CT-KIP Magnus Nyström, RSA Security 23 May 2005

Overview A client-server protocol for initialization (and configuration) of cryptographic tokens —Intended for general use within computer and communications systems employing connected cryptographic tokens Objectives: —To provide a secure and interoperable method of initializing cryptographic tokens with secret keys —To avoid, as much as possible, any impact on existing cryptographic token manufacturing processes —To provide a solution that is easy to administer and scales well —To provide a solution which does not require private-key capabilities in tokens, nor the existence of a public-key infrastructure

Principles of operation

Key generation Note: The order of the parameters changed in draft 2 (proposal from Laszlo Elteto, Safenet) CT-KIP-PRF —Three inputs: Secret, Variable data, Output length —Output: Pseudorandom string of desired length Defined as “black box”, two example realizations in specification Key generation: K TOKEN = CT-KIP-PRF(R C, “Key generation” || k || R S, 16) R C = Nonce from client k = Server’s public key or a shared secret key R S = Nonce from server

Encryption of client nonce Client may encrypt the nonce with the server key used in the generation of K TOKEN —But should not wrap it with any other key! Client may encrypt the nonce using CT-KIP-PRF when no standard encryption algorithm is available: Enc-R C = CT-KIP-PRF(K, “Encryption” || R S, 16)  R C where K is the shared secret key R S = Nonce from server R C = Nonce from client Note: Changed since draft 1: The string “Encryption” prepended

MAC calculations Any existing MAC algorithm may be used When no MAC algorithm is present on the token, the CT-KIP- PRF primitive may be used: MAC 1 = CT-KIP-PRF(K, [R ||] “MAC 1 computation” || R S, 16) MAC 2 = CT-KIP-PRF(K, “MAC 2 computation” || R C, 16) where K is a shared key (should be used for this purpose only) R is an optional, initial nonce from the client R S is the nonce from server R C is the (secret) nonce from client Note: Changed since draft 1: Use of the strings and their placements. Optional client initial nonce R (protection against certain attacks)

Integration with PKCS #11 Re-designed in draft 2 —Now more low-level, traditional PKCS #11 style Three new mechanisms: —CKM_KIP_PRF —CKM_KIP_DERIVE —CKM_KIP_WRAP CKM_KIP_PRF is the PKCS #11 version of CT-KIP-PRF CKM_KIP_DERIVE derives secret keys using the CT-KIP-PRF construct CKM_KIP_WRAP wraps a key using CT-KIP-PRF Note: Intent here is to stop an application from being able to deduce R C – but this may need further work, e.g. introduce CKM_KIP_MAC and simplify CKM_KIP_PRF (or not make it directly callable at all)

CKM_KIP_DERIVE & CKM_KIP_PRF CKM_KIP_DERIVE derives the token key by using parameters: —Key: Shared secret key or server’s public key (and R C ) —Seed: Server’s nonce —Mechanism: Underlying cryptographic mechanism, e.g. SHA-1 —Internally, will place string before K and R S (which is impossible to do with CKM_KIP_PRF) CKM_KIP_PRF corresponds to CT-KIP-PRF —May be used to produce the MAC messages —Key: Shared secret MAC key —Seed: The string and nonce values —Mechanism: Underlying cryptographic mechanism

CKM_KIP_WRAP CKM_KIP_WRAP is used to wrap the client’s nonce R C —Key: NULL (Wrapping key is through C_WrapKey) —Seed: R S —Mechanism: Underlying, e.g. SHA-1 Note: Token shall use the key that was used in the generation of K TOKEN when wrapping! —This possibly needs to be clarified in next draft —If any key can be used, then the application may be able to extract R C

For discussion Bindings: —HTTP provided, how about SOAP? —Security built-in (but not total confidentiality, e.g. key identifiers) Is the PKCS #11 integration sufficient? —Introduce CKM_KIP_MAC, simplify (no keys) or remove CKM_KIP_PRF? Should there be a corresponding CryptoAPI integration? Agreement and stabilization of document content Possible future contribution of document, to (new) OASIS TC or elsewhere?