Attacking Bank-Card PINs

Research paper by Omer Berkman and Odelia Moshe Ostrovsky: “The Unbearable Lightness of PIN Cracking“:

Abstract. We describe new attacks on the financial PIN processing API. The attacks apply to switches as well as to verification facilities. The attacks are extremely severe allowing an attacker to expose customer PINs by executing only one or two API calls per exposed PIN. One of the attacks uses only the translate function which is a required function in every switch. The other attacks abuse functions that are used to allow customers to select their PINs online. Some of the attacks can be applied on a switch even though the attacked functions require issuer’s keys which do not exist on a switch. This is particularly disturbing as it was widely believed that functions requiring issuer’s keys cannot do any harm if the respective keys are unavailable.

Basically, the paper describes an inherent flaw with the way ATM PINs are encrypted and transmitted on the international financial networks, making them vulnerable to attack from malicious insiders in a bank.

One of the most disturbing aspects of the attack is that you’re only as secure as the most untrusted bank on the network. Instead of just having to trust your own issuer bank that they have good security against insider fraud, you have to trust every other financial institution on the network as well. An insider at another bank can crack your ATM PIN if you withdraw money from any of the other bank’s ATMs.

The authors tell me that they’ve contacted the major credit card companies and banks with this information, and haven’t received much of a response. They believe it is now time to alert the public.

Tags: , , , , , ,

Posted on November 17, 2006 at 7:31 AM • 45 Comments

Comments

supersnail • November 17, 2006 9:21 AM

If you can get inside an ATM switch with enough authority to run arbitary code, then you’re a pretty poor fraudster if you only come away with a bunch of pin codes!

The real weakness in the attack from a practical point of view is how do you capture and identify “your” ATM transaction in all the thousands of transactions flowing through the switch?

Also Brits and Frenchies cannot sleep soundly either. A different more secure protocol is used for chip n pin, but, the old pin block is supported for backward compatibility, so, it would be vulnerable to this attack.

Stan • November 17, 2006 9:28 AM

@ Felix: My goodness, thanks for that. I’m sure nobody ever would have figured that out on their own.

Keith • November 17, 2006 9:29 AM

And of course PIN numbers are the customer’s responsibility to keep secure and secret, so the security problem here is an externality to the bank anyway.
Added to that externality, even if someone gets a pile of your customers’ PINs, you can just blame it on one of the other banks in the network.

Gopi Flaherty • November 17, 2006 10:12 AM

“The authors tell me that they’ve contacted the major credit card companies and banks with this information, and haven’t received much of a response.”

This is the sort of behaviour that encourages full disclosure. When I read of corporations dismissing attacks as impractical or improbable, I’m reminded of the banner at the top of l0pht Heavy Industries’ web site, which went approximately:

“‘That exploit is purely theoretical.’ – Microsoft

l0pht: Making the theoretical practical since 199x”

Todd Jonz • November 17, 2006 10:37 AM

We’ve recently been assured by election officials and Diebold executives alike that all poll workers are trustworthy (titter), and that we needn’t worry our pretty little heads about insiders compromising electronic voting systems. By extension, I think it’s safe to assume that all bank employees are similarly trustworthy (snicker), and that security vulnerabilities in internal banking systems are nothing we need to be concerned about. (GUFFAW!)

Graham Steel • November 17, 2006 10:59 AM

I recently wrote a paper on automatically quantifying the difficulty of cracking PINs, when various different combinations of the commands mentioned in Berkman and Ostrovsky’s paper are available to the intruder. It will appear in the November 2006 edition of Theoretical Computer Science, (Volume 367, Issues 1-2, pages 257-270), but you can also download a pre-print from my webpage if you’re interested…

http://homepages.inf.ed.ac.uk/gsteel/papers/

Fergus Doyle • November 17, 2006 11:40 AM

The bad news is there is a real problem here and has always been it only applies where you are using your card at an “untrusted” bank though. You should be safe at your bank if you trust them 🙂

The good news is that for chip cards where the ATM acquires the card by the chip this problem does not exist as the encryption is done in the pinpad (the actual thing you press the keys on) and in the card itself and never gets seen elsewhere.

So the sooner we are all using chip cards rather than magnetic stripe cards the better.

CJ • November 17, 2006 12:08 PM

@Fergus:

