Re: [pkcs11] pkcs11-global-objects.docx: CKA_GLOBAL

[Michael StJohns <msj@nthpermutation.com>]

There are three documents you need to look at:

 - the CKM_SEAL_KEY document which describes the mechanisms
- the CKA_GLOBAL document which describes the attribute
- and the not-submitted-yet-as-a-formal-proposal-but-was-the-second-part-of-CKA_GLOBAL document pkcs11-global-objects.docx (which is on the website) which describes a sample set of objects, include two types of seal key - a token seal key and a session seal key.   Please read that for the descriptions of these keys.

I had this mostly as one document, but it seemed to be too big of a bite for most of the WG participants, so it got broken down into stand alone items with CKA_GLOBAL being the first item in the dependency chain and with CKM_SEAL_KEY and parts of the pkcs11-global-objects document being second and third.

More below.

No.  It won't.  When you initialize zeroize a token, the previous seal keys are thrown away and any key material sealed by that seal key is no better than random bits.  When you re-initialize the token, you generate a new seal key - which basically CAN'T unwrap the previously sealed keys.

This is where I get confused.
I need more explanation here.

Q#4 (continue # from previous emails):

In pkcs11-cka-global.docx, you wrote:

" 1   Global Attribute Values

CKA_GLOBAL - CK_GLOBAL_TYPES

This attribute is used to identify objects that generally persist through reinitializations of individual tokens, but are created though token or driver action and not user action."

The statement, "objects (you meant: "wrapped objects") that generally persist through reinitializations of individual tokens", seems to have conflicts with your previous email which says, "When you initialize zeroize a token, the previous seal keys are thrown away".

the key word is "generally" and combined with "created through token or driver action and not user action"

A seal key is created automatically - a token seal key by the initialization of the token, a session seal key by the completion of a user or SO login.  They are destroyed automatically - the token seal key by zeroization of the token, the session seal key by closing the login session.  When destroyed, all objects sealed by those keys become no more than random strings of data as there is no longer any way to decrypt them.


Compare and contrast this to a "certify key" also defined in the document.  The certify key pair is created at token manufacture, the public key of the key pair is bound into a certificate and that certificate is installed on the token as a global object also at manufacture.  The user can use the certify key to sign keys (CKM_CERTIFY_KEY mechanism) but for no other purpose.  The key can't be created, deleted, copied or changed by user action.

The "thrown away" and "persist through reinitializations" are conflicting each other.

If the seal key is being "thrown away", how can we unwrap the "wrapped objects" after reinitialization of token ?
If we cannot, how can those "wrapper objects" "persist through reinitializations" ?

It is very important if you could draw two (2) state diagrams to explain the seal key life cycle:

a) when CKA_GLOBAL != CKV_NOT_GLOBAL
    when was the seal key get created, where stored, and destroyed ?

Read pkcs11-global-objects.docx.

b) when CKA_GLOBAL == CKV_NOT_GLOBAL
    when was the seal key get created, where stored, and destroyed ?

There is no such seal key.

Q#5:
How many seal key can you have per token ?

My intent is to have 3 - two of which have been partially described in pkcs11-global-objects.docx.  The third I'll hold off on describing unless and until CKM_SEAL_KEY goes forward. (or I may re-work the general description slightly).

If you can have more than one, how do you know which seal key is used to wrap which object ?

It's the responsibility of the client using C_WrapKey to track which key sealed which object, and to understand the seal key life cycles.  E.g. if it seals using the token seal key for token A, then it should store the opaque object with some sort of tag that indicates which token.  If it seals using the session seal key for Token A it should clean up all the opaque objects once the session is closed.

Thanks!

-- 

Best,
Oscar