SmartCard-HSM Supports Key Attestation

[CardContact]

The SmartCard-HSM token supports Key Attestation using CV-Certificate Requests as defined in TR-03110.

Whenever new key pairs (EC or RSA) are generated on a device, the public key is embedded in CV-REQ and signed by the Device Authentication Private Key. The resulting CV-REQ can be processed by most CVC libraries or other SmartCard-HSMs.

Each device has a Device Authentication EC Key Pair that is certified by the Device Issuer CA during production. The Device Issuer CA itself is certified by the SmartCard-HSM Root CA. The Root CA certificate is placed as trust-anchor in the device during production, so that peering SmartCard-HSMs can validate each others public keys.

The key attestation is the basis for P2P ECDH, that is the cryptographic basis for XKEK Key Domains in which key material can migrated between authorized devices.

[primetomas]

@CardContact : I don't know why notifications from GitHub hasn't worked. If you can't make a PR, can you provide information here for what to put in each cell in the table. Then I can easily add it.

[CardContact]

Created #20 to add the SmartCard-HSM to the list.

For nerds like us, it contains a link to a deep dive into the bits and bytes of remote key attestation in a SmartCard-HSM.

[primetomas]

Great PR. Can I convince you to make a PR for a validation page as well? Looks like you have all the information ready in your documentation? https://pkic.org/remote-key-attestation/validation/ https://github.com/pkic/remote-key-attestation/tree/main/validation

[CardContact]

I can certainly do this.

Is the expectation, that a user can do validation on the command line ?

In that case, I'd propose to carry the card generated CVC in a PKCS#10 extension and have some Java CLI to parse the request, validate the CVC and match the public keys.

That will take a couple of days though...

[primetomas]

At this time there is no standard for carrying the generated evidence in a CSR, so this is out of scope. You can look at the existing articles under validation for what I believe is the expectation today:

• CSR and attestation evidence delivered separately
• parse and validate the attestation
• match the public keys

I.e. ignoring exactly how the attestation is delivered. Once the IETF draft on CSR attestation moves to RFC, that can be worked in at some time.