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

[Michael Richardson <[e-mail]>]

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

From: "Smith, Ned" <[e-mail]>
To: Michael Richardson <[e-mail]>
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" <[e-mail]> 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" <[e-mail]> wrote:


        Smith, Ned <[e-mail]> 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  [
        ]     [e-mail]  http://www.sandelman.ca/        |   ruby on rails    [







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