AS 2805.6.7:2011 pdf – Electronic funds transfer—Requirements for interfacesPart 6.7: Key management— Transaction keys-Derived unique keyper transaction (DUKPT)

admin
AS 2805.6.7:2011 pdf – Electronic funds transfer—Requirements for interfacesPart 6.7: Key management— Transaction keys-Derived unique keyper transaction (DUKPT)

AS 2805.6.7:2011 pdf – Electronic funds transfer—Requirements for interfacesPart 6.7: Key management— Transaction keys-Derived unique keyper transaction (DUKPT).
6.5 Cryptographic keys synchronization
The DUKPT method is inherently self-synchronizing.
Special recovery is not required because synchronization cannot be lost.
1-lowever, other system, communication or operational failures may appear to impaL cryptographic key synchronization.
6.6 Other considerations
The DUKPT method does not require an acquirer to maintain any database of key management related data, except for a relatively small number of base derivation keys that can be stored by the SCMs of this acquirer.
Because, in this method, a transaction identifies its own transaction key, it is susceptible to a fraud threat. An adversary compromises one transaction-originating TCU and then replicates the key identifier, in this case the key name (which forms the SMID transmitted by this TCU), and the key itself in many originating TCUs. In this case this threat may he countered by two means:
(a) The originating TCU automatically sets its transaction counter to zero when a new key is loaded. Since the compromised TCU had a non-zero transaction counter (the counter is incremented immediately after key loading), the fraudulently-loaded TCU cannot be made to simulate the compromised TCU.
(b) An audit process is performed, perhaps offline using logged key names, to determine if two or more transaction-originating TCUs are associated with the same KSI and TCU ID. This audit process detects the use of a counterfeit TCU that has been loaded with data from a compromised TCU.
This method allows transaction-originating TCUs to be loaded with initial keys and initial key names prior to being distributed to their operational locations. If the TCUs are PIN Entry Devices that are used with POS terminals, this means that the PIN Entry Devices may he delivered to the merchant’s non-secure facility with the keys already loaded. This prevents an adversary from replacing a legitimate TCU with a counterfeit unit that has all of the correct operational characteristics plus a secret data disclosing ‘bug’. Since the design of the PED will ensure that the key is automatically erased if the TCU is opened, it also prevents the placing of a secret data disclosing ‘bug’ within a legitimate TCU. The counterfeit TCU could not contain a valid key and therefore transactions from that TCU would he rejected.
This method allows a TCU that has been loaded with a key to be subsequently associated with a transaction-originating terminal without the need for any coordination with the acquirers. If the TCUs are POS PIN Entry Devices, the merchant can install any PIN Entry Device at any time with any terminal and can replace a failed PIN Entry Device at any time with a spare unit, all without the need for manual coordination with the acquirers.
This method can be used with a ‘sub-key’ methodology that enables a set of TCUs, for example, a merchant’s POS PIN Entry Devices, to change from one acquirer to another without the need to transfer to this second acquirer the base derivation key. which the first