Michael,
One more question, what if the private key that you are trying to
wrap with CKM_SEAL_KEY is NOT EXPORTABLE due to the hardware
restriction, what can you do ?
I know that during key generation on "some types" of crypto chip,
there is an option to mark the key as exportable.
But, what if the key had been generated with exportable=false, what
do you do in this case ?
Thanks!
Best,
Oscar
On 07/ 3/13 02:57 PM, Oscar K So Jr. wrote:
Thanks Michael.
Your example is actually a real world example which I experienced
at two of my previous companies - TWO TIMES!!!
The security crypto chip (cannot disclose the chip company name,
but, it's a famous French company that makes smartcard chip) in
their USB crypto devices for
our "retail" customers (believe it or not) have spaces for only
FOUR (4) RSA key pairs. :-(
The rest of the spaces were hidden from PKCS #11, and it has keys
used for security channel communication between the host (PC) and
the device.
For nowadays computing environment, each person has a few emails,
and many certificates. FOUR(4) is not enough!!!!
And, your solutions is helpful in this case.
May I suggests a few things:
SUGGEST_01:
To address Stef's question about the uniqueness, can't we set
CKA_ID for key pairs as:
CKA_ID = SHA1(wrapped(byte_array))
Mozilla Firefox is setting CKA_ID this way.
SUGGEST_02:
If you need to show this in GUI for user:
Then, attach (or, associate) a CKA_LABEL for such wrapped key
since you may want to display it for the user in the GUI level.
As you already know, most HSM refers to keys in terms of its
CKA_LABEL.
SUGGEST_03:
[it's just a suggestion or idea - I got this idea from Oracle
Database Transparent Data Encryption (TDE)]
Generate a Master Encryption Key (MEK, 1st level key, a symmetric
key) in the crypto chip, and use it to wrap a 2nd level key which
in turns wrap your sensitive byte array outside the chip.
Plus, here is an advantage, when the key expires (i.e. certificate
expire), or, compromised, or simply due to SOX/PCI requirements
(where a key must be rotated every 12 months for example),
you may have an easier life with just MEK inside the chip.
And,
Finally, as for the "password" comment below, if you have seen the
PKCS #15 v1.1 spec, a Password is described in Section 6.8.2 "Pin
objects".
Also, applies to biometric info.
Best,
Oscar
On 07/ 3/13 02:14 PM, Michael StJohns wrote:
On 7/3/2013 3:07 AM, Oscar K So Jr.
wrote:
Thanks Michael.
Q#3 (continue # from previous emails):
I tried to dig through the old emails, but I could not find
the "Use Case" example for CKM_SEAL_KEY.
AFAIK that's usually not included with a mechanism description.
But there is a code example.
But, here is a one example that I can think of (if I
understand this correctly):
Backing up a wrapped RSA private key, a password on a USB
stick for temporary use, and seal it with this CKM_SEAL_KEY
mechanism.
This wrapped RSA private key is by no means to be exported to
anywhere outside of the token.
I'm not sure actually what the question is? If you're saying
this is one example of a use case, I'm not sure what the
password comment is about.
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. 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.
Mike
Best,
Oscar
--
Best,
Oscar
--
Best,
Oscar
|