Schneier on Security

scot • June 17, 2020 8:19 AM

(Also, if anyone wants to see how the algorithms work, there is a tool here https://github.com/fluzwup/Cryptonomicon that performs most of the chip card cryptographic functions.)

scot • June 17, 2020 12:49 PM

@zboot The bank can already impersonate the customer, all they have to do is create a new card linked to the customer’s account. Or just change some numbers in the database to move the money to a different account. There are many ways for “the bank” to do such things, but all of them should involve more than one person. By keeping the entire key stored in a single location, they bank broke the rules, and let a single person exploit succeed.

For example, when symmetric keys are exchanged between organizations, the key is generated inside the originating organization’s HSM along with two random numbers of the same length. The random numbers are XORed with the key, and the result, along with the random numbers, are physically mailed, in tamper-evident packaging, on different days, by different carriers, to different individuals at the destination organization. When all components arrive, the three individuals then open their packages, enter their components into their HSM one at a time, where the key is reassembled inside the HSM by XORing the three components. No one person ever has access to more than one component, and if any of the three components are compromised, the key is discarded and the process is repeated.

I do wonder how the fraud was committed with the PVK, though. Sure, you can reverse engineer the PIN from the PVV and PVK, but that only helps you in PIN based transactions, which are by necessity card-present transactions. That leaves you with the problem of generating physical cards; not technically challenging if you’re just creating magstripe cards (just need card stock and a stripe writer), but you need many additional keys to create chip cards (the issuer master RSA key to match the CA signed certificate, the master derivation key, card verification key). Of more use would be the CVK, which is used to generate the CVV, iCVV, and CVV2 values. With a list of PANs, expiration dates, and the CVK, you could generate the CVV2 values (that’s the 3 digit code printed on the back of the card) and perform card-not-present fraud.

scot • June 18, 2020 9:16 AM

@Winter The PIN verification key is actually a pair of single length DES keys, used in a TDES-like hash function (encrypted with key A, decrypt with B, encrypt again with A). The card also encodes a single digit PVK index, allowing 10 potential PVK pairs to be chosen. Of course each bank has its own key set, and could potentially have different key sets for different card ranges, specified by certain digits of the card numbers.

The question here is why was the key on paper in the clear?

If the bank shared their PVK with, say, Visa (allowing Visa to do stand-in PIN validation), then the keys would have been shared in three parts that had to be XORed together (see my earlier comment). No single person should ever see or have possession of more than one compoment, and the components should be securely stored until the key ceremony. During the key ceremony, the components are combined in the hardware security module (HSM), and that is the only place the complete key should ever come together. The only keys typically shared this way are transport keys, which are keys used to encrypt other keys. A PVK exchange between organizations would involve exchanging the PVK under a previously established transport key.

Keys do have to be backed up, of course, in case of an HSM failure. HSMs, at least the ones I’ve worked with, store the keys encrypted with a master key. A PVK backup, then, would only have needed to be a backup of the encrypted key. To restore or upgrade an HSM, you would set the master key, and then load all the encrypted keys. Modern HSMs back up their master key in a secure fashion that protects against compromise or loss, such as writing it across a set of smart cards, where you need at least N of M cards to assemble the full key (N being a minimum of 2, and M > N). Data security standards call for storing those keys in separate safes, ideally at separate physical locations (as a loss prevention measure), with no person having access to more than one safe.

The last possible route to compromise is the transport keys. If an individual had HSM access, and knew the clear key value of a transport key, then the PVK could have been exported under the compromised transport key, and decrypted elsewhere. The only way to inject a key into a locked down HSM is through a key ceremony, and the interface for that should require two administrator passwords to unlock.

In short, either multiple people with privileged access where involved, or there were some serious breakdowns in Payment Card Industry Data Security Standards compliance at the bank. I’d bet on the latter.