Skip to content

Thoughts on current trusted hardware core problems #2

@sbellem

Description

@sbellem

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions