Subject: [Suit] Trust Anchor Store definition in arch doc

From: Dave Thaler <[email-masked]>
Date: Mon, 25 Mar 2019 12:24:08 +0000

There’s a discussion on the TEEP WG list, where David Wheeler provided feedback that applies to the SUIT architecture document text.
Forwarding his feedback to SUIT, with his permission.  (Most recent response, with said feedback, at top, with older responses following,
since that’s what github did with them…)

Dave

--------------------- feedback follows -----------------------

From: Dave W <[email-masked]>
To: ietf-teep/architecture <[email-masked]>
Sent: Monday, March 25, 2019 9:34 AM

I agree with the definition as posted, but I believe that there is a requirement missing.

Specifically, a trsut anchor store must resist modification against unauthorized insertion, deletion, and modification. Without such a requirement, a plain-text file on my file system containing X.509 certificates would be a trust anchor store. Any attacker on the platform can add new trusted certificates and remove other trusted certificates. This does not meet the minimal requirements for TEEP, because if any modification is performed to the trust anchor store that can change the management of the TAs.

Perhaps there is an underlying assumption that the trust anchor store is kept within the TEE. But that is not stated in the discussion. However, mandating the store be inside the TEE is restrictive of implementations. In some renditions I am aware of, the trust anchor store is kept by a separate entity outside the TEE, and there is a trusted channel between the TEE and the store.

Therefore, I think the definition @DaveThaler provided needs to be updated to include security requirements on the protection and management of the store.

From: Dave Thaler
Sent: Monday, March 25, 2019 9:12 AM
To: ietf-teep/architecture <reply+0063e94802a8defb98ba[email-masked]>; ietf-teep/architecture <[email-masked]>

Here’s what https://tools.ietf.org/html/draft-ietf-suit-architecture-03 currently says:

   The terms 'trust anchor' and 'trust anchor store' are defined in
   [RFC6024<https://tools.ietf.org/html/rfc6024>]:

   -  "A trust anchor represents an authoritative entity via a public
      key and associated data.  The public key is used to verify digital
      signatures, and the associated data is used to constrain the types
      of information for which the trust anchor is authoritative."

   -  "A trust anchor store is a set of one or more trust anchors stored
      in a device.  A device may have more than one trust anchor store,
      each of which may be used by one or more applications."

As co-chair of both WG’s, I’d suggest that the teep arch doc and the suit arch doc be consistent.

Dave

From: Dave W <[email-masked]<mailto:[email-masked]>>
Sent: Monday, March 25, 2019 8:53 AM
To: ietf-teep/architecture <[email-masked]<mailto:[email-masked]>>

In my view, a Trust Anchor is a

  *   a unique identifier for a trusted entity that is used to select a verification key for that entity
  *   a trust anchor resists replacement, modification or corruption by an adversary

An X.509 certificate by itself does not fulfill the second criteria, as by itself it cannot resist replacement.
Some mechanism to protect the key must be used. A typical example is fuses - a hash of the public exponent and modulus of an RSA key is put in fuses. Then either an X.509 certificate or even just a raw RSA key, can be used as the trust anchor. The fuses are set during manufacturing or some post manufacturing process, by a trusted entity (manufacturer, device admin, device owner, etc.).
The hash of the public key and modulus is typically referred to as a FINGERPRINT.

One recommended approach to a trust anchor list is for the device manufacturer to provision a hash of the RAW RSA key into fuses (it can be any type of key, ECDSA if you prefer, but we will use RSA for the example). The private RSA key is held by the trusted entity. Trusted keys can be issued at any time by the trusted entity by putting the new trusted key into an X.509 certificate and signing that certificate with the Trust Anchor key. The device can check if this new key it receives is trustable, by verifying the certificate is signed by a key whose hash matches the hash in fuses.

We must be clear that there are can many ways to create a Trust Anchor list. X.509 certificates are not required. Fuses are not required. I can use locked Flash blocks. I could also use encrypted battery-backed RAM. I could use separate flash accessible only to a TEE. Many, Many ways are possible.

We must identify ONLY the REQUIREMENTS for the trust anchor, and their usage. Examples are fine to provide, but the requirements are the basis, so we allow different implementations.