# Destructive Hardware Trojan Detection Protocol Brainstorming
**URL:** https://collective.flashbots.net/t/destructive-hardware-trojan-detection-protocol-brainstorming/3596
**Category:** Research
**Tags:** brainstorming
**Created:** [June 26, 2024, 3:11am UTC](https://collective.flashbots.net/t/destructive-hardware-trojan-detection-protocol-brainstorming/3596 "2024-06-26T03:11:47Z")
**Posts on this page:** 4
**Page:** 1
### Author:  [@Quintus](https://collective.flashbots.net/u/Quintus)
#### Post date: [June 26, 2024, 3:11am UTC](https://collective.flashbots.net/t/destructive-hardware-trojan-detection-protocol-brainstorming/3596/1 "2024-06-26T03:11:48Z")
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](https://swarup.ece.ufl.edu/papers/IC/IC6.pdf) or [this](https://eprint.iacr.org/2022/1720).
### Notes:
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.
- 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:
- 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:
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.
EDIT: since writing we realised that there are somewhat promising directions for non-destructive analysis. One is x-ray ptychometry, which is expensive and the other is a [combination of short-wave infra red imaging with scan chains](https://www.bunniestudios.com/blog/2024/iris-infra-red-in-situ-project-updates/).
---
### Author:  [@guayabyte](https://collective.flashbots.net/u/guayabyte)
#### Post date: [June 26, 2024, 5:19am UTC](https://collective.flashbots.net/t/destructive-hardware-trojan-detection-protocol-brainstorming/3596/2 "2024-06-26T05:19:26Z")
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](https://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_ReflectionsonTrustingTrust.pdf), 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?
---
### Author:  [@Quintus](https://collective.flashbots.net/u/Quintus)
#### Post date: [June 26, 2024, 11:34pm UTC](https://collective.flashbots.net/t/destructive-hardware-trojan-detection-protocol-brainstorming/3596/3 "2024-06-26T23:34:17Z")
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.
---
### Author:  [@gluonix](https://collective.flashbots.net/u/gluonix)
#### Post date: [June 28, 2024, 1:08am UTC](https://collective.flashbots.net/t/destructive-hardware-trojan-detection-protocol-brainstorming/3596/4 "2024-06-28T01:08:39Z")
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](https://eprint.iacr.org/2022/1720) by Puschner et al, linked above, mention the following:
> “_New non-invasive scanning methods based on X-Rays [[17]](https://www.nature.com/articles/s41928-019-0309-z) 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._”