Subject: Re: [Rats] Composite Evidence

From: "Smith, Ned" <[email-masked]>
Date: Thu, 23 Jan 2020 19:04:07 +0000

Eric,
Can you say more about relayed evidence in terms of how it was obtained and how it is protected as it is ‘relayed’?

The Passport and Background Check models incorporate ‘relaying’ of Evidence, but don’t try to describe the Evidence as ‘relayed evidence’.

In the context of Attesting Environment Collecting Evidence from a Target environment the way it is collected seems to determine whether it would be classified as (i), (ii) or (iii). (Note: there is the category of simple evidence that is just a set of atomic claims – no need to drill deeper into the foo[] data structure – and not represented by (i), (ii) or (iii))

If (i) means the target environment consists of a decomposition of things, then there is expected to be a nesting of Evidence that parallels the decomposition.
If (i) also means the target environment consists of a decomposition of things and where there is a ‘local verifier’ that evaluates Evidence and produces an Attestation Result in the place where the decomposition would otherwise expect nested Evidence then this seems to overload (i) somewhat.

However, it could be that one of these is what you mean by (iii)?

-Ned

From: RATS <[email-masked]> on behalf of "Eric Voit (evoit)" <[email-masked]>
Date: Thursday, January 23, 2020 at 7:40 AM
To: Dave Thaler <[email-masked]>, "Smith, Ned" <[email-masked]>, Henk Berkholz <[email-masked]>, Michael Richardson <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [Rats] Composite Evidence

Hi Ned,
Hi Dave,

I agree with Ned's framing of (i) and (ii).  These two are embedded in my passport example below.    We also have (iii): evidence which is relayed from outside the Attester.  I think (iii) needs to be broken out as an evidence type because signed information from the Verifier should be trusted differently from other evidence the Attester.

That makes:
 (i) component evidence
(ii) time-series evidence
(iii) relayed evidence

Beyond (i), (ii), & (iii), do we need term combinations of (i), (ii), & (iii) with the word "composite"?  Hopefully we wouldn't need to define six terms for each combination of these three variants.  Otherwise my example might be called "component, time-series, relayed composite evidence".  And that is a mouthful.

Eric

From: Dave Thaler, January 22, 2020 9:05 PM

Agree with Ned that we should keep composite devices separate from time series snapshots of the same component in terms of concepts.

From: Smith, Ned <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, January 22, 2020 5:54 PM
To: Eric Voit (evoit) <[email-masked]<mailto:[email-masked]>>; Birkholz, Henk <[email-masked]<mailto:[email-masked]>>; Michael Richardson <[email-masked]<mailto:[email-masked]>>; Dave Thaler <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: Composite Evidence

Eric,
I think there are two types of “composite” things that could be considered (i) decompositions of hardware and software such as a motherboard and the sub-components that could be plugged into it and (ii) time series snapshots of the same component.

You seem to be asserting (ii) where a time series snapshot of the same thing could be considered “composite evidence”.

