Slashdot Mirror

Here's some text from the "What is Dasher For?" web page:

Dasher is an information-efficient text-entry interface, driven by natural continuous pointing gestures. Dasher is a competitive text-entry system wherever a full-size keyboard cannot be used

They have bought lots of companies and hired away experts from other companies and universities.

We strongly encourage contributions to the HTK source code base. These will in general be additional tools or library modules which will not fall under this HTK License Agreement.

They have bought lots of companies and hired away experts from other companies and universities.

We strongly encourage contributions to the HTK source code base. These will in general be additional tools or library modules which will not fall under this HTK License Agreement.

i highly doubt gun rights advocates would ever swallow wide implementation of computer technology in guns, especially if TCPA and RFID ever come to their attention.

Yes. There's this little company, Microsoft, I think it's called, working on it right now.

Our universe isn't three dimensional. At the very least we can perceive four dimensions. The latest guess, though, seems to put the actual figure at 11 dimensions.

Here is an annotated mirror which should help: Image

i want a sandbox (run from un-writeable media, cd perhapse) that automatically checks md5 checksums against every program/dll/library i use every time i use it against some pgp checksums. lets see them get around that! with faster processors/hds/ram this should be feasible without too much wasted time.

You are lucky then.

Or do you?

There is a serious game (with tournaments and all) which is somewhat similar to this. It's called tiddlywinks

Unfortunately for my employeer, I just spent a large chunk of time visiting the referenced discussion about the journalist's notes. While doing so I followed a link to a TCPA and Palladium faq. As a result, I think I just crapped my pants (I could be wrong, let me check). Nope that wasn't crap. It was any hope of a bright future leaving my body through the same orafice that I will take it for the rest of my life. I admit to ignoring most news / rumors about TCPA and Palladium. Until now I didn't read much about it. Having done so, and serriously thought about ramifications, possibilities, and likely outcomes, I have concluded that the future will not be bright. I think I'll start digging that hole I will eventually shove my head in.

Iris patterns are unique, even among twins. Far more unique than fingerprints or just about anything but DNA. It's really an amazing technology. See the web site of its inventor, John Daugman.

--

At the top of that page:
An introduction to the Jesus College network

Note - this is not an introduction to the Jesus College Network

Note: This is not a post to Slashdot

There's Jesus, but I think that's about it.

Ross Anderson talks about this (here) having happened sometime in the 80's when ATMs were first launched in the UK - and how the banks 'conspired' together to keep videocams out of the ATMs so that these phantom withdrawls could be foisted off as 'forgetfulness' on the customer's part.

Intresting book -- ~1 typos per page, though. Burns the eyes of an English Major.

Ross Anderson talks about this (here) having happened sometime in the 80's when ATMs were first launched in the UK - and how the banks 'conspired' together to keep videocams out of the ATMs so that these phantom withdrawls could be foisted off as 'forgetfulness' on the customer's part.

Intresting book -- ~1 typos per page, though. Burns the eyes of an English Major.

