[EAT] Introduction

[Shawn Willden <[e-mail]>]

Please excuse me if I'm violating some list etiquette with this
introduction; it seemed like the best way to jump in. It appears that
cross-posting between RATS and EAT is fairly common, so I think I'm good on
that front :-)

My name is Shawn Willden, and I lead the Android hardware-backed security
team at Google. I designed and implemented the Keystore attestation scheme
that's been present in Android since 7.0 (Nougat) and required for new
devices since 8.0 (Oreo). Laurence invited me to participate in the EAT
effort.

I'm very interested in standard attestation protocols.  Attestation in
Keystore began as a narrow solution to a narrow problem, but it has become
clear that there is massive demand for attestation in a wide variety of
contexts. I'm not particularly happy with Keystore attestation, but it's
hard to argue for changing it given that many people have implemented
solutions on it, warty as it is. Compliance with an IETF standard would
provide a perfect rationale for revising it -- assuming, of course, that
the standard actually meets all of Android's needs.

Since I doubt everyone is familiar with Android Keystore attestation [1],
let me give a brief overview.

Android Keystore provides a place for Android apps and system components to
store and use cryptographic key material (RSA, ECC, AES & HMAC) in a
trusted [2] environment. The goal is that key material should not be
compromised even by total compromise of the Android operating system, e.g.
kernel compromise.

Further, since 6.0 (Marshmallow), various usage constraints can be attached
to keys at key creation time, and most of these constraints are also
enforced by the trusted environment, limiting the use of the trusted
environment as an oracle for an attacker who has compromised Android. The
ways that keys can be used are expressed affirmatively as "authorizations";
keys may only be used in ways defined by the associated authorizations.
Perhaps the most obviously-useful of the authorizations is authentication
binding. Authentication-bound keys may only be used when the user
authenticates via password or fingerprint so an attacker who steals or
finds your phone cannot use the keys.

So Keystore provides a valuable tool to authors of apps that require strong
security. For example, for a key used to authenticate an account holder to
a banking system. But this tool is much less valuable if the bank's server
can't verify that the secret is managed in a trusted environment. Hence,
Keystore attestation, which allows the trusted environment to prove that it
secures the key material, and specifies the authorizations that define how
it may be used.

Some important constraints upon Keystore derive from the fact that it is an
implementation (some may say "subversion") of the Java Keystore API [3].  A
result of needing to fit attestation into the standard Java APIs was that
attestations must come in the form of an X.509 certificate chain. Given
that it would be necessary for users of Keystore attestations to parse the
ASN.1 DER-encoded X.509 certificate, I opted to implement attestation as an
ASN.1 DER-encoded certificate extension, so they didn't have to parse two
different sorts of encodings. To simplify implementation in
resource-constrained trusted environments, I opted to structure the schema
around the data structure that implementations already used to manage
authorizations, namely "authorization lists".

The schema has subsequently been extended to support device ID attestation
(attesting to various device identifiers -- though this functionality is
tightly restricted in the interest of user privacy), and attestation of
firmware versioning data. I expect more such extensions to come in each
release of Android, as more use cases are identified and implemented.

Within the Android scheme, attestation signing keys are injected into
devices during manufacturing and can never be rotated without returning the
device to the manufacturer. Signing keys are also not device-unique,
because we use standard RSA and ECDSA signatures, not a group scheme, and
we wished to avoid providing a strong unique device identifier, again for
user privacy reasons. Android compliance requirements specify that each
signing key must be injected into at least 100K devices, all of the same
model. Attestation key certificate chains are rooted in a Google-owned
certificate for Android devices with Google Play; manufacturers of non-Play
devices (e.g. Amazon) can provide their own root.

Because this is already long I won't go into the rationale behind the
decisions described in the last paragraph, but I'm happy to explain.

[1] https://source.android.com/security/keystore/attestation
[2] "Trusted" is always an interesting word. The actual security level of
the various Android trusted execution environments (TEEs) is largely
unknown. Based on what has happened every time security researchers looked
hard at them, I suspect they're not very good. However, they are isolated
from the main Android OS and the usage model generally means that it's
necessary to first compromise Android in order to even begin attacking the
TEE. Thus they provide a security benefit, though precisely how large is
unknown. With Android 9.0 (Pie) we've begun supporting Android Keystore
backed by hardware secure elements, which come with a culture of
certification testing which is presently lacking in the TEE world.
[3] https://docs.oracle.com/javase/7/docs/api/java/security/KeyStore.html



-- 
Shawn Willden | Staff Software Engineer | [e-mail] | 801-477-4296