platform_hardware_interfaces/security/rkp

Remote Provisioning HAL

Objective

Design a HAL to support over-the-air provisioning of certificates for asymmetric keys. The HAL must interact effectively with Keystore (and other services) and protect device privacy and security.

Note that this API was originally designed for KeyMint, with the intention that it should be usable for other HALs that require certificate provisioning. Throughout this document we'll refer to the Keystore and KeyMint (formerly called Keymaster) components, but only for concreteness and convenience; those labels could be replaced with the names of any system and secure area components, respectively, that need certificates provisioned.

Key design decisions

General approach

To more securely and reliably get keys and certificates to Android devices, we need to create a system where no party outside of the device's secure components is responsible for managing private keys. The strategy we've chosen is to deliver certificates over the air, using an asymmetric key pair derived from a unique device secret (UDS) as a root of trust for authenticated requests from the secure components. We refer to the public half of this asymmetric key pair as UDS_pub.

In order for the provisioning service to trust UDS_pub we ask device OEMs to use one of two mechanisms:

1. (Preferred, recommended) The device OEM extracts the UDS_pub from each device they manufacture and uploads the public keys to a backend server.

2. The device OEM signs the UDS_pub and stores the certificates on the device rather than uploading a UDS_pub for every device immediately. However, there are many disadvantages and costs associated with this option as the OEM will need to pass a security audit of their factory's physical security, CA and HSM configuration, and incident response processes before the OEM's public key is registered with the provisioning server.

Note that in the full elaboration of this plan, UDS_pub is not the key used to sign certificate requests. Instead, UDS_pub is just the first public key in a chain of public keys that end the KeyMint public key. All keys in the chain are transitively derived from the UDS and joined in a certificate chain following the specification of the Android Profile for DICE.

Phases

RKP will be deployed with phased management of the root of trust binding between the device and the backend. To briefly describe them:

• Degenerate DICE (Phase 1): A TEE root of trust key pair is used to sign certificate requests; a single self-signed certificate signifies this phase.
• DICE (Phase 2): A hardware root of trust key pair is only accessible to ROM code; the boot process follows the Android Profile for DICE.
• SoC vendor certified DICE (Phase 3): This is identical to Phase 2, except the SoC vendor also does the UDS_pub extraction or certification in their facilities, along with the OEM doing it in the factory. This tightens up the "supply chain" and aims to make key upload management more secure.

Privacy considerations

Because the UDS, CDIs and derived values are unique, immutable, unspoofable hardware-bound identifiers for the device, we must limit access to them. We require that the values are never exposed in public APIs and are only available to the minimum set of system components that require access to them to function correctly.

Key and cryptographic message formatting

For simplicity of generation and parsing, compactness of wire representation, and flexibility and standardization, we've settled on using the CBOR Object Signing and Encryption (COSE) standard, defined in RFC 8152. COSE provides compact and reasonably simple, yet easily-extensible, wire formats for:

• Keys,
• MACed messages,
• Signed messages, and
• Encrypted messages

COSE enables easy layering of these message formats, such as using a COSE_Sign structure to contain a COSE_Key with a public key in it. We call this a "certificate".

Due to the complexity of the standard, we'll spell out the COSE structures completely in this document and in the HAL and other documentation, so that although implementors will need to understand CBOR and the CBOR Data Definition Language (CDDL, defined in RFC 8610), they shouldn't need to understand COSE.

Note, however, that the certificate chains returned from the provisioning server are standard X.509 certificates.

Algorithm choices

This document uses:

• ECDSA P-256 for attestation signing keys;
• Remote provisioning protocol signing keys:
• Ed25519 / P-256 / P-384
• ECDH keys:
• X25519 / P-256
• AES-GCM for all encryption;
• SHA-256 / SHA-384 / SHA-512 for message digesting;
• HMAC with a supported message digest for all MACing; and
• HKDF with a supported message digest for all key derivation.

We believe that Curve25519 offers the best tradeoff in terms of security, efficiency and global trustworthiness, and that it is now sufficiently widely-used and widely-implemented to make it a practical choice.

However, since hardware such as Secure Elements (SE) do not currently offer support for curve 25519, we are allowing implementations to instead make use of ECDSA and ECDH.

The CDDL in the rest of the document will use the '/' operator to show areas where either curve 25519, P-256 or P-384 may be used. Since there is no easy way to bind choices across different CDDL groups, it is important that the implementor stays consistent in which type is chosen. E.g. taking ES256 as the choice for algorithm implies the implementor should also choose the P256 public key group further down in the COSE structure.

