Dealing with crypto module device certificates in PKCS #11

[Anders Rundgren <anders.rundgren@telia.com>]

Hi,

I have worked extensively with crypto modules housing specific device IDs which are used for creating attested key generations which are nice since current HSMs when used in auto-renewal scenarios in no way can assert that a renewed key actually resides in the HSM!

Anyway, a problem on the HSM side is that you may need new APIs or mechanisms that wouldn't pass existing wrappers such as Oracle's P11 wrapper in JDK.  If you don't think "hacks" are too bad, I believe this could fit in PKCS #11 and associated wrappers by introducing a "virtual device key object" with a fixed name which is automatically created during the first run through self-signing or created in a specific device personalization/certification process.

The "virtual device key object" would be able to "C_Sign" where the input data would be a new "key generation request" and the result would be an equally newly defined "attested public key".  Any other operations and input data would be forbidden since an attestation key must only attest information it knows about!

Since Google have defined device attestation as _mandatory_ in their coming U2F (Universal Two Factor) authentication scheme for consumers, my guess is that this concept is going to be a de-facto standard.

CKM_CERTIFY_KEY is of course a cleaner solution but from a usage perspective it is no better than the kludge I suggest; it will only move the time-line further away on the horizon.

It would also be cool mixing this with key-wrapping so that you would not only get a certified public key, but a wrapped private key as well.  This is what my own "home-brewed" scheme does at least.

Just my 2 öres.

Cheers
Anders