Crypto-Gram Newsletter

July 15, 2001

by Bruce Schneier
Founder and CTO
Counterpane Internet Security, Inc.
schneier@schneier.com
<http://www.counterpane.com>

A free monthly newsletter providing summaries, analyses, insights, and commentaries on computer security and cryptography.

Back issues are available at <http://www.schneier.com/crypto-gram.html>. To subscribe or unsubscribe, see below.

Copyright (c) 2001 by Counterpane Internet Security, Inc.


In this issue:


Phone Hacking: The Next Generation

The phone network and the Internet are converging. That's good news for smart telephones, new telephony services, and customer convenience, and bad news for security. If you think that phone hacking is bad now, take a gander at what's coming.

During the last fifteen years or so, there has been a trend toward intelligent telephone networking. We've seen ISDN. We've seen SS7. We've seen IN (Intelligent Networking). These protocols are responsible for all the cool telephony features we've come to know and love: call forwarding, call following, local number portability, caller ID, etc. These features work fine, but are limited because they are all controlled by the phone company. If you want to initiate caller ID, you need to get the phone company involved. If you want your business calls forwarded to your home after 5:00 PM, you need to turn that on and off every day.

On the corporate side, we've seen Computer Telephony Integration (CTI), which didn't work very well because it was so big and clunky. It might be fine if you're a huge call center, but it just wasn't cost-effective for your average business. Development cycles were long, and service creation horrendously expensive; usage was rare.

But along came the Internet, and everything changed. The notion of intelligent endpoints (computers) and a dumb network (routers) turns the telephony model upside down. There are several consortiums and standards bodies working on bringing the Internet model to the telephone network, and allowing Internet-based control of telephone switching. The idea is to turn the telephone network into a giant networking resource that people outside the telephone network can control and manage. The benefit to the enterprise is more features and control: cost savings, better sales and marketing, improved customer service, etc.

The Parlay Group is a major player in this space. A consortium of software, hardware, and telephony companies, they are creating a specification and API to enable phone-system control from outside the secure telco network. This API will allow software to do such things as reroute calls, get notified of call attempts, retrieve the location of mobile users, and more. Even access to telco billing systems is planned. The idea is that computer applications can have integrated telephone components.

Even more fundamentally, all the switching protocols will interoperate at multiple points. Switches, gatekeepers, proxies, and call control agents will all be components of the new telephony control system. Control can be distributed or centralized, depending on the application.

Meanwhile, the IETF is defining the Session Initiation Protocol (SIP) for Voice over IP (VoIP) and more. This protocol will allow a user to define complicated ways to redirect calls: between 9 AM and 5 PM ring my office number, between 5 and 6 PM call my cell phone, after 6 PM call my home phone, and if my mother calls at any time, send her directly to voice mail. The protocol even includes a programming language, so a user can write a program to handle phone calls to match his own needs. While these features are nominally controlled by the user, the programs are stored in the telco network, and a DNS-like service is used to handle the profile and call forwarding. SIP is becoming a big thing; it's currently being used for VoIP telephony, will control calls in 3G wireless networks, and is being envisaged for all sorts of other uses like Instant Messaging.

The big idea here is to leverage the development techniques of the Web to services for telephony. New services are essential, because all the carriers have cut their collective throats on per-minute long-distance rates. Premium services are seen by many as the only source of meaningful revenue in the future. This means that telephony, which has heretofore been slow and methodical and reliable, will become as freewheeling as the Internet.

I am terrified at the security implications of these services. Sure, the Parlay spec says that communication between the Parlay client and Parlay server in the telco network is encrypted, and authentication will be enforced, but I don't believe for a minute that this will remain unhacked. SIP contains security provisions, but I don't trust them.

It's not the details of the protocols. It doesn't matter how many bits the key is, or what authentication protocol they employ: we've learned from experience that all systems like this are hackable. The worry is that these protocols open a huge hole into the telephone system. The problem is that these telephony control systems will sit on top of insecure operating systems. They will be hacked, and then things will get ugly.

