January 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.counterpane.com>. To subscribe or unsubscribe, see below.
Copyright (c) 2001 by Counterpane Internet Security, Inc.
In this issue:
A Cyber UL?
Underwriters Laboratories (UL) is an independent testing organization that rates electrical equipment, safes, and a whole lot of other things. It all started in 1893, when William Henry Merrill was called in to find out why the Palace of Electricity at the Columbian Exposition in Chicago kept catching on fire (not the best way to tout the wonders of electricity). After making the exhibit safe, he realized he had a business model on his hands. He approached insurance underwriters with the idea of an independent testing lab. They were all sick of paying for electricity fires, and took him up on the deal. Eventually, if your electrical equipment wasn't UL certified, you couldn't get insurance.
Today, UL rates many different things. Safes, for example, are rated based on time and materials. A "TL-15" rating means that the safe is secure against a burglar limited to safecracking tools and 15 minutes' working time. Other ratings certify the safe for longer periods of time, or against burglars with blowtorches and explosives. These ratings are not theoretical; actual hotshot safecrackers, employed by UL, take actual safes and test them. If a company comes out with a new version of a safe, it has to get it retested -- the rating does not carry forward.
Applying this sort of thinking to computer networks -- firewalls, operating systems, Web servers -- is a natural idea. And the newly formed Center for Internet Security plans to implement it. I'll talk about the general idea first, and then the specifics.
I don't believe that this is a good idea, certainly not now and possibly not ever. First, network security is too much of a moving target. Safes are easy. Safecracking tools don't change much. Maybe someone invents a hotter torch. Or someone else invents a more sensitive microphone. But most of the time, techniques of safecracking remain constant. Not so with the Internet. There are always new vulnerabilities, new attacks, new countermeasures. There are a couple of dozen new vulnerabilities each week in major software products; any rating is likely to become obsolete within months, if not weeks.
Second, network security is much too hard to test. Again, safes are easy. Breaking into them requires skill, but is reasonably straightforward. Modern software is obscenely complex: there are an enormous number of features, configurations, implementations. And then there are interactions between different products, different vendors, and different networks. In the past, I've written extensively about complexity and the impossibility of testing security. For now, suffice it to say that testing any reasonably sized software product would cost millions of dollars, and wouldn't guarantee anything at the end. And worse, if you updated the product you'd have to test it all over again.
Third, I'm not sure how to make security ratings meaningful. Intuitively, I know what it means to have a safe rated at 30 minutes and another rated at an hour. But computer attacks don't take time in the same way that safecracking does. The Center for Internet Security talks about a rating from 1 to 10. What does a 9 mean? What does a 3 mean? How can ratings be anything other than binary: either there is a vulnerability or there isn't?
The moving-target problem particularly exacerbates this issue. Imagine a server with a 10 rating; there are no known weaknesses. Someone publishes a single vulnerability that allows an attacker to easily break in. What is the server's rating now? 9? 1? How are users notified of this change? Is the manufacturer required to change his official rating on his Web site? On his packaging? How does the Center re-rate the server once it is updated? But then the rating only affects certain patch levels of the product; how do you explain that? And once you've solved that, how do you deal with vulnerabilities that only affect the product in some configurations?
Fourth, failures in network security are not always obvious. If a safe is broken into, the owner learns about it when he next opens his safe. If a network is broken into, the owner might never know. Data isn't stolen in the same way as diamonds or cash: it is copied, it is modified, or it is just examined. Remember that Microsoft's network was compromised for weeks before anyone knew about it. I believe that most network intrusions are never even noticed. A "secure" network product might fail completely, and no one would be the wiser.
Fifth, I don't see how a rating could take context into account. Safes are just as hard to crack in a bank as they are in a house; network security products are highly dependent on their environment. A product rating cannot take into account the environment and interactions that a component will deal with. Network components would be certified in isolation, but deployed in a complex interacting environment. It is common to have several individual "secure" components completely blow a security model when they are all forced to interact with each other.
Sixth, I don't see how to combine this concept with security practices. Today the biggest problem with firewalls is not how they're built, but how the user configures them. How does a security rating take that into account? How does a security rating take into account the people problem: users naively executing e-mail attachments, or resetting passwords when a stranger calls and asks them to?
And seventh, this kind of thing could easily fall into the trap of bashing small products and protecting large products. A little-discussed fact of computer security is that minority products are more secure than popular products for the simple reason that there aren't as many exploits for them. But the unpopularity of those products might make it difficult for them to pay for evaluation. And can major vendors be held to the same standards as everyone else? It will take a lot of organizational fortitude to fail Microsoft's security, for example.
This is not to say that there's no hope. I believe that the insurance industry will eventually drive network security, and that some sort of independent testing is inevitable. But I don't think that providing a rating, or a seal of approval, is possible anytime soon.
Even so, the Center for Internet Security is tackling the challenge. Unfortunately, I don't particularly like what I see so far (although admittedly, I haven't seen much). Looking at their Web site, it seems more like a marketing scheme than anything else. A security supplier or consulting organization can spend $25K to become a member. (Organizations that use security can join for only $7K.) Benefits include "your organization's name...on Center brochures and benchmarks documents," "your organization's name included on the Center's website," and "the privilege of using the Center's logo on your website." The last time I checked, there were 71 charter members.
Their initial push is to consolidate a bunch of the mediocre security requirements documents out there (such as BS7799) and come up with a "final set of minimum benchmarks to be used as a basis for demonstrating due care," and to create a suite of tests that can give computer owners some kind of security rating or feeling of confidence.
I see ideas like this as part of the Citadel model of security, as opposed to the Insurance model. The Citadel model basically says: "If you have this stuff and do these things, you'll be safe." The Insurance model says: "Inevitably things will go wrong, so you need to plan for what happens when they do." In theory, the Citadel model is a much better model than the pessimistic, fatalistic Insurance model. But in practice, no one has ever built a citadel that is both functional and dependable.
My worry is that the Center for Internet Security will become an "extort-a-standard" body, which charges companies for a seal of approval. I believe that the people behind the Center for Internet Security have completely pure motives; you can be an ethical extortionist with completely honorable intentions. What makes it extortion is the detriment from *not* paying. If you don't have the "Security Seal of Approval," then (tsk, tsk) you're just not concerned about security.
Early discussions of a cyber-UL:
Complexity and security:
A version of this article appeared on ZDNet:
Block and stream ciphers:
Timing attacks on Web browsers. The basic idea is that by timing how long a browser takes to download a page, you can learn whether the page is stored in the browser's cache...and therefore whether or not the person visited that Web site recently.
The White House released an "International Crime Threat Assessment." The report discusses organized crime's use of computer and network attacks.
Only 25% of people who have break-ins report them. People are more worried about malicious code than break-ins, but information theft is the most damaging. Spending on security is predicted to more than triple in four years.
Personal firewalls have security holes. Is anyone surprised that commercial software fails real-world security tests?
Clever steganography application: turn a message into innocuous spam:
Here's a product that until now has only been available to intelligence services. It's a special spray that allows someone to examined the contents of sealed opaque envelopes without opening them. When sprayed on the envelope, it renders envelopes temporarily transparent, enabling you to view the contents within. The company claims that it will only market the chemical to law enforcement, but you know how things get around.
Last month I complained that Microsoft is prohibiting services like BugTraq from reposting its security advisories. Now @Stake, a company I expected better from, is doing the same thing.
Good analysis of the European CyberCrime Treaty. Short summary: it's still horrible.
Interesting interview on (among other topics) encryption with Eben Moglen, general counsel of the Free Software Foundation:
Nasty story of what an insider can do to your network:
Clever things to do with Internet bugs:
Last month I discussed a New Yorker story about someone who pretended to be an employee for a few weeks. The company in question is Luminant, which wasn't pleased with the goings on:
However, I have another story about a teen pretending to be a doctor at a DC-area hospital:
And a very strange story about a group impersonating the World Trade Organization:
Along a similar line, a non-computer story about social engineering and industrial espionage:
Ireland is rushing into electronic voting:
MIT and CalTech announce a voting technology initiative:
Hacker tool that does a man-in-the-middle attack against SSL and HTTPS (among other things):
Good information on various security resources on the WWW:
An article about the FBI's current hypocritical pretense of protecting "national security" and "privacy" by increasing its wiretapping abilities, using laws that were written to prevent hostile foreign domination of critical national infrastructure.
The Center for Strategic and International Studies has released a report: "Cyber Threats and Information Security: Meeting the 21st Century Challenge."
The NSA has finally declassified "NACSIM 5000: TEMPEST Fundamentals" and "NSTISS 7000: TEMPEST Countermeasures for Facilities." They're old documents, and redacted, but still interesting to read.
This really isn't a review of _Secrets and Lies_, but it is a good article that discusses some of its conclusions.
Excellent ActiveX security document from CERT:
Weird story about an abandoned NSA facility:
Good article on Unicode and how it can be used to evade Intrusion Detection System products:
The FBI tries to get industry to tell it about security incidents:
New security threats:
Read the new federal guidelines for search and seizure of computer equipment: the recently updated Computer Crime and Intellectual Property Section of the Department of Justice manual. There are lots of invasive searches discussed here -- car searches, work place searches, no-knock searches, secret searches, border searches -- all of whose guidelines do little to protect personal privacy. The page is 500+KB, but it's fun to search it for keywords like "palm," "pager," or "trip-wire."
Now it seems that Egghead.com is claiming the hackers who broke in didn't get millions of credit card numbers like they previously thought. As I say in this article, that doesn't matter at this point. The damage was done the moment anyone thought his or her credit card number was compromised; the reality is much less relevant.
Counterpane Internet Security News
Password Safe has won best password protection freeware (admittedly, a pretty narrow category) from Personal Firewall Guide:
Crypto-Gram has been nominated for an "Information Security Excellence Award" by Information Security Magazine, in the "On-Line Security Resource" category. If you are a subscriber -- it's a free subscription -- you can vote. You will need a copy of your magazine's mailing label. Voting is open until 19 January.
The biometrics article from the August 98 Crypto-Gram has been republished on the TechTV Web site:
Solution in Search of a Problem: SafeMessage
SafeMessage's security model is encrypted communications that is not e-mail. E-mail is risky, because the encrypted messages can get stored on servers along the way, can get backed up on disks, can leave footprints. The security model is someone so paranoid that even that is too risky. Think of it as kind of a secure instant messaging.
There are lot of details about how the product actually works, and whether those are the best choices. But that's not the point here. I can't figure out the business model here. Surely there can't be a sustainable market of people this paranoid. There's barely a sustainable market of people willing to use encrypted e-mail.
A Social Engineering Example
The Industry Standard published an example of social engineering in an article on @Stake's vulnerability assessment service:
"We pretended to be employees of the (b-to-b) company. That allowed us to wreak havoc, because we had 10 accounts to play with. I could order a piece of heavy equipment, like a backhoe, and have it financed instantly online and have it shipped to Chile."
Here's the attack: Someone calls the company's Help Desk and pretends to be an employee. He has a known userID, and convinces the Help Desk person to reset his password. He then dials in (or VPNs in, or whatever) to the network using the reset password, and orders a tractor shipped to Chile.
This is almost impossible to catch automatically. There's not a company out there that tracks which IP addresses are "valid" for their remote sales force; those people need to dial in from random ISPs that assign addresses from a pool. Even if the company recorded all successful logins and their originating addresses or phone numbers, it's nearly impossible to track what's allowed and what isn't.
Even for the large number of telecommuters using DSL/cable modem VPNs to get into their corporate networks, the vast majority of companies do not restrict VPN connections to specific addresses. It's just too hard to manage.
You improve things immensely -- assuming you're using a VPN -- by requiring client side certificates on the PC or laptop making the connection, and by using a one-time password system. You also improve things by convincing your Help Desk staff to not reset passwords based on phone calls, but that's hardly enforceable. The best idea I've heard is to train Help Desk employees not to give out reset passwords over the phone, but instead to leave it on their voicemail. This makes a lot of sense to me.
The Doghouse: Gianus Technologies
Gianus claims that their dual boot system is more secure than an encrypted file system, just because they are hiding their partition. The hype on their Web site is beyond decency.
NIST Crypto Update
On January 5, 2001, NIST announced a Draft FIPS for HMAC (Keyed-Hash Message Authentication Code) that is a generalization of HMAC as specified in Internet RFC 2104 and ANSI X9.71. A 90-day public comment period ends April 5, 2001.
On January 2, 2001, NIST posted a white paper that discusses plans for developing standards and recommendations for public key-based key management. This will be a two-part process, involving the development of 1) a scheme definition document, and 2) a key management guideline.
NIST will release the draft FIPS for the AES for public review "in the very near future." Final approvals for the release of this document are pending. When an announcement is made, information on the draft and for providing public comments will be available at the AES Web site.
Code Signing in Microsoft Windows
There's a report that the new version of Microsoft Windows, code named "Whistler," will include code signing as a security feature. The idea is to protect users from Internet-borne viruses and Trojan horses. It is unclear how much protection there really will be, and the side effects are significant.
Exactly how the system works is unknown (it's an application of Authenticode), but the general idea is that code -- software programs, plug-ins, whatever -- will come with a digital signature attached. The operating system will check the digital signature and could allow only -- presumably this will be optional -- signed code to execute. (Note the word "could"; this is an option you can turn off.)
The Internet allows viruses to spread faster than we've ever seen before, and clearly something has to be done. Assuming that this is implemented correctly, it could help somewhat. But will this security feature be turned on by default, or turned off by default? This is important; most home users don't turn security features on. And Microsoft has a history of insecure default configurations.
User interface is vital. Will unsigned code be ignored, or will the user get a dialog box on the order of: "This code is unsigned. Do you really want it to run?" Most users are incapable of making intelligent security decisions, and are likely to let the unsigned code run anyway. "What's the problem, Ron? It's just a Christmas card from Sue. It can't possibly do anything bad." Code signing can't protect you if you can't figure out whom to trust.
The easiest way to defeat this security feature is to disable, or corrupt, the signature verification function on the computer. There are lots of ways to do this: change the public key, modify the comparison so that all unsigned code is trusted, etc. This is not hard to do, if you can get a malicious program to run on the victim's machine. But if the victim has the code signing feature turned on, then presumably you can't do that. So it works.
At least, it works until someone figures out how to get his Trojan signed. This brings us to some very important questions about the system. What does it mean when a piece of code is signed? Is the idea that all signed code will be verified as not being malicious, or simply that signed code will be tied to the identity of the author? In the first case, you can be sure that anything signed is okay. In the latter case, all you can be sure of is that you know who to blame when things go wrong. Remember, digital signatures provide accountability, not protection.
How is code signed? Do software companies get the blanket ability to sign code, or is each piece of code individually submitted? If it is the former, defeating it can be as easy as breaking into a software company's network and slipping the malicious code into the signing process. Not easy, but there are a lot of software companies out there; even if only 1% of them have sloppy security, that's a lot of targets.
Who is in charge of signing code? If it is Microsoft, can they use this as a way of influencing software vendors? Steve Bellovin painted an interesting scenario: "Remember the Instant Messenger war between Microsoft and AOL? Now, suppose that the tables were reversed, that Microsoft had a service that it didn't want AOL to access. Could they revoke AOL's certificate? Would that be legal?" Do we really want Microsoft to be the final arbiter on who can and cannot be a Windows developer? There are other questions: Would small developers be able to cheaply get their code signed? What about shareware and public-domain programs? Sometimes it's hard to tell the difference between a hacker who wrote a cool utility and one who has written a new piece of malware.
And what about script files and macros? While this feature could help defend against executable viruses like ILOVEYOU from spreading, it wouldn't stop macro viruses like Melissa. Think about it. Melissa is embedded in a data file, so it can't be signed like a piece of software is. The whole point of macros is that users can easily create them. If Microsoft adds a feature whereby the creator of the data file can sign it, that won't help either since Melissa sent copies of itself to people already in the computer's address book. The point is that there is a big difference between trusting a person and trusting a person's computer, and this difference can fell many a system.
Code signing in Microsoft Windows is not new. There are two systems in Windows 2000. Something called a "trusted application" is signed by the software publisher, allowing users to verify that it has not been tampered with. (Anyone with a valid VeriSign signature key can sign their own code.) But Windows doesn't warn users if the signature does not verify; users have to manually check, and there's no automatic rejection of unsigned applications. Another security option allows users to block unsigned drivers from being installed in Windows. Microsoft controls the signing process for this system. The new security feature is an extension of this driver signing, so presumably Microsoft will control the signing process here as well.
This is probably a good idea, although it won't do much to improve Windows security overall. It's just too easy to sign bad code or to subvert signed code. Most ActiveX exploits, for example, don't involve explicitly evil code; they subvert vendor-supplied pre-installed signed code. And my guess is that most people will either turn it off or learn to automatically click "run it anyway." Preventing computers from executing every piece of code that comes across the Internet is probably a good thing; preventing them from executing *any* piece of code that comes from the Internet is not.
Well, not really. No one has broken the cryptographic algorithms that protect PGP traffic. No one has found a software flaw in the PGP program, allowing someone to read PGP-encrypted traffic. What someone did was to install a keyboard sniffer on a computer. That someone was then able to eavesdrop on every keystroke the user made: his PGP passphrase, the plaintext of messages he typed, everything.
The victim is an alleged mobster, Nicodemo S. Scarfo, who was using PGP to encrypt his e-mail messages. The attacker is the FBI, who ran a black-bag operation against Scarfo and installed the keyboard sniffer. But the principles surrounding this case could have profound effects on all of us.
There are lots of constitutional issues here. The FBI did obtain a warrant, but it is unclear if the warrant allowed this sort of surveillance. Scarfo's attorney certainly doesn't think so, and many civil rights groups agree. Lots of people are watching this case, which may force the courts to sort out some of these complicated issues.
My interest is more in the technical issues. The story graphically illustrates an important lesson of computer and network security: it's only as secure as the weakest link. PGP provides just one piece of an e-mail security solution. It protects messages in transit from the sender to the receiver. It protects against eavesdropping and impersonation attacks that happen during transit, in the network. PGP does not protect either endpoint. Keyboard sniffers can capture plaintext and passphrases. Trojan horses and viruses can send signed PGP traffic in the computer user's name. A clever attacker can even find printed copies of PGP-encrypted e-mail in the trash. Last year I cowrote a paper that described a social-engineering attack that could trick someone into decrypting his own PGP mail for an eavesdropper.
I worry that many cryptographers -- I have been as guilty as everyone else -- have lulled people into a false sense of security. We toss about phrases like "2048-bit RSA" and "trillions of years to break," and we believe them. Instead of building a defensive wall, we're planting a huge stake in the ground and hoping the attacker will only take the path that runs into the stake. We can argue about whether the stake should be a mile tall or a mile and a half tall, but the reality is that a smart attacker will simply go around the stake.
To be sure, cryptography is a good stake. It blocks the narrow gap where the attacker could easily pass through, protecting against non-invasive attacks. Attackers can still "go around" the stake, but by doing things such as breaking into Scarfo's home and installing the keyboard sniffer. Many attackers are not motivated enough -- or even capable of doing so.
There is another lesson we can learn from the story: in order to do its job, the police do not need any escrow techniques for cryptographic keys, nor laws to force people to reveal their passphrases or keys on demand. The lack of such things makes mass surveillance much more difficult, but effective law enforcement is clearly possible.
A final comment in the Philadelphia Inquirer story is quite telling: "Manno [Scarfo's attorney] would not discuss what his client was storing on the encrypted program but said Scarfo was using software known as PGP. 'It stands for Pretty Good Privacy,' the lawyer said with a chuckle." That chuckle might raise the hackles of your average cypherpunk, but you have to admit he's right.
The FBI application to the court is at:
The resulting court order is at:
My PGP attack paper:
Comments from Readers
Here in France (a technologically advanced country about 1/4 the population of the USA), we use paper ballots put into a transparent sealed box. Ballots are counted immediately after the vote by volunteers supervised by representatives of each candidate.
This century-old system seems to be equal or superior to any mechanized voting system I've heard of along each of your five dimensions. In particular, it scales well as the number of available (human) ballot counters is proportional to the number of voters. The time required to get the first, unchecked results is practically constant for all elections: local, regional or national. The delay for definitive, officially announced results grows logarithmically with the number of voters as partial counts are transmitted up a hierarchical structure, with additions and verifications at each node.
In a typical French presidential election, the media announce their first poll-based estimated results as soon as the voting booths close (they are not allowed to do it before). Estimates based on actual counting are published about two hours later, "official" preliminary results on the next morning, and final results after a week. I seriously doubt that any mechanized voting system would significantly reduce these figures. Nor would it offer any advantage in case of a particularly tight election requiring a second counting.
Voting machines were tested, a few decades ago, in some regions of France with a high fraud rate. The goal was to reduce fraud, not increase speed. As far as I know, these machines did not show any superiority of any kind over paper ballots, and are no longer used anywhere in the country.
You write: "in the rush to improve the first four attributes, accuracy has been sacrificed." Not only that, but it remains to be shown that any of the first four attributes were actually improved.
From: Louis Bertrand <louisbertrandtech.on.ca>
There is no improvement in the democratic process by counting the votes ever faster, only playing to the media's horse race mentality. All this technology aims to solve a non-existent problem.
Consider Canada's 100% manual system: pencils and hand-counted paper ballots. The polling stations are run by political appointees, but the catch is that appointees who work together must be from at least two different political parties. People simply put their differences aside, get some coffee and pizza, and count ballots all evening.
Canada's latest national election was counted in less than twelve hours after the polling stations closed, as was Ontario's round of municipal elections a few weeks before. Recounts? No problem. The ballots are available but there's fewer people to count them, so it takes about a week. That's still better than five weeks.
From: Daniel Balparda de Carvalho <danielatan.com.br>
Here in Brazil, voting is a duty. You *must* vote. Many citizens are also required to help in the elections. I have been for many elections called to help. Something like six years ago we had plain normal paper elections. Since then the system has been substituted by an electronic one. In our last elections (last October) we had an 100% electronic system. It worked perfectly and the results of the election were known in the same day. The system has been very very successful and I think we can be proud of it. If you don't mind me saying, the gross errors in the US elections have become quite a joke in Brazil.
How does it work? The machine is a tamperproof modified PC that the police delivers at the voting site. It has a display, a keypad with the numbers and three buttons, a mini printer, a 3.5 floppy drive and a remote module.
Before voting starts the machine prints a slip of paper showing its initial "internal state"; that is, the initial number of votes for all candidates. This is just to show that everyone has zero votes to start with. After this a small ballot box is attached to the machine. Every voter can see in the display the photograph of his candidate before confirming the vote so that misvotes are minimal. For every vote, the machine records the vote in its internal disk and drops a slip of paper into the ballot box. All the process of voting can be commanded by a small "remote control" that the machine has. Of course the controller can't see the vote, but he can see the status of the machine and he is the one that authorizes a valid voter so that he can use the machine. At the end of the election the ballot box is sealed, and the machine records the results on a 3.5 floppy that is also sealed. Then the machine prints several copies of the results for that machine. All of these are se
I have twice worked in an electronic election with these machines and I can say (as a person highly involved with security processes) that it is very well designed. I can't think of any obvious way to defraud the system. I have heard of no grave problem with this system and I am reasonably confident that it is a good system.
From: philipal.net (Phil Howard)
One idea is to go back to the traditionally hand marked paper ballot, but add an on-the-spot scanner to read it. The scanner will check for inconsistencies like voting twice in a one-vote office. It can also report how many offices recorded no vote at all. A more sophisticated scanner can measure the level of reading for each box marked and give an assessment of the accuracy of that read, and reject a ballot with marginal markings. The voter can read the screen and confirm that their votes are read properly, or see what mistakes are made, much like a digital system with data at 0 volts and 1 volt would reject levels between 0.3 volts and 0.7 volts as potentially ambiguous. The "error correction" would be to "resend" (re-mark the ballot or make a new one).
The scanner/computer would serve ONLY to test the ballots for accuracy of voting, AND (when a button is pressed to indicate acceptance) record the vote in the first round of counting. If this component fails, voting can still go on, with voters (and polling place workers assisting) checking their own ballots, and early totals being unavailable.
One thing we need to do in all this not only make a system WE know can be very accurate and incorruptible, but also make a system that actually appears to be accurate and probably incorruptible to the largest number of people.
From: "C.P. Crossno" <ccrossnoswbell.net>
Use lottery terminals. In general, when you make a whole lot of things they tend to work well and cost less. There are probably at least 50 times as many lottery ticket machines as there are voting machines and they work very well. Using the same technology as the lottery ticket machine, most of the dilemmas we have faced during the past few weeks could be avoided.
In Texas, the lottery cards have five columns and each column has 54 numbers. A total of 270 choices are available using just these five columns. To eliminate the need of a hand recount, the voter must mark three separate numbers for each candidate. A vote will be registered if two out of three of the numbers are marked (maybe one out of three in Palm Beach County). Each ballot will permit the selection of up to 90 candidates or issues, each with a triple redundancy.
Another benefit would be a fixed numbered set of ballots using very large numbers with random gaps for identification that would detect illegally printed ballots.
The lottery ticket machines (modified for voting) could even print a receipt showing the voter how his votes were registered.
From: Mark Seecof, <marksjural.com>
Respectfully, Ben Wright is wrong in his December Crypto-Gram letter. Part of the E-Sign law (Section 102(a)(2)(A)(ii)) forbids states to enforce technical standards for electronic signatures. This may be read as promoting technical "competition" (e.g., states can't require electronic sigs to use a specific vendor's implementation of RSA) but will have the effect of legitimizing completely worthless (e.g., checkbox on Web form) so-called e-signatures.
When you go to state court to deny some alleged signature and your experts testify that the technical basis of the alleged signature makes it impossible to authenticate, your opponent will whap you with the E-Sign law -- the state court is expressly forbidden to enforce any technical standard, so you must defend your case on other, fuzzier grounds.
From: "Bluefish (P.Magnusson)" <11agmx.net>
> And the question of retaliation: should you strike back
The story features Ira Winkler, "president of security consulting firm Internet Security Advisors Group in Severna Park, MD" who has a few interesting quotes. For example: "There's nothing wrong with doing a Traceroute [a tracking program] back to the IP address, so long as you alert the administrator...."
Ira seems to not be aware of the fact that traceroutes are perfectly normal tools, used commonly to track network faults. Why on earth would anyone even consider telling someone they were about to use it? It would be incredibly stupid to even try to log usage of traceroute.
Also: "When you detect an attack, dump all logs to read-only tape so you can prove that the data hasn't been tampered with."
Where do I get this Mission Impossible stuff that I can write to, but is read only, and at the same time verifies that what is written hasn't been tampered with? Seems like Ira has gone shopping in the same store where Mulder bought "copy protected" floppies for an X-Files movie.
From: "Penafiel, Cathy" <Cathy.Penafielcsoconline.com>
In my experience working on a large government contract, it is very difficult to get patches/tools into operational computer systems. By operational systems, I mean a collection of computing resources, hardware and software, which are dedicated to perform a mission. Our systems have real-time, near real-time, and/or rigorous production schedules. Collectively, our various facilities process thousands of megabytes of spacecraft and science telemetry on a daily basis.
In these environments, there is great reluctance on the part of administrators, developers, operations, and the government to perturb the operational systems. Any changes are rolled out with the greatest of caution, and for good reasons too. We have had instances where vendor patches have taken out critical mission capabilities which were not discovered until after the systems were delivered to operations. Although it was possible to recover before a spacecraft was put into safehold and science data lost, the resulting scramble was an unnecessarily gut-wrenching experience for all and resulted in a black mark for the contract from the customer.
As you so often point out in your essays and commentaries, there is no such thing as "perfect" security, either from a technical or an organizational perspective. Instead, we in the security business, either as engineers, consultants, or network/system administrators, are left to balance the various risk factors imposed by operating systems, networks, tools, applications, users, configuration management processes, etc. Judgment, experience, and an ability to articulate the tradeoffs/risks to the responsible manager (whether that manager be a civil servant or a CEO) are equally important in maintaining secure systems.
The window of exposure is a useful concept, difficult to meaningfully quantify. In general, organizations *should* run their operations so that the window of exposure is minimized, but it depends on what your organization's risk aversion is. Here, our customer is more averse to risks to operational spacecraft and science data production than to dangers posed by unknown marauders over the hill. In the real world of missions and systems, there is no silver bullet, as Mr. Ranum implies in his letter.
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 "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.