Donate to e Foundation | Murena handsets with /e/OS | Own a part of Murena! Learn more

Commit 0fa242c3 authored by Andrew Scull's avatar Andrew Scull Committed by Automerger Merge Worker
Browse files

Merge "Allow P-384 and SHA-384 in RKP v3" am: 9132147d 

Original change: https://android-review.googlesource.com/c/platform/hardware/interfaces/+/2394582



Change-Id: Ic18fe8803e3f59cf614af88b19758a8e4b4f6ad3
Signed-off-by: default avatarAutomerger Merge Worker <android-build-automerger-merge-worker@system.gserviceaccount.com>
parents 116ddaf0 9132147d

security/rkp/CHANGELOG.md

+1 −0
Original line number Diff line number Diff line
@@ -41,6 +41,7 @@ This document provides an exact description of which changes have occurred in th 
      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.

* 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.

security/rkp/README.md

+12 −15
Original line number Diff line number Diff line
@@ -172,31 +172,28 @@ This document uses: 


*   ECDSA P-256 for attestation signing keys;

*   Remote provisioning protocol signing keys:

  *  Ed25519 / P-256

  *  Ed25519 / P-256 / P-384

*   ECDH keys:

  *  X25519 / P-256

*   AES-GCM for all encryption;

*   SHA-256 for all message digesting;

*   HMAC-SHA-256 for all MACing; and

*   HKDF-SHA-256 for all key derivation.

*   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 Secure Elements (SE) do not currently offer support for curve

25519, we are allowing implementations to instead make use of EC P-256 for

signing and ECDH. To put it simply, the device unique key pair will be a P-256

key pair for ECDSA instead of Ed25519, and the ProtectedData COSE\_Encrypt

message will have its payload encrypted with P-256 ECDH key exchange instead of

X25519.

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 or P-256 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.

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.



### Testability

security/rkp/aidl/android/hardware/security/keymint/IRemotelyProvisionedComponent.aidl

+21 −11
Original line number Diff line number Diff line
@@ -342,7 +342,7 @@ interface IRemotelyProvisionedComponent { 
     *

     * ; COSE_Sign1 (untagged)

     * SignedData<Data> = [

     *     protected: bstr .cbor { 1 : AlgorithmEdDSA / AlgorithmES256 },

     *     protected: bstr .cbor { 1 : AlgorithmEdDSA / AlgorithmES256 / AlgorithmES384 },

     *     unprotected: {},

     *     payload: bstr .cbor Data / nil,

     *     signature: bstr      ; PureEd25519(CDI_Leaf_Priv, SignedDataSigStruct<Data>) /
@@ -352,7 +352,7 @@ interface IRemotelyProvisionedComponent { 
     * ; Sig_structure for SignedData

     * SignedDataSigStruct<Data> = [

     *     context: "Signature1",

     *     protected: bstr .cbor { 1 : AlgorithmEdDSA / AlgorithmES256 },

     *     protected: bstr .cbor { 1 : AlgorithmEdDSA / AlgorithmES256 / AlgorithmES384 },

     *     external_aad: bstr .size 0,

     *     payload: bstr .cbor Data / nil,

     * ]
@@ -384,7 +384,7 @@ interface IRemotelyProvisionedComponent { 
     * ; after the first describe a link in the boot chain (e.g. bootloaders: BL1, BL2, ... BLN)

     * ; Note that there is no DiceChainEntry for UDS_pub, only a "bare" COSE_key.

     * DiceCertChain = [

     *     PubKeyEd25519 / PubKeyECDSA256,  ; UDS_Pub

     *     PubKeyEd25519 / PubKeyECDSA256 / PubKeyECDSA384,  ; UDS_Pub

     *     + DiceChainEntry,                ; First CDI_Certificate -> Last CDI_Certificate

     *                                      ; Last certificate corresponds to KeyMint's DICE key.

     * ]
@@ -392,16 +392,17 @@ interface IRemotelyProvisionedComponent { 
     * ; This is the signed payload for each entry in the DICE chain. Note that the "Configuration

     * ; Input Values" described by the Open Profile are not used here. Instead, the DICE chain

     * ; defines its own configuration values for the Configuration Descriptor field. See

     * ; the Open Profile for DICE for more details on the fields. SHA256 and SHA512 are acceptable

     * ; hash algorithms. The digest bstr values in the payload are the digest values without any

     * ; padding. Note that for SHA256, this implies the digest bstr is 32 bytes. This is an

     * ; intentional, minor deviation from Open Profile for DICE, which specifies all digests are

     * ; 64 bytes.

     * ; the Open Profile for DICE for more details on the fields. SHA256, SHA384 and SHA512 are

     * ; acceptable hash algorithms. The digest bstr values in the payload are the digest values

     * ; without any padding. Note that this implies that the digest is a 32-byte bstr for SHA256

     * ; and a 48-byte bstr for SHA384. This is an intentional, minor deviation from Open Profile

     * ; for DICE, which specifies all digests are 64 bytes.

     * DiceChainEntryPayload = {                    ; CWT [RFC8392]

     *     1 : tstr,                                ; Issuer

     *     2 : tstr,                                ; Subject

     *     -4670552 : bstr .cbor PubKeyEd25519 /

     *                bstr .cbor PubKeyECDSA256,    ; Subject Public Key

     *                bstr .cbor PubKeyECDSA256,

     *                bstr .cbor PubKeyECDSA384,    ; Subject Public Key

     *     -4670553 : bstr                          ; Key Usage

     *

     *     ; NOTE: All of the following fields may be omitted for a "Degenerate DICE Chain", as
@@ -422,7 +423,7 @@ interface IRemotelyProvisionedComponent { 
     * ; Each entry in the DICE chain is a DiceChainEntryPayload signed by the key from the previous

     * ; entry in the DICE chain array.

     * DiceChainEntry = [                            ; COSE_Sign1 (untagged)

     *     protected : bstr .cbor { 1 : AlgorithmEdDSA / AlgorithmES256 },

     *     protected : bstr .cbor { 1 : AlgorithmEdDSA / AlgorithmES256 / AlgorithmES384 },

     *     unprotected: {},

     *     payload: bstr .cbor DiceChainEntryPayload,

     *     signature: bstr ; PureEd25519(SigningKey, DiceChainEntryInput) /
@@ -433,7 +434,7 @@ interface IRemotelyProvisionedComponent { 
     *

     * DiceChainEntryInput = [

     *     context: "Signature1",

     *     protected: bstr .cbor { 1 : AlgorithmEdDSA / AlgorithmES256 },

     *     protected: bstr .cbor { 1 : AlgorithmEdDSA / AlgorithmES256 / AlgorithmES384 },

     *     external_aad: bstr .size 0,

     *     payload: bstr .cbor DiceChainEntryPayload

     * ]
@@ -458,7 +459,16 @@ interface IRemotelyProvisionedComponent { 
     *     -3 : bstr                    ; Y coordinate, big-endian

     * }

     *

     * PubKeyECDSA384 = {               ; COSE_Key

     *     1 : 2,                       ; Key type : EC2

     *     3 : AlgorithmES384,          ; Algorithm : ECDSA w/ SHA-384

     *     -1 : 2,                      ; Curve: P384

     *     -2 : bstr,                   ; X coordinate

     *     -3 : bstr                    ; Y coordinate

     * }

     *

     * AlgorithmES256 = -7

     * AlgorithmES384 = -35

     * AlgorithmEdDSA = -8

     */

    byte[] generateCertificateRequestV2(in MacedPublicKey[] keysToSign, in byte[] challenge);