Subject: Re: [Rats] More use cases for draft-richardson-rats-usecases-00

From: Michael Richardson <[email-masked]>
Date: Fri, 14 Jun 2019 14:15:52 -0400

Anders Rundgren <[email-masked]> wrote:
    >> Makes sense to me to capture current artifacts. Maybe in an appendix
    >> to the use cases draft.

    > For completeness you should consider mentioning that there are two
    > quite different platform attestation concepts: - Static: FIDO, Android,
    > and current TEEP architecture - Session based: Used by some smart card
    > schemes and SKS/KeyGen2
    > (https://github.com/ietf-teep/architecture/issues/52)

I have added the following text.
I read through the link above, and I found it really interesting, but I
wasn't really sure if I could pin down some clear details about
session attestions.

Are there things that could never be in one category or another?

----

Platform attestions generally come in two categories. This document will
attempt to indicate for a particular attestion technology falls into this.

## Static attestions

A static attestion says something about the platform on which the code is
running.

## Session attestions

A session attestion says something about how the shared session key was
created.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Michael Richardson <[email-masked]>
Date: Fri, 14 Jun 2019 14:46:02 -0400

Smith, Ned <[email-masked]> wrote:
    > Anders refers to session-based attestation in the TEEP archive which
    > points to several sources including a TCG source. This may be referring
    > to a public specification known as DICE - Device Identifier Composition
    > Engine.
    > https://trustedcomputinggroup.org/wp-content/uploads/Hardware-Requirements-for-Device-Identifier-Composition-Engine-r78_For-Publication.pdf

    > TCG terminology for TEEP's "Static" attestation is "Explicit
    > Attestation" and TEEP's term "Session Based" attestation is "Implicit
    > Attestation" by TCG.

I have included these translations into the document.

    > The EAT draft defines an attestation approach that seems close to (i)
    > if you ignore the nonce that is returned as a static claim / assertion
    > and if you rule out of scope the definition of how the signing key is
    > created / persisted.

    > The tokbind draft seems closely resemble (ii).

I want to be sure you mean: draft-mandyam-tokbind-attest-07 ?

    > The TUDA draft seems to
    > resemble (i). (Henk can correct me).

    > The yang draft seems to resemble
    > (ii). (Henk can correct me).

I'm trying to figure out what to do this statement.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Anders Rundgren <[email-masked]>
Date: Fri, 14 Jun 2019 22:46:13 +0200

> wasn't really sure if I could pin down some clear details about

Hi Michael,

A session based attestation is the combination of a static attestation
and the creation of a shared session key.  That is, possible subsequent
operations using the shared session key "inherit" the initial attestation.
Such operations use MAC signatures and symmetric encryption (using keys
derived from the session key) in order to form a protected API.
Ideally a session based attestation scheme also provides "atomic"
operation, terminated by a "commit" call.

> Are there things that could never be in one category or another?

To me they appear pretty distinct, including the code.

Regards,
Anders

> A session attestion says something about how the shared session key was

See text above.

---

From: "Smith, Ned" <[email-masked]>
Date: Mon, 17 Jun 2019 17:07:21 +0000

See inline [nms]

On 6/14/19, 11:46 AM, "Michael Richardson" <[email-masked]> wrote:

    

    
[nms] Yes.

    
    I'm trying to figure out what to do this statement.
[nms] If there is value in categorizing the attestation approach taken by various proposed RATS drafts in terms of (i) implicit attestation and (ii) explicit attestation then it seems TUDA (https://datatracker.ietf.org/doc/draft-birkholz-rats-tuda/ ) may be classified as implicit attestation. Since TUDA is also using time-based exchanges Henk may think it doesn't fit well into this categorization. The YANG module draft https://datatracker.ietf.org/doc/draft-birkholz-rats-basic-yang-module/ appears to me to be a case of explicit attestation.

The basic definition of implicit attestation is that evidence isn't exchanged directly between attester to verifier. Rather only a handle, keyid or use of the attestation key is sufficient to signal the verifier which context to reference for evaluating trust properties. The details of the trust properties is communicated out-of-band (the out-of-band path is out of scope for RATS currently). 

Explicit attestation conveys the evidence directly from attester to verifier. 

Obviously, real world attestation deployments likely will use a hybrid of implicit and explicit attestation approaches.
-Ned

---

From: Michael Richardson <[email-masked]>
Date: Tue, 18 Jun 2019 22:30:27 -0400

Thomas Fossati <[email-masked]> wrote:
    > On 27/03/2019, 18:25, "RATS on behalf of Michael Richardson"
    > <[email-masked] on behalf of [email-masked]> wrote:
    >> (Still looking for some pointers to *attestion* parts of the Android
    >> KeyStore.)

    > Maybe you want to take a look at [1]

    > Cheers, t

    > [1] https://arxiv.org/pdf/1904.05572.pdf

Thank you. It was a really interesting read.
What I learnt is that Android mostly attests to the location of a device
signing key.  I think that this is an implementation of the device-type
attestation that FIDO cares about.

The paper and the referenced info at:
  https://developer.android.com/training/articles/security-key-attestation

does not give me additional use case, but I have other reading that I have
not yet finished.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 18 Jun 2019 22:31:42 -0400

Anders Rundgren <[email-masked]> wrote:
    > Here you have another link:

    > As an application developer I find this scheme and the associated
    > "AndroidKeyStore" quite impractical.  The recent addition of
    > "StrongBox" makes it worse.

Interesting. What is it that you find that you can not do?

    > With a two-level TEE/SE session-key based scheme you only need to
    > attest the session permitting you to perform any number of secure
    > operations and close the session with a "commit" which in turn responds
    > with a (session signed) message to the SP that everything went right.

Or is this what you wish you had?

---

From: Anders Rundgren <[email-masked]>
Date: Wed, 19 Jun 2019 08:02:53 +0200

> Interesting. What is it that you find that you can not do?

A mechanism that only attests keys cannot (securely) be used for provisioning anything but keys.

> Or is this what you wish you had?

In the absence of installable TA support, I have implemented this in Android as a SW emulator [1]. It is a part of the Saturn [3] payment authorization system I'm working on.

As I have tried to describe [2], this concept also relieves you from (IMO) unwanted/unnecessary dependencies on provisioning protocol formats.

Anders
1] https://github.com/cyberphone/webpkisuite-4-android/blob/master/app/src/main/java/org/webpki/mobile/android/sks/AndroidSKSImplementation.java
2] https://github.com/ietf-teep/architecture/issues/52
3] https://cyberphone.github.io/doc/two-visions-4-mobile-payments.pdf

