Evolution-x/hardware_interfaces
1
0
Fork 0
mirror of https://github.com/Evolution-X/hardware_interfaces synced 2026-02-01 22:04:26 +00:00
Code Issues Packages Projects Releases Wiki Activity

Merge "Allow P-384 and SHA-384 in RKP v3"

Browse Source
This commit is contained in:
Andrew Scull
2023-01-20 20:49:14 +00:00
committed by Gerrit Code Review
parent d2bbda8b32 5bdc9f92bb
commit 9132147d0a
3 changed files with 34 additions and 26 deletions
Download Patch File Download Diff File Expand all files Collapse all files

1
security/rkp/CHANGELOG.md
View File

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

27
security/rkp/README.md
View File

@@ -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

32
security/rkp/aidl/android/hardware/security/keymint/IRemotelyProvisionedComponent.aidl
View File

@@ -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);