Transcript CT-KIP
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: 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 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 MAC calculations • • • Any existing MAC algorithm may be used When no MAC algorithm is present on the token, the CT-KIPPRF 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) 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) 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 before K 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 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 KTOKEN 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 RC 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?