> _______________________________________________
> RATS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rats
>

---

From: Michael Richardson <[email-masked]>
Date: Wed, 19 Jun 2019 12:02:36 -0400

"I am editing the usecase document prior to next Thursday's virtual interim"
This has taken longer than I would have liked, and Thursday is now tomorrow,
and you might want time to read it, so I have mostly failed here.
I am putting out a -02 document anyway.

I realized as I was processing the various comments that I and many others
are perhaps confused about what we need here.  I kept thinking that
this document was going to collect *end user* use cases, and of course some
people were wondering why I was talking about specific verticals.

Let me propose the following text:

+This document exists as place to collect use cases for the common RATS
+technologies in support of the IETF RATS charter point 1.  This document is
+not expected to be published as an RFC, but remain open as a working
+document.  It could become an appendix to provide motivation for a protocol
+standards document.
+
+This document will probably not deal with use cases from an end-user
+point of
+view, but rather on the technology verticals that wish to use RATS concepts
+(such as EAT) in their deployments.
+
+End-user use cases that would either directly leverage RATS technology, or
+would serve to inform technology choices are welcome, however.

I would be very happy if it turned out that we only discussed this point at
the virtual interim!   That we wind up with a strong consensus.

====

---

From: Michael Richardson <[email-masked]>
Date: Wed, 19 Jun 2019 15:45:04 -0400

> operations using the shared session key "inherit" the initial
    > attestation.  Such operations use MAC signatures and symmetric
    > encryption (using keys derived from the session key) in order to form a
    > protected API.  Ideally a session based attestation scheme also
    > provides "atomic" operation, terminated by a "commit" call.

I understand.  I'm not sure what to change, if anything, based upon your
comments.

---

From: Michael Richardson <[email-masked]>
Date: Wed, 19 Jun 2019 15:47:24 -0400

