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

[Ira McDonald <[e-mail]>]

Hi,

SP800-164 contains this rather informative definition for RoTs:

Roots of Trust (RoTs). RoTs are security primitives composed of hardware,
firmware and/or software that provide a set of trusted, security-critical
functions. They must always behave in an expected manner because their
misbehavior cannot be detected. As such, RoTs need to be secured by their
design. Hardware RoTs are preferred over software RoTs due to their
immutability, smaller attack surface, and more reliable behavior.

Notice that both hardware and software RoTs are addressed, with a rationale
for the preference for hardware RoTs.

If the term RoT continues to cause heartburn in RATS, then we might just use
the generic "Trust Anchor" which is widely used to encompass both hardware
and software RoTs in a number of SDOs.

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 Mon, Sep 9, 2019 at 7:20 PM Ira McDonald <[e-mail]> wrote:

> Hi,
>
> Chiming in here.
>
> The TCG is neither the originator of the term "Root of Trust", nor a
> particularly good source for RoT definitions.
>
> One might look at this US NIST project on Roots of Trust:
>
> https://csrc.nist.gov/Projects/Hardware-Roots-of-Trust/publications
>
> And especially this SP800-164 document:
>
> https://csrc.nist.gov/publications/detail/sp/800-164/draft
>
> 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 Mon, Sep 9, 2019 at 6:49 PM Henk Birkholz <
> [e-mail]> wrote:
>
>> Hi all,
>>
>> wrt the topic of "roots of trust", on the list a very visible concern
>> was highlighted: "the definition [of RoT] defines what they are -not-
>> and not what it actually -are-". And I am inclined to agree with that.
>>
>> My initial and unpolished proposal is this:
>>
>> "If" we use the spectrum of meanings what "roots of trust" are in RATS,
>> we probably have to do two things:
>>
>> 1.) We maybe should highlight that "Roots of Trust" are a demarcation
>> line. There are system components or system components characteristics
>> (aka "Claims" that are composed into "Evidence" about "Trustworthiness")
>> that an Attester cannot create Evidence about only by itself. It is the
>> "rock bottom" that an Attester cannot attest to (because, quoting:
>> "their misbehavior cannot be detected"). While that being very true, it
>> seems not to be enough of a reason to just exclude them conceptually.
>>
>> Hence, the only established procedure to "deal" with these roots of
>> trust is a third's party endorsement. The consumer of attestation
>> results is at its own liberty to put trust into these third party's
>> endorsements - or not.
>>
>> It is an optional Claim Set, typically provided in the form of
>> Endorsement Certificates (but there surely are other ways). And these
>> methods might simply not be available to an Attester. And if that i that
>> case that MUST not be a blocker, especially wrt to the RATS architecture.
>>
>> I.e. in RATS these Claims about RoT (Endorsements) should be purely
>> optional. The architecture should allow to include them. But by any
>> means, there should not be prescriptive or a normative MUSTs to provide
>> them.
>>
>> If an Attester is able to provide or refer to such an endorsements of a
>> system components capabilities, it should be able to do so. If an
>> Attester is not able to provide such third party endorsements, that
>> should not be a blocker to conducts RATS. The benefit of having the
>> option to provide them is to fuel a framework about "levels of
>> confidence" that most likely is out of scope of IETF definitions, but
>> would enable other entities to fill that gap in.
>>
>> 2.) I am proposing that the RATS WG puts some effort in defining what
>> "roots of trust" actually do (and not only what they cannot do). That
>> would help to create an understanding what they actually mean - a lot.
>> And - I think that is important - that might not have to be part of the
>> architecture document. Maybe it is an Appendix of it, maybe it is an
>> informational draft that complements the architecture document, or this
>> content goes alongside with solutions drafts. We don't know yet, I think.
>>
>> TL;DR
>>
>> Roots of Trust are relevant. But their upcoming definition and use
>> should not stop us from progressing essential corner stone drafts, today.
>>
>> My understanding is that some use cases really require them, and other
>> use cases don't. Neither am I inclined to include them in the
>> architecture draft and over-complicate elegant solutions, such as EAT,
>> nor am I inclined to exclude them and thereby inhibit established
>> solution, such as RIV.
>>
>> There is some middle ground here, I think. My proposal is to neither
>> disregard the system components an Attester is not able to create
>> Evidence for by itself, nor to mandate that an Attester can only create
>> believable Evidence, if RoT are available. Both options should be
>> enabled by the RATS architecture, I think.
>>
>> Viele Grüße,
>>
>> Henk
>>
>>
>> On 09.09.19 22:56, Laurence Lundblade wrote:
>> > Appreciate you wading into this with something written and concrete.
>> >
>> > As a thought experiment consider adding this to our RATS definition:
>> >
>> >     A root of trust may also be a simple unsecured user mode
>> >     application, like an Android, Windows or Linux application that
>> >     trust has been placed in by a particular attestation system. It is
>> >     provisioned with a signing key or such and other capabilities so as
>> >     to be able to produce attestation evidence (e.g. signed tokens).
>> >       The application may or may not be signed or authenticated.
>> >
>> >     In a sense, the usual definition of root of trust applies in that it
>> >     is something that is unconditionally trusted. In another sense, this
>> >     is at odds with the usual conception as it is not anchored in HW or
>> >     to any kind of system or boot SW.
>> >
>> > I assuming this addition is too much at odds with the convention usage
>> > and there is no support for RATS adopting this definition. This is one
>> > of the main reasons I am asking we not use the term normatively.
>> >
>> > LL
>> >
>> >
>> >> On Sep 8, 2019, at 6:23 AM, Michael Richardson <[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:[e-mail]>>, 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
>>
>