Think about the possibilities for a minute. Denial-of-service attacks are a breeze: just reroute all calls to a person elsewhere. Or reroute all calls to a popular phone-sex service to another person. Or maybe just eavesdrop: set up a three-way conference bridge whenever someone receives a phone call. Remember the Trojan program that quietly made the modem dial Moldavia; this kind of system would make that hack a lot easier. And don't you think all of those hackers who chat on IRC would much rather take over a PBX and set up a conference call? You don't need me to think up the possibilities; there are lots and lots of them, none of them good.

One of the biggest backward steps is the re-merging of the control and voice channels. Switch and PBX hacking used to be very easy when signaling was done in-band. SS7 is an out-of-band signaling system, which separated the voice from the telephone control and made "beeping into the receiver" hacking impossible. These new IP telephony systems rebuild that old, vulnerable model.

It gets worse. The FCC is mandating that cell phone companies pinpoint phone locations to within 50-100 meters (for use with 911 calls). The carriers plan to use this information to create new data services based on location. The location information will also be available through services like Parlay for third parties to use. Imagine the security implications of that information getting into unauthorized hands. What if someone correlated a person's cell phone with his online identity? Could he pinpoint locations of desktop computers on the Internet? (This is actually a serious issue for 911 services. Unless one can somehow manage location information for endpoints, there's no hope of fielding a reasonable life-critical communications system based on the Internet.)

And think about reliability. The one thing about the telephone system is that it just works. That reliability is very hard to engineer using Internet protocols. As the phone system starts to look more and more like the Internet, it will become as reliable as the Internet. This means that it will forever be in beta. This means there will be software incompatibilities, upgrade problems, and random weird errors. This means that it will fail, catastrophically, once in a while.

Telephone hacking is not new. There have been decades of allegations and investigations into Las Vegas crime syndicates surreptitiously rerouting escort-service phone numbers, and the automatic telephone exchange was invented in the late 1800s by someone convinced that operators were rerouting his calls to rival businesses. Before the Internet, the phone network was the primary focus of hackers.

But it's a hard network to hack. Telephony is still a controlled closed universe. The protocols are often proprietary, access is limited, and information is scarce. You need to speak SS7, have the right physical connections, etc. There is nominally no interconnect to the TCP/IP Internet. Even with knowledge, it is the limited physical access that provides the most constraint. Voice and control are on separate channels. None of this provides absolute security, but it helps keep the number of hackers down.

The Internet, on the other hand, is much easier to hack. It's public. It's available. Anyone can connect a computer up to the Internet. Anyone can download boatloads of hacking tools. Anyone can become a script kiddie.

What we're seeing is another example of the tension between functionality and security. Opening the network is a good thing from the perspective of creating innovative new services, speeding up development cycles, adding value to data and voice. Yet when we do this, we open up the potential for the bad things as well. It's impossible to get the one without the other.

Soon the phone network will become just like the Internet. Putting control of telephony networks on the Internet means anyone can hack chicago.switch.uswest.net. These protocols will turn control over to both authorized and unauthorized Internet control. If you think phone phreaking was bad, just wait until anyone can do it.

Standards and companies active in this area:
<http://www.parlay.org>
<http://www.telecomsys.com>
<http://www.invertix.com>
<http://www.locationet.com>
<http://www.openls.org>
<http://www.locationforum.org>
<http://www.3gpp.org>
<http://www.sipforum.org>
<http://www.sipcenter.com>
<http://www.etsi.org/tiphon>

Steve Bass and John Ladwig both helped with this article.


Crypto-Gram Reprints

Those of you who have subscribed recently might have missed these essays from back issues.

Declassifying Skipjack:
<http://www.schneier.com/crypto-gram-9807.html#skip>

The Future of Crypto-Hacking:
<http://www.schneier.com/...>

Bungled SSL:
<http://www.schneier.com/...>

Full Disclosure and the CIA:
<http://www.schneier.com/crypto-gram-0007.html#1>

Security Risks of Unicode:
<http://www.schneier.com/crypto-gram-0007.html#9>


News

Security is a people problem:
<http://cgi.zdnet.com/slink?107608:8469234>

The NSA has released a bunch of guides to help DoD organizations secure Windows 2000.
<http://nsa1.www.conxion.com/win2k/index.html>

