Subject: [Rats] Android comments on EAT draft

From: Shawn Willden <[email-masked]>
Date: Wed, 15 May 2019 20:43:47 -0400

Hi all.

After being invited by Laurence to join this WG some time ago, I have
completely dropped the ball. I apologize for that; in the interim period I
have expanded my team from one engineer (me) to six, and we all still have
more to do than we can accomplish, which gives a good indication of how
much I was dropping on the floor.  I think I have now delegated enough that
I can begin to put some time into this.

After reviewing the draft (which I like a lot, in many ways), I notice a
crucial divergence of focus between EAT and Android Keystore Attestation.
Perhaps this means that EAT is not applicable for Android; but I'd like to
explore the question a bit.

Specifically, EAT is about attesting to a *device* while Keystore
Attestation is about attesting to a *key* -- though we also attest to quite
a bit about the context of the key, i.e. the device. Indeed, the device
information we provide is growing with every release, because there's a
strong pent-up demand for device attestation.  So Keystore Attestation is
gradually expanding to include the device attestation role, but must also
retain its key attestation purpose.  For EAT to be directly applicable, it
would have to include claims about a key as well.

Perhaps another option is that we could use an EAT attestation as a
sub-element inside a CBOR structure that attests to a key.  Or maybe there
are other ideas about how an EAT attestation may fit into a larger
attestation that describes characteristics of entities other than the
containing device?

Another, more tractable, area of difference is that EAT provides Claims for
several data items which Android will likely never allow to be attested
because of their privacy implications and potential for ecosystem
fragmentation (apps choosing which devices they'll run on -- we generally
try to deny them the information they'd like to have to make those
choices).  These are:

   - UEID
   - Origination
   - Location

We do allow OEM Identification, though it's a different format and is
restricted.

Some other claims that we have, and think are important, are OS version and
patch-level (represented as a date, YYYYMMDD); secure boot verification key
digest; secure boot digest (hash of all verified code); application ID (a
digest of the requesting app signing key); and secure app version (hmm,
don't have a patchlevel, but we should!  I'll see about adding that for R).

I suppose all of this could be address by registering additional claims.
I'm not sure it would make sense to add a set of claims (or a complex
claim) that addresses key attestation, though.  That seems to significantly
change the semantics. Or does that sort of extension seem appropriate to
folks?

I also have a set of more detailed comments and questions, plus some
editorial suggestions.  I put the draft into a Google Doc and added
comments.  I've asked my team to take a pass through it as well, and I'll
share it with this mailing list as soon as they've had a chance to weigh in.

Again, my apologies for jumping in late.  Let me know if you think EAT just
isn't appropriate for Android.

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

---

From: Laurence Lundblade <[email-masked]>
Date: Wed, 15 May 2019 19:26:25 -0700

Hi Shawn, a couple notes:

- The claims in EAT are just a start and by no means complete. Adding claims that carry and describe keys is certainly on the list.

- All claims are considered optional and many claims are expected to be left out in some use cases for privacy reasons.

Personally, I’d like to see EAT be useful for Android and would value yours and Google’s input to make it so.

LL

(Not sure what [email-masked] is, have replaced that address with [email-masked])

> On May 15, 2019, at 5:43 PM, Shawn Willden <swillden=[email-masked]> wrote:
> 
> Hi all.
> 
> After being invited by Laurence to join this WG some time ago, I have completely dropped the ball. I apologize for that; in the interim period I have expanded my team from one engineer (me) to six, and we all still have more to do than we can accomplish, which gives a good indication of how much I was dropping on the floor.  I think I have now delegated enough that I can begin to put some time into this.
> 
> After reviewing the draft (which I like a lot, in many ways), I notice a crucial divergence of focus between EAT and Android Keystore Attestation.  Perhaps this means that EAT is not applicable for Android; but I'd like to explore the question a bit.
> 
> Specifically, EAT is about attesting to a device while Keystore Attestation is about attesting to a key -- though we also attest to quite a bit about the context of the key, i.e. the device. Indeed, the device information we provide is growing with every release, because there's a strong pent-up demand for device attestation.  So Keystore Attestation is gradually expanding to include the device attestation role, but must also retain its key attestation purpose.  For EAT to be directly applicable, it would have to include claims about a key as well.
> 
> Perhaps another option is that we could use an EAT attestation as a sub-element inside a CBOR structure that attests to a key.  Or maybe there are other ideas about how an EAT attestation may fit into a larger attestation that describes characteristics of entities other than the containing device?
> 
> Another, more tractable, area of difference is that EAT provides Claims for several data items which Android will likely never allow to be attested because of their privacy implications and potential for ecosystem fragmentation (apps choosing which devices they'll run on -- we generally try to deny them the information they'd like to have to make those choices).  These are:
> UEID
> Origination
> Location
> We do allow OEM Identification, though it's a different format and is restricted.
> 
> Some other claims that we have, and think are important, are OS version and patch-level (represented as a date, YYYYMMDD); secure boot verification key digest; secure boot digest (hash of all verified code); application ID (a digest of the requesting app signing key); and secure app version (hmm, don't have a patchlevel, but we should!  I'll see about adding that for R).
> 
> I suppose all of this could be address by registering additional claims.  I'm not sure it would make sense to add a set of claims (or a complex claim) that addresses key attestation, though.  That seems to significantly change the semantics. Or does that sort of extension seem appropriate to folks?
> 
> I also have a set of more detailed comments and questions, plus some editorial suggestions.  I put the draft into a Google Doc and added comments.  I've asked my team to take a pass through it as well, and I'll share it with this mailing list as soon as they've had a chance to weigh in.
> 
> Again, my apologies for jumping in late.  Let me know if you think EAT just isn't appropriate for Android.
> 
> -- 
> Shawn Willden | Staff Software Engineer | [email-masked] <mailto:[email-masked]> | 720-924-6645
> _______________________________________________
> RATS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rats

