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

From: Michael Richardson <[email-masked]>
Date: Tue, 03 Mar 2020 09:45:43 -0500

Laurence's slides not yet posted to https://siot-hackathon.github.io/agenda,
but I hope they will be.

From: "Smith, Ned" <[email-masked]>
To: Michael Richardson <[email-masked]>
Subject: Re: IDevID and TPM devices

Michael,
I looked at https://tools.ietf.org/html/draft-richardson-anima-masa-considerations-02 and Laurence's tutorial slides. The IDevID aspects seem to be inline with my understanding. Laurence's slides don't go into much detail.

Section 2 of anima-masa is correct. There is variation of 1) that provisions some setup FW to generate the keys on the device then removes the setup FW so that in the case of DICE, the setup FW isn't included in the seed computation for generating the IDevID.

The basic difference between a DICE key derivation an 'traditional' is the key gen algorithm isn't a random seed, but a seed computed from a PUF or similar secret plus a hash of the FW. This way, if the FW changes, the key is not re-generated / usable. This forces the device to quarantine itself if the device is modified in an unexpected way.

The 3rd (TPM) approach isn't different from 1) or 2) in the draft as the TPM is a device that gets provisioned by a manufacturer. The difference is the software that uses the TPM has to execute on a trusted environment (e.g. Root of Trust for Measurement - RTM or a trusted execution environment such as NIST SP800-155 terminology "Measurement Agent"). The Measurement Agent and RTM have to be securely bound / connected to the TPM. The TCG uses the term "trusted building block" to abstractly refer to any number of ways the binding might be implemented.

The point of this background is the mfg needs to not only provision IDevID, but it needs to provision FW / SW into all the places where the "Measurement Agent" and Roots-of-trust exist. And provide Endorsement and/or Evidence that everything was constructed and provisioned correctly.

Section 3 possibly inaccurately positions that the "end entity" certificate is the end of the certificate chain. In reality, the EE is more like a CA if it creates keys that are allocated to another "measurement agent" in the device. This is where "layered attestation" and "layered device" concepts differ from Laurence's tutorial. Possibly, Composite Device concept also involves some form of 'embedded CA' that issues certificate (aka 'signed documents containing a public key').

I don't have suggested wording changes, only to point out there is hidden complexity and the current wording doesn't try to expose it. The wording you have may nevertheless be accurate as is.

In section 3.2 it suggests keys are stored in an HSM. A DICE layering model would not necessarily require an HSM but could be re-derived at power reset. Someone could argue that an always-on system has the equivalent of an HSM in memory.

Section 3.3 says " This suggests that it can not be the same
   intermediate CA that is used to sign the IDevID, since that CA should
   have the authority to sign vouchers.  If it did, then the End-
   Entities that it created, the IDevID for devices, would then be able
   to sign vouchers, which would not be an appropriate authorization."
I'm not sure the wording or sentence structure is clear. Reads like a fragment or collection of fragments.

Layering concepts allow the IDevID to be issued to a fundamental layer known to the mfg. Subsequent layers could have additional complexity that supports vouchers, onboarding and provisioning of cross-domain anchors as well as provisioning of LDevIDs.

I'm still not sure I understand how a MASA differs from either a CA or a EE. Both are authorized to sign things. If there is a cert path to a mfg then they are mfg authorized. Often CA can sign more than just certificates. It seems the paragraph in quotes is asserting otherwise?

Thx,
Ned

On 2/21/20, 8:21 AM, "Smith, Ned" <[email-masked]> wrote:

    Michael,
    Is there a link to Laurence's slides?
    The link is to a draft spec for DICE. There is a final version available now.
    I'll look at draft-richardson-anima-masa-considerations-01

    -Ned

    On 2/21/20, 4:39 AM, "Michael Richardson" <[email-masked]> wrote:

        Smith, Ned <[email-masked]> wrote:
            > The TCG tries to avoid specifying HW implementation. However, the TCG
            > DICE spec
            > (https://www.trustedcomputinggroup.org/wp-content/uploads/Device-Identifier-Composition-Engine-Rev69_Public-Review.pdf)
            > comes close. I'm aware of at least one implementation of a firmware TPM
            > that uses a DICE RoT.

            > There is also a TCG specification in progress that defines the various
            > TPM supported keys (IDevID, LDevID, IAK, LAK, EK) that may be used or
            > provisioned during onboarding. Unfortunately, this specification has
            > been under development for multiple years and it isn't clear how
            > motivated the authors are to publish it. (Fine wine?). This isn't
            > exactly what you're after, but it is a TCG document that says the most
            > about IDevID.

        Hi, trying to clean up some old email threads.
        Did you see Laurence's slides on the three ways to initialize the IDevID on Monday?
        THe specification you mention above, is that the DICE URL above, or a
        different document?

        I have too many TCG documents to read right now.

        I wrote draft-richardson-anima-masa-considerations-01 in December in an
        attempt to capture some of this: I'm seeking reviewers and/or co-authors with
        more contact at silicon and device makers who will tell me what is
        wrong/native/unworkable.

        --
        ]               Never tell me the odds!                 | ipv6 mesh networks [
        ]   Michael Richardson, Sandelman Software Works        | network architect  [
        ]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Michael Richardson <[email-masked]>
Date: Tue, 03 Mar 2020 17:33:20 -0500