Design

Certificate provisioning flow

TODO(jbires): Replace this with a .png containing a sequence diagram. The provisioning flow looks something like this:

rkpd -> KeyMint: generateKeyPair KeyMint -> KeyMint: Generate key pair KeyMint --> rkpd: key_blob,pubkey rkpd -> rkpd: Store key_blob,pubkey rkpd -> Server: Get challenge Server --> rkpd: challenge rkpd -> KeyMint: genCertReq(pubkeys, challenge) KeyMint -> KeyMint: Sign CSR KeyMint --> rkpd: signed CSR rkpd --> Server: CSR Server -> Server: Validate CSR Server -> Server: Generate certificates Server --> rkpd: certificates rkpd -> rkpd: Store certificates

The actors in the above diagram are:

• Server is the backend certificate provisioning server. It has access to the uploaded device public keys and is responsible for providing encryption keys, decrypting and validating requests, and generating certificates in response to requests.
• rkpd is, optionally, a modular system component that is responsible for communicating with the server and all of the system components that require key certificates from the server. It also implements the policy that defines how many key pairs each client should keep in their pool. When a system ships with rkpd as a modular component, it may be updated independently from the rest of the system.
• Keystore is the Android keystore daemon (or, more generally, whatever system component manages communications with a particular secure aread component).
• KeyMint is the secure area component that manages cryptographic keys and performs attestations (or perhaps some other secure area component).

Android Profile for DICE

The Android Profile for DICE is based on the Open Profile for DICE, with additional constraints for details that the Open Profile for DICE leaves intentionally underspecified. This section describes the differences from the Open Profile for DICE.

Algorithms

The choice of algorithm must remain consistent with a given certificate e.g. if SHA-256 is used for the code hash then the authority hash, config hash, etc. must also use SHA-256.

• UDS and CDI key pairs:
  • Ed25519 / P-256 / P-384
• Hash algorithms (digests can be encoded with their natural size and do not need to be the 64-bytes specified by the Open Profile for DICE):
  • SHA-256 / SHA-384 / SHA-512
• HKDF with a supported message digest for all key derivation

Mode

A certificate must only set the mode to normal when all of the following conditions are met when loading and verifying the software component that is being described by the certificate:

• verified boot with anti-rollback protection is enabled
• only the verified boot authorities for production images are enabled
• debug ports, fuses, or other debug facilities are disabled
• device booted software from the normal primary source e.g. internal flash

The mode should never be not configured.

Every certificate in the DICE chain will need to be have the normal mode in order to be provisioned with production certificates by RKP.

Configuration descriptor

The configuration descriptor is a CBOR map with the following optional fields. If no fields are relevant, an empty map should be encoded. The key value range

-70000, -70999

Implementation-specific fields may be added using key values outside of the reserved range.

| Name              | Key    | Value type | Meaning                           |
| ----------------- | ------ | ---------- | ----------------------------------|
| Component name    | -70002 | tstr       | Name of firmware component / boot |
:                   :        :            : stage                             :
| Component version | -70003 | int / tstr | Version of firmware component /   |
:                   :        :            : boot stage                        :
| Resettable        | -70004 | null       | If present, key changes on factory|
:                   :        :            : reset                             :
| Security version  | -70005 | uint       | Machine-comparable, monotonically |
:                   :        :            : increasing version of the firmware:
:                   :        :            : component / boot stage where a    :
:                   :        :            : greater value indicates a newer   :
:                   :        :            : version                           :

HAL

The remote provisioning HAL provides a simple interface that can be implemented by multiple secure components that require remote provisioning. It would be slightly simpler to extend the KeyMint API, but that approach would only serve the needs of KeyMint, this is more general.

NOTE the data structures defined in this HAL may look a little bloated and complex. This is because the COSE data structures are fully spelled-out; we could make it much more compact by not re-specifying the standardized elements and instead just referencing the standard, but it seems better to fully specify them. If the apparent complexity seems daunting, consider what the same would look like if traditional ASN.1 DER-based structures from X.509 and related standards were used and also fully elaborated.

Please see the related HAL documentation directly in the source code at the following links:

• IRemotelyProvisionedComponent HAL
• ProtectedData
• MacedPublicKey
• RpcHardwareInfo
• DeviceInfo