security/rkp/CHANGELOG.md

# Remote Provisioning Changelog

This document provides an exact description of which changes have occurred in the
`IRemotelyProvisionedComponent` HAL interface in each Android release.

## Releases
* **Android S (12):** IRemotelyProvisionedComponent v1
* **Android T (13):** IRemotelyProvisionedComponent v2
* **Android U (14):** IRemotelyProvisionedComponent v3

## IRemotelyProvisionedComponent 1 -> 2
* DeviceInfo
  * Most entries are no longer optional.
  * `att_id_state` is now `fused`. `fused` is used to indicate if SecureBoot is enabled.
  * `version` is now `2`.
  * `board` has been removed.
  * `device` has been added.
* RpcHardwareInfo
  * `uniqueId` String added as a field in order to differentiate IRPC instances on device.

## IRemotelyProvisionedComponent 2 -> 3
* The RKP HAL now builds separately from KeyMint.
  * The HAL remains under the `android.hardware.security.keymint` package for
    compatibility with previous releases. ABI compatibility requires this.
  * Dependencies on the RKP HAL must add a dependency on
    `"android.hardware.security.rkp"` generated code (instead of
    `"android.hardward.security.keymint"`).
* ProtectedData has been removed.
* DeviceInfo
  * `version` has moved to a top-level field within the CSR generated by the HAL.
* IRemotelyProvisionedComponent
  * The need for an EEK has been removed. There is no longer an encrypted portion of the CSR.
  * Keys for new CSR format must be generated with test mode set to false, effectively removing test
    mode in the new CSR flow.
  * The schema for the CSR itself has been significantly simplified, please see
    IRemotelyProvisionedComponent.aidl for more details. Notably,
    * the chain of signing, MACing, and encryption operations has been replaced with a single
      COSE_Sign1 object.
    * CertificateType has been added to identify the type of certificate being requested.
    * The structure has been composed to enable a clear split between what is required to validate a
      payload and the implementation-defined payload itself. This is done by creating a typed
      `AuthenticatedRequest<T>` object representing the top level data required to authenticate
      the data provided in the payload, `T`.
  * The new CSR format supports P-384 signing keys and SHA-384 hashes in the DICE chain.
  * The component version can now be either an int or a string.
* RpcHardwareInfo
  * `supportedNumKeysInCsr` added to report the maximum number of keys supported in a CSR.
  * `supportedEekCurve` is no longer used, due to the removal of the EEK from the scheme.