CT-KIP

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

2. 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

3. Principles of operation

4. 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: KTOKEN = CT-KIP-PRF(RC, “Key generation” || k || RS, 16) RC = Nonce from client k = Server’s public key or a shared secret key RS = Nonce from server

5. Encryption of client nonce • Client may encrypt the nonce with the server key used in the generation of KTOKEN • 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-RC = CT-KIP-PRF(K, “Encryption” || RS , 16) RC where K is the shared secret key RS = Nonce from server RC = Nonce from client • Note: Changed since draft 1: The string “Encryption” prepended

6. 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: MAC1 = CT-KIP-PRF(K, [R ||] “MAC 1 computation” || RS, 16) MAC2 = CT-KIP-PRF(K,“MAC 2 computation” || RC, 16) where K is a shared key (should be used for this purpose only) R is an optional, initial nonce from the client RS is the nonce from server RC 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)

7. 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 RC – 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)

8. 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 RC) • Seed: Server’s nonce • Mechanism: Underlying cryptographic mechanism, e.g. SHA-1 • Internally, will place string beforeK and RS(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

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

10. 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?