Re: [Rats] Android comments on EAT draft

[Jeremy O'Donoghue <[e-mail]>]

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=[e-mail]<mailto:swillden=[e-mail]>> 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 <[e-mail]<mailto:[e-mail]>>
Date: Thu, May 16, 2019 at 3:11 PM
To: Simon Frost
Cc: Laurence Lundblade, [e-mail]<mailto:[e-mail]>

From: Simon Frost <[e-mail]<mailto:[e-mail]>>
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.

--
Shawn Willden | Staff Software Engineer | [e-mail]<mailto:[e-mail]> | 720-924-6645


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