---

From: Anders Rundgren <[email-masked]>
Date: Thu, 16 May 2019 06:36:11 +0200

Hi Shawn & RATS,

FWIW, I'm working on another scheme which tries to combine different needs.
In this scheme an attestation (which would contain all applicable device data) creates a shared session key which is subsequently used for provisioning data including creating or importing keys in an atomic session, ending with a "commit" which in turn provides (through the session key) a proof/attest of success to the provisioning service.

The protected API concept was loosely derived from TPM's authorized sessions.

https://github.com/ietf-teep/architecture/issues/52

This scheme also enables the creation of an entirely static "StrongBox" (SE) supporting a three level security architecture OS/TEE/SE.

Note the disclaimer though.

thanx,
Anders

On 2019-05-16 02:43, Shawn Willden wrote:
> Specifically, EAT is about attesting to a /device/ while Keystore Attestation is about attesting to a /key/ -- though we also attest to quite a bit about the context of the key, i.e. the device. Indeed, the device information we provide is growing with every release, because there's a strong pent-up demand for device attestation.  So Keystore Attestation is gradually expanding to include the device attestation role, but must also retain its key attestation purpose.  For EAT to be directly applicable, it would have to include claims about a key as well.
> 
>   * UEID
>   * Origination
>   * Location
> Shawn Willden | Staff Software Engineer [email-masked] <mailto:[email-masked]> | 720-924-6645
>

---

From: Simon Frost <[email-masked]>
Date: Thu, 16 May 2019 11:16:00 +0000

Hi Shawn,

I think you’re at the stage with EAT that we were at Arm on first embracing it. We received the essential guidance, as below, from Laurence that all claims are optional and that the conversation about the claim set is at an early stage. I would encourage you to enlarge on the set of claims you think would be needed for the Android use case and we can see what overlap there might be with other use cases and whether the working group can converge on more standard claims.

