Re: [pkcs11] CKM_SEAL_KEY

[Michael StJohns <msj@nthpermutation.com>]

On 7/10/2013 5:17 AM, Darren J Moffat wrote:
> On 07/03/13 22:14, Michael StJohns wrote:
> > How about:  Token has space for 50 keys. Application needs to use 1000
> > keys.  It's willing to manage the loading and unloading as necessary.
>
> For this use case why do we need the PKCS#11 consumer involved in that 
> at all ?

"Why" questions are some of the most insidious and useless ones for 
getting work done in standards.  And for CKM_SEAL_KEY this question is 
generally moot given the results of the ballot.  But there are a lot of 
reasons where this makes sense - none, some or all may apply to any 
given implementation.

1) The PKCS11 key database model sucks big time.  Retrieval and 
management of large numbers of keys is painful using PKCS11.  (And more 
than problematic if the vendor doesn't use stable handle values - 
seriously, having to do a C_FindObject for every key retrieval?).

2) The PKCS11 spec has been applied to the complete range of tokens - 
from smart card based on up to big iron.  At the small end, the token 
you're using may not be anywhere near where you want to store the 
wrapped keys.  (Consider that one useful approach - not EVER 
contemplated by PKCS11 - is the storage in the cloud of wrapped keys).

3) The HSM vendor's remit is to make a general purpose device.  The 
consumer's remit is to make his stuff work really well.   These two 
items sometimes come into conflict.  Many vendors then provide an SDK to 
get around the limitations of PKCS11 (and incidentally void all the 
FIPS140-2 guarantees).  This approach appears less than ideal.



> The Oracle/Sun CA-6000 card is an example of such a system.  The 
> hardware can only have in memory a small number of keys but it 
> provides the illusion of unlimited space.
>
> It does this because the device driver and operating system daemon 
> that sit behind the PKCS#11 interface deal with loading and unloading 
> the PKCS#11 object content (data and metadata) from an data blob 
> encrypted with a persistent master key that lives only side the FIPS 
> 140-2 @ Level 3 boundary (and goes away when you do a master reset).

There's a vendor I've worked with that has space for about 2400 keys in 
non-volatile storage inside the secure perimeter of their HSM PCIe 
card.  They use a linear search/insertion model to manage the key 
database.  I watched the thing come to a grinding halt as I got near the 
limit after inserting/generating 2200 keys without deletion.

For your particular card, it appears to have been built as an SSL 
accelerator rather than a general purpose HSM.   My guess is the key 
store management is oriented around that approach only and probably 
wouldn't scale usefully past a certain point.  It's hard to tell from 
the spec-sheet.  And my guess as well is that there is a vendor specific 
call to the actual HSM hardware that pretty much does what CKM_SEAL_KEY 
does, it just hides what's happening from the user in possibly a 
non-useful way.

I needed space for about 200 million symmetric keys on a single token. I 
wanted to ensure those keys were locked to that HSM/token. I couldn't do 
that with the current PKCS11 spec and the vendor never contemplated 
anyone needing that many keys.  [For why I couldn't do this - consider - 
how do you mark a secret symmetric key "TRUSTED" using PKCS11 so that 
CKA_WRAP_WITH_TRUSTED usefully applies?]

> I'm fairly sure I've seen other vendors do a very similar thing.
>
> > Application generates the keys on the token (or derives them using
> > something like ECDH), seals them (exporting the encrypted blob), and
> > then deletes the generated key.  Later, when it needs the key, it
> > unseals it from the encrypted blob creating a new key on the token.
>
> Who is "it" in this case ?  The Application or the PKCS#11 
> implementation that the library is calling ?

The application.  Or rather the application using PKCS11 to accomplish 
those actions.


Let me run a taxonomy through - CKM_SEAL_KEY is (3d) below:


1) HSM with no backup mechanism
  -- keys constrained to the internal storage (and to whatever PKCS11 
wrapping mechanisms apply)
  -- typically the model for a smart card, although sometimes (2) applies.
  -- may apply to some high security HSMs where key rollover is 
possible for the application.

2) HSM with an administrative backup mechanism
  -- the token key store is encrypted under a backup key.  The back up 
of the token is either a vendor specific PKCS11 extension, or a 
out-of-band non-PKCS11 action.  Generally, the entire token store is 
backed up, not the individual key.  Administrative controls vary between 
vendors.

3) HSM with external key store
  -- HSM has small/finite internal key store, but has a mechanism for 
programmatic wrapping and storage of keys outside the internal store
   3a) HSM has support for an external key store managed by the HSM 
driver and HSM
    -- completely transparent to user, but may not meet user needs due 
to size, performance, key management etc.
   3b) HSM has support for an external key store, but all managed by 
the client using non-PKCS11 mechanisms
    --- This is the TPM model mostly.  PKCS11 can wrap around this, but 
the TPM model allows a true seal key where PKCS11 doesn't and TPM 
doesn't enforce all of the PKCS11 attributes on the unwrapped key.
   3c) HSM has support for an external key store, but managed by the 
client using PKCS11 mechanisms - ad hoc
   --- This is the current model using C_WrapKey, but breaks when you 
try an enforce policy on wrapped keys when you unwrap them.
   3d) HSM has support for an external key store, but managed by the 
client using PKCS11 mechanisms - defined so the exact key you wrapped is 
returned when you unwrap.


All of the above are valid models, but few if any vendors I've found 
even do (3a) leaving the key management to the user.  An implementation 
of a (3d) model means that I don't have to worry about the internals of 
the token, I don't have to write separate code to deal with different 
vendors idiosyncrasies and I don't ever have to worry about running out 
of non-volatile storage in the token.

Later, Mike