On 05/05/2015 08:42 AM, Andrew Cagney wrote:
Hi,I'm cleaning up some code (it has a long history) that, among other things, computes IKE's PRF (hmac) and PRF+ (key derivation function). The computation involves the use of PK11_Derive to perform lots of concatenation, padding, xoring, and hashing(1). To get an idea, the PRF+ function (which uses PRF, which uses HASH) is described in the RFC as: prf+ (K,S) = T1 | T2 | T3 | T4 | ... where: T1 = prf (K, S | 0x01) T2 = prf (K, T1 | S | 0x02) T3 = prf (K, T2 | S | 0x03) T4 = prf (K, T3 | S | 0x04) For specifics: PRF http://tools.ietf.org/html/rfc2104 PRF+ http://tools.ietf.org/html/rfc7296#page-48 The code works - at least in the sense that it computes the same values as the test vectors found on http://csrc.nist.gov/groups/STM/cavp/index.html The thing I'm not sure about is how the code is using PK11_Derive "target" parameter for its intermediate(2) operations. For instance, when doing concatenation and xoring, the "derive" parameter might have sane with values like: CKM_CONCATENATE_DATA_AND_BASE CKM_CONCATENATE_BASE_AND_DATA CKM_CONCATENATE_BASE_AND_KEY CKM_XOR_BASE_AND_DATA while the *target* parameter gets values like: CKM_EXTRACT_KEY_FROM_KEY CKM_ SHA1_KEY_DERIVATION (when BASE_AND_KEY) CKM_CONCATENATE_BASE_AND_DATA Similarly, when performing the hash using PK11_Derive, the "derive" parameter is something sane like: CKM_SHA1_KEY_DERIVATION yet the *target* parameter is: CKM_CONCATENATE_BASE_AND_KEY Does any of this matter? Is there a preferred value? (If there is I could simplify some code further). And are there any, mumble mumble, security, mumble, mumble, implications?
The target Mechanism is the operation you are going to use the target key for, It shouldn't match the mechanism used to derive the key. It is basically used to set the appropriate key type and flags on the resultant key. Example psuedo code:
key1 = derive(keybase, mech=CKM_XOR_BASE_AND_DATA, target=CKM_SHA1_KEY_DERIVATION, data);
key2 = derive(key1, mech=CKM_SHA1_KEY_DERIVATION, target=CKM_AES_CBC, NULL); decrypt(key2, mech=CKM_AES_CBC, input, output);Ideally you should try to keep it consistent with how your are planning on using the key, but in practice as long as the key is basically the same kind of key, the extact value of target is not necessary (You can use a key generated with target CKM_AES_CBC on an CKM_AES_ECB operation, for instance). Target may also be used to try to set the appropriate key length (if key length isn't supplied).
Most of these key derive operations either ignore keyType or take CKK_GENERIC_SECRET keys, so bad things aren't likely to happen if you mix up target a bit, but certainly the final resultant keys should target the proper crypto targets our your decrypt operation will fail with an inappropriate key type.
bob
Andrew PS: If there's documentation I've missed, please let me know :-) -- (1): It's computing the hash using calls like PK11_Derive (derive=CKM_SHA1_KEY_DERIVATION) rather than the lower level hash interface. This is because PK11_Derive returns a PK11SymKey, hopefully keeping the result secure. (2): Once the keying material has been created things become more sane, for instance when extracting (CKM_EXTRACT_KEY_FROM_KEY) an AES_GCM key the target is CKM_AES_GCM; and when extracting IV that ends up on the wire the target is CKM_VENDOR_DEFINED.
smime.p7s
Description: S/MIME Cryptographic Signature
-- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
