• 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.


2 Answers 2


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.


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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .