OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

pkcs11 message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [pkcs11] CKM_SEAL_KEY


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 ?

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

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 ?

--
Darren J Moffat


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]