The Cryptographic Token Key Initialization Protocol (CT-KIP)

OTPS WorkshopFebruary 2006

CT-KIP Primer A client-server protocol for initialization

(and configuration) of cryptographic tokens with shared keys

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

Current status

Version 1.0 finalized in December 2005

Describes a 4-pass protocol for the initialization of cryptographic tokens with secret keys Includes a public-key variant as well

as a shared-key variant

Principle of Operation (4-pass variant)

CT-KIP serverCT-KIP client

Client Hello

Server Hello

Client Nonce

Server Finished

CT-KIP 1- and 2-pass New variants introduced in January draft To meet the needs of certain

environments E.g. no communication path token server,

or high network latency Essentially key transport or key wrap Maintain the property that No other entity

than the token and the server will have access to generated / distributed keys

CT-KIP 2-passCT-KIP serverCT-KIP client

Client Hello

Server Hello

Client Nonce

Server Finished

CT-KIP 2-pass New extension in ClientHello signals

support for two-pass, and supported key transport/key wrapping schemes Payload could include a token public key

Client includes nonce in ClientHello Will ensure Server is alive

Server provides key wrapped (in symmetric key or token’s public key) in new extension in ServerFinished

CT-KIP 1-passCT-KIP serverCT-KIP client

Client Hello

Server Hello

Client Nonce

Server Finished

CT-KIP 1-pass

Server MUST have a priori knowledge of token’s capabilities

Server provides key wrapped in symmetric key or token’s public key in new extension in ServerFinished

Cryptographic properties

Server authentication through MAC in ServerFinished if dedicated K_auth Otherwise MAC provides key

confirmation With K_auth no key confirmation

Server aliveness through MAC on client nonce Not present in 1-pass, however

Identified Issues Key confirmation

Present in 4-pass version Shall it be required for 1-, 2-pass?

Requires some more work for 1-pass Replay protection

OK in 2- and 4-pass Method to use in 1-pass? Counter?

Will require some additional capabilities in token, see mailing list discussion

Next Steps

Decide on key confirmation, replay protection

Resolve any other comments Produce new draft version

Preferably within 4 – 5 weeks