WP_Term Object
(
    [term_id] => 111
    [name] => Zentera
    [slug] => zentera
    [term_group] => 0
    [term_taxonomy_id] => 111
    [taxonomy] => category
    [description] => 
    [parent] => 14433
    [count] => 6
    [filter] => raw
    [cat_ID] => 111
    [category_count] => 6
    [category_description] => 
    [cat_name] => Zentera
    [category_nicename] => zentera
    [category_parent] => 14433
)

Next Generation Remote Access: Under the Hood

Next Generation Remote Access: Under the Hood
by Paul McLellan on 08-16-2013 at 2:56 pm

I wrote a few weeks ago about Zentera’s push to create a new standard for remote access that allows semiconductor companies and EDA companies to cooperate on resolving issues without requiring that the semiconductor company’s IP leaves the company network. At the 50,000 foot level, Zentera’s technology allows a secure version of the GDB debugger to be run at the semiconductor company’s site in a controlled environment where the semiconductor company controls exactly which data is and is not accessible. Zentera call this restricted environment a cloud chamber.

 There are actually three layers in the implementation model (well, actually more since each layer has sub-layers). At the bottom level is the existing IT infrastructure: the internet, local networks at the EDA company and the semiconductor company. Zentera does not require any physical infrastructure changes to maintain the security of the remote access. On top of this is the first layer of Zentera’s secret sauce that creates a secure virtual platform. The level above that are the Zentera EDA access applications.

The secure virtual network platform has an end-to-end virtual network that allows authorized network traffic only. It is fully encrypted using 256 bit AES. This is all fully decoupled from existing network and augments existing security. There is no native file transfer capability preventing IP leakage and all activities are logged. Access to the chamber is by highly controlled invitation only from the owner of the Zentera solution. This eliminates “who bought the other fax machine?” issue where both parties had to invest for the solution to work.


To the EDA engineer it looks as if he or she is working on the problem locally. But under the hood Zentera’s virtual network switch (VNS) is controlling access. This in turn is driven one level up by the controller’s web portal that hooks up the client and server in the first place. zGDB actually consist of two halves, a client part that runs on the EDA engineer’s desk and a server part that runs inside the semiconductor company’s network where it has limited access to whatever design data is required to fix the problem.


The above diagram shows how the process works in more detail:

[LIST=1]

  • At the semiconductor company the Zentera admin creates security infrastructure: users, groups, access and creates the cloud chamber that will be used to debug the problem
  • The EDA engineer Ed (Ed for EDA) receives login credentials
  • The design engineer Chip (err…I think that one is obvious) logs in and invites Ed to join in the cloud chamber
  • Ed logs in and connects zGDB
  • The Zentera gateway provides Ed with a zGDB client which is locked to the zGDB server that runs at the semiconductor company. Ed can now debug the problem
  • When Ed is finished, Chip can terminate all access
  • The admin removes the session completely. Everything is back how it was before with no authority for the EDA company to access the semiconductor company’s network or data

    Share this post via:

  • Comments

    There are no comments yet.

    You must register or log in to view/post comments.