On 25 August 2000, the press release distribution service Internet Wire received a forged e-mail that appeared to come from Emulex Corp. and said that the CEO had resigned and the company's earnings would be restated. Internet Wire posted the press release, not bothering to verify either its origin or contents. Several financial news services and Web sites further distributed the false information, and the stock dropped 61% (from $113 to $43) before the hoax was exposed.

This is a devastating network attack. Despite its amateurish execution (the perpetrator, trying to make money on the stock movements, was caught in less than 24 hours), $2.54 billion in market capitalization disappeared, only to reappear hours later. With better planning, a similar attack could do more damage and be more difficult to detect. It's an illustration of what I see as the third wave of network attacks -- which will be much more serious and harder to defend against than the first two waves.

The first wave of attacks was physical: attacks against the computers, wires, and electronics. These were the first kinds of attacks the Internet defended itself against. Distributed protocols reduce the dependency on any one computer. Redundancy removes single points of failure. We've seen many cases where physical outages -- power, data, or otherwise -- have caused problems, but largely these are problems we know how to solve.

Over the past several decades, computer security has focused around syntactic attacks: attacks against the operating logic of computers and networks. This second wave of attacks targets vulnerabilities in software products, problems with cryptographic algorithms and protocols, and denial-of-service vulnerabilities -- pretty much every security alert from the past decade.

It would be a lie to say that we know how to protect ourselves against these kinds of attacks, but I hope that detection and response processes will give us some measure of security in the coming years. At least we know what the problem is.

The third wave of network attacks is semantic attacks: attacks that target the way we, as humans, assign meaning to content. In our society, people tend to believe what they read. How often have you needed the answer to a question and searched for it on the Web? How often have you taken the time to corroborate the veracity of that information, by examining the credentials of the site, finding alternate opinions, and so on? Even if you did, how often do you think writers make things up, blindly accept "facts" from other writers, or make mistakes in translation? On the political scene we've seen many examples of false information being reported, getting amplified by other reporters, and eventually being believed as true. Someone with malicious intent can do the same thing.

In the book _How to Play With Your Food_, Penn and Teller included a fake recipe for "Swedish Lemon Angels," with ingredients such as five teaspoons of baking soda and a cup of fresh lemon juice, designed to erupt all over the kitchen. They spent considerable time explaining how you should leave their book open to the one fake page, or photocopy it and sneak it into friends' kitchens. It's much easier to put it up on www.cookinclub.com and wait for search engines to index it.

People are already taking advantage of others' naivete. Many old scams have been adapted to e-mail and the Web. Unscrupulous stockbrokers use the Internet to fuel their "pump and dump" strategies. On 6 September, the Securities and Exchange Commission charged 33 companies and individuals with Internet semantic attacks (they called it fraud) such as posting false information on message boards.

It's not only posting false information; changing old information can also have serious consequences. I don't know of any instance of someone breaking into a newspaper's article database and rewriting history, but I don't know of any newspaper that checks, either.

Against computers, semantic attacks become even more serious. Computer processes are much more rigid in the type of input they accept; generally this input is much less than a human making the same decision would get. Falsifying input into a computer process can be much more devastating, simply because the computer cannot demand all the corroborating input that people have instinctively come to rely on. Indeed, computers are often incapable of deciding what the "corroborating input" would be, or how to go about using it in any meaningful way. Despite what you see in movies, real-world software is incredibly primitive when it comes to what we call "simple common sense." For example, consider how incredibly stupid most Web filtering software is at deriving meaning from human-targeted content.

Can airplanes be delayed, or rerouted, by feeding bad information into the air traffic control system? Can process control computers be fooled by falsifying inputs? What happens when smart cars steer themselves on smart highways? It used to be that you had to actually buy piles of books to fake your way onto the New York Times best-seller list; it's a lot easier to just change a few numbers in booksellers' databases. What about a successful semantic attack against the NASDAQ or Dow Jones databases? The people who lost the most in the Emulex hoax were the ones with preprogrammed sell orders.

None of these attacks is new; people have long been the victims of bad statistics, urban legends, and hoaxes. Any communications medium can be used to exploit credulity and stupidity, and people have been doing that for eons. Computer networks make it easier to start attacks and speed their dissemination, or for one anonymous individual to reach vast numbers of people at virtually no cost.

