[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [pkcs11] Re: Updates to CKA_GLOBAL, CKM_CERTIFY_KEY and CKM_SEAL_KEY
On 6/4/2013 1:28 AM, Darren Krahn
wrote:
Maybe cryptographic module or security module. Device is too generic.
This was sort of what happened with the TPM, but the model here is quite a bit different. The TPM is tied to individual PCs which tend to be assigned to individuals and that has some interesting privacy concerns. That said, I think the TCG went off the rails on how they solved that problem. And you still have the concept of an EK (endorsement key) and EK cert (which *is* signed by the manufacturer). This is a first cut to get an EK and EK Cert into the device. If someone else wants to write up the TPM CreateIdentity and ActivateIdentity stuff later, that shouldn't be precluded.
This is the TPM EK, not a TPM AIK. And I think the AIK model is just weird.
I attached the wrong document. Here's the right one. This one expands the set of global objects and types of global objects.
Actually, the way you handle this is by limiting the mechanisms allowed for those keys. But I take your point that a certify key should only be used with the CKM_CERTIFY_KEY mechanism. I'll note this for change.
In the TPM, the public key is always part of the private key, and what you certify is the public data of the private key. In PKCS11 we only have a weak relationship between a public key object and a private key object, and I don't see any reasonable way to cryptographically link the two in a certify blob. What I want to do is certify that the private key associated with a specific public key is locked to a specific token (e.g. if I'm issuing a certificate, I'd really rather not issue one to a soft token). That means I need to certify data that is enforceably part of the private key. Hence CKA_PUBLIC_KEY_INFO (or rather the actual contents of that attribute) as the base data to be certified.
I hope not.
Ok.
Both are useful. The nonce one allows you to lock the certify operation to a particular point in time from the acceptors POV. It may be important to know that the key existed at one specific point in time. And it makes sense for the general contract for C_Sign.
Not necessary. The receiver has to get all of the data that was signed so that it can verify the signature. That includes the length of the object.
You mean like CKA_WRAP_TEMPLATE? :-)
Yup. I need to generate 10K session keys for various purposes. I can't store them in the HSM because I only have space for 1K keys. I want to make sure the keys are unusable after the session ends.
Mechanisms are generally tied to a particular class of object. This mechanism is a secret key mechanism. Mostly I can't see much use for a public key version of this for this specific type of mechanism.
Yes.
Later maybe. I touch on it briefly in the CKA_GLOBAL document, but that's a whole new set of things we don't do here. Mostly I'd add the whole measurement stuff as a new set of hardware class objects, and then add specific mechanisms to fold those measurements in.
Yes, but mostly the seal mechanism is less useful if you don't implement this. Use a normal wrapping mechanism instead.
|
Attachment:
pkcs11-global-values.docx
Description: application/vnd.openxmlformats-officedocument.wordprocessingml.document
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]