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

[Michael Richardson <[e-mail]>]

Michael Richardson <[e-mail]> 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
        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.

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

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