Slashdot Mirror

Wrong dude. Here is a link to the warrant, and other relevant info on what was actually found in his apartment. Things like bomb making materials. Link to Info

This is far from being about overthrowing the government.

This is about teaching how to make explosives with the intent be that those who learn how to use that knowledge against the government.

But the real kicker is that, according to the search warrant, Austin was flying under the radar until he defaced a couple web sites. Then an FBI investigator started looking into Austin and found his site raisethefist.com.

From that site Austin secured himself a second charge under 18 USC 842 (p)(2)(A) which makes it unlawful to provide information about explosives when the intent is that such knowledge be used to committ a crime.

Warning: IANAL.

First take a look at the search warrant issued against the home of Austin.

What we see here is that he's being suspected of breaking two specific laws.

18 USC 1030 - Computer Fraud

Austin is charged under this because he was suspected of being responsible for several defacements which are detailed in the warrant. Looking at what's in the warrant there seems to be more than enough evidence to support this charge.

18 USC 842(p)(2) - Unlawful Distribution of Information Relating to Explosives, etc...

In the search warrant are several quotes from raisethefist.com in which information about explosives is provided along side some comments that encourage this knowledge be used against police officers.

Here's the exact quote from 18 USC 842 (p)(2)(A):

to teach or demonstrate the making or use of an explosive, a destructive device, or a weapon of mass destruction, or to distribute by any means information pertaining to, in whole or in part, the manufacture or use of an explosive, destructive device, or weapon of mass destruction, with the intent that the teaching, demonstration, or information be used for, or in furtherance of, an activity that constitutes a Federal crime of violence;


Clearly what Austin did, provide information about explosives within the context of causing harm to others with said knowledge, falls under this law.

From the information that I have available it seems very apparent that Austin did commit crimes under current US law.

Now had Austin removed suggestions for use of this bomb making knowledge and just presented it in a separate, straight-forward format, he could not be charged under 18 USC 842.

However, he still defaced some sites and thus is still in violation of 18 USC 1030.

Remember, IANAL, but this seems pretty straightforward to me. No freedom of speech issue here.

Have a look at this site they say, much about Mach 3 razorz and RFID,

they claim "Gillette shelf photographs unsuspecting shoppers!" and they have some pdf files here, and here to prove that Auto-ID Center is invading your privacy. There is also a (mirror) Video here which is currently on auto-id website here.

Have a look at this site they say, much about Mach 3 razorz and RFID,

they claim "Gillette shelf photographs unsuspecting shoppers!" and they have some pdf files here, and here to prove that Auto-ID Center is invading your privacy. There is also a (mirror) Video here which is currently on auto-id website here.

The Axed Docs are on Cryptome.

It is called Assasination Politics and was initially put forth by a fellow named Jim Bell. Fedgov didn't much like Mr. Bell after he started talking about this idea for obvious reasons. John Young's excellent site, Cryptome, has a lot of information about AP and exactly what happened to Jim Bell.

Read the above links for more info.

A full subpoena may be examined courtesy of Cryptome:


http://cryptome.org/riaa-hit.htm

Or, for the lazy:

This is one of several hundred similar subpoenas issued by RIAA recently under the DMCA. Most have been filed in US District Court in the District of Columbia.
US District Court in the District of Columbia

1:03-mc-00273-UNA

Unassigned, presiding

Date filed: 07/02/2003 Date of last filing: 07/02/2003
Entered 07/17/03
LAW OFFICES
MITCHELL SILBERBERG & KNUPP LLP
A PARTNERSHIP INCLUDING PROFESSIONAL CORPORATIONS
TRIDENT CENTER
11377 WEST OLYMPIC BOULEVARD
LOS ANGELES, CALIFORNIA 90064-1683
(310) 312-2000
FAX: (310) 312-3100
June 30, 2003
Sir or Madam
Comcast Cable Communications, Inc.
3 Executive Campus
Cherry Hill. NJ 08002

Re: Notice of Copyright Infringement (17 U.S.C. 512(c)(3))

Dear Sir or Madam:

We are counsel to the Recording Industry Association of America, Inc. ("RIAA") and its member record companies. The RIAA is a trade association whose member companies create, manufacture, and/or distribute approximately ninety percent (90%) of all legitimate sound recordings sold and distributed in the United States. Under penalty of perjury, we submit that we are authorized to act on behalf of the R1AA and its member companies in matters involving the online infringement of their copyrighted sound recordings.