Smith, Ned <[email-masked]> wrote:
    >> The TUDA draft seems to resemble (i). (Henk can correct me).

    >> The yang draft seems to resemble (ii). (Henk can correct me).

    mcr>     I'm trying to figure out what to do this statement.

    nms> If there is value in categorizing the attestation approach taken by
    nms> various proposed RATS drafts in terms of (i) implicit attestation
    nms> and (ii) explicit attestation then it seems TUDA
    nms> (https://datatracker.ietf.org/doc/draft-birkholz-rats-tuda/ ) may be
    nms> classified as implicit attestation. Since TUDA is also using
    nms> time-based exchanges Henk may think it doesn't fit well into this
    nms> categorization. The YANG module draft
    nms> https://datatracker.ietf.org/doc/draft-birkholz-rats-basic-yang-module/
    nms> appears to me to be a case of explicit attestation.

okay, but this is an analysis what the implementations/protocols provide,
whereas the usecase document is trying to categorize what the users need :-)

I'm violently agreeing that the terms are useful, but I don't think they
belong here.

---

From: "Smith, Ned" <[email-masked]>
Date: Wed, 19 Jun 2019 20:34:09 +0000

The use case context for implicit attestation is that for example, the protocol between attester and verifier doesn't allow explicit inclusion of attestatation evidence but the verifier requires the attester to meet various trustworthiness criteria. Use of the attestation key provides the verifier with enough context to locate attestation evidence that was conveyed out-of-band (by some other path). For example, it could be supplied in a certificate for the signing key.
-Ned

On 6/19/19, 12:47 PM, "RATS on behalf of Michael Richardson" <[email-masked] on behalf of [email-masked]> wrote:

---

From: Anders Rundgren <[email-masked]>
Date: Thu, 20 Jun 2019 07:28:06 +0200

> I understand.  I'm not sure what to change, if anything, based upon your

Doesn't TEEP represent yet another attestation concept where each operation
is attested?

To me it looks that most if not all attestation schemes provide platform-related
data but they also combine that with application-specific data like keys in Android,
arbitrary operations like in TEEP, or the creation of a shared session key
like in SKS/KeyGen2.  I would consider splitting these topics since they appear
to be fairly independent.

Anders

---

From: Shawn Willden <[email-masked]>
Date: Thu, 20 Jun 2019 14:52:42 +0200

On Wed, Jun 19, 2019 at 4:30 AM Michael Richardson <[email-masked]>
wrote:

> signing key.

This is correct.  Originally, keystore attestation was intended *only* to
prove that a key (a) lived in a thought-to-be-secure environment and (b)
that the key had a certain set of properties.  The scope has expanded a bit
to also attest to some bits of information about the device state, at least
as it was at boot time.

> I think that this is an implementation of the device-type attestation that
> FIDO cares about.
>

It can serve that purpose, yes.

>   ]The paper and the referenced info at:

-- 
Shawn Willden | Staff Software Engineer | [email-masked] | 720-924-6645

---

From: Shawn Willden <[email-masked]>
Date: Thu, 20 Jun 2019 15:16:48 +0200

> provisioning anything but keys.

What else do you wish to provision? Anything other than TAs (addressed
below)?  And how does the addition of StrongBox make keystore worse?

> In the absence of installable TA support, I have implemented this in
> Android as a SW emulator [1]. It is a part of the Saturn [3] payment
> authorization system I'm working on.
>

The Android platform security team considers this an anti-goal.  We're very
concerned that the scope of functionality being installed in TEEs is
exploding to a degree that the TEEs are becoming less trustworthy, not more
(and they haven't been particularly good).  Not only do we not want to
enable field-installation of TAs, we'd like to constrain factory/OTA
installation to smaller sets (some devices ship with upwards of 40 TAs
today), though our ability to do that is very limited.

There's a tension here between enabling more use cases and maintaining /
increasing the security of existing use cases. We recognize that GP and
many others disagree with us on how to balance the issues, and that perhaps
we're wrong, but we have to respond to the Android ecosystem as we see it.

> As I have tried to describe [2], this concept also relieves you from (IMO)
> unwanted/unnecessary dependencies on provisioning protocol formats.

> Anders
> 1]
> https://github.com/cyberphone/webpkisuite-4-android/blob/master/app/src/main/java/org/webpki/mobile/android/sks/AndroidSKSImplementation.java

