tequilaOS/platform_hardware_interfaces
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity
platform_hardware_interfaces/security/rkp/CHANGELOG.md

2.5 KiB
Raw Blame History

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.