I think both cases are valid, but maybe it makes sense to use different terms for each as they seem to have distinct properties. (e.g. evidence having multiple entries of a component with the same name  under (i) implies multiple instances of the same type of device – such as two NIC cards. Whereas under (ii) multiple entries implies there is one instance of the NIC sampled over a time interval.

-Ned

From: "Eric Voit (evoit)" <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, January 22, 2020 at 4:04 PM
To: Henk Berkholz <[email-masked]<mailto:[email-masked]>>, Michael Richardson <[email-masked]<mailto:[email-masked]>>, Dave Thaler <[email-masked]<mailto:[email-masked]>>, "Smith, Ned" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Composite Evidence

Henk,         Dave,
Michael,    Ned,

I promised you a definition for Composite Evidence.  You can see my proposed definition directly the text below, but I am not willing yet to place it in a Pull Request. I thought an email thread might be helpful first.

Anyway my strawman definition for Composite Evidence is:  Evidence which includes multiple sub-elements of evidence, more than one of which can be computationally verified to have been generated by a specific Attester Subcomponent or Verifier.

I built this definition considering the passport model, which looks like it will often needs to use composite evidence.  As an example of why I believe this, see the use case below.

    ..--------------.
    |  Verifier A  |
    '--------------'
        ^     [2]
        |     Verifier A signed Attestation Results @time(x) (
    evidence(  |  determination, hash(TpmQuote@time(x)))
    TpmQuote   |
    @time(x))  |
       [1]     V
     .-------------.                           .---------------.
     |  Attester   |<------nonce @time(y)---[3]|  Verifier B   |
     |    ..-----.  |                           |       /       |
     |    | Tpm |  |[4]-composite evidence ( ->| Relying Party |
     |    '-----'  |      TpmQuote@time(y),    '---------------'
     '-------------'      TpmQuote@time(x),
                          Verifier A signed Attestation Results @time(x) )

In the example above, evidence at time x is generated and signed within a TPM.  This would *not* be composite evidence.   This evidence would be evaluated by Verifier A, signed, and returned as Attestation Results to the Attester.   A subsequent request from a Relying Party at time y could pull three independently signed elements of evidence from the Attester.  These three would comprise the composite evidence which when taken together would allow Verifier B / Relying Party to evaluate the current trustworthiness of the Attester.

Does this definition meet your needs?

Thanks,
Eric

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Thu, 23 Jan 2020 20:56:58 +0000

Hi Ned,

From: Smith, Ned, January 23, 2020 2:04 PM

Eric,

<eric> While it isn't 100% clear in the current terminology, I see "Attestation Results"  as a special type of evidence. This is evidence where any trustworthiness claims made of the Attester can be accepted without requiring further evaluation.

The Relying Party needs a way to validate the freshness of whatever comes from the Verifier.   This can be done a number of ways.   For example in my diagram below, the TPM2's timeticks counters can be included in [1] and [4].  As the TPM has predictable incrementing of these counters.  The deltas between the timeticks counters can be trusted, even though both claims were generated from within an Attester Component.

A related question then is whether the Attestation Results in [2] actually match to the TpmQuote from [1].  The Relying party can establish this based on a hash within [2] proving its relation to [1].

In the context of Attesting Environment Collecting Evidence from a Target environment the way it is collected seems to determine whether it would be classified as (i), (ii) or (iii). (Note: there is the category of simple evidence that is just a set of atomic claims – no need to drill deeper into the foo[] data structure – and not represented by (i), (ii) or (iii)

<eric> I agree with other type of evidence/claims relating to the attester in general, and these not needing to be provably associated with any specific sub-component.    This is one of the reasons I am hoping we turn this discussion towards a decomposed set of evidence types, rather than having individual terms for different combinations of composite evidence.

) 

<eric> Nesting is certainly possible. So I am fine with this statement.  To match this to my example below, step [4] assembles a composition of this evidence, rather than doing any nesting.  Although perhaps nesting *could* be claimed the Attestation Results in [2] contains a hash of [1].  Is this nesting?  Is this Layering?  I don't know.

<eric> This is the exact reason why I got caught up attempting a definition of "Layering".  I am not sure what constraints can a 'local verifier' trustworthy, nor when a 'networked verifier' can provide validation into a TCG DICE type Layer.  These are not questions I have looked at closely.   

<eric> This is one type of thing covered in (iii).  The generalization of what I intended from (iii) was evidence provided by an Attester which is provably not generated within the Attester.  For example, a recent Time quote from a Time Stamp Authority like in draft-birkholz-rats-tuda could also be included in what is sent to a Verifier/Relying Party.

Eric

-Ned

From: RATS <[email-masked] <mailto:[email-masked]> > on behalf of "Eric Voit (evoit)" <[email-masked] <mailto:[email-masked]> >
Date: Thursday, January 23, 2020 at 7:40 AM
To: Dave Thaler <[email-masked] <mailto:[email-masked]> >, "Smith, Ned" <[email-masked] <mailto:[email-masked]> >, Henk Berkholz <[email-masked] <mailto:[email-masked]> >, Michael Richardson <[email-masked] <mailto:[email-masked]> >
Cc: "[email-masked] <mailto:[email-masked]> " <[email-masked] <mailto:[email-masked]> >
Subject: Re: [Rats] Composite Evidence

Hi Ned,

Hi Dave,

That makes:

 (i) component evidence

(iii) relayed evidence

Eric

From: Smith, Ned < <mailto:[email-masked]> [email-masked]> 
Sent: Wednesday, January 22, 2020 5:54 PM
To: Eric Voit (evoit) < <mailto:[email-masked]> [email-masked]>; Birkholz, Henk < <mailto:[email-masked]> [email-masked]>; Michael Richardson < <mailto:[email-masked]> [email-masked]>; Dave Thaler < <mailto:[email-masked]> [email-masked]>
Cc:  <mailto:[email-masked]> [email-masked]
Subject: Re: Composite Evidence

Eric,

-Ned

From: "Eric Voit (evoit)" <[email-masked] <mailto:[email-masked]> >
Date: Wednesday, January 22, 2020 at 4:04 PM
To: Henk Berkholz <[email-masked] <mailto:[email-masked]> >, Michael Richardson <[email-masked] <mailto:[email-masked]> >, Dave Thaler <[email-masked] <mailto:[email-masked]> >, "Smith, Ned" <[email-masked] <mailto:[email-masked]> >
Cc: "[email-masked] <mailto:[email-masked]> " <[email-masked] <mailto:[email-masked]> >
Subject: Composite Evidence

Henk,         Dave,

Michael,    Ned,

    .--------------.             

    |  Verifier A  |

    '--------------'     

        ^     [2]           

    TpmQuote   |                  

    @time(x))  |                        

       [1]     V                        

     |    .-----.  |                           |       /       |

 

Thanks,

Eric

---

From: "Smith, Ned" <[email-masked]>
Date: Thu, 23 Jan 2020 23:25:32 +0000

