Re: [pkcs11] Re: Updates to CKA_GLOBAL, CKM_CERTIFY_KEY and CKM_SEAL_KEY

[Andrey Jivsov <Andrey_Jivsov@symantec.com>]

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.