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

From: Michael Richardson <[email-masked]>
Date: Fri, 05 Jul 2019 14:39:23 -0400

>> > A session based attestation is the combination of a static attestation
    >> > and the creation of a shared session key.  That is, possible

t
    >> > 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.

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

Anders Rundgren <[email-masked]> wrote:
    > Doesn't TEEP represent yet another attestation concept where each
    > operation is attested?

I certainly what to discuss this more.
My understanding is that TEEP is looking for (and has probably found, via
SUIT) a way for code to admitted into the trusted area from a network source.

While I can imagine that the resulting new code might affect the measurements
that get attested to, I'm not sure they are a use case distinct from
other verified boot use cases.

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

---

From: Michael Richardson <[email-masked]>
Date: Fri, 05 Jul 2019 14:41:24 -0400

Shawn Willden <[email-masked]> wrote:
    mcr> I think that <Android Keystore> is an implementation of the
    mcr> device-type attestation that FIDO cares about.

    > It can serve that purpose, yes.

Are there use cases that Android Keystore provides for that are beyond what
FIDO would ever want to do, but for which you need new claims, or new forms
of claims, or new ways to attest to freshness of claims.

---

From: Michael Richardson <[email-masked]>
Date: Fri, 05 Jul 2019 14:47:14 -0400

Carl Wallace <[email-masked]> wrote:
    >> 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.

    > 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).

You have asked for a specific ability/feature: the ability to encrypt
a claim using trusted code.  I don't know if that's a symmetric or
asymmetric encryption.  I don't know who you need to hide the claim from.  It
seems that it can't be done by an app.

Can you explain this in terms of the problem that you are trying to solve,
or the threat you are trying to mitiate rather than a solution?

When you say challenge password, I think you mean some kind of nonce
a relying party might send to the device in order to maintain freshness.
That also seems like a solution to a problem, the nature of which I'm unclear
about.

---

From: Michael Richardson <[email-masked]>
Date: Fri, 05 Jul 2019 14:53:02 -0400

Anders Rundgren <[email-masked]> wrote:
    > 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

So I think you are saying that you want software running outside of
TEE/RE environment to be able to ask for a key to decrypt an private
(assymetric) key (also stored outside of the TEE).  This software would do
something with the key, and then destroy the key.

Is this a use case where the software needs to make some kind of claim
to the TEE (which is the relying party now), in order to get this access?

I can easily see a situation where there are three trusted modules that
the software interacts with:

1) an attestation service that measures and attests to the integrity of the
   software running... produces a claim (A)

2) the StrongBox that releases the private key-key based upon claim (A) to
   produce some signature X.

3) a trusted module that counter-signs signature X, to say that the
   end-user authorized the transaction via hardware FOO.

---

From: Carl Wallace <[email-masked]>
Date: Fri, 5 Jul 2019 15:19:25 -0400

inline...

> or the threat you are trying to mitiate rather than a solution?
[CW] The problem that motivated the question is establishment of trust in a
public key associated with a specific device (i.e., the device in my hand
not any authentic XYZ device). The suggestion is to use an attestation
encrypted for a given relying party to convey something the relying party
can verify (i.e., a challenge password or TOTP value) along with the key
attestation. This could establish trust more conveniently than more manual
mechanisms like verifying hashes. An app could certainly perform this
function given an attestation but there may be value in performing this
step at a lower level, depending on whether the lower level validated the
key at all (else just doing encryption in the app would be equivalent).

> That also seems like a solution to a problem, the nature of which I'm

[CW] In the solution that motivated the question two TOTP values are used
to establish trust in a device key. The first used to present a fresh key
to a portal, the second used to capture affirmation of a person that the
hash check was performed and the device key is trusted. If the first OTP
was encrypted with an attestation, the second is potentially unnecessary.

---

From: Michael Richardson <[email-masked]>
Date: Fri, 05 Jul 2019 16:35:16 -0400

> key at all (else just doing encryption in the app would be equivalent).

Some other emails and slides went back and forth privately.

Carl is looking at a self-service SCEP situation where a Time-base One-Time
Password (TOTP) is used to validate an enrollment process.

If he were using a strictly online mechanism like EST(RFC7030), then the TOPT
could be used to authenticate the TLS connection (using some EAP method, for
instance).

But, my understanding is that this goal is a mechanism which can operate with
some kind of store and forward situation such that an object-based security
for the PKCS10 CSR.

I'm not convinced this is in scope as a RATS use case.
Please tell me otherwise.

    > was encrypted with an attestation, the second is potentially unnecessary.

So the trusted base of the system would be attesting that the hash check was
displayed to the user?    Maybe I don't understand what is being checked by a
human that could be skipped.

---

