Posted by Shawn Willden, Software Engineer

Android’s keystore has been available for many years, providing app developers
with a way to use cryptographic keys for authentication and encryption. Keystore
keeps the key material out of the app’s process space, so that the app cannot
inadvertently reveal it to the user where it could be phished, leak it through
some other channel, or have it compromised in the event of a compromise of the
app. Many devices also provide hardware-based security for keystore keys in
secure hardware, which keeps the key material out of the Android system
entirely, so that the key material cannot be leaked even by a Linux kernel
compromise. In the vast majority of Android devices, secure hardware is a
special mode of the main CPU, with hardware-enforced isolation from the Linux
kernel and Android userspace. Alternatively, some devices use a separate secure
microprocessor.

Android provides APIs that allow the app to determine whether a given keystore
key is in secure hardware, but these APIs could be unreliable if the operating
system has been compromised. Key attestation provides a way for a device’s
secure hardware to verify that an asymmetric key is in secure hardware,
protected against compromise of the Android OS.

History of Keystore

Keystore was originally introduced in Android 4.0 and keys were encrypted with
the user’s passcode. In Android 4.1 the infrastructure to use device secure
hardware was added.

Up until Android 6.0, Keystore supported RSA and ECDSA. In Android 6.0, Keystore
was significantly enhanced, adding support for AES and HMAC. Also, other crucial
elements of cryptographic operations, such as RSA padding¹ and AES block chaining² modes were moved into secure hardware.

In Android 6.0, Keystore also gained the ability to restrict the ways in which a
particular key could be used. The most obviously useful restriction that can be
applied is user authentication binding. This allows a key’s usage to be
“bound” to the user’s passcode—their PIN, pattern, or password—or fingerprint.
For passcode authentication binding, the app developer can specify a timeout in
seconds. If more than the specified time has elapsed since the user last entered
their passcode, the secure hardware refuses any requests to use the key.
Fingerprint-bound keys require a new user authentication each time the key is
used.

Other, more technical, restrictions can be applied to Android 6.0+ keys as well.
In particular, at point of key creation or import, it is necessary to specify
the cryptographic purposes (encrypt, decrypt, sign, or verify) for which the key
may be used, as well as padding and block modes, digests, source of entropy for
initialization vectors or nonces, and other details of the cryptographic
operation. Because the specified information is permanently and
cryptographically bound to the key material, Keystore won’t allow the key to be
used in any other way. Therefore, an attacker who gains control of the app or
the system can’t misuse the key. To help prevent attacks, developers should
specify the narrowest possible range of uses for a given key.

One of the most important changes to Android Keystore was introduced in Android
7.0. New devices that launch with Android 7.0+ with a secure lock screen must
have secure hardware and support hardware-based passcode authentication and
keystore keys. Prior to Android 7.0, secure hardware support was widespread, but
over the next few years it will become universal.

In Android 8.0, key attestation was made mandatory for all new devices that ship
with Google Play installed.

Why use key attestation?

Suppose you’re developing an app to provide a bank’s customers with access to
their bank balance, transaction history, and bill pay system. Security is
important; you don’t want anyone who picks up the user’s phone to have access to
their the bank account. One approach would be to use the user’s web site
password. But that’s often inconvenient for the user because web sites often
demand long, complex passwords, which are inconvenient on a small touchscreen.

With Android Keystore, you can generate an asymmetric authentication key, such
as a 256-bit ECDSA key, and have each user sign in with their complex web
password once, then register the public key in the bank’s customer account
database. Each time they open the app, you can execute a challenge-response
authentication protocol using that ECDSA key. Further, if you make the key
authentication-bound, the user can authenticate with their lock screen passcode
or fingerprint each time they open the app. That allows them to use the simpler
and more convenient authentication mechanism on their phone.

If an attacker compromises Android and attempts to extract the key, they
shouldn’t be able to because the key is in secure hardware.

As an app developer, key attestation allows you to verify on your server that
the ECDSA key your app requested actually lives in secure hardware. Note that
there’s little point in using the attestation in your app itself; if the Android
OS is uncompromised and trustworthy, then you can just use the KeyInfo
class introduced in 6.0 to discover whether the key is in secure hardware. If it
is compromised, then that API and any attempt you make to validate the
attestation on device are both unreliable.

Note that key attestation is distinct from SafetyNet
attestation. They’re the same concept, but attest to different things and
come from different places. Keystore key attestation affirms that a crypto key
lives in secure hardware and has specific characteristics. SafetyNet attestation
affirms that a device is real (not an emulator) and that it’s running known
software. SafetyNet uses Keystore key attestation under the covers, so if you
want to know about device integrity use that. If you want to confirm that your
key is in secure hardware, use key attestation.

For details and sample code, see the key
attestation training article on developer.android.com.

Notes