Re: ISSUE-17: Key Attributes - Proposed resolution

On Tue, Sep 4, 2012 at 10:30 AM, Mitch Zollinger <mzollinger@netflix.com> wrote:
> On 9/4/12 2:04 AM, Vijay Bharadwaj wrote:
>
> We would like to see a standard way to identify a symmetric key, just as we
> have a standard way to identify a public & private key pair.
>
> Would something like PKCS#11's CKA_CHECK_VALUE suffice?
>
>
> Google says:
>
> CKA_CHECK_VALUE: The value of this attribute is derived from the key object
> by taking the first three bytes of the ECB encryption of a single block of
> null (0x00) bytes, using the default cipher associated with the key type of
> the secret key object.
>
> There are two problems I see with this approach:
> 1. 3 bytes is not enough to uniquely identify a unique device key, when
> there are 100s of millions (billions, perhaps?) of connected devices
> currently and that number can only grow.
> 2. Even if the number of bytes were increased, the uniqueness is only as
> good as the random entropy used to create the key. Assuming all of the
> device manufacturers use good HW generated random numbers and don't abuse a
> PRNG initialized with time of day, the likelihood of collision becomes the
> answer to the birthday problem. I don't think that's good enough ;)
>
> Mitch

Google the search engine, not Google the participants ;-)

Why not just CKA_ID? Which is to say the same as / no different than
the Key.id attribute (note: Specifically in the context of
*pre-provisioned* keys. *Discovered* keys are likely different)

Nothing in the spec, normative or informative, prevents an
implementation from exposing some fixed, meaningful ID as the key ID,
provided it meets the criteria of unique (to the key) and opaque (to
the application - which is to say - its just bytes)

As far as PKCS#11 is concerned, the CKA_ID is a common attribute for
all Key objects, which is a byte array that is the "key identifier for
key"

Quoth the Spec:
"The  CKA_ID attribute is intended as a means of distinguishing
multiple publickey/private-key pairs held by the same subject (whether
stored in the same token or not).  (Since the keys are distinguished
by subject name as well as identifier, it is possible that keys for
different subjects may have the same CKA_ID value without introducing
any ambiguity.)

It is intended in the interests of interoperability that the subject
name and key identifier for a certificate will be the same as those
for the corresponding public and private keys (though it is not
required that all be stored in the same token). However, Cryptoki does
not enforce this association, or even the uniqueness of the key
identifier for a given subject; in particular, an application may
leave the key identifier empty."

However, as you can see, even PKCS#11 does not require that symmetric
keys have any form of unique identifier, and if arguably one of the
most widely implemented crypto APIs can do get away with it, I feel
fairly confident that we could too.

Received on Wednesday, 5 September 2012 01:59:58 UTC