I'm not sure what to make of this one. Robert Hanssen, the FBI agent accused of spying for the Russians, wanted to retire into a job with Invicta Networks. (Invicta Networks is the company run by Soviet KGB defector Viktor Sheymov that I talked about last month.) Is Invicta Networks a government front? For which government? This is just plain weird.
<http://www.nydailynews.com/2001-02-23/...>

Rental car companies use GPS features in their cars to spy on renters.
<http://www.zdnet.com/zdnn/stories/news/...>
At least in this case, it has been declared illegal.
<http://www.zdnet.com/zdnn/stories/news/...>
But the car rental company has no plans to change the policy.
<http://www.wired.com/news/privacy/0,1848,45163,00.html>

Insiders are a serious security concern.
<http://cgi.zdnet.com/slink?110672:8469234>
As are ex-employees (outsiders who used to be insiders, and who 1) often still have access, and 2) are sometimes pissed).
<http://www.securityfocus.com/templates/article.html?...>
<http://www.computerworld.com/itresources/rcstory/...>
And corporate downsizing makes the problem worse:
<http://www.computerworld.com/rckey73/story/...>

I have long wondered about the security of various online competitions. Here is a Coca Cola competition that has been hacked.
<http://www.theage.com.au/news/national/2001/06/18/...>

Negligence causes security problems. (Does this surprise anyone?)
<http://www.vnunet.com/News/1123341>

Here's a story about a Microsoft IIS vulnerability, a patch that many people have not bothered installing, and a hacker tool that exploits the vulnerability. Often the tools are made public, and are used by thousands of script kiddies world-wide. At this time, it seems that the hacker tools are being held closer to the vest because they are so valuable.
<http://news.cnet.com/news/0-1003-200-6353491.html?...>

How the FBI investigates computer crime:
<http://www.cert.org/tech_tips/...>

Parody: "Terms used in the disciplines of Cryptography, IT Security and Risk Analysis."
<http://www.ii.uib.no/~larsr/craptology/crv0n0-0.html>

Excellent three-part series on developing good security habits:
<http://www.securityfocus.com/focus/basics/articles/...> [link moved to http://www.securityfocus.com/infocus/1195]
<http://www.securityfocus.com/focus/basics/articles/...> [link moved to http://www.securityfocus.com/infocus/1196]
<http://www.securityfocus.com/focus/basics/articles/...> [link moved to http://www.securityfocus.com/infocus/1197]

NIST has released a new FIPS 140 standard. This has been the de facto standard for cryptographic modules, and is evoked for other crypto hardware devices. There aren't many changes in the new FIPS 140-2, but there are some.
<http://csrc.nist.gov/cryptval/140-2.htm>

Comparing computer viruses with biological viruses:
<http://securityportal.com/articles/greatanalogy1.html>

Terrorists are using encryption!!! This is a terrible story, one-sided and full of hyperbole. But it plays well as FBI propaganda. Remember kids, cryptography is for criminals. Big Brother is your friend. What I particularly like is the way key escrow is proposed as the solution when steganography is described as the problem. Geez.
<http://www.usatoday.com/life/cyber/tech/...>

Big Brother is Tampa's friend. During the recent Super Bowl in Tampa, Florida, the city installed video cameras that watched everybody coming into the stadium. Then, the faces were compared to an archive of wanted criminal suspects, looking for a match. (The system matched nineteen people, all wanted for minor offenses. No one was arrested.) Tampa liked the system so much they're making it permanent.
<http://www.cnn.com/2001/TECH/ptech/07/02/...> [link dead; for a related story see http://www.theregister.co.uk/content/4/20134.html]

Time for some good news. The EU is funding a project to build an intelligent agent that executes actions in compliance with European standard privacy legislation.
<http://pet-pisa.openspace.nl/pisa_org/pisa/index.html>

Article on NSA's Cryptologic Museum:
<http://www.washingtonpost.com/wp-dyn/articles/...>

Teen hacker gets sentenced to psychiatric care, not jail:
<http://news.bbc.co.uk/hi/english/uk/wales/...>
<http://cgi.zdnet.com/slink?116143:8469234>

Eli Lilly leaks 600 names of Prozac users. I wonder what the "computer programming error" was -- using "To:" instead of "Bcc:" in an e-mail?
<http://www.washingtonpost.com/wp-dyn/articles/...>
<http://www.siliconvalley.com/docs/news/svfront/...>

