1
$\begingroup$

I am looking for the transaction capacity of a Point-Of-Sale device using 3DES DUKPT. Once all keys derived from the future key set are exhausted (1M or 500K?), how will the POS be reloaded with a new set of future keys. Have not seen many topics on this online.

Is changing the KSI number a widely used industry practice?

Improve this question
$\endgroup$
  • 1
    $\begingroup$ Maybe you should explain the acronyms here and give some context for your question? I can't make heads or tails of what you're asking. $\endgroup$ – pg1989 Apr 23 '16 at 1:22
  • $\begingroup$ I tried to clarify, but this is not my area of expertise, so please edit if I butchered it. $\endgroup$ – otus Apr 23 '16 at 5:31
  • $\begingroup$ @pg1989 DUKPT -> Derived Unique Key Per Transaction. Pretty much if you don't know DUKPT you will not be able to abswer the question. $\endgroup$ – zaph Oct 29 '16 at 15:35
1
$\begingroup$

How many transactions? It depends on precisely how the 80 bit KSN has been divided between key set ID, and device ID. There is freedom on this - the spec does not say how it should be done. In practice usually only 64 bits is used, and it is divided 6-5-5, giving 16 million key sets, 500k devices per key set, and 1 million transactions per device. But you could easily increase that if you needed less key sets/devices.

No, changing the device's serial number is not standard practice. It is intended to remain the same for the life time of the device. It would need to be replaced (via an RMA procedure), or re-injected.

Improve this answer
$\endgroup$
  • 1
    $\begingroup$ The standard doesn't let you change the counter boundary. You could allocate multiple device-ids to one device, but you'd need to inject all the corresponding initial keys; the future-key algorithm can't get from one to another (by design). $\endgroup$ – dave_thompson_085 Sep 22 '17 at 5:02
1
$\begingroup$

As mentioned by Nik, It depends on how many bits are reserved to hold the transaction counter.

While working on a POS application, I have seen 21-bit transaction counter in use. Thus, allowing over 2 million transactions. After key exhaustion, the device needs to be re-injected. But since key exhaustion can happen anytime, immediate key injection is not possible. In this scenario, our application re-injects the same IPEK to get the merchant going but later a terminal engineer will come and do the fresh key injection.

Note: This is the use case I have worked with. I am not sure if this is widely used or not.

Another veriation: In case of exhaustion, your application can do an automatic RKI(Remote Key Injection) where it can receive new IPEK from a server.

Improve this answer
$\endgroup$
  • 1
    $\begingroup$ The standard (X9.24) requires the 'counter' field be 21 bits, but not all values are used -- Hamming weights over 10 are skipped, leaving just over 1 million KSN values (and thus keys) per device-id. $\endgroup$ – dave_thompson_085 Sep 22 '17 at 5:00

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.