In the near future, I predict that semantic attacks will be more serious than physical or even syntactic attacks. It's not enough to dismiss them with the cryptographic magic wands of "digital signatures," "authentication," or "integrity." Semantic attacks directly target the human/computer interface, the most insecure interface on the Internet. Only amateurs attack machines; professionals target people. And any solutions will have to target the people problem, not the math problem.

Good article of how government officials at all levels routinely and knowingly commit security violations with laptops and sensitive data. Most troubling quote: "Even when officials are cited for security infractions, they rarely are subjected to punishment. Infractions do go in personnel records. But, unless there is a clear pattern of repeated violations, they generally are ignored, security officials said."
<http://www.latimes.com/business/cutting/20001003/...>

The Council of Europe has released a new draft of their cybercrime treaty. Some highlights:

Two new sections on interception of communications have been included. All service providers must either technically conduct surveillance on demand, or technically assist law enforcement (i.e. Carnivore).

The section outlawing security tools remains unchanged, except for a footnote that says that an explanatory report will take care of the problem of legitimate users.

The section that seems to require releasing crypto keys remains unchanged. A new section proposes that people be forced to process the information for the police, and an amusing footnote describes how this will be better for privacy.

The intellectual property section has been slightly modified, but appears to still be so broad that it will require criminal penalties for putting anything on the net that would violate copyrights.

According to HSBC's terms and conditions for its banking service: "You must not access the Internet Banking Service from any computer connected to a local area network (LAN) or any public internet access device or access point without first making sure that no-one else will be able to observe or copy your access or get access to the Internet Banking Service pretending to be you."

Even worse, the same document states that the customer will be liable for any losses that are the result of gross negligence. And gross negligence is defined as non-compliance with the terms and conditions. So HSBC is now free to penalize the customer if they screw up security.

For a while I've made the case that the person who should be concerned about computer and network security is the person who holds the liability for problems. Credit cards are a good example; the limits on customer liability put the onus on the banks and credit card companies to clean up security. Here we see a bank deliberately trying to pass the liability off for its own security lapses onto its customers.

Pretty sneaky.

Based on this negative publicity, HSBC will "review the wording of its terms and conditions." It's a first step.

"A lot of you are making security products that are an attractive nuisance.... Shame on you. [...] I want you to grow up. I want functions and assurances in security devices. We do not beta test on customers. If my product fails, someone might die." --Brian Snow, INFOSEC Technical Director at the National Security Agency, speaking to commercial security product vendors and users at the Black Hat Briefings security conference.

