Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Thoughts on current trusted hardware core problems #2

Open
sbellem opened this issue Mar 1, 2023 · 2 comments
Open

Thoughts on current trusted hardware core problems #2

sbellem opened this issue Mar 1, 2023 · 2 comments

Comments

@sbellem
Copy link
Owner

sbellem commented Mar 1, 2023

Goal: Security through Physics

Current challenges facing trusted hardware:

  1. NO "proof of manufacturing" according to a known open source chip design specification
  2. NO proof that whatever secrets were encoded into the hardware are not known to anyone
  3. NO proof that physical attacks are not possible
  4. Centralized remote attestation -- depends on the manufacturer (see https://www.rfc-editor.org/rfc/rfc9334.html#name-security-considerations)

Note: Concern 2 is in a way a subset of concern 1.

Concern 1: Proof of Correct Manufacturing for an Open Source Hardware Specification Design

For concern 1 above, initiatives like OpenTitan + Keystone Enclaves, and more recently Caliptra, address the concern partially.

A while ago, when looking into this, I came across https://hensoldt-cyber.com/mig-v/, but I cannot find a more detailed description right now.

From what I recall the gist was that they could provide a "proof of manufacturing" to make sure that a chip had been manufactured as per a given specification. This may be a somewhat standard & common practice for highly critical applications (e.g. military), but may be challenging for chips with nano-scale components.

Concern 2: Proof of No-Leakage of Root Key at Manufacturing Time

For concern 2 above, perhaps PUFs? I don't enough about it. Do PUFs require some kind of initial measurement that must be kept secret?
Hence, if I understood correctly, PUFs would pose the problem that "someone" must know the measurement, or some information about it, and must safeguard it from attackers, and consequentially the protector of that measurement data becomes a trusted party, which is what we (or I at least) wish to avoid.

Concern 3: Proof of Physical Attacks Resistance

For concern 3 above, I feel it is the most challenging problem. Perhaps PUFs again?
It seems that PUFs can be attacked, especially via machine learning techniques. But perhaps these ML attacks can somehow be mitigated, but I don't know how.

As an aside there is a line of research on quantum PUFs that aims to address the limitations of PUFs in the classical (physics) setting. e.g. https://arxiv.org/abs/1910.02126

@amiller
Copy link

amiller commented Mar 10, 2023

For Concern 1: Proof of Correct Manufacturing for an Open Source Hardware Specification Design
a possibility is to do "Cut-and-Choose."

Suppose we have a way that we can inspect whether a chip was manufactured according to the specification, but doing so is destructive, either because it could leak the internal secrets or because the chip would just be unusable after. Furthermore, suppose this could be carried out by a public process, like a setup ceremony, whether the chip is analyzed in plain view / with lots of witnesses.

What an anonymous node operator could do is buy 40 CPUs (i'm not joking, hear me out), and commit to an enclave identity on each of them. Using a beacon lottery, e.g. a bitcoin block, randomly select 30 of the 40 to "open." These 30 are shipped to the analysis lab / public ceremony site. If all 30 of the "opened" CPUs pass inspection, then we have high probability that among the remaining 10 that we didn't open, at least say 9/10 of them are good too.

This does not solve the problem of whether it's possible to inspect a piece of hardware and see if it's compromised. It's also clearly wasteful and involves a complex "trusted setup ceremony." But, it does sidestep the manufacturer being the root of trust.

@sbellem
Copy link
Owner Author

sbellem commented Jul 24, 2023

Logic Encryption in the context of Open Source Hardware Designs

Regarding Concern 1: Proof of Correct Manufacturing for an Open Source Hardware Specification Design, something that may be relevant to look into, or at the very least learn about is Logic Encryption, but beyond its current usage and see whether it could be relevant to the blockchain world in the sense that chip making would align with the "don't trust but verify" moto.

Logic encryption implements a built-in locking mechanism on integrated circuits (ICs) to prevent reverse engineering and intellectual property (IP) piracy by a malicious foundry and user, and hinder Trojan insertion by a malicious foundry.

Resource

https://www.ice.rwth-aachen.de/publications/publication/sisejkovicETS2019/

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants