Destructive Hardware Trojan Detection Protocol Brainstorming

The following are notes from the Crypto Academic Workshop at Edge City.

Problem Description

There are several problems that need to be solved to make the TEE trust model palatable for a wide set of Web3 use cases. One of these is defense against hardware trojans - i.e. hardware that is maliciously buit to deviate from spec, potentially compromising any system running on top of it. The goal of this discussion was to arrive at a sort of “decentralised quality assurance protocol”, which provides some guarantees over hardware correctness under more reasonable assumptions than the honesty of the manufacturer, a sole party.

We assume any analysis must be destructive.

Note that it is insufficient for a prospective buyer to purchase superfluous TEEs and conduct their own sampling and analysis. Manufacturers and TEE operators may collude and we assume a TEE operator must also convince multiple counterparties of the correctness of their hardware.

This is separate form (but related to) defense against manufacturers keeping copies of hardware secrets and phsyical tamper resistance.

For more background on hardware trojan detection, you can read this or this.


We did not arrive at a protocol, but have several constructive thoughts to share.

  • Once a verifier claims that they have some conclusion after analysis, how do we verify this given that the process employed is destructive? Can we stop halfway through the process and use the remaining parts of the chip to support a claim of misbehaviour? If not, we need to guard against verifiers making spurious claims.

    • If we can stop the manufacturing process halfway, how can we associated the semi-destroyed chip with its identity? Presumably the identity is derived from platform secrets, but if the chip is no longer functional, these may no longer be used in an authentication protocol.
  • The analysis is very hard to pull off as even subtle deviations in chip design can open channels for information exfiltration [must add link].

  • A QA protocol may begin something like this:

      1. all chips in a batch are registered on-chain.
    • 1a) (optionally) some intentionally modified chips are also registered on chain, along with a commitment to show that these are indeed tampered with
      1. a verifiable randomness beacon is used to shuffle and randomly select devices for analysis
    • 2a) (optionally) Whistleblowers are allowed to put down some collateral to identify chips that ought to be analysed
      1. results of analysis are posted on chain
    • 3a) (if step 1a is followed) the committed list of intentionally compromised chips is revealed.
      1. purchasers registers their desire to purchase chips on chain. Again, using a randomness beacon we randomly select from the remaining chips and assign to the buyers.
  • As indicated above, we can defend against lazy verifiers by intentionally inserting compromised chips into the testing process. This would require a manufacturer to comply, potentially increasing attack surface area.

  • In the protocol above, it is unclear how to handle the cases in which:

    • the verifier is assigned a chip that is on the list of (supposedly) intentionally modified chips, but the verifier does not flag it
    • the verifier flags a chip which is not on the test list as malicious

One way to address the above is to do analysis in a public setting. In a similar way to some vote recounting processes.

Watermarking the hardware could be a way to connect a semi-destructed chip with an identity or manufacturer but needs to explored a bit more.

1 Like

Can the machines that print the chips run in a trusted enclave?
Can a hash and attestation be printed into the chip?

This bootstrapping will ultimately hit the trusting trust problem, but it’s fascinating to start thinking about reproducible [chip] builds, visual auditability, compare hashes between chips somehow, and to use advanced technology similar to the one used for side-channel attacks to verify correctness.

Are we thinking about destructive tamper-proof mechanisms because open, diy, reproducible, verifiable chips sound too far in the future?

1 Like

All good questions to which I don’t have any answers.

We focused on destructive techniques because these seem the hardest to build a protocol around and because (from my little reading so far) they seem like the most potent technique.

Just to put this here, for future explorations on non-destructive approaches:

Red Team vs. Blue Team: A Real-World Hardware Trojan Detection Case Study Across Four Modern CMOS Technology Generations by Puschner et al, linked above, mention the following:

New non-invasive scanning methods based on X-Rays [17] seem more promising for the future
than the lengthy process of delayering and imaging the chip. These non-invasive techniques are potentially able to scan all metal layers and provide a 3D-image of the entire routing without destroying the device, but the research on this subject is still at an early stage.

1 Like