A user, customer, or subscriber of your system or network, identified by the IP address, date, and time on the attached document, is offering tbr download over the Internet files containing copyrighted sound recordings owned by RIAA member companies. The attached document also includes a representative list of the recordings the identified user is offering for download. We have a good faith belief that such activities are not authorized by the copyright owners, their agents, or the law, and assert that the intbrmation in this Notice of Copyright Infringement is accurate, based on the data available to us.

Thank you for your prompt attention to this matter. Should you have any questions, please contact me at (310) 312-3297 or at dmca@msk.com.

[Signature]

Yvette Molinaro
for
MITCHELL SILBERBERG & KNUPP LLP

24.61.155.10 on 6/26/2003 at 11:49:00 p.m.(EDT)

The user at the above-identified IP address, using the screen name Tyler@KaZaA, has offered for download through the online media distribution system known as KaZaA copyrighted sound recordings owned by RIAA member record companies, including the following representative recordings:

Michelle Branch - All You Wanted
Avril Lavigne - Complicated
Radiohead - Just
Incubus - Nice to Know You
Busta Rhymes - Pass the Courvoisier
Sheryl Crow - Soak Up The Sun
Incubus - Stellar
Guns N Roses - Sweet Child O' Mine
A PERFECT CIRCLE - Three Libras ...etc

Whining about this is almost as bad as the tool that got kicked off a British Airways flight for wearing a button that said "Suspected Terrorist."

John Gilmore has done more for personal freedoms and liberties on the net than anyone you know. He founded or helped found the EFF, the "alt" newsgroups, the Cypherpunks, and Cygnus Support, the first company that showed that you could make money supporting open source software. Cygnus was later bought by Red Hat for umpteen millions of dollars, but Gilmore was already rich, having been one of the first employees at Sun Microsystems.

He has steadily plowed his money back into causes designed to promote freedom online and in the physical world. He has funded the FreeS/Wan project designed to provide automatic link-based encryption. He's also funded efforts to add security to the DNS. He provided the money for the machine that proved once and for all that DES was insecure. He is presently suing the government over travel restrictions.

As for the button incident, his point is that we are all being treated as suspected terrorists under the current regulations. As long as people put up with that without a protest, nothing is going to change. We should all be grateful that someone with Gilmore's credentials and financial strength is doing something about the increasingly harsh restrictions that all of us face as the government cracks down.

http://cryptome.org/rfid-spy.htm

That would imply they actually stopped at some point. Echelon is complete fact, not a tinfoil-hat wearers wet dream. They are routinely monitoring your calls, emails and faxes. This offical EU report details a lot about the system.

There's been a lot of talk here about RFIDs lately. Mostly (justifiably) negative talk. However, this is okay, for now, right? Does anyone here have a problem with the use of RFIDs in the warehouses (assuming they don't trickle down to the consumers)?

I do see the privacy problems with RFIDs, but I'm not really worried about it... yet. I don't care if they use RFIDs in their warehouses/stores, as long as any items I buy do not have an active RFID when I leave (not that I shop at, or have ever even seen, a Walmart). RFIDs do have legitimate (anti-theft) uses. They have a use for inventory tracking/control. They could be used in corporate offices to keep track of various items (laptops/desktops [maybe], other electronics, books, etc).

RFIDs also have other uses, outside the traditional business realm, such as in ecology and field biology. They can be used (theoretically) in some tasks in meteorology.

Yes, they have "immoral" uses, but so does P2P software. It should still be legal to manufacture and use RFIDs, just like it should be legal to write and use P2P code. Don't sound like a paranoid kook, be rational about all of this. Write to your local representative what's bad about RFIDs, and what sort of legislation would help curb the privacy invasion that will inevitably come along with widespread use. Better yet, try getting an appointment with any of your local representatives to discuss it in person (not too likely, but it can happen). Now is the time to get this taken care of, because it will soon be too late. Once something gets in motion, it's much much harder to legislate it out (again, this is similar to P2P).

Note: I didn't read the article.

ummm.

http://cryptome.org
and
http://cartome.org

Damn, I've just Slashdotted Cryptome... :(

The article conspicuously lacks any link to the website of John Young, although it references it in the article. So the two that I found are here and here.

It's cryptome.

http://cryptome.org

I think they are talking about the Eyeball series at http://www.cryptome.org

