February 15, 2001
by Bruce Schneier
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:
Hard-Drive-Embedded Copy Protection
CPRM (Content Protection for Recordable Media) is a system for enforcing copy protection on personal computers. The basic idea is to enforce digital rights management -- copy-prevention, limited use, whatever -- in electronic media.
In more detail, the scheme requires specially designed copying software. This software communicates directly to the disk drive, bypassing the operating system. To write a document, first the drive and the software authenticate to each other. Then the drive sends the software keying material that is stored in a nonstandard place on the drive that's unique to the medium, and also reads back an increment-only counter in the medium. The user-level application -- or, more likely, a server somewhere on the Web -- encrypts the file using that keying material. The encrypted object is written as an ordinary file on the medium. An intermediate key file is written as a second ordinary file.
The "player" for these encrypted objects will pull an increment-only counter out of the drive, use it and the keying material to decrypt the intermediate key-file, and then extract the document key from that file. It will then play the document.
To move (as opposed to copy) the document to another disk, the software will check to determine if this is permissible. (Perhaps the permissions will be embedded in the file; perhaps the software will query another computer over the Internet.) If the move is allowed, the software will re-encrypt the document for the new medium (only allowing it to be stored in a copy-protected medium), increment the increment-only counter in the old medium, generate a new key-file key with the new counter value, and rewrite the old key-file, deleting the key that would allow the old copy to be played. After moving the document, even if the user keeps a copy of the encrypted bits, it won't play on the original medium because its key won't be in the key-file on that medium.
If a user copies the encrypted object to another medium without going through the approved procedure, its key won't be in the key-file on the new medium, so the reader can't play it. If the user copies both of them to another medium, the key-file won't be decryptable since its key depends on the medium-specific keying info. If the user makes a backup copy of his entire disk, "moves" the encrypted song onto another medium, then scrubs and restores the entire original disk, the restored key-file won't be decryptable, since the increment-only counter (that is hashed with the medium-specific keys to produce the key-file key) will have changed.
There are other tricks built into the system. There's no single global secret to steal, and there's a mechanism to recover security if some of the many global secrets get out. The system is based on something called "broadcast encryption," developed by Amos Fiat and Moni Naar in 1993.
The technology will be ineffective, but that may not matter.
Broadly speaking, there are three classes of people who copy documents. There are average users, who just want a second copy for whatever reason but won't use hacker tools. There are more savvy users, who are willing to download programs that break copy-protection schemes. And there are professionals, who are prepared to spend serious money to break copy-protection schemes.
Against the first group, any security measure works. This hardware scheme is overkill. Against the second group, any scheme that involves software fails. I've written about this extensively both in _Secrets and Lies_ (see pp. 250-253) and in a previous issue of Crypto-Gram. Basically, the scheme described above has a key stored in hardware and a software decryptor. To break the scheme, you don't need to extract the hardware key. You can let the decryption software do it normally, and then grab the document after decryption and before play. Someone will write software do to this, just as someone has written software to get around every other similar scheme. The hardware component doesn't matter.
Where it will make a difference is in devices that don't expose the decrypted document. The reason the computer embodiment fails is because the document exists unencrypted in the computer, and a hacker can write a program to take advantage of that. If this copy protection is brought forward to the video monitor, or the speakers, then the document never exists in the computer in unencrypted form. If the scheme only runs on DVD players or MP3 devices or anything else where you can't run custom software, this is much more effective.
But it still doesn't work against the third class of attackers: the professionals. These are people willing to invest in custom hardware. They will always be able to break these schemes and extract the documents. And they will always be able to produce and sell bootlegs, at least to the limits of law enforcement in whatever country they're in.
There is another angle here, making this even more complicated. Content providers are no longer relying on technology to enforce copy protection, they're relying on laws. The algorithms used in this scheme will be patented, so anyone who writes a hacked decoder will be infringing on the patent. And any software designed to circumvent this mechanism will be illegal under the Digital Millennium Copyright Act. Not only can the authors of this software be prosecuted, but so can people who "traffic" in this software: e.g., post or link to it on their Web site.
This will not make it any harder to find such circumvention software -- notice how easy it is to find DeCSS today with your search engine -- but it will have a chilling effect on the whole idea. 2600 Magazine was successfully prosecuted for linking to DeCSS; similar pressure will be brought to bear against anyone who publicizes any DeCPRM software.
So, what do we have here? We have a serious threat to civil liberties: large entertainment companies are allying themselves with the computer industry to dictate what can and can't happen on your hard drive. (CPRM is only supposed to be for flash memory. This is a lie, of course. Already it is planned for IBM's tiny hard drive, and larger drives aren't far behind.) We have a technology that will, in some circumstances, make backups impossible. Compatibility problems between disk drives that have CPRM and those that don't will force networks to completely upgrade their mass storage. We have a technology that forces users to buy proprietary decoding software forever. We have a technology that won't really work unless it extends to computer output devices; you may find yourself forced to upgrade your monitor as well to watch movies on your computer. And we have an increased reliance on legal harassment by media companies. It's that last bit that scares me the most.
What's Wrong with Copy Protection, by John Gilmore:
Copy protection and why it doesn't work:
EFF's archives on the topic:
The 4C Entity (IBM, Intel, Toshiba and Matsushita), which owns and advocates CPRM:
Distributed denial-of-service attacks:
Recognizing crypto snake-oil:
Nineteen technology companies have joined forces to share data on system vulnerabilities and Internet threats. Called the Information Technology Information Sharing and Analysis Center (IT-ISAC), the group is supposed work with the government to head off future cyberattacks on the group's members. I have very mixed feelings about this. On the one hand, sharing information is a good idea, and we need more of this. On the other hand, the problem with sharing information among group members is that it remains a secret from the rest of the world. The last thing we want is a divide of haves and have-nots, with only those in special clubs being secure.
Princeton University's Ed Felten is not going to publish details about how he broke the Secure Digital Music Initiative (SDMI) watermark challenge, because of the prosecution provisions of 1998 Digital Millennium Copyright Act (DMCA).
A rebuttal to my essay last month about certifying security products:
The future of operating system security:
Latest news on U.S. crypto export controls:
Testimony on evaluating voting machines. He makes the point that voting machines should never have secret or proprietary parts. A bit long, but worth reading.
A Linux worm -- called Ramen -- is working its way through the Internet. Some consider this retribution for the smugness of Linux users about the security of their operating system versus Windows. That misses the point; of course all operating systems will have vulnerabilities. The two interesting points are: 1) default installations of Red Hat Linux are insecure, just like default installations of Windows, and 2) just because patches exist for a vulnerability doesn't mean we're safe.
Why the government needs to protect individual privacy on the Internet, while staying away from regulating content, information, and ideas.
A year after the highly publicized distributed denial-of-service attacks, the Internet is still vulnerable:
The EFF has petitioned a federal appeals court to overturn a lower court's interpretation of the DMCA to mean that the 2600 Web site must remove links to DeCSS.
Leo Marks, WW II cryptographer and author of _Between Silk and Cyanide_ died:
Often, security vulnerabilities are never patched:
The 3G cell phone encryption algorithms are public. This is a welcome change from the industry's usual practice of secret cryptography. Bravo.
After all these years, the Net still isn't a safe place (no surprise):
All vulnerability scanners miss things, but the open source (and free) Nessus was judged to be the best:
Children are a significant personal privacy risk:
Master's thesis: Cryptographic Software Export Controls in the EU.
DirecTV scored a direct hit against pirates. Over the course of a few months it surreptitiously broadcast, byte by byte, a program that allowed it to permanently disable pirate DirecTV access cards. On January 21st, they triggered the program. Supposedly this knocked out 98% of cracked cards. My favorite tidbit is that they wrote "GAME OVER" into an affected area of memory. The pirate community is already working on hardware workarounds and, supposedly, the cracked cards that use emulation are easy to fix. So while DirecTV won this battle, the war goes on.
Basic cryptanalysis of RSA's formerly proprietary SecurID hash function.
The NSA is trying to design a hack-proof computer. I don't know, but this seems like a poorly thought out idea.
Classic snake oil:
More snake oil: cryptanalysis of "Encrypted Magic Folders":
It seems that private keys are exposed in the Java security database. This explanation is worth reading.
A bunch of cryptographers, myself included, wrote an amicus brief for the DeCSS case that EFF is supporting:
Optical vote readers can be worse than punch cards, according to a 28 Jan 01 LA Times article. Some systems reject ballots because the voter marked the oval for a candidate and then also wrote the same candidate's name in the write-in space. Personally, I don't see how that can be interpreted as anything but "the clear intent of the voter." My favorite blunder has to be the counting machines that rejected mail-in absentee ballots because they detected the fold in the paper (unavoidable in order to actually mail the ballot in the legal envelope) as a second vote. (If you want to read the article online, you have to pay for it at www.latimes.com. The idiots only keep their links free for a few weeks.)
Excellent article on why micropayments don't make business sense.
Fascinating thought piece on the future of "digital rights management":
There have been reports that RSA has been cracked by a Filipino "math enthusiast." Actually, the cracking algorithm is slower than factoring.
Crypto break of the 802.11 wireless LAN encryption protocol (Apple's AirPort, for example). Real-time decryption of traffic is possible. Nice work.
Counterpane Internet Security News
An Intentional Back Door
It's one thing have an attacker add a back door to your system for later unauthorized access. It's quite another to deliberately do it to yourself.
It seems that Borland did this very thing with its Interbase database. All versions released for the past seven years (versions 4.x through 6.01) have this back door. How it came about and how it was discovered is instructive.
Versions of Interbase before 1994 didn't have any access-control mechanisms. This was fixed in version 4.0 using a peculiar system. Since they had a database, the engineers created a special database within Interbase for account names and encrypted passwords. This solution had a problem: in order to authenticate a user, the program had to access the database, but before the program could access the database, it had to authenticate a user.
Now there are many ways to solve this problem, but hard coding the username "politically" and the password "correct" is not the one I would have chosen. But it is the one Borland did. This is the backdoor; anyone using that username and password can access any Interbase database.
Lesson one: Deliberately adding back doors creates a security problem whose magnitude is unknown and changes over time. I call this the "window of exposure." The moment this product was shipped, the vulnerability existed. But as long as no one knew about it, it wasn't a problem. At this point we have no idea if anyone in the hacking underground knew about the vulnerability, or if any criminals took advantage of it. Certainly the programmers who coded the "feature" knew about it. They could have told others. Word could have gotten around.
Now the vulnerability is public; everyone knows about. Within days of announcement, there were reports of scans looking for the vulnerability. Borland issued a patch, but who knows what percentage of users will patch their systems. The vulnerability will remain in many systems for years.
Lesson two: Open source helps security, sometimes. Interbase was made open source in July 2000. This vulnerability was discovered six months later by a German software developer. If he hadn't discovered it, maybe we would still not know about it. If someone had looked at the code sooner, maybe we would have known sooner. Open source means that more people examine the source code, but it is no guarantee that vulnerabilities will be found or -- even if found -- fixed properly. If the person who discovered the vulnerability was intent on breaking into systems, this would have played out much differently.
Lesson three: In a world with no liabilities, trust is transitive whether you like it or not. Company X's customers trust Company X. If Company X was using Interbase, those customers were also trusting Borland...only they didn't know it. Those customers are also trusting Company X's hardware and software suppliers, ISP, etc., etc., etc. If the Company X had some sort of legal liability towards its customers, then this transitive relationship would not exist. But because the customers have no recourse if Company X screws up, it does.
Back doors have the unfortunate property of being all or nothing. It's like leaving your house key under the mat. If no one knows about it, it's pretty safe. If everyone knows about it, it makes your door lock useless. Borland certainly belongs in the doghouse for this one.
The Doghouse: NASA and eTrue
NASA is testing a biometric authentication system that works over the Internet. I've repeatedly written, both in these pages and in _Secrets and Lies_, about the dangers and insecurities of remote biometric authentication. But if that weren't enough, the CEO of the biometric company eTrue was reported to have said: "And anyone attempting to hack into a NASA system will have his or her own biometric characteristics logged and recorded." Why would anyone attempting to break into a network send his *own* fingerprint to be authenticated? (Note that it is not a direct quote in the article, which may mean that the reporter is to blame for this.)
My essay on biometrics:
A Semantic Attack on URLs
This is clever. Last month I received an e-mail that said:
Check out breaking news at CNN:
(Unfortunately, the URL no longer works. But stick with me.) At first glance, this looks like a CNN URL. But the URL does not lead to, or does not redirect from, cnn.com. The page is not CNN's. The URL is a clever hack that plays with people's assumptions about what a URL is supposed to look like.
Here's how it works. An MIT student created a fake Web page and put it up on his Web site at:
He then sent out the first URL above. If you examine that URL carefully, you can see that the host name is not "www.cnn.com" but "22.214.171.124," which is the same as salticus-peckhamae.mit.edu. (For extra obfuscation, he could have converted that host name to decimal.) That entire bit before the @-sign -- "www.cnn.com&story=breaking_news" -- is a "username," something allowed by the HTTP specification but rarely used in actual URLs.
This is a really clever example of a semantic attack: one that targets people and meaning rather than computer syntax. The attacks are obvious: someone could send a fake e-mail from www.whatever.com, telling them to click on this URL for a free gift. The URL would look like it came from the Whatever company, but would instead go to a look-alike site that harvests the usernames and passwords.
Most Internet users have no idea what a URL is supposed to look like, let alone how to parse one. In a world where there is no real way to validate anything, the URL has become the means that people use to determine the source of a Web page. (Does anyone EVER examine a public-key certificate?) But if URLs can play with our expectations of what they should look like, what can we do?
E-Mail Filter Idiocy
As long as we're mentioning semantic attacks, let's talk about semantic defenses. Many companies filter incoming e-mail for viruses, Trojans, spam, etc. Some of these filters blocked the January Crypto-Gram.
Ten copies were blocked because they contained the character string "ILOVEYOU" -- even though they were plain text with no attachments. This makes no sense to me: it's laughably easy to change ILOVEYOU to use some other subject line, but good luck getting it to spread through plain text e-mail. (I suppose you could put the source code in the message and just hope the recipient would compile it.) So what the filter really does is block e-mail containing information about the Trojan, not to mention this issue of Crypto-Gram.
But that bit of overreaction pales in comparison to this bounce message I received: "MailMarshal (an automated content monitoring gateway) has stopped the following e-mail for the following reason: It believes it may contain unacceptable language terms, or inappropriate material....
"MailMarshal Rule: Inbound Messages: Block Unacceptable Language, Script Profanity Porn and Racism Triggered, Expression: blow AND job Triggered 1 times weighting 5. For more information on e-mail virus scanning, security and content management, visit http://www.crypsys.nl
That's right, MailMarshal blocked Crypto-Gram because in one place I used the word "blow" and then a couple of thousand words later I used the word "job." And the sad thing is that the very same e-mail filter will block this issue of Crypto-Gram for the very same reason, and the recipient will never know.
Whale Communications has been marketing something called e-Gap, which they claim is an "air gap" between two networks. Basically, the system consists of two servers. One is connected to the Internet and the other to the internal network. The two servers only connect through the e-Gap system, a SCSI-based memory device that gets toggled between them. The two servers are never directly connected.
This is an interesting idea, but it's not an air gap.
What E-Gap really does is create a proxy connection between two computers. It's a slow connection. It's a very limited connection; the system strips down any network layers under the session layer. What that means is that if you set up a system using E-Gap and an intruder were to break into the Internet server, he could not obtain TCP/IP connectivity to the internal server. This certainly increases the security of the back-end server.
Nonetheless, the intruder can still access the back-end server as a regular client. The intruder can still break into the internal system by exploiting any vulnerabilities above the transport layer.
The whole point of an air gap is that there is no automated connection between the two devices. It's not simply that there is no physical connection between the devices most of the time, but that any logical connection between the two devices is not automated. If the Internet server and the back-end server were on opposite sides of a room, there would be an air gap between them. To connect the two computers, a user has to walk a floppy disk across the room. For an attacker to attack one computer from the other, he needs to be physically present. Even if an attacker gains access to the Internet server remotely, he cannot bridge the air gap to the back-end server.
While E-Gap can claim that with their device systems are "completely disconnected at all times," the truth is that their switch operates automatically at all times. There is always a logical connection between the systems connected by their device. And that connection is subject to remote attack, and possible compromise.
I'm not saying that this is a bad product -- it sounds like a good product -- but it is not an air gap. Calling it one is deceptive marketing. Kind of like calling a stream cipher a one-time pad.
Whale's page describing their technology:
A response to critics by someone with Whale:
Hall of shame puff piece:
Whale isn't the only one. Here's a review of six "air gap" products:
Airgap Networks, which has few details on their product, is notable for actually defining "air gap" (albeit in an Orwellian manner).
Internet Voting vs. Large-Value e-Commerce
One of the odder comments I've heard in the debate on Internet voting is the following: "If we can protect multi-billion-dollar e-commerce transactions on the Internet, certainly we can protect elections" (or words to that effect). I've heard it so often that I feel the need to explain why it isn't true.
There are two important differences between large financial transactions and voting that make the former much more suitable for networked implementation: anonymity and recovery.
In _Secrets and Lies_, I made the point that electronic financial systems based on identity (electronic credit cards, electronic checks, PayPal, etc.) are much more likely to be implemented than electronic cash because the former is much easier to secure. Large financial transactions all have names attached: who gets the money, who loses the money. Votes only have the names of the recipients attached; the whole point of a secret ballot is to remove the name of the voter. This makes is much harder to protect the system from fraud, much harder to detect fraud if it happens, and much harder to identify the perpetrator and arrest him.
Another difference between large financial transactions and voting is that you can unwind a financial transaction. This is important. If someone manages to steal a billion dollars from a financial system, you can freeze the transaction, try to figure out what happened, and hopefully return the money. If someone manages to hack the vote, there's nothing you can do. This is the lesson from Florida: even in the face of a confusing ballot, manipulation of absentee ballot applications, widespread voter irregularities, and voting technology that disproportionally disenfranchised minorities, there was nothing that could be done. The vote was taken on Election Day, and that's that. Revoting would have been even more unfair, because it is impossible to recreate the conditions at the time of the original vote. Our voting system doesn't allow for the same ability to redo transactions that our financial systems do.
There's another, less important, difference between large financial transactions and voting: in the latter, appearances matter. If someone claims to have stolen a billion dollars and no one seems to have lost it, you can safely ignore his boast. On the other hand, if some political group claims, on election night, to have hacked the vote...what do you do? You can't disprove the claim. You can't redo the vote to make sure it is accurate.
Building a secure Internet-based voting system is a very hard problem, harder than all the other computer security problems we've attempted and failed at. I believe that the risks to democracy are too great to attempt it.
Phil Noble, director of politicsonline.com, said "...if the largest banks in the world transfer billions of dollars every day electronically we can use the same technology to ensure secure voting."
From "Analysis of Internet Voting Protocols," by Andre M. Chernay: "Currently existing software is adequate to protect the integrity of the ballot once the ballot gets into the Internet pipeline. Transactions currently performed over the Internet include e-commerce, the transferring of funds around the world, and the purchasing and selling of stocks. For example, 100 million Americans will go online this year and spend almost $12 billion in online purchases."
This same argument was made on an All Things Considered radio segment "Allow People to Register to Vote Online" on 10 Aug 1999.
"'Vote Integrity on the Internet Is No Different From Billion Dollar Transactions,' Says Chris Kenber, President and CEO of Hifn."
From an article called "About (tele)democracy": "First, we experience voter fraud now and always have lived with it. Today claims about voting irregularities are heard at nearly every election. Second, if there is an incentive to commit electronic fraud, surely money is the prime motivation. Yet, every day, hundreds of billions of dollars move through the banking system with good security. Fraud exists, but it has been policed and prosecuted."
Comments from Readers
From: Richard <richardaway32.com>
I used to work for a company that manufactured electric hospital beds, and was the liaison to UL, and I became very familiar with their modus operandi and know how the public can continue to be hoodwinked.
First, they take no legal responsibility for a product (if it should fail), by saying that the product is "Listed" not "Approved". Listing simply means that the product met some minimal standards that were in effect at the time the product was made. For encryption software, cracking simply means that that version met the old standard, and the software company needs to submit a new version to meet the new standard.
Next, they require the manufacturer to pay an annual fee to keep up the listing, along with allowing a UL inspector to visit the premises and check various samples periodically. The manufacturer naturally paid extra for this. If the manufacturer wanted to make changes to a product in a listed area, they had to submit the change beforehand and when UL accepts it (charging extra, of course), then the manufacturer could put it into production. If the inspector found an unauthorized change in the product, he could tell the manufacturer they could not ship any more product with the UL label on it. Since the UL logo is usually part of the regularly applied product packaging, he was, in effect, halting production. This means that if a software company wanted to improve or fix a bug in their product, they couldn't sell it until UL was satisfied.
Finally, every electrically savvy buyer of electrical products can look at the guts of a product and pretty well tell if it is reasonably "safe". The consumer, on the other hand, is made to believe that the product is totally safe. The truth is, is that UL goes through an evolution rating a product and making changes, just like any manufacturer, and makes mistakes and fixes to their standards. So any defect in any given UL Listed Encryption software would simply mean revisions to their standards.
All of this means money for UL, with no responsibility for any damage done.
Your last paragraph on "Ethical Extortionist" hits the nail exactly on the head. It plays right into the current public thinking that we need some "authority" to validate every facet of our lives. Authority is one of the six principles of influence as explained by Dr Robert Cialdini's http://www.influenceatwork.com/6principles.html [link moved to http://www.workingpsychology.com/6principles.html] article on influence.
I guess what I am trying to point out is that while you and I know that UL is a farce, they will probably be involved and come out smelling like a rose. The only way for them not to be involved is if all the encryption companies band together and ignore them. But that "authority" stamp of approval, excuse me, listing is too much of a selling point to be ignored.
From: Nick Rozanski <nickrozanski.com>
When most of us think about security, we view it as a binary quality of a system -- so we ask questions like "Is this system secure?" The correct answer to this question is always "no" --- *any* security architecture can be broken if there is someone willing to invest the effort, time, and/or money to break it.
However this approach is flawed. A much better way is to recognise that it is impossible to implement totally foolproof security -- the best we can do is to decide how *resistant to attack* our security architecture needs to be, which we can do this by answering two questions. Firstly, "what is the cost to me if my security architecture is compromised?" And secondly (not always the same thing) "what is the benefit to someone else of compromising my security?"
It is important to understand that the answers to these questions come from the business, not from technologists. (All we have to do is to design and build it!) Furthermore, in an ideal world it should be possible to objectively *demonstrate* that the system provides the required level of security -- in the same way that we are expected to demonstrate conformance to other classes of requirement (functional, performance, etc.) as part of acceptance.
Where we are today, this is very hard, not least because of the difficulty in quantifying, or better still eliminating, the human factors which so often seem to be involved in security breaches. In practice, demonstration of conformance to security requirements (or otherwise!) usually takes place after systems go live.
The final question to ask is "how will I respond if (when) my security architecture is eventually breached?" This is a problem which needs to be addressed by both sides -- technology to "tighten up" the security holes which have been exposed, and business to deal with the commercial fall-out and make the needed organisational changes. The answers to these questions should form part of any security model as much as the technology components do.
From: Greg Guerin <glguerinamug.org>
Here's a relatively simple attack on the code-signing in Whistler, regardless of who controls it or what it turns out to be.
1) Create an individual Web-based e-mail account on Hotmail, representing yourself as a sole proprietorship software developer. For the truly criminal, falsify all the information.
2) Register as a developer with Microsoft, providing the Hotmail e-mail address. The basic Microsoft registration is probably free.
3) Buy a genuine Authenticode code-signing key. This may be a non-trivial expense though probably not more than a few hundred bucks. For the truly criminal, pay for it with a stolen credit-card number.
4) Once you have the code-signing certificate, sign your malware with it, then distribute in the usual way. If your malware subtly sabotages the code-signing system itself, say by subverting the root key, so much the better.
5) Make the private key widely public by posting the private key and the code-signing certificate on a H4KOR 51TE, or by other means. One truly wicked possibility is to incorporate the private key and the cert itself as part of the malware, creating a self-signing worm.
6) Don't tell Microsoft, or the certificate provider, or anyone else that your private key has been "compromised." For the truly criminal, delete or abandon the falsified identity.
Eventually your code-signing certificate will be revoked (we hope). Until that happens and the Certificate Revocation List eventually gets around, your malware can go anywhere and do anything. It is, after all, completely authentic and trusted as far as the code-signing process is concerned. And if there's no CRL at all, then your malware can survive until its certificate expires or an antidote is released.
There is some monetary cost involved in this attack, but if a group of even petty criminals pools their cash, it's basically pocket-change. And if they profit from the attacks in some way, then they can create identities and buy keys on the fly, staying ahead of the CRL effectively forever.
This attack shows what happens when one of the main premises inherent in the crypto-system is flagrantly violated. In this case, the intentional widespread dissemination of the private key makes everything else in the system, including accountability, moot.
From: Phil Pennock <Phil.Pennockglobnix.org>
There's another way to defeat this. If a program is signed and running, then it's henceforth trusted. If there's a buffer overrun allowing someone to smash the stack, then their code is presumably trusted -- how would Microsoft prevent it? Stackguard-like technologies go some way towards preventing the more trivial attacks, but that's it.
So you have a buffer overrun in, say, an e-mail client. Given Microsoft's history, it isn't far-fetched to suppose that it's the default client which Microsoft ships (but then, the same can be said for c-client). The lack of adequate bounds-checking is discovered, someone writes a worm which goes around, lugging extra code as needed (e.g., along the lines of Samhain) and they disable the checking on the system. Hey presto ...
From: Leonardo Humberto Liporati <liporatialmg.gov.br>
The description of the modified PC used in the Brazilian elections has an error. The machine doesn't have a small ballot box attached to it. So the machine doesn't print and slip every vote into the ballot box. At the end of voting the machine only prints some copies of a final report with totals by candidate. This is most criticized "weakness" of the machine; there is no way to recount the votes because there are no physical proof of the vote, just a digital record on a floppy and in an internal flash memory card. This way the machine fails to achieve the AUDIT attribute, enforced by the fact that the modified PC runs a proprietary operating system/software whose source code is a commercial secret and can't be reviewed. Also the machine is said to use classified encryption software/algorithm developed by ABIN (the Brazilian secret service) that isn't available to public review. This way, when the machine print the initial "zero votes" report, no one can be sure that it represents the "initial state," just that the software inside it knows how to print such report. There is no way to check/ensure whether the final report (or the floppy contents) are the real results or pre-programmed values set by the own government.
The machine also fails to achieve the ANONYMITY attribute. The machine holds the name and ID number of each voter of that electoral zone. Before every vote, using the remote control, the operator types the ID number of the voter to release the keypad. As the software is secret, we can't be sure that it doesn't record the vote along with the ID of the voter. Another problem is that the machine sounds a beep for every key pressed. Usually a vote is made by typing the candidate's number (2 to 5 digits) and pressing the "confirm" key, but there is one key for "blank vote." So counting the number of beeps we can easy identify blank votes.
The Brazilian electronic system is far from perfect and receives many criticisms by specialists. The Web site <http://www.votoseguro.org> holds a discussion group about it, but it is in Portuguese.
From: Celso Brites <britescorreionet.com.br>
In your Cryptogram December 15 proposal for an automated voting system you say: "The voter checks the paper ballot for accuracy, and then drops it into a sealed ballot box. The paper ballots are the 'official' votes and can be used for recounts, and the computer provides a quick initial tally."
The paper ballot you propose was used in the first Brazilian electronic election. However, it has been abandoned on the elections that followed, in order to avoid an old type of electoral fraud, known in Brazil as "Voto de Cabresto" (literally translated, "halter vote"). In this fraud, a politician (typically a small-town, large property owner) "buys" votes from his (usually desperately poor) electorate with promises of small benefits, goods, or even cash. To assure that they will vote as promised, the politician uses the following trick: someone in his payroll gets to be the first one to vote, but it drops any piece of paper instead of his ballot in the box. He takes the ballot with him and marks it with a small handwritten sign. He then hands it to the first of the politician "clients", which is instructed to put the signed ballot in the box and bring his own ballot back, thus proving he voted for the "right" candidate. The whole process is then repeated: the new ballot is signed and handed to the next "client".
This process could be avoided by using a sealed transparent conduit between the machine and the box, so that the voter would not touch the ballot, but could check if it was properly printed. For some reason it was not adopted.
From: Todd Hooper <Todd.Hooperwatchguard.com>
I think the spat between Microsoft and Bugtraq is less about the rights of the security community, and more about Bugtraq (aka SecurityFocus) protecting their income stream from advertising on their portal. If Microsoft don't let them distribute the material, the value of Bugtraq (and SecurityFocus) is reduced in some fashion.
From: Jonah Duckles <jducklespurdue.edu>
I found your "Doghouse" entry for <http://www.gianus.com> intriguing. I visited their site and found that they were claiming they had full technical reports detailing how none of the independent testing agencies they had submitted their product to were able to access protected information. The two "technical" reports that I received had descriptions that basically were accounts of how good the product seemed to be. There was no technical probing of what kinds of things the product was actually doing to "hide" the data.
I contacted the person who had sent me these technical reports again to say that I felt the product simply obfuscates the data and does not actually provide any security and I received the following e-mail:From: "GIANUS TECHNOLOGIES" <email@example.com>
I guess you have every reason to keep these guys out in the Doghouse, for bad security practice AND bad PR.
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 firstname.lastname@example.org. 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 a venture-funded company bringing innovative managed security solutions to the enterprise.
Schneier.com is a personal website. Opinions expressed are not necessarily those of Co3 Systems, Inc.