I find this quote (and Snow's entire talk) fascinating, because it speaks directly to the different worlds inside and outside the NSA. Snow is campaigning for increased assurance in software products: assurance that the products work as advertised, and assurance that they don't do anything that is not advertised. Inside the NSA, assurance is everything. As Snow says, people die if security fails. Millions of dollars can be spent on assurance, because it's that serious.

Outside the NSA, assurance is worth very little. The market rewards better capabilities, new features, and faster performance. The market does not reward reliability, bug fixes, or regression testing. The market has its attention firmly fixed on the next big idea, not on making the last big idea more reliable.

Certainly, assurance is important to security. I argued as much in _Secrets and Lies_. I also argued that assurance is not something we're likely to see anytime soon, and that the smart thing to do is to recognize that fact and move on.

In the real world, there's little assurance. When you buy a lock for your front door, you're not given any assurances about how well it functions or how secure your house will be as a result. When a city builds a prison, there are no assurances that it will reduce crime. Safety is easier than security -- there is some assurance that buildings won't collapse, fire doors will work, and restaurant food will be disease-free -- but it's nowhere near perfect.

Business security is all about risk management. Visa knows that there is no assurance against credit card fraud, and designs their fee structures so that the risks are manageable. Retailers know that there are no assurances against shoplifting, and set their prices to account for "shrinkage." Computer and network security is no different: Implement preventive countermeasures to make attacks harder, implement detection and response countermeasures to reduce risk, and buy enough business insurance to make the rest of the problem go away. And build your business model accordingly.

Those are tools that the military cannot take advantage of. The military can't buy insurance to protect itself if security fails. The military can't revise its "business model"; it's not a business. If military security doesn't work, secrets might be exposed, foreign policy might fail, and people might die.

Assurance is a great idea, and I'm sure the military needs more of it. But they are as likely to get it out of the commercial sector as they are likely to find EMP-hardened, TEMPEST-shielded, and MIL-SPEC electronics down at the local Radio Shack.

Rijndael has been selected as AES. Well, NIST has proposed Rijndael for AES. There is a three-month public review, and then the Secretary of Commerce will sign a Federal Information Processing Standard (FIPS) formalizing the Advanced Encryption Standard. But the choice of algorithms has been narrowed to one: Rijndael.

Of course I am disappointed that Twofish didn't win. But I have nothing but good things to say about NIST and the AES process. Participating in AES is about the most fun a block-cipher cryptographer could possibly have, and the Twofish team certainly did have a lot of fun. We would do it all over again, given half the chance.

And given their resources, I think NIST did an outstanding job refereeing. They were honest, open, and fair. They had the very difficult job of balancing the pros and cons of the ciphers, and taking into account all the comments they received. They completed this job in an open way, and they stuck to the schedule they outlined back in 1996.

While some people may take issue with the decision NIST made -- the relative importance NIST gave to any particular criterion -- I don't think anyone can fault the process or the result. There was no one clear AES winner of the five semi-finalists; NIST took an impossible job and completed it fairly.

Rijndael was not my first choice, but it was one of the three algorithms I thought suitable for the standard. The Twofish team performed extensive cryptanalysis of Rijndael, and will continue to do so. While it was not the most secure choice (NIST said as much in their report), I do not believe there is any risk in using Rijndael to encrypt data.

There is a significant difference between an academic break of a cipher and a break that will allow someone to read encrypted traffic. (Imagine an attack against Rijndael that requires 2^100 steps. That is an academic break of the cipher, even though it is a completely useless result to anyone trying to read encrypted traffic.) I believe that within the next five years someone will discover an academic attack against Rijndael. I do not believe that anyone will ever discover an attack that will allow someone to read Rijndael traffic. So while I have serious academic reservations about Rijndael, I do not have any engineering reservations about Rijndael.

Nor do I have any reservations about NIST and their decision process. It was a pleasure working with them, and the entire Twofish team is pleases to have been part of the AES process. Congratulations Rijndael, congratulations NIST, and congratulations to us all.

The NSA's non-endorsement of AES was very carefully worded: "The National Security Agency (NSA) wishes to congratulate the National Institute of Standards and Technology on the successful selection of an Advanced Encryption Standard (AES). It should serve the nation well. In particular, NSA intends to use the AES where appropriate in meeting the national security information protection needs of the United States government."

The quote is attributed to Michael J. Jacobs, Deputy Director for Information Systems Security at the National Security Agency.

Note the last sentence. The NSA has not stated that it will use AES to protect classified information. The NSA has not stated that it will use AES widely. It has simply stated that, "where appropriate," it will use AES to meet its "national security information protection needs."

In the past, the NSA has, on occasion, used DES to protect what was known as "sensitive but unclassified" information -- personnel records, unclassified messages, etc. -- and we all know how secure DES is. My guess is that they will use AES to protect a similar level of information, in instances where buying commercial products that implement AES is a cheaper alternative to whatever custom alternatives there are.

It is possible that they will eventually use AES for classified information. This would be a good thing. But my guess is that many more years of internal cryptanalysis are required first.

Senate Judiciary Committee Chairman Orrin Hatch has released a consumer guide to online privacy tools. His stated hope is that consumers will demand adequate privacy from e-retailers and avoid legislated privacy regulation. Really, it's a piece of propaganda against government regulation of privacy, though nicely buzzword compliant with "anonymizers" and "infomediaries" among the technological superheros who can save the day.

Some observations:

a) Companies who post privacy policies online are not legally obligated to follow those policies, nor are they prohibited from changing them arbitrarily. That is, there are essentially no legal consequences for cheating (breaking the policy), probably not even "false advertising" claims. And that completely ignores companies who don't even post their policies.

b) Consumers cannot even begin to make "informed decisions" about sharing their personal data if they are unaware of all the ways that data can be aggregated, cross-correlated, and otherwise manipulated. The whole point of regulation is to protect customers from corporate manipulation.

c) The whole debate is built on the tacit premise that you don't own information about yourself, regardless of how that information was collected (including being collected under false pretenses). Contrast that to EU personal-data laws, which are based on a very different premise.

