Re: [Rats] use case document updates on Roots of Trust

["Smith, Ned" <[e-mail]>]

The term "Trust Anchor" seems to connote a public key, public key certificate or something related primarily to termination of a certificate path validation. https://tools.ietf.org/html/rfc5914. 

The root_of_trust term as used by https://csrc.nist.gov/Projects/Hardware-Roots-of-Trust/publications seems to refer to a computing environment that performs a well-defined security related function. The environment doesn't necessarily need to have a key associated with it - unless its function requires a key or trust anchor. For example: 
	- Attestation requires signing of evidence, hence it requires a key. 
	- Verification of signatures requires a Trust Anchor / public key. 
	- A RATS Verifier produces Attestation Results, hence must have a signing key in addition to Trust Anchor(s). 

The TCG uses the term "roots" of trust because there are several separable functions included in a TPM. It can store measurements and keys hence it is a "storage" RoT. It can sign evidence hence it is a "reporting" RoT - aka attestation RoT. A TPM can also verify signatures hence it is a Verification RoT. 

A RoT is more than just functions. A TPM is a library of security functions that are intended to be implemented in a trustworthy environment. However, there are software TPM libraries that can run in a variety of environments - some of which wouldn't normally be thought of as "trustworthy". 

Glossaries defining root of trust seem to consistently acknowledge the distinguishing factor for root-of-trust as "misbehavior cannot be detected". To protect root-of-trust functions from simple attacks, implementers often harden them by implementing them in immutable hardware. But the property of non-detectable misbehavior existed before the hardening was applied.

RATS Attestation architecture should promote minimizing the surface area of Root-of-Trust functions IMO. Nevertheless, it seems there will always be some function r() for which there is no function f'() that can detect misbehavior. Nevertheless, there may be a function f() where misbehavior can be detected by f'(), but not of r().  Hence, f'(f(r())) means f'() can detect misbehavior of f() but not of r(). Therefore, r() is a root of trust.

Maybe an attestation construction looks something like this:
	 f'''(f''(f'(f(r())))) where a prime (') denotes attestation function(s) that can detect misbehavior of enclosed functions. Since the inner-most functions f() contains r() and where no f'() exists to detect its misbehavior, r() is a root-of-trust. In theory, there could be many layers of functionality that are attestable. For example, the TEEP architecture allows fan-out and nesting of Trusted Agents in the same platform.

That doesn't however mean r() must remain anonymous, r() can be given a name and can be subject to manufacturing process controls. Typically, something like the tuple (mfg, product ID, version, S/N) can be used to manually track r(). But that is the best anyone can do. 

In the case of TPM, the root of trust for reporting a() includes a key called the "endorsement key" that is only used for tracking purposes. Nevertheless, the verifier must trust a() to implement the endorsement key and tracking functionality correctly. Maybe it is circular logic, but a() still fits the definition of a root-of-trust.

Trusted boot is another use case for a root of trust. The idea of trusted boot is there is a function b() that is trusted to load another function b'(). Misbehavior on the part of b() could result in loading a malicious function m() instead of b'(). Before b'() loads, b() measures b'() into a storage root s(). A trusted boot construction might look like this: b(b'(b''(b'''(...)))). Since there is no function x() that loads b(). Therefore, b() is a root-of-trust. 

Note: that if b() doesn't have some function f'() such that f'(b()) exists, then b() cannot be attested - but it is still a root-of-trust. 

The TCG anticipated b() but didn't standardize it. It also assumed there was a trusted function that combined b() with a TPM storage root of trust s(). TCG presumed f(b(), s()) would exist even if they didn't standardize f() and b(). There was no attestation function for f(b(), s()) either, other than using supply chain entity endorsements (e.g. attribute certs) of platform constructions containing f(b(), s()). TCG used attribute certificates to link the TPM endorsement key in a() to other platform components such as b(). E.g.:
	TCG Trusted Platform =  f(b(b'(b''(...))), TPM(s(), a())); if the TPM implements the attestation function f'() for b'(b''(b'''(...))). 
	Then the construction: R = f(b(), TPM(s(), a())) are the roots-of-trust upon which the attestation function in the TPM depends. 
	E.g. f'() =  a(s(b'(b''(b'''(...))))) --> R; where "-->" denotes root-of-trust dependency. 

Another form of root-of-trust is a Verifier. I began this thread talking about trust anchor terminology. A Verifier function v() contains a trust anchor TA that v() uses to terminate cert path validation. Possibly, v() relies on a TA provisioning function p(), such as RFC5934 that helps v() determine which TA to use. In this case, v() contains p() e.g. v(p()); but it may be the case that there is no attestation function for p() such that f'(p()) does not exist. It may also be the case that no f'(v()) exists either. Hence, both v() and p() are roots of trust. 

However, if f'(p()) did exist, and no f'(v()) existed, then v() is still a root-of-trust, but the trusted surface area in v() is minimized by f'(p()). 

Those familiar with TPM, trusted boot and the ecosystem around it, may use the term 'roots of trust' as a way to talk about the above complexity without going into the details as I have done here.

RATS scope is essentially definition of f'() but it should acknowledge roots of trust functions even if we refer to them by some other name.

-Ned

On 9/8/19, 6:22 AM, "RATS on behalf of Michael Richardson" <[e-mail] on behalf of [e-mail]> wrote:

    
    We seem to have regular email disputes on terms like Roots of Trust. 
    I continue to have difficulty with the term. Particularly in the plural
    "Roots" form.
    As I process edits to the use case document, I got a bunch of text:
    
       The TCG Glossary also offers a general definition for Root of Trust “A
       component that performs one or more security-specific functions, such as
       measurement, storage, reporting, verification, and/or update. It is trusted
       always to behave in the expected manner, because its misbehavior cannot be
       detected (such as by measurement) under normal operation. “ 
    
    {I personally find it very difficult to understand the words as other than an
    alias for Trust Anchor, yet it clearly is something else.  It's hard to make
    my neurons pull up a different meaning.  This is probably something that
    every RATS document should say clearly upon first using the term, in order to
    ease the impedence mis-match with IETF readers as we get reviews} 
    
    I have included not just Ned Smith's comments about the term Roots of Trust,
    but his survey of the various origins of the term.  I'm sure that this
    belongs somewhere else.
    
    That diff is here:
      https://ietf.org/rfcdiff?url1=draft-richardson-rats-usecases-04&url2=https://ietf-rats-wg.github.io/ietf-rats-usecases/draft-richardson-rats-usecases.txt
    
    and commit is:
      https://github.com/ietf-rats-wg/ietf-rats-usecases/commit/7386e8c0df11ece66e3c95f85d141a639d440e12
    
    
    -- 
    Michael Richardson <[e-mail]>, Sandelman Software Works
     -= IPv6 IoT consulting =-