Slashdot Mirror
Citibank Tries to Hush ATM Crypto Vulnerability
palme999 writes "Citibank is trying to get a gag order for new
vulnerabilities found in the cryptographic equipment commonly used to protect the PINs of ATM transactions. The vulnerabilities came to light during a court case involving 'phantom' ATM transactions that users deny making but that banks still charge to customers accounts because they claim their systems are secure."
I love ATM fees. I can use a 'FREE' ATM and still am charged a fee from my own bank! With all this dough they are raking in, they should be COMPLETELY secure!!!
If at first you don't succeed... How does that go again? Ah, forget it.
Hehe.
The ATM in the WalMart by us runs Windows.
And it crashes, gives blue screens, and popup error messages all the time.
Who needs security when the system can't even run stabily?
Location: Mt. Xinu
How do bank atm lines work anyways? Are they over phone or satelite? Has anyone ever managed to break into them remotely?
up 12 days, 22:30, 2 users, load averages: 993.20, 994.21, 994.56
*makes note to limit user processes...
I've been using automated debit for years to pay all of my bills.
Maybe I can get all of that money back.
From The Register.
Nice formatting, why not go vomit on some toddlers while you're at it?
I watched the atm(called a cash machine here in the UK) I was withdrawing from reboot.. was using os/2.. Im checking now to see if it actualy deducted from my account..
moo
Does anybody smell a class-action for ATM users who have filed these complaints? It would probably work similarly to the CD price-fixing settlement that was in the news lately, since it would be hard to identify the specific members of the class.
Stop by my site where I write about ERP systems & more
I wonder how much that court case cost to take on a huge corporation like Citibank because they blatantly charged you $1 per transaction for a dozen transactions that never happened last month. Hardly seems worth the effort to save $12, but I'm glad someone is fighting for the little guys...
We all want this to happen! Citi will fix it because it is in the best interest of their customers. Releasing the info would increase the risk of **YOUR** money stolen. Give them time, but follow up with them to ensure it is fixed.
If Citibank sez that their systems are secure. Tell 'em to prove it.
Dolemite
Save the World! Use a Quote!
This is the kind of shit that scares me about the DMCA...
Snooze and you lose your sushi.
Thanks for making sure it looked okay!
Oh you guys, that's just Citibank's patented Security Through Litigation (tm) method. I hear it works wonders on keeping financial info secure.
Mostly it affects where banks choose your pin for you (which happens in the UK among other places) based upon a hash of your account number. Not that a 4 digit pin was particularly strong an encription method, but this paper merely says it's even weaker when based of the users account number. However, it seems this crack is most easily acheived by an insider, not your local script kiddie with Aunt Edna's ATM card.
8
Read more here:
http://www.kuro5hin.org/story/2003/2/20/61350/054
Why is it they can even try things like this without massive public backlash? They would be far better off accepting the "new" information, and promising to work hard to always keep their systems secure.
I'm sure certian companies would love to see legal actions like this get upheld by a court.... Oh well, I guess we can always move to Norway... I wonder if they'd let me live on sealand once all my rights are gone here...
My Linux Command of the Day site : LCOD
From the article
What the bank is doing is very irresponsible. I hope they get lots of bad publicity for this. Getting on /. is a good start.
I swear this is a duplicate from today but I can't find the original post. Am I going crazy?
/syle
Citibank CEO: "Guys, we need a new algorithm for our pin-codes. Our current 'pin-code-backwards'-encryption wasnt sufficient."
Germany Tech-boy: "I know one very strong. It's called brot13 and is is supposed to be very strong."
Another teccie: "Dude, its ROT13 and I have heard it is the strongest encryption algorithm ever. Good choice!"
So they submitted it to /. to gag it for them.
Much quicker then a court order.
We should teach our kids at school how to raise a 200-digit challenge number to a secret 200-digit power, modulo a 200-digit composite public key, all in their head. Then ATM machines could use this math to achieve secure authentication.
Tell 'em to prove it.
Well, as nice as it would be to have them prove the security, it is technically impossible to prove that a system is secure. It is only possible to prove that a system is not secure by exposing a flaw.
neurostarhttp://www.theregister.co.uk/content/55/29425.html
The Register is running a story with more content
Which also explains in laymans terms how the two guys in the submitted link went about working out the vulnerability
"Citibank is trying to get a gag order for new vulnerabilities found in the cryptographic equipment commonly used to protect the PINs of ATM transactions..."
/. there are probably thousands of geeks downloading it as we speak. I think we can safely say that it is "in the wild"
Now that it has been posted on
Integrate Keynote and LaTeX
I believe that in some countries banks actually install a camera in every ATM they own. They simply take a video or a snapshot of the person making transaction with the machine.
I think this is pretty good idea to record frauds, false claims, and extortions in front of the machine. Personally I don't have a privacy issue in this case.
geek page at KY speaks
involving 'phantom' ATM transactions that users deny making but that banks still charge to customers accounts because they claim their systems are secure
"Honestly, Mr. Citibank Manager, why would I guy several cases of Fort Garry Ale or Guinness? I demand you credit my account.
Trolling is a art,
These attacks defeat machines such as the Racal RG7000 and the IBM 4758/CCA which are commonly used to protect the PINs and keys used in automatic teller machines.
While the IBM 4758 has been cracked before, it's not something that someone can do on their lunch break. What I suspect is being cracked is the little desktop unit that the customer service rep spins around for you to enter your PIN when you sign up for ATM service.
Chip H.
Since this is the case listed as establishing US law on phantom withdrawals, and is listed as a Citibank loss, anyone have further details?
First there was the Phantom Menace, then there was the Phantom Edit, now we have "phantom" transactions... coindidence? I think not.
George Lucas is involved here somwhere.
--
I sense a great disturbance in the fiber, as if a million ATM transactions were suddenly silenced...
http://www.theregister.co.uk/content/55/29425.html
Sorry, HTML formatting doesn't seem to be working...
ATM send encrypted request asking CENTRAL server if it is OK to give you the amount of money you ask for. If yes then gives you money. Central server requests money from your bank when batch is run.
(By central server I don't mean there is only one, I mean that the ATM does not ask you back directly, it asks a machine that is owned and operated by the orginization that owns the ATM)
ATM lines are land lines.
Not exactly, there was a case of a man intercepting the transmission (hacking the land line) and telling the machine to empty itself. I'm not sure he got account numbers and pins or if he just told the machine to mechanically empty all the cash. He got caught and is probably still in jail. If you want to know for sure google for the case. I believe it was overseas. (The Netherlads somewhere maybe)
I do not believe there has been a case of remote comprimise of ATM machines.
I got from the paper, that this attack was somehow based on PINS originally coming from an encryption of the users acct. number?? I chose my PIN number when I set up my acct....not one assigned. Don't most banks let you choose your own PIN number?
Light travels faster than sound. This is why some people appear bright until you hear them speak.........
As a Swede, I'm supposed to trust someone calling himself Palme?
How about we got a link to the submitters profile so that we can value the content of his story in perspective of what he has written in the comments previously?
Not that I wouldn't trust a story like this normally, but I'm having some major trust issues with anyone _choosing_ a screen name that in any part contains the word "palme".
(For everyone to whom the word "palme" means nothing, Palme was the socialist prime minister of Sweden between 1969-1976 and 1982 to his assasination in 1986.)
Civilization is the process of setting man free from men.
How about this:
:)
http://www.phule.net/mirrors/pacc.htm
for formatting?
In Soviet Russia...michael would be rotting in Siberia!
Your money is safe.
The world is simple.
You are with us or against us.
Go buy yourself something, you deserve it.
Those in charge know what they are doing and will take care of you.
Revolutions are never about freedom or justice. They're about who's going to be top dog. -- Kilgore Trout
Link to PDF given in page
Link to PDF
cthread. cthread_fork(). Fork, thread, fork!
A young John Connor figured out how to crack PINs way back in 1991. How is this "News" for Nerds?
Beauty is in the eye of the beerholder.
Well, taken from http://www.sophos.com/support/faqs/savos2.html:
There are no OS/2 specific viruses in circulation but OS/2 computers can still be affected:
* Macro viruses that infect Word, Excel and other Windows mode applications can spread as usual.
* Boot sector viruses can affect the master boot sector, the OS/2 boot sector and the Boot Manager.
* DOS executable file viruses can run on OS/2 systems and infect other DOS executables.
* Any type of file can be stored on an OS/2 server and could infect a vulnerable workstation.
So yes, there are hacks that will affect OS/2, though they might not target OS/2 exclusively.
geek page at KY speaks
With no cash in my wallet, I went to an ATM (Wells Fargo) a few months ago. I withdrew $200, and went along my merry way.
I pulled out my wallet about an hour later. As I was thumbing through my cash to pay for something I discovered a ten dollar bill in the middle of my stack of twenties... HUH? Damned ATM machine ripped me off.
The next time I went by a Wells Fargo branch office, I reported the problem. They mentioned that there was some complicated method for submitting a complaint. I decided that it would cost me a lot more than $10 to try to get it back.
Why are you letting these clowns ruin our country?
Informative? C'mon! I cannot read that. In fact, I stared at it cross-eyed and saw a sailship!
IMHO, I think that was just karma-whoring FP. Anyone else would have thought to hit the preview button. Please, if you are going to mirror or post the text, please preview and make sure it will not throw somebody into seizures...
Updated 20 February 2003
18 February 2003
To: ukcrypto@chiark.greenend.org.uk
Subject: Citibank tries to gag crypto bug disclosure
Date: Thu, 20 Feb 2003 09:57:34 +0000
From: Ross Anderson <Ross.Anderson@cl.cam.ac.uk>
Citibank is trying to get an order in the High Court today gagging public disclosure of crypto vulnerabilities:
http://www.cl.cam.ac.uk/ftp/users/rja14/citibank_
I have written to the judge opposing the order:
http://www.cl.cam.ac.uk/ftp/users/rja14/citibank_
The background is that my student Mike Bond has discovered some really horrendous vulnerabilities in the cryptographic equipment commonly used to protect the PINs used to identify customers to cash machines:
http://www.cl.cam.ac.uk/TechReports/UCAM-CL-TR-56
These vulnerabilities mean that bank insiders can almost trivially find out the PINs of any or all customers. The discoveries happened while Mike
and I were working as expert witnesses on a `phantom withdrawal' case.
The vulnerabilities are also scientifically interesting:
http://cryptome.org/pacc.htm
For the last couple of years or so there has been a rising tide of phantoms. I get emails with increasing frequency from people all over the world whose banks have debited them for ATM withdrawals that they deny making. Banks in
many countries simply claim that their systems are secure and so the customers must be responsible. It now looks like some of these vulnerabilities have also been discovered by the bad guys. Our courts and regulators should make the banks fix their systems, rather than just lying about security and dumping the costs on the customers.
Curiously enough, Citi was also the bank in the case that set US law on phantom withdrawals from ATMs (Judd v Citibank). They lost. I hope that's
an omen, if not a precedent
_____
Abstract
We present an attack on hardware security modules used by retail banks for the secure storage and verification of customer PINs in ATM (cash machine) infrastructures. By using adaptive decimalisation tables and guesses, the
maximum amount of information is learnt about the true PIN upon each guess.
It takes an average of 15 guesses to determine a four digit PIN using this technique, instead of the 5000 guesses intended. In a single 30 minute
lunch-break, an attacker can thus discover approximately 7000 PINs rather than 24 with the brute force method. With a $300 withdrawal limit per card, the potential bounty is raised from $7200 to $2.1 million and a single motivated attacker could withdraw $30{50 thousand of this each day. This attack thus presents a serious threat to bank security.
-- Mike Bond and Piotr Zielinski
Decimalisation table attacks for PIN cracking
February 2003
-----
From: Ross Anderson <Ross.Anderson@cl.cam.ac.uk>
To: ukcrypto@chiark.greenend.org.uk
Subject: Yet another failure of commercial cryptographic equipment
Date: Tue, 18 Feb 2003 17:52:13 +0000
I gave a talk at Cambridge yesterday in which I described a new and interesting family of attacks on cryptographic equipment. These attacks defeat machines such as the Racal RG7000 and the IBM 4758/CCA which are commonly used to protect the PINs and keys used in automatic teller machines.
The paper is available online at:
http://research.microsoft.com/~aherbert/volume63.
as pages 27-30 in the PDF. [HTML below]
I got a fax yesterday informing me that an application is to be brought in the High Court, it seems by Citibank, on Thursday 20th February for `relief in relation to the protection of nformation which they accept as being confidential and which ought not to be in the public domain.'
I hope that no English court would go so far as to censor already published material. However, one just can't tell these days
Protocol Analysis, Composability and Computation
Ross Anderson, Michael Bond
University of Cambridge, England
Security protocols early days
The study of security protocols has been associated with Roger Needham since 1978, when he published the seminal paper on the subject with Mike Schroeder [1]. The problem they investigated was how to distribute cryptographic keys in a network of computers. One solution is to have an authentication service with which all the principals share a key; then if Alice wants to chat with Bob (for example) she can call the service and get two encrypted messages containing the same session key one encrypted under the key she shares with the service so she can read it, and one encrypted under the key Bob
shares with the service so Bob can read it. She can now send the second of these to Bob to establish secure communication. The mechanism that Needham and Schroeder designed for this evolved into Kerberos, which is now part of Windows and is probably the most widely used of all uthentication protocols.
Security protocols are now embedded in a great many applications, but it is common to find unexpected bugs in them. For example, many banks used to encrypt each customers PIN using a key known to their ATMs and write it on the ATM card magnetic strip. The idea was to provide a limited service when the network was down. Years later, a villain discovered that the account number and the encrypted PIN were not linked: he could make up a bank card with his own encrypted PIN but someone elses account number, and loot their account. He went on to steal a lot of money, and once in prison wrote a manual telling everyone else how to do it too. The banks had to spend millions on changing their systems.
Clarifying the assumptions
Researchers started to gnaw away at the protocols described in the literature and found fault with essentially all of them. The failure to bind protocol elements was one frequent problem; another was that old messages could be
replayed. In the case of the original Needham-Schroeder protocol, for example, the freshness of the key generated by the server was guaranteed to only one of the principals. This was not necessarily an attack, as its inventors only
claimed to protect honest insiders from dishonest outsiders. However, it led to a debate about the assumptions underlying security protocol design.
Do we protect only against outsiders, or against insiders? Against the malicious, or the merely careless? For example, if we use timestamps to guarantee protocol freshness, are we vulnerable to principals who carelessly let their clocks
run slow? Do we only consider an attacker to have won if he can impersonate an authorised principal, or do we need to stop people abusing the protocol
mechanisms to perform a service denial attack?
The early attacks led to a second seminal paper, which Roger wrote with Mike Burrows and Martin Abadi in 1989 [2], and which introduced a logic of
authentication. This enables an analyst to formalise the assumptions and goals of a security protocol, and to attempt to prove its correctness. When a proof cannot be found, the place at which one gets stuck often shows where an attack can be mounted. This style of analysis turned out to be very powerful, and a large literature quickly developed in which the BAN Logic
and other formal tools were developed and extended to tackle a range of problems in protocol design.
One of the remarkable things about the study of security protocols is that they have not become a solved problem. One might think that managing the
objects associated with authenticating users over a network passwords, keys and the like was a fairly compact problem which would have been done to death within a few years. However, the more we dig, the more we find.
Since 1992, Roger has hosted a protocols workshop every Easter. Early events dwelled on matters of authentication and logic, but by the mid-90s, the growing interest in electronic commerce was yielding papers on mechanisms for micropayments, bets, streaming media, mobile communications and electronic voting. Later years brought work on PKI, trust management and copyright enforcement. More and more problems come along as more and more businesses reinvent themselves online; threat models have also become more realistic, with dishonest insiders displacing the mythical evil hacker on the Internet.
Dishonest insiders, and the composition problem
Over the last two years, we have been exploring exactly how one might re-engineer cryptography to cope with dishonest insiders. One conclusion is that the analysis of security protocols must be extended to application programming interfaces. This is because the crypto keys used in authentication and payment protocols are often kept in separate hardware security processors, or at least in cryptographic libraries, to which access can be restricted using physical or logical mechanisms. However, an interface has to be exposed to the application program, which will occasionally be suborned whether by a corrupt insider, or by malware. How much harm can be done, and how can we limit it?
Protecting protocols was hard enough, and yet the typical protocol consists of 35 messages exposed to manipulation. The API of a modern crypto library or hardware cryptoprocessor may contain 30500 callable functions, many with a range of options. This provides a very rich and complex environment for mischief.
Attacks often involve using two separate echanisms provided by the cryptoprocessor for different purposes, each of which could be innocuous by itself but which combine to cause trouble. For example, it is common to compute a customer PIN by encrypting the account number with a PIN
derivation key: the cryptoprocessor then returns the PIN encrypted with a PIN storage key, so that the application has no access to its clear
value. So far, so good. Then there is another transaction that can be used to encrypt a communications key under the terminal key loaded in an ATM. Here things start to go wrong, as the cryptoprocessor does not distinguish between a terminal key and a PIN derivation key; it considers them both to be of the same type. The upshot is that an attacker can supply the device
with an account number, claiming that it is a communications key, and ask for it to be encrypted under the PIN derivation key.
Attacks like this extend protocol analysis all the way to the composition problem the problem that connecting two systems that are secure in
isolation can give a composite system that leaks. This had previously been seen as a separate issue, tackled with different conceptual tools.
Differential protocol analysis
We are now working on the second generation of API attacks, which exploit the application syntax supported by the cryptographic service. These attacks are even more powerful, and at least as interesting from the scientific point of view. PIN generation provides a neat example here too. In more detail, the standard PIN computation involves writing the result of the encryption as a hex string and decimalising it. As some banks like to let customers change their PIN to a more memorable number, there is a provision to add an offset to give the PIN that the customer actually enters:
Account number: 8807 0123 4569 1715
PIN derivation key: FEFE FEFE FEFE FEFE
Encrypted account number: A2CE 126C 69AE C82D
Natural (decimalised) PIN: 0224
Offset: 6565
Customer PIN: 6789
The typical implementation requires the programmer to send the cryptoprocessor the account number, a table describing the decimalisation (here, 0123 4567 8901 2345) and the offset. The processor returns the PIN, encrypted under the PIN storage key. The designers do not seem to have realised that a crooked programmer can manipulate the decimalisation table and the offset as well as the account number. A multitude of attacks follow. For example, one can send in an account number with a decimalisation table of 1111...11 to find out the ciphertext corresponding to a clear PIN of 1111, and then with a decimalisation table of 0111...11 to see if there is a zero in the first four digits of the encrypted account number (if so, the PIN, and thus the ciphertext output, will be different). By manipulating the decimalisation table further,
he can get all the digits in the PIN, and by then playing with the offset he can get their order. In total, the attack requires only 1525
unprivileged cryptoprocessor transactions to discover the PIN on a single target account.
This second type of attack takes protocol analysis into yet another realm: that of differential attacks. Over the last ten years, a number of techniques have been invented for attacking cryptographic systems by bombarding them with inputs with chosen differences.
For example, in differential cryptanalysis, one analyses the changes in the output of the encryption algorithm; while with differential power analysis, one measures changes in the current consumption or electromagnetic emissions
of the equipment. Now we have examples of how consecutive runs of a protocol can leak information if the inputs are suitably chosen. The resulting differential protocol analysis appears to be very powerful against
application-level crypto.
It will take us some time to figure out the general lessons to be drawn from attacks like this, the robustness principles that designers should use to avoid them, and the analysis techniques that might assure us of a particular
designs soundness. The randomisation of all protocols (another feature of Rogers work) is likely to be important.
Quantitative analysis and multiparty computation
Various researchers have speculated about whether there might one day be a quantitative analysis of protocol security. This might be feasible for
PIN processing applications as we can measure the information leakage per transaction in terms of the reduction of entropy in the unknown PIN. This
leads in turn to a possible real-world application of an attack previously considered theoretical.
Gus Simmons wrote extensively on covert channels in protocols. One such channel that is always present is the balking channel when one of the principals in a protocol signals something by halting and refusing to continue. This is normally considered unimportant as its information capacity is only a third of a bit per transaction. But with systems designed to cope
with large transaction volumes, this need no longer hold. For example, a Trojanned cryptoprocessor could balk when it sees a redetermined PIN. If the PIN length were eight digits, this would be unlikely to hinder normal
operation, but at a thousand transactions a second, a programmer could quickly find a number in a typical nine-digit account number range with just this PIN, and open an account for it. Once this kind of problem is appreciated, one can start to look for attacks that involve inducing rare error conditions that cause the cryptoprocessor to abort a transaction. (They exist.)
A third emerging link is between protocol analysis and secure multiparty computation. In application-level crypto we may have several inputs to a computation, some of them coming from an untrusted source, and we have to
stop users manipulating the computation to get outputs useful for bad purposes. In the PIN decimalisation example above, one might try to solve the problem by blocking tables such as 1111...11. Yet an attacker can get by with scarcely more work by using two normal-looking tables that differ slightly (another kind of differential attack). We might therefore think that if we cant sanitize the inputs to the computation, perhaps we can authenticate them,
and use only those tables that real banks actually use. But building every bank in the world into our trust base is what we were trying to avoid by
using cryptography!
Conclusion
The protocol work that started off a quarter of a century ago may have seemed at the time like a minor detail within the larger project of designing robust distributed systems. Yet it has already grown into the main unifying theme of security engineering. Application-level protocols, and especially those from which an attacker can harvest data over many runs, open up new problems.
The resulting analysis techniques are set to invade the world of composable security, and the world of multiparty computation. The influence, and the consequences, of Rogers contribution just keep on growing.
References
1. NEEDHAM, R.M. AND SCHROEDER, R.M.,
Using encryption
for authentication in large networks of computers. Comm. ACM, vol.
21, no. 12, pp. 993-999, 1978.
2. BURROWS, M. ABADI, M. AND NEEDHAM, R.M.,
A
logic of authentication, ACM Transactions on Computer Systems,
vol. 8, no. 1, pp. 18-36, 1990.
Won't changing your PIN from the initial one the bank assigns you avoid this problem?
The hell? This isn't informative--without any sort of formatting, it's painful!
!#@%*)anks for hanging up the phone, dear.
Don't most ATMs have cameras now that take your picture when you do a transaction?
When these "phantom transactions" occur, I assume there is a picture taken of a dark wraith in a hooded cloak.
But seriously, wouldn't the bank have your picture if you had performed a transaction?
Read any good sonnets lately?
How the hell do you use a pin, if you don't have the card. I'm pretty sure the ATM doesn't let me type in my card number.
Sure I could make a card, if I had the right equipment and had the card for long enough to make it, but in that case I could just as easily use the card.
I guess if I were super clever and I owned a business that used ATM's at the POS I could rig a line sniffer or something to save the ATM card info, then make some cards, then do this hack 15 times until I got the pin #, then I could steal 300.00 a day.
but if I owned a business why would I need to steal money?
Is there some easier way to use the pin #???
because I have been enjoined by this Holy Office to abandon the false opinion which maintains that the Sun is the centre
What's POTS? The best I can come up with is "Piece of The Shit"
Citibank Tries to Hush ATM Crypto Vulnerability..
The problem was discovered in the syste-
*sounds of struggle*
Where are you throwing meeeeee...
What goes across the line is mostly a hash of the pin and some data stored on the card. That's why ATM transactions can only typically occur with card present. I believe this vunerability is based on a weak hash algorithm or something in that region that allows you to derive the original pin much quicker than the 5000 or so guess normally required.
:)
Therefore you'd also need to steal the physical card and make a dupe, so I'm not sure of the potential loss here. Other places where pins are asked for such as online banking may be vunerable however.
I'm probably missing something here, but I'm fairly sure from the Visa transaction specs I've got sitting here you need data from the card and the pin to initiate a transaction. Could be wrong
perhaps that's where you saw it.
I could not justify my existence if I were a turkey farmer. Would I terminate myself? Undoubtably, yes.
One major difference between the US and UK is the liability on phantom and fradulent transactions. In the US, the bank has to prove you performed the transaction. In the UK, you have to prove that you did NOT perform the transaction.
This difference in liability results in vastly different response to vulnerabilities. In the US, a vulnerability like this is taken very seriously, and phantom transactions are tracked down as they cost the bank money. In the UK, since it is the customer left holding the bag, the banks just don't care until they are sued, and, when sued, will deny deny deny.
This is a classic example of Citibank trying to cover up a problem, because it allows the customer, in court, to prove that the problem is Citibank's.
Test your net with Netalyzr
I hope it happens to you again in 6 months. I hope that you make the same decision, and gradually get nickle and dimed into subsidizing Wells Fargo enough so that they can cut fees to people like me.
http://www.ftp.cl.cam.ac.uk/ftp/users/rja14/liabil ity.pdf
From the linked PDF:
Basically, it says that the bank has the burden of proof in the United States, because the court decided it was unreasonable to have the customer "prove" a flaw within the bank's systems. The UK, however, is different. The customer has the burden of proof.
<:
one right there to take your picture of the transaction, and one farther away, so they can see you when you cover it with a post it.
All Troll + "offtopic" mods are meta moderated as "Unfair", because you abused the system.
I sense a new ad campaign in the offing.
to the machine
Updated 20 February 2003
18 February 2003
To: ukcrypto@chiark.greenend.org.uk
Subject: Citibank tries to gag crypto bug disclosure
Date: Thu, 20 Feb 2003 09:57:34 +0000
From: Ross Anderson <Ross.Anderson@cl.cam.ac.uk>
Citibank is trying to get an order in the High Court today gagging public disclosure of crypto vulnerabilities:
http://www.cl.cam.ac.uk/ftp/users/rja14/citibank_g ag.pdf
I have written to the judge opposing the order:
http://www.cl.cam.ac.uk/ftp/users/rja14/citibank_r esponse.pdf
The background is that my student Mike Bond has discovered some really horrendous vulnerabilities in the cryptographic equipment commonly used to protect the PINs used to identify customers to cash machines:
http://www.cl.cam.ac.uk/TechReports/UCAM-CL-TR-560 .pdf
These vulnerabilities mean that bank insiders can almost trivially find out the PINs of any or all customers. The discoveries happened while Mike and I were working as expert witnesses on a `phantom withdrawal' case.
The vulnerabilities are also scientifically interesting:
http://cryptome.org/pacc.htm
For the last couple of years or so there has been a rising tide of phantoms. I get emails with increasing frequency from people all over the world whose banks have debited them for ATM withdrawals that they deny making. Banks in many countries simply claim that their systems are secure and so the customers must be responsible. It now looks like some of these vulnerabilities have also been discovered by the bad guys. Our courts and regulators should make the banks fix their systems, rather than just lying about security and dumping the costs on the customers.
Curiously enough, Citi was also the bank in the case that set US law on phantom withdrawals from ATMs (Judd v Citibank). They lost. I hope that's an omen, if not a precedent ...
_____
Abstract
We present an attack on hardware security modules used by retail banks for the secure storage and verification of customer PINs in ATM (cash machine) infrastructures. By using adaptive decimalisation tables and guesses, the maximum amount of information is learnt about the true PIN upon each guess. It takes an average of 15 guesses to determine a four digit PIN using this technique, instead of the 5000 guesses intended. In a single 30 minute lunch-break, an attacker can thus discover approximately 7000 PINs rather than 24 with the brute force method. With a $300 withdrawal limit per card, the potential bounty is raised from $7200 to $2.1 million and a single motivated attacker could withdraw $30{50 thousand of this each day. This attack thus presents a serious threat to bank security.
-- Mike Bond and Piotr Zielinski
Decimalisation table attacks for PIN cracking
February 2003
-----
From: Ross Anderson <Ross.Anderson@cl.cam.ac.uk>
To: ukcrypto@chiark.greenend.org.uk
Subject: Yet another failure of commercial cryptographic equipment
Date: Tue, 18 Feb 2003 17:52:13 +0000
I gave a talk at Cambridge yesterday in which I described a new and interesting family of attacks on cryptographic equipment. These attacks defeat machines such as the Racal RG7000 and the IBM 4758/CCA which are commonly used to protect the PINs and keys used in automatic teller machines.
The paper is available online at:
http://research.microsoft.com/~aherbert/volume63.p df [4.8MB] (link appears to be broken)
as pages 27-30 in the PDF. [HTML below]
I got a fax yesterday informing me that an application is to be brought in the High Court, it seems by Citibank, on Thursday 20th February for `relief in relation to the protection of information which they accept as being confidential and which ought not to be in the public domain.'
I hope that no English court would go so far as to censor already published material. However, one just can't tell these days ...
Protocol Analysis, Composability and Computation
Ross Anderson, Michael Bond
University of Cambridge, England
Security protocols early days
The study of security protocols has been associated with Roger Needham since 1978, when he published the seminal paper on the subject with Mike Schroeder [1]. The problem they investigated was how to distribute cryptographic keys in a network of computers. One solution is to have an authentication service with which all the principals share a key; then if Alice wants to chat with Bob (for example) she can call the service and get two encrypted messages containing the same session key one encrypted under the key she shares with the service so she can read it, and one encrypted under the key Bob shares with the service so Bob can read it. She can now send the second of these to Bob to establish secure communication. The mechanism that Needham and Schroeder designed for this evolved into Kerberos, which is now part of Windows and is probably the most widely used of all authentication protocols.
Security protocols are now embedded in a great many applications, but it is common to find unexpected bugs in them. For example, many banks used to encrypt each customers PIN using a key known to their ATMs and write it on the ATM card magnetic strip. The idea was to provide a limited service when the network was down. Years later, a villain discovered that the account number and the encrypted PIN were not linked: he could make up a bank card with his own encrypted PIN but someone elses account number, and loot their account. He went on to steal a lot of money, and once in prison wrote a manual telling everyone else how to do it too. The banks had to spend millions on changing their systems.
Clarifying the assumptions
Researchers started to gnaw away at the protocols described in the literature and found fault with essentially all of them. The failure to bind protocol elements was one frequent problem; another was that old messages could be replayed. In the case of the original Needham-Schroeder protocol, for example, the freshness of the key generated by the server was guaranteed to only one of the principals. This was not necessarily an attack, as its inventors only claimed to protect honest insiders from dishonest outsiders. However, it led to a debate about the assumptions underlying security protocol design. Do we protect only against outsiders, or against insiders? Against the malicious, or the merely careless? For example, if we use timestamps to guarantee protocol freshness, are we vulnerable to principals who carelessly let their clocks run slow? Do we only consider an attacker to have won if he can impersonate an authorised principal, or do we need to stop people abusing the protocol mechanisms to perform a service denial attack?
The early attacks led to a second seminal paper, which Roger wrote with Mike Burrows and Martin Abadi in 1989 [2], and which introduced a logic of authentication. This enables an analyst to formalise the assumptions and goals of a security protocol, and to attempt to prove its correctness. When a proof cannot be found, the place at which one gets stuck often shows where an attack can be mounted. This style of analysis turned out to be very powerful, and a large literature quickly developed in which the BAN Logic and other formal tools were developed and extended to tackle a range of problems in protocol design.
One of the remarkable things about the study of security protocols is that they have not become a solved problem. One might think that managing the objects associated with authenticating users over a network passwords, keys and the like was a fairly compact problem which would have been done to death within a few years. However, the more we dig, the more we find.
Since 1992, Roger has hosted a protocols workshop every Easter. Early events dwelled on matters of authentication and logic, but by the mid-90s, the growing interest in electronic commerce was yielding papers on mechanisms for micropayments, bets, streaming media, mobile communications and electronic voting. Later years brought work on PKI, trust management and copyright enforcement. More and more problems come along as more and more businesses reinvent themselves online; threat models have also become more realistic, with dishonest insiders displacing the mythical evil hacker on the Internet.
Dishonest insiders, and the composition problem
Over the last two years, we have been exploring exactly how one might re-engineer cryptography to cope with dishonest insiders. One conclusion is that the analysis of security protocols must be extended to application programming interfaces. This is because the crypto keys used in authentication and payment protocols are often kept in separate hardware security processors, or at least in cryptographic libraries, to which access can be restricted using physical or logical mechanisms. However, an interface has to be exposed to the application program, which will occasionally be suborned whether by a corrupt insider, or by malware. How much harm can be done, and how can we limit it?
Protecting protocols was hard enough, and yet the typical protocol consists of 35 messages exposed to manipulation. The API of a modern crypto library or hardware cryptoprocessor may contain 30500 callable functions, many with a range of options. This provides a very rich and complex environment for mischief.
Attacks often involve using two separate mechanisms provided by the cryptoprocessor for different purposes, each of which could be innocuous by itself but which combine to cause trouble. For example, it is common to compute a customer PIN by encrypting the account number with a PIN derivation key: the cryptoprocessor then returns the PIN encrypted with a PIN storage key, so that the application has no access to its clear value. So far, so good. Then there is another transaction that can be used to encrypt a communications key under the terminal key loaded in an ATM. Here things start to go wrong, as the cryptoprocessor does not distinguish between a terminal key and a PIN derivation key; it considers them both to be of the same type. The upshot is that an attacker can supply the device with an account number, claiming that it is a communications key, and ask for it to be encrypted under the PIN derivation key.
Attacks like this extend protocol analysis all the way to the composition problem the problem that connecting two systems that are secure in isolation can give a composite system that leaks. This had previously been seen as a separate issue, tackled with different conceptual tools.
Differential protocol analysis
We are now working on the second generation of API attacks, which exploit the application syntax supported by the cryptographic service. These attacks are even more powerful, and at least as interesting from the scientific point of view. PIN generation provides a neat example here too. In more detail, the standard PIN computation involves writing the result of the encryption as a hex string and decimalising it. As some banks like to let customers change their PIN to a more memorable number, there is a provision to add an offset to give the PIN that the customer actually enters: Account number: 8807 0123 4569 1715 PIN derivation key: FEFE FEFE FEFE FEFE Encrypted account number: A2CE 126C 69AE C82D Natural (decimalised) PIN: 0224 Offset: 6565 Customer PIN: 6789
The typical implementation requires the programmer to send the cryptoprocessor the account number, a table describing the decimalisation (here, 0123 4567 8901 2345) and the offset. The processor returns the PIN, encrypted under the PIN storage key. The designers do not seem to have realised that a crooked programmer can manipulate the decimalisation table and the offset as well as the account number. A multitude of attacks follow. For example, one can send in an account number with a decimalisation table of 1111...11 to find out the ciphertext corresponding to a clear PIN of 1111, and then with a decimalisation table of 0111...11 to see if there is a zero in the first four digits of the encrypted account number (if so, the PIN, and thus the ciphertext output, will be different). By manipulating the decimalisation table further, he can get all the digits in the PIN, and by then playing with the offset he can get their order. In total, the attack requires only 1525 unprivileged cryptoprocessor transactions to discover the PIN on a single target account.
This second type of attack takes protocol analysis into yet another realm: that of differential attacks. Over the last ten years, a number of techniques have been invented for attacking cryptographic systems by bombarding them with inputs with chosen differences.
For example, in differential cryptanalysis, one analyses the changes in the output of the encryption algorithm; while with differential power analysis, one measures changes in the current consumption or electromagnetic emissions of the equipment. Now we have examples of how consecutive runs of a protocol can leak information if the inputs are suitably chosen. The resulting differential protocol analysis appears to be very powerful against application-level crypto.
It will take us some time to figure out the general lessons to be drawn from attacks like this, the robustness principles that designers should use to avoid them, and the analysis techniques that might assure us of a particular designs soundness. The randomisation of all protocols (another feature of Rogers work) is likely to be important.
Quantitative analysis and multiparty computation
Various researchers have speculated about whether there might one day be a quantitative analysis of protocol security. This might be feasible for PIN processing applications as we can measure the information leakage per transaction in terms of the reduction of entropy in the unknown PIN. This leads in turn to a possible real-world application of an attack previously considered theoretical.
Gus Simmons wrote extensively on covert channels in protocols. One such channel that is always present is the balking channel when one of the principals in a protocol signals something by halting and refusing to continue. This is normally considered unimportant as its information capacity is only a third of a bit per transaction. But with systems designed to cope with large transaction volumes, this need no longer hold. For example, a Trojanned cryptoprocessor could balk when it sees a predetermined PIN. If the PIN length were eight digits, this would be unlikely to hinder normal operation, but at a thousand transactions a second, a programmer could quickly find a number in a typical nine-digit account number range with just this PIN, and open an account for it. Once this kind of problem is appreciated, one can start to look for attacks that involve inducing rare error conditions that cause the cryptoprocessor to abort a transaction. (They exist.)
A third emerging link is between protocol analysis and secure multiparty computation. In application-level crypto we may have several inputs to a computation, some of them coming from an untrusted source, and we have to stop users manipulating the computation to get outputs useful for bad purposes. In the PIN decimalisation example above, one might try to solve the problem by blocking tables such as 1111...11. Yet an attacker can get by with scarcely more work by using two normal-looking tables that differ slightly (another kind of differential attack). We might therefore think that if we cant sanitize the inputs to the computation, perhaps we can authenticate them, and use only those tables that real banks actually use. But building every bank in the world into our trust base is what we were trying to avoid by using cryptography!
Conclusion
The protocol work that started off a quarter of a century ago may have seemed at the time like a minor detail within the larger project of designing robust distributed systems. Yet it has already grown into the main unifying theme of security engineering. Application-level protocols, and especially those from which an attacker can harvest data over many runs, open up new problems. The resulting analysis techniques are set to invade the world of composable security, and the world of multiparty computation. The influence, and the consequences, of Rogers contribution just keep on growing.
References
1. NEEDHAM, R.M. AND SCHROEDER, R.M., Using encryption for authentication in large networks of computers. Comm. ACM, vol. 21, no. 12, pp. 993-999, 1978.
2. BURROWS, M. ABADI, M. AND NEEDHAM, R.M., A logic of authentication, ACM Transactions on Computer Systems, vol. 8, no. 1, pp. 18-36, 1990.
Good security is based upon reality and common sense. Common sense is a function of having common knowledge.
Lunatics rally in Washington to allow nuclear launch codes posted on slashdot.org.
I'm doing a late night coding session, and reading slashdot at the same time.
:o)
My project? A windows 2000 based ATM machine.
If only your people *really* knew the truth...
--sex
Very popular slashdot journal for adul
WHy would they fis it, when they already KNOW theres a problem, and yet they refuse to admit it to the customers who have lost money??!?! If they were quietly REIMBURSING the customers, then i would agree. But they arent.
All Troll + "offtopic" mods are meta moderated as "Unfair", because you abused the system.
I just downloaded the pdf. I'm sure thousands of others have as well. If they manage to get a BS gag order, I'll happily send my archived copy to a web server outside the US.
It's a ridiculous scam, and if it works, that simply reflects the propensity of lack of true patriotism among those in charge.
Everyone is entitled to their own opinion. It's just that yours is stupid.
This, to me, actually means, noone cares about OS2 enough to hack it. There isn't an OS that can't be busted. There are creative/genius people out there.
The absence of an action does not make such action impossible. To think otherwise is very ego-maniacal.
SUBMIT is what's cool now.
Now that this information has been posted here and on various news sites, will this pressure Citibank to fix their problem - or open up new lawsuits and claims that such postings helped/caused crimes . . .
In an age of Information Technology, the medium, the message, and the misuse can be the same thing.
"The Sage treasures Unity and measures all things by it" - Lao Tzu
"History doesn't repeat itself, but it does rhyme." Mark Twain
Yeah, we all know how that story ends: three crappy sequels, each one desecrating a little bit more what little of that was good in our youth, where it turns out that Trollvader is the hero!
A student at my old school noticed once that the ATM machine had a problem and so voided the transaction he was making. He also noted that the ATM gave him his money before it gave the ATM card back.
He went up to an ATM one evening and slipped in his card. Pushed all the righ buttons to take out his daily limit. Took the cash. The ATM asked if he wanted to do anything else, he said no. As the ATM was about to eject his card, he put his hand in front of the slot. The ATM displayed that there was a jam. It voided the transaction and displayed that it was unavailable. He removed his hand and was able to grab the card by it's edge and pull it out. The ATM sensed the jam was cleared and displayed it was ready for business.
The procedure was repeated. and repeated. and repeated. Eventually the ATM was empty.
The next day he went into the bank, put down a pile of cash and explained to the manager that they had a problem.
I'm an American. I love this country and the freedoms that we used to have.
To the court case is at the Inququirer
Hats off to you, sir! Light up a stogie and lean back and enjoy the good life and all the fruits concommitent thereto.
YOU HAVE ARRIVED.
when you can steal the whole machine?
(As far as I know, they still haven't caught all the guys responsible for these.)
Not too long ago, I was a building inspector. One of the main types of buildings that I inspected were FUNB (First Union National Banks) and got to see the inside of how things were run.
*Every single ATM* machine I saw in use (that would be hundreds) were simply p166s with IBM OS/2 attached. That's it, nothing fancy, nothing sneaky, justa plain PC. After watching how they were updated and the "security" on them, I no longer use ATM machines, and advise those I care about not to either.
Scary, huh? Kinda makes you think, doesn't it?
Ouch, that hurts. Well, let's go shopping.
I guess he can be more effective in that position than slumming as a projectionist!
the preceding comment is my own and in no way reflects the opinion of the Joint Chiefs of Staff
It the great /. tradition of saying something fast rather than saying it properly. Nice work!
Worst. Sig. Ever.
This research is now posted publically on my University's web site (univ. of colorado). have a nice day, Citidorks.
do they really think anybody that would do this kind of froud would really have any trouble getting this info even if it was "gagged"?
So here's my ATM camera story...
In 1983, my first job out of college was as an internal auditor at a small regional bank that had only seven branches. We were just installing ATMs and most of our customers were elderly types who weren't interested in these new fangled computers. I, being young and more enlightened, loved them, used them all the time, and rarely carried much cash at all, preferring to just stop by a convenient ATM for a fresh withdrawal. This was in the days when banks considered ATMs as a money saver because customers would use the ATM rather than coming inside to bother a teller, thus saving the bank loads of money by reducing the number of tellers they had to employ, so there were no fees. But I digress...
One of our older patrons had his ATM card misappropriated by a handyman, family member, or other close associate, and said villian used the card to make several large withdrawals. The customer reported the problem, we told the system to capture the card on the next use, and waited.
Within a week, the card was used, and captured. The film from the camera was sent off (these days it's probably digital). The ATM company found that either our tellers had been ordering the wrong kind of film for our ATMs, or they had been sending us the wrong kind, or the tellers where installing it wrong, or something. They sent a note with that info to our President, explaining that the photo was probably the wrong person and wouldn't hold up in court, along with the developed photograph.
Fortunately he read the note before he looked at the photograph, because the guy in the photo was me! He came into my office and with as serious an expression as he could manage, told me they had the photo back, and had their man (I didn't know about the problem with the film at this point). He slid open the envelope, and there in stark black and white was me, probably on a Saturday morning, unshaven and in a dirty Ramones t-shirt.
I stuttered for a few seconds but he couldn't hold it together and started laughing. Needless to say that photo appeared all over the bank for the next several years, along with signs like "Have you seen this man?" and "Do not serve - notify security." We figured that since I used the ATM so much, I was probably on 85% of the photos on the film. The odds were pretty good that with the indexes being wrong I would come up, but it couldn't have been a worse photograph.
Oh, eventually the real crook was caught because he came into the bank to complain that the ATM had taken "his" card and the replacement hadn't arrived yet.
This was supposed to be an homage to becoming a moderator, and yet in hindsight, giving that it's a first post, and there is some thinly-veiled sexual references, I can honestly see how this was not well received.
~Airrage.
"This isn't a study in computer science, its a study in human behavior"
This whole thing about PIN numbers just kills me. In New Zealand, you can walk into a bank branch and (upon supplying ID) get a new bank card and choose your own PIN. The card is totally anonymous so there's no way anybody could perform any kind of cryptographic hash against, for example, the card number embossed on the card (because there isn't one that identifies you) to get the PIN.
Never, ever lose a file again. Ever.
In the second place, the really funny part is that Diner's Club South Africa is trying to force Diner's Club International to produce experts to testify! DCI didn't want to help DCSA to this degree so DCSA is trying to get the courts to force them to help.
But the main point is that the "gag order" reads as follows:
This is what Ross Anderson objects to. He agrees that if the DCI experts testify about confidential information regarding the workings of the ATM system, that that should be kept secret. But he doesn't want the secrecy order to be so broad that it would interfere with him and his students publishing data based on publicly available information. He wants to make sure that the secrecy order is drawn to clarify the distinction between information that is available elsewhere and confidential information revealed by the experts.So when you look at it this way, it's not at all the black and white issue that is being presented here. Neither Diner's Club nor Citibank is seeking a "gag order" to suppress discussion of vulnerabilities. They just want to make sure that confidential testimony by their experts (information which they are contractually bound to keep confidential based on their relationships with others in the financial community) is kept secret. And the only issue is the technical details of how to draft the secrecy order.
In short, it's a tempest in a teapot. Move along, folks. There's really nothing to see here.
The Register reports that Mike Bond and Piotr Zielinski have detailed how any ATM programmer (bank, repairman, etc..) insider can crack any ATM PIN in just 15 guesses. Banks use a hardware encryption scheme to avoid the having a crackable psswd-like file. Oops...turns out theres a hole in the hardware design. Direct link to download the pdf paper. Here is how the crack works. first you have to understand how the pin is generated. banks had two problems they needed to solve, first an ATM had to be able to verify a card even if it went off-line from the bank computers. Thus to allow for on the spot verification, the pin has to derivable from the card somehow. Second, they also did not want to endure the security risk having to distribute a list of all PIN numbers of all cards to all machines, even if it was encrypted. So the scheme they came up with is they take your PIN number and DES encrypt it, and the first four digits of the encrypted number becomes your base PIN. Then to allow you to change your pin, they permit an offset number. Since knowing this offset number does not tell anyone the base PIN, these offset numbers can be kept in the public domain and distributed worldwide. thus when you type in your "pin" number to an ATM the sequence of steps is the machine reads the account code off the mag stripe, DES encodes it, grabs the first four numbers, adds your public offset, and compares it to the number you typed in at the key pad. to keep everything secure the entire process is done in hardware. So even a priviledged bank employee could not have access to the encrypted account code and thus learn the PIN. But wait, there's just one teeny tiny extra step I omitted that causes all the problems. when you DES encode something you get back a HEX number and since PINS are decimal you have to convert it to a decimal number. There's lots of ways you could do this, but what is done is simply to have a table that maps the 15 hex digits 0...F many-to-one down to 0...9. Again still no problem if this mapping had been done in hardware. Unfortunately, it was not viewed as a securtiy risk and this mapping table is not fixed but is rather a software input to the hardware unit. Any one with access to the hardware device such as a priviledged bank employee or a repair man, or someone who found one at a salvage yard can send a substitute table to the hardware. And thats where the problem lies. The paper gives several crack approaches one of which takes 15 tries maximum and is not easily explianed in a few words. they also give a simpler approach that takes max of 46 steps to get the pin which I'll explain. first change the many-to-one mapping to all zeros, except for 1 digit. say this digit is a 3. Then type in a trial PIN of 0000. the hardware unit will say this pin is a correct match unless the encrypted Account number happens to have a 3 anywhere in it. (all other get mapped to zero) Next Change the map to all zeros, except say for say the digit 4, and repeat. after trying all ten digits, you know know which digits are in the PIN number. Now you just try all permuations of these. worst case is a total of 36+10=46 trials. Their other algorithm is more efficient (only 15 trials maxiumum), but you get the idea. I note that this is a big problem for the banks. The reason is that it would not simply do to replace the hardware units with ones that have a fixed map table. The PINS are crackable by anyone who still has one of the old hardware units. To fix the system they would have to both change all of the ATM hardware, change the DES salt in the hardware (to render old machines useless), and change everyone's PINS. this would all have to be done simultaneouly, world wide in every ATM for the banking systems ATMs not to stop working for customers. alternatively I guess they could upgrade all the hardware slowly if they were willing to leave the crack in place until they finished. to do this they woul have to have two sets of offsets. one for the new machines and one for the old machines. the cards would remain crackable until the last machine was removed and the users changed their PIN numbers. I note that in a real system it only takes about 5000 tries on average to crack a 4 digit pin. However, the hardware units limit the rate of trials, so that reducing the number of trials by a couple orders of magnitude is significant.
Some drink at the fountain of knowledge. Others just gargle.
From reading the article it would seem that the only people who could pull off something like this are "Bank Programmers," but there's a much bigger security hole that i can think of.
Here in Canada we have non-bank ATM machines proliferating across the countryside - it's basically a machine that performs an Interac (debit) transaction and spits out money. It runs over a telephone line, you can buy one for a few thousand dollars, and you plonk it down in the middle of a bar where people are too drunk to care that you're adding $2.00 to every transaction.
But who are the people making these machines? They have no certification that I'm aware of. I've seen at least a dozen varieties of these "mini-ATMs" from companies whose names I have never heard of. It seems to me that it would be very easy to build a few of these, rent them to bar owners or corner stores (also very common) and just log magnetic strips and PINs till the cows come home. What does the guy who owns the corner store know about security? He'll just be glad that he has an alternative in his store to offering debit himself, which costs him money on every transaction.
So anyway, if anybody has some plans or examples of how to build your own Interac-ATM please post them on the net ASAP and lets talk business.
In all matters of opinion, our adversaries are insane. -Oscar Wilde
oops...posting with the correct formatting this time:
The Register reports that Mike Bond and Piotr Zielinski have detailed how any ATM programmer (bank, repairman, etc..) insider can crack any ATM PIN in just 15 guesses. Banks use a hardware encryption scheme to avoid the having a crackable psswd-like file. Oops...turns out theres a hole in the hardware design. Direct link to download the pdf paper.
Here is how the crack works.
first you have to understand how the pin is generated.
banks had two problems they needed to solve, first an ATM had to be able to verify a card even if it went off-line from the bank computers. Thus to allow for on the spot verification, the pin has to derivable from the card somehow. Second, they also did not want to endure the security risk having to distribute a list of all PIN numbers of all cards to all machines, even if it was encrypted.
So the scheme they came up with is they take your PIN number and DES encrypt it, and the first four digits of the encrypted number becomes your base PIN. Then to allow you to change your pin, they permit an offset number. Since knowing this offset number does not tell anyone the base PIN, these offset numbers can be kept in the public domain and distributed worldwide.
thus when you type in your "pin" number to an ATM the sequence of steps is the machine reads the account code off the mag stripe, DES encodes it, grabs the first four numbers, adds your public offset, and compares it to the number you typed in at the key pad.
to keep everything secure the entire process is done in hardware. So even a priviledged bank employee could not have access to the encrypted account code and thus learn the PIN.
But wait, there's just one teeny tiny extra step I omitted that causes all the problems. when you DES encode something you get back a HEX number and since PINS are decimal you have to convert it to a decimal number. There's lots of ways you could do this, but what is done is simply to have a table that maps the 15 hex digits 0...F many-to-one down to 0...9.
Again still no problem if this mapping had been done in hardware. Unfortunately, it was not viewed as a securtiy risk and this mapping table is not fixed but is rather a software input to the hardware unit. Any one with access to the hardware device such as a priviledged bank employee or a repair man, or someone who found one at a salvage yard can send a substitute table to the hardware. And thats where the problem lies.
The paper gives several crack approaches one of which takes 15 tries maximum and is not easily explianed in a few words. they also give a simpler approach that takes max of 46 steps to get the pin which I'll explain.
first change the many-to-one mapping to all zeros, except for 1 digit. say this digit is a 3. Then type in a trial PIN of 0000. the hardware unit will say this pin is a correct match unless the encrypted Account number happens to have a 3 anywhere in it. (all other get mapped to zero) Next Change the map to all zeros, except say for say the digit 4, and repeat. after trying all ten digits, you know know which digits are in the PIN number. Now you just try all permuations of these. worst case is a total of 36+10=46 trials.
Their other algorithm is more efficient (only 15 trials maxiumum), but you get the idea.
I note that this is a big problem for the banks. The reason is that it would not simply do to replace the hardware units with ones that have a fixed map table. The PINS are crackable by anyone who still has one of the old hardware units. To fix the system they would have to both change all of the ATM hardware, change the DES salt in the hardware (to render old machines useless), and change everyone's PINS. this would all have to be done simultaneouly, world wide in every ATM for the banking systems ATMs not to stop working for customers. alternatively I guess they could upgrade all the hardware slowly if they were willing to leave the crack in place until they finished. to do this they woul have to have two sets of offsets. one for the new machines and one for the old machines. the cards would remain crackable until the last machine was removed and the users changed their PIN numbers.
I note that in a real system it only takes about 5000 tries on average to crack a 4 digit pin. However, the hardware units limit the rate of trials, so that reducing the number of trials by a couple orders of magnitude is significant.
Some drink at the fountain of knowledge. Others just gargle.
How secure can a number that can't be more than 4 digits long BE?
I hate my pin number. I hate that they won't let me use a longer number like I want to. Jesus, I know Pi out to 50 digits...yet the number that exposes all of my funds (yes, they forced me to have the same pin to link my savings, line of credit and money market accounts) is like the combination to a moron's luggage.
Hey you ATM hackers. How much work would it take to make these goddamn things accept a 12 digit pin -- or better still, a passcode.
And to whomever's about to bring up biometrics: shut up.
Hey freaks: now you're ju
This guy is correct. The vulnerable system is used by banks in the US just as much (or more) as it is in the UK. The idea was to create ATMs that could verify PIN numbers without dialing into a central computer. Very few ATMs do that these days, but the vulnerability remains.
cuz he's clearly a thief.
DMCA? Who said anything about the DMCA? The article is about a British bank trying to keep information about ATM vulnerabilities in a British court case secret.
And who was the idiot who modded this insightful? Geez, seems like all you have to do to get positive karma these days is to say something negative about DMCA.
The site is up and running fast. They're just blocking URL's with an external referrer.
I know a guy who's brother writes software for POS terminals that you use at gas pumps. He says if you choose the "debit card" payment option, your pin number is transmitted in plain text over the Internet.
http://www.askthevoid.com
The absence of an action does not make such action impossible. To think otherwise is very ego-maniacal.
Wow. I couldn't agree more.
However, this theory isn't readily applied to all the Linux zealots we have here, now is it? Double standard maybe?
but then I thought, well where could you do this an not get caught? how about North Korea or Nigeria. North Korea already mints high tech conterfeit US 100 dollar bills on government printing presses. So this would be small but useful potatoes.
but more important than the money, It also would make a nice weapon: UN provokes N. Korea, N korea dumps 100,000 cards with pins written on them in say the NY subway system. Next day all ATM banking is halted world wide. Nice little panic. Travelers stranded. Runs on banks as people have to now go inside to get money and they run out of cash. Anyhow you get the idea.
or maybe just one of the millions of merchant accounts visa hands out is owned by
Yikes
Some drink at the fountain of knowledge. Others just gargle.
First off it might be appropriate to link to Mike Bond's site, where he's tracking some of the news articles about his research, and it has unicycle jousting photos. Also of interest may be Ross Anderson's site.
When Ross mentioned the case and the gagging order in a software engineering lecture he was giving on thursday I was amused... but i didn't expect all this. What i think is most amusing is the fact that if citibank hadn't taken the pretty rash decision to pursue litigation rather than investigate it internal and fix the vuln quietly then they wouldn't look anywhere near as foolish!
I think that's probably enough for my first post, but i'd just like to say that i expect the software engineering lecture with Ross Anderson tomorrow will be most amusing.
Ross: 1
Citibank: 0
Alaric.
MOD PAERNT UP
Gotta love how when the server gets too busy, it suggests you keep hammering it. :)
READ THE THREAD YOU ARE REPLYING TO its explained in the grandparent post.
your base-pin is fixed and unchanging.
they use a public offeset to create a changable pin. changing your pin only changes the offset, not the base pin.
example your base pin is 1234. but you want your pin to be 5555.
citi bank just publishes a pin offset of
4321 for you.
when you use your card and type in 5555
then the machine looks up the public offset for you, subtracts off the offset (4321) and then compares the result 1234 to the pin encoded by the account number. if it matches you get the money.
publishing the offset does not reveal the base pin, so its not considered a security risk. when you change your pin, the base pin number never changes only the public offset.
What proof? You could easily withdraw a hundred dollars, then show the stack front-on to the camera and claim you only got twenty. There's no proof there.
Quoth the report:
"However, HSMs [Hardware Security Modules] implementing several common PIN generation methods have a flaw. The first ATMs were IBM 3624s, introduced widely in the US in around 1980, and most PIN generation methods are based upon their approach. They calculate the customer's original PIN by encrypting the account number printed on the front of the customer's card with a secret DES key called a 'PIN generation key'."
Weird. So they're talking about _generated_ PINs. Every bank account I've opened in the last 7 years, I've been able to request my PIN. And if I wanted to change it, I request what to change it to. Does any bank actually still use this method?
I'm a wee bit confused....
The Right Reverend K. Reid Wightman,
My PIN is 6 digits; I'm not sure if I was limited to 6 or 8. I'm Canadian, so maybe it's just our banks that allow longer PINs. Nonetheless, I've been able to use my bank card with 6-digit PIN in the States without any trouble.
But I don't. I count it out such as not to obscure it. Does it guarantee me anything? No. But it helps. Or it did in the one case I had a problem. (Or maybe because it was only short $20 they just said fuck it.)
-William Shatner can be neither created nor destroyed.
Nothing to do with crypto, but im worried. Ive heard of allot of ATM's using systems such as.. Windows. I saw a shut down screen from windows NT4 on a NatWest cash machine too. What happens if i withdraw money and after making the transaction with the bank, the ATM crashes without giving me my money?
This comment does not represent the views or opinions of the user.
Are you the roadie who was in charge of the fireworks at your show in R.I., the band being great white I think ?
Yeah, sure, it was slashdotted. I guess you don't have to fool all of the moderators all of the time, just some of the moderators some of the time.
Hope someone with some sense gets some points and mods you into oblivion... Whore.
P.S. Mods, If it's not AC, and not truly slashdotted (try checking the links first, even if you can't be bothered to read the article), then it's redundant.
Someone ought make a military-grade ATM programmed in ADA someday. Or not?
I consider it more likely that they knew how much money should be in the ATM, and there was extra at the end of the day....
WWJD? JWRTFA!
This is not very suprising at all.Having worked for Citibank, I can vouch for their poor security and joke of a ethical hack process, Im not suprised that their ATM's (Global CATS is what they are called internaly) encryption scheme for PIN numbers is poor. If I remember correctly, its actually a VB app on a PC. The goal of the ATM was focused more on ease of use and accessibility, or so the training would lead you to believe. Im not exactly sure what the process is in the Branches for PIN assignment, but with the cluelessness of their CGTI (Citigroup Technical Infastrucutre) and their development team, I wouldnt be suprised if these boxes were more vunerable to other attacks. There used to be sites like citibanksucks.com and shitibank.com (I dont think they are still around, I think they were "silenced") that used to point out flaws in Citis systems. They arent the first to sweep bad press under the rug though.
cntrl-A, cntrl-C, cntrl-V
automatic 2+ informative
Mike Bond has made a temporary webpage The paper on the attack (UCAM-CL-TR-560) is also duplicated.
These URLs are just temporary until the webserver is back up so could disappear at any time.
Steven Murdoch.
web: http://www.cl.cam.ac.uk/users/sjm217/
Alright I realize this is "different" but ... come on ... how much can we can complain about the secrecy of a 4 digit number. There's only 10,000 different combinations. What pisses me off is my bank uses the pin numbers for your online banking password and they use your frickin social security number as the username. You get 3 tries on every account. So how hard is that to automate a hack?
How many morons we got on this ship?
Nobody ever bothers to mention the fact that ATM machines are electromagnetically insecure. They aren't RF shielded worth doodle and any reasonably competent spook can capture all of the details of any transaction from across a parking lot. Find a bank with some outside ATMs, park a van with some affordable electronics a hundred or so feet away, spend a few hours capturing data, encode the magnetic strips on a few blank cards using different and still affordable electronics, write the PIN numbers on each card, wait a few days so that everybody forgets seeing your van, travel a few miles to another ATM, and then start withdrawing cash. Move to another ATM and repeat. A couple of hundred bucks 40 or 50 times a day for three or four days adds up to serious cash quickly and probably before anybody notices. Burn the cards and return to step one.
The interesting thing about this attack is that its very much like an attack aginst most smart cards except that they lock out after 3 to 5 tries. If you have access to a point of sale network that uses lots of smart cards (say a large food store) and you can keep track of people who come in often and don't get their pin number wrong then you can try 2 guesses per visit. The interesting bit is that once you have the pin code and account number, you can program your own chip card for about $10 if your bank is nice enough to send you your very own chip card writer.
Shucks! I never DID think we can trust these newfangles things...
Wow, sounds exactly like a game of Mastermind. But instead, you only get the "right color, maybe right place" pegs back.
It all goes downhill from first post
I opened an account with a local bank which recently got bought out by M&I Bank; over the course of a year or two there were several occasions where I suddenly got overdraft notices. Now those are by their nature always a surprise, and I hadn't gone through my statements like I should've for several months and it turned out a statement was missing. When it finally turned up, I went through the entire account from the beginning and found math errors of around a dollar, and nothing that was on the statement that wasn't in my register.
No other account in the 20 yrs I've been banking has ever done this. There was always a reason. And I'm not in the habit of writing checks days before the money will be in there. I concluded there's a problem in the fundamental code running that bank. I want to ask the Slashdot community is this possible? Anyone had similar experiences? Am I just screwed out of the money? It's around $400 now, and I've let the account die, but they're threatening me with collections, and I'd like to not have it affect my credit either.
O~ Him that studies revenge keeps his own wounds green. -- Francis Bacon
When I think about this, the fact that this post was modded as "insightful" by someone is perhaps the most frightening thing I've seen in a long time.
Stop being so damn literal!
The "insightful" moderation need not apply only to the content of a post. It may apply, as I believe was this case, to the fact that it was posted in this context. Sort of "meta insightful".
In debit-capable equipment, the PIN is encrypted immediately within the keypad itself, a sealed assembly - that heavy PIN pad the cashier hands you that feels like a block of epoxy - it is. In the real POS world (those systems certified to directly connect to financial networks - not the Internet), no provision is made for the systems to self-verify the PIN like the teller machines described in the attack, hence they lack that vulnerability. PIN verification is the responsiblity of the network. If the network is down, so is the service.
eat my -1 the-server-is-fast-for-me (redundant) moderation, you karma whore.
Didn't Citibank learn anything from the Russians hacking their systems? Fah, I hate corporate subcultures. They're more subversive than anything Ashcroft can put forward.
Rick
Is that you can do nothing about it!
The banks current position is that everything works fine. Afterall, they do handle the world economy everyday, so your little small potatoes checking account is no big deal right?
Unless you can demonstrate a bank error that meets their criteria I might add, the bank basically says you must pay all fees like it or not.
So, let me tell you from experience, you are screwed. Either you pay even though you may not be totally in the wrong, or you don't.
If you pay, you will be out some cash, but the bank will be happy to let you continue doing business and will even screw you again later if you are willing.
If you don't pay, it gets worse. They charge off your account so they can get the tax benefit. They still send you to collections, and they report you to ChexSystems. This database will record your debt to your current bank and will be used as the reason you cannot get new accounts elsewhere. 95% of all banks use this. Getting a record removed is very difficult. The worst part is that even if you pay at this stage, your record will last for 7 years.
Big banks really suck right now. There are only a few laws they must follow, the rest are rules and regulations they get to set for us without our feedback. Big banks are greedy and are making more money each year. They charge fees for almost anything and have no reasonable appeal process. Currently the larger banks are even beginning to charge check cashing fees on their own checks!
You could write me a check for $5.00 and it could be worth nothing if I presented to the bank it was drafted on.
My advice to you would be to pay that bank, and realize that (1) you have no power here. --Trust me I tried hard to work through a problem with my bank and could not and (2) big banks are not working in your best interests.
Keep your banking record clean and look for a smaller bank that actually wants your business and will serve you as needed to keep it.
Things to look for:
- Low fees across the board.
- Daily caps on overdraft charges to prevent cascading fees. (This is what happened to me. $300 turned into $1100 in a couple of days !?!)
- Teller access without fees
- Reasonable ATM policy. No double dipping ATM transactions. Some bigger banks can and do charge you for use of a free ATM even though the ATM owner does not!
For those wondering, the banks that I have found particularly nasty are:
US Bank
Beginning to impose check cashing fees, highest overdraft charge with no daily cap, poor deposit policy. They hold every check they can for three days. Their own tellers advise you to cash your check then deposit cash.
Key Bank
Very strict on transaction type. Will freeze accounts for very little reason. A disagreement with a teller is enough for this. Check cashing fees with no daily cap. Poor deposit policy combined with their allowed transaction types make some common deposits very difficult.
Both banks guilty of transaction ordering with intent to charge fees. Basically they will clear large checks in order to let many smaller ones bounce. They say it is for your own good, but realistically which is better? Personally, I would rather reissue the larger check, pay the fees and use the rest of my money to cover the damage as cheap as I can. You decide.
Both banks guilty of issuing dangerous check cards by default. Check card works like credit, but with none of the protections.
All this talk of PIN theft is one thing, losing one of these cards is way worse. They can use it any number of places without a PIN and you have to pay.
Personally, the errors are likely to be unstated fees for transactions. Many places charge a fee when you use a debit card. Not all of them let you know about it even though they should. Another error comes from charges when you pay for dinner out. Remember the little place on the receipt for tips? If you don't fill it out, they can later. Problem here is that you don't always get to see the amount they key into the little visa machine. Your copy says one thing, theirs says another..
Seriously, if you are banking with a larger bank, ditch it and go shopping and tell your friends when you are done. You will be better for it.
Blogging because I can...
In the last few years reports have been written about ways banks can increase revenue. In the early 90's the easiest way was to increase fees.
There are consultants that will analyze a banks customer transaction histories in order to recommend a fee structure that will retain the highest number of customers and generate the most revenue from fees while lowering costs.
They do this with the teller fee, minimum balance fee, account inactivity fee and the overdraft fee.
Recently the check cashing fee was added to both make money on both the check writer and the casher while discouraging face to face business at the bank which lowers costs.
The high growth of bank profits combined with growing negative public perception of the fees has recently sparked a few recommendations toward more reasonable structures that actually do help people and the bank without so much profit.
Try and find a couple of those. They get almost zero notice.
See how it works? Remember that the next time you read a shiny well produced brochure that 'assures' you that no other bank is working harder for you.
Blogging because I can...
There are many people here who have withdrawn 5000 Rs(100 $) a day for days together even when the balance in their checking account was less than 100 $ in the first place. If you have overdrawn your account, you are sent a mail(snail) or the bank gives you a call to collect the money. The time limit in which you withdraw money without any problem is 3 days to 15 days.
That is why some banks here give credit/debit cards only to customers who have had a 100 $ minimum balance over a period of 2 years.See, it's those damn OS/2 16-bit programmers. Good for nothings.
A bit off-topic, but here's a train timetable board ;)
g i? dir=Ranska&pic=7
running windows. The trains in paris were three four hours late that day. I wonder why
http://sinex.hut.mediapoli.com/juhapics/slide.c
..the problem is that the ATM needs to at the very least verify that the PIN is right irrespective of whether it is online or offline with the bank database. Therefore the offsets need to be present for each account number at every ATM point. The entire paper is based on a bank employee having access to change the code and insert his keyset for mapping to find out which numbers form part of the key.
As it is,whether it is a four,five or six digit pin doesnt matter if a bank employee has access to the system.
If an ATM cannot be online with the bank database is there a need to verify the PIN. Isnt that an inherent security risk?..
It should have been clear from the beginning that when you put thousands of copies of a system master key out in the field, it would eventually be compromised. The sad thing is that this crack means accounts can be compromised by faking cards without even the thieves having to have a real card. If for example some other secret were on the key and used as part of what got used to generate the PIN, then at least the real ATM cards would be needed also in stealing money from an account. This need not be fancy. Another secret key, unknown to the ATM, could be used and one or a few digits of a crypt of an acct number with that key stored on the card. Getting fancy with public/private keys to private-crypt a pin and storing it on card isn't necessary (even if there were room which there isn't).
It has been a basic tenet of security that you don't trust information that is placed in untrustworthy places, and there have been plenty of articles about people analyzing "secure" hardware modules given time. All it would take is some period where a store that has an ATM in it is closed for long enough to open up the ATM, get the bits out, run analysis, and perhaps even put them back. In all these years since ATMs were first released something of the kind must have happened, to generate the bogus charges that are now taking place.
It is probably feasible to do a remedy by using a character or two in the magnetic stripe, but it would mean at least that the ability of every ATM that is now able to work without connecting to the card issuer bank to do that would be lost. I suspect that the ability of these machines to function when they WERE connected might be salvagable, though, which would mean most ATMs would be flaky a bit oftener but could still work. The main problem is that for something to depend on a secret on the ATM card magstripe, all the ATM CARDS would have to be replaced. If you get a new ATM card from your bank, you will know this is possible. I suspect too that not all banks will have done anything this dumb. If they had it would suggest that every ATM would be a bonanza with secret keys for multiple bank systems, or that entire networks of banks all used the same key...another egregious security misdesign. The principles have been around at least as long as before the Orange Book came out (check the old literature!) and even with the attempts at crypto control that went way back too, banking was understood to need decent crypto and was always allowed to do it right. Banks that did this are victims of their own stupidity (or perhaps it should be said, victims of the stupidity or unwillingness to read about the subject of some employees who may by this time be long retired or dead; I can't believe anyone today would make this mistake.)
If they'd ask for the password/pin before issuing the card (or at least, before writing the magnetic stripe stuff) they could just do a crypto hash of the password and store that, possibly with a salt based on something like card number. It works in computers. Why not on cards? Also then the thing could be a bit longer without having to store the whole thing. If you really got stuck and could store only half the hash on the card, well, that would probably work better than the current system.
Ross Anderson talks about this (here) having happened sometime in the 80's when ATMs were first launched in the UK - and how the banks 'conspired' together to keep videocams out of the ATMs so that these phantom withdrawls could be foisted off as 'forgetfulness' on the customer's part.
Intresting book -- ~1 typos per page, though. Burns the eyes of an English Major.
Keep your packets off my GNU/Girlfriend!
The ATMs in convenience stores in the Philadelphia area at least, and in malls, just have you swipe the card. They do not accept deposits but do give money and some of them, balance inquiry replies.
10 Free Checking accounts with ATM cards ... $0 ... $5,000 ... $1,000
1000 FPGAa at 200 MHz
Beer and Pizza for 100 all-nighters
Everyone's PINs... priceless
Some things money can't buy, for everything else there's CitiBank.
Copyright Violation:"theft, piracy"::Anti-Trust Violation:"thermonuclear price terrorism"<-Overly dramatic language.
Yup, that's pretty much what they do. I had an ATM short me over $100 once (it crapped out while spitting out the cash), and the bank was up-front and told me that if there was $X too much in the machine at the end of the day, they would credit my account. There was, and they did.
"Tomorrow's forecast: a few sprinkles of genius with a chance of doom!" - Stewie Griffin
...as a truck-load of dead babies
At least it is simple if you have some space
to store things.
Consider: suppose you want a system with no system wide r/w keys anywhere in the field.
If you encrypt a secret key with a private rsa key and put this on each card, at the atm you could use the public rsa key to decrypt the secret key and use that to store secret key encrypted stuff on the card. Encrypt card number with the private key and store that too, and you can check the card is valid. But you need more magstripe tracks or other storage. Make sure every card has different secret keys and there's no global key anywhere except where you make them. Someone can still record the data though, but can't generate it from nothing unless he/she can get to the data at the manufacturing site. However this is useless against data recording devices that record cards.
People recording valid cards and playing them back cannot be stopped so simply; that requires something more involved than a simple data store and may not be solvable at all by simple designs. The storage in normal atm or credit cards is way too small for this kind of trick, and simple storage can be simply copied, cleartext or not. If someone used the crock above, a valid card could still be jiggered even w/o a global symmetric key.
Bypasses are devices that allow some people to dash from point A to
point B very fast while other people dash from point B to point A very
fast. People living at point C, being a point directly in between, are
often given to wonder what's so great about point A that so many people
from point B are so keen to get there and what's so great about point B
that so many people from point A are so keen to get _____there. They often
wish that people would just once and for all work out where the hell
they wanted to be.
-- Douglas Adams, "The Hitchhiker's Guide to the Galaxy"
- this post brought to you by the Automated Last Post Generator...