Key Attestation

[peppelinux]

What's in the Key Attestation is defined by the device manufacturer ?

[peppelinux]

The Wallet instance has two types of keys:

(1) A set of Cryptographic Hardware Keys which it has throughout its lifetime. (2) Ephemeral keys used for the Wallet Attestation Requests

Does the OEM key specifies the use of X.509? We don't have any mention about this in the specs.

[peppelinux]

When we read "public key of the Wallet Hardware" the key is the "Cryptographic Hardware Key" ?

Does the Device Integrity Service (DIS) be able to extract the public key from the Wallet ?

Where in the text that the Wallet sends it in a message to the DIS?

[peppelinux]

The Wallet Instance sends hardware_key_tag to the Wallet Provider backend but the Wallet Provider stores Cryptographic Hardware keys. How is that possible ?

[peppelinux]

There are places in the text when we start using the abbreviation WSCD without a definition or a reference to a definition.

[cmarco0]

The Wallet Instance sends hardware_key_tag to the Wallet Provider backend but the Wallet Provider stores Cryptographic Hardware keys. How is that possible ?

The answer can be found in the "Wallet Instance Initialization and Registration" section, specifically in steps 8 and 9.

In step 8, the Device Integrity Service (DIS) creates a Key Attestation linked to the provided "challenge" and the public key of the Wallet Hardware.

In step 9, the Wallet Instance sends the previously created key attestation and the cryptographic hardware key tag to the Wallet Provider. This process eliminates the need to send the Wallet Hardware public key directly, as it is already included in the key attestation.

The hardware_key_tag serves as a reference or identifier for the corresponding Cryptographic Hardware key stored by the Wallet Provider. Therefore, the Wallet Provider can associate the received hardware_key_tag with the appropriate Cryptographic Hardware key in its storage.

[cmarco0]

What's in the Key Attestation is defined by the device manufacturer ?

The short answer is yes, but the Key Attestation argument must be expanded.

If we use the term Key Attestation as the Strongbox Keymaster feature, the answer is also yes and we can get more information about it from the official Andoid documentation https://developer.android.com/privacy-and-security/security-key-attestation#attestation-v4

If we improperly use the term "Key Attestation" for iOS, it's essential to specify that it's the DeviceCheck services that offer the key attestation feature. This feature is named "attestKey," and for further details, we can consult the official iOS documentation.

1. attestKey function: https://developer.apple.com/documentation/devicecheck/dcappattestservice/attestkey(_:clientdatahash:completionhandler:)
2. the output of attestKey is attestationObject: https://developer.apple.com/documentation/authenticationservices/aspasskeyregistrationcredential/4172659-attestationobject

[cmarco0]

The Wallet instance has two types of keys:

(1) A set of Cryptographic Hardware Keys which it has throughout its lifetime. (2) Ephemeral keys used for the Wallet Attestation Requests

Does the OEM key specifies the use of X.509? We don't have any mention about this in the specs.

Android During Key Attestation, you specify the alias of a key pair and retrieve its certificate chain, which you can use to verify the properties of that key pair. One of the steps to implement Key Attestation is to get a reference to the chain of X.509 certificates associated with the key that you want to attest. source:https://developer.android.com/privacy-and-security/security-key-attestation#attestation-v4

Then the Attestation Certificate, compliant with the X.509 standard, is the digital certificate used to attest to the validity of a cryptographic key, providing verifiable evidence of its properties and origin. source:https://source.android.com/docs/security/features/keystore/attestation#attestation-certificate

iOS After calling the function attestKey, it returns an attestationObject as a Base64 encoded string. The validation steps begin by getting a reference to the chain of X.509 certificates associated with the key that you want to attest. The X.509 array contains the intermediate and leaf certificates for App Attest, starting from the credential certificate in the first data buffer in the array (credcert). source: https://developer.apple.com/documentation/devicecheck/validating-apps-that-connect-to-your-server#Verify-the-attestation source (validation process): https://developer.apple.com/documentation/devicecheck/attestation-object-validation-guide

[cmarco0]

When we read "public key of the Wallet Hardware" the key is the "Cryptographic Hardware Key" ?

Does the Device Integrity Service (DIS) be able to extract the public key from the Wallet ?

Where in the text that the Wallet sends it in a message to the DIS?

To answer the first question: It is mentioned in the Wallet Instance Initialization and Registration section, specifically in Step 8. The reason why is written in this way is because the only pair of keys created and handled are the Cryptographic Hardware Keys for the Initialization and Registration of the Wallet Instance.

To answer the second question: The DIS is a service designed to attest to the authenticity and genuineness of a cryptographic key, app, or the phone itself. Therefore, it can extract the public key from the Wallet. By passing the key tag to the key attestation function, the DIS can extract the key.

To answer the third question: In the text, it is not specified that the Wallet sends the public key within a message directed to the DIS. In the Wallet Instance Initialization and Registration section, particularly in Step 7, the Wallet Instance must provide the Cryptographic Hardware Key Tag instead of the public key directly to acquire the Key Attestation.

[grausof]

These considerations should also be added: https://github.com/italia/eudi-wallet-it-docs/pull/339