> Laurence's slides not yet posted to https://siot-hackathon.github.io/agenda,

Laurence's slides are actually at:
           https://siot-hackathon.github.io/slides/rats01.pdf

it's just that the ones I care about are way at the end, look for "Key Setup"

---

From: Michael Richardson <[email-masked]>
Date: Sun, 08 Mar 2020 17:31:15 -0400

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.

---

From: Michael Richardson <[email-masked]>
Date: Mon, 09 Mar 2020 12:50:57 -0400

Michael Richardson <[email-masked]> wrote:
    > I looked at
    > https://tools.ietf.org/html/draft-richardson-anima-masa-considerations-02
    > and Laurence's tutorial slides. The IDevID aspects seem to be inline
    > with my understanding. Laurence's slides don't go into much detail.

I agree that the slides are very high-level.
I have been trying to find public (no NDA) examples from industry that go
into more detail.  In particular, I would like, for each of the three methods
to have references to manufacturers who use that method.
A set of three terms would be also very nice, even if it's just "Yellow"/"Green"/"Blue",
or three other content/judgement-free terms, such as names of three rivers :-)

My belief is that the method of generation will come into audits of supply
chain security.

    > Section 2 of anima-masa is correct. There is variation of 1) that
    > provisions some setup FW to generate the keys on the device then
    > removes the setup FW so that in the case of DICE, the setup FW isn't
    > included in the seed computation for generating the IDevID.

By FW, do you mean firmware?

    > The basic difference between a DICE key derivation an 'traditional' is
    > the key gen algorithm isn't a random seed, but a seed computed from a
    > PUF or similar secret plus a hash of the FW. This way, if the FW
    > changes, the key is not re-generated / usable. This forces the device
    > to quarantine itself if the device is modified in an unexpected way.

The manufacturer knows the hash of the firmware, and I would think that this
could easily become public.  A PUF is usually known to the manufacturer only
(and the device).   I can see how this generates an interesting key with
which to sign evidence, but I don't think that an IDevID can be generated in
this way, as I would expect the IDevID to be the same across firmware updates.

    > The 3rd (TPM) approach isn't different from 1) or 2) in the draft as
    > the TPM is a device that gets provisioned by a manufacturer.

Yes, I would say that I have been led to believe that in some cases TPM
devices were shipped with private keys already provisioned.  I understand
that this is never the case.

    > Section 3 possibly inaccurately positions that the "end entity"
    > certificate is the end of the certificate chain. In reality, the EE is
    > more like a CA if it creates keys that are allocated to another
    > "measurement agent" in the device.

We don't set the CA=True bit on End-Entity certificates, which prevents them
from creating new PKIX-format certificates.  But that doesn't prevent them
from signing other artifacts which might also attest to things other than identity.

    > I don't have suggested wording changes, only to point out there is
    > hidden complexity and the current wording doesn't try to expose it. The
    > wording you have may nevertheless be accurate as is.

    > In section 3.2 it suggests keys are stored in an HSM. A DICE layering
    > model would not necessarily require an HSM but could be re-derived at
    > power reset. Someone could argue that an always-on system has the
    > equivalent of an HSM in memory.

The HSM is for the root-CA PKI at the manufacturer.
I want to make sure we are talking about the same thing here.

    > Section 3.3 says
      " This suggests that it can not be the same

    > fragment or collection of fragments.

I have rewritten that section.

    > Layering concepts allow the IDevID to be issued to a fundamental layer
    > known to the mfg. Subsequent layers could have additional complexity
    > that supports vouchers, onboarding and provisioning of cross-domain
    > anchors as well as provisioning of LDevIDs.

    > I'm still not sure I understand how a MASA differs from either a CA or
    > a EE.. Both are authorized to sign things. If there is a cert path to a
    > mfg then they are mfg authorized. Often CA can sign more than just
    > certificates. It seems the paragraph in quotes is asserting otherwise?

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

---

From: Laurence Lundblade <[email-masked]>
Date: Mon, 9 Mar 2020 13:15:44 -0700

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 <[email-masked]> wrote:
> 
>

---

From: Michael Richardson <[email-masked]>
Date: Tue, 10 Mar 2020 16:31:03 -0400

Laurence Lundblade <[email-masked]> wrote:
    > I assume you are referring to slide titled "ECDSA key setup based on
    > 256-bit secret seed”, the first of the three.

Yes, I want to discuss that, as well as the other two slides.

    > 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.

Then, what's the point of your slide?
Are CHIP vendors going to run a database of IDevID certificates for each of
their OEMs?  How will they know what serial numbers and what extensions to
put into the certificates?

    > 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.

I don't really want to simplify the process, I want to point to real
instances of the process being used by real people.

    > 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.

That still seems to skip a major step: how does the OEM get the TEE app
loaded?   If this can only be done by $1B/year OEMs, then we are doomed.

    > 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.

That's not the case.
The point on the curve is a secret, and it needs to be a random point.
To say that there is no computation is inaccurate:  true, with RSA you have to
test if the key is prime, but once you have it, you have it.
Making it (an RSA private key) deterministically found from a secret seed
takes a bit of care to get all the tests in the right order, etc. but it can
be done.

    > 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.

I thought the TPM had an attestation key, but none of them that I have
purchased seem to.   The OEM has to configure/generate them.  It is this
process that I care about, because the IDevID also needs to be built at that
point.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [