Subject: Re: [T2TRG] Comments on draft-richardson-t2trg-idevid-considerations

From: Michael Richardson <[email-masked]>
Date: Thu, 27 Aug 2020 15:07:20 -0400

Sorry for the length of this reply.
I have cut all the editorial comments out, thank you.

Here is the diff:
     https://github.com/mcr/idevid-security-considerations/commit/40c8ab80e38c238c82f94f550c4de021449ba371#diff-07db62839a060a7e40eb3661c3ddeff7

Carsten Bormann <[email-masked]> asked, in the middle of many smaller comments:
    cabo> Is there a difference between validate and verify?

This relates to the text:

}The following uses are specifically called out:
}
}* to validate the signature on a software update (as per {{?I-D.ietf-suit-architecture}}).
}* to verify a TLS Server Certificate, such as when setting up an HTTPS connection.
}* to verify the {{RFC8366}} format voucher that provides proof of an ownership change

I don't know why I have said that I'd validate for software updates, but
verify for other things.  I think maybe just not wanting to repeat the same
words.  I have reworded.

    }            These security artifacts are used to anchor other chains of
    } information: an EAT Claim as to the version of software/firmware
    } running on a device (XXX and [I-D.birkholz-suit-coswid-manifest]), an

    > Do we know what XXX would be?

I don't remember anymore. I will remove it.

    }            each device.  A device may mislead audit systems as to its
    } provenance, about its software load or even about what kind of device
    } it is. (see [RFC7168] for a humourous example).  In order to properly

    > You Canadian?  (humourous) (s/is./is/)

There is no humour without U!
[fixing,  :-(]

    }            To do this, this document details the different trust
    } anchors (TrA) and identities (IDs) found in typical devices.  The
    } privacy and integrity of the TAs and IDs is often provided by a
    } different, superior artifacts.  This relationship is examined.

    > a ... artifacts?

singular.
What I'm trying to get across is that the various anchors are often kept
in a secure container (the artifact), which is controlled by a key strored in a secure
enclave, or equivalent.

    }            The words Trust Anchor are contracted to TrA rather than TA,
    } in order not to confuse with [I-D.ietf-teep-architecture]'s "Trusted
    } Application".

    > "TrAnc" (pronounced like "trance") would be so much nicer :-)

okay.
I suppose a trance state is a good way to change someone's trust anchors.

    >            device-generated : a private or symmetric key which is
    > generated on

    > (we typically don't use spaces in front of colons in Latin-based
    > writing)

That seems to be be doing the markdown wrong.

    }            mechanically-installed : when a key or certificate is
    } programmed into flash by out-of-band mechanism like JTAG

    > ("flash" is less important here than what role that memory plays in
    > what -- it may be OTP after all)

"non-volatile storage" then?

    > JTAG might need a reference -- https://en.wikipedia.org/wiki/JTAG is my
    > suggestion (NOT IEEE 1149.1-2013, as that's behind a (thin) paywall).

I didn't actually follow the link through the paywall.
If you think I can get way with just the wikipedia entry only, I will.

    > (Whatever "physically private" means -- the serial console may be
    > behind a TCP connection...)

Could be firewire, i2c, SPI.  Could be socketed NOR flash...
I don't care if the interfaces within the factory/provisioning facility are
over TCP, as long as they are independantly secure.

    }            network-transfered : when a key or certificate is transfered
    } into a system using a network interface which would be available after
    } the device has shipped.  This applies even if the network is physically
    } attached using a bed-of-nails.

    > What is interesting about a bed-of-nails?  (This seems to be a
    > pars-pro-toto here.)

So, the bed of nails reaches up to connect to the MII side of the PHY, for
instance.  The device is now "plugged in" with a cable that is just more
convenient.  You could plug a real cable in and you might be able to get the
device to do the network-transfer again.

This implies, unless the mechanically-transfered, that some network security is required.
This is not so hard, as the firmware that was loaded can have trust anchors
(public keys) to be used to encrypt traffic to.  This could be as simple as TLS.

    >         2.  Applicability Model

    }            There is a wide variety of devices to which this analysis
    } can apply.  (See [I-D.bormann-lwig-7228bis]) This document will use a
    } J-group

    > period

huh? I don't understand.  Do you want me to end the sentence here?

    >            class C13 as a sample.  This class is sufficiently large to
    > experience complex issues among multiple CPUs, packages and operating
    > systems, but at the same time, small enough that this class is often
    > deployed in single-purpose IoT-like uses.

    >         2.1.  A reference manufacturing/boot process

    }            In order to provide for immutability and privacy of the
    } critical TANs

    > TAN not defined yet -- do you mean TAM?

Oops. TrAnc.  Pluralized to TrAncs seems bizarre.

    }            The entire mechanism may be external to the CPU in the form
    } of a hardware-TPM module, or it may be entirely internal to the CPU in
    } the form of a firmware-TPM.  It may use a custom interface to the rest
    } of the system, or it may implement the TPM 1.2 or TPM 2.0
    } specifications.  Those details are important to performing a full
    } evaluation, but do not matter that to this model (see initial-
    } enclave-location below).

    > that?  (that much?)  s/that/much/?

much, I guess.

    }            During the manufacturing process, once the components have
    } been soldered to the board, the system is usually put through a system-
    } level test.  This is often done on as a "bed-of-nails" test
    } [BedOfNails], where the board has key points attached mechanically to a
    } test system.  A [JTAG] process tests the System Under Test, and then
    } initializes some firmware into the still empty flash storage.  It is
    } now common for a factory test image to be loaded first: this image will
    } include code to initialize the private memory key described above, and
    } will include a first-stage bootloader and some kind of (primitive)
    } Trusted Application Manager (TAM).  Embedded in the stage one
    } bootloader will be a Trust Anchor that is able to verify the
    } second-stage bootloader image.

    > The TAM is on the device here?

Yes, that's correct.
It's a TEEP thing, and it is basically the gatekeeper into a secure-enclave.

    }         3.  Types of Trust Anchors

    }            Trust Anchors are fundamentally public keys.  They are used
    } to

    > (I would argue that they really are pairs of PKs and authorizations; or
    > you can think of them as different "kinds" of TAs, but that is just
    > obscuring the fact that you ascribe some authorization to the kind
    > instead.)

Yes, I agree with you.
I think that part of my goal in this document/process is recognize that the
embedded trust anchor is not useful without an understanding of the
authorization which it is imbued with.
And the human-process authorization which is used to access the corresponding private key(s).

    }            When evaluating the degree of trust for each trust anchor
    } there are four aspects that need to be determined:

    }            * can the trust anchor be replaced or modified?

    > Ah, here you are assuming that the trust anchor comes with implied
    > authorization, so "replacing" the TA means changing the pairing of TAs
    > and authorizations.

Yes.  It's an authorization slot.
The dual (private key) to the thing in this slot is
authorized to do X. X may include delegating (via RFC5280 or other
certificates) that authority to another key Y or Z.

How can I say this better?

    }            * how is the private key associated with the trust anchor
    } stored?

    > Er.  You mean, on the device?  Now I'm confused.

No, in the "factory" or "provisioning facility", or many just manufacturer.

    }            The first three things are device specific properties of how
    } the integrity of the trust anchor is maintained.

    }            The fourth property has nothing to do with the device, but
    } has to do with the reputation and care of the entity that maintains the
    } private key.

    > OK, maybe "stored" is not quite the right word above.

Yes.
Secured?  Kept?  Maintained?

    }         3.3.  Trusted Application Manager anchor

    }           This anchor is part of a [I-D.ietf-teep-architecture]
    } Trusted Application Manager.  Code which is signed by this anchor will
    } be

    > is part of = the SK for the TA is held by (but the device only has a
    > TA, which is a PK)

yes, how can I word this better?

    >            A number of protocols depend upon this certificate.

    >            * [I-D.ietf-anima-bootstrapping-keyinfra] introduces a
    > mechanism for new devices (called pledges) to be onboarded into a
    > network without intervention from an expert operator.  A number of
    > derived protocols such as {{I-D.

    > FIXME

oops. fixed.

    }            This document recommends the use of ECDSA keys for the root
    } and intermediate CAs, but there may be operational reasons why an RSA
    } intermediate CA will be required for some legacy TPM equipment.

    > Well, can a taxonomy recommend?  You could assume a general preference
    > ...

Point.
I want to measure, not recommend.

    >            This transmission must be done in an integral manner, and
    > must be securely associated with the assigned serial number.  The
    > serial number goes into the certificate, and the resulting certificate
    > needs to be loaded into the manufacturer's asset database.  This asset
    > database needs to be shared with the MASA.

    > (Expand once.  Maybe add reference to
    > I-D.richardson-anima-masa-considerations here?)

I think that actually, I will remove that sentence.

    }            Because the key is generated inside the device, it is
    } assumed that the device can never be convinced to disclose the private
    } key.

    > Well, that is not the reason.  Generating inside enables a construction
    > that has that property, but that isn't a given.

