RE: [pkcs11] Key Import proposal update

Thanks Bob.

Sorry for the delay . Some clarifications below

Doron

-----Original Message-----

From: Robert.Burns@thalesesec.com

Sent: Wednesday, May 29, 2013 3:50 PM

To: 'Cohen, Doron'

Subject: RE: [pkcs11] Key Import proposal update

Doron,

>I like the proposal and just have a couple of questions/comments:

> 1) At the risk of overcomplicating things, should we be also adding the OAEP parameters encoded in the wrapped result? It would certainly make things

> easier on the receiver of the key blob, but at the risk of complexity in the encoding of the data, as well as potentially requiring an authentication (MAC)

> over the encoded data, which doesn't have a real easy/clean solution on first blush. But just curious about this one as other standards (such as CMS) do

> encode the OAEP parameters as part of their 'envelopes', so not sure what would be the best option for this solution. Was this considered?

[Doron Cohen] While encoding the OAEP parameters in the wrapped result is possible - but I prefer to avoid it. The main motivation was to keep

the wrapped result simple and there are a bunch of issues around integrity and data encoding that we should avoid . I also believe Keeping the

OAEP parameters as part of the parameters also keeps it more consistent with the rest of the specification

> 2) What should be the technique for disambiguating the case where the caller to C_UnwrapKey() provides an object attribute template, and the

> encrypted key contains Attributes in the PrivateKeyInfo structure? My opinion is that an error should be thrown and allow the caller decide what

> to do, but that's a bit complicated because the caller then has no idea what the actual attributes might be, because they are encrypted.

[Doron Cohen] I agree, error should be thrown . Any ambiguity may lead to security weakness/exploit

> 3) Given that there are now 3 keys involved in unwrapping, (instead of two), is there any need/desire to deal with the ambiguities in the return codes;

> meaning, some error codes refer to the wrapping key, and others to the wrapped key -- in this case, we have one unambiguous unwrapping key (the

> RSA private key), one unambiguous unwrapped key (the object in the PrivateKeyInfo struct), but then one very confusing AES key which is both an

> unwrapping key, and an unwrapped key? Seems like errors in unwrapping these objects might result in confusing messages. For example, if I try to

> unwrap one of these keys and get a CKR_WRAPPED_KEY_INVALID, what does it indicate? That my RSA wrapped key was bad (let's say a transmission

> error?) or that my key I really want unwrapped is bad somehow?

[Doron Cohen] Point taken . I agree, there should be a unique error to indicate the error is in the in unwrapping the transient AES key rather than the

CKR_WRAPPED_KEY_INVALID.

>4) Just to conform to other parts of the spec, we should probably refer to the PrivateKeyInfo structures consistently to avoid ambiguities, (e.g. "For

> wrapping, a private key is BER-encoded according to PKCS #8's PrivateKeyInfo ASN.1 type." -- see Section 12.6 for examples).

[Doron Cohen] Makes sense .

>5) Finally, I do like the security attributes of using RSA PKCS OAEP for wrapping an AES key, and then the AES_KEY_WRAP_PAD for using the AES

> key for transport, but something is bugging me, although I can't put my finger on something specific. And that is the fact that there is no explicit

> cryptographic binding between the OAEP wrapped key and the AES wrapped key. Sure, there is an implicit link in that the OAEP and AES Key Wrap

> have intrinsic 'MAC's built-in, but it just *feels* like the lack of an explicit link between the two makes it somehow 'less strong'. Again, not saying it

> is bad, just that it *feels* like we're leaving ourselves exposed here. Anyone else have an opinion on this?

[Doron Cohen] I wanted to get our cryptographer comment on that point and his view is this is fine cryptographically – “ There is a proof that

if you use a CCA-secure scheme for RSA to encrypt a symmetric key, and then a CCA-secure symmetric scheme to encrypt the message (in our

case another key) then the result is CCA secure. (CCA security means "chosen-ciphertext security" and it guarantees security against padding

oracle attacks.)” . So it looks like we should be fine .

> Finally, I hate to beat this drum again, but this solution is of course relying upon DER/BER encoding -- perhaps this is a discussion for a separate

> thread, but perhaps we should be considering alternative encoding methods which are easier to document and implement?

[Doron Cohen] I agree this should be a separate thread. I am ok with adapting the encoding recommendation in this proposal to whatever is agreed

Thanks,

Bob

pkcs11 message