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

[Ira McDonald <[e-mail]>]

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]
PO Box 221  Grand Marais, MI 49839  906-494-2434



On Tue, Sep 10, 2019 at 7:24 PM Smith, Ned <[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] 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 =-
>
>
>
>
>
> _______________________________________________
> RATS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rats
>