Not quite. The PIN is encrypted on the keypad, but it still needs to be translated to encryption under the key of the appropriate switch, as it travels through the system. So your PIN is encrypted and decrypted multiple times on the route to your bank from the ATM: the reason this is thought to be safe is because the decryption and re-encryption occurs within a hardware module (the HSM), which is a sealed unit which is tamper-proof. This attack shows that that isn’t sufficient.

kirill • November 17, 2006 3:32 PM

you may have missed this piece of news about a year ago, approximately September-October 2005. I don’t remember exactly, it was either Citi or Raiffeisen, who did forced replacement of all its cards ever inserted into ATMs in Ukraine. It was suggested at that time that the one of those nice ATM cryptoprocessors vulnerabilities has been exploited.

Lawrence D'Oliveiro • November 17, 2006 6:24 PM

Do you find it depressing being a security researcher? Describing a flaw doesn’t seem to be enough for you to get taken seriously by those who are supposed to be responsible for maintaining security. Then when you try to prove your point by demonstrating an actual attack, instead if admitting you were right, they get you arrested and thrown in jail.

swiss connection • November 18, 2006 7:18 AM

@lawrence

Interesting thought. Let’s suppose I can demonstrate this vulnerability. What do I do? Do I call the BBC or CNN and pull a couple of thousand dollars out some celebrities bank account in front of the running camera, or do I pull a few hundred thousand dollars secretly and run.

Which is more likely to get you arrested?

Michael McKay • November 18, 2006 12:00 PM

As a former financial standards member and designer of financial HSMs, I can see this paper is exploring the ramifications of two known weaknesses. The combination of the two together may lead to more effective attacks than was generally thought – but at this point I’ve only done a quick skim of the paper.

I have a bit of bad news for those trumpeting the security of chipcards as a solution — ironically they are the main reason why ISO 0 format PIN Blocks still exist. I can’t count the times that we have attempted to eliminate that format in the standards group (pretty much successfully in the USA I might note). Although I’m a bit hazy on early chipcard history, I believe the original reason chipcards started using ISO format 0 was a situation when the chipcards needed to accept an encrypted PIN before the account number was known. In any case, I’ve heard of multiple places where chipcards ended up using ISO 0 Pin Blocks.

There are ways to eliminate this need at the protocol level, but it is notoriously hard to change these things once they get implemented. Worse the HSM designs have to support them as long as they are still in use. I can’t speak for all HSM vendors, but the one I used to work for provided mitigations by giving the HSM owner very fine grained controls over the HSM API. The HSM owner, using k-of-n schemes of multifactor user identification, can disable individual commands and/or protocol-primitives (such as ISO 0 support).

Some of the following comments are pretty similar to the ones I made here the last time an attack of this type was mentioned here. Not so ironically the root cause of that problem was the same (where it was revealed some British banks were still using non-ISO format 3 PIN Blocks).

Speaking of how hard it is to change these things, you have to realize a couple of thing about the financial security area. The first is that any change is typically very expensive, and extremely slow at its best when compared to say a OS or application patch. The biggest reason is the large fleet of remote (and poorly connected) hardware devices. Although it has been slowly changing, you can’t assume universal connectivity for the vast majority of POS devices (the integrated POS device, like the PIN Pads attached to supermarket may have 5 or more different protocols hops, none of which allow arbitrary messages to be sent back and forth). Combine that with the fact that client devices are deployed in the millions and have only limited remote update capabilities. The devices are extremely cost sensitive– which means they have minimal functionality and any major change means they have to be replaced altogether. Another reason for the slow pace of change is that financial networks consist of many participants running mission-critical transactions. Any changes have to be coordinated, tested, usually supported in parallel, and eventually phased-out.

Put these altogether, and you will find extremely slow response (compared to what application or OS level security researchers are used to). My favorite big example is the transition to 3DES away from single-DES; which believe it or not is still ongoing! The standards committee I served on knew about this potential from the beginning, and started making active recommendations to phase out single-DES in the mid-to-early 90’s. Around 2000 or so (long after the EFF DES Cracker), large entities like Visa and MasterCard started to requires it (or more accurately threaten to charge more for single-DES transactions). The deadlines kept changing, but last I heard the USA was supposed to have no more single-DES ATMs by 2005 (who knows how many waivers have been issued). The USA POS market still is not free of single-DES terminals. Many other countries were even slower than the USA.

