分类： 网络与安全
2010-07-21 14:15:37
In cryptography, Derived Unique Key Per Transaction (DUKPT) is a key management scheme in which for every transaction, a uniquekey 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.
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:
Contents[hide] |
DUKPT was first invented in the late 1980s at Visa, but it didn’t receive much acceptance until the 1990s. It was during this later period that the industry practices shifted towards recommending (and later requiring) that each device have a distinct encryption key. The scheme that was state-of-the-art at the time—known as “Master/Session”—would require that every PIN encrypting device be initialized with a unique master key. In consequence, processors would require a table of encryption keys as large as the number of devices deployed, when handling transactions originating from devices using Master/Session key management, given the need for unique keys per device. This table could become quite large for a major merchant acquirer. DUKPT solves this problem because—although each device is still initialized with a distinct key—this device initialization key is derived from a different key which an entire family of devices may share. Hence, the recipient of encrypted messages needs only to store one key to support a large number of devices in the field, while simultaneously meeting the unique-key-per-device requirement.
This single key was called the “super-secret key” in the original description of the algorithm, but was later renamed to the more official-sounding “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), and the party which initializes the encryption devices (typically the manufacturer of the device). Further, there are pains taken to ensure that this key does not exist in plaintext outside of any tamper-resistant security module (TRSM, or HSM), and in fact is not the key that is used to initialize the encryption device that will participate in DUKPT operations. Rather, a different key is irreversibly derived from the BDK (and within aTRSM), known as the “Initial PIN Encryption Key” (IPEK). This is the key that is actually injected into the device, and a compromise of that key will not compromise the BDK (though the device itself would be considered compromised, and will need to have a new key injected). Even then, the IPEK is used internally by the device to create yet another set of keys irreversibly derived from it (called the “Future Keys”), and the IPEK is then immediately discarded.
On the originating (encrypting) end, the system works as follows:
On the receiving (decrypting) end, the system works as follows:
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).
The following storage areas relating to key management are maintained from the time of the "Load Initial Key" command for the life of the PIN Entry Device:
Holds the left-most 59 bits of the key serial number initially injected into the PIN Entry Device along with the initial PIN encryption key during the "Load Initial Key" command. The contents of this register remain fixed for the service-life of the PIN Entry Device or until another "Load Initial Key" command.
A counter of the number of PIN encryptions that have occurred since the PIN Entry Device was first initialized. Certain counter values are skipped (as explained below), so that over 1 million PIN encryption operations are possible. Note: The concatenation (left to right) of the Initial Key Serial Number Register and the Encryption Counter form the 80-bit (20 hexadecimal digits) Key Serial Number Register.
A set of 21 registers, numbered #1 to #21, used to store future PIN encryption keys. Each register includes a 2 hexadecimal digit longitudinal redundancy check (LRC) or a 2 hexadecimal digit cyclical redundancy check (CRC).
The following storage areas relating to key management are required on a temporary basis and may be used for other purposes by other PIN processing routines:
Contains the address of that Future Key Register whose contents are being used in the current cryptographic operation. It identifies the contents of that Future Key Register whose address is contained in the Current Key Pointer.
A 21-bit register, whose bits are numbered left to right as #1 to #21. This register normally contains 20 "zero" bits and a single "one" bit. One use of this register is to select one of the Future Key Registers. The Future Key Register to be selected is the one numbered identically to the bit in the Shift Register containing the single "one".
A register used in performing cryptographic operations.
A second register used in performing cryptographic operations.
A register used to hold a cryptographic key.
In practical applications, one would have several BDKs on record, possibly for different customers, or to contain the scope of key compromise. When processing transactions, it is important for the receiver to know which BDK was used to initialize the originating device. To achieve this, the 80-bit KSN is structured into parts: as Key Set ID, a TRSM ID, and the transaction counter. The algorithm specifies that the transaction counter is 21-bits, but treats the remaining 59 bits opaquely (the algorithm only specifies that unused bits be 0-padded to a nibble boundary, and then 'f' padded to the 80-bit boundary). Because of this, the entity managing the creation of the DUKPT devices (typically a merchant acquirer) is free to subdivide the 59 bits according to their preference.
The industry practice is to designate the partitioning as a series of three digits, indicating the number of hex digits used in each part: the Key Set ID, the TRSM ID, and the transaction counter. A common choice is '6-5-5', meaning that the first 6 hex digits of the KSN indicate the Key Set ID (i.e., which BDK is to be used), the next 5 are the TRSM ID (i.e. a device serial number within the range being initialized via a common BDK), and the last 5 are the transaction counter.
This notational scheme is not strictly accurate, because the transaction counter is 21 bits, which is not an even multiple of 4 (the number of bits in a hex digit). Consequently, the transaction counter actually consumes one bit of the field that is the TRSM ID (in this example that means that the TRSM ID field can accommodate 2(5*4-1) devices, instead of 2(5*4), or about half a million).
Also, it is common practice in the industry to use only 64-bits of the KSN (probably for reasons pertinent to legacy systems, and DES encryption), which would imply that the full KSN is padded to the left with four ‘f’ hex digits. The remaining 4 hex digits (16-bits) are available, nonetheless, to systems which can accommodate them.
The 6-5-5 scheme mentioned above would permit about 16 million BDKs, 500,000 devices per BDK, and 1 million transactions per device.
