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?