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

[Henk Birkholz <[e-mail]>]

Hi Ira & Ned,
hi all,

TL;DR
While I understand the point of the SAE, there a number of good reasons 
not to mimic their decision here, I think.


while I see, acknowledge, and understand (to some extent) the confusion 
about TA & ROT, reiterating and adding to the confusion is a prominent 
reason why people are actually starting to become reluctant to use these 
terms at all. Down to the notion that "includes a root of trust" 
sometimes is already believed to be just a marketing term.

And that is a big problem with direct impact on security considerations 
and threat models.

At least Trust Anchor is well defined in RFC4949 and is also used in 
TEEP (although "TA" means something else there, but TEEP is dealing with 
that successfully) based on the definition in RFC4949.

Now that TEEP and RATS start to align in some capacity, I would strongly 
recommend to simply stick with the established IETF term Trust Anchor 
from RFC4949 and its corresponding use in I-D.ietf-teep-architecture.

Which leaves us with "the other confusing term" that Ned once called 
"the-entity-whose-misbehavior-cannot-be-detected".  The important point 
here is that the output of an Attester in the form of Claims that 
compose Evidence can only go so far while staying believable.  At some 
point you hit rock bottom and you cannot create believable evidence 
anymore, because there are no more turtles that go all the way down.  At 
that point an Attester cannot create believable evidence about its most 
fundamental system components and requires an external Endorsement that 
speaks on behalf of these system components.

And that is the point where Roots of Trust come into play. If you do not 
have them - that is absolutely compliant with RATS. But I'd also like to 
quote Kathleen here:

> Why would I want a device with no root of trust?  Plausible deniability perhaps? Lower cost?
> Why would I want to sell such a device?  I probably wouldn't and this could spur on higher level of assurance and remake of devices without this capability depending on the target market for a device.

And now - comes the the really tricky part: these Endorsements that come 
alongside with Roots of Trusts - those typically have Trust Anchors.

And I think that is one of the major sources of confusion (but maybe it 
is not, due to the fact that I am under the personal believe not to be 
confused here...).

On the one hand, it is okay to not have or use a Root of Trust in any 
way and not to bother with them at all in a solution I-D.

On the other hand, not using an endorsed root of trust always has a 
significant impact on the "level of assurance" (which is called "level 
of confidence" in the architecture at the moment, but that is not 
important now) and thereby on the confidence in the veracity of Claims 
in Evidence.

In summary, there are fundamental factors to take into account, if you 
want to decide whether to talk about the use a RoTs - or not, including:

* market impact,
* effective assurance of protection levels, and
* the inevitable fact that at some point an Attester hits a demarcation 
line beyond which it cannot attest to one of its system components 
anymore - and starts to depend on external endorsements about these 
system components.


Viele Grüße,

Henk

p.s. I really, really hope that I did not add to the confusion!

p.p.s. I'd also like to try to create an EAT flavor now that is an 
"Endorsement EAT" signed by a TA, I think.


On 11.09.19 02:28, Ira McDonald wrote:
> Hi,
> 
> FWIW, the various SAE vehicle security committees commonly use "Trust 
> Anchor"
> (rather than "RoT") to encompass the entire spectrum of RoTs, *as well 
> as* the
> X.509 CA style trust anchor.  There's an entire SAE vehicle security 
> committee
> titled SAE Trust Anchors and Authentication.  In addition, the SAE J3101 
> spec,
> soon to be published, is titled Requirements for Hardware-Protected Security
> for Ground Vehicle Applications and abstracts primitives and functions 
> from any
> of the automotive HSM-like components - it *always* uses the term "Hardware
> Trust Anchor" rather than "Hardware RoT".  It explicitly avoids the 
> anti-definition
> that misbehavior of a "Hardware Trust Anchor" cannot be detected.
> 
> Cheers,
> - Ira
> 
> 
> 
> Ira McDonald (Musician / Software Architect)
> Co-Chair - TCG Trusted Mobility Solutions WG
> Co-Chair - TCG Metadata Access Protocol SG
> Chair - Linux Foundation Open Printing WG
> Secretary - IEEE-ISTO Printer Working Group
> Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG
> IETF Designated Expert - IPP & Printer MIB
> Blue Roof Music / High North Inc
> http://sites.google.com/site/blueroofmusic
> http://sites.google.com/site/highnorthinc
> mailto: [e-mail] <mailto:[e-mail]>
> PO Box 221  Grand Marais, MI 49839  906-494-2434
> 
> 
> 
> On Tue, Sep 10, 2019 at 7:24 PM Smith, Ned <[e-mail] 
> <mailto:[e-mail]>> wrote:
> 
>     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] <mailto:[e-mail]> on behalf of
>     [e-mail] <mailto:[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]
>     <mailto:mcr%2BIETF@sandelman..ca>>, Sandelman Software Works
>           -= IPv6 IoT consulting =-
> 
> 
> 
> 
> 
>     _______________________________________________
>     RATS mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/rats
> 
> 
> _______________________________________________
> RATS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rats
>