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

[Laurence Lundblade <[e-mail]>]

I assume you are referring to slide titled "ECDSA key setup based on 256-bit secret seed”, the first of the three.

I think it is possible to have this partly done by the chip vendor and partly by the board vendor, but that’s not what I’d envision. It seems more complex and a lot less secure because of the transfer of the millions of secret keys from the chip vendor to the board vendor. I think there are business reasons too. I don’t know that chip vendors would share the private keys like this.

In such a document as this, I’d just describe it as if the board vendor did it all, or the chip vendor did it all to be simpler. 

Note that some chips have extra fuses that the board vendor can use to put keys into. Or, they might just put the keys in a TEE app. That will be secure enough for many use cases. The TEE app has to use the key anyway to signing tokens or such.

With ECDSA you don’t use a PRNG. The secret seed is just the point on the curve that is the private key. There is no computation.  You can do it each time you need the key, not at boot. You can also make a key ID by hashing the secret seed and this is not expensive.  The ECDSA public key does require computation, but you can avoid ever doing it on the device. You can do it on a separate system.

You can turn it into a certificate or not. It is perfectly fine for a Verifier to have buckets of bare public keys. If you turn it into a certificate, there is an additional signing operation. That might matter if the volume of device is really high. 

There does need to be a key ID on the device that is given to the Verifier along with the signature. If you are using X.509 certs it can be the subject key identifier. If not it’s just a COSE Key ID used to look up a public key. The key ID can be the serial number or be mapped to it or be KDF’d from the secret seed or such.

With RSA you do need the PRNG and it is much more difficult because RSA key gen is much more expensive. It might be too expensive to do on first boot if that is part of a high-speed assembly line. It might be better to do on first use. Seems like it would be better to just describe all this for ECDSA and skip RSA. The key sizes you need with RSA today seem mostly to big for IoT devices and their small CPUs.

I doubt any of this works for a TPM and you probably don’t even want to to it because a TPM already has an attestation key. That’s part of what you pay so much for.

TEEP is not a description of TEEs. Maybe try https://globalplatform.org/specs-library/ <https://globalplatform.org/specs-library/tee-system-architecture-v1-1/>tee-system-architecture-v1-1/ <https://globalplatform.org/specs-library/tee-system-architecture-v1-1/> or https://en.wikipedia.org/wiki/Trusted_execution_environment

LL



> On Mar 8, 2020, at 2:31 PM, Michael Richardson <[e-mail]> wrote:
> 
> 
> 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 =-
> 
> 
>