Secure Collaboration for Chip Design in Cloud Environments
Earlier this year, Perforce hosted the Embedded DevOps Summit, exploring solutions to modern challenges in the planning, development, and testing stages of embedded software. As part of this event, Warren Savage, Visiting Researcher at the Applied Research Laboratory for Intelligence and Security (ARLIS) at the University of Maryland, presented Secure Collaboration in Cloud-Based Chip Design Environments.
Warren is currently engaged as the Principal Investigator for the Independent Validation & Verification (IV&V) of DARPA’s Automatic Implementation of Secure Silicon (AISS) program which has the lofty goal of changing the ways chips are designed from a security point of view. The challenges of this effort are enormous involving establishing a secure, cloud-based infrastructure in which up to 15 universities and companies can work securely handling highly valuable source code and ensuring that is only in the hands of authorized personnel involved in the program.
This blog discusses the difficult requirements to this program, and how one tool was able to serve as a critical technology to enable dozens of designers to efficiently and securely work together.
Want to see the presentation?
▶ Watch Here
Chip Design Challenges
Transistors were first created in the late 1950’s and over the course of the last 60 years, people have found increasingly creative ways to put those transistors together in new ways: from transistor radios, to two-way radios, clock radios, video games, mobile phones, and eventually smart phones.
This progression of increasingly sophisticated electronics have been enabled through continuous advances in semiconductors. Over time, things have gotten progressively more complex and we're entering a phase right now where applications are becoming “smart” — smart homes, smart cities, smart grid, smart medical devices, smart retail, smart supply chains, smart farming, etc. These are our next frontier in semiconductors and system design.
But what makes these things “smart”? In a word — connectivity. Today, there are an estimated 35 billion of these devices connected to the internet. That number is expected to double by 2025. Connectivity means these devices can collaborate and, like cells of the human brain, that connectivity calls for “smart” things to happen. That all sounds wonderful and great, but a connected world is a dangerous place.
Such smart devices have infiltrated our lives. We have cars now that talk to the internet continuously. We have shopping retail experiences where you walk into a store, the store knows that you are in that store through your GPS information, and it may offer you a special price on products that you want to buy. This is the internet of things; devices behinds the scenes are talking in a conspiracy to make you want to make something.
It's a fascinating new frontier that's coming, but it also brings with it new threats to our security. In the previously mentioned presentation, four particular threats to semiconductor security are identified:
- Side Channel: Extraction of secrets through physical communication channels other than intended.
- Reverse Engineering: Extraction of algorithms from an illegally obtained design representation.
- Malicious Hardware: Insertion of secretly triggered, hidden, and/or disruptive functionality, typically for purposes of sabotage or espionage.
- Supply Chain: Cloning, counterfeit, recycled, or re-marked chips represented as genuine.
However, as with any frontier, expertise in security is a rare commodity in semiconductor design today. There are simply not enough people with these skills to go around. The aim of AISS is to democratize security by embedding it into the design (EDA) tools and design IP making those capabilities ubiquitous and available to non-security-expert chip designers.
AISS intends to change the way people design chips. In traditional chip design, there are three dimensions: performance, power, and size. The program adds a fourth dimension — security — so that when a designer designs a chip, they will not only make decisions based on the first three dimensions, but also consider the desired security level as one of their design constraints.
In considering security, it is useful to think about each of the above-mentioned attack vectors in terms of why individuals would want to do this, which essentially boil down to four main motivators:
- Economic gain
- IP theft
For more in-depth discussion of these four aspects, the methods and motivations behind them, and real world examples, we encourage you to watch the full presentation.
Setting up the cloud-based infrastructure for AISS presented many challenges:
- Mandate that AISS must operate entirely in a cloud environment.
- Many different players of different types: commercial, academic, defense industrial base.
- Fine-grain access control to software and hardware technology.
- Semiconductor engineers are not accustomed to operating in a cloud environment.
- Fixed-cost government project.
- Secure boundaries around certain pockets of technology to avoid IP contamination.
Given that most engineers and academic researchers are not familiar with cloud-based computing, the approach taken was to make it look as much as possible like the users are working in an traditional on-prem design environment. When the user logs into the cloud, they are in their own area, can view their team and resources, and have a little area that is private and not visible to others. But there is also a shared area with a number of tools that everyone has access to. This is where Perforce lives.
If you look at the big picture diagrammed below, the left side shows all the different companies working in their own pods, but securely connected to other areas of the cloud to do their work. You will note Perforce in the secure, Shared Applications space.
How Perforce Enables Secure Collaboration in Cloud-Based Chip Design
In the diagram below, you will see three companies, each of which has a number of users and assets (such as software they own). The challenge is to make it all work together. Some companies will work with other companies more than other companies and require extensive collaboration. Perforce is particularly well-suited for this task.
Company A’s users have write access to everything within their company. Everything is private in that regard. But let’s say that Company A needs to coordinate with Company C, sharing one of their assets. To do this, they will set up read access for that particular asset for Company C to use. Another more permissive example would be granting open access to another company, and ever more permissive than that would be granting write access, all of which are illustrated below.
The value that Perforce provides is the creation of this crossbar switch, where users and assets can be shared at a very fine grain level. This is a very powerful feature that doesn’t exist in any other source code management system, at least to the degree that is needed in the DARPA AISS program. While they are in the early stages of the program, there will be more learnings and innovations, but so far so good.
Click below for the full on-demand replay of this presentation:
To learn more about leveraging Perforce solutions for cloud-based chip design, speak to one of our Methodics IPLM experts today.