This is a lot more complicated than simply sending out a patch! Having said that; I’ve also found many banks to be unresponsive to security issues. In some cases I think this is OK, one of the lessons I’ve had to learn as a financial security designer is that banks are the experts on risk management. I can advise and point out the risks, but at the end of the day it is just one factor in an incredibly broad set of risks the bank is managing. That is not to say that the banks are always right; and more perniciously there are a number of situations where security decision makers are not subject to the proper amount of liability (IMHO POS security is weaker than it should be in the USA because of muddled liability).

Finally, I’d mention that the other HSM command the paper deals with is also a known weakness. My former company did not offer that specific function on its general purpose financial HSMs, because of exactly the types of attacks mentioned (being able to associate attacker chosen accounts with an existing account). It was actually a long running conflict between us and the dominant European HSM manufacturer; we insisted they buy a special purpose system to perform those types of functions while our competitor made it available on the same box (save money vs. doing security right).

As I said in the beginning, they took two known weakness and combined them in a specific implementation to come up with something that was worse than generally known. At first glance, I believe some of these problems can be solved (or at least mitigated) at the HSM API level (and at one point that would been my job – but not any longer 🙂 Most switches don’t need the change PIN function, so that should be disabled. The tricky part is when you can’t just simply shut-off a feature (like if you HAVE TO support ISO-0 for those pesky chipcards), in that case you try to design a very restricted special purpose API will be less subject to attacks of this type. Not always easy to do, but that was what made that job fun!

yRFID • November 19, 2006 3:14 AM

Do you find it depressing being a security researcher? Describing a flaw doesn’t seem to be enough for you to get taken seriously by those who are supposed to be responsible for maintaining security. Then when you try to prove your point by demonstrating an actual attack, instead if admitting you were right, they get you arrested and thrown in jail.

Odelia Moshe Ostrovsky • November 20, 2006 12:09 PM

I am glad to see all the remarks here.

Regarding the EMV issue – the attacks are relevant also to chip cards, since in the EMV world the PIN verification process remains the same when online PIN verification takes place (and currently, due to VISA requirements for a certain hardware configuration in ATMs, there is no other way for ATMs to verify the PIN but online).

The attacks in the paper are taking advantage of 3 functions:
“translate???, “calculate_Offset??? and “calculate_PVV???.

The “translate??? function uses new weaknesses (of ISO_1 format) as well as known weaknesses (of ISO-0 format), which together enable exposure of the PIN code even outside of the issuer environment – for example in switches. Disabling the “translate??? function at the HSM as suggested cannot be a solution, as every switch application require this function.

The “calculate_Offset??? function retrieves in clear format the difference (SUBmodulu10) of the customer intermediate PIN and the Final PIN (which is used by the customer). So what if we know one of the values in advance? It means that we know 2 out of 3 variables of the equation and thus it is very easy to compute the missing secret variable. Adding the “calculate_Offset??? function’s weaknesses to the ISO_1 weaknesses – enables reveling 1 PIN code per 1 (!!!) HSM call.

Disabling the “calculate_Offset“ function or the “calculate_PVV??? function in the HSM is not a solution for financial institutions that allow their customers to select their own PIN code because the capability of “customer selected PIN??? is enabled by using these functions.

Some of the attacks that use the “calculate_Offset??? and “Calculate_PVV??? functions are possible in switches. These functions exist in switches since the HSMs come with the complete set of the PIN processing API, as it was widely believed that functions requiring issuer’s keys cannot do any harm if the respective keys are unavailable. We describe in the paper how the “calculate_Offset??? and “calculate_PVV??? functions can also be used to expose customers PIN codes even without the issuer keys.

As in the previous cases, disabling these two functions in switches is also not a good solution for preventing the attacks – since issuers cannot prevent the switch employees from re-enabling the functions and use them maliciously.

Michael McKay • November 21, 2006 3:21 AM

I read Odelia’s comments, and mostly agree with them. Let me clarify a few points:

1) I never suggested disabling the translate function. This is mandatory functionality for a switch.

2) The calculate_Offset and Calculate_PVV functions are not needed by switches, unless the banks want “not-on-us” PIN Change transactions, something I’ve never heard requested.