Outlook Redemption is a developer tool specifically designed to let Outlook applications evade the Outlook security patches and built-in features of Outlook 2000 that warn users when applications send mail on their behalf, read their address book, and so forth. This can't possibly be a good idea.
<http://www.dimastr.com/redemption/>
On the other hand, the "security patch" is a really terrible idea, too; it won't let you receive bunches of different types of attachments, rather than letting the user choose. And there's no way to uninstall the security patch, once installed. That's what inspired this tool, I'll bet.

This story is interesting because it shows how easy it is to track someone trying to be anonymous on the Internet, especially someone who doesn't understand how the Internet works.
<http://www.wired.com/news/politics/...>

Yet another scary hacking tool. Sure, there's a patch available. But what percentage of users actually have installed the patch? Anyone care to take a guess?
<http://cgi.zdnet.com/slink?115257:8469234>

Trojan horse that is a spam tool; it sends bulk e-mail without the user's knowledge.
<http://cgi.zdnet.com/slink?115260:8469234>

Having a firewall set up on your system doesn't do you much good if you don't monitor it for abnormal behavior.
<http://cgi.zdnet.com/slink?116145:8469234>
What I find interesting is the number of different things the author suggests you watch out for. This would be a tall order for anyone to do continuously, and this is just a small number of the total number of alerts -- from firewall logs and all the other network-device logs -- that you should be looking for. And, of course, you really want to be reading those logs in real-time, so you can react to problems quickly. This article explains the precise reason why I formed Counterpane Internet Security as a Managed Security Monitoring company.

An argument for anonymity: From "The Economist": "Scientists and engineers at Xerox's Palo Alto Research Center (PARC), for instance, were discouraged from searching an online database of patents maintained by IBM. Xerox feared that if IBM tracked the pattern of inquiries made by its engineers at PARC, the computer giant could build a fairly accurate profile of the kind of research under way in the Palo Alto laboratories."
<http://www.economist.com/science/tq/...>

Top 10 security mistakes. Not a bad list, actually. The main problem is that some of these mistakes are not fixable. At least, it's not realistic to expect them to be fixed.
<http://www.idg.net/ic_646834_1794_9-10000.html>

You have to love the irony of this story. "A U.S. government website devoted to helping businesses keep sensitive information private instead revealed confidential information about American firms." Honestly, I don't think the so-called Safe Harbor idea is going to work long-term. As soon as European governments realize that private information is being leaked, they are going to demand the same controls on non-collection that they subject their own companies to.
<http://www.wired.com/news/technology/...>

Malware of the future will be worse.
<http://news.cnet.com/news/0-1003-200-6548363.html?...>


Counterpane Internet Security News

Some time ago I talked about various cool things going on at Counterpane that I couldn't talk about. One was the reseller agreement with Exodus, which I mentioned last month. The other is our VAR program. This is a big deal. A whole bunch of security VARs and resellers have signed up to resell Counterpane's Managed Security Monitoring service.
Counterpane's U.S. VARs:
<http://www.counterpane.com/pr-resellers.html>
Counterpane's European VARs:
<http://www.counterpane.com/pr-emeavars.html>
Press coverage (please pardon the awful picture of me):
<http://www.crn.com/Components/Search/Article.asp?...>

Alliance between Counterpane and Cigital:
<http://www.counterpane.com/pr-cigital.html>

Schneier is speaking at the 3rd Annual CERT Conference in Omaha on 6 August:
<http://www.certconf.org/>

A video interview with Bruce Schneier is on silicon.com:
<http://www.silicon.com/a45413>


Monitoring First

(Note: This essay advocates something that my company, Counterpane Internet Security, is selling. If this will offend you, please do not read this. I have announced my bias. You are forewarned.)

You have a safe in a dilapidated building, and you need to secure it. What's the first thing you do? Inventory the safe? Assess the security of the building? Install better locks on the doors and bars on the windows? Probably not. The first thing you do, as quickly as possible, is alarm the safe. Once the safe is being monitored, you can then afford the time and attention needed to inventory the stock, analyze the environment, and improve the security. Without monitoring, you're vulnerable until your security is perfect. If you monitor first, you're immediately more secure.

