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

From: "Smith, Ned" <[email-masked]>
Date: Tue, 2 Apr 2019 17:27:19 +0000

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.e.
(i) TCG.Implicit-Attestation ~= IETF.TEEP.Session-Based-Attestation
(ii) TCG.Explicit-Attestation ~= IETF.TEEP.Static-Attestation

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).
The TUDA draft seems to resemble (i). (Henk can correct me).
The yang draft seems to resemble (ii). (Henk can correct me).

-Ned

On 3/31/19, 12:01 AM, "RATS on behalf of Anders Rundgren" <[email-masked] on behalf of [email-masked]> wrote:

    On 2019-03-30 17:03, Carl Wallace 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)
    
    > 
    > On 3/30/19, 7:04 AM, "Michael Richardson" <[email-masked]> wrote:
    > 
    >>
    >> Carl Wallace <[email-masked]> wrote:
    >>     > Example attestations from Android devices, Yubikey devices and
    >> Surface
    >>     > Pro virtual smart cards can be found here:
    >>     > https://github.com/Purebred/SampleAttestations. These are
    >> accompanied
    >>     > by SCEP requests that include the attestations and the resulting
    >>     > certificates. The attestations were generated and used as part of
    >>     > issuing device and end user certificates where the public key was
    >> the
    >>     > focus of the attestation. The Android and Yubikey attestations take
    >> the
    >>     > form of X.509 certificates (packaged as certs-only SignedData). The
    >>     > Surface Pro attestations take the form of CMC requests.
    >>
    >> I think that seeing the examples is very useful to extract common pieces.
    >> Do you think it's useful to include some in the use case document?
    >>
    >> -- 
    >> Michael Richardson <[email-masked]>, Sandelman Software Works
    >> -= IPv6 IoT consulting =-
    >>
    >>
    >>
    > 
    > 
    > _______________________________________________
    > RATS mailing list
    > [email-masked]
    > https://www.ietf.org/mailman/listinfo/rats
    > 
    
    _______________________________________________
    RATS mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/rats

---

From: Anders Rundgren <[email-masked]>
Date: Wed, 3 Apr 2019 06:37:00 +0200

Hi Ned et al,
I have briefly looked into the referenced documents and my conclusion is that "session-based attestation" probably lacks a clear definition.

What I meant with session-based attestation was that an attestation challenge-response sequence would in addition to exchange of trust information also create a session (in both ends) and associated session-key (typically using a DH scheme) which is subsequently used for executing MAC-protected API calls and finishing with a "commit" call.

For smart card provisioning a device-unique "masterkey" is sometimes used to achieve similar functionality but the trust establishment is implicit [1].

I'm currently not aware of any other system than SKS/KeyGen2 [2] supporting (this definition of) session-based attestation.  The protected API concept was loosely derived from TPM's authorization scheme.

Anders

1] https://naeemgik.blogspot.com/2017/12/globalplatform-secure-channel-protocol.html
2] https://github.com/ietf-teep/architecture/issues/52

---

From: Thomas Fossati <[email-masked]>
Date: Thu, 18 Apr 2019 13:06:40 +0000

Hi Michael,

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

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

---

From: Anders Rundgren <[email-masked]>
Date: Fri, 19 Apr 2019 08:08:10 +0200

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.

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.

Anders