From your email, it appears that the two major areas you may need additional claims on are the description of (at least one) software component and description of (at least one) key. The description of a software component appears to be a recurring need and one that seems likely can achieve some convergence towards some standard claims. As an example, have a look at the draft ‘profile’ we put together for an Arm PSA attestation (https://www.ietf.org/id/draft-tschofenig-rats-psa-token-01.txt) and let us know where that does or doesn’t cover your software needs. Note that all claims in that profile are marked as custom ones as it is being used in an existing implementation and we did not want to use what is in the draft in anticipation of potential change, even where some of the PSA profile claims are closely modelled on those in the draft.
I would be very interested in reading your set of claims necessary to describe a key as that use case has also been expressed for our usage.

Thanks
Simon

From: Laurence Lundblade <[email-masked]>
Sent: 16 May 2019 03:26
To: Shawn Willden <swillden=[email-masked]>
Cc: [email-masked]
Subject: Re: [Rats] Android comments on EAT draft

LL

(Not sure what [email-masked]<mailto:[email-masked]> is, have replaced that address with [email-masked]<mailto:[email-masked]>)

On May 15, 2019, at 5:43 PM, Shawn Willden <swillden=[email-masked]<mailto:swillden=[email-masked]>> wrote:

Hi all.

  *   UEID
  *   Origination
  *   Location

--
Shawn Willden | Staff Software Engineer | [email-masked]<mailto:[email-masked]> | 720-924-6645
_______________________________________________
RATS mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/rats

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: Laurence Lundblade <[email-masked]>
Date: Thu, 16 May 2019 09:13:04 -0700

Here’s a slide from the Prague IETF meeting aimed to outline claim definition work.

LL

> On May 16, 2019, at 4:16 AM, Simon Frost <[email-masked]> wrote:
> 
> Hi Shawn,
>  
> From your email, it appears that the two major areas you may need additional claims on are the description of (at least one) software component and description of (at least one) key. The description of a software component appears to be a recurring need and one that seems likely can achieve some convergence towards some standard claims. As an example, have a look at the draft ‘profile’ we put together for an Arm PSA attestation (https://www.ietf.org/id/draft-tschofenig-rats-psa-token-01.txt <https://www.ietf.org/id/draft-tschofenig-rats-psa-token-01.txt>) and let us know where that does or doesn’t cover your software needs. Note that all claims in that profile are marked as custom ones as it is being used in an existing implementation and we did not want to use what is in the draft in anticipation of potential change, even where some of the PSA profile claims are closely modelled on those in the draft.
> From: Laurence Lundblade <[email-masked] <mailto:[email-masked]>> 
> Sent: 16 May 2019 03:26
> To: Shawn Willden <swillden=[email-masked] <mailto:swillden=[email-masked]>>
> Cc: [email-masked] <mailto:[email-masked]>
> (Not sure what [email-masked] <mailto:[email-masked]> is, have replaced that address with [email-masked] <mailto:[email-masked]>)
>  
> 
> 
> On May 15, 2019, at 5:43 PM, Shawn Willden <swillden=[email-masked] <mailto:swillden=[email-masked]>> wrote:
>  
> Hi all.
>  
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/rats <https://www.ietf.org/mailman/listinfo/rats>
>

---

From: Mathias Brossard <[email-masked]>
Date: Thu, 16 May 2019 16:31:43 +0000

> I would be very interested in reading your set of claims necessary to describe a key as that use case has also been expressed for our usage.

On that topic, the "Proof-of-Possession Key Semantics for CBOR Web Tokens" (https://tools.ietf.org/html/draft-ietf-ace-cwt-proof-of-possession-06) is looking to add a CWT claim that contains key information. Once this is standardized it would be possible to include this claim, like all CWT claims, inside an EAT token.

But even for the relatively simple use-case of putting a public key in a token, which it technically supports, I am worried that the semantics might be too constraining. It focuses on proof-of-possession (PoP), where we are thinking about additional functions (signature, encryption, key agreement, etc.). I was wondering if others have an opinion w.r.t. draft-ietf-ace-cwt-proof-of-possession (engage to add language to allow "cnf" use for other things than PoP, create a "key" claim possibly based of "cnf" syntax, ...).

Sincerely,
-- Mathias Brossard

---

From: Giridhar Mandyam <[email-masked]>
Date: Thu, 16 May 2019 17:03:51 +0000

As has been mentioned in other responses, base EAT claims are optional and the original list is meant to be expanded as necessary.

> Specifically, EAT is about attesting to a device while Keystore Attestation is about attesting to a key -- though we also attest to quite a bit about the context of the key, i.e. the device. Indeed…

Much like ARM defined a PSA token (https://tools.ietf.org/html/draft-tschofenig-rats-psa-token-00), there is nothing to prevent the creation of a Keystore attestation token based on EAT.  For instance, the “entity” could be assumed to the keypair instance itself.   I would imagine the list of attributes defined in the 509 attestation extension in https://source.android.com/security/keystore/attestation would be the place to start for what would constitute the claim set in an Keystore attestation token based on EAT.  Note there are already some claims that appear to overlap the Android Keystore attestation attributes (e.g. seclevel for attestationSecurityLevel, nonce for attestationChallenge).  If the existing claim semantics in the EAT spec need to be re-considered for the Keystore use case, then that it something we can discuss.  There are also several claims that would need to be defined in order to meet the requirements for an Android Keystore attestation.

-Giri Mandyam

From: RATS <[email-masked]> On Behalf Of Shawn Willden
Sent: Wednesday, May 15, 2019 5:44 PM
To: [email-masked]
Subject: [Rats] Android comments on EAT draft

Hi all.

  *   UEID
  *   Origination
  *   Location

---

From: Shawn Willden <[email-masked]>
Date: Thu, 16 May 2019 14:34:34 -0600

*From: *Laurence Lundblade <[email-masked]>

> - The claims in EAT are just a start and by no means complete. Adding
> claims that carry and describe keys is certainly on the list.
>

That's great to hear.  The existing claim set seemed to go an entirely
different direction and I wasn't sure if it would be considered a
"pollution" of the claim space to attest such radically different things.
I'll be glad to provide the set of key attestation parameters that Android
uses as a starting point for key attestation discussions.

> - All claims are considered optional and many claims are expected to be
> left out in some use cases for privacy reasons.
>

Perfect.  The Android case is kind of interesting because although we
specify the secure area implementations (and write reference
implementations), most of the implementations on actual devices are written
by third parties, often organizations that aren't as careful about privacy
as Google.

> (Not sure what [email-masked] is, have replaced that address with

Hmm. Me neither.  At least it didn't fall into a black hole.  Thanks for
correcting it.

>
>
> On May 15, 2019, at 5:43 PM, Shawn Willden <
> swillden=[email-masked]> wrote:
>
> Hi all.
>
> Attestation is about attesting to a *key* -- though we also attest to
> quite a bit about the context of the key, i.e. the device. Indeed, the
> device information we provide is growing with every release, because
> there's a strong pent-up demand for device attestation.  So Keystore
> Attestation is gradually expanding to include the device attestation role,
> but must also retain its key attestation purpose.  For EAT to be directly
> applicable, it would have to include claims about a key as well.
>
> Another, more tractable, area of difference is that EAT provides Claims
> for several data items which Android will likely never allow to be attested
> Some other claims that we have, and think are important, are OS version
> and patch-level (represented as a date, YYYYMMDD); secure boot verification
> key digest; secure boot digest (hash of all verified code); application ID
> (a digest of the requesting app signing key); and secure app version (hmm,

---

From: Shawn Willden <[email-masked]>
Date: Thu, 16 May 2019 15:11:49 -0600

*From: *Simon Frost <[email-masked]>

> As an example, have a look at the draft ‘profile’ we put together for an
> Arm PSA attestation (
> https://www.ietf.org/id/draft-tschofenig-rats-psa-token-01.txt) and let
> us know where that does or doesn’t cover your software needs.
>

I'll do that.

I would be very interested in reading your set of claims necessary to
> describe a key as that use case has also been expressed for our usage.
>

Sure, here's a list of everything currently included in Android key
attestations (excluding device info items and some elements that are
redundant, also specified in the enclosing X.509 certificate):

   - Purpose:  one or more of SIGN, ENCRYPT and WRAP_KEY.
   - Digest: one or more of MD5, SHA1, SHA-256, SHA-324, SHA-512; which
   digest(s) can be used for message digesting (MD5 and SHA1 are only for
   legacy compatibility).
   - Padding:  (RSA only) one or more of RSA_PKCS1_1_5_ENCRYPT, RSA_OAEP,
   RSA_PKCS1_1_5_SIGN and RSA_PSS
   - Rollback resistance: Boolean, if true, indicates that when the key is
   deleted it is guaranteed never to be usable again
   - No auth required:  Indicates key can be used without user
   authentication.  If this is present, user auth type and auth timeout must
   not be present.
   - User auth type:  Indicates type of required user authentication
   (password/biometric)
   - Auth timeout: Indicates time in seconds during which key can be used
   after user authentication (absence indicates key requires authentication
   for each key usage).
   - Allow while on body: Applicable only to wearables, and only for keys
   that require authentication with a timeout.  Indicates that the key
   immediately becomes unusable when the device is removed from the body, even
   if timeout has not yet expired.
   - Origin:  Where the key originated, one of GENERATED (in device; exists
   nowhere else), DERIVED (in device, but also derivable by some off-device
   entity), IMPORTED (imported in plaintext), SECURELY_IMPORTED (imported in
   encrypted form), UNKNOWN
   - Application ID:  Which Android app created the key

A note about purpose, digest, padding: the idea is that AndroidKeyStore
only allows keys to be used in the mode(s) that were declared when the key
was created.  Any attempt to use the keys in any other way (e.g. sign with
a n RSA key that has only the ENCRYPT purpose) will be rejected by the
TEE/SE.

I think Android R will add support for ECDH, so that will add some
associated claims, and we may also add an option for secure export of key
material, assuming the key was configured to allow it at creation/import
time.  That will add some associated claims as well, including the public
key(s) to which exports may be encrypted.

---

From: Shawn Willden <[email-masked]>
Date: Thu, 16 May 2019 15:15:01 -0600

Oh, I should also mention that in R I think we're going to add a claim to
present security certifications, for example Common Criteria Secure IC
Profile PP84, probably in multiple assurance levels (though PP84 is EAL4
plus AVA_VAN.5), and perhaps some others.

*From: *Shawn Willden <[email-masked]>
*Date: *Thu, May 16, 2019 at 3:11 PM
*To: *Simon Frost
*Cc: *Laurence Lundblade, [email-masked]

>    - Rollback resistance: Boolean, if true, indicates that when the key
>    is deleted it is guaranteed never to be usable again
>    - Origin:  Where the key originated, one of GENERATED (in device;
>    exists nowhere else), DERIVED (in device, but also derivable by some
>    off-device entity), IMPORTED (imported in plaintext), SECURELY_IMPORTED
>    (imported in encrypted form), UNKNOWN

---

From: Jeremy O'Donoghue <[email-masked]>
Date: Fri, 17 May 2019 07:53:17 +0000

This specific point is one for which GlobalPlatform has a solution in our TEE/SE related claim definitions. It is possible that this solution may be more general, although it had not previously occurred to me that this could be the case.

The problem with having a device self-attest security is that some certifications change e.g. due to discovered vulnerabilities / have variable duration etc. For low-end devices (and, frankly even for high-end) managing revocations is tricky, so GlobalPlatform created the Digital Letter of Approval. This is simpler than it sounds.

It starts from the perspective that while the manufacturer is necessarily trusted in respect of keys injected during manufacturing, it is not really the most trustworthy entity when it comes to security certification. It this makes sense to separate verification of claims about a device (or key, or whatever) and claims about certification. It further assumes that certification status may change over time in ways that could be difficult for devices with low-bandwidth connectivity to track.

The Digital Letter of Approval is a published specification, available for free (of charge) download behind a click-through license at https://globalplatform.org/specs-library/?filter-committee=tps. I am aware that some RATS participants may be unable/unwilling to access this document, so I paste the outline DLOA format information below:

The Digital Letter of Approval (DLOA) is an XML file containing the minimum fields required to:

  *   • Identify the platform – the combination of the application and the platform – this DLOA corresponds to

  *   • Identify the Authority that issued the corresponding Letter of Approval

  *   • Provide the expiration date of the corresponding Letter of Approval

  *   • Identify the Letter of Approval from which this DLOA has been generated (i.e. include the identifier of the Letter of Approval issued by the Authority)

  *   • Ensure authenticity and integrity of the DLOA thanks to a digital signature computed by the Authority

  *   • Provide additional information such as the date of issuance of the corresponding Letter of Approval or

a URL where the original Letter of Approval can be retrieved

The work to incorporate this in an EAT is ongoing, and will be shared at Public Review time, but basically you need two claims: one is a platform identifier and the second is the URL of a web service where certification details can be retrieved.

The web service is generally operated by a Certification Body (GlobalPlatform in the case of GlobalPlatform compliance secretariat) and allows retrieval of complete certification information which is valid at the time of retrieval.

If an approach based on an external registrar service is of more general interest, I can arrange a more detailed explanation.

Best regards
Jeremy

On 16 May 2019, at 22:15, Shawn Willden <swillden=[email-masked]<mailto:swillden=[email-masked]>> wrote:

CAUTION: This email originated from outside of the organization.

Oh, I should also mention that in R I think we're going to add a claim to present security certifications, for example Common Criteria Secure IC Profile PP84, probably in multiple assurance levels (though PP84 is EAL4 plus AVA_VAN.5), and perhaps some others.

From: Shawn Willden <[email-masked]<mailto:[email-masked]>>
Date: Thu, May 16, 2019 at 3:11 PM
To: Simon Frost
Cc: Laurence Lundblade, [email-masked]<mailto:[email-masked]>

From: Simon Frost <[email-masked]<mailto:[email-masked]>>
As an example, have a look at the draft ‘profile’ we put together for an Arm PSA attestation (https://www.ietf.org/id/draft-tschofenig-rats-psa-token-01.txt) and let us know where that does or doesn’t cover your software needs.

I'll do that.

Sure, here's a list of everything currently included in Android key attestations (excluding device info items and some elements that are redundant, also specified in the enclosing X.509 certificate):

  *   Purpose:  one or more of SIGN, ENCRYPT and WRAP_KEY.
  *   Digest: one or more of MD5, SHA1, SHA-256, SHA-324, SHA-512; which digest(s) can be used for message digesting (MD5 and SHA1 are only for legacy compatibility).
  *   Padding:  (RSA only) one or more of RSA_PKCS1_1_5_ENCRYPT, RSA_OAEP, RSA_PKCS1_1_5_SIGN and RSA_PSS
  *   Rollback resistance: Boolean, if true, indicates that when the key is deleted it is guaranteed never to be usable again
  *   No auth required:  Indicates key can be used without user authentication.  If this is present, user auth type and auth timeout must not be present.
  *   User auth type:  Indicates type of required user authentication (password/biometric)
  *   Auth timeout: Indicates time in seconds during which key can be used after user authentication (absence indicates key requires authentication for each key usage).
  *   Allow while on body: Applicable only to wearables, and only for keys that require authentication with a timeout.  Indicates that the key immediately becomes unusable when the device is removed from the body, even if timeout has not yet expired.
  *   Origin:  Where the key originated, one of GENERATED (in device; exists nowhere else), DERIVED (in device, but also derivable by some off-device entity), IMPORTED (imported in plaintext), SECURELY_IMPORTED (imported in encrypted form), UNKNOWN
  *   Application ID:  Which Android app created the key
A note about purpose, digest, padding: the idea is that AndroidKeyStore only allows keys to be used in the mode(s) that were declared when the key was created.  Any attempt to use the keys in any other way (e.g. sign with a n RSA key that has only the ENCRYPT purpose) will be rejected by the TEE/SE.

I think Android R will add support for ECDH, so that will add some associated claims, and we may also add an option for secure export of key material, assuming the key was configured to allow it at creation/import time.  That will add some associated claims as well, including the public key(s) to which exports may be encrypted.

---

From: Thomas Fossati <[email-masked]>
Date: Fri, 17 May 2019 09:08:28 +0000

Hi Jeremy,

Thanks for the insights into GlobalPlatform.

I have a few questions inline.

On 17/05/2019, 08:53, Jeremy O'Donoghue wrote:
> This specific point is one for which GlobalPlatform has a solution in
> our TEE/SE related claim definitions. It is possible that this
> solution may be more general, although it had not previously occurred
> to me that this could be the case.
>
> [...]
>
> The Digital Letter of Approval is a published specification, available
> for free (of charge) download behind a click-through license at
> https://globalplatform.org/specs-library/?filter-committee=tps.  I am
> aware that some RATS participants may be unable/unwilling to access
> this document, so I paste the outline DLOA format information below:
>
> * Identify the platform – the combination of the application and the
>   platform – this DLOA corresponds to

It is not completely clear to me what is meant by platform in this
context?  Is it the TEE/SE only or is it the whole device or something
else?

Also when you mention the "platform identifier" a few paragraphs below,
what kind of identifier is this?  And who has authority to mint these
IDs?

> * Identify the Authority that issued the corresponding Letter of
>   Approval
>
> * Provide the expiration date of the corresponding Letter of
>   Approval
>
> * Identify the Letter of Approval from which this DLOA has been
>   generated (i.e. include the identifier of the Letter of Approval
>   issued by the Authority)
>
> * Ensure authenticity and integrity of the DLOA thanks to a digital
>   signature computed by the Authority
>
> * Provide additional information such as the date of issuance of the
>   corresponding Letter of Approval or a URL where the original Letter of
>   Approval can be retrieved
>
> The work to incorporate this in an EAT is ongoing, and will be shared
> at Public Review time, but basically you need two claims: one is a
> platform identifier and the second is the URL of a web service where
> certification details can be retrieved.
>
> The web service is generally operated by a Certification Body
> (GlobalPlatform in the case of GlobalPlatform compliance secretariat)
> and allows retrieval of complete certification information which is
> valid at the time of retrieval.
>
> If an approach based on an external registrar service is of more
> general interest, I can arrange a more detailed explanation.

That would be fantastic.

Cheers, t

---

From: Jeremy O'Donoghue <[email-masked]>
Date: Fri, 17 May 2019 11:21:27 +0000

Hi Thomas,

Please see inline

On 17 May 2019, at 10:08, Thomas Fossati <[email-masked]<mailto:[email-masked]>> wrote:

Hi Jeremy,

[...]

The Digital Letter of Approval (DLOA) is an XML file containing the
minimum fields required to:

Today the "platform" is a unique identifier, normally chosen by the manufacturer, that identifies the hardware and any software relevant to the Target of Evaluation described in a Security Target document - in GlobalPlatform terms this is the TEE or SE, but it is really dependent on the chosen Protection Profile.

There is nothing inherently preventing this from being an entire device although there are, to my knowledge, few certifications that operate at the device level. I do expect this to change.

All of these would be issued by a Conformance Assessment Body (CAB).

In most cases the CAB approves test laboratories to perform the testing on behalf of a device manufacturer and submit reports to the CAB for assessment. Labs may choose to participate in multiple schemes, both commercial and/or government run.

In general, we can consider several types of Conformance Assessment Body.

  *   Commercial CAB schemes such as GlobalPlatform, EMVCo, FIDO, China UnionPay
  *   Government-run / Supra-national schemes such as ANSSI, BSI, SOG-IS mutual recognition, probably ENISA in future,

In principle, anyone can set up such a scheme. In practice a degree of credibility is needed to assure relying parties of the value of a certification. Commercial CABs face challenges here and usually go to considerable lengths to show that certifications are meaningful (e.g. GlobalPlatform went to ANSSI for assessment of the TEE Protection Profile.

I expect two general changes in the use of certification over the next couple of years that might affect how we think of attesting certifications:

  *   Regulation at the national or supra-national level. It may be that certifications from selected "trusted" CABs are required for some device classes.
  *   Creation of meaningful certifications at the whole device level. As an example, a device may have some components that are certified at high levels of assurance (e.g. a Secure Element or TPM / EAL4+), others at a lower ("substantial" / EAL2+) level and some without more than simple functional compliance (e.g. a WiFi subsystem). Such certification will certify a complete device as fit for purpose as some level, depending on the Security Functional Requirements for that device class.

The general concept behind DLOA is flexible enough to adapt to these.

That would be fantastic.

Cheers, t

---

From: Thomas Fossati <[email-masked]>
Date: Fri, 17 May 2019 16:24:48 +0000

Jeremy: thanks for taking the time to elaborate, very much appreciated.

On 17/05/2019, 12:21, "RATS on behalf of Jeremy O'Donoghue" <[email-masked] on behalf of [email-masked]> wrote:

    Hi Thomas,

    Please see inline

    On 17 May 2019, at 10:08, Thomas Fossati <[email-masked]> wrote:

    Hi Jeremy,

    [...]

    Today the "platform" is a unique identifier, normally chosen by the manufacturer, that identifies the hardware and any software relevant to the Target of Evaluation described in a Security Target document - in GlobalPlatform terms this is the TEE or SE,
     but it is really dependent on the chosen Protection Profile.

    In principle, anyone can set up such a scheme. In practice a degree of credibility is needed to assure relying parties of the value of a certification. Commercial CABs face challenges here and usually go to considerable lengths to show that certifications
     are meaningful (e.g. GlobalPlatform went to ANSSI for assessment of the TEE Protection Profile.

    * Regulation at the national or supra-national level. It may be that certifications from selected "trusted" CABs are required for some device classes.
    * Creation of meaningful certifications at the whole device level. As an example, a device may have some components that are certified at high levels of assurance (e.g. a Secure Element or TPM / EAL4+), others at a lower ("substantial" / EAL2+) level
     and some without more than simple functional compliance (e.g. a WiFi subsystem). Such certification will certify a complete device as fit for purpose as some level, depending on the Security Functional Requirements for that device class.

    That would be fantastic.

    Cheers, t

    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: Laurence Lundblade <[email-masked]>
Date: Fri, 17 May 2019 16:19:07 -0700

> On May 17, 2019, at 4:21 AM, Jeremy O'Donoghue <[email-masked]> wrote:
> 

Can you give some examples?

Is a platform identifier unique by being a 128-bit random number, or it is a combination of OEM ID, HW and SW versions? 

How does it relate to OEM ID, HW Version and SW Version?

LL

---

From: Laurence Lundblade <[email-masked]>
Date: Fri, 17 May 2019 16:57:07 -0700

> On May 16, 2019, at 9:31 AM, Mathias Brossard <[email-masked]> wrote:
> 
> But even for the relatively simple use-case of putting a public key in a token, which it technically supports, I am worried that the semantics might be too constraining. It focuses on proof-of-possession (PoP), where we are thinking about additional functions (signature, encryption, key agreement, etc.).

Mathias, can you say more about the additional functions you are thinking about? 

Would they change the protocol flow in a big way? Mostly what we are thinking is that the RP sends a nonce to the device and the device returns a token. 

LL

---

From: Jeremy O'Donoghue <[email-masked]>
Date: Mon, 20 May 2019 08:51:09 +0000

On 18 May 2019, at 00:19, Laurence Lundblade <[email-masked]<mailto:[email-masked]>> wrote:

On May 17, 2019, at 4:21 AM, Jeremy O'Donoghue <[email-masked]<mailto:[email-masked]>> wrote:

I will see if I can get some real examples - may take a week or so.

It is a string. It is something like a combination of OEM ID, HW and SW versions. It is not intended to be cryptographically unique.

The platform identifier in DLOA is only trustworthy if you have first verified the entity to which it applies.

As far as I am aware, it is chosen by the platform vendor as a mechanism to uniquely identify the combination of the above that was certified. It probably could be a concatenation of the above, but I believe it is generally shorter for convenience. Best way to describe it is as a hardware and meta-build identifier. Some strong identifying an exact HW platform and some combination of SW images.

Jeremy

LL

---

From: Mathias Brossard <[email-masked]>
Date: Mon, 20 May 2019 21:03:38 +0000

Hi,

The idea is that a device might want to attest a key that would be used for other purposes than proof-of-possession (authentication). The attestation token would act as a form of certificate, essentially the link between a key to a device. We are thinking about integrity (signature) and encryption / key agreement. In many cases you could use TLS with PoP to provide the same kind of security properties. But in some cases there is no IP connectivity, the resources are too constrained or you want the security to be maintained end-to-end (rather than at the transport layer).

The protocol flow would not change for attestation.

Sincerely,
-- Mathias Brossard

From: Laurence Lundblade <[email-masked]>
Date: Friday, May 17, 2019 at 6:57 PM
To: Mathias Brossard <[email-masked]>
Cc: Simon Frost <[email-masked]>, Shawn Willden <swillden=[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Rats] Android comments on EAT draft

On May 16, 2019, at 9:31 AM, Mathias Brossard <[email-masked]<mailto:[email-masked]>> wrote:

LL

---

From: Giridhar Mandyam <[email-masked]>
Date: Tue, 21 May 2019 03:40:45 +0000

> The idea is that a device might want to attest a key that would be used for other purposes than proof-of-possession (authentication).

EAT can be applied to use cases other than attestation of a key that is only used for PoP.

For instance, I had proposed a usage of EAT for the W3C’s Web Authentication API (Webauthn).  For Webauthn, the ideal attestation would be for the authenticator itself (e.g. biometric), which could also include the credential (keypair) along with matcher protection, anti-spoof implementation, etc.  In the Webauthn case, the keypair is used to sign assertions when a user verification having taken place (see https://w3c.github.io/webauthn/#sctn-op-get-assertion, the assertion represents more than just PoP of the private key).  The Webauthn attestation can be broader than just attesting the keypair – the authenticator implementation can be attested as well (which is not the same as the device itself).  In other words, the attestation is broader than for a key used only for proof-of-possession.

Following the model provided in Webauthn (https://w3c.github.io/webauthn/#sctn-attestation), I proposed https://pr-preview.s3.amazonaws.com/gmandyam/webauthn/pull/1121.html#fido-eat .  Granted – this is only an initial proposal and would need a another look.  But the existing claim set only had to be extended slightly in order to meet Webauthn requirements.  The claim set can be extended further given the use of the Webauthn keypair in the context of user verification.  For instance, in the SoC context, if the keypair is implemented in a root-of-trust but the biometric is implemented in user space (e.g. rich execution environment such as Android), then the EAT claims can be augmented to provide this information.

Note that for Webauthn, an IANA registry has been proposed that would allow for extension of the existing suite of attestation formats (https://tools.ietf.org/html/draft-hodges-webauthn-registries-02 ).  For any attestation formats this group considers, it could be a good exercise to see how the format could meet the Webauthn requirements if we want to verify that an attestation format is usable beyond keypairs used for PoP.

-Giri Mandyam

From: RATS <[email-masked]> On Behalf Of Mathias Brossard
Sent: Monday, May 20, 2019 2:04 PM
To: Laurence Lundblade <[email-masked]>
Cc: Shawn Willden <swillden=[email-masked]>; [email-masked]; Simon Frost <[email-masked]>
Subject: Re: [Rats] Android comments on EAT draft

.
Hi,

Sincerely,
-- Mathias Brossard

From: Laurence Lundblade <[email-masked]<mailto:[email-masked]>>
Date: Friday, May 17, 2019 at 6:57 PM
To: Mathias Brossard <[email-masked]<mailto:[email-masked]>>
Cc: Simon Frost <[email-masked]<mailto:[email-masked]>>, Shawn Willden <swillden=[email-masked]<mailto:swillden=[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Rats] Android comments on EAT draft

LL

---

From: Laurence Lundblade <[email-masked]>
Date: Tue, 21 May 2019 17:40:12 +0200

Seems like we can define the inclusion of a public key in an attestation token to mean whatever we want. We don’t have to restrict ourselves to the semantics implied by draft-ietf-ace-cwt-proof-of-possession-06 (and usage for authentication only seems implied). 

Maybe there is optional key usage associated with the key. If the key usage is absent, then there is no restriction. The key usage would look something like X.509 Extended Key Use <https://tools.ietf.org/html/rfc5280#section-4.2.1.12>.

(Is proof-of-possesion a term defined somewhere that I don’t know about to mean something very specific? If so where is this definition?)

LL

> On May 20, 2019, at 11:03 PM, Mathias Brossard <[email-masked]> wrote:
> 
> Hi,
>  
> On May 16, 2019, at 9:31 AM, Mathias Brossard <[email-masked] <mailto:[email-masked]>> wrote:
>