Network security has this backwards. Companies see monitoring as something to do after they have their security products in place. First they develop a security policy. Then they do a vulnerability analysis. Then they install a firewall, and maybe an intrusion detection system. And finally they think about monitoring. Rationally, this makes no sense.

Monitoring should be the first step in any network security plan. It's something that a network administrator can do today to provide immediate value. Policy analysis and vulnerability assessments take time, and don't actually improve a network's security until they're acted upon. Installing security products improves security, but only if they are installed correctly and in the right places. How does a CIO know what products to install, and whether they are actually working -- in the actual corporate environment, not as they worked in the lab? The only way he can know is to monitor. Monitoring ensures that security products are working properly.

This kind of thinking is especially important in dynamic environments like company networks. The network changes every day: new applications, new servers, new vulnerabilities. A CIO can go to sleep one night confident that his network is secure, and can wake up the following morning to read about a major vulnerability in the newspaper. Suddenly his network is wide open, even though nothing changed. A CIO can reconfigure his network to increase productivity, or add a new network service, or simply upgrade a software package, and suddenly the security of his environment is completely different. Networks are extremely complex -- nonlinear and tightly coupled -- and it's impossible to predict how different subsystems interact. How does he know the security ramifications of what he does? The only way is to monitor security.

It's specious logic for a CIO to decide to wait until his network is stable, he understands his security, and all his patches are up to date. It'll never happen. Monitoring's best value is when a network is in flux -- as all large networks always are -- due to internal and external factors. Monitoring provides immediate security in a way that a vulnerability assessment can never provide, in a way that dropping a firewall into a network can never provide. Monitoring provides dynamic security in a way that a random product can never provide. And as security products are added into a network -- firewalls, IDSs, specialized security devices -- monitoring only gets better.

In engineering, control theory is based on the concept of monitoring. An engineer might want to be able to tune his factory: "How can I control this plastic film extruder to ensure a uniform thickness of plastic?" This is a real question, and a complicated one. The plastics extruder might have a dozen different dials controlling things like temperature, pressure, and speed. You can adjust the amount and force of the air being blown, the amount of plastic bead material in the machine, or how rapidly the film is pulled out of the machine. All of these controls affect the thickness of the plastic; but what you really want is to turn a single dial that says "4 mil plastic." But since each dial affects the others, can even cause time-dependent feedback loops, it's not nearly as simple as that. So what do you do? You monitor the system, not just at the output but internally. Then, based on what you've observed, you establish feedback loops to create a closed-loop system (I am i
gnoring a library's worth of advanced mathematics here), and apply the mathematics of control theory to get what you want. It might take hundreds of pages of analysis, but that's how control theory works. But first you need to monitor so you know what's going on. Monitor, and you gain control of the system.

Security is no different. Monitoring is what gives companies a window into their security. Did you install a firewall? An IDS? Why? Did it increase security or not? Did you configure it right? Did you install it at the right place in your network? How do you know? Monitoring is how you know. Monitoring is the only way you can really know. And once you know, you can start making changes. If you make changes without monitoring, you're just guessing.

Monitoring is the feedback loop that makes all the other network security activities more effective. It's how you determine where to install security devices, and whether or not they're doing any good. It's how you know if your security devices are configured correctly. It's how you ensure that your security doesn't degrade over time. And it needs to be done first.


Comments from Readers

From: Hal Lockhart <hal.lockhart entegrity.com>
Subject: What Military History Can Teach Network Security
In recent years, I have become convinced that one of the biggest obstacles to information security is incorrect reasoning based on false analogies. Don't get me wrong. I think analogies are great, I use them all the time to explain technical concepts to laymen. The problem comes when you try to design solutions from the analogy rather than the technology. A familiar, non-computer example is when people who don't understand the math try to argue about relativity. Closer to home, I have seen many people who put their Web server with private key outside the firewall. "I don't want to let somebody inside my wall until I check their credentials," they say. They are thinking about a guy with a crowbar, not computers sending and receiving messages.
This brings me to your articles on war as a metaphor for hacking, which makes me nervous for the reasons stated. I am always happy to steal good ideas from anybody, but hacking as war strikes me more as rhetoric than reality. In a war, the enemy has some identity, common characteristics, loyalty and objectives. While we would prefer to defeat the enemy, we can have confidence that if the enemy achieves some set of goals they will be willing to stop fighting.
The current state of the Internet seems a lot more like anarchy or vandalism. Attackers have no common characteristics or objectives, except the attacks themselves. In fact it appears that in most cases they have no external objective at all. Web defacements in particular seem almost exactly like spray painting graffiti on subway trains. This is a problem that was once thought to be insoluble, but was eventually reduced to acceptable levels by the combined use of technology (padlocks and special paints) and labor (cops and cleaners).
However if you insist on war as the metaphor, here are two thoughts along those lines. First, the war, if that is what it is, is surely a guerrilla war. The entities being attacked are large, visible, slow-moving and part of the power structure. They have much greater resources than the attackers, but no effective way to apply them. The attackers and few, dispersed, hidden and have few resources. But what they have is the free choice of when and where to attack.
To fight guerrillas it is necessary to a) identify them; i.e., distinguish them from civilians and b) control some resource that is essential to their survival. Given the Internet as it exists today, I don't see much hope of doing either of these. If the authorities decide to employ broadly targeted, draconian measures, they will find like the British in America and the Americans in Vietnam, that the collateral effects on innocent civilians are simply unacceptable.
My second thought about hacking as war is that the situation can be compared to that in many wars, but most especially the American Civil War. While some people were busy fighting and dying, war profiteers made fortunes selling rotten food, unserviceable uniforms and non-working weapons. With a market full of snake oil security, bug-ridden applications and vendors who are more interested in suing or prosecuting people who reveal security problems than fixing them, this seems like the kind of war we are in.

