|
On 7/3/2013 5: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.
Not part of this proposal. No attributes are added or deleted
during the wrap unwrap process. If this attribute is present prior
to wrapping it will be present after unwrapping. The creation of
such an attribute is outside the scope of this proposal.
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.
Not part of this proposal and not really applicable to all use
cases. In this particular case, the application twiddling with the
keys is probably going to have its own way of keeping track of them
(e.g. handle inside the token upon creation, some database handle
when it stores the wrapped key externally).
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.
No. Or probably not. This would go with the description of the
seal keys which is another document.
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
|