> In my opinion the industry should move away from embedding verified boot (digital signature verification) firmware in this ROM.
Interesting, is it possible to perform attestation without an embedded signing or verification key that way as well? If so, how is it possible to tie an attestation statement to a vendor that way?
Yes. I've described some of the flexibility characteristics elsewhere in this thread, but here's how you could do it:
1. The ROM stage measures the first mutable application stage A1, and makes the Compound Device Identifier (CDI) available to A1. CDI=Hash(UDS, Hash(A1), USS).
2. A1 creates a key pair for itself using CDI.
3. A1 measures A2 and creates a key pair for A2.
4. A1 signs A2's public key. This is the attestation.
5. A1 scrubs CDI and its private key from memory while ensuring that the attestation as well as A2's key pair is available to A2. Note that the TKey only supports two-stage boot chains at the moment.
Ah, I see, so rather than embedding a shared private key or a signed certificate, the private key is essentially deterministically created using UDS, USS, and the application hash?
Very interesting, I’ll have to wrap my head around the idea a bit more, but I think this also answered a couple of questions I had around PUFs.
Thank you, and good luck with the project, I’m always happy to see open projects in this space!
Interesting, is it possible to perform attestation without an embedded signing or verification key that way as well? If so, how is it possible to tie an attestation statement to a vendor that way?