Re: [Rats] Android comments on EAT draft

[Shawn Willden <[e-mail]>]

*From: *Simon Frost <[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] | 720-924-6645