On 6/4/2013 2:28 PM, Chris Zimman
wrote:
I
have some concerns with the concept of CKM_SEAL_KEY. This
seems like very token specific behavior,
I'm pretty sure that is by design. By design, a key sealed with
this mechanism is only guaranteed to be restorable (unsealed) to the
token from which it originated. I consciously avoided specifying
the actual cryptographic mechanism used to seal and the format of
what was sealed and the format of the sealed blob for that reason.
and
also, it violates CKA_NEVER_EXTRACTABLE without informing
one that it’s been done.
Actually, no. It takes a conscious effort to bypass this - the only
way the normal controls are bypassed is if you use the CKA_GLOBAL
seal key (defined in the other document).
I’d want to get some guidance on if and how supporting this
might affect FIPS 140 evaluations.
This should be fine. A number of devices already do this
implicitly. And we're doing a device that uses this concept to deal
with storage. I also refer you to several TPMs which support this
and are FIPS140 certified.
In
terms of CKM_SEAL_KEY, which algo does it use? If I were
implementing this, I’d want something that does enc + auth
for example.
I'll add this guidance to the draft, but I won't specify the
mechanism. That's up to each and every token manufacturer to
select. (But CKA_AES_KEYWRAP_PAD might be a good choice... ) The
main reason for avoiding specifying this is that various regulatory
domains (e.g. countries) may have specific guidance on which types
algorithms can be used for this purpose.
Mike