3) If the switch personal can re-enable the commands, than the HSM has a real security problem. At one point HSM enabling and disabling commands were considered kind of separate from sensitive mode. But by the mid-90’s we knew that enabling optional functionality was a real threat (thieves made money that way), so I’ve generally considered it mandatory that a financial HSMs have either dual-control or K-of-N user management to enable or disable “weak” commands (but upon reflection I don’t recall a statement to this effect in ISO 13491).

To recap for the people reading this who are not HSM API designers (just about everyone I guess), a financial HSM typically has to support have many, many different functions. The financial HSM API has two basic modes – sensitive and operational. The sensitive mode is used to configure the HSM, load keys, and perform other sensitive operations (most HSM users will think of enabling a CA signature operation).

Operational mode functionality is supposed to be safe – e.g. they will provide the cryptographic functionality needed and nothing else (won’t provide an useful oracle attack, etc.). The translate PIN command is an example of an operational command, which will be safe so long as certain aspects of the environment are carefully constrained (such as restricting the loading of key to sensitive mode). A way to view this paper is that is presents a method of attacking operational mode commands in such a way that they inappropriately serve as an oracle.

Some of these are operational mode commands have known weaknesses, but are required for certain solutions. A good (and relevant) example of a “weak command” is one that has the ability to accept an ISO 0 format PIN Block. Over the years I’ve made a specialty of trying to get rid of the need for these commands (not easy, usually have to change the environment as well as the HSM API).

4) As I mentioned before, most of the HSM API’s I’ve seen for PIN Change functionality are inherently weak. This is both because the command generates PVNs (thus opening a possible oracle attack based on the number of possible PINs – instead of the normal HSM requirement to make oracle attacks no more valuable than exhaustive key attacks), and because the command needs the ability to associate encrypted PINs and account numbers. A true operational mode command should prevent an attacker from putting their PIN onto a chosen account (hello Bill Gates!), or submitting a known PIN to a PVN generating command. The naive approaches I’m familiar with have a customer entering the current and new PIN at an ATM using the same structure and keys as a normal PIN transaction; and believe me, it has a lot more weaknesses than the attacks mentioned by the paper.

I’ve actually designed a robust ATM based PIN Change HSM API (for a major British Bank). Our security goals (commands with no known weaknesses) could only be accomplished by changing the environment, which meant modifications to both host and ATM applications were needed. There are also a lot of nuances, for example consider that the account number of the card has a many-to-many relationship with actual bank accounts (an ATM card can access a checking and saving account, while the same checking account may be accessible by multiple ATM cards). This relationship needs to be formally stated and protected by a signature or MAC, which can be checked by the HSM before it associates the new PIN with the account. You also need to carefully keep track of three types of PINs (reference PIN from the database, trial current PIN, and proposed new PIN), each of which should be encrypted with it’s own type of key and/or structure (so they can’t be substituted for one another). It was a design I was proud of, and at one point we (I and my counterpart at the bank) were prepared to present a paper on this, but than I switched jobs and it kind of fell apart.

Again, to clarify things for the people who are not HSM API designers.

Designing operational mode commands is pretty much a black art, and this is an area where I’d like to see more formal methods and tests developed. Mike Bond and Ross Anderson have done some good work in this area, and just now I’m starting to see some more academic work. Part of the reason I’m making such in-depth posts is to encourage people to look into this area (and make it better).

Brandy • November 21, 2006 3:35 AM

Hi,
is it possible that there are systems which use the same static PIN block key again and again ? As far as i understand the attack on the PIN block transfer function, it only makes sense if the originator of the PIN block, e.g. an ATM, always uses the same PIN block key. And this is very hard to imagine, it would be unthinkable here. The systems i know use an unpredictable new key for each transaction, so it would not be possible to generate the lookup table that seems to be required for the attack (to be exact, the table would not be of any use). Am i missing something here ?
Cheers,
Brandy

Ronnie • November 21, 2006 3:46 AM

Bruce,

Is this in any way connected to the Decimalisation attack theory expounded by Mike Bond back in 2003? As I recall this too was based on the ability of a Bank insider to make use of ‘redundant’ HSMs for guessing PIN values.

These theories although extremely valid, if unfortunatly as yet devalued by the UK Courts, are in my view extremely interesting but too complex.

