Forgot your password?
typodupeerror
Encryption Security

Citibank Tries to Hush ATM Crypto Vulnerability 410

Posted by michael
from the be-vewwy-vewwy-qweit dept.
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."
This discussion has been archived. No new comments can be posted.

Citibank Tries to Hush ATM Crypto Vulnerability

Comments Filter:
  • by zmcgrew (265718) on Friday February 21, 2003 @04:03PM (#5355181) Homepage
    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?
  • by Anonymous Coward on Friday February 21, 2003 @04:05PM (#5355194)
    From The Register [theregister.co.uk].
  • 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..
  • by TopShelf (92521) on Friday February 21, 2003 @04:06PM (#5355211) Homepage Journal
    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.

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

    • Actually, I would be happier with a settlement that forced atm usage to be free.
  • Shut them up! (Score:2, Interesting)

    by Anonymous Coward
    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! (Score:5, Insightful)

      by Daniel Dvorkin (106857) on Friday February 21, 2003 @04:23PM (#5355401) Homepage Journal
      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.
      • He's right. My uncle-in-law is one of the heads of Citibank's private label card division (Home Depot credit card, various chain store credit cards).

        He definitley doesn't give a shit.
        But he does enjoy being rich as fuck.

        Can't say I blame him on that last part. He makes my yearly salary every month.

    • Did you even read any of it? Citi believes there system is 100% secure! They're trying to hush this so they can continue to say it is. Chances of them fixing it are very low. Remember, Citi is in the business to make money. If they can use their lawyers to hush up talk about the security vulnerabilities, then they consider the problem fixed. It's like Microsoft, security through obscurity. "If no one knows about the problem it's not a problem is it?"

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

  • by Dolemite_the_Wiz (618862) on Friday February 21, 2003 @04:06PM (#5355217) Journal
    If Citibank sez that their systems are secure. Tell 'em to prove it.

    Dolemite
    • They Can't (Score:3, Insightful)

      by neurostar (578917)

      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
    • > If Citibank sez that their systems are secure. Tell 'em to prove it.

      I sense a new ad campaign [msn.com] in the offing.

      You are not your per-card withdrawal limit.

      You know things more important than your PIN.
      You are worth more than your bank balance.

      Live richly.
      Citi.
  • by micq (266015) on Friday February 21, 2003 @04:07PM (#5355225)
    This is the kind of shit that scares me about the DMCA...
  • New System (Score:5, Funny)

    by alaric187 (633477) on Friday February 21, 2003 @04:07PM (#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.
  • by Anonymous Coward on Friday February 21, 2003 @04:08PM (#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]
    • by Dudio (529949) on Friday February 21, 2003 @04:41PM (#5355572)
      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.

      While technically true, the catch is that this applies to a lot of PINs, even those chosen by the cardholder. When you set your own PIN, the bank just stores an offset that is used in conjunction with the autogenerated PIN. The vulnerability paper [cam.ac.uk] goes into this in section 3.
  • right to know (Score:5, Informative)

    by dougnaka (631080) on Friday February 21, 2003 @04:08PM (#5355246) Homepage Journal
    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...

    • Re:right to know (Score:4, Informative)

      by KernelHappy (517524) on Friday February 21, 2003 @05:39PM (#5356169) Homepage
      All processors in the debit card industry are required to have their security procedures audited. This includes extensive documentation of any change made to production code, handling of master encryption keys, database maintenance etc. It's not that the companies don't answer to someone, it's that the someone they answer to either doesn't see the weakness or realizes the huge cost involved in rectifying these problems and ignores it.
  • This is SERIOUS (Score:5, Insightful)

    by arvindn (542080) on Friday February 21, 2003 @04:09PM (#5355253) Homepage Journal
    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 (Score:5, Informative)

      by dachshund (300733) on Friday February 21, 2003 @04:24PM (#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 (Score:2, Insightful)

      by Hammerikaner (570527)
      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! (Score:5, Funny)

    by spazoid12 (525450) on Friday February 21, 2003 @04:09PM (#5355263)
    I'd better go back and tell my 12-year-old self not to get an ATM card!
  • by prgammans (134908) on Friday February 21, 2003 @04:12PM (#5355293)
    So they submitted it to /. to gag it for them.
    Much quicker then a court order.
  • by UberLord (631313) on Friday February 21, 2003 @04:14PM (#5355319) Homepage
    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
  • by Llywelyn (531070) on Friday February 21, 2003 @04:15PM (#5355324) Homepage
    "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 (Score:5, Informative)

    by doubtless (267357) on Friday February 21, 2003 @04:15PM (#5355328) Homepage
    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.
    • 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.
    • Except not every ATM is equipped with this, or, like those around here, when it gets really snowy, sometimes cars driving past the external ATMs can splash slush and salt onto the covering of the camera and block its view.

      Probably the best thing to do is a complete overhaul of the CC, ATM and Debit Card markets, over the course of the next ten years or so. Increase the numbers to 24 digits, secure a pin of no less than six digits, and have complete address verification based on the entire address, country and postal code, instead of the absurdly simple address/postal code there is now.

      It wouldn't be too difficult to supply most terminals with an update to software, and upgrade other pieces of software, to accept both types of cards until the old ones are phased out. And it wouldn't cost too much more money, since they're not replacing all the old cards, just phasing them out when new ones are released.

      So why don't they?
    • Re:ATM with an eye (Score:3, Insightful)

      by Skyshadow (508)
      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.

      Most ATMs in the US are under video survailance, too.

      Of course, this won't prevent me from using a techincal exploit to rob them. All I need to do is find an ATM in a somewhat secluded place (not hard), put on a ski mask just before I go to work and not take it off while I'm robbing the thing blind.

      Cameras != protection from crime. They just assist in catching stupid criminals.

  • by grub (11606) <slashdot@grub.net> on Friday February 21, 2003 @04:16PM (#5355341) Homepage Journal

    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.
  • by chiph (523845)
    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.
  • Since this is the case listed as establishing US law on phantom withdrawals, and is listed as a Citibank loss, anyone have further details?
    • Judd vs. Citibank (Score:5, Informative)

      by SirWhoopass (108232) on Friday February 21, 2003 @04:42PM (#5355579)
      This is the best that I could find:

      http://www.ftp.cl.cam.ac.uk/ftp/users/rja14/liabil ity.pdf [cam.ac.uk]


      From the linked PDF:

      The US is totally different; there, in the landmark court case Judd v Citibank

      [JC], Dorothy Judd claimed that she had not made a number of ATM with-
      drawals which Citibank had debited to her account; Citibank claimed that she
      must have done. The judge ruled that Citibank was wrong in law to claim that
      its systems were infallible, as this placed `an unmeetable burden of proof' on
      the plaintif. Since then, if a US bank customer disputes an electronic debit, the
      bank must refund the money within 30 days, unless it can prove that the claim
      is an attempted fraud.

      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.

  • by revery (456516) <charles@nOsPAM.cac2.net> on Friday February 21, 2003 @04:18PM (#5355356) Homepage
    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...
  • 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?
    • My bank, when you first open an account, chooses the password for you. But it's not just a hash of your account number or completely random, but it's the digits based on the telephone keypad letters of a four letter word, like BOTH, YOLK, THIS, etc.

      Then in the menu of the ATM, once the card is activated by typing in this word, you can select your new PIN.
  • by ralphus (577885) on Friday February 21, 2003 @04:21PM (#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.

    • by aussersterne (212916) on Friday February 21, 2003 @04:44PM (#5355596) Homepage

      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.



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

        I agree. I'm frightened myself, and had a high level of sarcasm when I wrote it, but I feel that this basic sales pitch is done over and over again to the mass public and for the most part they buy it! The moderators probably picked up on that and agreed.

  • Link to PDF (Score:2, Informative)

    by FlyingCarrot (181545)
    Link to PDF given in page

    Link to PDF [cam.ac.uk]
  • Old news (Score:3, Funny)

    by MarkGriz (520778) on Friday February 21, 2003 @04:23PM (#5355400)
    A young John Connor figured out how to crack PINs way back in 1991 [imdb.com]. How is this "News" for Nerds?
  • by osgeek (239988) on Friday February 21, 2003 @04:25PM (#5355416) Homepage Journal
    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.
    • That reminds me of the ATM where I asked for $20, and got $40 out instead. I checked my next statement to see how much it took out of my account, and it was $20! I guess I owe you and some other guy $10 each then huh?
    • I got shorted $20 dollars once. Luckily I counted it in front of the ATM (which has a video, most here do) and got really pissed off.

      I held it up and counted, like there was a little guy in there and started screaming at it. I went to my bank the next day, and the say they had to review it. A few days later they credited me. I assume one of the things they did was look at the tape.

      Now I always count it in front of the camera so if there is a problem I've got proof.
  • by scottennis (225462) on Friday February 21, 2003 @04:28PM (#5355447) Homepage
    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 (Score:3, Interesting)

      by nochops (522181)
      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.
  • by asscroft (610290) on Friday February 21, 2003 @04:29PM (#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 #???
    • A while back there was a case where some bad guys made up a fake ATM machine along the lines of the ones you see in convenience stores. It would simply record the mag stripe on the card and capture the keystrokes, then display an error message about communication lines being down. They planted it in a mall for a week or so and captured thousands of mag stripes and PINs.

      An imaginative person could come up with dozens of similar scenarios.

    • by jjon (555854) on Friday February 21, 2003 @06:39PM (#5356824)

      Parent is plain wrong. Read the paper describing the attack (PDF) [cam.ac.uk]. (Link courtesy of The Register [theregister.co.uk].

      Sure I could make a card, if I had the right equipment

      Making a card is trivial - blank magstripe cards and encoders are legally and cheaply available.

      and had the card for long enough to make it,

      To clone a card you just need the account number, that's all that's encoded on the magstripe.

      but in that case I could just as easily use the card.

      No, because you wouldn't know the PIN.

      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 #

      No, if the customer enters their PIN into your dodgy ATM then you just record the account number and PIN - you don't need to hack anything.

      This attack can only be done by someone inside the bank with access to the PIN checking machine. These machines are meant to be protected against insider attack, but this attack gets around it. The number of guesses required is so small (~30 - if the machines were secure it should be ~5000 for a 4-digit PIN) they might not even be detected by the bank's auditing (assuming that the PIN checker has a suitable audit trail at all).

      then I could steal 300.00 a day

      For about one (or maybe two) days, before the bank or cardholder noticed and cancelled the card. For this to work, you need lots of PINs and just use each account once. The paper claims 20,000+ dollars per day (presumably this is based on how long it physically takes to use the ATM with several cards then move to another one before the cops arrive), and claims 2 million dollars total given a half-hour lunchbreak spent cracking PINs.

      but if I owned a business why would I need to steal money?

      Some people can never have enough money.

  • by Metallic Matty (579124) on Friday February 21, 2003 @04:34PM (#5355501)
    Citibank Tries to Hush ATM Crypto Vulnerability..

    The problem was discovered in the syste-
    *sounds of struggle*
    Where are you throwing meeeeee...
  • by nweaver (113078) on Friday February 21, 2003 @04:39PM (#5355551) Homepage
    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.
  • by Rojo^ (78973) on Friday February 21, 2003 @04:42PM (#5355584) Homepage Journal
    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."
    What the fuck are there video cameras embedded in ATMs for? When do they turn on? Have my efforts to moon the bank people been completely in vain?
  • by JRHelgeson (576325) on Friday February 21, 2003 @04:45PM (#5355605) Homepage Journal
    Protocol Analysis, Composability and Computation

    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] (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. [yale.edu] Comm. ACM, vol. 21, no. 12, pp. 993-999, 1978.

    2. BURROWS, M. ABADI, M. AND NEEDHAM, R.M., A logic of authentication [dec.com], ACM Transactions on Computer Systems, vol. 8, no. 1, pp. 18-36, 1990.

  • 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.
  • An old vulnerability (Score:5, Interesting)

    by frovingslosh (582462) on Friday February 21, 2003 @04:56PM (#5355699)
    This seems the right time and place to relate a story about a 30 year old ATM bug I heard about:

    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.

  • by bearl (589272) on Friday February 21, 2003 @05:14PM (#5355883)
    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.
  • The real issue (Score:5, Informative)

    by SiliconEntity (448450) on Friday February 21, 2003 @05:25PM (#5356013)
    Few of you have read the document from Citibank [cam.ac.uk]. In the first place, it's not even Citibank! It's Diner's Club, and specifically Diner's Club South Africa, which is suing two customers who refuse to make good on supposed ATM withdrawals. (The withdrawals were made in England while the customers were in South Africa.)

    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:

    The parties, their legal representative and their experts shall keep confidential all information revealed during the examination and such information shall not be used for any purpose other than the purposes of the Proceedings and the parties shall take all steps necessary to keep such information confidential
    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.

  • by giminy (94188) on Friday February 21, 2003 @07:04PM (#5357047) Homepage Journal
    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....
  • Not suprising (Score:4, Interesting)

    by j_kenpo (571930) on Friday February 21, 2003 @08:07PM (#5357506)
    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.
  • 4 digits anyway (Score:3, Interesting)

    by Darth_Burrito (227272) on Friday February 21, 2003 @08:56PM (#5357799)
    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?

"How do I love thee? My accumulator overflows."

Working...