In cryptography, Derived Unique Key Per Transaction (DUKPT) is a key management scheme in which for every transaction, a unique key is used which is derived from a fixed key. Therefore, if a derived key is compromised, future and past transaction data are still protected since the next or prior keys cannot be determined easily. You can also use an HSM to store ECDSA keys used for SSL Forward Proxy or SSL Inbound Inspection decryption. On the HSM, import or generate the certificate and private key used in.

(Redirected from DUKPT)

In cryptography, Derived Unique Key Per Transaction (DUKPT) is a key management scheme in which for every transaction, a unique key is used which is derived from a fixed key. Therefore, if a derived key is compromised, future and past transaction data are still protected since the next or prior keys cannot be determined easily. DUKPT is specified in ANSI X9.24 part 1.

Overview[edit]

DUKPT allows the processing of the encryption to be moved away from the devices that hold the shared secret. The encryption is done with a derived key, which is not re-used after the transaction. DUKPT is used to encrypt electronic commerce transactions. While it can be used to protect information between two companies or banks, it is typically used to encrypt PIN information acquired by Point-Of-Sale (POS) devices.

DUKPT is not itself an encryption standard; rather it is a key management technique. The features of the DUKPT scheme are:

enable both originating and receiving parties to be in agreement as to the key being used for a given transaction,
each transaction will have a distinct key from all other transactions, except by coincidence,
if a present derived key is compromised, past and future keys (and thus the transactional data encrypted under them) remain uncompromised,
each device generates a different key sequence,
originators and receivers of encrypted messages do not have to perform an interactive key-agreement protocol beforehand.

History[edit]

DUKPT was invented in the late 1980s at Visa but didn’t receive much acceptance until the 1990s, when industry practices shifted towards recommending, and later requiring, that each device have a distinct encryption key.

Before DUKPT, state of the art was known as Master/Session, which required every PIN-encrypting device to be initialized with a unique master key. In handling transactions originating from devices using Master/Session key management, an unwanted side effect was the need for a table of encryption keys as numerous as the devices deployed. At a major merchant acquirer the table could become quite large indeed. DUKPT resolved this. In DUKPT each device is still initialized with a distinct key, but all of the initialization keys of an entire family of devices are derived from a single key, the base derivation key (BDK). Mak key generator office 2016 online. To decrypt encrypted messages from devices in the field, the recipient need only store the BDK.

Keys[edit]

As stated above, the algorithm needs an initial single key which in the original description of the algorithm was called the super-secret key, but was later renamed to—in a more official-sounding way—Base Derivation Key (or BDK). The original name perhaps conveys better the true nature of this key, because if it is compromised then all devices and all transactions are similarly compromised.

This is mitigated by the fact that there are only two parties that know the BDK:

the recipient of the encrypted messages (typically a merchant acquirer)
the party which initializes the encryption devices (typically the manufacturer of the device).

The BDK is usually stored inside a tamper-resistant security module (TRSM), or hardware security module (HSM). It must remain clear that this key is not the one used to initialize the encryption device that will participate in DUKPT operations. See below for the actual encryption key generation process.

First: A key derived from the BDK, this is known as the IPEK (Initial PIN Encryption Key)
Second: The IPEK is then injected into the devices, so any compromise of that key compromises only the device, not the BDK. This creates yet another set of keys (inside the device) irreversibly derived from it (nominally called the Future Keys)
Fourth: Afterwards the IPEK is then immediately discarded. NOTE: This step contradicts 'Session Keys' section where it indicates that only 21 'Future Keys' are generated. The IPEK must be retained by the terminal in order generate the next batch of 21 Future Keys.
Fifth: Future Keys are used to encrypt transactions in the DUKPT process.

Upon detection of compromise the device itself a new is derived inside the and the Derived Key Generation Process

Communication[edit]

Origination[edit]

On the originating (encrypting) end, the system works as follows:

A transaction is initiated which involves data to be encrypted. The typical case is a customer's PIN.
A key is retrieved from the set of “Future Keys”
This is used to encrypt the message, creating a cryptogram.
An identifier known as the “Key Serial Number” (KSN) is returned from the encrypting device, along with the cryptogram. The KSN is formed from the device’s unique identifier, and an internal transaction counter.
The (cryptogram, KSN) pair is forwarded on to the intended recipient, typically the merchant acquirer, where it is decrypted and processed further.
Internally, the device does the following:
1. Increments the transaction count (using an internal counter)
2. Invalidates the key just used, and
3. If necessary generates more future keys

Can A Virtual Hsm Generate Dukpt Keys Youtube

Receiving[edit]

On the receiving (decrypting) end, the system works as follows:

The (cryptogram, KSN) pair are received.
The appropriate BDK (if the system has more than one) is located.
The receiving system first regenerates the IPEK, and then goes through a process similar to that used on the originating system to arrive at the same encrypting key that was used (the session key). The Key Serial Number (KSN) provides the information needed to do this.
The cryptogram is decrypted with session key.
Any further processing is done. For merchant acquirers, this usually means encrypting under another key to forward on to a switch (doing a “translate”), but for certain closed-loop operations may involve directly processing the data, such as verifying the PIN.

Session Keys[edit]

The method for arriving at session keys is somewhat different on the originating side as it is on the receiving side. On the originating side, there is considerable state information retained between transactions, including a transaction counter, a serial number, and an array of up to 21 “Future Keys”. On the receiving side there is no state information retained; only the BDK is persistent across processing operations. This arrangement provides convenience to the receiver (a large number of devices may be serviced while only storing one key). It also provides some additional security with respect to the originator (PIN capture devices are often deployed in security-averse environments; the security parameters in the devices are ‘distant’ from the sensitive BDK, and if the device is compromised, other devices are not implicitly compromised).

Registers Usage[edit]

Backup Registers[edit]

The following storage ar