2

Assumptions:

  • We have devices out in the field injected with keys derived from our one and only BDK.
  • The devices encrypt data using the injected derived key.
  • All our devices connect to our server where the data is decrypted.
  • Our server connects to 2 different processors (A and B) for transaction processing.

Now lets say processor B says that they want the data to remain encrypted all the way through to them and hence asks us to share our precious BDK with them so that they can decrypt the data. What is the recommended way for doing this?

I want to do it in such a fashion that if BDK is compromised at processor B, all of processor A’s devices remain safe. An obvious way would be to create two BDKs: BDK-A and BDK-B. All of processor A’s devices will use BDK-A and all of processor B’s devices will use BDK-B. But the disadvantage of doing so is that now at the time of key injection we will need to know which processor the device is for and inject keys accordingly. That makes device preparation process more operationally expensive.

I want to know if there is a way to keep things operationally simple and yet minimize the impact of a compromise at processor B.

3

If B specifically wants the data encrypted end-to-end from the field device to them, then indeed you need devices injected under a BDK known to B -- either you generated and gave to B, or B generated itself and gave to you or your vendor(s)/injection facility(s) -- and preferably not used by or shared with anybody else.

You don't say what type(s) of devices and users/settings you are concerned with. I have seen (in the US) some retail/point-of-sale (magstripe "swipe" and pinpad, sometimes EMV) devices that can be injected with two device keys, under two different BDKs. But the ones I saw tended to be the higher end (thus more expensive), and you still have the problem of choosing which key to use for a given transaction/data-item, which usually means some other system that is interfacing with the human(s) involved, like a cash register/till, being modified to make this decision and command the device.

If B is only concerned about the data being encrypted all the time so it isn't vulnerable to attacks, they might well be satisified to treat your server as a single (unusually busy) device in their network -- i.e. they assign you an initial key (and corresponding initial KSN) under their BDK; you get each transaction encrypted by the device under a BDK-A key, decrypt it and immediately re-encrypt it under the BDK-B key, and send it up to B.

If you are using an HSM for your crypto, and for large volumes of payment-sensitive data you should, this is often provided as a single operation called "translate" -- that is, instead of "decrypt under key #3" then "encrypt under key #17", your software can request "translate from key #3 to key #17", and then the plaintext is never visible in your CPU/memory/swap, only within the dedicated and hardware-protected HSM.

Depending on your transaction volumes this could burn through the somewhat-less-than-2^21 values of TCTR pretty fast, so B may have to send you another "device" key (or maybe several) every month, or week or whatever, using some mechanism that is both secure and as automated as possible to avoid mistakes. You should definitely try to have each new key ready at least a week before you expect to need it, preferably more, in case volume spikes or some fault forces you to switch early. But if they're making money on the transactions you send them, and they presumably wouldn't accept your business otherwise, they should be able to manage.

1

DUKPT The Derived Unique key per Transaction (DUKPT) Scheme is used in a point-of-sale (POS) environment. As its name indicates, Derived Unique Key per Transaction generates a new key for each transaction. This technique involves the use of Base Derivation Key (BDK) and Key Serial Number (KSN). On each transaction, the PIN pad generates a new encryption keys that are derived from a secret BDK and a non-secret KSN. It encrypts the PIN with this key, and then forwards both the encrypted PIN and the key serial number to the acquirer. The benefit of DUKPT is that if one of these one-time encryption key is discovered, only one transaction will be compromised, none of the others transactions from the same POS device would be able to be decrypted with that key. Note that the ANSI X9.24-1:2009 method for DUKPT PIN key derivation is used.

Base Derivation Key

Acquirer host has the responsibility for maintaining the Base Derivation Key. In HSM, the one-time encryption key generated by the PIN-entry is “derived”, using the original Base Derivation Key and the Key Serial Number supplied by the PIN-entry. In practical applications, acquirer host would have several BDKs, possibly for different PIN-entry devices. When processing transactions, it is important for the acquirer to know which BDK was used to initialize or injected into the originating PIN-entry device. To achieve this, Base Derivation Key identifier is embedded in Key Serial Number string.

For each transaction, acquirer host will extract from internal storage the appropriate encrypted base derivation key identified by the BDK ID of the KSN string. Acquirer host must find a match within BDK cryptogram list (BDK profile maintained in acquirer host). If a match is not found in the database, the transaction will be rejected. More at : http://www.writeulearn.com/dukpt/

0

One way to maintain both security and control is to provide processor B with a physical HSM that they install in their data center, but contractually belongs to you. This has two huge advantages.

  1. Security of the device is your decision, and an HSM ensures it can't be violated by the processor.
  2. Since you own the device, you are free to change payment processors based strictly on business reasons. If the business wants to change processors at the end of a contract, you simply take your HSM back. No need for a costly reinjection of keys into your thousands of already-deployed terminals, and the long-term delays this would create.

This will be costly, of course, but cheaper than the problems that other solutions might create.

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.