It seems to be down right now...but is on my daily reading list.

cryptome.org is a good site as well. It isn't the easiest site to get around, but its comprehensive. Maybe there can be a marriage of the two. It would be beautiful.

...which is....which is...which is.

Oh hell, I forget what I was going to say. Damn viagra!

BTW, Palladium is neither a technology nor an application. It is an initiative encompassing a suite of applications and hardware specifically designed to provide localized content control and administration according to industry choice and desire.

You need some sleep, friend.

From the second "David Nelson" article:

Dennis Radke finds it ominous. "Given sufficient time, is it unreasonable to expect we Americans will be required to carry travel papers inside the U.S., just as residents of Nazi Germany and Stalin's Soviet Union" did?

As previously reported on Slashdot, the issue of requiring ID when traveling within the US has already been challenged as unconstitutional. EFF co-founder John Gilmore sued the government and two airlines for not letting him board aircraft without ID.

See his site for history and court documents.

If you do, you already have this sort of thing. Sure, you need to hold the card 6 inches from the panel for it to open the door, however it can register the presence of a card over a much longer distance. So, that ID badge you already carry could be doing just this sort of thing. It all depends on how the system was configured.

But, this isn't all that new anyway. Mobile phones have been able to do similar things for quite some time. Take this high profile rape case in the UK, where a couple were cleared of criminal charges using mobile phone location evidence.

Hell, while we are talking about the complete loss of privacy in todays society, I might as well throw in this link to an official European Union report into the routine monitoring of the internet and telephone networks by Echelon.

This new thing isn't anything to fear. You should be scared already.

One of the fascinating articles that John Young linked to in his invaluable Cryptome a few years ago was a PDF of some new portable missles -- sadly, I've lost the original file.

In this there was a tube-launched missle that worked much like a water rocket. The front half of the missle was the warhead, and the back half was filled with a relatively (compared to water) high-density gel. At the front of the gel section, in about the middle of the missle, was a small explosive.

On launch, the explosive would fire, generating gas that would propel the gel out of a nozzle in the back of the rocket at high velocity. The final speed of the missle was on the order of 300 knots -- quite slow for a rocket.

The big upside of this, though, was that it could be fired indoors stealthily. There would be no huge cloud of smoke at the launch point -- there would be very little indication where the rocket had come from except for a large mess of jelly on a wall.

Pretty wild.

thad

Exactly. They can still target someone who deserves it. However, they can't scan most e-mails, like they are right now.

You might want to check out this site which debunks the myth that polygraphs work. And yes, I'll bet most people probably give up their passwords themselves. For instance, Jim Bell, the guy behind Assination Politcs, a guy who should know better, gave up his PGP passphrase as part of his plea bargin. He is now suing the state of Washington and a host of others for the costs of breaking the encryption, brute-force using 1997 hardware.

Some links: One Two

Some links: One Two

That was a most enlightening court case. The official decision can be found at the wonderful Cryptome.

Don't worry. It opens in Open Office Impress just fine!

Yeah, what's next, putting a former government official convicted of violating the Constitution in charge of spying on US citizens?

Come on. Do you really think that MS wouldn't be using this in their OS and apps as well? Intel and AMD have already pledged their support for Palladium. You can also read up on the ins and outs of palladium here. When you do read it, pay attention to the section that reads:

Tells you who you?re dealing with?and what they?re doing. Palladium is all about deciding what?s trustworthy. It not only lets your computer know that you?re you , but also can limit what arrives (and runs on) your computer, verifying where it comes from and who created it.

Sorry about the '?'s, my HTML is still in early days. But as you can see, if AMD and Intel incorporate palladium into their chips, then the entire computer system will be at the mercy of he who wrote palladium. Now, fair enough it might not be turned on at first, but someone had an intersting comment that more and more software will require it to be turned on and I dare say MS would be one of the first. Not only for thier apps, but also to maybe kill off linux in one fell swoop. I don't think the average Joe will understand what palladium is or how to disable it

People should be able to freely choose which ID systems to sign up for. If they want an ID issued by a government agency, fine. If they want an ID issued by a private corporation or individual, fine. Others can decide whether or not to recognize the ID as valid and/or useful.

In regards to passports being from a neutral government body, there is no such thing. If the government has a problem with you they can deny you a passport. As an example take a look at the bottom of the list of requirements for a U.S. passport. You see that if you fail to provide your Social Security Number the IRS may impose a $500 penalty on you. Government issued and mandated passports are an infringement on your freedom to travel.

