As discussed at more length in this post, its essential that we are able to verify that a physically instantiated piece of hardware is manufactured according to spec and does not have bugs or backdoors from inserted by the designer, the fab or any other supply chain actor.
I’m writing a short summary of what we’ve thought of so far for anyone trying to get up to speed. Most of it is taken from the article I linked above.
Kinds of trojans
I refer to “triggered” and “untriggered” trojans. The former only become active after a certain time or after a pre-specified input has been provided, which typically requires more logic. We can also divide trojans into those which undermine defenses (e.g. introducing a timing or EM side channel) or those that change the logical functionality (e.g. incorrectly executing AES).
Bunnie gives a nice taxonomy in this talk, which focuses on difficulty of detection.
Enrollment Protocol
Especially for remotely attested hardware (to which the relying party never has access), a protocol for checking for trojans is needed. The idea is to use randomness to assign chips to one of a diverse range of verifier labs. There are lots of extra things we can do to make this protocol more secure. E.g. randomly sampling chips that have already been checked to be checked by other verifiers or intentionally inserting chips that should be detected by the verifier.
The entire process should be recorded on a public blockchain. At the end of the day, the end user receiving a signed attestation from a hardware key should be able to check an on-chain record of the chip being registered on-chain, randomly (not) assigned, attested to by verifiers and randomly allocated to the operator.
Testing Methodology
The cheaper and more efficient a testing methodology becomes the more chips we can test. We assume that the verifiers have access to all design files, down to the GDS (perhaps under NDA). We’ve considered several different technologies, but not at much depth. More work needs to be done here.
- Delayering + SEM: we expect that this is the most thorough technique, but since its destructive we can only image a sample of the chips and its impossible to check a verifier’s work.
- IRIS: This is appealing since its non-destructive. As far as we have looked, this is the only non-destructive approach which won’t set one back 7 figures.
- TVLA and fuzzing: non-destructive, but will only catch certain kinds of trojans (e.g. maybe non-triggered). Testing TRNG entropy should fall in this category.
These could all be used in concert with many/all chips being fuzzed, some verified with IRIS and a smaller percentage destructively analysed.
Design Approaches
Some designs are easier to test than others.
- In his work on IRIS, Bunnie suggests using scan chains as a means to catch trojans that are beneath a certain size, but this has met with apprehension as scan chains could constitute a side channel attack vector.
- Another observation (formalised here and described here) is that we can rule out input-triggered trojans in circuits that operate on masked values as these should be random. Similarly, we can protect against timed trojans by regularly briefly cutting power to some circuits so that volatile memory in the circuit is erased. Neither of these techniques are sufficient in themselves but can complement other techniques like IRIS.
Questions
- Can we arrive at a solution that allows for easy and effective trojan detection while simultaneously not introducing physical attack vectors. For instance, Bunnie’s IRIS requires an unprotected silicon backside, which means laser fault injection is possible.
- If we introduce additional defenses after testing, do we need a second layer of verification to verify that the defenses have been correctly applied? If so, how do we ensure that defenses are added before the sampling is conducted as we don’t have the PUF hardware key to rely on to tie these defenses to the chip?
- Can untriggered trojans circumvent black box testing like TVLA and fuzzing?
- Can scan chains or boundary scans be used without physically compromising the chip?
- Who would be good verifiers?