Re: [Anima] IDevID and TPM devices and draft-richardson-anima-masa-considerations-02

[Michael Richardson <[e-mail]>]

Laurence, do you think this text matches your slide 32?
I would like to link to manufacturers that do this.

https://github.com/mcr/masa-operational-considerations/commit/a56e4255864cfb86aa14790505633e310fbfe18d

### Key setup based on 256-bit secret seed

A hybrid of the previous two methods leverages a symmetric key that is often provided by a silicon vendor to OEM manufacturers.
Each CPU (or a Trusted Execution Environment {{I-D.ietf-teep-architecture}}, or a TPM) is provisioned at fabrication time with a unique, secret seed, usually at least 256-bits in size.

This value is revealed to the OEM board manufacturer only via a secure channel.
Upon first boot, the system (probably within a TEE, or within a TPM) will generate a key pair using the seed to initialize a Pseudo-Random-Number-Generator (PRNG).
The OEM, in a separate system, will initialize the same PRNG, generating the same key pair.
The OEM then derives the public key part, signs it and turns it into a certificate.
The private part is then destroyed, ideally never stored or seen by anyone.
The certificate (being public information) is placed into a database, in some cases it is loaded by the device as its IDevID, in other cases, it is retrieved during the onboarding process based upon a unique serial number asserted by the device.

This method appears to have all of the downsides of the previous two methods: the device must correctly derive its own private key, and the OEM has access to the private key, making it also vulnerable.
The secret seed must be created in a secure way and it must also be communicated.

There are some advantages to the OEM however: the major one is that the problem of securely communicating with the device is outsourced to the silicon vendor.
The private keys and certificates may be calculated by the OEM asynchronously to the manufacturing process, either done in batches in advance of actual manufacturing, or on demand when an IDevID is demanded.
Doing the processing in this way permits the key derivation system to be completely disconnected from any network, and requires placing very little trust in the system assembly factory.
Operational security such as is often incorrectly presented fictionalized stories of a "mainframe" system to which only physical access is permitted begin to become realistic.
That trust has been replaced with a heightened trust placed in the silicon (integrated circuit) fabrication facility.

The downsides of this method to the OEM are: they must be supplied by a trusted silicon fabrication system, which must communicate the set of secrets seeds to the OEM in batches, and they OEM must store and care for these keys very carefully.
There are some operational advantages to keeping the secret seeds around in some form, as they same secret seed could be used for other things.
There are some significant downsides to keeping that secret seed around.





--
Michael Richardson <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-