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

[Dave Thaler <[e-mail]>]

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 <[e-mail]> On Behalf Of Michael Richardson
Sent: Friday, July 5, 2019 11:39 AM
To: [e-mail]; Anders Rundgren <[e-mail]>
Cc: Carl Wallace <[e-mail]>
Subject: Re: [Rats] More use cases for draft-richardson-rats-usecases-00


    >> > 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 <[e-mail]> 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 <[e-mail]>, Sandelman Software Works  -= IPv6 IoT consulting =-