In the chapter "Method: DUKPT (Derived Unique Key Per Transaction)", page 41, it says, that the receiver should verify that the originator's transaction counter in the SMID has increased.

Other sources say that HSM's (the receiver) do not store any state apart from the base derivation keys: The base derivation keys can be looked up by the key set identifier (contained in the SMID). So the receiver (HSM) is able to decrypt without keeping any state of the originator. I understand that very well.

But when verifying the transaction counter I can not imagine any other way than keeping track of the transaction counter per key serial number (KSN) of the originator (a table or map) - that is there is some state in the HSM kept, but there should not be kept any state.

Although the document contains pseudo code that explains the implementation of the methods described in the document there is no hint how the transaction counter is verified.

How is this actually implemented or what is the basic idea how this is achieved without keeping track of the state?

(this question was posted on stackoverflow, not answered there, but recommended to be asked here)

Could you post a link to the specification? I am not familiar with ANSI X9.24, but on cursary reading I think you are correct that the HSM must store the KSN. Transaction counters are used to mitigate replay attacks where an adversary captures a transaction and resends the same data from one party in the transaction. Prohibitions on keeping state are usually to mitigate information leakage or prevent short-cycling a protocol. I can not think of a good reason not to store the KSN as it a function of the device’s unique identifier, and the device's internal transaction counter.
–
this.joshJul 5 '11 at 16:41

Thanks a lot for your answer and your well thought out explanation! Unfortunately I can neither post a link nor show here a part of the document since there is a strict copyright on the document that doesn't allow it. We had to buy it, it is not available on the internet for free. You asked for a good reason: One reason I have read about the HSM being stateless is that the number of devices can be really high. Thanks again for your response!
–
gerneGrossJul 5 '11 at 17:18

3 Answers
3

I'm not sure if I understand your question correctly, so first let me explain my understanding of your question and then the answer to it.

You're basically asking how it is possible that the receiving HSM box keeps no state but is able to validate that the PED (Pin Entry Device) is using the correct sequence key derived from the BDK.

If this is correct, then the answer is as follows:
The BDK is used to generate one-time keys which are the actual keys used for encryption. The counter is sent as part of the KSN so the receiving HSM can calculate the correct key used based on the counter sent by the PED and the first key (which is stored in the HSM and is derived from the BDK). You can look at it as a chain.

Consider the function s(key) which gives you the next(successor) key to be used after key.

Both parties have knowledge of the first key k1
Now the PED sends the transaction counter t to the HSM. and the hsm can calculate the key used by recursively applying the s function t times with k1 as initial input. Depending on the implementation, the key can be stored to avoid performing superfluous calculations.

Thanks for your answer! I'm sorry that the question is unclear. I use your terminology: How it is possible that the receiving HSM box keeps no state but is able to validate that the PED is using the correct transaction counter t. A counter t is correct if t was increased since the last request. As this.josh pointed out this is done to mitigate replay attacks. If the PED sends in the same counter t a second time and the HSM box is not checking the counter t, in the end the same sequence key is used again. How can the HSM box validate the counter t without storing the counter t for each device?
–
gerneGrossJul 6 '11 at 9:37

1

The PED cannot do that in theory since a PED is a tamper resistant device (i.e. PED is also a HSM), so the firmware that runs on it cannot be tampered with, in case it is opened, it self destructs. Moreover, the PED's serial number is whitelisted (at least in my case) so if the PED is functional, has a valid serial number AND has a key derived from the correct BDK, you can be sure it works correctly. The receiving HSM does not need to check that.
–
HenriJul 8 '11 at 8:21

I am probably a bit late with my answer, but your initial question is very clear for me and I know exactly what you mean.

The KSN is normally stored by the receiving host in order to keep track of the transaction counter. So for each transaction, the host verifies that the sending device is not using a previously used key by checking that the transaction counter in the KSN is higher than it was when previous transaction was handled by the host. For some transaction types however, the host might have logic that it accepts the same set of DUKPT keys to be used for more than one request/response pair. E.g. for technical reversals.

Normally a record is kept in a data table on the application host's database for each PED and in the record a field is set to keep track of last counter received from the PED, if the next counter value is less than the value of last counter value in the database then appropriate action can be taken. DUKPT transaction counter is in clear so there is no need for HSM to verify this, Only the host application requires a logic to verify the transaction counter