"Certain software products, often known as ``filtering software'' or ``blocking software,'' restrict users from visiting certain internet websites. [...] Critics charge that some filtering programs unfairly block sites that do not contain undesirable material and therefore should not be filtered. [...] Several commenters assert that manufacturers of filtering software encrypt the lists naming the targeted sites and that they are not made available to others, including the operators of the targeted sites themselves. R56. These commenters assert that they have no alternative but to decrypt the encrypted lists in order to learn what websites are included in those lists. [...] Such acts of decryption would appear to violate 1201(a)(1) if it took effect without an exemption for these activities. [...] The case has been made for an exemption for compilations consisting of lists of websites blocked by filtering software applications."

I read that question and I thought "WTF? Spammers to get privacy? No way!!".

The Internet is, before anything else, a system based on sharing and cooperation. Which is what makes it so interesting: people who know what they talk about post interesting information on all kind of subjects, and enrich a global discourse.

Linux/Open Source systems are the best example of this: they were made possible -- and became a force in the computing world -- through sharing and cooperatino. For instance NetBSD added "Net" to "BSD" to reflect its root in the cooperation made possible by the Internet.

On the other hand, spammers do nothing but abuse the resources of the system and inundate people with messages that are othing more than complete scams.

Abusing the cooperation and the good will of the global Internet, and using its resources in an unlawful way (it's a scam, remember?), is IMHO, enough to forfeit all the protections that should be enjoyed by all on the Internet.

Would you protect the privacy of a live-and-still-at-large criminal? I think not. Would you protect the "privacy" of a con artist, knowing full well that he may rip off another person behind your back? I think not.

Remember this: spammers are swindlers. Period. No privay for the wicked, says I.

Besides, sending thousands of email messages per day, on a network known for it lack of security and authentication is just asking for trouble... (Proof enough that they are stupid as well as dishonest!)

Also interesting: go to Cryptome, and read all about two scam artists of a different kind: these two do not spam, but they swindled the public by offering snake-oil security products. Very, very interesting and recommended reading...

This,

This,

This,

This,

This,

This

For the solution, wait for the Second American Revolution.

Cryptome is hosting more information on the whole rebuilding effort in Iraq. One such article is this one which is the text of a new york times article and two pdf's from USAID. Should be of interest to anyone who's following the whole Iraq war and is interested in the aftermath.

Cryptome is hosting more information on the whole rebuilding effort in Iraq. One such article is this one which is the text of a new york times article and two pdf's from USAID. Should be of interest to anyone who's following the whole Iraq war and is interested in the aftermath.

Cryptome is responding at the time of this post although Al-Jazeera is well and truely down (I'm not even getting the DNS lookup). Cryptome has pictures and links to the video here and the the video is up on various P2P networks.

While other people have posted links to various sites that are hosting images and the Al-jazeera news feeds and images, I decided to mirror the news feeds as an attempt to help move these feeds to people who are curious about the hype circling this situation, but unable to see it in the news.

I've rarely been moved like this situation moved me. After reading about these Al-jazeera clips showing dead American soldiers and captured American POWs, I wanted to actually see them to see if the hype matched the furvor. They aren't completely gruesome, but they definately show that this war won't be a week jaunt through the Middle East.

I don't mind having the news censored for security reasons, but when the rest of the world can view these clips, and Americans can't, my whole opinion of the situation changes.

Posted anonymously. Mod accordingly.

I'm having trouble getting to Cryptome tonight as well. Can anyone else see it?

Of course you have the education and of course you are in the position to tell me what happened in IRAQ and what not yes ?

Do you call this liberation ? Specially scroll down to the little kid who'se head is smashed and then the next one where the father is carrying away his kid.

You are a fucking faggot!

oGALAXYo

Not for her it's not.
Or her
Still believe in smart bombs, precision bombing etc.
Does he?

More links: Unknown news Dead guys Boycott

The vietnam war ended when enough people were sickened by pictures like these, so have a good look.

Not to sound, you know.. anti-Slashdot.. But has anyone ever produced any kind of PROOF that this is the case?

Not to sound, you know.. anti-Slashdot.. But has anyone ever produced any kind of PROOF that this is the case?

Read and be afraid. Be very afraid.

Yeah, but if someone hacked Cryptome?

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.

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

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.