Parent is plain wrong. Read the paper describing the attack (PDF). (Link courtesy of The Register.

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.

First off it might be appropriate to link to Mike Bond's site, where he's tracking some of the news articles about his research, and it has unicycle jousting photos. Also of interest may be Ross Anderson's site.

When Ross mentioned the case and the gagging order in a software engineering lecture he was giving on thursday I was amused... but i didn't expect all this. What i think is most amusing is the fact that if citibank hadn't taken the pretty rash decision to pursue litigation rather than investigate it internal and fix the vuln quietly then they wouldn't look anywhere near as foolish!

I think that's probably enough for my first post, but i'd just like to say that i expect the software engineering lecture with Ross Anderson tomorrow will be most amusing.

Ross: 1
Citibank: 0

Alaric.

First off it might be appropriate to link to Mike Bond's site, where he's tracking some of the news articles about his research, and it has unicycle jousting photos. Also of interest may be Ross Anderson's site.

When Ross mentioned the case and the gagging order in a software engineering lecture he was giving on thursday I was amused... but i didn't expect all this. What i think is most amusing is the fact that if citibank hadn't taken the pretty rash decision to pursue litigation rather than investigate it internal and fix the vuln quietly then they wouldn't look anywhere near as foolish!

I think that's probably enough for my first post, but i'd just like to say that i expect the software engineering lecture with Ross Anderson tomorrow will be most amusing.

Ross: 1
Citibank: 0

Alaric.

oops...posting with the correct formatting this time:
The Register reports that Mike Bond and Piotr Zielinski have detailed how any ATM programmer (bank, repairman, etc..) insider can crack any ATM PIN in just 15 guesses. Banks use a hardware encryption scheme to avoid the having a crackable psswd-like file. Oops...turns out theres a hole in the hardware design. Direct link to download the pdf paper.

Here is how the crack works.

first you have to understand how the pin is generated.

banks had two problems they needed to solve, first an ATM had to be able to verify a card even if it went off-line from the bank computers. Thus to allow for on the spot verification, the pin has to derivable from the card somehow. Second, they also did not want to endure the security risk having to distribute a list of all PIN numbers of all cards to all machines, even if it was encrypted.

So the scheme they came up with is they take your PIN number and DES encrypt it, and the first four digits of the encrypted number becomes your base PIN. Then to allow you to change your pin, they permit an offset number. Since knowing this offset number does not tell anyone the base PIN, these offset numbers can be kept in the public domain and distributed worldwide.

thus when you type in your "pin" number to an ATM the sequence of steps is the machine reads the account code off the mag stripe, DES encodes it, grabs the first four numbers, adds your public offset, and compares it to the number you typed in at the key pad.

to keep everything secure the entire process is done in hardware. So even a priviledged bank employee could not have access to the encrypted account code and thus learn the PIN.

But wait, there's just one teeny tiny extra step I omitted that causes all the problems. when you DES encode something you get back a HEX number and since PINS are decimal you have to convert it to a decimal number. There's lots of ways you could do this, but what is done is simply to have a table that maps the 15 hex digits 0...F many-to-one down to 0...9.

Again still no problem if this mapping had been done in hardware. Unfortunately, it was not viewed as a securtiy risk and this mapping table is not fixed but is rather a software input to the hardware unit. Any one with access to the hardware device such as a priviledged bank employee or a repair man, or someone who found one at a salvage yard can send a substitute table to the hardware. And thats where the problem lies.

The paper gives several crack approaches one of which takes 15 tries maximum and is not easily explianed in a few words. they also give a simpler approach that takes max of 46 steps to get the pin which I'll explain.

first change the many-to-one mapping to all zeros, except for 1 digit. say this digit is a 3. Then type in a trial PIN of 0000. the hardware unit will say this pin is a correct match unless the encrypted Account number happens to have a 3 anywhere in it. (all other get mapped to zero) Next Change the map to all zeros, except say for say the digit 4, and repeat. after trying all ten digits, you know know which digits are in the PIN number. Now you just try all permuations of these. worst case is a total of 36+10=46 trials.

Their other algorithm is more efficient (only 15 trials maxiumum), but you get the idea.

I note that this is a big problem for the banks. The reason is that it would not simply do to replace the hardware units with ones that have a fixed map table. The PINS are crackable by anyone who still has one of the old hardware units. To fix the system they would have to both change all of the ATM hardware, change the DES salt in the hardware (to render old machines useless), and change everyone's PINS. this would all have to be done simultaneouly, world wide in every ATM for the banking systems ATMs not to stop working for customers. alternatively I guess they could upgrade all the hardware slowly if they were willing to leave the crack in place until they finished. to do this they woul have to have two sets of offsets. one for the new machines and one for the old machines. the cards would remain crackable until the last machine was removed and the users changed their PIN numbers.

I note that in a real system it only takes about 5000 tries on average to crack a 4 digit pin. However, the hardware units limit the rate of trials, so that reducing the number of trials by a couple orders of magnitude is significant.

The Register reports that Mike Bond and Piotr Zielinski have detailed how any ATM programmer (bank, repairman, etc..) insider can crack any ATM PIN in just 15 guesses. Banks use a hardware encryption scheme to avoid the having a crackable psswd-like file. Oops...turns out theres a hole in the hardware design. Direct link to download the pdf paper. Here is how the crack works. first you have to understand how the pin is generated. banks had two problems they needed to solve, first an ATM had to be able to verify a card even if it went off-line from the bank computers. Thus to allow for on the spot verification, the pin has to derivable from the card somehow. Second, they also did not want to endure the security risk having to distribute a list of all PIN numbers of all cards to all machines, even if it was encrypted. So the scheme they came up with is they take your PIN number and DES encrypt it, and the first four digits of the encrypted number becomes your base PIN. Then to allow you to change your pin, they permit an offset number. Since knowing this offset number does not tell anyone the base PIN, these offset numbers can be kept in the public domain and distributed worldwide. thus when you type in your "pin" number to an ATM the sequence of steps is the machine reads the account code off the mag stripe, DES encodes it, grabs the first four numbers, adds your public offset, and compares it to the number you typed in at the key pad. to keep everything secure the entire process is done in hardware. So even a priviledged bank employee could not have access to the encrypted account code and thus learn the PIN. But wait, there's just one teeny tiny extra step I omitted that causes all the problems. when you DES encode something you get back a HEX number and since PINS are decimal you have to convert it to a decimal number. There's lots of ways you could do this, but what is done is simply to have a table that maps the 15 hex digits 0...F many-to-one down to 0...9. Again still no problem if this mapping had been done in hardware. Unfortunately, it was not viewed as a securtiy risk and this mapping table is not fixed but is rather a software input to the hardware unit. Any one with access to the hardware device such as a priviledged bank employee or a repair man, or someone who found one at a salvage yard can send a substitute table to the hardware. And thats where the problem lies. The paper gives several crack approaches one of which takes 15 tries maximum and is not easily explianed in a few words. they also give a simpler approach that takes max of 46 steps to get the pin which I'll explain. first change the many-to-one mapping to all zeros, except for 1 digit. say this digit is a 3. Then type in a trial PIN of 0000. the hardware unit will say this pin is a correct match unless the encrypted Account number happens to have a 3 anywhere in it. (all other get mapped to zero) Next Change the map to all zeros, except say for say the digit 4, and repeat. after trying all ten digits, you know know which digits are in the PIN number. Now you just try all permuations of these. worst case is a total of 36+10=46 trials. Their other algorithm is more efficient (only 15 trials maxiumum), but you get the idea. I note that this is a big problem for the banks. The reason is that it would not simply do to replace the hardware units with ones that have a fixed map table. The PINS are crackable by anyone who still has one of the old hardware units. To fix the system they would have to both change all of the ATM hardware, change the DES salt in the hardware (to render old machines useless), and change everyone's PINS. this would all have to be done simultaneouly, world wide in every ATM for the banking systems ATMs not to stop working for customers. alternatively I guess they could upgrade all the hardware slowly if they were willing to leave the crack in place until they finished. to do this they woul have to have two sets of offsets. one for the new machines and one for the old machines. the cards would remain crackable until the last machine was removed and the users changed their PIN numbers. I note that in a real system it only takes about 5000 tries on average to crack a 4 digit pin. However, the hardware units limit the rate of trials, so that reducing the number of trials by a couple orders of magnitude is significant.

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

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.

Updated 20 February 2003

18 February 2003

To: ukcrypto@chiark.greenend.org.uk
Subject: Citibank tries to gag crypto bug disclosure
Date: Thu, 20 Feb 2003 09:57:34 +0000
From: Ross Anderson <Ross.Anderson@cl.cam.ac.uk>

Citibank is trying to get an order in the High Court today gagging public disclosure of crypto vulnerabilities:

http://www.cl.cam.ac.uk/ftp/users/rja14/citibank_g ag.pdf

I have written to the judge opposing the order:

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

The background is that my student Mike Bond has discovered some really horrendous vulnerabilities in the cryptographic equipment commonly used to protect the PINs used to identify customers to cash machines:

http://www.cl.cam.ac.uk/TechReports/UCAM-CL-TR-560 .pdf

These vulnerabilities mean that bank insiders can almost trivially find out the PINs of any or all customers. The discoveries happened while Mike and I were working as expert witnesses on a `phantom withdrawal' case.

The vulnerabilities are also scientifically interesting:

http://cryptome.org/pacc.htm

For the last couple of years or so there has been a rising tide of phantoms. I get emails with increasing frequency from people all over the world whose banks have debited them for ATM withdrawals that they deny making. Banks in many countries simply claim that their systems are secure and so the customers must be responsible. It now looks like some of these vulnerabilities have also been discovered by the bad guys. Our courts and regulators should make the banks fix their systems, rather than just lying about security and dumping the costs on the customers.

Curiously enough, Citi was also the bank in the case that set US law on phantom withdrawals from ATMs (Judd v Citibank). They lost. I hope that's an omen, if not a precedent ...

_____
Abstract

We present an attack on hardware security modules used by retail banks for the secure storage and verification of customer PINs in ATM (cash machine) infrastructures. By using adaptive decimalisation tables and guesses, the maximum amount of information is learnt about the true PIN upon each guess. It takes an average of 15 guesses to determine a four digit PIN using this technique, instead of the 5000 guesses intended. In a single 30 minute lunch-break, an attacker can thus discover approximately 7000 PINs rather than 24 with the brute force method. With a $300 withdrawal limit per card, the potential bounty is raised from $7200 to $2.1 million and a single motivated attacker could withdraw $30{50 thousand of this each day. This attack thus presents a serious threat to bank security.

-- Mike Bond and Piotr Zielinski

Decimalisation table attacks for PIN cracking

February 2003

-----

From: Ross Anderson <Ross.Anderson@cl.cam.ac.uk>
To: ukcrypto@chiark.greenend.org.uk
Subject: Yet another failure of commercial cryptographic equipment
Date: Tue, 18 Feb 2003 17:52:13 +0000

I gave a talk at Cambridge yesterday in which I described a new and interesting family of attacks on cryptographic equipment. These attacks defeat machines such as the Racal RG7000 and the IBM 4758/CCA which are commonly used to protect the PINs and keys used in automatic teller machines.

The paper is available online at:

http://research.microsoft.com/~aherbert/volume63.p df [4.8MB] (link appears to be broken)

as pages 27-30 in the PDF. [HTML below]

I got a fax yesterday informing me that an application is to be brought in the High Court, it seems by Citibank, on Thursday 20th February for `relief in relation to the protection of information which they accept as being confidential and which ought not to be in the public domain.'

I hope that no English court would go so far as to censor already published material. However, one just can't tell these days ...

Protocol Analysis, Composability and Computation

Ross Anderson, Michael Bond
University of Cambridge, England

Security protocols early days

The study of security protocols has been associated with Roger Needham since 1978, when he published the seminal paper on the subject with Mike Schroeder [1]. The problem they investigated was how to distribute cryptographic keys in a network of computers. One solution is to have an authentication service with which all the principals share a key; then if Alice wants to chat with Bob (for example) she can call the service and get two encrypted messages containing the same session key one encrypted under the key she shares with the service so she can read it, and one encrypted under the key Bob shares with the service so Bob can read it. She can now send the second of these to Bob to establish secure communication. The mechanism that Needham and Schroeder designed for this evolved into Kerberos, which is now part of Windows and is probably the most widely used of all authentication protocols.

Security protocols are now embedded in a great many applications, but it is common to find unexpected bugs in them. For example, many banks used to encrypt each customers PIN using a key known to their ATMs and write it on the ATM card magnetic strip. The idea was to provide a limited service when the network was down. Years later, a villain discovered that the account number and the encrypted PIN were not linked: he could make up a bank card with his own encrypted PIN but someone elses account number, and loot their account. He went on to steal a lot of money, and once in prison wrote a manual telling everyone else how to do it too. The banks had to spend millions on changing their systems.

Clarifying the assumptions

Researchers started to gnaw away at the protocols described in the literature and found fault with essentially all of them. The failure to bind protocol elements was one frequent problem; another was that old messages could be replayed. In the case of the original Needham-Schroeder protocol, for example, the freshness of the key generated by the server was guaranteed to only one of the principals. This was not necessarily an attack, as its inventors only claimed to protect honest insiders from dishonest outsiders. However, it led to a debate about the assumptions underlying security protocol design. Do we protect only against outsiders, or against insiders? Against the malicious, or the merely careless? For example, if we use timestamps to guarantee protocol freshness, are we vulnerable to principals who carelessly let their clocks run slow? Do we only consider an attacker to have won if he can impersonate an authorised principal, or do we need to stop people abusing the protocol mechanisms to perform a service denial attack?

The early attacks led to a second seminal paper, which Roger wrote with Mike Burrows and Martin Abadi in 1989 [2], and which introduced a logic of authentication. This enables an analyst to formalise the assumptions and goals of a security protocol, and to attempt to prove its correctness. When a proof cannot be found, the place at which one gets stuck often shows where an attack can be mounted. This style of analysis turned out to be very powerful, and a large literature quickly developed in which the BAN Logic and other formal tools were developed and extended to tackle a range of problems in protocol design.

One of the remarkable things about the study of security protocols is that they have not become a solved problem. One might think that managing the objects associated with authenticating users over a network passwords, keys and the like was a fairly compact problem which would have been done to death within a few years. However, the more we dig, the more we find.

Since 1992, Roger has hosted a protocols workshop every Easter. Early events dwelled on matters of authentication and logic, but by the mid-90s, the growing interest in electronic commerce was yielding papers on mechanisms for micropayments, bets, streaming media, mobile communications and electronic voting. Later years brought work on PKI, trust management and copyright enforcement. More and more problems come along as more and more businesses reinvent themselves online; threat models have also become more realistic, with dishonest insiders displacing the mythical evil hacker on the Internet.

Dishonest insiders, and the composition problem

Over the last two years, we have been exploring exactly how one might re-engineer cryptography to cope with dishonest insiders. One conclusion is that the analysis of security protocols must be extended to application programming interfaces. This is because the crypto keys used in authentication and payment protocols are often kept in separate hardware security processors, or at least in cryptographic libraries, to which access can be restricted using physical or logical mechanisms. However, an interface has to be exposed to the application program, which will occasionally be suborned whether by a corrupt insider, or by malware. How much harm can be done, and how can we limit it?

Protecting protocols was hard enough, and yet the typical protocol consists of 35 messages exposed to manipulation. The API of a modern crypto library or hardware cryptoprocessor may contain 30500 callable functions, many with a range of options. This provides a very rich and complex environment for mischief.

Attacks often involve using two separate mechanisms provided by the cryptoprocessor for different purposes, each of which could be innocuous by itself but which combine to cause trouble. For example, it is common to compute a customer PIN by encrypting the account number with a PIN derivation key: the cryptoprocessor then returns the PIN encrypted with a PIN storage key, so that the application has no access to its clear value. So far, so good. Then there is another transaction that can be used to encrypt a communications key under the terminal key loaded in an ATM. Here things start to go wrong, as the cryptoprocessor does not distinguish between a terminal key and a PIN derivation key; it considers them both to be of the same type. The upshot is that an attacker can supply the device with an account number, claiming that it is a communications key, and ask for it to be encrypted under the PIN derivation key.

Attacks like this extend protocol analysis all the way to the composition problem the problem that connecting two systems that are secure in isolation can give a composite system that leaks. This had previously been seen as a separate issue, tackled with different conceptual tools.

Differential protocol analysis

We are now working on the second generation of API attacks, which exploit the application syntax supported by the cryptographic service. These attacks are even more powerful, and at least as interesting from the scientific point of view. PIN generation provides a neat example here too. In more detail, the standard PIN computation involves writing the result of the encryption as a hex string and decimalising it. As some banks like to let customers change their PIN to a more memorable number, there is a provision to add an offset to give the PIN that the customer actually enters: Account number: 8807 0123 4569 1715 PIN derivation key: FEFE FEFE FEFE FEFE Encrypted account number: A2CE 126C 69AE C82D Natural (decimalised) PIN: 0224 Offset: 6565 Customer PIN: 6789

The typical implementation requires the programmer to send the cryptoprocessor the account number, a table describing the decimalisation (here, 0123 4567 8901 2345) and the offset. The processor returns the PIN, encrypted under the PIN storage key. The designers do not seem to have realised that a crooked programmer can manipulate the decimalisation table and the offset as well as the account number. A multitude of attacks follow. For example, one can send in an account number with a decimalisation table of 1111...11 to find out the ciphertext corresponding to a clear PIN of 1111, and then with a decimalisation table of 0111...11 to see if there is a zero in the first four digits of the encrypted account number (if so, the PIN, and thus the ciphertext output, will be different). By manipulating the decimalisation table further, he can get all the digits in the PIN, and by then playing with the offset he can get their order. In total, the attack requires only 1525 unprivileged cryptoprocessor transactions to discover the PIN on a single target account.

This second type of attack takes protocol analysis into yet another realm: that of differential attacks. Over the last ten years, a number of techniques have been invented for attacking cryptographic systems by bombarding them with inputs with chosen differences.

For example, in differential cryptanalysis, one analyses the changes in the output of the encryption algorithm; while with differential power analysis, one measures changes in the current consumption or electromagnetic emissions of the equipment. Now we have examples of how consecutive runs of a protocol can leak information if the inputs are suitably chosen. The resulting differential protocol analysis appears to be very powerful against application-level crypto.

It will take us some time to figure out the general lessons to be drawn from attacks like this, the robustness principles that designers should use to avoid them, and the analysis techniques that might assure us of a particular designs soundness. The randomisation of all protocols (another feature of Rogers work) is likely to be important.

Quantitative analysis and multiparty computation

Various researchers have speculated about whether there might one day be a quantitative analysis of protocol security. This might be feasible for PIN processing applications as we can measure the information leakage per transaction in terms of the reduction of entropy in the unknown PIN. This leads in turn to a possible real-world application of an attack previously considered theoretical.

Gus Simmons wrote extensively on covert channels in protocols. One such channel that is always present is the balking channel when one of the principals in a protocol signals something by halting and refusing to continue. This is normally considered unimportant as its information capacity is only a third of a bit per transaction. But with systems designed to cope with large transaction volumes, this need no longer hold. For example, a Trojanned cryptoprocessor could balk when it sees a predetermined PIN. If the PIN length were eight digits, this would be unlikely to hinder normal operation, but at a thousand transactions a second, a programmer could quickly find a number in a typical nine-digit account number range with just this PIN, and open an account for it. Once this kind of problem is appreciated, one can start to look for attacks that involve inducing rare error conditions that cause the cryptoprocessor to abort a transaction. (They exist.)

A third emerging link is between protocol analysis and secure multiparty computation. In application-level crypto we may have several inputs to a computation, some of them coming from an untrusted source, and we have to stop users manipulating the computation to get outputs useful for bad purposes. In the PIN decimalisation example above, one might try to solve the problem by blocking tables such as 1111...11. Yet an attacker can get by with scarcely more work by using two normal-looking tables that differ slightly (another kind of differential attack). We might therefore think that if we cant sanitize the inputs to the computation, perhaps we can authenticate them, and use only those tables that real banks actually use. But building every bank in the world into our trust base is what we were trying to avoid by using cryptography!

Conclusion

The protocol work that started off a quarter of a century ago may have seemed at the time like a minor detail within the larger project of designing robust distributed systems. Yet it has already grown into the main unifying theme of security engineering. Application-level protocols, and especially those from which an attacker can harvest data over many runs, open up new problems. The resulting analysis techniques are set to invade the world of composable security, and the world of multiparty computation. The influence, and the consequences, of Rogers contribution just keep on growing.

References

1. NEEDHAM, R.M. AND SCHROEDER, R.M., Using encryption for authentication in large networks of computers. Comm. ACM, vol. 21, no. 12, pp. 993-999, 1978.

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

Updated 20 February 2003

18 February 2003

To: ukcrypto@chiark.greenend.org.uk
Subject: Citibank tries to gag crypto bug disclosure
Date: Thu, 20 Feb 2003 09:57:34 +0000
From: Ross Anderson <Ross.Anderson@cl.cam.ac.uk>

Citibank is trying to get an order in the High Court today gagging public disclosure of crypto vulnerabilities:

http://www.cl.cam.ac.uk/ftp/users/rja14/citibank_g ag.pdf

I have written to the judge opposing the order:

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

The background is that my student Mike Bond has discovered some really horrendous vulnerabilities in the cryptographic equipment commonly used to protect the PINs used to identify customers to cash machines:

http://www.cl.cam.ac.uk/TechReports/UCAM-CL-TR-560 .pdf

These vulnerabilities mean that bank insiders can almost trivially find out the PINs of any or all customers. The discoveries happened while Mike and I were working as expert witnesses on a `phantom withdrawal' case.

The vulnerabilities are also scientifically interesting:

http://cryptome.org/pacc.htm

For the last couple of years or so there has been a rising tide of phantoms. I get emails with increasing frequency from people all over the world whose banks have debited them for ATM withdrawals that they deny making. Banks in many countries simply claim that their systems are secure and so the customers must be responsible. It now looks like some of these vulnerabilities have also been discovered by the bad guys. Our courts and regulators should make the banks fix their systems, rather than just lying about security and dumping the costs on the customers.

Curiously enough, Citi was also the bank in the case that set US law on phantom withdrawals from ATMs (Judd v Citibank). They lost. I hope that's an omen, if not a precedent ...

_____
Abstract

We present an attack on hardware security modules used by retail banks for the secure storage and verification of customer PINs in ATM (cash machine) infrastructures. By using adaptive decimalisation tables and guesses, the maximum amount of information is learnt about the true PIN upon each guess. It takes an average of 15 guesses to determine a four digit PIN using this technique, instead of the 5000 guesses intended. In a single 30 minute lunch-break, an attacker can thus discover approximately 7000 PINs rather than 24 with the brute force method. With a $300 withdrawal limit per card, the potential bounty is raised from $7200 to $2.1 million and a single motivated attacker could withdraw $30{50 thousand of this each day. This attack thus presents a serious threat to bank security.

-- Mike Bond and Piotr Zielinski

Decimalisation table attacks for PIN cracking

February 2003

-----

From: Ross Anderson <Ross.Anderson@cl.cam.ac.uk>
To: ukcrypto@chiark.greenend.org.uk
Subject: Yet another failure of commercial cryptographic equipment
Date: Tue, 18 Feb 2003 17:52:13 +0000

I gave a talk at Cambridge yesterday in which I described a new and interesting family of attacks on cryptographic equipment. These attacks defeat machines such as the Racal RG7000 and the IBM 4758/CCA which are commonly used to protect the PINs and keys used in automatic teller machines.

The paper is available online at:

http://research.microsoft.com/~aherbert/volume63.p df [4.8MB] (link appears to be broken)

as pages 27-30 in the PDF. [HTML below]

I got a fax yesterday informing me that an application is to be brought in the High Court, it seems by Citibank, on Thursday 20th February for `relief in relation to the protection of information which they accept as being confidential and which ought not to be in the public domain.'

I hope that no English court would go so far as to censor already published material. However, one just can't tell these days ...

Protocol Analysis, Composability and Computation

Ross Anderson, Michael Bond
University of Cambridge, England

Security protocols early days

The study of security protocols has been associated with Roger Needham since 1978, when he published the seminal paper on the subject with Mike Schroeder [1]. The problem they investigated was how to distribute cryptographic keys in a network of computers. One solution is to have an authentication service with which all the principals share a key; then if Alice wants to chat with Bob (for example) she can call the service and get two encrypted messages containing the same session key one encrypted under the key she shares with the service so she can read it, and one encrypted under the key Bob shares with the service so Bob can read it. She can now send the second of these to Bob to establish secure communication. The mechanism that Needham and Schroeder designed for this evolved into Kerberos, which is now part of Windows and is probably the most widely used of all authentication protocols.

Security protocols are now embedded in a great many applications, but it is common to find unexpected bugs in them. For example, many banks used to encrypt each customers PIN using a key known to their ATMs and write it on the ATM card magnetic strip. The idea was to provide a limited service when the network was down. Years later, a villain discovered that the account number and the encrypted PIN were not linked: he could make up a bank card with his own encrypted PIN but someone elses account number, and loot their account. He went on to steal a lot of money, and once in prison wrote a manual telling everyone else how to do it too. The banks had to spend millions on changing their systems.

Clarifying the assumptions

Researchers started to gnaw away at the protocols described in the literature and found fault with essentially all of them. The failure to bind protocol elements was one frequent problem; another was that old messages could be replayed. In the case of the original Needham-Schroeder protocol, for example, the freshness of the key generated by the server was guaranteed to only one of the principals. This was not necessarily an attack, as its inventors only claimed to protect honest insiders from dishonest outsiders. However, it led to a debate about the assumptions underlying security protocol design. Do we protect only against outsiders, or against insiders? Against the malicious, or the merely careless? For example, if we use timestamps to guarantee protocol freshness, are we vulnerable to principals who carelessly let their clocks run slow? Do we only consider an attacker to have won if he can impersonate an authorised principal, or do we need to stop people abusing the protocol mechanisms to perform a service denial attack?

The early attacks led to a second seminal paper, which Roger wrote with Mike Burrows and Martin Abadi in 1989 [2], and which introduced a logic of authentication. This enables an analyst to formalise the assumptions and goals of a security protocol, and to attempt to prove its correctness. When a proof cannot be found, the place at which one gets stuck often shows where an attack can be mounted. This style of analysis turned out to be very powerful, and a large literature quickly developed in which the BAN Logic and other formal tools were developed and extended to tackle a range of problems in protocol design.

One of the remarkable things about the study of security protocols is that they have not become a solved problem. One might think that managing the objects associated with authenticating users over a network passwords, keys and the like was a fairly compact problem which would have been done to death within a few years. However, the more we dig, the more we find.

Since 1992, Roger has hosted a protocols workshop every Easter. Early events dwelled on matters of authentication and logic, but by the mid-90s, the growing interest in electronic commerce was yielding papers on mechanisms for micropayments, bets, streaming media, mobile communications and electronic voting. Later years brought work on PKI, trust management and copyright enforcement. More and more problems come along as more and more businesses reinvent themselves online; threat models have also become more realistic, with dishonest insiders displacing the mythical evil hacker on the Internet.

Dishonest insiders, and the composition problem

Over the last two years, we have been exploring exactly how one might re-engineer cryptography to cope with dishonest insiders. One conclusion is that the analysis of security protocols must be extended to application programming interfaces. This is because the crypto keys used in authentication and payment protocols are often kept in separate hardware security processors, or at least in cryptographic libraries, to which access can be restricted using physical or logical mechanisms. However, an interface has to be exposed to the application program, which will occasionally be suborned whether by a corrupt insider, or by malware. How much harm can be done, and how can we limit it?

Protecting protocols was hard enough, and yet the typical protocol consists of 35 messages exposed to manipulation. The API of a modern crypto library or hardware cryptoprocessor may contain 30500 callable functions, many with a range of options. This provides a very rich and complex environment for mischief.

Attacks often involve using two separate mechanisms provided by the cryptoprocessor for different purposes, each of which could be innocuous by itself but which combine to cause trouble. For example, it is common to compute a customer PIN by encrypting the account number with a PIN derivation key: the cryptoprocessor then returns the PIN encrypted with a PIN storage key, so that the application has no access to its clear value. So far, so good. Then there is another transaction that can be used to encrypt a communications key under the terminal key loaded in an ATM. Here things start to go wrong, as the cryptoprocessor does not distinguish between a terminal key and a PIN derivation key; it considers them both to be of the same type. The upshot is that an attacker can supply the device with an account number, claiming that it is a communications key, and ask for it to be encrypted under the PIN derivation key.

Attacks like this extend protocol analysis all the way to the composition problem the problem that connecting two systems that are secure in isolation can give a composite system that leaks. This had previously been seen as a separate issue, tackled with different conceptual tools.

Differential protocol analysis

We are now working on the second generation of API attacks, which exploit the application syntax supported by the cryptographic service. These attacks are even more powerful, and at least as interesting from the scientific point of view. PIN generation provides a neat example here too. In more detail, the standard PIN computation involves writing the result of the encryption as a hex string and decimalising it. As some banks like to let customers change their PIN to a more memorable number, there is a provision to add an offset to give the PIN that the customer actually enters: Account number: 8807 0123 4569 1715 PIN derivation key: FEFE FEFE FEFE FEFE Encrypted account number: A2CE 126C 69AE C82D Natural (decimalised) PIN: 0224 Offset: 6565 Customer PIN: 6789

The typical implementation requires the programmer to send the cryptoprocessor the account number, a table describing the decimalisation (here, 0123 4567 8901 2345) and the offset. The processor returns the PIN, encrypted under the PIN storage key. The designers do not seem to have realised that a crooked programmer can manipulate the decimalisation table and the offset as well as the account number. A multitude of attacks follow. For example, one can send in an account number with a decimalisation table of 1111...11 to find out the ciphertext corresponding to a clear PIN of 1111, and then with a decimalisation table of 0111...11 to see if there is a zero in the first four digits of the encrypted account number (if so, the PIN, and thus the ciphertext output, will be different). By manipulating the decimalisation table further, he can get all the digits in the PIN, and by then playing with the offset he can get their order. In total, the attack requires only 1525 unprivileged cryptoprocessor transactions to discover the PIN on a single target account.

This second type of attack takes protocol analysis into yet another realm: that of differential attacks. Over the last ten years, a number of techniques have been invented for attacking cryptographic systems by bombarding them with inputs with chosen differences.

For example, in differential cryptanalysis, one analyses the changes in the output of the encryption algorithm; while with differential power analysis, one measures changes in the current consumption or electromagnetic emissions of the equipment. Now we have examples of how consecutive runs of a protocol can leak information if the inputs are suitably chosen. The resulting differential protocol analysis appears to be very powerful against application-level crypto.

It will take us some time to figure out the general lessons to be drawn from attacks like this, the robustness principles that designers should use to avoid them, and the analysis techniques that might assure us of a particular designs soundness. The randomisation of all protocols (another feature of Rogers work) is likely to be important.

Quantitative analysis and multiparty computation

Various researchers have speculated about whether there might one day be a quantitative analysis of protocol security. This might be feasible for PIN processing applications as we can measure the information leakage per transaction in terms of the reduction of entropy in the unknown PIN. This leads in turn to a possible real-world application of an attack previously considered theoretical.

Gus Simmons wrote extensively on covert channels in protocols. One such channel that is always present is the balking channel when one of the principals in a protocol signals something by halting and refusing to continue. This is normally considered unimportant as its information capacity is only a third of a bit per transaction. But with systems designed to cope with large transaction volumes, this need no longer hold. For example, a Trojanned cryptoprocessor could balk when it sees a predetermined PIN. If the PIN length were eight digits, this would be unlikely to hinder normal operation, but at a thousand transactions a second, a programmer could quickly find a number in a typical nine-digit account number range with just this PIN, and open an account for it. Once this kind of problem is appreciated, one can start to look for attacks that involve inducing rare error conditions that cause the cryptoprocessor to abort a transaction. (They exist.)

A third emerging link is between protocol analysis and secure multiparty computation. In application-level crypto we may have several inputs to a computation, some of them coming from an untrusted source, and we have to stop users manipulating the computation to get outputs useful for bad purposes. In the PIN decimalisation example above, one might try to solve the problem by blocking tables such as 1111...11. Yet an attacker can get by with scarcely more work by using two normal-looking tables that differ slightly (another kind of differential attack). We might therefore think that if we cant sanitize the inputs to the computation, perhaps we can authenticate them, and use only those tables that real banks actually use. But building every bank in the world into our trust base is what we were trying to avoid by using cryptography!

Conclusion

The protocol work that started off a quarter of a century ago may have seemed at the time like a minor detail within the larger project of designing robust distributed systems. Yet it has already grown into the main unifying theme of security engineering. Application-level protocols, and especially those from which an attacker can harvest data over many runs, open up new problems. The resulting analysis techniques are set to invade the world of composable security, and the world of multiparty computation. The influence, and the consequences, of Rogers contribution just keep on growing.

References

1. NEEDHAM, R.M. AND SCHROEDER, R.M., Using encryption for authentication in large networks of computers. Comm. ACM, vol. 21, no. 12, pp. 993-999, 1978.

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

Updated 20 February 2003

18 February 2003

To: ukcrypto@chiark.greenend.org.uk
Subject: Citibank tries to gag crypto bug disclosure
Date: Thu, 20 Feb 2003 09:57:34 +0000
From: Ross Anderson <Ross.Anderson@cl.cam.ac.uk>

Citibank is trying to get an order in the High Court today gagging public disclosure of crypto vulnerabilities:

http://www.cl.cam.ac.uk/ftp/users/rja14/citibank_g ag.pdf

I have written to the judge opposing the order:

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

The background is that my student Mike Bond has discovered some really horrendous vulnerabilities in the cryptographic equipment commonly used to protect the PINs used to identify customers to cash machines:

http://www.cl.cam.ac.uk/TechReports/UCAM-CL-TR-560 .pdf

These vulnerabilities mean that bank insiders can almost trivially find out the PINs of any or all customers. The discoveries happened while Mike and I were working as expert witnesses on a `phantom withdrawal' case.

The vulnerabilities are also scientifically interesting:

http://cryptome.org/pacc.htm

For the last couple of years or so there has been a rising tide of phantoms. I get emails with increasing frequency from people all over the world whose banks have debited them for ATM withdrawals that they deny making. Banks in many countries simply claim that their systems are secure and so the customers must be responsible. It now looks like some of these vulnerabilities have also been discovered by the bad guys. Our courts and regulators should make the banks fix their systems, rather than just lying about security and dumping the costs on the customers.

Curiously enough, Citi was also the bank in the case that set US law on phantom withdrawals from ATMs (Judd v Citibank). They lost. I hope that's an omen, if not a precedent ...

_____
Abstract

We present an attack on hardware security modules used by retail banks for the secure storage and verification of customer PINs in ATM (cash machine) infrastructures. By using adaptive decimalisation tables and guesses, the maximum amount of information is learnt about the true PIN upon each guess. It takes an average of 15 guesses to determine a four digit PIN using this technique, instead of the 5000 guesses intended. In a single 30 minute lunch-break, an attacker can thus discover approximately 7000 PINs rather than 24 with the brute force method. With a $300 withdrawal limit per card, the potential bounty is raised from $7200 to $2.1 million and a single motivated attacker could withdraw $30{50 thousand of this each day. This attack thus presents a serious threat to bank security.

-- Mike Bond and Piotr Zielinski

Decimalisation table attacks for PIN cracking

February 2003

-----

From: Ross Anderson <Ross.Anderson@cl.cam.ac.uk>
To: ukcrypto@chiark.greenend.org.uk
Subject: Yet another failure of commercial cryptographic equipment
Date: Tue, 18 Feb 2003 17:52:13 +0000

I gave a talk at Cambridge yesterday in which I described a new and interesting family of attacks on cryptographic equipment. These attacks defeat machines such as the Racal RG7000 and the IBM 4758/CCA which are commonly used to protect the PINs and keys used in automatic teller machines.

The paper is available online at:

http://research.microsoft.com/~aherbert/volume63.p df [4.8MB] (link appears to be broken)

as pages 27-30 in the PDF. [HTML below]

I got a fax yesterday informing me that an application is to be brought in the High Court, it seems by Citibank, on Thursday 20th February for `relief in relation to the protection of information which they accept as being confidential and which ought not to be in the public domain.'

I hope that no English court would go so far as to censor already published material. However, one just can't tell these days ...

Protocol Analysis, Composability and Computation

Ross Anderson, Michael Bond
University of Cambridge, England

Security protocols early days

The study of security protocols has been associated with Roger Needham since 1978, when he published the seminal paper on the subject with Mike Schroeder [1]. The problem they investigated was how to distribute cryptographic keys in a network of computers. One solution is to have an authentication service with which all the principals share a key; then if Alice wants to chat with Bob (for example) she can call the service and get two encrypted messages containing the same session key one encrypted under the key she shares with the service so she can read it, and one encrypted under the key Bob shares with the service so Bob can read it. She can now send the second of these to Bob to establish secure communication. The mechanism that Needham and Schroeder designed for this evolved into Kerberos, which is now part of Windows and is probably the most widely used of all authentication protocols.

Security protocols are now embedded in a great many applications, but it is common to find unexpected bugs in them. For example, many banks used to encrypt each customers PIN using a key known to their ATMs and write it on the ATM card magnetic strip. The idea was to provide a limited service when the network was down. Years later, a villain discovered that the account number and the encrypted PIN were not linked: he could make up a bank card with his own encrypted PIN but someone elses account number, and loot their account. He went on to steal a lot of money, and once in prison wrote a manual telling everyone else how to do it too. The banks had to spend millions on changing their systems.

Clarifying the assumptions

Researchers started to gnaw away at the protocols described in the literature and found fault with essentially all of them. The failure to bind protocol elements was one frequent problem; another was that old messages could be replayed. In the case of the original Needham-Schroeder protocol, for example, the freshness of the key generated by the server was guaranteed to only one of the principals. This was not necessarily an attack, as its inventors only claimed to protect honest insiders from dishonest outsiders. However, it led to a debate about the assumptions underlying security protocol design. Do we protect only against outsiders, or against insiders? Against the malicious, or the merely careless? For example, if we use timestamps to guarantee protocol freshness, are we vulnerable to principals who carelessly let their clocks run slow? Do we only consider an attacker to have won if he can impersonate an authorised principal, or do we need to stop people abusing the protocol mechanisms to perform a service denial attack?

The early attacks led to a second seminal paper, which Roger wrote with Mike Burrows and Martin Abadi in 1989 [2], and which introduced a logic of authentication. This enables an analyst to formalise the assumptions and goals of a security protocol, and to attempt to prove its correctness. When a proof cannot be found, the place at which one gets stuck often shows where an attack can be mounted. This style of analysis turned out to be very powerful, and a large literature quickly developed in which the BAN Logic and other formal tools were developed and extended to tackle a range of problems in protocol design.

One of the remarkable things about the study of security protocols is that they have not become a solved problem. One might think that managing the objects associated with authenticating users over a network passwords, keys and the like was a fairly compact problem which would have been done to death within a few years. However, the more we dig, the more we find.

Since 1992, Roger has hosted a protocols workshop every Easter. Early events dwelled on matters of authentication and logic, but by the mid-90s, the growing interest in electronic commerce was yielding papers on mechanisms for micropayments, bets, streaming media, mobile communications and electronic voting. Later years brought work on PKI, trust management and copyright enforcement. More and more problems come along as more and more businesses reinvent themselves online; threat models have also become more realistic, with dishonest insiders displacing the mythical evil hacker on the Internet.

Dishonest insiders, and the composition problem

Over the last two years, we have been exploring exactly how one might re-engineer cryptography to cope with dishonest insiders. One conclusion is that the analysis of security protocols must be extended to application programming interfaces. This is because the crypto keys used in authentication and payment protocols are often kept in separate hardware security processors, or at least in cryptographic libraries, to which access can be restricted using physical or logical mechanisms. However, an interface has to be exposed to the application program, which will occasionally be suborned whether by a corrupt insider, or by malware. How much harm can be done, and how can we limit it?

Protecting protocols was hard enough, and yet the typical protocol consists of 35 messages exposed to manipulation. The API of a modern crypto library or hardware cryptoprocessor may contain 30500 callable functions, many with a range of options. This provides a very rich and complex environment for mischief.

Attacks often involve using two separate mechanisms provided by the cryptoprocessor for different purposes, each of which could be innocuous by itself but which combine to cause trouble. For example, it is common to compute a customer PIN by encrypting the account number with a PIN derivation key: the cryptoprocessor then returns the PIN encrypted with a PIN storage key, so that the application has no access to its clear value. So far, so good. Then there is another transaction that can be used to encrypt a communications key under the terminal key loaded in an ATM. Here things start to go wrong, as the cryptoprocessor does not distinguish between a terminal key and a PIN derivation key; it considers them both to be of the same type. The upshot is that an attacker can supply the device with an account number, claiming that it is a communications key, and ask for it to be encrypted under the PIN derivation key.

Attacks like this extend protocol analysis all the way to the composition problem the problem that connecting two systems that are secure in isolation can give a composite system that leaks. This had previously been seen as a separate issue, tackled with different conceptual tools.

Differential protocol analysis

We are now working on the second generation of API attacks, which exploit the application syntax supported by the cryptographic service. These attacks are even more powerful, and at least as interesting from the scientific point of view. PIN generation provides a neat example here too. In more detail, the standard PIN computation involves writing the result of the encryption as a hex string and decimalising it. As some banks like to let customers change their PIN to a more memorable number, there is a provision to add an offset to give the PIN that the customer actually enters: Account number: 8807 0123 4569 1715 PIN derivation key: FEFE FEFE FEFE FEFE Encrypted account number: A2CE 126C 69AE C82D Natural (decimalised) PIN: 0224 Offset: 6565 Customer PIN: 6789

The typical implementation requires the programmer to send the cryptoprocessor the account number, a table describing the decimalisation (here, 0123 4567 8901 2345) and the offset. The processor returns the PIN, encrypted under the PIN storage key. The designers do not seem to have realised that a crooked programmer can manipulate the decimalisation table and the offset as well as the account number. A multitude of attacks follow. For example, one can send in an account number with a decimalisation table of 1111...11 to find out the ciphertext corresponding to a clear PIN of 1111, and then with a decimalisation table of 0111...11 to see if there is a zero in the first four digits of the encrypted account number (if so, the PIN, and thus the ciphertext output, will be different). By manipulating the decimalisation table further, he can get all the digits in the PIN, and by then playing with the offset he can get their order. In total, the attack requires only 1525 unprivileged cryptoprocessor transactions to discover the PIN on a single target account.

This second type of attack takes protocol analysis into yet another realm: that of differential attacks. Over the last ten years, a number of techniques have been invented for attacking cryptographic systems by bombarding them with inputs with chosen differences.

For example, in differential cryptanalysis, one analyses the changes in the output of the encryption algorithm; while with differential power analysis, one measures changes in the current consumption or electromagnetic emissions of the equipment. Now we have examples of how consecutive runs of a protocol can leak information if the inputs are suitably chosen. The resulting differential protocol analysis appears to be very powerful against application-level crypto.

It will take us some time to figure out the general lessons to be drawn from attacks like this, the robustness principles that designers should use to avoid them, and the analysis techniques that might assure us of a particular designs soundness. The randomisation of all protocols (another feature of Rogers work) is likely to be important.

Quantitative analysis and multiparty computation

Various researchers have speculated about whether there might one day be a quantitative analysis of protocol security. This might be feasible for PIN processing applications as we can measure the information leakage per transaction in terms of the reduction of entropy in the unknown PIN. This leads in turn to a possible real-world application of an attack previously considered theoretical.

Gus Simmons wrote extensively on covert channels in protocols. One such channel that is always present is the balking channel when one of the principals in a protocol signals something by halting and refusing to continue. This is normally considered unimportant as its information capacity is only a third of a bit per transaction. But with systems designed to cope with large transaction volumes, this need no longer hold. For example, a Trojanned cryptoprocessor could balk when it sees a predetermined PIN. If the PIN length were eight digits, this would be unlikely to hinder normal operation, but at a thousand transactions a second, a programmer could quickly find a number in a typical nine-digit account number range with just this PIN, and open an account for it. Once this kind of problem is appreciated, one can start to look for attacks that involve inducing rare error conditions that cause the cryptoprocessor to abort a transaction. (They exist.)

A third emerging link is between protocol analysis and secure multiparty computation. In application-level crypto we may have several inputs to a computation, some of them coming from an untrusted source, and we have to stop users manipulating the computation to get outputs useful for bad purposes. In the PIN decimalisation example above, one might try to solve the problem by blocking tables such as 1111...11. Yet an attacker can get by with scarcely more work by using two normal-looking tables that differ slightly (another kind of differential attack). We might therefore think that if we cant sanitize the inputs to the computation, perhaps we can authenticate them, and use only those tables that real banks actually use. But building every bank in the world into our trust base is what we were trying to avoid by using cryptography!

Conclusion

The protocol work that started off a quarter of a century ago may have seemed at the time like a minor detail within the larger project of designing robust distributed systems. Yet it has already grown into the main unifying theme of security engineering. Application-level protocols, and especially those from which an attacker can harvest data over many runs, open up new problems. The resulting analysis techniques are set to invade the world of composable security, and the world of multiparty computation. The influence, and the consequences, of Rogers contribution just keep on growing.

References

1. NEEDHAM, R.M. AND SCHROEDER, R.M., Using encryption for authentication in large networks of computers. Comm. ACM, vol. 21, no. 12, pp. 993-999, 1978.

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

Updated 20 February 2003

18 February 2003

To: ukcrypto@chiark.greenend.org.uk
Subject: Citibank tries to gag crypto bug disclosure
Date: Thu, 20 Feb 2003 09:57:34 +0000
From: Ross Anderson <Ross.Anderson@cl.cam.ac.uk>

Citibank is trying to get an order in the High Court today gagging public disclosure of crypto vulnerabilities:

http://www.cl.cam.ac.uk/ftp/users/rja14/citibank_g ag.pdf

I have written to the judge opposing the order:

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

The background is that my student Mike Bond has discovered some really horrendous vulnerabilities in the cryptographic equipment commonly used to protect the PINs used to identify customers to cash machines:

http://www.cl.cam.ac.uk/TechReports/UCAM-CL-TR-560 .pdf

These vulnerabilities mean that bank insiders can almost trivially find out the PINs of any or all customers. The discoveries happened while Mike and I were working as expert witnesses on a `phantom withdrawal' case.

The vulnerabilities are also scientifically interesting:

http://cryptome.org/pacc.htm

For the last couple of years or so there has been a rising tide of phantoms. I get emails with increasing frequency from people all over the world whose banks have debited them for ATM withdrawals that they deny making. Banks in many countries simply claim that their systems are secure and so the customers must be responsible. It now looks like some of these vulnerabilities have also been discovered by the bad guys. Our courts and regulators should make the banks fix their systems, rather than just lying about security and dumping the costs on the customers.

Curiously enough, Citi was also the bank in the case that set US law on phantom withdrawals from ATMs (Judd v Citibank). They lost. I hope that's an omen, if not a precedent ...

_____
Abstract

We present an attack on hardware security modules used by retail banks for the secure storage and verification of customer PINs in ATM (cash machine) infrastructures. By using adaptive decimalisation tables and guesses, the maximum amount of information is learnt about the true PIN upon each guess. It takes an average of 15 guesses to determine a four digit PIN using this technique, instead of the 5000 guesses intended. In a single 30 minute lunch-break, an attacker can thus discover approximately 7000 PINs rather than 24 with the brute force method. With a $300 withdrawal limit per card, the potential bounty is raised from $7200 to $2.1 million and a single motivated attacker could withdraw $30{50 thousand of this each day. This attack thus presents a serious threat to bank security.

-- Mike Bond and Piotr Zielinski

Decimalisation table attacks for PIN cracking

February 2003

-----

From: Ross Anderson <Ross.Anderson@cl.cam.ac.uk>
To: ukcrypto@chiark.greenend.org.uk
Subject: Yet another failure of commercial cryptographic equipment
Date: Tue, 18 Feb 2003 17:52:13 +0000

I gave a talk at Cambridge yesterday in which I described a new and interesting family of attacks on cryptographic equipment. These attacks defeat machines such as the Racal RG7000 and the IBM 4758/CCA which are commonly used to protect the PINs and keys used in automatic teller machines.

The paper is available online at:

http://research.microsoft.com/~aherbert/volume63.p df [4.8MB] (link appears to be broken)

as pages 27-30 in the PDF. [HTML below]

I got a fax yesterday informing me that an application is to be brought in the High Court, it seems by Citibank, on Thursday 20th February for `relief in relation to the protection of information which they accept as being confidential and which ought not to be in the public domain.'

I hope that no English court would go so far as to censor already published material. However, one just can't tell these days ...

Protocol Analysis, Composability and Computation

Ross Anderson, Michael Bond
University of Cambridge, England

Security protocols early days

The study of security protocols has been associated with Roger Needham since 1978, when he published the seminal paper on the subject with Mike Schroeder [1]. The problem they investigated was how to distribute cryptographic keys in a network of computers. One solution is to have an authentication service with which all the principals share a key; then if Alice wants to chat with Bob (for example) she can call the service and get two encrypted messages containing the same session key one encrypted under the key she shares with the service so she can read it, and one encrypted under the key Bob shares with the service so Bob can read it. She can now send the second of these to Bob to establish secure communication. The mechanism that Needham and Schroeder designed for this evolved into Kerberos, which is now part of Windows and is probably the most widely used of all authentication protocols.

Security protocols are now embedded in a great many applications, but it is common to find unexpected bugs in them. For example, many banks used to encrypt each customers PIN using a key known to their ATMs and write it on the ATM card magnetic strip. The idea was to provide a limited service when the network was down. Years later, a villain discovered that the account number and the encrypted PIN were not linked: he could make up a bank card with his own encrypted PIN but someone elses account number, and loot their account. He went on to steal a lot of money, and once in prison wrote a manual telling everyone else how to do it too. The banks had to spend millions on changing their systems.

Clarifying the assumptions

Researchers started to gnaw away at the protocols described in the literature and found fault with essentially all of them. The failure to bind protocol elements was one frequent problem; another was that old messages could be replayed. In the case of the original Needham-Schroeder protocol, for example, the freshness of the key generated by the server was guaranteed to only one of the principals. This was not necessarily an attack, as its inventors only claimed to protect honest insiders from dishonest outsiders. However, it led to a debate about the assumptions underlying security protocol design. Do we protect only against outsiders, or against insiders? Against the malicious, or the merely careless? For example, if we use timestamps to guarantee protocol freshness, are we vulnerable to principals who carelessly let their clocks run slow? Do we only consider an attacker to have won if he can impersonate an authorised principal, or do we need to stop people abusing the protocol mechanisms to perform a service denial attack?

The early attacks led to a second seminal paper, which Roger wrote with Mike Burrows and Martin Abadi in 1989 [2], and which introduced a logic of authentication. This enables an analyst to formalise the assumptions and goals of a security protocol, and to attempt to prove its correctness. When a proof cannot be found, the place at which one gets stuck often shows where an attack can be mounted. This style of analysis turned out to be very powerful, and a large literature quickly developed in which the BAN Logic and other formal tools were developed and extended to tackle a range of problems in protocol design.

One of the remarkable things about the study of security protocols is that they have not become a solved problem. One might think that managing the objects associated with authenticating users over a network passwords, keys and the like was a fairly compact problem which would have been done to death within a few years. However, the more we dig, the more we find.

Since 1992, Roger has hosted a protocols workshop every Easter. Early events dwelled on matters of authentication and logic, but by the mid-90s, the growing interest in electronic commerce was yielding papers on mechanisms for micropayments, bets, streaming media, mobile communications and electronic voting. Later years brought work on PKI, trust management and copyright enforcement. More and more problems come along as more and more businesses reinvent themselves online; threat models have also become more realistic, with dishonest insiders displacing the mythical evil hacker on the Internet.

Dishonest insiders, and the composition problem

Over the last two years, we have been exploring exactly how one might re-engineer cryptography to cope with dishonest insiders. One conclusion is that the analysis of security protocols must be extended to application programming interfaces. This is because the crypto keys used in authentication and payment protocols are often kept in separate hardware security processors, or at least in cryptographic libraries, to which access can be restricted using physical or logical mechanisms. However, an interface has to be exposed to the application program, which will occasionally be suborned whether by a corrupt insider, or by malware. How much harm can be done, and how can we limit it?

Protecting protocols was hard enough, and yet the typical protocol consists of 35 messages exposed to manipulation. The API of a modern crypto library or hardware cryptoprocessor may contain 30500 callable functions, many with a range of options. This provides a very rich and complex environment for mischief.

Attacks often involve using two separate mechanisms provided by the cryptoprocessor for different purposes, each of which could be innocuous by itself but which combine to cause trouble. For example, it is common to compute a customer PIN by encrypting the account number with a PIN derivation key: the cryptoprocessor then returns the PIN encrypted with a PIN storage key, so that the application has no access to its clear value. So far, so good. Then there is another transaction that can be used to encrypt a communications key under the terminal key loaded in an ATM. Here things start to go wrong, as the cryptoprocessor does not distinguish between a terminal key and a PIN derivation key; it considers them both to be of the same type. The upshot is that an attacker can supply the device with an account number, claiming that it is a communications key, and ask for it to be encrypted under the PIN derivation key.

Attacks like this extend protocol analysis all the way to the composition problem the problem that connecting two systems that are secure in isolation can give a composite system that leaks. This had previously been seen as a separate issue, tackled with different conceptual tools.

Differential protocol analysis

We are now working on the second generation of API attacks, which exploit the application syntax supported by the cryptographic service. These attacks are even more powerful, and at least as interesting from the scientific point of view. PIN generation provides a neat example here too. In more detail, the standard PIN computation involves writing the result of the encryption as a hex string and decimalising it. As some banks like to let customers change their PIN to a more memorable number, there is a provision to add an offset to give the PIN that the customer actually enters: Account number: 8807 0123 4569 1715 PIN derivation key: FEFE FEFE FEFE FEFE Encrypted account number: A2CE 126C 69AE C82D Natural (decimalised) PIN: 0224 Offset: 6565 Customer PIN: 6789

The typical implementation requires the programmer to send the cryptoprocessor the account number, a table describing the decimalisation (here, 0123 4567 8901 2345) and the offset. The processor returns the PIN, encrypted under the PIN storage key. The designers do not seem to have realised that a crooked programmer can manipulate the decimalisation table and the offset as well as the account number. A multitude of attacks follow. For example, one can send in an account number with a decimalisation table of 1111...11 to find out the ciphertext corresponding to a clear PIN of 1111, and then with a decimalisation table of 0111...11 to see if there is a zero in the first four digits of the encrypted account number (if so, the PIN, and thus the ciphertext output, will be different). By manipulating the decimalisation table further, he can get all the digits in the PIN, and by then playing with the offset he can get their order. In total, the attack requires only 1525 unprivileged cryptoprocessor transactions to discover the PIN on a single target account.

This second type of attack takes protocol analysis into yet another realm: that of differential attacks. Over the last ten years, a number of techniques have been invented for attacking cryptographic systems by bombarding them with inputs with chosen differences.

For example, in differential cryptanalysis, one analyses the changes in the output of the encryption algorithm; while with differential power analysis, one measures changes in the current consumption or electromagnetic emissions of the equipment. Now we have examples of how consecutive runs of a protocol can leak information if the inputs are suitably chosen. The resulting differential protocol analysis appears to be very powerful against application-level crypto.

It will take us some time to figure out the general lessons to be drawn from attacks like this, the robustness principles that designers should use to avoid them, and the analysis techniques that might assure us of a particular designs soundness. The randomisation of all protocols (another feature of Rogers work) is likely to be important.

Quantitative analysis and multiparty computation

Various researchers have speculated about whether there might one day be a quantitative analysis of protocol security. This might be feasible for PIN processing applications as we can measure the information leakage per transaction in terms of the reduction of entropy in the unknown PIN. This leads in turn to a possible real-world application of an attack previously considered theoretical.

Gus Simmons wrote extensively on covert channels in protocols. One such channel that is always present is the balking channel when one of the principals in a protocol signals something by halting and refusing to continue. This is normally considered unimportant as its information capacity is only a third of a bit per transaction. But with systems designed to cope with large transaction volumes, this need no longer hold. For example, a Trojanned cryptoprocessor could balk when it sees a predetermined PIN. If the PIN length were eight digits, this would be unlikely to hinder normal operation, but at a thousand transactions a second, a programmer could quickly find a number in a typical nine-digit account number range with just this PIN, and open an account for it. Once this kind of problem is appreciated, one can start to look for attacks that involve inducing rare error conditions that cause the cryptoprocessor to abort a transaction. (They exist.)

A third emerging link is between protocol analysis and secure multiparty computation. In application-level crypto we may have several inputs to a computation, some of them coming from an untrusted source, and we have to stop users manipulating the computation to get outputs useful for bad purposes. In the PIN decimalisation example above, one might try to solve the problem by blocking tables such as 1111...11. Yet an attacker can get by with scarcely more work by using two normal-looking tables that differ slightly (another kind of differential attack). We might therefore think that if we cant sanitize the inputs to the computation, perhaps we can authenticate them, and use only those tables that real banks actually use. But building every bank in the world into our trust base is what we were trying to avoid by using cryptography!

Conclusion

The protocol work that started off a quarter of a century ago may have seemed at the time like a minor detail within the larger project of designing robust distributed systems. Yet it has already grown into the main unifying theme of security engineering. Application-level protocols, and especially those from which an attacker can harvest data over many runs, open up new problems. The resulting analysis techniques are set to invade the world of composable security, and the world of multiparty computation. The influence, and the consequences, of Rogers contribution just keep on growing.

References

1. NEEDHAM, R.M. AND SCHROEDER, R.M., Using encryption for authentication in large networks of computers. Comm. ACM, vol. 21, no. 12, pp. 993-999, 1978.

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

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

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.

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 goes into this in section 3.

The bugtraq post has lots of links:

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

The bugtraq post has lots of links:

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

The bugtraq post has lots of links:

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

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

Updated 20 February 2003

18 February 2003

To: ukcrypto@chiark.greenend.org.uk
Subject: Citibank tries to gag crypto bug disclosure
Date: Thu, 20 Feb 2003 09:57:34 +0000
From: Ross Anderson <Ross.Anderson@cl.cam.ac.uk>

Citibank is trying to get an order in the High Court today gagging public disclosure of crypto vulnerabilities:

http://www.cl.cam.ac.uk/ftp/users/rja14/citibank_g ag.pdf

I have written to the judge opposing the order:

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

The background is that my student Mike Bond has discovered some really horrendous vulnerabilities in the cryptographic equipment commonly used to protect the PINs used to identify customers to cash machines:

http://www.cl.cam.ac.uk/TechReports/UCAM-CL-TR-560 .pdf

These vulnerabilities mean that bank insiders can almost trivially find out the PINs of any or all customers. The discoveries happened while Mike
and I were working as expert witnesses on a `phantom withdrawal' case.

The vulnerabilities are also scientifically interesting:

http://cryptome.org/pacc.htm

For the last couple of years or so there has been a rising tide of phantoms. I get emails with increasing frequency from people all over the world whose banks have debited them for ATM withdrawals that they deny making. Banks in
many countries simply claim that their systems are secure and so the customers must be responsible. It now looks like some of these vulnerabilities have also been discovered by the bad guys. Our courts and regulators should make the banks fix their systems, rather than just lying about security and dumping the costs on the customers.

Curiously enough, Citi was also the bank in the case that set US law on phantom withdrawals from ATMs (Judd v Citibank). They lost. I hope that's
an omen, if not a precedent ...
_____

Abstract

We present an attack on hardware security modules used by retail banks for the secure storage and verification of customer PINs in ATM (cash machine) infrastructures. By using adaptive decimalisation tables and guesses, the
maximum amount of information is learnt about the true PIN upon each guess.
It takes an average of 15 guesses to determine a four digit PIN using this technique, instead of the 5000 guesses intended. In a single 30 minute
lunch-break, an attacker can thus discover approximately 7000 PINs rather than 24 with the brute force method. With a $300 withdrawal limit per card, the potential bounty is raised from $7200 to $2.1 million and a single motivated attacker could withdraw $30{50 thousand of this each day. This attack thus presents a serious threat to bank security.

-- Mike Bond and Piotr Zielinski
Decimalisation table attacks for PIN cracking
February 2003

-----

From: Ross Anderson <Ross.Anderson@cl.cam.ac.uk>
To: ukcrypto@chiark.greenend.org.uk
Subject: Yet another failure of commercial cryptographic equipment
Date: Tue, 18 Feb 2003 17:52:13 +0000

I gave a talk at Cambridge yesterday in which I described a new and interesting family of attacks on cryptographic equipment. These attacks defeat machines such as the Racal RG7000 and the IBM 4758/CCA which are commonly used to protect the PINs and keys used in automatic teller machines.

The paper is available online at:

http://research.microsoft.com/~aherbert/volume63.p df [4.8MB]

as pages 27-30 in the PDF. [HTML below]

I got a fax yesterday informing me that an application is to be brought in the High Court, it seems by Citibank, on Thursday 20th February for `relief in relation to the protection of nformation which they accept as being confidential and which ought not to be in the public domain.'

I hope that no English court would go so far as to censor already published material. However, one just can't tell these days ...

Protocol Analysis, Composability and Computation

Ross Anderson, Michael Bond

University of Cambridge, England

Security protocols early days

The study of security protocols has been associated with Roger Needham since 1978, when he published the seminal paper on the subject with Mike Schroeder [1]. The problem they investigated was how to distribute cryptographic keys in a network of computers. One solution is to have an authentication service with which all the principals share a key; then if Alice wants to chat with Bob (for example) she can call the service and get two encrypted messages containing the same session key one encrypted under the key she shares with the service so she can read it, and one encrypted under the key Bob
shares with the service so Bob can read it. She can now send the second of these to Bob to establish secure communication. The mechanism that Needham and Schroeder designed for this evolved into Kerberos, which is now part of Windows and is probably the most widely used of all uthentication protocols.

Security protocols are now embedded in a great many applications, but it is common to find unexpected bugs in them. For example, many banks used to encrypt each customers PIN using a key known to their ATMs and write it on the ATM card magnetic strip. The idea was to provide a limited service when the network was down. Years later, a villain discovered that the account number and the encrypted PIN were not linked: he could make up a bank card with his own encrypted PIN but someone elses account number, and loot their account. He went on to steal a lot of money, and once in prison wrote a manual telling everyone else how to do it too. The banks had to spend millions on changing their systems.

Clarifying the assumptions

Researchers started to gnaw away at the protocols described in the literature and found fault with essentially all of them. The failure to bind protocol elements was one frequent problem; another was that old messages could be
replayed. In the case of the original Needham-Schroeder protocol, for example, the freshness of the key generated by the server was guaranteed to only one of the principals. This was not necessarily an attack, as its inventors only
claimed to protect honest insiders from dishonest outsiders. However, it led to a debate about the assumptions underlying security protocol design.
Do we protect only against outsiders, or against insiders? Against the malicious, or the merely careless? For example, if we use timestamps to guarantee protocol freshness, are we vulnerable to principals who carelessly let their clocks
run slow? Do we only consider an attacker to have won if he can impersonate an authorised principal, or do we need to stop people abusing the protocol
mechanisms to perform a service denial attack?

The early attacks led to a second seminal paper, which Roger wrote with Mike Burrows and Martin Abadi in 1989 [2], and which introduced a logic of
authentication. This enables an analyst to formalise the assumptions and goals of a security protocol, and to attempt to prove its correctness. When a proof cannot be found, the place at which one gets stuck often shows where an attack can be mounted. This style of analysis turned out to be very powerful, and a large literature quickly developed in which the BAN Logic
and other formal tools were developed and extended to tackle a range of problems in protocol design.

One of the remarkable things about the study of security protocols is that they have not become a solved problem. One might think that managing the
objects associated with authenticating users over a network passwords, keys and the like was a fairly compact problem which would have been done to death within a few years. However, the more we dig, the more we find.

Since 1992, Roger has hosted a protocols workshop every Easter. Early events dwelled on matters of authentication and logic, but by the mid-90s, the growing interest in electronic commerce was yielding papers on mechanisms for micropayments, bets, streaming media, mobile communications and electronic voting. Later years brought work on PKI, trust management and copyright enforcement. More and more problems come along as more and more businesses reinvent themselves online; threat models have also become more realistic, with dishonest insiders displacing the mythical evil hacker on the Internet.

Dishonest insiders, and the composition problem

Over the last two years, we have been exploring exactly how one might re-engineer cryptography to cope with dishonest insiders. One conclusion is that the analysis of security protocols must be extended to application programming interfaces. This is because the crypto keys used in authentication and payment protocols are often kept in separate hardware security processors, or at least in cryptographic libraries, to which access can be restricted using physical or logical mechanisms. However, an interface has to be exposed to the application program, which will occasionally be suborned whether by a corrupt insider, or by malware. How much harm can be done, and how can we limit it?

Protecting protocols was hard enough, and yet the typical protocol consists of 35 messages exposed to manipulation. The API of a modern crypto library or hardware cryptoprocessor may contain 30500 callable functions, many with a range of options. This provides a very rich and complex environment for mischief.

Attacks often involve using two separate echanisms provided by the cryptoprocessor for different purposes, each of which could be innocuous by itself but which combine to cause trouble. For example, it is common to compute a customer PIN by encrypting the account number with a PIN
derivation key: the cryptoprocessor then returns the PIN encrypted with a PIN storage key, so that the application has no access to its clear
value. So far, so good. Then there is another transaction that can be used to encrypt a communications key under the terminal key loaded in an ATM. Here things start to go wrong, as the cryptoprocessor does not distinguish between a terminal key and a PIN derivation key; it considers them both to be of the same type. The upshot is that an attacker can supply the device
with an account number, claiming that it is a communications key, and ask for it to be encrypted under the PIN derivation key.

Attacks like this extend protocol analysis all the way to the composition problem the problem that connecting two systems that are secure in
isolation can give a composite system that leaks. This had previously been seen as a separate issue, tackled with different conceptual tools.

Differential protocol analysis

We are now working on the second generation of API attacks, which exploit the application syntax supported by the cryptographic service. These attacks are even more powerful, and at least as interesting from the scientific point of view. PIN generation provides a neat example here too. In more detail, the standard PIN computation involves writing the result of the encryption as a hex string and decimalising it. As some banks like to let customers change their PIN to a more memorable number, there is a provision to add an offset to give the PIN that the customer actually enters:
Account number: 8807 0123 4569 1715
PIN derivation key: FEFE FEFE FEFE FEFE
Encrypted account number: A2CE 126C 69AE C82D
Natural (decimalised) PIN: 0224
Offset: 6565
Customer PIN: 6789

The typical implementation requires the programmer to send the cryptoprocessor the account number, a table describing the decimalisation (here, 0123 4567 8901 2345) and the offset. The processor returns the PIN, encrypted under the PIN storage key. The designers do not seem to have realised that a crooked programmer can manipulate the decimalisation table and the offset as well as the account number. A multitude of attacks follow. For example, one can send in an account number with a decimalisation table of 1111...11 to find out the ciphertext corresponding to a clear PIN of 1111, and then with a decimalisation table of 0111...11 to see if there is a zero in the first four digits of the encrypted account number (if so, the PIN, and thus the ciphertext output, will be different). By manipulating the decimalisation table further,
he can get all the digits in the PIN, and by then playing with the offset he can get their order. In total, the attack requires only 1525
unprivileged cryptoprocessor transactions to discover the PIN on a single target account.

This second type of attack takes protocol analysis into yet another realm: that of differential attacks. Over the last ten years, a number of techniques have been invented for attacking cryptographic systems by bombarding them with inputs with chosen differences.

For example, in differential cryptanalysis, one analyses the changes in the output of the encryption algorithm; while with differential power analysis, one measures changes in the current consumption or electromagnetic emissions
of the equipment. Now we have examples of how consecutive runs of a protocol can leak information if the inputs are suitably chosen. The resulting differential protocol analysis appears to be very powerful against
application-level crypto.

It will take us some time to figure out the general lessons to be drawn from attacks like this, the robustness principles that designers should use to avoid them, and the analysis techniques that might assure us of a particular
designs soundness. The randomisation of all protocols (another feature of Rogers work) is likely to be important.

Quantitative analysis and multiparty computation

Various researchers have speculated about whether there might one day be a quantitative analysis of protocol security. This might be feasible for
PIN processing applications as we can measure the information leakage per transaction in terms of the reduction of entropy in the unknown PIN. This
leads in turn to a possible real-world application of an attack previously considered theoretical.

Gus Simmons wrote extensively on covert channels in protocols. One such channel that is always present is the balking channel when one of the principals in a protocol signals something by halting and refusing to continue. This is normally considered unimportant as its information capacity is only a third of a bit per transaction. But with systems designed to cope
with large transaction volumes, this need no longer hold. For example, a Trojanned cryptoprocessor could balk when it sees a redetermined PIN. If the PIN length were eight digits, this would be unlikely to hinder normal
operation, but at a thousand transactions a second, a programmer could quickly find a number in a typical nine-digit account number range with just this PIN, and open an account for it. Once this kind of problem is appreciated, one can start to look for attacks that involve inducing rare error conditions that cause the cryptoprocessor to abort a transaction. (They exist.)

A third emerging link is between protocol analysis and secure multiparty computation. In application-level crypto we may have several inputs to a computation, some of them coming from an untrusted source, and we have to
stop users manipulating the computation to get outputs useful for bad purposes. In the PIN decimalisation example above, one might try to solve the problem by blocking tables such as 1111...11. Yet an attacker can get by with scarcely more work by using two normal-looking tables that differ slightly (another kind of differential attack). We might therefore think that if we cant sanitize the inputs to the computation, perhaps we can authenticate them,
and use only those tables that real banks actually use. But building every bank in the world into our trust base is what we were trying to avoid by
using cryptography!

Conclusion

The protocol work that started off a quarter of a century ago may have seemed at the time like a minor detail within the larger project of designing robust distributed systems. Yet it has already grown into the main unifying theme of security engineering. Application-level protocols, and especially those from which an attacker can harvest data over many runs, open up new problems.
The resulting analysis techniques are set to invade the world of composable security, and the world of multiparty computation. The influence, and the consequences, of Rogers contribution just keep on growing.

References

1. NEEDHAM, R.M. AND SCHROEDER, R.M.,
Using encryption
for authentication in large networks of computers. Comm. ACM, vol.
21, no. 12, pp. 993-999, 1978.

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

Updated 20 February 2003

18 February 2003

To: ukcrypto@chiark.greenend.org.uk
Subject: Citibank tries to gag crypto bug disclosure
Date: Thu, 20 Feb 2003 09:57:34 +0000
From: Ross Anderson <Ross.Anderson@cl.cam.ac.uk>

Citibank is trying to get an order in the High Court today gagging public disclosure of crypto vulnerabilities:

http://www.cl.cam.ac.uk/ftp/users/rja14/citibank_g ag.pdf

I have written to the judge opposing the order:

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

The background is that my student Mike Bond has discovered some really horrendous vulnerabilities in the cryptographic equipment commonly used to protect the PINs used to identify customers to cash machines:

http://www.cl.cam.ac.uk/TechReports/UCAM-CL-TR-560 .pdf

These vulnerabilities mean that bank insiders can almost trivially find out the PINs of any or all customers. The discoveries happened while Mike
and I were working as expert witnesses on a `phantom withdrawal' case.

The vulnerabilities are also scientifically interesting:

http://cryptome.org/pacc.htm

For the last couple of years or so there has been a rising tide of phantoms. I get emails with increasing frequency from people all over the world whose banks have debited them for ATM withdrawals that they deny making. Banks in
many countries simply claim that their systems are secure and so the customers must be responsible. It now looks like some of these vulnerabilities have also been discovered by the bad guys. Our courts and regulators should make the banks fix their systems, rather than just lying about security and dumping the costs on the customers.

Curiously enough, Citi was also the bank in the case that set US law on phantom withdrawals from ATMs (Judd v Citibank). They lost. I hope that's
an omen, if not a precedent ...
_____

Abstract

We present an attack on hardware security modules used by retail banks for the secure storage and verification of customer PINs in ATM (cash machine) infrastructures. By using adaptive decimalisation tables and guesses, the
maximum amount of information is learnt about the true PIN upon each guess.
It takes an average of 15 guesses to determine a four digit PIN using this technique, instead of the 5000 guesses intended. In a single 30 minute
lunch-break, an attacker can thus discover approximately 7000 PINs rather than 24 with the brute force method. With a $300 withdrawal limit per card, the potential bounty is raised from $7200 to $2.1 million and a single motivated attacker could withdraw $30{50 thousand of this each day. This attack thus presents a serious threat to bank security.

-- Mike Bond and Piotr Zielinski
Decimalisation table attacks for PIN cracking
February 2003

-----

From: Ross Anderson <Ross.Anderson@cl.cam.ac.uk>
To: ukcrypto@chiark.greenend.org.uk
Subject: Yet another failure of commercial cryptographic equipment
Date: Tue, 18 Feb 2003 17:52:13 +0000

I gave a talk at Cambridge yesterday in which I described a new and interesting family of attacks on cryptographic equipment. These attacks defeat machines such as the Racal RG7000 and the IBM 4758/CCA which are commonly used to protect the PINs and keys used in automatic teller machines.

The paper is available online at:

http://research.microsoft.com/~aherbert/volume63.p df [4.8MB]

as pages 27-30 in the PDF. [HTML below]

I got a fax yesterday informing me that an application is to be brought in the High Court, it seems by Citibank, on Thursday 20th February for `relief in relation to the protection of nformation which they accept as being confidential and which ought not to be in the public domain.'

I hope that no English court would go so far as to censor already published material. However, one just can't tell these days ...

Protocol Analysis, Composability and Computation

Ross Anderson, Michael Bond

University of Cambridge, England

Security protocols early days

The study of security protocols has been associated with Roger Needham since 1978, when he published the seminal paper on the subject with Mike Schroeder [1]. The problem they investigated was how to distribute cryptographic keys in a network of computers. One solution is to have an authentication service with which all the principals share a key; then if Alice wants to chat with Bob (for example) she can call the service and get two encrypted messages containing the same session key one encrypted under the key she shares with the service so she can read it, and one encrypted under the key Bob
shares with the service so Bob can read it. She can now send the second of these to Bob to establish secure communication. The mechanism that Needham and Schroeder designed for this evolved into Kerberos, which is now part of Windows and is probably the most widely used of all uthentication protocols.

Security protocols are now embedded in a great many applications, but it is common to find unexpected bugs in them. For example, many banks used to encrypt each customers PIN using a key known to their ATMs and write it on the ATM card magnetic strip. The idea was to provide a limited service when the network was down. Years later, a villain discovered that the account number and the encrypted PIN were not linked: he could make up a bank card with his own encrypted PIN but someone elses account number, and loot their account. He went on to steal a lot of money, and once in prison wrote a manual telling everyone else how to do it too. The banks had to spend millions on changing their systems.

Clarifying the assumptions

Researchers started to gnaw away at the protocols described in the literature and found fault with essentially all of them. The failure to bind protocol elements was one frequent problem; another was that old messages could be
replayed. In the case of the original Needham-Schroeder protocol, for example, the freshness of the key generated by the server was guaranteed to only one of the principals. This was not necessarily an attack, as its inventors only
claimed to protect honest insiders from dishonest outsiders. However, it led to a debate about the assumptions underlying security protocol design.
Do we protect only against outsiders, or against insiders? Against the malicious, or the merely careless? For example, if we use timestamps to guarantee protocol freshness, are we vulnerable to principals who carelessly let their clocks
run slow? Do we only consider an attacker to have won if he can impersonate an authorised principal, or do we need to stop people abusing the protocol
mechanisms to perform a service denial attack?

The early attacks led to a second seminal paper, which Roger wrote with Mike Burrows and Martin Abadi in 1989 [2], and which introduced a logic of
authentication. This enables an analyst to formalise the assumptions and goals of a security protocol, and to attempt to prove its correctness. When a proof cannot be found, the place at which one gets stuck often shows where an attack can be mounted. This style of analysis turned out to be very powerful, and a large literature quickly developed in which the BAN Logic
and other formal tools were developed and extended to tackle a range of problems in protocol design.

One of the remarkable things about the study of security protocols is that they have not become a solved problem. One might think that managing the
objects associated with authenticating users over a network passwords, keys and the like was a fairly compact problem which would have been done to death within a few years. However, the more we dig, the more we find.

Since 1992, Roger has hosted a protocols workshop every Easter. Early events dwelled on matters of authentication and logic, but by the mid-90s, the growing interest in electronic commerce was yielding papers on mechanisms for micropayments, bets, streaming media, mobile communications and electronic voting. Later years brought work on PKI, trust management and copyright enforcement. More and more problems come along as more and more businesses reinvent themselves online; threat models have also become more realistic, with dishonest insiders displacing the mythical evil hacker on the Internet.

Dishonest insiders, and the composition problem

Over the last two years, we have been exploring exactly how one might re-engineer cryptography to cope with dishonest insiders. One conclusion is that the analysis of security protocols must be extended to application programming interfaces. This is because the crypto keys used in authentication and payment protocols are often kept in separate hardware security processors, or at least in cryptographic libraries, to which access can be restricted using physical or logical mechanisms. However, an interface has to be exposed to the application program, which will occasionally be suborned whether by a corrupt insider, or by malware. How much harm can be done, and how can we limit it?

Protecting protocols was hard enough, and yet the typical protocol consists of 35 messages exposed to manipulation. The API of a modern crypto library or hardware cryptoprocessor may contain 30500 callable functions, many with a range of options. This provides a very rich and complex environment for mischief.

Attacks often involve using two separate echanisms provided by the cryptoprocessor for different purposes, each of which could be innocuous by itself but which combine to cause trouble. For example, it is common to compute a customer PIN by encrypting the account number with a PIN
derivation key: the cryptoprocessor then returns the PIN encrypted with a PIN storage key, so that the application has no access to its clear
value. So far, so good. Then there is another transaction that can be used to encrypt a communications key under the terminal key loaded in an ATM. Here things start to go wrong, as the cryptoprocessor does not distinguish between a terminal key and a PIN derivation key; it considers them both to be of the same type. The upshot is that an attacker can supply the device
with an account number, claiming that it is a communications key, and ask for it to be encrypted under the PIN derivation key.

Attacks like this extend protocol analysis all the way to the composition problem the problem that connecting two systems that are secure in
isolation can give a composite system that leaks. This had previously been seen as a separate issue, tackled with different conceptual tools.

Differential protocol analysis

We are now working on the second generation of API attacks, which exploit the application syntax supported by the cryptographic service. These attacks are even more powerful, and at least as interesting from the scientific point of view. PIN generation provides a neat example here too. In more detail, the standard PIN computation involves writing the result of the encryption as a hex string and decimalising it. As some banks like to let customers change their PIN to a more memorable number, there is a provision to add an offset to give the PIN that the customer actually enters:
Account number: 8807 0123 4569 1715
PIN derivation key: FEFE FEFE FEFE FEFE
Encrypted account number: A2CE 126C 69AE C82D
Natural (decimalised) PIN: 0224
Offset: 6565
Customer PIN: 6789

The typical implementation requires the programmer to send the cryptoprocessor the account number, a table describing the decimalisation (here, 0123 4567 8901 2345) and the offset. The processor returns the PIN, encrypted under the PIN storage key. The designers do not seem to have realised that a crooked programmer can manipulate the decimalisation table and the offset as well as the account number. A multitude of attacks follow. For example, one can send in an account number with a decimalisation table of 1111...11 to find out the ciphertext corresponding to a clear PIN of 1111, and then with a decimalisation table of 0111...11 to see if there is a zero in the first four digits of the encrypted account number (if so, the PIN, and thus the ciphertext output, will be different). By manipulating the decimalisation table further,
he can get all the digits in the PIN, and by then playing with the offset he can get their order. In total, the attack requires only 1525
unprivileged cryptoprocessor transactions to discover the PIN on a single target account.

This second type of attack takes protocol analysis into yet another realm: that of differential attacks. Over the last ten years, a number of techniques have been invented for attacking cryptographic systems by bombarding them with inputs with chosen differences.

For example, in differential cryptanalysis, one analyses the changes in the output of the encryption algorithm; while with differential power analysis, one measures changes in the current consumption or electromagnetic emissions
of the equipment. Now we have examples of how consecutive runs of a protocol can leak information if the inputs are suitably chosen. The resulting differential protocol analysis appears to be very powerful against
application-level crypto.

It will take us some time to figure out the general lessons to be drawn from attacks like this, the robustness principles that designers should use to avoid them, and the analysis techniques that might assure us of a particular
designs soundness. The randomisation of all protocols (another feature of Rogers work) is likely to be important.

Quantitative analysis and multiparty computation

Various researchers have speculated about whether there might one day be a quantitative analysis of protocol security. This might be feasible for
PIN processing applications as we can measure the information leakage per transaction in terms of the reduction of entropy in the unknown PIN. This
leads in turn to a possible real-world application of an attack previously considered theoretical.

Gus Simmons wrote extensively on covert channels in protocols. One such channel that is always present is the balking channel when one of the principals in a protocol signals something by halting and refusing to continue. This is normally considered unimportant as its information capacity is only a third of a bit per transaction. But with systems designed to cope
with large transaction volumes, this need no longer hold. For example, a Trojanned cryptoprocessor could balk when it sees a redetermined PIN. If the PIN length were eight digits, this would be unlikely to hinder normal
operation, but at a thousand transactions a second, a programmer could quickly find a number in a typical nine-digit account number range with just this PIN, and open an account for it. Once this kind of problem is appreciated, one can start to look for attacks that involve inducing rare error conditions that cause the cryptoprocessor to abort a transaction. (They exist.)

A third emerging link is between protocol analysis and secure multiparty computation. In application-level crypto we may have several inputs to a computation, some of them coming from an untrusted source, and we have to
stop users manipulating the computation to get outputs useful for bad purposes. In the PIN decimalisation example above, one might try to solve the problem by blocking tables such as 1111...11. Yet an attacker can get by with scarcely more work by using two normal-looking tables that differ slightly (another kind of differential attack). We might therefore think that if we cant sanitize the inputs to the computation, perhaps we can authenticate them,
and use only those tables that real banks actually use. But building every bank in the world into our trust base is what we were trying to avoid by
using cryptography!

Conclusion

The protocol work that started off a quarter of a century ago may have seemed at the time like a minor detail within the larger project of designing robust distributed systems. Yet it has already grown into the main unifying theme of security engineering. Application-level protocols, and especially those from which an attacker can harvest data over many runs, open up new problems.
The resulting analysis techniques are set to invade the world of composable security, and the world of multiparty computation. The influence, and the consequences, of Rogers contribution just keep on growing.

References

1. NEEDHAM, R.M. AND SCHROEDER, R.M.,
Using encryption
for authentication in large networks of computers. Comm. ACM, vol.
21, no. 12, pp. 993-999, 1978.

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

Updated 20 February 2003

18 February 2003

To: ukcrypto@chiark.greenend.org.uk
Subject: Citibank tries to gag crypto bug disclosure
Date: Thu, 20 Feb 2003 09:57:34 +0000
From: Ross Anderson <Ross.Anderson@cl.cam.ac.uk>

Citibank is trying to get an order in the High Court today gagging public disclosure of crypto vulnerabilities:

http://www.cl.cam.ac.uk/ftp/users/rja14/citibank_g ag.pdf

I have written to the judge opposing the order:

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

The background is that my student Mike Bond has discovered some really horrendous vulnerabilities in the cryptographic equipment commonly used to protect the PINs used to identify customers to cash machines:

http://www.cl.cam.ac.uk/TechReports/UCAM-CL-TR-560 .pdf

These vulnerabilities mean that bank insiders can almost trivially find out the PINs of any or all customers. The discoveries happened while Mike
and I were working as expert witnesses on a `phantom withdrawal' case.

The vulnerabilities are also scientifically interesting:

http://cryptome.org/pacc.htm

For the last couple of years or so there has been a rising tide of phantoms. I get emails with increasing frequency from people all over the world whose banks have debited them for ATM withdrawals that they deny making. Banks in
many countries simply claim that their systems are secure and so the customers must be responsible. It now looks like some of these vulnerabilities have also been discovered by the bad guys. Our courts and regulators should make the banks fix their systems, rather than just lying about security and dumping the costs on the customers.

Curiously enough, Citi was also the bank in the case that set US law on phantom withdrawals from ATMs (Judd v Citibank). They lost. I hope that's
an omen, if not a precedent ...
_____

Abstract

We present an attack on hardware security modules used by retail banks for the secure storage and verification of customer PINs in ATM (cash machine) infrastructures. By using adaptive decimalisation tables and guesses, the
maximum amount of information is learnt about the true PIN upon each guess.
It takes an average of 15 guesses to determine a four digit PIN using this technique, instead of the 5000 guesses intended. In a single 30 minute
lunch-break, an attacker can thus discover approximately 7000 PINs rather than 24 with the brute force method. With a $300 withdrawal limit per card, the potential bounty is raised from $7200 to $2.1 million and a single motivated attacker could withdraw $30{50 thousand of this each day. This attack thus presents a serious threat to bank security.

-- Mike Bond and Piotr Zielinski
Decimalisation table attacks for PIN cracking
February 2003

-----

From: Ross Anderson <Ross.Anderson@cl.cam.ac.uk>
To: ukcrypto@chiark.greenend.org.uk
Subject: Yet another failure of commercial cryptographic equipment
Date: Tue, 18 Feb 2003 17:52:13 +0000

I gave a talk at Cambridge yesterday in which I described a new and interesting family of attacks on cryptographic equipment. These attacks defeat machines such as the Racal RG7000 and the IBM 4758/CCA which are commonly used to protect the PINs and keys used in automatic teller machines.

The paper is available online at:

http://research.microsoft.com/~aherbert/volume63.p df [4.8MB]

as pages 27-30 in the PDF. [HTML below]

I got a fax yesterday informing me that an application is to be brought in the High Court, it seems by Citibank, on Thursday 20th February for `relief in relation to the protection of nformation which they accept as being confidential and which ought not to be in the public domain.'

I hope that no English court would go so far as to censor already published material. However, one just can't tell these days ...

Protocol Analysis, Composability and Computation

Ross Anderson, Michael Bond

University of Cambridge, England

Security protocols early days

The study of security protocols has been associated with Roger Needham since 1978, when he published the seminal paper on the subject with Mike Schroeder [1]. The problem they investigated was how to distribute cryptographic keys in a network of computers. One solution is to have an authentication service with which all the principals share a key; then if Alice wants to chat with Bob (for example) she can call the service and get two encrypted messages containing the same session key one encrypted under the key she shares with the service so she can read it, and one encrypted under the key Bob
shares with the service so Bob can read it. She can now send the second of these to Bob to establish secure communication. The mechanism that Needham and Schroeder designed for this evolved into Kerberos, which is now part of Windows and is probably the most widely used of all uthentication protocols.

Security protocols are now embedded in a great many applications, but it is common to find unexpected bugs in them. For example, many banks used to encrypt each customers PIN using a key known to their ATMs and write it on the ATM card magnetic strip. The idea was to provide a limited service when the network was down. Years later, a villain discovered that the account number and the encrypted PIN were not linked: he could make up a bank card with his own encrypted PIN but someone elses account number, and loot their account. He went on to steal a lot of money, and once in prison wrote a manual telling everyone else how to do it too. The banks had to spend millions on changing their systems.

Clarifying the assumptions

Researchers started to gnaw away at the protocols described in the literature and found fault with essentially all of them. The failure to bind protocol elements was one frequent problem; another was that old messages could be
replayed. In the case of the original Needham-Schroeder protocol, for example, the freshness of the key generated by the server was guaranteed to only one of the principals. This was not necessarily an attack, as its inventors only
claimed to protect honest insiders from dishonest outsiders. However, it led to a debate about the assumptions underlying security protocol design.
Do we protect only against outsiders, or against insiders? Against the malicious, or the merely careless? For example, if we use timestamps to guarantee protocol freshness, are we vulnerable to principals who carelessly let their clocks
run slow? Do we only consider an attacker to have won if he can impersonate an authorised principal, or do we need to stop people abusing the protocol
mechanisms to perform a service denial attack?

The early attacks led to a second seminal paper, which Roger wrote with Mike Burrows and Martin Abadi in 1989 [2], and which introduced a logic of
authentication. This enables an analyst to formalise the assumptions and goals of a security protocol, and to attempt to prove its correctness. When a proof cannot be found, the place at which one gets stuck often shows where an attack can be mounted. This style of analysis turned out to be very powerful, and a large literature quickly developed in which the BAN Logic
and other formal tools were developed and extended to tackle a range of problems in protocol design.

One of the remarkable things about the study of security protocols is that they have not become a solved problem. One might think that managing the
objects associated with authenticating users over a network passwords, keys and the like was a fairly compact problem which would have been done to death within a few years. However, the more we dig, the more we find.

Since 1992, Roger has hosted a protocols workshop every Easter. Early events dwelled on matters of authentication and logic, but by the mid-90s, the growing interest in electronic commerce was yielding papers on mechanisms for micropayments, bets, streaming media, mobile communications and electronic voting. Later years brought work on PKI, trust management and copyright enforcement. More and more problems come along as more and more businesses reinvent themselves online; threat models have also become more realistic, with dishonest insiders displacing the mythical evil hacker on the Internet.

Dishonest insiders, and the composition problem

Over the last two years, we have been exploring exactly how one might re-engineer cryptography to cope with dishonest insiders. One conclusion is that the analysis of security protocols must be extended to application programming interfaces. This is because the crypto keys used in authentication and payment protocols are often kept in separate hardware security processors, or at least in cryptographic libraries, to which access can be restricted using physical or logical mechanisms. However, an interface has to be exposed to the application program, which will occasionally be suborned whether by a corrupt insider, or by malware. How much harm can be done, and how can we limit it?

Protecting protocols was hard enough, and yet the typical protocol consists of 35 messages exposed to manipulation. The API of a modern crypto library or hardware cryptoprocessor may contain 30500 callable functions, many with a range of options. This provides a very rich and complex environment for mischief.

Attacks often involve using two separate echanisms provided by the cryptoprocessor for different purposes, each of which could be innocuous by itself but which combine to cause trouble. For example, it is common to compute a customer PIN by encrypting the account number with a PIN
derivation key: the cryptoprocessor then returns the PIN encrypted with a PIN storage key, so that the application has no access to its clear
value. So far, so good. Then there is another transaction that can be used to encrypt a communications key under the terminal key loaded in an ATM. Here things start to go wrong, as the cryptoprocessor does not distinguish between a terminal key and a PIN derivation key; it considers them both to be of the same type. The upshot is that an attacker can supply the device
with an account number, claiming that it is a communications key, and ask for it to be encrypted under the PIN derivation key.

Attacks like this extend protocol analysis all the way to the composition problem the problem that connecting two systems that are secure in
isolation can give a composite system that leaks. This had previously been seen as a separate issue, tackled with different conceptual tools.

Differential protocol analysis

We are now working on the second generation of API attacks, which exploit the application syntax supported by the cryptographic service. These attacks are even more powerful, and at least as interesting from the scientific point of view. PIN generation provides a neat example here too. In more detail, the standard PIN computation involves writing the result of the encryption as a hex string and decimalising it. As some banks like to let customers change their PIN to a more memorable number, there is a provision to add an offset to give the PIN that the customer actually enters:
Account number: 8807 0123 4569 1715
PIN derivation key: FEFE FEFE FEFE FEFE
Encrypted account number: A2CE 126C 69AE C82D
Natural (decimalised) PIN: 0224
Offset: 6565
Customer PIN: 6789

The typical implementation requires the programmer to send the cryptoprocessor the account number, a table describing the decimalisation (here, 0123 4567 8901 2345) and the offset. The processor returns the PIN, encrypted under the PIN storage key. The designers do not seem to have realised that a crooked programmer can manipulate the decimalisation table and the offset as well as the account number. A multitude of attacks follow. For example, one can send in an account number with a decimalisation table of 1111...11 to find out the ciphertext corresponding to a clear PIN of 1111, and then with a decimalisation table of 0111...11 to see if there is a zero in the first four digits of the encrypted account number (if so, the PIN, and thus the ciphertext output, will be different). By manipulating the decimalisation table further,
he can get all the digits in the PIN, and by then playing with the offset he can get their order. In total, the attack requires only 1525
unprivileged cryptoprocessor transactions to discover the PIN on a single target account.

This second type of attack takes protocol analysis into yet another realm: that of differential attacks. Over the last ten years, a number of techniques have been invented for attacking cryptographic systems by bombarding them with inputs with chosen differences.

For example, in differential cryptanalysis, one analyses the changes in the output of the encryption algorithm; while with differential power analysis, one measures changes in the current consumption or electromagnetic emissions
of the equipment. Now we have examples of how consecutive runs of a protocol can leak information if the inputs are suitably chosen. The resulting differential protocol analysis appears to be very powerful against
application-level crypto.

It will take us some time to figure out the general lessons to be drawn from attacks like this, the robustness principles that designers should use to avoid them, and the analysis techniques that might assure us of a particular
designs soundness. The randomisation of all protocols (another feature of Rogers work) is likely to be important.

Quantitative analysis and multiparty computation

Various researchers have speculated about whether there might one day be a quantitative analysis of protocol security. This might be feasible for
PIN processing applications as we can measure the information leakage per transaction in terms of the reduction of entropy in the unknown PIN. This
leads in turn to a possible real-world application of an attack previously considered theoretical.

Gus Simmons wrote extensively on covert channels in protocols. One such channel that is always present is the balking channel when one of the principals in a protocol signals something by halting and refusing to continue. This is normally considered unimportant as its information capacity is only a third of a bit per transaction. But with systems designed to cope
with large transaction volumes, this need no longer hold. For example, a Trojanned cryptoprocessor could balk when it sees a redetermined PIN. If the PIN length were eight digits, this would be unlikely to hinder normal
operation, but at a thousand transactions a second, a programmer could quickly find a number in a typical nine-digit account number range with just this PIN, and open an account for it. Once this kind of problem is appreciated, one can start to look for attacks that involve inducing rare error conditions that cause the cryptoprocessor to abort a transaction. (They exist.)

A third emerging link is between protocol analysis and secure multiparty computation. In application-level crypto we may have several inputs to a computation, some of them coming from an untrusted source, and we have to
stop users manipulating the computation to get outputs useful for bad purposes. In the PIN decimalisation example above, one might try to solve the problem by blocking tables such as 1111...11. Yet an attacker can get by with scarcely more work by using two normal-looking tables that differ slightly (another kind of differential attack). We might therefore think that if we cant sanitize the inputs to the computation, perhaps we can authenticate them,
and use only those tables that real banks actually use. But building every bank in the world into our trust base is what we were trying to avoid by
using cryptography!

Conclusion

The protocol work that started off a quarter of a century ago may have seemed at the time like a minor detail within the larger project of designing robust distributed systems. Yet it has already grown into the main unifying theme of security engineering. Application-level protocols, and especially those from which an attacker can harvest data over many runs, open up new problems.
The resulting analysis techniques are set to invade the world of composable security, and the world of multiparty computation. The influence, and the consequences, of Rogers contribution just keep on growing.

References

1. NEEDHAM, R.M. AND SCHROEDER, R.M.,
Using encryption
for authentication in large networks of computers. Comm. ACM, vol.
21, no. 12, pp. 993-999, 1978.

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

Updated 20 February 2003

18 February 2003

To: ukcrypto@chiark.greenend.org.uk
Subject: Citibank tries to gag crypto bug disclosure
Date: Thu, 20 Feb 2003 09:57:34 +0000
From: Ross Anderson <Ross.Anderson@cl.cam.ac.uk>

Citibank is trying to get an order in the High Court today gagging public disclosure of crypto vulnerabilities:

http://www.cl.cam.ac.uk/ftp/users/rja14/citibank_g ag.pdf

I have written to the judge opposing the order:

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

The background is that my student Mike Bond has discovered some really horrendous vulnerabilities in the cryptographic equipment commonly used to protect the PINs used to identify customers to cash machines:

http://www.cl.cam.ac.uk/TechReports/UCAM-CL-TR-560 .pdf

These vulnerabilities mean that bank insiders can almost trivially find out the PINs of any or all customers. The discoveries happened while Mike
and I were working as expert witnesses on a `phantom withdrawal' case.

The vulnerabilities are also scientifically interesting:

http://cryptome.org/pacc.htm

For the last couple of years or so there has been a rising tide of phantoms. I get emails with increasing frequency from people all over the world whose banks have debited them for ATM withdrawals that they deny making. Banks in
many countries simply claim that their systems are secure and so the customers must be responsible. It now looks like some of these vulnerabilities have also been discovered by the bad guys. Our courts and regulators should make the banks fix their systems, rather than just lying about security and dumping the costs on the customers.

Curiously enough, Citi was also the bank in the case that set US law on phantom withdrawals from ATMs (Judd v Citibank). They lost. I hope that's
an omen, if not a precedent ...
_____

Abstract

We present an attack on hardware security modules used by retail banks for the secure storage and verification of customer PINs in ATM (cash machine) infrastructures. By using adaptive decimalisation tables and guesses, the
maximum amount of information is learnt about the true PIN upon each guess.
It takes an average of 15 guesses to determine a four digit PIN using this technique, instead of the 5000 guesses intended. In a single 30 minute
lunch-break, an attacker can thus discover approximately 7000 PINs rather than 24 with the brute force method. With a $300 withdrawal limit per card, the potential bounty is raised from $7200 to $2.1 million and a single motivated attacker could withdraw $30{50 thousand of this each day. This attack thus presents a serious threat to bank security.

-- Mike Bond and Piotr Zielinski
Decimalisation table attacks for PIN cracking
February 2003

-----

From: Ross Anderson <Ross.Anderson@cl.cam.ac.uk>
To: ukcrypto@chiark.greenend.org.uk
Subject: Yet another failure of commercial cryptographic equipment
Date: Tue, 18 Feb 2003 17:52:13 +0000

I gave a talk at Cambridge yesterday in which I described a new and interesting family of attacks on cryptographic equipment. These attacks defeat machines such as the Racal RG7000 and the IBM 4758/CCA which are commonly used to protect the PINs and keys used in automatic teller machines.

The paper is available online at:

http://research.microsoft.com/~aherbert/volume63.p df [4.8MB]

as pages 27-30 in the PDF. [HTML below]

I got a fax yesterday informing me that an application is to be brought in the High Court, it seems by Citibank, on Thursday 20th February for `relief in relation to the protection of nformation which they accept as being confidential and which ought not to be in the public domain.'

I hope that no English court would go so far as to censor already published material. However, one just can't tell these days ...

Protocol Analysis, Composability and Computation

Ross Anderson, Michael Bond

University of Cambridge, England

Security protocols early days

The study of security protocols has been associated with Roger Needham since 1978, when he published the seminal paper on the subject with Mike Schroeder [1]. The problem they investigated was how to distribute cryptographic keys in a network of computers. One solution is to have an authentication service with which all the principals share a key; then if Alice wants to chat with Bob (for example) she can call the service and get two encrypted messages containing the same session key one encrypted under the key she shares with the service so she can read it, and one encrypted under the key Bob
shares with the service so Bob can read it. She can now send the second of these to Bob to establish secure communication. The mechanism that Needham and Schroeder designed for this evolved into Kerberos, which is now part of Windows and is probably the most widely used of all uthentication protocols.

Security protocols are now embedded in a great many applications, but it is common to find unexpected bugs in them. For example, many banks used to encrypt each customers PIN using a key known to their ATMs and write it on the ATM card magnetic strip. The idea was to provide a limited service when the network was down. Years later, a villain discovered that the account number and the encrypted PIN were not linked: he could make up a bank card with his own encrypted PIN but someone elses account number, and loot their account. He went on to steal a lot of money, and once in prison wrote a manual telling everyone else how to do it too. The banks had to spend millions on changing their systems.

Clarifying the assumptions

Researchers started to gnaw away at the protocols described in the literature and found fault with essentially all of them. The failure to bind protocol elements was one frequent problem; another was that old messages could be
replayed. In the case of the original Needham-Schroeder protocol, for example, the freshness of the key generated by the server was guaranteed to only one of the principals. This was not necessarily an attack, as its inventors only
claimed to protect honest insiders from dishonest outsiders. However, it led to a debate about the assumptions underlying security protocol design.
Do we protect only against outsiders, or against insiders? Against the malicious, or the merely careless? For example, if we use timestamps to guarantee protocol freshness, are we vulnerable to principals who carelessly let their clocks
run slow? Do we only consider an attacker to have won if he can impersonate an authorised principal, or do we need to stop people abusing the protocol
mechanisms to perform a service denial attack?

The early attacks led to a second seminal paper, which Roger wrote with Mike Burrows and Martin Abadi in 1989 [2], and which introduced a logic of
authentication. This enables an analyst to formalise the assumptions and goals of a security protocol, and to attempt to prove its correctness. When a proof cannot be found, the place at which one gets stuck often shows where an attack can be mounted. This style of analysis turned out to be very powerful, and a large literature quickly developed in which the BAN Logic
and other formal tools were developed and extended to tackle a range of problems in protocol design.

One of the remarkable things about the study of security protocols is that they have not become a solved problem. One might think that managing the
objects associated with authenticating users over a network passwords, keys and the like was a fairly compact problem which would have been done to death within a few years. However, the more we dig, the more we find.

Since 1992, Roger has hosted a protocols workshop every Easter. Early events dwelled on matters of authentication and logic, but by the mid-90s, the growing interest in electronic commerce was yielding papers on mechanisms for micropayments, bets, streaming media, mobile communications and electronic voting. Later years brought work on PKI, trust management and copyright enforcement. More and more problems come along as more and more businesses reinvent themselves online; threat models have also become more realistic, with dishonest insiders displacing the mythical evil hacker on the Internet.

Dishonest insiders, and the composition problem

Over the last two years, we have been exploring exactly how one might re-engineer cryptography to cope with dishonest insiders. One conclusion is that the analysis of security protocols must be extended to application programming interfaces. This is because the crypto keys used in authentication and payment protocols are often kept in separate hardware security processors, or at least in cryptographic libraries, to which access can be restricted using physical or logical mechanisms. However, an interface has to be exposed to the application program, which will occasionally be suborned whether by a corrupt insider, or by malware. How much harm can be done, and how can we limit it?

Protecting protocols was hard enough, and yet the typical protocol consists of 35 messages exposed to manipulation. The API of a modern crypto library or hardware cryptoprocessor may contain 30500 callable functions, many with a range of options. This provides a very rich and complex environment for mischief.

Attacks often involve using two separate echanisms provided by the cryptoprocessor for different purposes, each of which could be innocuous by itself but which combine to cause trouble. For example, it is common to compute a customer PIN by encrypting the account number with a PIN
derivation key: the cryptoprocessor then returns the PIN encrypted with a PIN storage key, so that the application has no access to its clear
value. So far, so good. Then there is another transaction that can be used to encrypt a communications key under the terminal key loaded in an ATM. Here things start to go wrong, as the cryptoprocessor does not distinguish between a terminal key and a PIN derivation key; it considers them both to be of the same type. The upshot is that an attacker can supply the device
with an account number, claiming that it is a communications key, and ask for it to be encrypted under the PIN derivation key.

Attacks like this extend protocol analysis all the way to the composition problem the problem that connecting two systems that are secure in
isolation can give a composite system that leaks. This had previously been seen as a separate issue, tackled with different conceptual tools.

Differential protocol analysis

We are now working on the second generation of API attacks, which exploit the application syntax supported by the cryptographic service. These attacks are even more powerful, and at least as interesting from the scientific point of view. PIN generation provides a neat example here too. In more detail, the standard PIN computation involves writing the result of the encryption as a hex string and decimalising it. As some banks like to let customers change their PIN to a more memorable number, there is a provision to add an offset to give the PIN that the customer actually enters:
Account number: 8807 0123 4569 1715
PIN derivation key: FEFE FEFE FEFE FEFE
Encrypted account number: A2CE 126C 69AE C82D
Natural (decimalised) PIN: 0224
Offset: 6565
Customer PIN: 6789

The typical implementation requires the programmer to send the cryptoprocessor the account number, a table describing the decimalisation (here, 0123 4567 8901 2345) and the offset. The processor returns the PIN, encrypted under the PIN storage key. The designers do not seem to have realised that a crooked programmer can manipulate the decimalisation table and the offset as well as the account number. A multitude of attacks follow. For example, one can send in an account number with a decimalisation table of 1111...11 to find out the ciphertext corresponding to a clear PIN of 1111, and then with a decimalisation table of 0111...11 to see if there is a zero in the first four digits of the encrypted account number (if so, the PIN, and thus the ciphertext output, will be different). By manipulating the decimalisation table further,
he can get all the digits in the PIN, and by then playing with the offset he can get their order. In total, the attack requires only 1525
unprivileged cryptoprocessor transactions to discover the PIN on a single target account.

This second type of attack takes protocol analysis into yet another realm: that of differential attacks. Over the last ten years, a number of techniques have been invented for attacking cryptographic systems by bombarding them with inputs with chosen differences.

For example, in differential cryptanalysis, one analyses the changes in the output of the encryption algorithm; while with differential power analysis, one measures changes in the current consumption or electromagnetic emissions
of the equipment. Now we have examples of how consecutive runs of a protocol can leak information if the inputs are suitably chosen. The resulting differential protocol analysis appears to be very powerful against
application-level crypto.

It will take us some time to figure out the general lessons to be drawn from attacks like this, the robustness principles that designers should use to avoid them, and the analysis techniques that might assure us of a particular
designs soundness. The randomisation of all protocols (another feature of Rogers work) is likely to be important.

Quantitative analysis and multiparty computation

Various researchers have speculated about whether there might one day be a quantitative analysis of protocol security. This might be feasible for
PIN processing applications as we can measure the information leakage per transaction in terms of the reduction of entropy in the unknown PIN. This
leads in turn to a possible real-world application of an attack previously considered theoretical.

Gus Simmons wrote extensively on covert channels in protocols. One such channel that is always present is the balking channel when one of the principals in a protocol signals something by halting and refusing to continue. This is normally considered unimportant as its information capacity is only a third of a bit per transaction. But with systems designed to cope
with large transaction volumes, this need no longer hold. For example, a Trojanned cryptoprocessor could balk when it sees a redetermined PIN. If the PIN length were eight digits, this would be unlikely to hinder normal
operation, but at a thousand transactions a second, a programmer could quickly find a number in a typical nine-digit account number range with just this PIN, and open an account for it. Once this kind of problem is appreciated, one can start to look for attacks that involve inducing rare error conditions that cause the cryptoprocessor to abort a transaction. (They exist.)

A third emerging link is between protocol analysis and secure multiparty computation. In application-level crypto we may have several inputs to a computation, some of them coming from an untrusted source, and we have to
stop users manipulating the computation to get outputs useful for bad purposes. In the PIN decimalisation example above, one might try to solve the problem by blocking tables such as 1111...11. Yet an attacker can get by with scarcely more work by using two normal-looking tables that differ slightly (another kind of differential attack). We might therefore think that if we cant sanitize the inputs to the computation, perhaps we can authenticate them,
and use only those tables that real banks actually use. But building every bank in the world into our trust base is what we were trying to avoid by
using cryptography!

Conclusion

The protocol work that started off a quarter of a century ago may have seemed at the time like a minor detail within the larger project of designing robust distributed systems. Yet it has already grown into the main unifying theme of security engineering. Application-level protocols, and especially those from which an attacker can harvest data over many runs, open up new problems.
The resulting analysis techniques are set to invade the world of composable security, and the world of multiparty computation. The influence, and the consequences, of Rogers contribution just keep on growing.

References

1. NEEDHAM, R.M. AND SCHROEDER, R.M.,
Using encryption
for authentication in large networks of computers. Comm. ACM, vol.
21, no. 12, pp. 993-999, 1978.

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

Link to PDF given in page

Link to PDF

Dasher was featured on slashdot a while ago. "Dasher is an information-efficient text-entry interface, driven by natural continuous pointing gestures. Dasher is a competitive text-entry system wherever a full-size keyboard cannot be used". It has two features that are important to your situation: one, it has predictive behavior, meaning that it sort of guesses what you want to write and makes it easier to say "that's exactly what I meant", all this without losing the ability to input stuff even if dasher can't guess it; and it doesn't require a keyboard. You could even rig some sort of visual tracker so the user won't need anything but her eyes.

Check out Dasher here.

Yeah, it's a shame that XFree86's monitor database doesn't include the physical dimensions of the monitor so it can set the dpi correctly. (Although I would prefer to use micrometres-per-dot rather than dots-per-inch.)

Too bad that isn't so secure after all. 1 in 150 of those cards can be guessed by simply testing them in ATM terminals.

So, if it didn't require an ATM terminal... wow. We're talking microseconds here?

" We found it astonishing that our MCI and AT&T calling cards had the PIN number stored in the magnetic stripe WITH NO ENCRYPTION! "

Yes, there's a lot of crappy PIN security out there. Best to avoid it.

Check if your card has crappy PIN security! Next time you swipe it through a POS debit machine at your local small store (which doesn't have a full-time linkup to the bank) enter the wrong PIN. If it tells you it's wrong without dialing out, and your bank is like mine and only supports PIN sizes between 4 and 6 digits, there's less than 1 million combinations to try. That shouldn't take a good computer more than a couple of minutes, and unless the debit machine has a demagnetizer, I don't think it can hurt your card. Of course, a smart person wouldn't take chances and would clone it first. Oh, look, now I can't enter the US. Oh well.

I think I'm going to buy the used POS debit machine I saw at the local junkshop. Could be piles of fun. I'll charge myself a dollar on it and see what happens...

Recent research suggests that there is an excess of L-amino acids (the specific enantiomer used in life-proteins) found in space, suggesting that the chiral specific process involving circular polarized light (mentioned in the article) could have lead to the amino acids that were found on the Murchison (and other meteorites).

From the article:
Recently it has been discovered that an excess of L-amino acids is present in the Murchison and Murray meteorites indicating that a preference for L-amino acids existed in solar system material before there was life on Earth. This supports an idea, first proposed by Rubenstein et al. (1983, Nature 306, 118), for an extraterrestrial origin for homochirality.

In this model the action of circular polarized light on interstellar chiral molecules introduced a left handed excess into molecules in the material from which the solar system formed. ...

If our own solar system formed in such a region of high circular polarization, it could have led to the excess of L-amino acids which we see in meteorites and to the homochirality of biological molecules. It is possible that without such a process operating it would not be possible for life to start. This may have implications for the frequency of occurrence of life in the universe.

Yeah, that's going to happen anytime soon. Face it, we've got the staunchest fully paid up supporters of MS "running" our country.

Now that's not fair, according to a report from the University of Cambridge computing laboratory.

Dear God, what have they done?

We had to replace already the Lelon capacitors mentioned in that story in more than half a dozen SunRay1 clients, which had failed exactly in the way described (details and photo).

Nice to hear the newly emerging espionage-twist of that story ...

But my biometric identity is part of my keypair, and if the keypair is validated with each transaction, how does he fake my biometric identity?

The attacker doesn't fake your biometrics. He bribes a government clerk to produce a genuine government card with your stolen details such as SSN, bank accounts, credit card numbers, medical records, etc. and his fingerprint or retinal print. Similar to current credit card cloning, jus t a different procedure to produce the cloned card.

BTW using your biometrics as the actual public/private key data is very bad, and hopefully no system uses it. Because nearly every biometrics system is thought of as producing a small amount of random data, ie. a shared secret, which cannot withstand attacks if the validation system is compromised. A organized crime owned storefront could gather biometric data/keys as well as legimate banking details for the valid customer transaction.

More common designs involve the biometrics info as a symmetric (key-wrapping) key to protect the private key as it is stored on the smartcard. This means the biometrics never leave the smartcard if the smartcard can collect the biometrics directly itself.

There is also the issue that biometrics are harder (and limited) to revoke in the event of a compromise. You have a very small finite number of fingers and eyes.

If your argument is based on the fact that the computer system is compromisable and my entire identity record (public keys) is replaced with a fake identity record, I'll notice within the day and/or hour that this has taken place and can quickly stop it. Plus I don't believe that a public keyserver that stores biometrically authenticated data would necessarily be so easily compromisable. Not impossible, but very difficult.

The forged card is an duplicate, not a replacement. Your card is still valid, and you will be able to withdraw from the ATM as long as there is still money in your bank account / credit limit. Like a forged plastic credit card with magstrip, your card is still accepted as long as your account is less than your credit limit.

This is where I get lost in all this. The system is always attackable, always will be, but shouldn't the parts of the system make those attacks far more expensive, complicated and difficult?

Give the professional criminal some credit, they will use the path of least resistance, and often of least sophistication.

It doesn't matter if the front side of your house has reinforced armoured doors and windows, if the burgular can simply go in the unlocked patio door in the backyard. So why expect any less of the forger / identity thief?

This is covered in the archives if RISKS digest, Secrets and Lies, and Security Engineering.

Come on, Intel. Do it. Centrino for the desktop. I dare ya. I double-dog dare ya.

Oh yeah...any DRM features in Centrino? That's the only downside I can think of.

You are right, the human factor is often ignored in building secure systems, though Schneier's Secrets and Lies and Anderson's Security Engineering (Chapter 3 I believe) deals with building entire systems that are secure including making them usable to the human users.

why can't the crypto whizzes put together a few lines of math.h and networking code to be a proof of concept?

Nearly all cryptographers do write reference implementations of their cryptographic algorithms. Rivest (RSA, MD4, MD5?, RC4, RC5, many more), Schneier (Blowfish, Twofish), Daemen (AES), Rijmen (AES), and many others write their own code AFAIK.

The issue that Peter Gutmann is focusing on (cryptographic) security protocols and systems, not cryptographic primitives like encrypting, signing which can be insecure when used incorrectly. E.g. A working RSA implmentation can be written in about 100 lines of C and a multi-percision interger library like GMP or MPI. The problem is that unless you do message padding following a scheme like OEAP your security is not as strong as expected / advertised.

crypto is very much an applied field, so the theorists should include example source in their papers.

Cryptography / cryptology falls into a relation with number theory and abstract algebra and computation computer science. Security Engineering is the practice of building secure systems including using cryptographic algorithms and protocols.

> a TuxPod
Probably should be 'tuxPod', or even 'tPod'?

> It should be possible to put something together to allow you to use the scroll wheel
> to enter text (I'm thinking something like [snip!]
*I'm* thinking something like Dasher...

follower@iname

Many people have posted to explain that you are all wrong about this. The bigger question is, where did you get your misinformation? Was it perhaps from the TCPA/Palladium FAQ? That FAQ is full of misinformation! You can't trust a word in it.

Someone yesterday posted that TCPA had good uses. They were accused of spreading FUD! And yet people post all kinds of totally incorrect information about Palladium and TCPA and nobody objects. People don't seem to mind when they are lied to, as long as the people doing the lying are on the same side. But lies which promote your goals are just as bad as lies which oppose them! In the long run, lying hurts you because eventually the truth will come out.

More and more, people are learning the truth behind Palladium (excuse me, the Windows next generation secure computing platform - boy, that just rolls off the tongue, doesn't it?) and TCPA. It's not great news, but it's not nearly as bad as some of the doomsayers were claiming. Let us rededicate ourselves to dealing with reality, to getting the full facts about these technologies and not believing every net.rumor that someone is mongering.

Among their clients, Dittus Commuications counts BSA (Business Software Alliance), Intel and Microsoft.

These simple facts are revealed by Dittus' press release, about yesterday's event and the actual press release from the event.

So, how does Dittus work? Go to dittus.com to find out. Clicking on "services", then "coalitions & grassroots" gives you this:

Dittus tailors each coalition and grassroots program to help our clients run a successful campaign. We will recruit and mobilize the right people to help you influence key decision makers and retain their support. Through experience, effective monitoring, innovation and the ability to deliver the right message at the appropriate decision points, Dittus will help you win.

Coalition Building
Support voiced from the right allies can vastly amplify your message and add credibility to your argument. Marshalling diverse players can be a delicate art, and Dittus Communications has a flair for it. On a range of hotly debated issues, we have successfully managed varied alliances across the political spectrum.

Grassroots Organizing
The quickest way to policymakers' hearts is through their backyards. Time and again, Dittus Communications has demonstrated an uncanny gift for grassroots campaign management. We're known for finding innovative ways to mobilize widespread support and sway important votes.

Now, click on "clients" on the main menu to the left, then "case studies". Read through a couple of the studies, for example "Americans for Computer Privacy" (text mirrored below). Interestingly, you'll find that Dittus was behind the strategy and campaign that in the end lifted U.S. export limitations on strong encryption. Now of course, the current DRM campaign they are running on behalf of their clients, is pretty much the opposite of the goals of "Americans for Computer Privacy". This campaign is no more than a call for unregulated, oligopoly-controlled implementation of TCPA / Palladium, but of course they never mention TCPA/Palladium. I am not surprised to find all of the TCPA founding members in this so called "Alliance for Digital Progress".

This is a fight were it is in the public interest that both parties fail.

Here's Dittus' own case study on how they helped relax U.S. encryption regulations:

"In one six-month period, Dittus Communications generated more than 130 million media impressions."

CHALLENGE
Encryption systems, which scramble electronic communications and information, allow users to communicate on the internet with confidence in the knowledge that their security and privacy are protected. In 1998, however, American manufacturers were facing heavy export restrictions by the U.S. government on U.S.-made encryption products, thus restricting American manufacturers from meeting global demand. Momentum was also building in Washington for policies that would allow the FBI to unlock encrypted information.

STRATEGY
An existing client asked Dittus Communications to draft a strategic plan that would rally the support of other industries and manufacturers similarly affected by U.S. encryption policies. The Dittus plan called for the creation of a "strange bedfellows" coalition that would energize organizations outside of the technology community to support encryption policy and oppose the FBI's mandatory key recovery proposal. Dittus also recognized that the issues surrounding the encryption debate would have to be reframed in order to broaden support among the memeber organizations and in Congress. After conducting significant focus group research, Dittus reframed the debate to focus on privacy and security. And thus Americans for Computer Privacy was born.

Dittus then actively recruited groups such as the Louisiana Sheriff's Association, Americans for Tax Reform, and the Eagle Forum to join the coalition. Dittus helped build and manage the coalition that grew to 40 trade associations and more than 100 companies representing financial services, manufacturing, high- tech, and trasportation industries as well as law enforcement, civil-liberty, taxpayer, and privacy groups.

Understanding that Members of Congress needed to hear from their constituents regarding this issue, Dittus mounted an extensive public affairs campaign nationally and in targeted congressional districts that delivered favorable editorials; placed ads, op- eds and letters to the editor; and generated grassroots, third- party, and coalition support. Our objective was to convince lawmakers to reform current policy and to stop the passage of anti-privacy legislation.

We organized Hill drops, visiting every congressional office with ACP information packets; established relationships with key staff and press secretaries; organized demonstrations and briefings; and developed press/lobby kits and papers. Building widespread, vocal grassroots support among targeted congressional constituencies was critical. We targeted the campaign to the markets of lawmakers who were either undecided about the issue or against it.

RESULTS
In one six-month period, Dittus Communications genereated more than 130 million media impressions on the coalition's position. We earned favorable coverage in the Boston Globe, Chicago Tribune, Houston Chronicle, Los Angeles Times, New York Times, San Fransisco Chronicle, USA Today, Washington Post, Wall Street Journal, Business Daily, Newsweek, Roll Call, PC Magazine, Internet Week, Time, U.S. News & World Report, and Wired. We also booked ACP spokespeople on Bloomberg TV, MSNBC, the Fox News Channel, and all three major TV networks, as well as radio talk shows nationwide.

Our campaign created a groundswell of public and congressional support for the SAFE Act and killed the third- party key recovery plan. It also brought the Administration, which had shown little movement in support of ACP's position on the issue, to the negotiating table. The Administration also eased its encryption export policy, allowing American companies to export strong encryption overseas.