Array
(
    [content] => 
    [params] => Array
        (
            [0] => /forum/index.php?threads/along-came-a-trojan-gdsii-vs-silicon-check.11405/
        )

    [addOns] => Array
        (
            [DL6/MLTP] => 13
            [Hampel/TimeZoneDebug] => 1000070
            [SV/ChangePostDate] => 2010200
            [SemiWiki/Newsletter] => 1000010
            [SemiWiki/WPMenu] => 1000010
            [SemiWiki/XPressExtend] => 1000010
            [ThemeHouse/XLink] => 1000970
            [ThemeHouse/XPress] => 1010570
            [XF] => 2020771
            [XFI] => 1050170
        )

    [wordpress] => /var/www/html
)

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:

Daniel Nenni

Admin
Staff 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.

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.
 

Anshuman

New member
Wow, thanks guys. Really appreciate all the comments. :)

I guess logic lock is one of the ways of solving this problem. Any one actually implemented a logic lock in their design?

Secondly, it seems some SoCs go out of the way to insert some other "Design for Trust" features to keep the Trojans detectable.

Lastly, as mentioned here and in other threads on this wiki there seem to have been a few spotted Trojans. Any one have a story or case to share?
 
Last edited:

hskuo

Active member
From my past experience, it should be very very challenging. When you tapeout in Foundry, for each IP, there will be IP tag to check IP license during tapeout. If there is any IP insertion, it could be found and reported. Besides, typically foundry will provide jobview before mask making. You have chance to check any abnormality then also. Another input, in advanced node, due to variation and manufacturability, foundry will try to fill dummy features or on-chip metrology marks for process variation control. It will be very challenge to add >5umx5um marks without impact device routing. If these trojans exist, they should be <5umx5um, have foundry help you insert it, wireless and no need for power, no impact for your circuit operation, your engineers can not catch it during jobview, and very lucky to escape any engineering analysis due to fail parts.
 

Anshuman

New member
From my past experience, it should be very very challenging. When you tapeout in Foundry, for each IP, there will be IP tag to check IP license during tapeout. If there is any IP insertion, it could be found and reported. Besides, typically foundry will provide jobview before mask making. You have chance to check any abnormality then also. Another input, in advanced node, due to variation and manufacturability, foundry will try to fill dummy features or on-chip metrology marks for process variation control. It will be very challenge to add >5umx5um marks without impact device routing. If these trojans exist, they should be <5umx5um, have foundry help you insert it, wireless and no need for power, no impact for your circuit operation, your engineers can not catch it during jobview, and very lucky to escape any engineering analysis due to fail parts.

There's a full symposium on this subject. (I have nothing to do with it, just showing how big this issue is)

IEEE International Symposium on Hardware Oriented Security and Trust (HOST)


December 6-9, 2020
DoubleTree by Hilton
San Jose, CA, USA
 

schemmel

New member
From my past experience, it should be very very challenging. When you tapeout in Foundry, for each IP, there will be IP tag to check IP license during tapeout. If there is any IP insertion, it could be found and reported. Besides, typically foundry will provide jobview before mask making. You have chance to check any abnormality then also. Another input, in advanced node, due to variation and manufacturability, foundry will try to fill dummy features or on-chip metrology marks for process variation control. It will be very challenge to add >5umx5um marks without impact device routing. If these trojans exist, they should be <5umx5um, have foundry help you insert it, wireless and no need for power, no impact for your circuit operation, your engineers can not catch it during jobview, and very lucky to escape any engineering analysis due to fail parts.
If the foundry is compromised, the jobview and similar reports from the foundry will not help. A physical LVS is the only safe solution (and you have to repeat it continuously during the time the ASIC is in production.
 
I believe Chipworks have a circuit reverse engineering flow: from chip to circuit schematic.

I think they are now part of TechInsights providing their Circuit Analysis service. I also think it will cost you a figure with 5 or 6 digits.

Personally I have been thinking about timing behavior of the ATPG test; e.g. increase the clock frequency of the testing and see if it starts to fail in correct ways. This should it make quite difficult to insert something functional in the circuit.
 

hskuo

Active member
If the foundry is compromised, the jobview and similar reports from the foundry will not help. A physical LVS is the only safe solution (and you have to repeat it continuously during the time the ASIC is in production.
If foundry intended to add this malicious circuit after you tape in design to fab, will LVS be applied on your original design or on the manipulated one ?
 

schemmel

New member
If foundry intended to add this malicious circuit after you tape in design to fab, will LVS be applied on your original design or on the manipulated one ?
you have to do the LVS on the manufactured silicon -> therefore my term "physical", i.e. using FIB or similar methods to reconstruct the manufactured circuit structure. I am not sure how feasible this is from a technological point of view, but to my knowledge it would be the only reliable way to check for tampering.
 
Top