From: Bill McGonigle <bill zettabyte.net>
Subject: Re: CRYPTO-GRAM, June 15, 2001
>From: Richard Straub <richard.straub@mediacrypt.com>
>Subject: Digital Content Protection
>Preventing unauthorized people from copying or distributing
>intellectual property is a natural law of this world, whether
>it is a digital or physical product.
It cannot be argued that a human law created less than 300 years ago is a natural law. Copyright was established in 1710 by the Statute of Anne by the British Parliament to protect the public from the publishers.
This was an artifact of the printing press. After Gutenberg invented it a market for books developed. Before that people actually memorized and told stories. Books were way too expensive and had to be hand-copied by monks (in papal states). People decided they liked books, probably since then they could spend time on things besides memorizing stories. Once people didn't remember how to memorize stories, publishers figured out that they could make a bunch of money by creating a scarcity of stories in the books market. The Parliament put a stop to that with the copyright law by limiting the term of exclusivity, but since the capital costs of hiring a logging team, building a pulp plant and building a printing press are beyond that of ordinary citizens, a scarcity still existed, and publishers could make a fair profit.
Digital reproduction drives the scarcity towards zero since the costs of reproduction and distribution of text are extremely low. Digital copyright protection seeks to artificially enforce the scarcity. But the function of the publishers as converters of trees into books is approaching obsolescence in the post-Gutenberg era. Rich citizens can afford to commission works directly, and poor citizens can cooperate with something like the Street Performer protocol.
Neither Sophocles nor Chaucer nor Shakespeare had the benefit of copyright protection.

From: Russell Nelson <nelson crynwr.com>
Subject: Digital Content Protection
>From: Paul Kocher <paul@cryptography.com>
>Subject: Digital Content Protection
>For this reason, I disagree with the assertion that "unrestricted
>distribution is a natural law of digital content" -- I don't see
>piracy as the result of a natural law any more than stealing,
>cheating, and eavesdropping are.
Sorry, Paul, but Bruce is right. Without end-to-end encryption (in other words, directly inserted from the distributor into the person's senses without ever being available in plaintext -- using some technology that I doubt could exist or if it could, wouldn't be accepted by consumers), the hostile attacker (in other words, the user in the privacy of their home) can intercept the communications.
Okay, so the plaintext is available. Now, I take that plaintext and encrypt it. I tell everyone "Suck down a copy of this file. I'll tell you what it is later; possibly much later." How is a content "owner" to deal with that? They can't decrypt it. They don't even know it's their content. They might think they own it if I describe it vaguely, or even exactly. But how to prove it in a court of law? "Sorry, your honor, I don't really know what that file is. I got it from someone else. No, your honor, I can't give you the key. Only the encryptor has the key to it, and I didn't encrypt it."
The endgame has only two possibilities: 1) the complete prohibition of publishing anything with random bits in it, or 2) the death of copyright. #1 is not in the cards, therefore you can count on #2. Any action taken by any content owner to stop copying is just a delaying action based on revising their business plan or implementing same. Any action NOT based on the reality of #2 is head-in-the-sand idiocy, to be whacked by knowledgeable stockholders.