---

From: Carl Wallace <[email-masked]>
Date: Thu, 20 Jun 2019 09:31:40 -0400

>> <snip>
> concerned that the scope of functionality being installed in TEEs is exploding
> to a degree that the TEEs are becoming less trustworthy, not more (and they
> haven't been particularly good).  Not only do we not want to enable
> field-installation of TAs, we'd like to constrain factory/OTA installation to
> smaller sets (some devices ship with upwards of 40 TAs today), though our
> ability to do that is very limited.

+1
> increasing the security of existing use cases. We recognize that GP and many
> others disagree with us on how to balance the issues, and that perhaps we're
> wrong, but we have to respond to the Android ecosystem as we see it.

Re: more use cases, the ability to encrypt a key attestation in TEE/SE for a
specific provisioning end point would be nice to have (to conceal a
challenge password while in transit, for example).

---

From: Anders Rundgren <[email-masked]>
Date: Thu, 20 Jun 2019 17:15:15 +0200

On 2019-06-20 15:16, Shawn Willden wrote:
> On Wed, Jun 19, 2019 at 8:03 AM Anders Rundgren <[email-masked] <mailto:[email-masked]>> wrote:
> 
>      > Anders Rundgren <[email-masked] <mailto:[email-masked]>> wrote:
>      >      > Here you have another link:
>      >      > https://developer.android.com/training/articles/security-key-attestation
>      >
>      >      > As an application developer I find this scheme and the associated
>      >      > "AndroidKeyStore" quite impractical.  The recent addition of
>      >      > "StrongBox" makes it worse.
>      >
> What else do you wish to provision? Anything other than TAs (addressed below)?

Most of all I wanted to provision "stuff" in an *atomic fashion* which was the initial motive for the session based attestation scheme.
In my particular case "stuff" also includes various key meta data like payment credential images.

And how does the addition of StrongBox make keystore worse?

I don't have much data on StrongBox so maybe I was out of line there, but the idea I had was that keys would not be stored in secure silicon, but rather encrypted in the TEE or RE environment.  In that case StrongBox would be a crypto processor with embedded keys which also would be used for provisioning/attestation:
https://github.com/ietf-teep/architecture/issues/52#issuecomment-486929941

Anders

> 
>      >      > With a two-level TEE/SE session-key based scheme you only need to
>      >      > attest the session permitting you to perform any number of secure
>      >      > operations and close the session with a "commit" which in turn responds
>      >      > with a (session signed) message to the SP that everything went right.
>      >
> The Android platform security team considers this an anti-goal.  We're very concerned that the scope of functionality being installed in TEEs is exploding to a degree that the TEEs are becoming less trustworthy, not more (and they haven't been particularly good).  Not only do we not want to enable field-installation of TAs, we'd like to constrain factory/OTA installation to smaller sets (some devices ship with upwards of 40 TAs today), though our ability to do that is very limited.
> 
> There's a tension here between enabling more use cases and maintaining / increasing the security of existing use cases. We recognize that GP and many others disagree with us on how to balance the issues, and that perhaps we're wrong, but we have to respond to the Android ecosystem as we see it.
> 
> Shawn Willden | Staff Software Engineer [email-masked] <mailto:[email-masked]> | 720-924-6645

---

From: Laurence Lundblade <[email-masked]>
Date: Thu, 20 Jun 2019 10:25:15 -0700

> On Jun 20, 2019, at 5:52 AM, Shawn Willden <[email-masked]> wrote:
> 
> This is correct.  Originally, keystore attestation was intended *only* to prove that a key (a) lived in a thought-to-be-secure environment and (b) that the key had a certain set of properties.  The scope has expanded a bit to also attest to some bits of information about the device state, at least as it was at boot time.

A few other things that seem useful and may be implemented in some cases:
That the key use is gated by user verification like a fingerprint match. This is immensely valuable IMO.
That there are timer throttles that govern the rate of key use.
Knowing which application (e.g. Android app) requested the attestation.
Allowing the application to include custom data in the attestation (it must be marked as as less secure than other data in the attestation). 
Inventory of some or or all of the SW on the device.

A lot of these are useful as risk signals or cross-checks for payments and such.

LL