Beta

Slashdot: News for Nerds

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Citibank Tries to Hush ATM Crypto Vulnerability

michael posted more than 11 years ago | from the be-vewwy-vewwy-qweit dept.

Encryption 410

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

cancel ×

410 comments

My Days in the Show (-1, Offtopic)

airrage (514164) | more than 11 years ago | (#5355152)

"I was in the show once, best 21 days of my life. You know you don't carry your bags in the show? You hit white balls for batting practice, the stadiums are like cathedrals, and the women all have long legs and brains."

Recently, I was in the show. It wasn't a goal of mine to get to the show, it just happened, through luck or talent or both. It's not like you have a progress-bar to the show, to show how close or far you are. But one day, I showed up to read about ol' Ike, and there it was: 'you've been granted access to the show'.

Now, I'm not going to say I was Mr. Cool about it. It was a nice little surprise, so I read the link on how to act in the show and quickly went out and got stinking drunk, had sex, and woke up with an 85 year old woman. Yes, like that first grope in the back seat of Dad's Buick 88, I was spent before the bra was off. And so I sat, staring at my new wife -- with a tattoo I don't remember getting -- smoking a Kool Menthol asking, "Was it good for you too?" Naturally, my first experience in the show was a bust.

But that's the problem with the show, you know what to do technically, but you don't know the art of it. I endeavored to do a better job next time. But a better job at what? What exactly am I supposed to do? And that's what all the veterans know and all the rooks don't: the key is to influence the show.

Now I figured after such a spectacular flameout, I'd never get back to the show...

But then it happened again. And this time it was going to be different. I kept up with the flow, trying to route the conversation, looking for wicked turn-of-phrase, or a pun, or deep insight, and then I found it. Like Cap' Ahab, I said 'harpoon that som' bitch thar!' So I threw +1, and waited. And waited. And waited. And as the thundering herd came towards me I realized that the show would not turn for me, and I had a made a critical error. I was stampeded by pre-pubescent pimpled youngsters in Star Trek T-Shirts. I pulled myself from the muck to watch the thundering herd move farther and farther out of sight. I tried this again and again, to the same results. Needless to say, I ended up in the same seedy motel, waking and rolling to the same sight. I relit a used Kool and took a deep drag. My ass hurt and I had a sinking suspicion that my other buttocks said 'boat' which would have delighted the tattoo artist no end to finish his partially completed 'love'. I dared not look.

I had become the Gary Coleman of the show. I was starting to learn Spanish or French or whatever language is appropriate to disappear to the fringes of civilization. And disappear I did.

Arthur C. Clarke said all things come in threes, it's the way of the universe, ultimate karma, triple redundancy I think. And as the old man predicted, the random seed generator came up with my social, and beyond belief, it was time for a comeback to the show.

This time would be different, really. This time I would commit. The third base coach is telling me take a pitch, but I'm digging in for a big cut. That's what I didn't realize before: you have to commit. You have to go all in. You have to be willing to risk all in one swing in the show; you have to bend steel with your mind. The next Shakespeare or Dickens or Simmons is out there, and I'm going to find them, so I set the filter to -1 Uncut and Raw and step into the light...

Re:My Days in the Show (-1)

handybundler (232934) | more than 11 years ago | (#5355299)

bravo! bravo!

YOU DID IT! (-1)

YOU DID IT! (630541) | more than 11 years ago | (#5355428)

Congratulations! You got first post!

YOU DID IT!

3rd post! (-1)

thr0d ps1t (641973) | more than 11 years ago | (#5355158)

This thr0d ps1t is brought to you by the Sirius Cybernetics Corporation's Model Thr00 Thr0d Ps1t Generator.

Share and enjoy!

In Soviet Russia (-1, Offtopic)

Anonymous Coward | more than 11 years ago | (#5355161)

Citibank hushes [narconews.com] you!

First Crypto Post (-1, Offtopic)

Anonymous Coward | more than 11 years ago | (#5355162)

svefg cbfg

Joke... (-1, Offtopic)

Anonymous Coward | more than 11 years ago | (#5355163)

What is red and orange and looks good on hippies?

Fire.

FP!

Shit..that's a good joke! (-1, Troll)

Shit...that's a good (651209) | more than 11 years ago | (#5355384)

Shit...that's a good joke!

Fees... (1, Interesting)

RyansPrivates (634385) | more than 11 years ago | (#5355164)

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!!!

Re:Fees... (5, Insightful)

Lawbeefaroni (246892) | more than 11 years ago | (#5355547)

They're not completely secure because if they were, it would put a dent in all that dough they're raking in. Security through obscurity is free, security that is secure isn't.

eat a dick (-1, Offtopic)

Anonymous Coward | more than 11 years ago | (#5355174)

MONKEY COCK!

Re:eat a dick (-1, Offtopic)

Anonymous Coward | more than 11 years ago | (#5355304)

go free speech. and all that. cock monkey!

in case of /. (-1, Redundant)

squarefish (561836) | more than 11 years ago | (#5355178)

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 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 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] 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 customer's 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 else's 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 3-5 messages exposed to manipulation. The API of a modern crypto library or hardware cryptoprocessor may contain 30-500 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 15-25 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 design's soundness. The randomisation of all protocols (another feature of Roger's 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 can't 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 Roger's 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.

Re:in case of /. (2, Funny)

Anonymous Coward | more than 11 years ago | (#5355204)

Nice formatting, why not go vomit on some toddlers while you're at it?

So easy to read! (2, Funny)

Anonymous Coward | more than 11 years ago | (#5355227)

Thanks for making sure it looked okay!

Mirror (was: Re:in case of /.) (2, Informative)

cetan (61150) | more than 11 years ago | (#5355375)

How about this:

http://www.phule.net/mirrors/pacc.htm [phule.net]

for formatting? :)

Why is this modded up? (0, Offtopic)

Dman33 (110217) | more than 11 years ago | (#5355424)

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

Mirror: Formatted Correctly (2, Informative)

purduephotog (218304) | more than 11 years ago | (#5355431)



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 [cam.ac.uk]

I have written to the judge opposing the order:

http://www.cl.cam.ac.uk/ftp/users/rja14/citibank_r esponse.pdf [cam.ac.uk]

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 [cam.ac.uk]

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 [cryptome.org]

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 [cam.ac.uk]
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 [microsoft.com] [4.8MB]

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 [yale.edu]
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 [dec.com]
logic of authentication, ACM Transactions on Computer Systems,
vol. 8, no. 1, pp. 18-36, 1990.

Re:in case of /. (1)

PhxBlue (562201) | more than 11 years ago | (#5355440)

The hell? This isn't informative--without any sort of formatting, it's painful!

Re:in case of /. (-1, Offtopic)

LongJohnStewartMill (645597) | more than 11 years ago | (#5355467)

I think I saw this in a movie one time.
YODA: (irritated) I cannot teach him. The boy has no patience. Look at that formatting. It's completely nonexistent.


BEN'S VOICE: He will learn patience. You just have to show him where the preview button is.

YODA: Hmmm. No karma in him, like his father. We know what a fine piece of work he is.

BEN'S VOICE: Was I any different when you taught me?

YODA: Hah. He is not ready. You knew HTML as a fetus.

SQUAREFISH: Yoda! I am ready. I...Ben! I can be a Karma Whore. Ben, tell him I'm ready.

ATM? I don't need no stinkin' ATM! (5, Funny)

zmcgrew (265718) | more than 11 years ago | (#5355181)

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?

Re:ATM? I don't need no stinkin' ATM! (1, Offtopic)

UberLord (631313) | more than 11 years ago | (#5355226)

Who needs security when the system can't even run stabily?

That's like saying people on 56k dialup who are online for about an hour a day on average don't need firewalls.

Heck, I get a firewall up before I even think about going online!

Re:ATM? I don't need no stinkin' ATM! (1, Funny)

spasm (79260) | more than 11 years ago | (#5355311)

really? where do you live? {grin}

Re:ATM? I don't need no stinkin' ATM! (2, Interesting)

TheRaven64 (641858) | more than 11 years ago | (#5355321)

I've seen windows ATMs before (there's one near me that rugularly has a dhcp error dialog showing) but I recently went up to use one in one of the London stations. As I approached it crashed (Computers often do that to me.) It then went through the OS/2 boot-up sequence...

in russia soviet (-1, Offtopic)

Anonymous Coward | more than 11 years ago | (#5355186)

post is first

4th post? (-1, Offtopic)

Anonymous Coward | more than 11 years ago | (#5355187)

Do I have 4th post? Earlier? Later? The suspense is killing me. 20 seconds between fame and glory and nothing. The bastards.

How do banks secure ATM lines? (0, Offtopic)

AcquaCow (56720) | more than 11 years ago | (#5355188)

How do bank atm lines work anyways? Are they over phone or satelite? Has anyone ever managed to break into them remotely?

Re:How do banks secure ATM lines? (3, Informative)

Lxy (80823) | more than 11 years ago | (#5355223)

The ATMs I've seen are POTS lines. The older machines actually dial up to somewhere, the newer ones either found a better way to do it or turned off the modem speaker. As for what's being done I don't know, but doing RSA over PPP sounds like a decent, flexible option.

POTS (0)

Anonymous Coward | more than 11 years ago | (#5355480)

What's POTS? The best I can come up with is "Piece of The Shit"

Re:POTS (1)

Lxy (80823) | more than 11 years ago | (#5355539)

Plain Old Telephone System.

Yes, POTS is a POS.

Re:How do banks secure ATM lines? (4, Interesting)

SquadBoy (167263) | more than 11 years ago | (#5355336)

They are some kind of leased line. We have customers that run on Frame, ISDN, and yes even dialup but mostly they go into some kind of Frame cloud. No they are not satelite and although a few people are trying to do them over VPNs it is for obvious reasons thought of as being a *very* bad thing. While this does not apply to what they are talking about in the article they mostly use 3DES for all the traffic that goes over the line. So an attacker could most likely wardial and find the dial backup lines and try to get in that way. But why bother with that when most places have dial in lines on their mainframes. Other than that if you had or could get access to the Frame cloud you could try. But at least the ones I work with are *very* hardened and most likely not worth the time /effort to break them remotly because it is hard to get cash over a line and breaking a ATM does not really get you into the mainframe. Far better and easier to try to break the mainframe mostly because there are far more ways to get to them and banks etc. do not pay nearly as much attention to security as you would think. This in spite of the fact that I yell at people all day long on the subject but I'm just one guy and they consider me paranoid. Gawd I hate people. Anyway hope the above answers your questions which could be summed up as I've never heard of anybody breaking them remotely and it would be *very* hard to do so.

They don't need to in many cases. (1)

rnicey (315158) | more than 11 years ago | (#5355519)

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 :)

Re:How do banks secure ATM lines? (5, Informative)

greechneb (574646) | more than 11 years ago | (#5355363)

Basically, there are two options for an ATM,

Either POTS (plain old telephone service) with a modem dialing in to a service provider, whether it be the bank itself, or outsourced.

or Leased Line - always connected to the service provider.

Encryption is going towards all triple DES encryption within the next year. The ATMs that I have been dealing with all run a form of OS2 for the operating system.

The majority of ATMs just have a dial up line that is set to block incoming calls, so the only connection is being made from the ATM to the service provider.

to answer your questions (0)

Anonymous Coward | more than 11 years ago | (#5355365)

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.

Re:How do banks secure ATM lines? (4, Informative)

froth (466330) | more than 11 years ago | (#5355451)

Everyone has mentioned that ATMs use POTS. This is true. But most of them use a dial-back feature to increase secuirty. They phone home (a pre-configured number, the only way to change this number is to physically open the ATM), hang up and wait for the return call. They will not answer unless they have called out first. ATMs are pretty damn secure.

Re:How do banks secure ATM lines? (0)

Anonymous Coward | more than 11 years ago | (#5355526)

Has anyone broke in, Yes. unsolved crime using an Apple ][, a 3 day weekend, and dressing up like a road crew.

cool (1, Funny)

Anonymous Coward | more than 11 years ago | (#5355192)

I've been using automated debit for years to pay all of my bills.

Maybe I can get all of that money back.

Another PIN vuln story (3, Informative)

Anonymous Coward | more than 11 years ago | (#5355194)

From The Register [theregister.co.uk] .

and only 15minutes ago.. (2, Interesting)

odyrithm (461343) | more than 11 years ago | (#5355207)

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

Re:and only 15minutes ago.. (1)

odyrithm (461343) | more than 11 years ago | (#5355248)

nope... but will have to wait 24hours really just to be sure... never trusted os/2 myself.. nething that runs windows like it did is ungodly.

Re:and only 15minutes ago.. (4, Funny)

kfg (145172) | more than 11 years ago | (#5355334)

For what it's worth, they're called "cash machines" here in the colonies as well.

A west coastism is to refer to twenty dollar bills as "Yuppie Foodstamps" because cash machines only dispense twenties, and thus people who rely on them never seem to have anything but.

KFG

Re:and only 15minutes ago.. (1)

odyrithm (461343) | more than 11 years ago | (#5355397)

kewl(cool for the nazies), you learn somthing everyday ;)

Release the lawyers!!! (2, Insightful)

TopShelf (92521) | more than 11 years ago | (#5355211)

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.



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.

Re:Release the lawyers!!! (3, Insightful)

rgmoore (133276) | more than 11 years ago | (#5355366)

It should be pointed out that this is a problem in the UK, but the US has saner legal rules. The article mentions that Citibank lost a similar case in the US, so apparently the US doesn't think that "our system is secure; it must be the user's fault" is sufficient defense.

Legal fees (0, Offtopic)

hafree (307412) | more than 11 years ago | (#5355213)

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

Re:Legal fees (0)

Anonymous Coward | more than 11 years ago | (#5355280)

i have a feeling its more about the withdrawl that was those transactions then its is about the 1 dollar fees that they are suing over

Re:Legal fees (0)

Anonymous Coward | more than 11 years ago | (#5355325)

Yeah, but if they are claiming you withdrew $300 on each of those 12 transactions, you certainly would find the effort to take them to court for that.

Shut them up! (2, Interesting)

Anonymous Coward | more than 11 years ago | (#5355216)

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.

Re:Shut them up! (5, Insightful)

Daniel Dvorkin (106857) | more than 11 years ago | (#5355401)

Um ... you're kidding, right?

Citibank has no interest in "the best interest of its customers." Like any other megacorp, they don't give a shit about you. They're much more concerned about the embarrassment of admitting that their security is worthless than they are about actually keeping people's money safe. The only way to get them to fix this problem is to publicize it as loudly as possible, because then not fixing the problem becomes even more of an embarrassment for them.

Tell 'em to prove it. (4, Funny)

Dolemite_the_Wiz (618862) | more than 11 years ago | (#5355217)

If Citibank sez that their systems are secure. Tell 'em to prove it.

Dolemite

They Can't (2, Insightful)

neurostar (578917) | more than 11 years ago | (#5355314)

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.

neurostar

Re:They Can't (2, Informative)

SquadBoy (167263) | more than 11 years ago | (#5355354)

The parent poster of course knew this fact. :)

Now think for a minute about what s/he was trying to say. :)

dmca problems, again? (3, Insightful)

micq (266015) | more than 11 years ago | (#5355225)

This is the kind of shit that scares me about the DMCA...

New System (5, Funny)

alaric187 (633477) | more than 11 years ago | (#5355233)

Oh you guys, that's just Citibank's patented Security Through Litigation (tm) method. I hear it works wonders on keeping financial info secure.

Snake Oil (-1, Troll)

pkcs11 (529230) | more than 11 years ago | (#5355237)

The two biggest sources of snake oil today: Linux & Banking Both claim to provide something they can't deliver.

This was covered at k5 also (5, Interesting)

Anonymous Coward | more than 11 years ago | (#5355245)

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.

Read more here:
http://www.kuro5hin.org/story/2003/2/20/61350/0548 [kuro5hin.org]

right to know (5, Informative)

dougnaka (631080) | more than 11 years ago | (#5355246)

The statements made by Citibank regarding their security can only be trusted as far as they are independently evaluated. Consumers in general, and especially Americans, rely far too heavily on a companies claims. If a company makes false claims these days they often simply ignore the facts, and that enough is wrong. But when someone comes out with evidence that a company is making false claims, and the company tries to silence them? That is outright immoral, and should be illegal.

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 [microsoft.com] 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 [sealandgov.com] once all my rights are gone here...

This is SERIOUS (5, Insightful)

arvindn (542080) | more than 11 years ago | (#5355253)

This isn't like on of the regular "a new vulnerability has been discovered. No exploitz are known yet. Patch can be found <here>" kind of things we get on bugtraq all the time.

From the article

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.

What the bank is doing is very irresponsible. I hope they get lots of bad publicity for this. Getting on /. is a good start.

Re:This is SERIOUS (4, Informative)

dachshund (300733) | more than 11 years ago | (#5355409)

It now looks like some of these vulnerabilities have also been discovered by the bad guys.

Of course, this isn't necessarily the case. Note that this particular scheme would require a insider in the bank with access to the pin-verification system. Until somebody verifies that, or at least combs through the logs to look for patterns of suspicious PIN guessing, any connection between the increase in phantom withdrawals and this vulnerability is pure speculation.

Re:This is SERIOUS (4, Insightful)

mosch (204) | more than 11 years ago | (#5355521)

Yes, but the banks are claiming that the system contains no vulnerabilities at all. The presence of any vulnerability demonstrates that the banks are being less than honest with the courts.

Last I checked, it's significantly illegal to be less than honest with the courts.

Re:This is SERIOUS (2, Insightful)

Hammerikaner (570527) | more than 11 years ago | (#5355544)

Everyone should just mirror the PDF [cam.ac.uk] file on your own web server. Would it matter then, if the court filed an injunction? Everyone already has it.

woah! (5, Funny)

spazoid12 (525450) | more than 11 years ago | (#5355263)

I'd better go back and tell my 12-year-old self not to get an ATM card!

Re:woah! (3, Funny)

Rojo^ (78973) | more than 11 years ago | (#5355398)

You never saw Terminator 2 then, huh? =)

Re:woah! (1)

theflea (585612) | more than 11 years ago | (#5355511)

damn, you guys beat me to it! I think I need more sleep if I can mentally connect two slashdot stories to a young John Connor in an 80's flick.

atm pins (0, Offtopic)

syle (638903) | more than 11 years ago | (#5355283)

I swear this is a duplicate from today but I can't find the original post. Am I going crazy?

Re:atm pins (1)

TheRaven64 (641858) | more than 11 years ago | (#5355349)

Am I going crazy?
Yes.

Re:atm pins (1)

terraformer (617565) | more than 11 years ago | (#5355439)

Do you read bugtraq? It came out on there 2 days ago? Tom

Re:atm pins (0)

Anonymous Coward | more than 11 years ago | (#5355475)

You may have seen it on the Register. Most good stories appear there several hours before slashdot. I don't know if it's related to time zones or the fact that the register is run by real journalists...

Re:atm pins (1)

Hell O'World (88678) | more than 11 years ago | (#5355514)

I bet you are getting your K5 mixed up with your /.
Happens to me all the time. I almost submitted it here when I saw it there, but my last 4 submissions were are rejected :( so I didn't bother.

Was on kuro5hin earlier... (1)

Skim123 (3322) | more than 11 years ago | (#5355527)

perhaps that's where you saw it.

Discussion over a donut and a coke at Citibank (0)

Anonymous Coward | more than 11 years ago | (#5355284)

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!"

Re:Discussion over a donut and a coke at Citibank (0)

Anonymous Coward | more than 11 years ago | (#5355313)

Oh fsck...its German, not Germany :) Maybe I ate too many donuts myself hehe

Re:Discussion over a donut and a coke at Citibank (0)

Anonymous Coward | more than 11 years ago | (#5355530)

Hail Deutschland !!! Was kann man heir getrinken?

Submission to /. (5, Funny)

prgammans (134908) | more than 11 years ago | (#5355293)

So they submitted it to /. to gag it for them.
Much quicker then a court order.

PINs can't work, only RSA will do. (1, Funny)

Anonymous Coward | more than 11 years ago | (#5355296)

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.

More meat to the story (5, Informative)

UberLord (631313) | more than 11 years ago | (#5355319)

http://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

They should just give up... (3, Interesting)

Llywelyn (531070) | more than 11 years ago | (#5355324)

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

Now that it has been posted on /. there are probably thousands of geeks downloading it as we speak. I think we can safely say that it is "in the wild"

ATM with an eye (4, Informative)

doubtless (267357) | more than 11 years ago | (#5355328)

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.

Credit please (2, Funny)

grub (11606) | more than 11 years ago | (#5355341)


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 [fortgarry.com] or Guinness [guinness.ie] ? I demand you credit my account.

Wrong hardware listed (2, Informative)

chiph (523845) | more than 11 years ago | (#5355342)

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 [slashdot.org] , 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.

Anyone have details on Judd vs. Citibank? (1)

burgburgburg (574866) | more than 11 years ago | (#5355343)

Since this is the case listed as establishing US law on phantom withdrawals, and is listed as a Citibank loss, anyone have further details?

Wouldn't have happened.... (-1, Flamebait)

MImeKillEr (445828) | more than 11 years ago | (#5355352)

... if ATMs continued to run OS/2.

Hmm.

Q:How many virii or hacks against an OS/2 kernel have you ever heard of?

A:None. My point exactly.

Matlock Is My Cousin (-1, Troll)

Acidic_Diarrhea (641390) | more than 11 years ago | (#5355404)

First of all, the plural of virus is viruses. The "word" "virii" does not exist so cut it out. Second of all, the number of viruses for a particular architecture/protocol/application/operating system is directly proportional to the installed user base. Stop trolling in this manner.

Re:Wouldn't have happened.... (2, Informative)

doubtless (267357) | more than 11 years ago | (#5355407)

Well, taken from http://www.sophos.com/support/faqs/savos2.html [sophos.com] :

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.

Coincidence..., I think not. (2, Funny)

revery (456516) | more than 11 years ago | (#5355356)

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

Re:Coincidence..., I think not. (0)

Anonymous Coward | more than 11 years ago | (#5355455)

that was pathetic.

Link to news story about this attack (2, Informative)

skintigh2 (456496) | more than 11 years ago | (#5355359)

http://www.theregister.co.uk/content/55/29425.html

Sorry, HTML formatting doesn't seem to be working...

PINS based on acct. number?? (2)

cayenne8 (626475) | more than 11 years ago | (#5355373)

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?

palme999? (0, Offtopic)

Xipe66 (587528) | more than 11 years ago | (#5355374)

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

Go back to sleep children (5, Funny)

ralphus (577885) | more than 11 years ago | (#5355380)

Everything is ok.

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.

Link to PDF (2, Informative)

FlyingCarrot (181545) | more than 11 years ago | (#5355390)

Link to PDF given in page

Link to PDF [cam.ac.uk]

Old news (2, Funny)

MarkGriz (520778) | more than 11 years ago | (#5355400)

A young John Connor figured out how to crack PINs way back in 1991 [imdb.com] . How is this "News" for Nerds?

Re:Old news (0)

Anonymous Coward | more than 11 years ago | (#5355500)

I thought his mom figured it out and showed him.

ATMs are fallible in lots of ways (5, Interesting)

osgeek (239988) | more than 11 years ago | (#5355416)

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.

Can't you just change your PIN? (0, Flamebait)

TheSync (5291) | more than 11 years ago | (#5355435)

Won't changing your PIN from the initial one the bank assigns you avoid this problem?

Re:Can't you just change your PIN? (1)

Flakeloaf (321975) | more than 11 years ago | (#5355506)

Nope. Having actually read the article in question I can assure you that won't help.

Candid Camera (4, Funny)

scottennis (225462) | more than 11 years ago | (#5355447)

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?

Re:Candid Camera (2, Interesting)

nochops (522181) | more than 11 years ago | (#5355524)

Yes they do, and that's how I got out of a bad charge on my account.

I went to the ATM and tried to make a withdrawal. The machine tried to give me the cash, but something went wrong mechanically, and the money never came out.

I disputed the charge, but since their systems said that I did make the withdrawal, they didn't want to give me my money back.

I told them I wanted to see the surveilance tape for my personal records. Well, they didn't let me see the tape, but I'm assuming they looked at it and saw that no money came out of the machine. A few days later, i had a credit for the withdrawal.

Am I missing something? (3, Interesting)

asscroft (610290) | more than 11 years ago | (#5355454)

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 #???

What really happened.. (2, Funny)

Metallic Matty (579124) | more than 11 years ago | (#5355501)

Citibank Tries to Hush ATM Crypto Vulnerability..

The problem was discovered in the syste-
*sounds of struggle*
Where are you throwing meeeeee...
Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Create a Slashdot Account

Loading...