Reply-To: Vladimir Katalov <vkatalov@elcomsoft.com>
Subject: Re: The Futility of Digital Copy Prevention
> All digital copy protection schemes can be broken, and once they
> are, the breaks will be distributed...
Totally agree. Unfortunately, not all the people (especially developers of DRM (or how you call it: "digital copy protection schemes") think so. Our company specializes in password recovery and decryption software; just about two weeks ago, we have released a product that decrypts protected Adobe Acrobat PDF files and e-books, removing all protections. And immediately got problems with Adobe: they did their best to close our site etc. Now the site is functional again, we don't sell the program anymore. Also, they 'closed' the hole
in Acrobat eBook Reader by making new, improved version, but we have broken it as well -- in just 20 minutes. Our program works like a demo -- decrypts only 25% of file contents, just to demonstrate the problems with such kind of 'copy protection'.
You can read the whole story about our battle with Adobe (and get our
program) here: <http://www.elcomsoft.com/aebpr.html>

From: Mike <John.Michael.Williams computer.org>
Subject: The Fallacy of Incomplete Requirements
In your 6/15 newsletter, Ken Ayer <kayer@visa.com> wrote in justification of the Common Criteria (CC): "Every vendor (whether of a chip, card, lab or consulting service) says it's the best, but we need a way to compare these claims... What Visa has done with the Common Criteria is to start a dialogue on how to clearly express security requirements... We are making progress, though there remains work to be done...."
This is the Fallacy of Incomplete Requirements: If we could all just get along, and write down what we REALLY want done, we could have those 'droid techies fix this annoying aberration.
We informally compare marketing/technical claims all the time, those involving the life-and-limb of ourselves and our family -- for example, automotive safety. Show me the SAE spec for "automotive security," or component-wise, cockpit-collapse security, comparable to what the CC ilk want.
Government and professional societies like SAE, IEEE, ACM, (or hybrids like CC bureaucracies) can't begin to do this. Collapse rate of a steering column? Right. Impact of a side-airbag? Right. Tire safety? Hmmm ... check the net for hearings and litigation, possibly criminal, on Ford vs. Firestone.
Safety-rating of a cockpit, a vehicle, a model, a brand? No way. The market and painful experience reject the failures (the pre-'65 Chevy Corvairs, and maybe the Ford Explorers, for examples).
What no one acknowledges is an observation I've made since entering the biz in '73. Science generally is extremely poor at detecting fraud and deception -- one doesn't get one's doctorate by proving why the big guys' ideas don't work, and you don't win tenure by winnowing out colleagues' detritus. Some of the biggest suckers for stage magic and plain old collusion have been scientists, especially government scientists.
Computer security is unique in an aspect it fails to acknowledge: it contains the notion, and realization, of hostile automata. Let's see a requirements spec for that!

CRYPTO-GRAM is a free monthly newsletter providing summaries, analyses, insights, and commentaries on computer security and cryptography.

To subscribe, visit <http://www.schneier.com/crypto-gram.html> or send a blank message to crypto-gram-subscribe@chaparraltree.com. To unsubscribe, visit <http://www.schneier.com/crypto-gram-faq.html>. Back issues are available on <http://www.counterpane.com>.

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 "Secrets and Lies" and "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 the world leader in Managed Security Monitoring. Counterpane's expert security analysts protect networks for Fortune 2000 companies world-wide.

<http://www.counterpane.com/>

later issue
earlier issue
back to Crypto-Gram index

Photo of Bruce Schneier by Per Ervland.

Schneier on Security is a personal website. Opinions expressed are not necessarily those of Co3 Systems, Inc..