Updated 20 February 2003
18 February 2003
To: ukcrypto@chiark.greenend.org.uk
Subject: Citibank tries to gag crypto bug disclosure
Date: Thu, 20 Feb 2003 09:57:34 +0000
From: Ross Anderson
Citibank is trying to get an order in the High Court today gagging public
disclosure of crypto vulnerabilities:
http://www.cl.cam.ac.uk/ftp/users/rja14/citibank_g ag.pdf
I have written to the judge opposing the order:
http://www.cl.cam.ac.uk/ftp/users/rja14/citibank_r esponse.pdf
The background is that my student Mike Bond has discovered some really
horrendous vulnerabilities in the cryptographic equipment commonly used
to protect the PINs used to identify customers to cash machines:
http://www.cl.cam.ac.uk/TechReports/UCAM-CL-TR-560.pdf
These vulnerabilities mean that bank insiders can almost trivially find
out the PINs of any or all customers. The discoveries happened while Mike
and I were working as expert witnesses on a `phantom withdrawal' case.
The vulnerabilities are also scientifically interesting:
http://cryptome.org/pacc.htm
For the last couple of years or so there has been a rising tide of phantoms.
I get emails with increasing frequency from people all over the world whose
banks have debited them for ATM withdrawals that they deny making. Banks in
many countries simply claim that their systems are secure and so the
customers must be responsible. It now looks like some of these
vulnerabilities have also been discovered by the bad guys. Our courts and
regulators should make the banks fix their systems, rather than just lying
about security and dumping the costs on the customers.
Curiously enough, Citi was also the bank in the case that set US law on
phantom withdrawals from ATMs (Judd v Citibank). They lost. I hope that's
an omen, if not a precedent...
_____
Abstract
We present an attack on hardware security modules used by retail banks for
the secure storage and verification of customer PINs in ATM (cash machine)
infrastructures. By using adaptive decimalisation tables and guesses, the
maximum amount of information is learnt about the true PIN upon each guess.
It takes an average of 15 guesses to determine a four digit PIN using this
technique, instead of the 5000 guesses intended. In a single 30 minute
lunch-break, an attacker can thus discover approximately 7000 PINs rather
than 24 with the brute force method. With a $300 withdrawal limit per card,
the potential bounty is raised from $7200 to $2.1 million and a single
motivated attacker could withdraw $30{50 thousand of this each day. This
attack thus presents a serious threat to bank security.
-- Mike Bond and Piotr Zielinski
Decimalisation table attacks for PIN cracking
February 2003
-----
From: Ross Anderson
To: ukcrypto@chiark.greenend.org.uk
Subject: Yet another failure of commercial cryptographic equipment
Date: Tue, 18 Feb 2003 17:52:13 +0000
I gave a talk at Cambridge yesterday in which I described a new and
interesting family of attacks on cryptographic equipment. These
attacks defeat machines such as the Racal RG7000 and the IBM 4758/CCA
which are commonly used to protect the PINs and keys used in automatic
teller machines.
The paper is available online at:
http://research.microsoft.com/~aherbert/volume63.p df [4.8MB]
as pages 27-30 in the PDF. [HTML below]
I got a fax yesterday informing me that an application is to be
brought in the High Court, it seems by Citibank, on Thursday 20th
February for `relief in relation to the protection of information
which they accept as being confidential and which ought not to be in
the public domain.'
I hope that no English court would go so far as to censor already
published material. However, one just can't tell these days...
Protocol Analysis, Composability and Computation
Ross Anderson, Michael Bond
University of Cambridge, England
Security protocols -- early days
The study of security protocols has been associated with Roger Needham since 1978, when he published the seminal paper on the subject with Mike Schroeder [1]. The problem they investigated was how to distribute cryptographic keys in a network of computers. One solution is to have an authentication service with which all the principals share a key; then if Alice wants to chat with Bob (for example) she can call the service and get two encrypted messages containing the same session key -- one encrypted under the key she shares with the service so she can read it, and one encrypted under the key Bob shares with the service so Bob can read it. She can now send the second of these to Bob to establish secure communication. The mechanism that Needham and Schroeder designed for this evolved into Kerberos, which is now part of Windows and is probably the most widely used of all authentication protocols.
Security protocols are now embedded in a great many applications, but it is common to find unexpected bugs in them. For example, many banks used to encrypt each customer's PIN using a key known to their ATMs and write it on the ATM card magnetic strip. The idea was to provide a limited service when the network was down. Years later, a villain discovered that the account number and the encrypted PIN were not linked: he could make up a bank card with his own encrypted PIN but someone else's account number, and loot their account. He went on to steal a lot of money, and once in prison wrote a manual telling everyone else how to do it too. The banks had to spend millions on changing their systems.
Clarifying the assumptions
Researchers started to gnaw away at the protocols described in the literature and found fault with essentially all of them. The failure to bind protocol elements was one frequent problem; another was that old messages could be replayed. In the case of the original Needham-Schroeder protocol, for example, the freshness of the key generated by the server was guaranteed to only one of the principals. This was not necessarily an attack, as its inventors only claimed to protect honest insiders from dishonest outsiders. However, it led to a debate about the assumptions underlying security protocol design. Do we protect only against outsiders, or against insiders? Against the malicious, or the merely careless? For example, if we use timestamps to guarantee protocol freshness, are we vulnerable to principals who carelessly let their clocks run slow? Do we only consider an attacker to have won if he can impersonate an authorised principal, or do we need to stop people abusing the protocol mechanisms to perform a service denial attack?
The early attacks led to a second seminal paper, which Roger wrote with Mike Burrows and Martin Abadi in 1989 [2], and which introduced a logic of authentication. This enables an analyst to formalise the assumptions and goals of a security protocol, and to attempt to prove its correctness. When a proof cannot be found, the place at which one gets stuck often shows where an attack can be mounted. This style of analysis turned out to be very powerful, and a large literature quickly developed in which the 'BAN Logic' and other formal tools were developed and extended to tackle a range of problems in protocol design.
One of the remarkable things about the study of security protocols is that they have not become a solved problem. One might think that managing the objects associated with authenticating users over a network -- passwords, keys and the like -- was a fairly compact problem which would have been done to death within a few years. However, the more we dig, the more we find.
Since 1992, Roger has hosted a protocols workshop every Easter. Early events dwelled on matters of authentication and logic, but by the mid-90s, the growing interest in electronic commerce was yielding papers on mechanisms for micropayments, bets, streaming media, mobile communications and electronic voting. Later years brought work on PKI, trust management and copyright enforcement. More and more problems come along as more and more businesses reinvent themselves online; threat models have also become more realistic, with dishonest insiders displacing the mythical 'evil hacker on the Internet'.
Dishonest insiders, and the composition problem
Over the last two years, we have been exploring exactly how one might re-engineer cryptography to cope with dishonest insiders. One conclusion is that the analysis of security protocols must be extended to application programming interfaces. This is because the crypto keys used in authentication and payment protocols are often kept in separate hardware security processors, or at least in cryptographic libraries, to which access can be restricted using physical or logical mechanisms. However, an interface has to be exposed to the application program, which will occasionally be suborned -- whether by a corrupt insider, or by malware. How much harm can be done, and how can we limit it?
Protecting protocols was hard enough, and yet the typical protocol consists of 3-5 messages exposed to manipulation. The API of a modern crypto library or hardware cryptoprocessor may contain 30-500 callable functions, many with a range of options. This provides a very rich and complex environment for mischief.
Attacks often involve using two separate mechanisms provided by the cryptoprocessor for different purposes, each of which could be innocuous by itself but which combine to cause trouble. For example, it is common to compute a customer PIN by encrypting the account number with a 'PIN derivation key': the cryptoprocessor then returns the PIN encrypted with a PIN storage key, so that the application has no access to its clear value. So far, so good. Then there is another transaction that can be used to encrypt a communications key under the terminal key loaded in an ATM. Here things start to go wrong, as the cryptoprocessor does not distinguish between a terminal key and a PIN derivation key; it considers them both to be of the same type. The upshot is that an attacker can supply the device with an account number, claiming that it is a communications key, and ask for it to be encrypted under the PIN derivation key.
Attacks like this extend protocol analysis all the way to the composition problem -- the problem that connecting two systems that are secure in isolation can give a composite system that leaks. This had previously been seen as a separate issue, tackled with different conceptual tools.
Differential protocol analysis
We are now working on the second generation of API attacks, which exploit the application syntax supported by the cryptographic service. These attacks are even more powerful, and at least as interesting from the scientific point of view. PIN generation provides a neat example here too. In more detail, the standard PIN computation involves writing the result of the encryption as a hex string and decimalising it. As some banks like to let customers change their PIN to a more memorable number, there is a provision to add an offset to give the PIN that the customer actually enters:
Account number: 8807 0123 4569 1715
PIN derivation key: FEFE FEFE FEFE FEFE
Encrypted account number: A2CE 126C 69AE C82D
Natural (decimalised) PIN: 0224
Offset: 6565
Customer PIN: 6789
The typical implementation requires the programmer to send the cryptoprocessor the account number, a table describing the decimalisation (here, '0123 4567 8901 2345') and the offset. The processor returns the PIN, encrypted under the PIN storage key. The designers do not seem to have realised that a crooked programmer can manipulate the decimalisation table and the offset as well as the account number. A multitude of attacks follow. For example, one can send in an account number with a decimalisation table of '1111...11' to find out the ciphertext corresponding to a clear PIN of '1111,' and then with a decimalisation table of '0111...11' to see if there is a zero in the first four digits of the encrypted account number (if so, the PIN, and thus the ciphertext output, will be different). By manipulating the decimalisation table further, he can get all the digits in the PIN, and by then playing with the offset he can get their order. In total, the attack requires only 15-25 unprivileged cryptoprocessor transactions to discover the PIN on a single target account.
This second type of attack takes protocol analysis into yet another realm: that of differential attacks. Over the last ten years, a number of techniques have been invented for attacking cryptographic systems by bombarding them with inputs with chosen differences.
For example, in differential cryptanalysis, one analyses the changes in the output of the encryption algorithm; while with differential power analysis, one measures changes in the current consumption or electromagnetic emissions of the equipment. Now we have examples of how consecutive runs of a protocol can leak information if the inputs are suitably chosen. The resulting 'differential protocol analysis' appears to be very powerful against application-level crypto.
It will take us some time to figure out the general lessons to be drawn from attacks like this, the robustness principles that designers should use to avoid them, and the analysis techniques that might assure us of a particular design's soundness. The randomisation of all protocols (another feature of Roger's work) is likely to be important.
Quantitative analysis and multiparty computation
Various researchers have speculated about whether there might one day be a quantitative analysis of protocol security. This might be feasible for PIN processing applications as we can measure the information leakage per transaction in terms of the reduction of entropy in the unknown PIN. This leads in turn to a possible real-world application of an attack previously considered theoretical.
Gus Simmons wrote extensively on covert channels in protocols. One such channel that is always present is the 'balking channel' -- when one of the principals in a protocol signals something by halting and refusing to continue. This is normally considered unimportant as its information capacity is only a third of a bit per transaction. But with systems designed to cope with large transaction volumes, this need no longer hold. For example, a Trojanned cryptoprocessor could balk when it sees a predetermined PIN. If the PIN length were eight digits, this would be unlikely to hinder normal operation, but at a thousand transactions a second, a programmer could quickly find a number in a typical nine-digit account number range with just this PIN, and open an account for it. Once this kind of problem is appreciated, one can start to look for attacks that involve inducing rare error conditions that cause the cryptoprocessor to abort a transaction. (They exist.)
A third emerging link is between protocol analysis and secure multiparty computation. In application-level crypto we may have several inputs to a computation, some of them coming from an untrusted source, and we have to stop users manipulating the computation to get outputs useful for bad purposes. In the PIN decimalisation example above, one might try to solve the problem by blocking tables such as 1111...11. Yet an attacker can get by with scarcely more work by using two normal-looking tables that differ slightly (another kind of differential attack). We might therefore think that if we can't sanitize the inputs to the computation, perhaps we can authenticate them, and use only those tables that real banks actually use. But building every bank in the world into our trust base is what we were trying to avoid by using cryptography!
Conclusion
The protocol work that started off a quarter of a century ago may have seemed at the time like a minor detail within the larger project of designing robust distributed systems. Yet it has already grown into the main unifying theme of security engineering. Application-level protocols, and especially those from which an attacker can harvest data over many runs, open up new problems. The resulting analysis techniques are set to invade the world of composable security, and the world of multiparty computation. The influence, and the consequences, of Roger's contribution just keep on growing.
References
1. NEEDHAM, R.M. AND SCHROEDER, R.M., 'Using encryption for authentication in large networks of computers.' Comm. ACM, vol. 21, no. 12, pp. 993-999, 1978.
2. BURROWS, M. ABADI, M. AND NEEDHAM, R.M., 'A logic of authentication,' ACM Transactions on Computer Systems, vol. 8, no. 1, pp. 18-36, 1990.
Regeestreshun inffurmeshun Regeestered Nu Neme-a N/A Oorgun eezeshun N/A
Peths Prefferences C:\Ducooments und Setteengs\JLungffeeeld\Eppleeceshun Deta\Oopera\Oopere7\pruffeele-a\oopere6.inee Sefe d veendoos C:\Ducooments und Setteengs\JLungffeeeld\Eppleeceshun Deta\Oopera\Oopere7\pruffeele-a\oopera.veen Buukm erks C:\Ducooments und Setteengs\JLungffeeeld\Eppleeceshun Deta\Oopera\Oopere7\pruffeele-a\oopere6.edr
Oopera durectury C:\Ducooments und Setteengs\JLungffeeeld\Eppleeceshun Deta\Oopera\Oopere7\pruffeele-a Ceche-a C:\Ducoo ments und Setteengs\JLungffeeeld\Eppleeceshun Deta\Oopera\Oopere7\pruffeele-a\ceche4 Meeel durectury C:\Ducooments und Setteengs\JLungffeeeld\Eppleeceshun Deta\Oopera\Oopere7\Meeel Help ducooments C:\Prugrem Feeles\Oopere7\Help
Ploog-in pet C:\Prugrem Feeles\Oopere7\Ploogeens C:\Prugrem Feeles\Oopere7\Prugrem\Ploogeens C:\Prugrem Feeles\Netscepe-a\Cummooneecetur\Prugrem\Ploogeens
Yes their sending these out to businesses in IL and saying that there's a 45 day grace period that will end on feb 28th. They are sending these letters to all registered businesses in the state and I think they got the addresses and contact info from the state. The reason I think this is becuase I have a home based business and have always used a po box for all business mail- the state is one basically the place that would have had my home address related to my business because they require a physical address for sales tax licensing.
About a week after receiving the bsa letter I got a very similar letter from microsoft mentioning the grace period and letting me know that if I need additional licenses I could get them for up to 20% off- then the fine print says that microsoft can't guarantee you any discount because you'll have to buy the additional licenses from one of their authorized resellers and that the resellers regulate the discounts they decide to give- so you may not really get one.
this has really pissed me off- I immediately killed my last windoze box and put redhat on it- I had just bought my first mac a few months before and it's great- I'm shooting for a dual powermac in the next six months. because I'm in a home based business that doesn't operate normal business hours they would basically have to have a search warrant to look at my computers. I dare them! I spoke to a few people about this and from what i've heard a search warrant cannot be issued to a private company for something like this. I'm so mad!!!
It's about fscking time people using pc's at least started catching up with the apples are used-
I work for a university and one of the grant projects I support recently bought about 40 ibooks with burners for students. One of the teachers in charge has us order $1700 worth of floppy drives with the reason being that it was the format they use to hand out and receive homework. cd's are so much cheaper, faster and more reliable that it's amazing it's not the standard for educators yet- teachers are behind the learning curve. And this is supposed to be a technology related grant program to boot! It was very frustrating to have to deal with a such a poor and wasteful decision.
There's a great art show in chicago right now that displaying a large quantity of audio, visual and standard art mediums that challenge copywrite as we know it. Many of the peices have been sued into submission until now. More info here and here
I went to the show's opening last night and I would highly recommend it, some of the bands will be playing live on feb 7th and 8th with an intense panel debate about copywrite with speakers like Lawrence Lessig and dj spooky on the 15th. The show will then be moving onto San Francisco.
This is where your email spam account comes into play.
Actually you don't even need to use your spam account for the realplayer setup- it doesn't authenticate the address for you to use the player. Mine currently set for 'biteme@real.com'
There seem to be a lot of complaints on the minimal speed boost for the iBook -> 12" PowerBook jump in cost.
minimal if you compare 800mhz to 867mhz, but also that it's an upgrade from a G3 to G4. Also adds 802.11G and bluetooth capabilities. It's also smaller in all deminsions including weight and has a slot drive and comes with the combo drive by default- the ibook doesn't.
Anyone actually look at the difference in the RAM the two products use? This is probably where the cost difference comes from, not the materials its made of.
iBooks seem to use 100 MHz SDRAM, 12" PowerBook uses 266MHz DDR and the 17" uses 333MHz DDR. This should have a pretty big performance boost, at least as much as the processor boost, probably a whole lot more. Apple never seem cutting edge on memory tech but at least they're now giving you something respectable with the high end powerbook. That was actually one of the things that kept me away from Mac before (not a gamer, all my critical software was availible on both). That and the still high price.
The 15" PowerBook is still using SDRAM though.
I think Apples are well worth the cost. I just bought an ibook a few weeks ago and I love it. I maxed everything out other than the screen because I wanted the small size... I should have waited. for a laptop the prices are still very competitive- you can't brew your own for less.
I print this every day for my boss and find it easier to just look at them rather than try to use the search function on their page. You can find the listings here. of course next week you'll just change the 2 in the url to a 3. we are usually searching for grant opportunities- this looks pretty interesting, I think I'll have to start looking for similar items.
NO, I was considering that I should have mentioned that in the first place after my original post. I suppose sex with yourself, or a non-living object would be more like 'vaporware' and still does not prevent one from being a virgin. although virginity was not my original thought either, many have commented that all geeks are not necessarily virgins anymore. But c'mon, anyone can get laid once!
before you mod me down, please note that I'm half drunk on a sunday afternoon and just got home from my girlfriend's place where we didn't have sex!!!
Slashdot Mirror
they've been predicting tons of disasters for years, a lot of them geological- has california ever tried to stop them?
Updated 20 February 2003 18 February 2003 To: ukcrypto@chiark.greenend.org.uk Subject: Citibank tries to gag crypto bug disclosure Date: Thu, 20 Feb 2003 09:57:34 +0000 From: Ross Anderson Citibank is trying to get an order in the High Court today gagging public disclosure of crypto vulnerabilities: http://www.cl.cam.ac.uk/ftp/users/rja14/citibank_g ag.pdf
I have written to the judge opposing the order:
http://www.cl.cam.ac.uk/ftp/users/rja14/citibank_r esponse.pdf
The background is that my student Mike Bond has discovered some really
horrendous vulnerabilities in the cryptographic equipment commonly used
to protect the PINs used to identify customers to cash machines:
http://www.cl.cam.ac.uk/TechReports/UCAM-CL-TR-560 .pdf
These vulnerabilities mean that bank insiders can almost trivially find
out the PINs of any or all customers. The discoveries happened while Mike
and I were working as expert witnesses on a `phantom withdrawal' case.
The vulnerabilities are also scientifically interesting:
http://cryptome.org/pacc.htm
For the last couple of years or so there has been a rising tide of phantoms.
I get emails with increasing frequency from people all over the world whose
banks have debited them for ATM withdrawals that they deny making. Banks in
many countries simply claim that their systems are secure and so the
customers must be responsible. It now looks like some of these
vulnerabilities have also been discovered by the bad guys. Our courts and
regulators should make the banks fix their systems, rather than just lying
about security and dumping the costs on the customers.
Curiously enough, Citi was also the bank in the case that set US law on
phantom withdrawals from ATMs (Judd v Citibank). They lost. I hope that's
an omen, if not a precedent ...
_____
Abstract
We present an attack on hardware security modules used by retail banks for
the secure storage and verification of customer PINs in ATM (cash machine)
infrastructures. By using adaptive decimalisation tables and guesses, the
maximum amount of information is learnt about the true PIN upon each guess.
It takes an average of 15 guesses to determine a four digit PIN using this
technique, instead of the 5000 guesses intended. In a single 30 minute
lunch-break, an attacker can thus discover approximately 7000 PINs rather
than 24 with the brute force method. With a $300 withdrawal limit per card,
the potential bounty is raised from $7200 to $2.1 million and a single
motivated attacker could withdraw $30{50 thousand of this each day. This
attack thus presents a serious threat to bank security.
-- Mike Bond and Piotr Zielinski
Decimalisation table attacks for PIN cracking
February 2003
-----
From: Ross Anderson
To: ukcrypto@chiark.greenend.org.uk
Subject: Yet another failure of commercial cryptographic equipment
Date: Tue, 18 Feb 2003 17:52:13 +0000
I gave a talk at Cambridge yesterday in which I described a new and
interesting family of attacks on cryptographic equipment. These
attacks defeat machines such as the Racal RG7000 and the IBM 4758/CCA
which are commonly used to protect the PINs and keys used in automatic
teller machines.
The paper is available online at:
http://research.microsoft.com/~aherbert/volume63.p df [4.8MB]
as pages 27-30 in the PDF. [HTML below]
I got a fax yesterday informing me that an application is to be
brought in the High Court, it seems by Citibank, on Thursday 20th
February for `relief in relation to the protection of information
which they accept as being confidential and which ought not to be in
the public domain.'
I hope that no English court would go so far as to censor already
published material. However, one just can't tell these days ...
Protocol Analysis, Composability and Computation
Ross Anderson, Michael Bond
University of Cambridge, England
Security protocols -- early days
The study of security protocols has been associated with Roger Needham since 1978, when he published the seminal paper on the subject with Mike Schroeder [1]. The problem they investigated was how to distribute cryptographic keys in a network of computers. One solution is to have an authentication service with which all the principals share a key; then if Alice wants to chat with Bob (for example) she can call the service and get two encrypted messages containing the same session key -- one encrypted under the key she shares with the service so she can read it, and one encrypted under the key Bob shares with the service so Bob can read it. She can now send the second of these to Bob to establish secure communication. The mechanism that Needham and Schroeder designed for this evolved into Kerberos, which is now part of Windows and is probably the most widely used of all authentication protocols.
Security protocols are now embedded in a great many applications, but it is common to find unexpected bugs in them. For example, many banks used to encrypt each customer's PIN using a key known to their ATMs and write it on the ATM card magnetic strip. The idea was to provide a limited service when the network was down. Years later, a villain discovered that the account number and the encrypted PIN were not linked: he could make up a bank card with his own encrypted PIN but someone else's account number, and loot their account. He went on to steal a lot of money, and once in prison wrote a manual telling everyone else how to do it too. The banks had to spend millions on changing their systems.
Clarifying the assumptions
Researchers started to gnaw away at the protocols described in the literature and found fault with essentially all of them. The failure to bind protocol elements was one frequent problem; another was that old messages could be replayed. In the case of the original Needham-Schroeder protocol, for example, the freshness of the key generated by the server was guaranteed to only one of the principals. This was not necessarily an attack, as its inventors only claimed to protect honest insiders from dishonest outsiders. However, it led to a debate about the assumptions underlying security protocol design. Do we protect only against outsiders, or against insiders? Against the malicious, or the merely careless? For example, if we use timestamps to guarantee protocol freshness, are we vulnerable to principals who carelessly let their clocks run slow? Do we only consider an attacker to have won if he can impersonate an authorised principal, or do we need to stop people abusing the protocol mechanisms to perform a service denial attack?
The early attacks led to a second seminal paper, which Roger wrote with Mike Burrows and Martin Abadi in 1989 [2], and which introduced a logic of authentication. This enables an analyst to formalise the assumptions and goals of a security protocol, and to attempt to prove its correctness. When a proof cannot be found, the place at which one gets stuck often shows where an attack can be mounted. This style of analysis turned out to be very powerful, and a large literature quickly developed in which the 'BAN Logic' and other formal tools were developed and extended to tackle a range of problems in protocol design.
One of the remarkable things about the study of security protocols is that they have not become a solved problem. One might think that managing the objects associated with authenticating users over a network -- passwords, keys and the like -- was a fairly compact problem which would have been done to death within a few years. However, the more we dig, the more we find.
Since 1992, Roger has hosted a protocols workshop every Easter. Early events dwelled on matters of authentication and logic, but by the mid-90s, the growing interest in electronic commerce was yielding papers on mechanisms for micropayments, bets, streaming media, mobile communications and electronic voting. Later years brought work on PKI, trust management and copyright enforcement. More and more problems come along as more and more businesses reinvent themselves online; threat models have also become more realistic, with dishonest insiders displacing the mythical 'evil hacker on the Internet'.
Dishonest insiders, and the composition problem
Over the last two years, we have been exploring exactly how one might re-engineer cryptography to cope with dishonest insiders. One conclusion is that the analysis of security protocols must be extended to application programming interfaces. This is because the crypto keys used in authentication and payment protocols are often kept in separate hardware security processors, or at least in cryptographic libraries, to which access can be restricted using physical or logical mechanisms. However, an interface has to be exposed to the application program, which will occasionally be suborned -- whether by a corrupt insider, or by malware. How much harm can be done, and how can we limit it?
Protecting protocols was hard enough, and yet the typical protocol consists of 3-5 messages exposed to manipulation. The API of a modern crypto library or hardware cryptoprocessor may contain 30-500 callable functions, many with a range of options. This provides a very rich and complex environment for mischief.
Attacks often involve using two separate mechanisms provided by the cryptoprocessor for different purposes, each of which could be innocuous by itself but which combine to cause trouble. For example, it is common to compute a customer PIN by encrypting the account number with a 'PIN derivation key': the cryptoprocessor then returns the PIN encrypted with a PIN storage key, so that the application has no access to its clear value. So far, so good. Then there is another transaction that can be used to encrypt a communications key under the terminal key loaded in an ATM. Here things start to go wrong, as the cryptoprocessor does not distinguish between a terminal key and a PIN derivation key; it considers them both to be of the same type. The upshot is that an attacker can supply the device with an account number, claiming that it is a communications key, and ask for it to be encrypted under the PIN derivation key.
Attacks like this extend protocol analysis all the way to the composition problem -- the problem that connecting two systems that are secure in isolation can give a composite system that leaks. This had previously been seen as a separate issue, tackled with different conceptual tools.
Differential protocol analysis
We are now working on the second generation of API attacks, which exploit the application syntax supported by the cryptographic service. These attacks are even more powerful, and at least as interesting from the scientific point of view. PIN generation provides a neat example here too. In more detail, the standard PIN computation involves writing the result of the encryption as a hex string and decimalising it. As some banks like to let customers change their PIN to a more memorable number, there is a provision to add an offset to give the PIN that the customer actually enters:
Account number: 8807 0123 4569 1715
PIN derivation key: FEFE FEFE FEFE FEFE
Encrypted account number: A2CE 126C 69AE C82D
Natural (decimalised) PIN: 0224
Offset: 6565
Customer PIN: 6789
The typical implementation requires the programmer to send the cryptoprocessor the account number, a table describing the decimalisation (here, '0123 4567 8901 2345') and the offset. The processor returns the PIN, encrypted under the PIN storage key. The designers do not seem to have realised that a crooked programmer can manipulate the decimalisation table and the offset as well as the account number. A multitude of attacks follow. For example, one can send in an account number with a decimalisation table of '1111...11' to find out the ciphertext corresponding to a clear PIN of '1111,' and then with a decimalisation table of '0111...11' to see if there is a zero in the first four digits of the encrypted account number (if so, the PIN, and thus the ciphertext output, will be different). By manipulating the decimalisation table further, he can get all the digits in the PIN, and by then playing with the offset he can get their order. In total, the attack requires only 15-25 unprivileged cryptoprocessor transactions to discover the PIN on a single target account.
This second type of attack takes protocol analysis into yet another realm: that of differential attacks. Over the last ten years, a number of techniques have been invented for attacking cryptographic systems by bombarding them with inputs with chosen differences.
For example, in differential cryptanalysis, one analyses the changes in the output of the encryption algorithm; while with differential power analysis, one measures changes in the current consumption or electromagnetic emissions of the equipment. Now we have examples of how consecutive runs of a protocol can leak information if the inputs are suitably chosen. The resulting 'differential protocol analysis' appears to be very powerful against application-level crypto.
It will take us some time to figure out the general lessons to be drawn from attacks like this, the robustness principles that designers should use to avoid them, and the analysis techniques that might assure us of a particular design's soundness. The randomisation of all protocols (another feature of Roger's work) is likely to be important.
Quantitative analysis and multiparty computation
Various researchers have speculated about whether there might one day be a quantitative analysis of protocol security. This might be feasible for PIN processing applications as we can measure the information leakage per transaction in terms of the reduction of entropy in the unknown PIN. This leads in turn to a possible real-world application of an attack previously considered theoretical.
Gus Simmons wrote extensively on covert channels in protocols. One such channel that is always present is the 'balking channel' -- when one of the principals in a protocol signals something by halting and refusing to continue. This is normally considered unimportant as its information capacity is only a third of a bit per transaction. But with systems designed to cope with large transaction volumes, this need no longer hold. For example, a Trojanned cryptoprocessor could balk when it sees a predetermined PIN. If the PIN length were eight digits, this would be unlikely to hinder normal operation, but at a thousand transactions a second, a programmer could quickly find a number in a typical nine-digit account number range with just this PIN, and open an account for it. Once this kind of problem is appreciated, one can start to look for attacks that involve inducing rare error conditions that cause the cryptoprocessor to abort a transaction. (They exist.)
A third emerging link is between protocol analysis and secure multiparty computation. In application-level crypto we may have several inputs to a computation, some of them coming from an untrusted source, and we have to stop users manipulating the computation to get outputs useful for bad purposes. In the PIN decimalisation example above, one might try to solve the problem by blocking tables such as 1111...11. Yet an attacker can get by with scarcely more work by using two normal-looking tables that differ slightly (another kind of differential attack). We might therefore think that if we can't sanitize the inputs to the computation, perhaps we can authenticate them, and use only those tables that real banks actually use. But building every bank in the world into our trust base is what we were trying to avoid by using cryptography!
Conclusion
The protocol work that started off a quarter of a century ago may have seemed at the time like a minor detail within the larger project of designing robust distributed systems. Yet it has already grown into the main unifying theme of security engineering. Application-level protocols, and especially those from which an attacker can harvest data over many runs, open up new problems. The resulting analysis techniques are set to invade the world of composable security, and the world of multiparty computation. The influence, and the consequences, of Roger's contribution just keep on growing.
References
1. NEEDHAM, R.M. AND SCHROEDER, R.M., 'Using encryption for authentication in large networks of computers.' Comm. ACM, vol. 21, no. 12, pp. 993-999, 1978.
2. BURROWS, M. ABADI, M. AND NEEDHAM, R.M., 'A logic of authentication,' ACM Transactions on Computer Systems, vol. 8, no. 1, pp. 18-36, 1990.
Ferseeun inffurmeshun
n eezeshun
e d veendoosm erks
o ments und Setteengs\JLungffeeeld\Eppleeceshun Deta\Oopera\Oopere7\pruffeele-a\ceche4
s
Ferseeun
7.02
Booeeld
2658 Bork ideeshun
Pletffurm
Veen32
System
Veendoos XP
Jefa
Soon Jefa Roonteeme-a Infurunment ferseeun 1.4
Regeestreshun inffurmeshun
Regeestered
Nu
Neme-a
N/A
Oorgu
N/A
Peths
Prefferences
C:\Ducooments und Setteengs\JLungffeeeld\Eppleeceshun Deta\Oopera\Oopere7\pruffeele-a\oopere6.inee
Sef
C:\Ducooments und Setteengs\JLungffeeeld\Eppleeceshun Deta\Oopera\Oopere7\pruffeele-a\oopera.veen
Buuk
C:\Ducooments und Setteengs\JLungffeeeld\Eppleeceshun Deta\Oopera\Oopere7\pruffeele-a\oopere6.edr
Oopera durectury
C:\Ducooments und Setteengs\JLungffeeeld\Eppleeceshun Deta\Oopera\Oopere7\pruffeele-a
Ceche-a
C:\Duco
Meeel durectury
C:\Ducooments und Setteengs\JLungffeeeld\Eppleeceshun Deta\Oopera\Oopere7\Meeel
Help ducooments
C:\Prugrem Feeles\Oopere7\Help
Ploog-in pet
C:\Prugrem Feeles\Oopere7\Ploogeens
C:\Prugrem Feeles\Oopere7\Prugrem\Ploogeens
C:\Prugrem Feeles\Netscepe-a\Cummooneecetur\Prugrem\Ploogeen
Thurd perteees
Thees prudooct incloodes sufftvere-a defeluped by zee OopenSSL Pruject fur use-a in zee OopenSSL Tuulkeet. Cupyreeght © 1998-2001 Zee OopenSSL Pruject. Ell reeghts reserfed. Bork Bork Bork!
Thees prudooct incloodes cryptugrepheec sufftvere-a vreettee by Ireec Yuoong. Cupyreeght © 1995-1998 Ireec Yuoong
Zee Independent JPEG Gruoop
Zee PNG Defelupment Gruoop, Glenn Runders-Pehrsun, Undrees Deelger, Gooy Ireec Schelnet und Gruoop 42, Inc. Bork Bork Bork!
Jeun-luoop Geeelly und Merk Edler
Jemes Clerk
Iberherd Mettes
Noomber-tu-streeng und streeng-tu-noomber cunferseeuns ere-a cufered by zee fullooeeng nuteece-a:
Zee oothur ooff thees sufftvere-a is Defeed M. Gey. Bork Bork Bork!
Cupyreeght (c) 1991, 2000, 2001 by Loocent Technulugeees. Bork Bork Bork!
Permeessiun tu use-a, cupy, mudeeffy, und deestriboote-a thees sufftvere-a fur uny poorpuse-a veethuoot fee-a is hereby grunted, prufeeded thet thees inture-a nuteece-a is inclooded in ell cupeees ooff uny sufftvere-a vheech is oor incloodes a cupy oor mudeefficeshun ooff thees sufftvere-a und in ell cupeees ooff zee sooppurteeng ducoomenteshun fur sooch sufftvere-a. Bork Bork Bork!
THIS SOFTVERE IS BEING PROFIDED "ES IS", VITHOOoT ENY IXPRESS OoR IMPLIED VERRENTY. IN PERTICOoLER, NEITHER THE EOoTHOR NOR LOoCENT MEKES ENY REPRESENTETION OoR VERRENTY OoF ENY KIND CONCERNING THE MERCHENTEBILITY OoF THIS SOFTVERE OoR ITS FITNESS FOR ENY PERTICOoLER POoRPOSE. Bork Bork Bork!
Zee Ilektruns
Undreey Ruzelook
Neece-a Grepheecs(TM) by Pål Syfertsee, Flutt Eltså
Oopera Sufftvere-a is greteffool tu zee gruoops und indeefidooels ebufe-a fur zeeur cuntreebooshuns. Bork Bork Bork!
Cupyreeght © 1995-2003 Oopera Sufftvere-a ESA. Ell reeghts reserfed. Bork Bork Bork!
Three sites I regularly visit still don't play well with safari;
my dating site
my mail reporting site
my domian registration site
sounds like an easy way to discriminate with your permission. call the aclu and a lawyer- this should not be allowed!
Yes their sending these out to businesses in IL and saying that there's a 45 day grace period that will end on feb 28th.
They are sending these letters to all registered businesses in the state and I think they got the addresses and contact info from the state. The reason I think this is becuase I have a home based business and have always used a po box for all business mail- the state is one basically the place that would have had my home address related to my business because they require a physical address for sales tax licensing.
About a week after receiving the bsa letter I got a very similar letter from microsoft mentioning the grace period and letting me know that if I need additional licenses I could get them for up to 20% off- then the fine print says that microsoft can't guarantee you any discount because you'll have to buy the additional licenses from one of their authorized resellers and that the resellers regulate the discounts they decide to give- so you may not really get one.
this has really pissed me off- I immediately killed my last windoze box and put redhat on it- I had just bought my first mac a few months before and it's great- I'm shooting for a dual powermac in the next six months. because I'm in a home based business that doesn't operate normal business hours they would basically have to have a search warrant to look at my computers. I dare them! I spoke to a few people about this and from what i've heard a search warrant cannot be issued to a private company for something like this. I'm so mad!!!
It's about fscking time people using pc's at least started catching up with the apples are used-
I work for a university and one of the grant projects I support recently bought about 40 ibooks with burners for students. One of the teachers in charge has us order $1700 worth of floppy drives with the reason being that it was the format they use to hand out and receive homework.
cd's are so much cheaper, faster and more reliable that it's amazing it's not the standard for educators yet- teachers are behind the learning curve. And this is supposed to be a technology related grant program to boot! It was very frustrating to have to deal with a such a poor and wasteful decision.
another one:
What's a stripper do to her asshole before she goes to work?
She drops him off at band practice.
There's a great art show in chicago right now that displaying a large quantity of audio, visual and standard art mediums that challenge copywrite as we know it. Many of the peices have been sued into submission until now. More info here and here
I went to the show's opening last night and I would highly recommend it, some of the bands will be playing live on feb 7th and 8th with an intense panel debate about copywrite with speakers like Lawrence Lessig and dj spooky on the 15th. The show will then be moving onto San Francisco.
'monopoly money'?
This is where your email spam account comes into play.
Actually you don't even need to use your spam account for the realplayer setup- it doesn't authenticate the address for you to use the player.
Mine currently set for 'biteme@real.com'
bad link. hold down shift and click here
I tested it first!!!
There seem to be a lot of complaints on the minimal speed boost for the iBook -> 12" PowerBook jump in cost.
minimal if you compare 800mhz to 867mhz, but also that it's an upgrade from a G3 to G4. Also adds 802.11G and bluetooth capabilities. It's also smaller in all deminsions including weight and has a slot drive and comes with the combo drive by default- the ibook doesn't.
Anyone actually look at the difference in the RAM the two products use? This is probably where the cost difference comes from, not the materials its made of. iBooks seem to use 100 MHz SDRAM, 12" PowerBook uses 266MHz DDR and the 17" uses 333MHz DDR. This should have a pretty big performance boost, at least as much as the processor boost, probably a whole lot more. Apple never seem cutting edge on memory tech but at least they're now giving you something respectable with the high end powerbook. That was actually one of the things that kept me away from Mac before (not a gamer, all my critical software was availible on both). That and the still high price. The 15" PowerBook is still using SDRAM though.
I think Apples are well worth the cost. I just bought an ibook a few weeks ago and I love it. I maxed everything out other than the screen because I wanted the small size... I should have waited. for a laptop the prices are still very competitive- you can't brew your own for less.
wow, they have other hacks too!
check out the Battlezone hack- it's such a vast improvement!!
will my silly putty still work the same way on the technical drawings in my cs books?
it was probably a 4 mb chip for my old apple
that's the earliest I can remember, oh wait...
why not link directly to their site?
Shhhhhhhhhhhh, unlike North Korea you're supposed to keep it a secret!!!!
I print this every day for my boss and find it easier to just look at them rather than try to use the search function on their page. You can find the listings here. of course next week you'll just change the 2 in the url to a 3. we are usually searching for grant opportunities- this looks pretty interesting, I think I'll have to start looking for similar items.
NO, I was considering that I should have mentioned that in the first place after my original post. I suppose sex with yourself, or a non-living object would be more like 'vaporware' and still does not prevent one from being a virgin. although virginity was not my original thought either, many have commented that all geeks are not necessarily virgins anymore. But c'mon, anyone can get laid once!
before you mod me down, please note that I'm half drunk on a sunday afternoon and just got home from my girlfriend's place where we didn't have sex!!!
What do others really wish could have happened by Xmas?
/. and all, I was thinking sex would be the #1 answer and might say I'm surprised it's not here.
this being
I mean they listed Viagra on there. VIAGRA?
I would call that a paid endosement/advertisement. I'm sure it's not the only one on the list.
Susan Kevorkian, an analyst with research firm IDC
I hear she can get you a KILLER deal on one of these!
For example gun manufacturors do not face such action for providing people with items that could be used in a crime.
This is not true, see: Chicago, New York, Los Angeles County, Newark, NJ, Cincinnati, others.
Pocket protector? Check.