You are currently viewing SemiWiki as a guest which gives you limited access to the site. To view blog comments and experience other SemiWiki features you must be a registered member. Registration is fast, simple, and absolutely free so please, join our community today!

Along came a trojan? GDSII vs Silicon check

Anshuman

New member
In countries without fabs: Many fabless companies and policy makers to support these fabless companies are wary of sending their tape outs to fabs in foreign countries.

There's a scare that these chips would come with trojans and back doors. And this Huawei tussle is not helping this argument either.

Any EDA tools out there that can do some kind of a check between the silicon and the GDSII to prove that nothing else was added to the chip at the fab end?

If there isn't one there's a big and growing demand for one.
 
Last edited:
In countries without fabs: Many fabless companies and policy makers to support these fabless companies are wary of sending their tape outs to fabs in foreign countries.

There's a scare that these chips would come with trojans and back doors. And this Huawei tussle is not helping this argument either.

Any EDA tools out there that can do some kind of a check between the silicon and the GDSII to prove that nothing else was added to the chip at the fab end?

If there isn't one there's a big and growing demand for one.
Not to my knowledge. Great idea though. An open source tool might work here.
 

mkjindal

New member
In countries without fabs: Many fabless companies and policy makers to support these fabless companies are wary of sending their tape outs to fabs in foreign countries.

There's a scare that these chips would come with trojans and back doors. And this Huawei tussle is not helping this argument either.

Any EDA tools out there that can do some kind of a check between the silicon and the GDSII to prove that nothing else was added to the chip at the fab end?

If there isn't one there's a big and growing demand for one.
I understand it as... kind of LVS for before and after silicon...
We at "chipspirit" are interested in working on this from Bangalore.
There are a couple of ideas to explore it further (and as this is a specific market, it needs co-development with only specific-customers ) :
1. Destructive: complete FIBBing layout on all the layers for different selected samples and this needs to be done.
2. Redundant data put on the masks for power profiling to detect unknown power profile, we know our per profile and if there's any other power profile we will be able to detect.
3. Empirical methods for formula based detections.
4. By creating test cases to create the actual war data on that chip and see how it behaves.
This is a problem out of no-problem so it can't be with same tools which are already there... it needs specific brainstorming and development.
 
Interesting: short of comparing actual die with GDS data, you can at least make it extremely difficult by filling vacant space with testable circuitry that is otherwise inactive. If paranoid you can get better coverage this way than by stripping a sample (if the foundry are determined the first batches could be dice without the Trojans/backdoors)
 

Yovav

New member
There is always a difference between the GDSII file sent to the foundry and the mask data (MEBES). This is because there are logical operations that are done on the GDSII layers, especially in advanced nodes.
The question is whether it is possible to convert back from mask data to GDSII and make sure all the changes that were done are due to process manufacturability.
There is also the issue of adding black box IPs by third parties just before the GDSII file hits the foundry.
 
There is always a difference between the GDSII file sent to the foundry and the mask data (MEBES). This is because there are logical operations that are done on the GDSII layers, especially in advanced nodes.
The question is whether it is possible to convert back from mask data to GDSII and make sure all the changes that were done are due to process manufacturability.
There is also the issue of adding black box IPs by third parties just before the GDSII file hits the foundry.
The GDS/MEBES mismatch is relatively easily handled if you use a foundry that lets you do the fill function. As a simplified example, you can use a simpified GDS to MEBES data and then do an XOR. Normally the resultant features will be smaller than a line-width. If not a preliminary sizing operation on your data should reduce the number of regions needing checking to a handle-able level.
The real problem would arise if the foundry decided to add the black box IPs after you had checked the MEBES data - or even after you have taken first delivery and erformed hazard checks.
Asuming you can't trust your foundry, this is where adding trivial but testable circuitry so there is no space left for unwanted circuitry is potentially valuable.
 

davemill

New member
Great question, and at least DARPA has been looking at securing the IC parts supply chain.

I participated in several long conversations with DARPA staff regarding their Trusted Foundry initiative, about 15 years ago (~65nm). They had identified many distinct categories of hostile IP threats (make the chip fail completely, make the chip undetectably unreliable, make the chip detectably unreliable, intercept data from the chip, inject data into the chip, control the chip, etc.) That team had already come to the conclusion that the growth in third-party IP and the many necessary changes that are made to a mask by multiple parties after it leaves the design team's hands mean that there are far too many ways to insert hostile IP to combat them all. Their concept at that time was to create a Trusted Foundry with a secure design, tool and IP custody chain, presumably all on US soil. Unfortunately, foundry technology evolves so quickly they could not gather a fraction of the necessary ecosystem for a node before everyone got distracted by the next node. At the time, their target foundry was IBM in New York.

The newer initiative described in Daniel Payne's post may have more potential to succeed, but I wonder if it can guard against all the different hostile IP attacks described above.
 
Top