From: Carl Wallace <[email-masked]>
Date: Fri, 5 Jul 2019 16:41:50 -0400

inline...

On Fri, Jul 5, 2019 at 4:35 PM Michael Richardson <[email-masked]>
wrote:

> [CW] I hadn't seen encrypted claims discussed so worth a mention.

>     >> That also seems like a solution to a problem, the nature of which
> I'm
>     >> unclear
>     >> about.
>
[CW] The OTP was capturing affirmation of a hash check. The idea here is
attaching it to the attestation in encrypted form could replace that.

---

From: Dave Thaler <[email-masked]>
Date: Sat, 6 Jul 2019 02:19:58 +0000

My comments on draft-richardson-rats-usecases-02 are in the PDF at 
https://www.microsoft.com/en-us/research/uploads/prod/2017/05/draft-richardson-rats-usecases-02.pdf 

In addition, besides the additional references I mentioned in a comment in the PDF, there are additional use
cases that I mentioned in the interim meeting.

Feel free to incorporate this text:

* TEEP: the "Trusted Application Manager (TAM)" server wants to verify the state of a TEE, or applications in the TEE,
   of a device.  The TEE attests to the TAM, which can then decide whether to install sensitive data in the TEE,
   or whether the TEE is out of compliance and the TAM needs to install updated code in the TEE to bring it back
   into compliance with the TAM's policy.

* Confidential ML model: Microsoft talked about this category of use cases at the recent Microsoft //build conference.
   An example use case is where a device manufacturer wants to protect its intellectual property in terms of the
   ML model it developed and that runs in the devices that its customers purchased, and it wants to prevent
   attackers, potentially including the customer themselves, from seeing the details of the model.   This works by having
   some protected environment (e.g., a hardware TEE) in the device attest to some manufacturer's service,
   which if attestation succeeds, then the manufacturer service releases the model, or a key to decrypt the model,
   to the requester.   If a hardware TEE is involved, then this use case overlaps with the TEEP use case.

* Critical infrastructure: when a protocol operation can affect some critical system, the device attached to the critical
   equipment wants some assurance that the requester has not been compromised.  As such, attestation can be used
   to only accept commands from requesters that are within policy.   Hardware attestation in particular, especially
   in conjunction with a TEE on the requester side, can provide protection against many types of malware.

Dave

-----Original Message-----
From: RATS <[email-masked]> On Behalf Of Michael Richardson
Sent: Friday, July 5, 2019 11:39 AM
To: [email-masked]; Anders Rundgren <[email-masked]>
Cc: Carl Wallace <[email-masked]>
Subject: Re: [Rats] More use cases for draft-richardson-rats-usecases-00

t

While I can imagine that the resulting new code might affect the measurements that get attested to, I'm not sure they are a use case distinct from other verified boot use cases.

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

---

From: Michael Richardson <[email-masked]>
Date: Mon, 08 Jul 2019 18:16:23 -0400

> https://www.microsoft.com/en-us/research/uploads/prod/2017/05/draft-richardson-rats-usecases-02.pdf

Dave asked about:

2.1. Static attestations
 A static attestation says something about the platform on which the
 code is running.

saying:
  Commented [DT5]: In what sense is this ‘static’? It can
  be updated at any time, and so can a policy as to whether a
  platform is considered compliant or not.

and I gotta say, I don't know.

I'm sorry about my consistent attestion vs attestation!

    > * TEEP: the "Trusted Application Manager (TAM)" server wants to verify
    > the state of a TEE, or applications in the TEE,

I'll find an appropriate draft to point a reference at on next edit.

    > * Confidential ML model: Microsoft talked about this category of use
    > cases at the recent Microsoft //build conference.

Is a reference to the conference itself the right thing?
How is this different from the media and DRM situation?

    > * Critical infrastructure: when a protocol operation can affect some
    > critical system, the device attached to the critical

This one seems rather abstract to me.

I got another revision posted with your changes:

https://www.ietf.org/rfcdiff?url1=draft-richardson-rats-usecases-03&url2=draft-richardson-rats-usecases-04

I've edited your suggested text slightly, but I didn't think I'd have to
chase the references better.

---

From: Dave Thaler <[email-masked]>
Date: Mon, 8 Jul 2019 23:05:02 +0000

> Is a reference to the conference itself the right thing?

No, you can delete that sentence.  That was just a FYI, doesn't need to be in any doc.

> How is this different from the media and DRM situation?

Yes it's probably similar in many ways.   The players and ecosystem are different,
with different legal protections (or lack thereof) in various jurisdictions though,
so I consider it a different use case.

> This one seems rather abstract to me. 

The others are primarily about access to data, or network access.  This one is about
access to local peripherals.

Dave