To defraud a bank at the level suggested insiders have far more opportunity by old fashioned fraud and forgery facilitated by computers than to go to all the effort involved in cracking an algorithm.

Despite their public image most banks are cavalier about securing customer data and are happier to take the small losses rather than secure their operation.

Odelia Moshe Ostrovsky • November 21, 2006 10:04 AM

Michael,

I agree with most of the things that you wrote. Some of the solutions we though about were as you mentioned. But I though that major changes are not something that the industry will be able to handle. So I started thinking how to enhance the security within the standards limits. I though that removing ISO-1 is crucial and can be done since the ISO-1 format was approved only in the last few years (so only those who used the ISO-1 will have to adjust their applications while others will get a more secured environment without performing any changes to their application, still getting the upgrade software that removes the ISO-1 implementation will be not simple). Removing ISO-0 will affect the whole industry and it will take years to implement the changes in practice. Do you think that removing ISO-0 is something that the ISO group will consider?

Regarding disabling function: I agree that if the switch personal can re-enable commands, then the HSM has a real security problem. But the functions “calc_Offset??? and “calc_PVV??? were not considered weak and in most HSMs there are not under the list of sensitive operations. I do believe that K-of-N approach is definitely enhancing the solution but in switches the solution must cover all areas. Even K-of-N persons at a switch should not be able to reveal PIN codes. In perfect world no information leakage is permitted. The best solution should be that even if all employees at the switch are corrupted – but the keys are well protected – the corrupted employees should gain no access to secret data.

I very much agree that PIN Change functionality is weak and that this is the outcome of using for “PIN change??? the same structure and keys as a normal PIN transaction. As you wrote, a true operational mode command should prevent an attacker from putting their PIN onto a chosen account. So it is obvious that ISO-0 is not very secure (and ISO-3 as well) since it is possible to find more than one account that will fit a PIN block – but how can anyone explain the fact that ISO group approved the ISO-1 format, which can fit to ANY account????

It is extremely interesting to design commands with no known weaknesses. For “PIN change??? this can work, as the bank will be the one to enforce the change and will be responsible to update all his applications. I started to design such a solution for the “translate??? function but it seems that it will requires changing all applications involved (ATM, Switches, verification facilities, “stand-in??? facilities). In order for it to be a complete solution – the switches should also adjust their application. How can this be enforced? For example, if one bank decides that his PIN codes will be formatted differently, all switches around the world should be able to handle this new format, otherwise this bank’s customers will not be able to use their cards everywhere. Even if ISO group will change the standard – as long as old formats are supported, the problem remains.

Michael McKay • November 21, 2006 12:16 PM

