Dynamic Symmetric Key Provisioning Protocol (DSKPP)
Extracted elements (30)
Four-pass DSKPP was designed so that K_TOKEN is never transmitted: both parties independently derive it from shared random inputs (R_C, R_S, K) via DSKPP-PRF. This eliminates wire-exposure risk during provisioning and avoids a single point of compromise after provisioning since neither party alone holds all key derivation inputs.
Two-pass DSKPP is chosen when pre-existing legacy keys must be transported, when a device has a manufacturer's pre-shared key (e.g., SIM or smart card), or when it has a keypad for passphrase entry. These conditions enable efficient one-round-trip provisioning without on-the-fly key agreement.
DSKPP defines an HTTP/1.1 binding using MIME type 'application/dskpp+xml'. Messages are transported via HTTPS POST; the KeyProvTrigger is delivered in an HTTP response that a configured browser hands to the DSKPP Client. The binding requires TLS with server certificate validation per RFC 2818.
After a successful key storage operation, it MUST NOT be possible to overwrite the key unless knowledge of an authorizing key is proven through a MAC on a later KeyProvServerHello (and KeyProvServerFinished) message.
After receiving KeyProvServerFinished with Status='Success', the DSKPP Client MUST verify the key confirmation MAC; if verification fails, the client MUST terminate the session and delete any nonces, keys, and secrets associated with the failed run.
Computation of the server's key confirmation MAC MUST include a hash of all DSKPP messages sent during the transaction; re-transmitted messages are removed, the remaining sequence is concatenated and hashed with SHA-256 per FIPS 180.
DSKPP Servers and DSKPP Clients MUST delete any secret values generated as a result of failed runs of DSKPP. Session identifiers MAY be retained for replay detection but MUST NOT be reused for subsequent protocol runs.
For DSKPP-PRF, the secret key k MUST be at least 16 octets long. The function MUST take arbitrary-length input, produce one-way collision-free output, and its output MUST be unpredictable even if other outputs for the same key are known.
For the Key Transport protection method, the DSKPP Server and Client MUST support the RSA-1_5 encryption mechanism defined in XMLENC (http://www.w3.org/2001/04/xmlenc#rsa-1_5).
For the Key Wrap protection method, DSKPP Server and Client MUST support all of: AES128 KeyWrap (RFC 3394), AES128 KeyWrap with Padding (RFC 5649), and AES-CBC-128 (FIPS 197).
For the Passphrase-Based Key Wrap method, implementations MUST support PBES2 password-based encryption (PKCS #5), PBKDF2 key derivation, and the same three AES128 wrapping mechanisms required for Key Wrap.
In four-pass DSKPP, the key package MUST NOT include K_TOKEN, since the token key is never transmitted between the DSKPP Server and DSKPP Client.
K_AC MUST be derived from the Authentication Code password via PBKDF2: K_AC = PBKDF2(AC->password, R_C || K, iter_count, 16). The iteration count MUST be at least 100,000 in the general case; it MUST be 1 when K is K_SHARED or a passphrase-derived key.
The DSKPP Server MUST authenticate the user to ensure they are authorized for the new key before completing the provisioning run.
Upon transmission or receipt of a message whose Status attribute is not 'Success' or 'Continue', both the DSKPP Server and DSKPP Client MUST immediately terminate the DSKPP run.
KeyProvClientHello is the mandatory first client message, carrying a Security Attribute List (SAL) listing supported DSKPP versions, variants, key types, and algorithms in preference order, plus optional AD, DeviceID, and KeyID.
KeyProvClientNonce carries the client's encrypted random nonce E(K, R_C) and User Authentication Data (AD) to the server. R_C, encrypted under the server key K, is the client's entropy contribution to K_TOKEN derivation.
KeyProvServerFinished delivers a Key Package (KP) containing key usage attributes but never K_TOKEN itself, along with a key confirmation MAC = DSKPP-PRF(K_MAC, 'MAC 1 computation' || SHA-256(msg_1,...,msg_n), dsLen). A Status='Success' acts as a Commit instruction to the cryptographic module.
KeyProvServerHello is the server's response to KeyProvClientHello, containing the selected SAL, server random nonce R_S, encryption key K (either server public key K_SERVER or pre-shared K_SHARED), and an optional MAC required when renewing an existing key.
KeyProvTrigger is an optional server-initiated message delivered via HTTP response (MIME type 'application/dskpp+xml') containing Authentication Data (AD), optional DeviceID, optional KeyID, and optional server URL. It launches the DSKPP Client and provides credentials for the subsequent ClientHello.
IANA maintains a DSKPP Key Container Registry. Initial entries identify four key package formats by URN: PSKC Key Container (RFC 6030), SKPC Key Container (RFC 6031), PKCS12 Key Container, and PKCS5-XML Key Container.
IANA maintains a DSKPP PRF Algorithm ID Sub-Registry with initial entries DSKPP-PRF-AES (AES-based pseudorandom function) and DSKPP-PRF-SHA256 (SHA-256-based pseudorandom function), each identified by a URN under urn:ietf:params:xml:ns:keyprov:dskpp.
IANA maintains a DSKPP Status Code Registry. Initial values include: Continue, Success, Abort, AccessDenied, MalformedRequest, UnknownRequest, UnknownCriticalExtension, UnsupportedVersion, NoSupportedKeyTypes, NoSupportedEncryptionAlgorithms, NoSupportedMacAlgorithms, NoProtocolVariants, NoSupportedKeyPackages, AuthenticationDataMissing, AuthenticationDataInvalid, InitializationFailed, ProvisioningPeriodExpired.
A man-in-the-middle presenting a substitute public key learns the client's K_TOKEN but cannot cause the legitimate server to derive the same value, since K_TOKEN is a function of the encryption key used. Client and server will detect desynchronization at authentication time. Independently validating K_SERVER via a separate connection is recommended.
Key confirmation via MAC is required to prevent a false Commit message from causing the cryptographic module to store a key the server does not recognize. The MAC binds K_TOKEN to the full message transcript, ensuring both parties share the same key derivation inputs.
Server authentication in four-pass DSKPP relies on TLS certificate validation per RFC 2818 Section 3.1. When K equals K_SERVER, the cryptographic module SHOULD verify the server's certificate before using it to encrypt R_C, preventing rogue key substitution.
The Passphrase-Based Key Wrap method in two-pass DSKPP SHOULD only be used when the device has a built-in keypad for direct passphrase entry, to preserve the property that K_TOKEN is exposed only to the server and the cryptographic module and not to any intermediate party.
Four-pass protocol flow: (1) optional KeyProvTrigger (server→client); (2) KeyProvClientHello (client→server); (3) KeyProvServerHello with status=Continue and R_S (server→client); (4) KeyProvClientNonce with E(K,R_C) and AD (client→server); (5) KeyProvServerFinished with KP and MAC (server→client). Any non-Continue/Success status triggers immediate termination.
Two-pass protocol flow: (1) optional KeyProvTrigger; (2) KeyProvClientHello carrying SAL, AD, R_C, and Key Protection Method List (KPML); (3) KeyProvServerFinished with K_PROV encrypted under the chosen key protection method. Server selects a key protection method from KPML and delivers K_PROV from which client derives K_TOKEN and K_MAC.
Authentication Code (AC) uses TLV encoding: Type field is 1 hex character; Length field is 2 hex characters (value up to 255); Value is a variable-length hex string. Mandatory TLVs: Client ID (type 1, max 255 chars) and Password (type 2). Optional Checksum (type 3) uses CRC16 (ISO 3309). Vendor-specific TLV types MUST have the high bit set.