d) As long as there is a profit to be made, and no consequences for cheaters, industry self-regulation is a paper tiger. The "bad actors" will simply stay one jump ahead of the law and legal jurisdiction, and there are precious few federal laws that can be applied effectively, anyway.

e) In the document, government regulation is always characterized as either "ill-advised," "burdensome," "excessive," or "heavy-handed." Industry self-regulation is always characterized as "meaningful," "commend[able]," or "effective." Whatever happened to simple effective federal legislation? And while the current federal fair-trade and food-purity laws are far from simple, is anyone seriously advocating that they be totally rescinded? Reformed, yes, but not demolished.

By the way, as long as we're on the subject of unintentional privacy leaks... Examining the PDF file, we can learn:

1) The document's author is listed as "AlR" (lower-case L in the middle).
2) It was created with PageMaker 6.5. 3) The PDF file was made by PDFWriter 3.0.1 for Power Macintosh.

It probably wouldn't be all that hard to find out exactly who "AlR" is; how rare are phone directories for the Judiciary Committee and Orrin Hatch's staff?

This is a true account of what happened to me a couple of weeks ago. (Passwords have been changed and names have been deleted.) I have an "Internet banking" arrangement with a local bank. I recently wanted to add another account to their system, so I rang their help desk to do so, the conversation going along the following lines:

Me: "Hello. I want to make some changes to my Internet banking account."
Operator: "Yes sir. What is your account number?"

Me: "and the third one is ..."
Operator: "Yes, I know. It's 'swordfish'. Now, what changes do you want to make to your account?"

When you look at this behavior, you can see that the bank can hire security experts, encrypt their data), and all this comes to naught if the operators divulge the passwords over the phone. It makes you wonder how far I would have got if I had actually said "I can't remember the password -- can you give me a hint".

Clearly there are some design problems with their system, on top of the obvious training problems. The operator *should not* be presented with the passwords on his screen, thus he cannot divulge them even if he wanted to. Rather, he should have to type in the word(s) the customer supplies, with the computer merely saying "right" or "wrong" (and locking him out after 3 or so attempts).

The fact that he did so, so readily, suggests that every second customer has forgotten his password, and he was just trying to be helpful. This being the case, it makes you wonder whether expecting customers to remember lots of passwords is really the solution to improved security. The evidence suggest not.

See if this company announcement looks familiar: "We acknowledge that product X has a serious security flaw (which, for security reasons, we cannot describe in too much detail), but don't worry -- we have fixed it. Registered users click here to upgrade to the latest secure version..."

Call me a cynic, but this strikes me as a marvelous sales booster. Users are told there is a known security problem in their software, but have insufficient information to conduct a realistic risk assessment, to determine whether they are really exposed. Therefore they are compelled to upgrade or face unknown risks. Meanwhile the newsletters and security sites discuss the gravity of the flaw and describe (often theoretical) exploits and eventually the mass media catch on. At this point, we've reached the stage at which it no longer matters whether an individual user/system manager is actually at risk. He's now facing serious pressure from peers and management to upgrade and can't argue strongly that there's no need.

Even if the product upgrade in question is offered as a "free patch," one often needs to upgrade associated programs at cost (especially if, say, the insecure product is an operating system). There's no such thing as a free lunch!

Just one more cynical thought. Suppose that the latest version has ANOTHER security flaw that is mysteriously revealed in, say, 6 months time, re-starting the upgrade cycle. Now, without access to the original source and associated materials, who can say whether or not the flaw was intentionally inserted by the vendor?

You can see where I'm heading here. Users' fears about security may be being used deliberately by the vendors to drive up product sales, when the traditional means (facelifts, releasing new product features etc.) are becoming less effective due to the software market maturing.

Please feel free to forward CRYPTO-GRAM to colleagues and friends who will find it valuable. Permission is granted to reprint CRYPTO-GRAM, as long as it is reprinted in its entirety.

CRYPTO-GRAM is written by Bruce Schneier. Schneier is founder and CTO of Counterpane Internet Security Inc., the author of "Applied Cryptography," and an inventor of the Blowfish, Twofish, and Yarrow algorithms. He served on the board of the International Association for Cryptologic Research, EPIC, and VTW. He is a frequent writer and lecturer on computer security and cryptography.

Counterpane Internet Security, Inc. is a venture-funded company bringing innovative managed security solutions to the enterprise.