My comments are for the
CKM_SEAL_KEY, the document ckm-seal-key.docx.
It's a good idea to have a standard API to offload the keys from the
token with benefits for:
1) key backup at application level (protecting from hardware
failure) and
2) support for unlimited number of keys
At least one vendor I know of essentially implements the ideas of
the CKM_SEAL_KEY by default. The token keys are always stored in the
file system as opaque blobs. It's easy to see what makes a key by
taking the snapshot of this directory before and after the key
generation. For other vendors there is an issue of supporting a
large number of user keys and the mechanism like CKM_SEAL_KEY can
accomplish this in a generic way.
Because
C_WrapKey
and C_UnWrapKey with the seal key require authenticated
session and they work on content that is not chosen plaintext, the
environment doesn't offer new attacks on the seal key. Assuming the
algorithm for internal packaging of the key is leaked, oracle
attacks will apply here to the C_UnWrapKey. Vendors are better off
with the MAC included in the output blob.
