Bank Card "Master Key" Stolen

South Africa's Postbank experienced a catastrophic security failure. The bank's master PIN key was stolen, forcing it to cancel and replace 12 million bank cards.

The breach resulted from the printing of the bank's encrypted master key in plain, unencrypted digital language at the Postbank's old data centre in the Pretoria city centre.

According to a number of internal Postbank reports, which the Sunday Times obtained, the master key was then stolen by employees.

One of the reports said that the cards would cost about R1bn to replace. The master key, a 36-digit code, allows anyone who has it to gain unfettered access to the bank's systems, and allows them to read and rewrite account balances, and change information and data on any of the bank's 12-million cards.

The bank lost $3.2 million in fraudulent transactions before the theft was discovered. Replacing all the cards will cost an estimated $58 million.

Posted on June 17, 2020 at 6:21 AM • 20 Comments

Comments

LéonJune 17, 2020 6:41 AM

When the architecture of a system depends so heavily on a single master key for everything, an accident like this is bound to happen.

Grima SJune 17, 2020 7:29 AM

You beat me to it. I was going to phrase that slightly differently, asking if it is at all prudent to have a single key that affords access to *everything* in such a system, but, yes, you have exactly identified the problem.

scotJune 17, 2020 8:17 AM

If the bank is using ICC cards (and everyone in Africa should be) and online PIN verification, this should not require replacement of all of the cards. The compromised key can be blocked by the issuer, a new PIN verification key (PVK) can be generated, and customers can be required to go to a branch to have a teller verify their identity and issue them a new random PIN (or sent via mail or SMS to a verified address). The PVK is assigned an index, so a new key would have a new index, and all PIN transactions include the index used, so it's easy to tell if the old or new PVK is being used.

The way PINs work is that you take the card number (PAN) as a salt, do a cryptographic hash with the two halves of the PVK (a double length TDES key), and grab the first N decimal digits of the result (if there aren't enough decimal digits, subtract 10 from the A-F values to get decimals). This gives you the PVV, or PIN verification value. This value is encoded, along with the PVK index, in the magnetic stripe and the chip and stored in the issuer's database. The issuer is forbidden by Payment Card Industry (PCI) rules from storing the PIN itself, they can only store the PVV (this is why a PIN leak should be impossible). When the encrypted PIN comes in from the terminal (in an encrypted block of data), the clear PIN entered by the user is decrypted, hashed, and compared to the PVV from the card data or the database.

There's nothing that can be done about the PVV encoded on the magnetic stripe--it's going to be bad, but the deprecated PVK index will let the issuer know that it should not trust that card for magstripe transactions. The PIN value and PVK index stored in the card's cip can be updated by pushing an issuer script to the card, and of course the PVVs and PVK indexes in the database can be set when a new PIN is issued.

Of course, that all assumes that the bank is doing things right.

zbootJune 17, 2020 10:09 AM

@Scott -If the bank can communicate a new PIN to the customer, that means they are capable of generating it, which means they have all the information necessary to impersonate the customer, which means whomever stole the banks master keys also has that information.

So, all the cards have to be replaced because the bank essentially needs to destroy all existing information that they have which could let them change the PIN information on existing cards.

ATNJune 17, 2020 10:45 AM

Interesting that this breach has been made public, I would have thought that considering $3.2 million is below $58 million, the bank managers would have hidden the fact and kept their yearly bonus...

Sue d'OnimJune 17, 2020 11:18 AM

"allows them to ... rewrite account balances"! This sounds like every crook's dream. Did that actually happen? Could the bank do anything about it if it did?

raulJune 17, 2020 11:44 AM

The key was copied, not stolen. Had it been stolen, the bank would have noticed it immediately, because they wouldn't have been able to process their customers' legitimate transactions. This might happen if, for example, a rogue but stupid employee walked out with the hardware security module.

wiredogJune 17, 2020 11:51 AM

Someone needs to forward this to the FBI with a little note about how this shows why having a master key to backdoor communications is a bad thing.

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

lurkerJune 18, 2020 12:26 AM

@Andrew:
this is Africa, price of replacing a card = $2-3 + (Bantu word for baksheesh|squeeze|gratuité).

Bobby JoeJune 18, 2020 12:46 AM

You would think basic access controls like least privilege, split knowledge, dual control, etc are child's play. But when it's the employees(aka the bank) committing the fraud, all those mean nothing due to massive collusion. Maybe there shouldn't be employee direct access to such codes but some kind of ERP access to an API. Talk of zero trust.

WinterJune 18, 2020 4:08 AM

Why is there a Single Master PIN Key?

I would expect to have to combine 2 or more keys held by different employees to be allowed to do Master PIN Key stuff. With the actual master key only available in secured memory during actual transactions and never stored.

Or was that the case and was the Master Key dumped from memory?

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

TatütataJune 18, 2020 10:30 AM

The master key, a 36-digit code,

Cryptologically speaking, isn't that a bit short for any sort of security?

TatütataJune 18, 2020 10:31 AM

Ooops, brain runs at 10% capacity. I read "bit" instead of "digit". Please disregard/delete previous nonsense.

Clive RobinsonJune 18, 2020 11:32 AM

@ Tatütata,

I read "bit" instead of "digit". Please disregard/delete previous

Let's see 36 "digits" is assumed to be decimal unless otherwise stated so 10^36 which is about, 2^120 (1.329228e36)...

So as 256 bits is prefered with a stronger algorithm than 3DES and 128 is considered a bare minimum.

Then,

... isn't that a bit short for any sort of security?

Is not wrong ;-)

Treat "your gut" to something it enjoys as it's "fealing / hunch" was close enough. As for the brain it obviously needs a couple of weeks somewhere relaxing, I would normally recomend a beach somewhere with a well stocked "on the beach" café and bar :-) But sadly most of those are compleatly unavailable currently :-(

Leave a comment

Allowed HTML: <a href="URL"> • <em> <cite> <i> • <strong> <b> • <sub> <sup> • <ul> <ol> <li> • <blockquote> <pre>

Sidebar photo of Bruce Schneier by Joe MacInnis.