point taken.
I have reworded to:

+ Devices are typically constructed in a fashion such that the device is
+ unable to ever disclose the private key via an external interface.
+ This is usually done using a secure-enclave provided by the CPU
+ architecture in combination with on-chip non-volatile memory.

    }            [RFC5280] provides mechanisms to deal with multi-level
    } certification authorities, but it is not always clear what operating
    } rules apply.

    }            PKIs can suffer two kinds of failures: 1. disclosure of a
    } private key. 2. loss of a private key.

    > Er, assignment of a certificate to a CSR from an unauthorized source?
    > Maybe qualify failure -- this is about catastrophic CA failures, no?

The authorization to use the PKI is abused here, but does not really fail.
Perhaps I am mincing words here, but after KomodoGate, the Komodo CA did not
have to be scrapped, and no EE certificates not involved in the attack had to
be replaced.
Yes, if it's your code signing trust anchor, then you probably also have to
recall all the product, but that's a slightly different failure, I think.
I will rewrite.

    >            .-------<-. |Issuer= X | | |Subject=X |-' '-------'

    > Figures are useless.  Did you forget to put them into artwork?

Crap.  I guess I didn't check that! Fixing.

    >            The Trust Anchor signs one or more certificates.  When this
    > first

    > Aargh, again, the TA is the PK, you can only sign with an SK.

+ The private key associated with the Trust Anchor signs one or more certificates.

    }            When this first level authority signs intermediate
    } certification authorities, and those certification authorities sign
    } End-Entity certificates, then this is a level two PKI.

    > Does the higher authority know how many levels the lower one will use?

Sometimes.  In 5280 use, it can restrict the depth with a pathLenConstraint.

    }         5.3.  Supporting provisioned anchors in devices

    }            IDevID-type Identity (or Birth) Certificates which are
    } provisioned into devices need to be signed by a certification authority
    } maintained by the manufacturer.  The manufacturer needs to maintain
    } availability of this PKI.

    > What does "available" mean here?  Explain.

I have expanded this:

+ During the period of manufacture of new product, the manufacturer needs to
+ be be able to sign new Identity Certificates.

+ During the anticipated lifespan of the devices the manufacturer needs to
+ maintain the ability for third parties to validate the Identity
+ Certificates.
+ If there are Certificate Revocation Lists (CRLs) involved, then they will
+ need to resigned during this period.
+ Even for devices with a short active lifetime, the lifespan of the device
+ could very long if devices are kept in a warehouse for many decades before
+ being activated.

    }            This section recaps the set of questions that may need to be
    } answered.  This document does not assign valuation to the answers.

    }         6.1.  Integrity and Privacy of on-device data

    }            initial-enclave-location : Is the location of the initial
    } software trust anchor internal to the CPU package?

    > (term not defined: "initial software trust anchor")

yes, you are right.
It is the "Secured First Boot Trust Anchor", section 3.1.
I've added a definition back there.
Brendan, I think that there is a better term somewhere for this.

    }            initial-enclave-privacy-key : If the first-stage data is
    } external to the CPU, is it encrypted?

    > privacy vs. confidentiality

Changed to:

+initial-enclave-privacy-key:
+: If the first-stage data is external to the CPU, is it kept confidential by use of encryption?

There are other possibilities, I think.
It could just be memory that is attached to the CPU via a private bus.

    }            pki-breadth : how many different EE certificates exist in
    } this PKI

    > Er, that changes over time?  How many ... is the PKI designed to
    > manage?

Consider a software update trust anchor.

Quite reasonably, there could be only one signing key active at a time.
Maybe several are issued at the same time for operational (code released in
different time zones?) or reliability reasons (access to HSM might require a
ceremony, which can only be done twice a year...)

I have added the word "non-expired" to the count above.

    }            pki-anchor-storage: how is the root CA stored?  How many
    } people are needed to recover it?

    > Again, SK or PK?

Yes, SK.

    >         12.1.  Normative References

    > Are any of these "normative"?  What are the interoperability
    > requirements here?

Hmm. Not sure yet.
RFC5280 seems important, but you are right, there is probably nothing normative.

    >            [fidotechnote] FIDO Alliance, ., "FIDO TechNotes: The Truth
    > about Attestation", July 2018, <https://fidoalliance.org/fido-
    > technotes-the-truth-about-attestation/>.

    > Put "FIDO Alliance" in the org, and leave the author otherwise blank.

Oops, many copy and paste errors.

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