Odelia became confused because I made a mistake about which ISO PIN Block format was which (since I was part of the ANSI X9 organization, I’ve always just thought of the “good one” as the “ANSI PIN Block” 🙂

ISO Format 0, which consists of both the PIN and an account number is the “better” format (and corresponds to the ANSI PIN Block). ISO Format 1 only uses the PIN, and ISO 2 adds some additional random material; and both have big weaknesses (ANSI X9 specifically bans their use). If you want the details, look at ANSI X9.9 or ISO 9564 part1 (I probably should have looked it over myself 🙁

Making the changes universal is a tough problem. At the very least this attack helps people recognize that the PIN Change commands are “weak” one. And we are both in full agreement that it is hard to solve the problem without changing the environment.

Michael McKay • November 21, 2006 12:28 PM

@Ronnie, the decimalization attack was similar, in that it involved the manipulation of an HSM API – one that was believed to be a proper operational mode command (see above for definition).

That problem was a lot simpler to solve though. Basically HSM vendors removed the the decimalization table from the API inputs, and instead required that it be a configuration value that could only be changed when the HSM was in senstive mode.

Still this was a good attack, and illustrates why the financial HSM APIs should have more scrutiny. To my knowledge, only two HSM vendors have made their API’s public (nCipher and IBM). I wish this was more common, but most HSM vendors consider their API to be a proprietary trade secret.

Todd • November 21, 2006 7:43 PM

This is a very interesting discussion. I am one of those “HSM designers”, and I am also a participant in the ANSI standards group that defines many of these standards under discussion. In my 20+ years working in this area, I can tell you that it is a very large ship that is very slow to change direction. As others have pointed out, while many would love to change the PIN block standards and other related standards, it simply cannot be done except over the course of many years – and even then, the banks demand that HSM vendors continue to support “legacy” formats and standards which will still be in use many years after they have been dropped as approved standards. We all wish it was not this way, but there is not much you can do about it – because of the large and diverse set of hardware and software in use, and because banks are very cautious about changing things in the security arena.

Having said that… I would like to let people know that the ANSI committee is right now working toward a new PIN block standard that would alleviate the known problems. However, it is likely to be quite a few years before it appears, and quite a few years beyond that before it is in widespread use.

By the way – for those who are less familiar with this world of standards, ANSI and ISO advise each other, submit proposals to each other, and try very hard to end up with finance industry security standards that are the same.

Don Davis • November 22, 2006 10:05 AM

I am a journalist writing an article about this attack. Anyone with knowledge of ATM cards and networks who would like to provide their thoughts on the significance of this paper, please contact me at don.davis@sourcemedia.com.

Don

JR • November 22, 2006 11:21 AM

The threat is significant and immediate.

It is quite possible that somewhere in the world an insider is already working on it. It is unreasonable to assume otherwise.

ISO-1 and most if not all legacy PIN block formats should be banned and banished from all active banking HSMs, ATMs, EPPs etc. as soon as possible. The ban must be substantiated by an audit.

Anonymous • November 22, 2006 12:20 PM

If an insider would have physical access to the HSM they’d be able to easily decrypt any information going in/out of the HSM when they change master keys. All the insider would have to do is sniff transactions going into the HSM and later decrypt them with the master key which he/she inputs into the HSM during the 30 – 90 day key change cycle.

JR • November 22, 2006 12:38 PM

To Anonymous:

  • The attacks do not require physical access. This is the main point of the research article.

  • Nobody is supposed to know the master key. Where I consult, no one does.

Omer Berkman • November 22, 2006 5:02 PM

To Brandy,

Transport keys may certainly change. However, parameters to the API functions that control the keys to be used in the API function come from the outside so the attacker can always use the same key. Additionally, when a transport key is changed between, say, an ATM and the attacked HSM, so that encrypted PIN blocks start to arrive encrypted with a new key, the attacker can use the translate function to change the encryption of the block from the new key to the desired one.

Donald • November 24, 2006 9:43 AM

The technical bit of the paper is ok, but it becomes highly unscientific where the authors imply that possible many phantom transactions are caused by this technical issue. That would require in-depth investigation of such transactions, which I don’t see in the paper.

I recognize that all scientist wish to do policy-relevant research, but I don’t think it is a good thing to expand a technical finding so easily and unscientifically into the discussion on causes of phantom-transactions (where family members are the real cause instead of the technical holes).

John • November 24, 2006 10:02 AM

Family members? Tell that to the victims of the Dollar Tree, Officemax, Wesco, Arco, GB, etc, etc frauds.

Donald • November 25, 2006 3:10 AM

John. I should clarify that my comment was coming from Europe; I acknowledge that the security culture and measures in the US is different (also depending on the nature of the card: debit/credit). So frauds in the US may have additional causes (unrelated to the customer). Still I don’t see on what grounds the paper would classify this specific technical issue as the main source of trouble for phantom transactions or all the frauds you mention. That would require additional research into those frauds, which I don’t read in their paper.

Omer Berkman • November 25, 2006 9:40 AM

Donald & John,

We were not careful enough in the sentence regarding phantom withrawls in the Conclusions. The word “may” should have been added (as is the case in the Introduction).

Thomas Brandtstaetter • December 4, 2006 8:59 AM

This attack scenario is tricky indeed, but not really new. It makes absolutely sense, to improve the technical implementation as described:

  • disable Refomat-Options at switch HSM and allow for PIN-Block Key-Translate (i.e. TRANSCIPHER) only
  • consequent usage of ISO-0 PIN-block format all the way through (from ATM through switch to authorisation instance)
  • correctly bind customer data and check for correct usage within HSM
  • keep vital operations and systems bank-internal (which doesn’t really meet the ideas of the outsourcing market)
  • improve ISO8583 Protocols by binding the data-entry-entity (ATM) to the HSMs being used
  • be good (god) to your employees
  • and so on

In total, I would assume, that attacking a webserver behind the SSL-Tunnel is easier for an insider adversary, in order to get valuable credit-card information.

Without a secure TRANSCIPHER function (HSM internal) at the switch-side (the frontend webserver in that case) you would be worse than the weekness of the PIN Translate implementation discussed here.

After all, if you are able to introduce “additional unauthorized” software in production systems, you could easily attack side-channel-wise after the PIN-Authorization process and directly bypass it’s decision and draw from the account directly.

Thomas Brandtstaetter

The world is a puzzle, with everyone puzzling (T.B.)

Thomas Brandtstaetter • December 4, 2006 9:06 AM

Addition to my comment regarding the similarity in attacking SSL-secured services, assuming one can introduce additonal unauthorized software:

A New Vulnerability In RSA Cryptography

A new vulnerability associated with RSA cryptography has been found, which works by spying the CPU internals with a spy program running on the same computer as the crypto application. Dedicated systems (like CAcert´s certificate generation) are not affected, only multi-tasking and multi-user systems are affected.

http://blog.cacert.org/2006/11/193.html

Best Regards, Thomas Brandtstaetter

mohit • December 6, 2006 10:47 AM

Hi,
I have followed this discussion with great interest. However, I am unclear as to how knowing all the PINs flowing through a switch would be of any help. How would the attacker know which account number the PIN corresponds to, i.e, which account to withdraw the money from.
(A previous post also wondered similarly about the practicality of this weakness.)

Mark Linton • December 6, 2006 12:09 PM

Within the threat model section of the paper, it discusses the attacker requirements. I have the following question related to this information.

By requiring logical access to the attacked facility, does this describe the requirement of the attacker to interact with the HSM through the APIs? If so, what are the typical interaction methods (i.e. what interfaces are normally available/used, and what’s required for their interaction?)

To combat these requirements, what compensating controls would be most effective at limiting the methods of interactions to only authorized components?

Thanks.

Very interesting paper and discussion by the way…

Michael McKay • December 7, 2006 12:33 AM

@Mohit – The PINS are associated with a “PAN” (Primary Account Number). At one point the PAN might have actually been the customer’s account number, but mostly now the PAN is effectively a unique number that corresponds the magnetic card itself. The PAN has a many-to-many relationship with actual account numbers (e.g. one card may access multiple accounts, and an account many have multiple cards). During most of the transaction, the PAN is the primary identifier, it is only when it reaches the issuer host that it becomes associated with an account. In practical terms, knowing the PAN is good enough to mount an attack.

@Mark Linton – Most financial HSMs are now attached through TCP/IP, usually on a private sub-net. Historically I think virtually every type of computer connection has been used in the past – Asynch, BiSynch, IBM and Tandem channel attached, PCMCIA, SCSI, PCI, etc. (USB is the only mode I’m pretty sure has not been used, although there are non-financial HSMs that use it).

The attacks definitely require some type of interactive communication with the HSM, so controlling that carefully is a mitigation measure. Some of this gets into the “just how rogue is the switch”. A purely bogus switch would not bother with this attack method, and just use their knowledge of the cryptographic master keys to directly recover the PINS. So this type of attack could occur at a “careless switch”, which has not disabled unneeded commands and allows communication access to the HSM.

I have not read the MSNBC article all the way through yet, but I’m quoted as saying that the problem is worrisome. This is correct as far as it goes, but I gave a lot of qualifiers first before I allowed that it would become worrisome. For instance, the PIN Translate feature has to support ISO Format 1/2 PIN Blocks, something that most HSMs do not by default support. So it does become worrisome, when a HSM is configured to support both of these weak commands, and is being operated by a careless switch.

As Thomas Brandtstaetter points out, there are easier places to attack. Some are much easier! The difference is that these are mostly done by issuing institutions, and flaws here only effect their own customers. What made this attack interesting was the potential for a careless switch to jeopardize multiple institutions (although I guess this really is just a shade of gray, since poorly handled master keys could have the same effect).

mofat • January 30, 2009 5:15 AM

i want to know more about how to hack a pin code of a bank card or to hack into an acc on the internet

Leave a comment

Login

Allowed HTML <a href="URL"> • <em> <cite> <i> • <strong> <b> • <sub> <sup> • <ul> <ol> <li> • <blockquote> <pre> Markdown Extra syntax via https://michelf.ca/projects/php-markdown/extra/

Sidebar photo of Bruce Schneier by Joe MacInnis.