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

[Henk Birkholz <[e-mail]>]

Thank you Ned for rephrasing my hastily added afterthought. That is 
exactly what I meant.

On 11.09.19 18:41, Smith, Ned wrote:
> Henk commented:
> "    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."
> 
> I assume Henk meant to say that the "Endorsement EAT" is a claim set that is signed by a supply-chain-entity and is trusted by a Verifier because the Verifier maintains the supply-chain-entity's Trust Anchor (TA).
> 
> -Ned
> 
> On 9/11/19, 2:31 AM, "RATS on behalf of Henk Birkholz" <[e-mail] on behalf of [e-mail]> wrote:
> 
>      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
>      >
>      
>      _______________________________________________
>      RATS mailing list
>      [e-mail]
>      https://www.ietf.org/mailman/listinfo/rats
>      
>