Eric said “However, it could be that one of these is what you mean by (iii)?
<eric> This is one type of thing covered in (iii).  The generalization of what I intended from (iii) was evidence provided by an Attester which is provably not generated within the Attester.  For example, a recent Time quote from a Time Stamp Authority like in draft-birkholz-rats-tuda could also be included in what is sent to a Verifier/Relying Party.”
[nms] The Time Stamp Authority is an Attester (A1) that claims the time is some value E1. When THE Attester (A2), receives E1. What does he do with it? Does he forward it (see my reply to Michael’s thread) or does he use it to create Evidence E2? I think you’re suggesting it’s the latter. In this case, the evidence consists of a claim that expects the time. E.g. Claim c1 in E2 looks like: c1.name = “name of something”, c1.timestamp = E1.time, c1.xyz = …

The question to ask is whether or not provenance of E1.time needs to be communicated to Verifier. Maybe A2 just needs to prove that it uses a secure time source and that’s it? If you’re saying Verifier needs to know which time source it used, then it becomes a question of defining the claim c1 in such a way that it includes E1 (or points to it somehow) – BTW I’m assuming E1 is signed by A1 so it has provenance.

This seems like an interesting possibility / use case.

-Ned

From: "Eric Voit (evoit)" <[email-masked]>
Date: Thursday, January 23, 2020 at 12:57 PM
To: "Smith, Ned" <[email-masked]>, Dave Thaler <[email-masked]>, Henk Berkholz <[email-masked]>, Michael Richardson <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: RE: [Rats] Composite Evidence

Hi Ned,

Eric

-Ned

From: RATS <[email-masked]<mailto:[email-masked]>> on behalf of "Eric Voit (evoit)" <[email-masked]<mailto:[email-masked]>>
Date: Thursday, January 23, 2020 at 7:40 AM
To: Dave Thaler <[email-masked]<mailto:[email-masked]>>, "Smith, Ned" <[email-masked]<mailto:[email-masked]>>, Henk Berkholz <[email-masked]<mailto:[email-masked]>>, Michael Richardson <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Rats] Composite Evidence

Hi Ned,
Hi Dave,

That makes:
 (i) component evidence

Eric

Eric,

-Ned

Henk,         Dave,
Michael,    Ned,

    .--------------.
    |  Verifier A  |
    '--------------'
        ^     [2]

Thanks,
Eric

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Fri, 24 Jan 2020 00:02:17 +0000

Hi Ned,

From: Smith, Ned, January 23, 2020 6:26 PM

<eric2> Interpreting TUDA (draft-birkholz-tuda) on behalf of Henk...  

*	The Sync token of TUDA's Figure 1 (let's call it E3) is created by signing across E1 plus E2 (a local TPM quote) to create E3.  
*	E1, E2, and E3 all must be analyzed by A2 to determine the validity of the sync token.

<eric2> E1 signed by A1 is an assumption of TUDA.  You need to know the Public Key of the TSA in order to understand (at minimum) a base timeticks or timestamp of the TSA.  (Actually it is a little more complicated than that, the Attester signs Quotes to the TSA, which is then signed and timestamped by the TSA.)   In any case, the answer to your question is that C1 will sometimes need to include E1 from a known, verifiable external source.

Eric

-Ned

To: "Smith, Ned" <[email-masked] <mailto:[email-masked]> >, Dave Thaler <[email-masked] <mailto:[email-masked]> >, Henk Berkholz <[email-masked] <mailto:[email-masked]> >, Michael Richardson <[email-masked] <mailto:[email-masked]> >

Hi Ned,

Eric,

) 

Eric

-Ned

Hi Ned,

Hi Dave,

That makes:

 (i) component evidence

(iii) relayed evidence

Eric

Eric,

-Ned

Henk,         Dave,

Michael,    Ned,

    .--------------.             

    |  Verifier A  |

    '--------------'     

        ^     [2]           

    TpmQuote   |                  

    @time(x))  |                        

       [1]     V                        

     |    .-----.  |                           |       /       |

 

Thanks,

Eric

---

From: "Smith, Ned" <[email-masked]>
Date: Fri, 24 Jan 2020 01:12:02 +0000

Date: Thursday, January 23, 2020 at 4:02 PM

Hi Ned,

<eric2> E1 signed by A1 is an assumption of TUDA.  You need to know the Public Key of the TSA in order to understand (at minimum) a base timeticks or timestamp of the TSA.  (Actually it is a little more complicated than that, the Attester signs Quotes to the TSA, which is then signed and timestamped by the TSA.)   In any case, the answer to your question is that C1 will sometimes need to include E1 from a known, verifiable external source.
[nms2] I assume you meant ‘c1’ – lower case?

Eric

-Ned

To: "Smith, Ned" <[email-masked]<mailto:[email-masked]>>, Dave Thaler <[email-masked]<mailto:[email-masked]>>, Henk Berkholz <[email-masked]<mailto:[email-masked]>>, Michael Richardson <[email-masked]<mailto:[email-masked]>>

Hi Ned,

Eric

-Ned

Hi Ned,
Hi Dave,

That makes:
 (i) component evidence

Eric

Eric,

-Ned

Henk,         Dave,
Michael,    Ned,

    .--------------.
    |  Verifier A  |
    '--------------'
        ^     [2]

Thanks,
Eric