Ohio report is available

Ohio's secretary of state, Jennifer Brunner has commissioned a study that appears to be on the same order as California's top to bottom review of their voting systems. There are several reports available on the SoS web site. The most remarkable report is that of the academic team who analyzed the ES&S, Premier Elections Solutions, and Hart InterCivic voting systems. The academic report, produced by some of the leading computer security experts such a Matt Blaze, Harri Hursti, and Giovannie Vigna, and led by Patrick McDaniel of Penn State, is available here, on the SoS web site.

Quoting from the executive summary:

"All of the studied systems possess critical security failures that render their technical controls insufficient to guarantee a trustworthy election. While each system possessed unique limitations, they shared critical failures in design and implementation that lead to this conclusion:

• Insufficient Security - The systems uniformly failed to adequately address important threats against election data and processes. Central among these is a failure to adequately defend an election from insiders, to prevent virally infected software from compromising entire precincts and counties, and to ensure cast votes are appropriately protected and accurately counted.
  
• Improper Use or Implementation of Security Technology - A root cause of the failures present in the studied systems is the pervasive mis-application of security technology. Failure to follow standard and well-known practices for the use of cryptography, key and password management, and security hardware seriously undermine the protections provided. In several important cases, the misapplication of commonly accepted principles renders the security technology of no use whatsoever.
  
• Auditing - All of the systems exhibited a visible lack of trustworthy auditing capability. In all systems, the logs of election practices were commonly forgeable or erasable by the principals who they were intended to be monitoring. The impact of the lack of secure auditing is that it is difficult to know when an attack occurs, or to know how to isolate or recover from it when it is detected.
  
• Software Maintenance - The software maintenance practices of the studied systems are deeply flawed. This has led to fragile software in which exploitable crashes, lockups, and failures are com- mon in normal use. Such software instability is likely to increase over time, and may lead to highly insecure and unreliable elections."
  

and later in the executive summary:

"The review teams were able to subvert every voting system we were provided in ways that would often lead to undetectable manipulation of election results. We were able to develop this knowledge within a few weeks. However, most of the problems that we found could have been identified with only limited access to voting equipment. Thus, it is safe to assume that motivated attackers will quickly identify – or already have – these and many other issues in these systems. Any argument that suggests that the attacker will somehow be less capable or knowledgeable than the reviewer teams, or that they will not be able to reverse engineer the systems to expose security flaws is not grounded in fact."

The report is an incredible read. This group, in only a couple of months, managed to completely subvert these system and to expose them as woefully insecure and inadequate for the real world. Secretary Brunner, to her credit, has now recommended the elimination of DREs in polling places in her state. Now if only other states will follow her lead and that of Debra Bowen, SoS of California.

Does your home address begin with a '5'?

Tuesday was not a national election, and there was no election in Baltimore County, where I live, but there were local elections in many places across the country. This Washington Post story describes some problems in a local election in Maryland.

"Rockville's voting was complicated by a glitch. Thousands of residents who had not yet voted were mistakenly listed as having already cast absentee ballots because of a state database problem ... The state's [voter registration] list inadvertently marked as absentee the names of voters with a home address that begins with the number 5."

My home street address is actually 5, so I might have been affected by this, if we had had an election this week.

While this is an inexcusable occurrence, it is not really that surprising. The greater the complexity in a system, the more likely it is that unexpected glitches such as this will occur. I don't know if this was a software error, a programming error, a configuration error, human error, or something else. And the point is that it does not really matter. Complex software-based systems, especially ones developed the way voting machines today are built and tested, are likely to result in unforeseen problems. In the 2006 primary in Rockville, there were even worse problems with the electronic poll books. In 2008, the problem will probably be something new.

What worries me are not only the problems that we can observe, such as the ones last year and this week. I'm worried about the problems that might result in the wrong votes being totaled, without us ever knowing it. It is foolish to think that only really obvious errors will occur. Maryland's voting system, using only DREs statewide, is vulnerable to catastrophic error but also undetectable errors. And, although the state passed a measure to move to optical scanners in 2010, it now appears that the funding for this move may not be available.

A case of the wrong technology applied incorrectly

In this week's Economist magazine, an article describes how the Swiss general election that was held on October 21 was to use quantum cryptography to protect the transmission of votes from the polling stations to the central tabulation centers. Quoting from the article:

The authorities will use quantum cryptography—a way to transmit information that detects eavesdroppers and errors almost immediately—to ensure not only that votes are kept secret but also that they are all counted.

I first became aware of this project when a New Scientist reporter sent me a note about it and asked for my opinion. I assumed that it was a joke or that the reporter had heard wrong. After all, protecting electronic transmissions is the one problem I can think of in all of this that is not really hard. Here are some of the problems in electronic voting that are hard:

• Ensuring that the software on the voting machines is the correct software. The proposed solution of having a library of hash values of the correct binaries of voting machine software and checking the voting machines does not work. There is no way to perform the check of the hash of the code that is running in the machines. In fact, any attempt to check that hash value would provide an opportunity for an attacker to change the code then and there.
  
  
• Ensuring that the software on the voting machines is not malicious.Even if the "correct" code is running on the voting machine, there is no deterministic way to determine that the code was not designed with a back door in it that could affect the outcome of the election.
  
  
• Ensuring that no unknown bugs in the voting machines can affect the outcome.Even if the "correct" code is running on the voting machine and even if there is no intentional malicious code in the machine, there is no way to ensure that the code does not contain inadvertent bugs or unexpected failure modes that could disrupt an election or cause the wrong result to be computed.
  

Quantum cryptography is a novel and very interesting topic. There are potentially many applications that could benefit from this technology, and I have always been a big fan. But, quantum cryptography does not address the problems in electronic voting that are actually difficult to solve. Transmitting the votes from the polls to the central tabulation center can be done with traditional cryptography. Authentication functions can provide tamper resistance and encryption can provide secrecy, assuming that secrecy is actually desirable here. I believe it is not, as every aspect of the process should be transparent, and I see no reason to keep the precinct results secret. Just the opposite is true - it is important for observers to see princinct level results.

I applaud the Swiss for pursuing innovation, but in this case, they are using the wrong tool to solve the wrong problem in an inappropriate way.

Holt's H.R. 811 is finally coming up for a vote

Congressman Rush Holt's bill requiring a voter verified paper trail is scheduled to come up for a vote tomorrow. I've been traveling out of town, and I just returned home this evening (to an overflowing inbox about this issue). I was planning on writing up my thoughts about H.R. 811, but I just noticed that Ed Felten did a great job of writing his up on his blog. I pretty much agree with everything he said, so no need to repeat it here.

I support Holt's bill. I know that many activists, including several who have contacted me today, are opposed to this bill because it does not entirely ban DREs. However, at the moment, I believe that we need this bill to pass. It would outlaw the voting systems used in places like Maryland and Georgia and, I believe, 13 other states that have entirely paperless voting.

What's sorely lacking right now are paper trails and mandatory audits. Holt provides these. I do hold out hope that some day we will be able to utilize the added benefits of end to end cryptographic systems. But right now, the Holt bill is the best measure I can foresee to have a realistic chance of eliminating the paperless DREs that I may have to vote on next November 4th.

Avi

The Virus Did It

I attended Crypto in Santa Barbara this past week, and I was talking to a colleague of mine from another university. He had served as an expert witness in an interesting case involving a man who had been accused of having illegal pornographic images on his computer. His defense was that his computer had been infected with a malware virus and that "the virus did it." This may seem a little far fetched. However, my friend is a top security expert, and he had disassembled and reverse engineered the virus code, and he showed that indeed the virus was designed to download pornographic images from the Web.

The "virus did it" defense is likely to become more popular as increasingly nefarious online activity is uncovered. In a society where you are innocent until proven guilty, the possibility that a virus performed a malicious action from someone's computer, and that the person was not aware of this, may be enough to provide plausible deniability of almost anything.

Consider the implications of this for electronic voting machines. While the Princeton team showed how a malicious virus could copy itself to infect a precinct full of voting machines, and whereas the California top to bottom review team showed how even a single infected voting machine or memory card can compromise a back end tabulating system, in light of "the virus did it" phenomenon, the attacker's job in disrupting an election is even simpler. All an attacker has to do is leave evidence that casts suspicion that there may have been a virus. If an election audit reveals signs of a possible virus, the results are thrown into doubt, and a losing candidate has a legitimate claim that a virus may have tampered with the results.

The evidence of a possible virus can be created anytime prior to the audit, even after the election is complete. In a computerized system such as a paperless DRE, it is much easier to concoct false evidence that raises suspicion than it is in a paper ballot or end to end cryptographic system.

To visualize how scary this could be, let's take the example of Sarasota County, Florida in the 2006 election. Congressional District 13 was an extremely close race with the strange anomaly that an abnormally high number of undervotes were found in an important race. Several studies and audits were conducted, but the reason for the problem has never been conclusively determined. Now, imagine if an audit had turned up virus code on some of the voting machines. Even if no virus had ever executed or propagated, the mere existence of such code would have created chaos. Taking this idea a step further, imagine if such evidence were found in the Virginia Senate race in 2006. This extremely close race singlehandedly determined the party majority in the Senate.

When defending the use of DREs, vendors and some election officials argue that it would be very difficult to tamper with a voting machine in an undetectable way to change the outcome of the election. While I disagree with this statement, the truth is that it grossly overestimates the job of the attacker. All an attacker has to do is to create the impression that something went very wrong. The losing candidate will do the rest.

If in a future election we begin to suspect that "the virus did it," things are going to get very ugly.

Why nobody wants to buy Diebold Election Systems

In an Associated Press story today, Diebold confirms that they tried and failed to sell their voting technologies business. Given the recent reports in California and Florida, I imagine it will be even harder for them now. I think people, even within Diebold, are coming to the realization that DREs are the wrong model for voting systems. There are several reasons for this.

1. DREs are too complex. There are typically 50,000+ lines of code in a DRE, much of that involves user interface and audio capability, and providing the DRE interface and user experience is not worth the hit in complexity.
   
   
2. DREs serve as a bottleneck on election day. DREs are expensive, and so it is unlikely that precincts will have more than they need. Since voters typically spend several minutes voting, and I've observed as a poll worker that quite a few voters take more than 10 minutes, the potential for long lines is tremendous. Once a backlog of voters is created, it only gets worse, as the effect propagates much like the airline systems gets backed up in a positive feedback loop of delays once some flights are late.
   
   
3. DREs are non-transparent. The public justifiably does not trust them. They cannot be independently audited, despite the vendor's insincere claims to the contrary. Even DREs with a VVPAT cannot be properly audited because they just don't work as we would hope. Voters often do not check the paper. The paper rolls used by most vendors do not lend themselves to easy recounts, and the retrofitting of DREs with VVPAT has led to awkward and sometimes ill defined procedures, especially when a voter disputes the printout.
   
   
4. Finally, a much better model for voting systems exists, namely, paper ballots with optical scan precinct counting and ballot marking machines for disability access.
   

So, it is no surprise that Diebold can't sell their voting business. They'd be as likely to sell 8 track players instead of ipods.

Secretary Bowen's clever insight

On Monday, our NSF ACCURATE center held its second annual EVT conference. It was a smashing success with packed attendance and great papers. Today, we held our Principal Investigator (PI) meeting consisting of the PIs, graduate students and some of our advisors. To all of our amazement, Debra Bowen, the Secretary of State of California, who is on our advisory board, showed up for both days. This is particularly incredible given that last Friday she created a firestorm by decertifying most of the electronic voting machines in her state after the top to bottom review that she ordered showed tremendous flaws in the machines.

Secretary Bowen was an active participant in both our workshop and our PI meeting. Today on a panel of our advisors, she said something that really struck a chord with me. It was a simple comment, but it showed great insight into the computer software process as well as the election system certification process. Bowen's observation was that the certification process is not well suited to software. Most election officials defer to staffers or to academics such as us about technical issues, but Secretary Bowen sounded as much like a computer scientists as a state official this afternoon. She rattled off technical terms that she was completely comfortable with and made arguments based on a level of understanding of technology that I have never seen from a non-computer scientist. It is no wonder that she was able to put together the team led by David Wagner and Matt Bishop to study the machines and to appreciate their findings.

Back to Bowen's comment about software not being suitable for the way election equipment is certified. It is right on the mark. The current certification process may have been appropriate when a 900 lb lever voting machine was deployed. The machine could be tested every which way, and if it met the criteria, it could be certified because it was not likely to change. But software is different. The software lifecycle is dynamic. As an example, look at the way Apple distributes releases of the iPhone software. The first release was 1.0.0. Two minor version numbers. When the first serious flaw was discovered, they issued a patch and called it version 1.0.1. Apple knew that there would be many minor and some major releases because that is the nature of software. It's how the entire software industry operates.

So, you cannot certify an electronic voting machine the way you certify a lever machine. Once the voting machine goes through a lengthy and expensive certification process, any change to the software requires that it be certified all over again. What if a vulnerability is discovered a week before an election? What about a month before the election, or a week after it passes certification? Now the point is that we absolutely expect that vulnerabilities will be discovered all the time. That would be the case even if the vendors had a clue about security. Microsoft, which arguably has some of the best security specialists, processes and development techniques issues security patches all the time.

Software is designed to be upgraded, and patch management systems are the norm. A certification system that requires freezing a version in stone is doomed to failure because of the inherent nature of software. Since we cannot change the nature of software, the certification process for voting machines needs to be radically revamped. The dependence on software needs to be eliminated.

California source code study results

The source code team reports for the California Top to Bottom review of Diebold, Hart and Sequoia's voting systems are now online. These reports are comprehensive and detailed and should mark the end of the use of these voting machines in public elections. From the executive summaries:

Diebold
Our analysis shows that the technological controls in the Diebold software do not provide sufficient security to guarantee a trustworthy election. The software contains serious design flaws that have led directly to specific vulnerabilities that attackers could exploit to affect election outcomes.

Hart
Many of these attacks can be mounted in a manner that makes them extremely hard to detect and correct. We expect that many of them could be carried out in the field by a single individual, without extensive effort, and without long-term access to the equipment.

Sequoia
We found significant security weaknesses throughout the Sequoia system. The nature of these weaknesses raises serious questions as to whether the Sequoia software can be relied upon to protect the integrity of elections. Every software mechanism for transmitting election results and every software mechanism for updating software lacks reliable measures to detect or prevent tampering.

I am most familiar with the Diebold system, and one thing that stands out is how every time there is another study of the Diebold code, more security problems come to light. Here are a few issues that this report identified:

The audit log does not adequately detect malicious tampering.

Buffer overflows in unchecked string operations allow arbitrary code execution.

Integer overflows in the vote counters are unchecked.

Multiple buffer overflows in .ins file handling allow arbitrary code execution on startup.

Setting a jumper on the motherboard enables a bootloader menu that allows the user to extract
or tamper with the contents of the internal flash memory.

Keys used to secure smart cards and election data are not adequately protected.

The machine does not adequately protect the supervisor PIN. (This same problem was identified in this week's Florida report)

Votes can be swapped or neutralized by modifying the defined candidate voting coordinates
stored on the memory card.

OpenSSL is not initialized with adequate entropy

...

And the list goes on. Dozens of such vulnerabilities are identified; I just picked a few at random from the list. This is the code that Diebold produced after they claimed to have fixed the vulnerabilities we found in 2003 and that Ed Felten's group identified last year. The backend GEMS system has its own serious problems as well. It is clear that they are simply not qualified to build these kinds of machines.

As I read the three new reports, I could not help but marvel at the fact that so many places in the US are using these machines. When it comes to perscription medications, we perform extensive tests before drugs hit the market. When it comes to aviation, planes are held to standards and tested before people fly on them. But, it seems that the voting machines we are using are even more poorly designed and poorly implemented than I had realized.

The more these machines are studied, the worse they look.

Florida SAIT report highlights more Diebold problems

The Florida Secretary of State has just released a report from the Security and Assurance in Information Technology Laboratory (SAIT) at Florida State University titled "Software Review and Security Analysis of the Diebold Voting Machine Software". This report is the output of a study that Florida commissioned to determine whether flaws reported in previous studies of voting systems, including my group's study, had been fixed yet. I was a reviewer of this report, and my graduate student, Ryan Gardner, played a key role in the study. The group was led by Alec Yasinsac who led the previous FSU study on voting machine security for Florida.

I am pleased to see that there are so many studies of voting systems being performed. In this past year, Connecticut, California, and now Florida have conducted thorough reviews, and all of them have highlighted serious problems with the voting systems. All this is happening as the House is considering federal legislation to improve the auditability of voting equipment.

Once again this new report shows serious, serious problems with Diebold, and that they clearly have not fixed some of the most egregious problems. One of the weaknesses that our report in 2003 pointed out was that Diebold used a single, fixed encryption key for all encryption in the system. Diebold has moved from using DES to AES. However, the key management is just as bad as before, and possibly worse. Here is an excerpt from the new report released today.

The system key is generated by computing an MD5 hash of the machine serial number. Its value is never changed after generation. Since the machine serial number is public, the system key is also essentially public. Anyone who knows this procedure can generate the system key and can access anything it protects, including the data encryption key and anything that it is used to encrypt.

This is arguably worse than having a fixed static key in all of the machines. Because with knowledge of the machine's serial number, anyone can calculate all of the secret keys. Whereas before, someone would have needed access to the source code or the binary in the machine.

Other attacks mentioned in the report include swapping two candidate vote counters and many other vote switching attacks. The supervisor PIN is protected with weak cryptography, and once again Diebold has shown that they do not have even a basic understanding of how to apply cryptographic mechanisms. Quoting once again:

The supervisor PIN is now stored on supervisor smart cards as a keyed hash of the actual PIN. Specifically, the PIN is concatenated with part of the data encryption key (the first 64 bits), and an MD5 sum is computed over the resulting string. The first 4 bytes of the MD5 are stored on the smart card. The most significant weakness of this approach again concerns the key management of the data encryption key as described in Section 3.7.1.1. The key can be compromised by an adversary with sufficient access to a voting terminal, and an adversary with it can find the PIN using a simple brute force computation. Again, the act of using the same key for more than one purpose is generally considered poor practice within the cryptographic community. Moreover, the input to the hash function is 64 bits of the 128-bit data encryption key. Using only 64 bits of the 128-bit AES key in this manner may allow an adversary to recover the data encryption key significantly faster than exhaustive search.

So, Diebold is doing some things better than they did before when they had absolutely no security, but they have yet to do them right. Anyone taking any of our cryptography classes at Johns Hopkins, for example, would do a better job applying cryptography. If you read the SAIT report, this theme repeats throughout.

In my opinion, in his letter to Diebold the Secretary of State of Florida, Kurt Browning downplays the severity of this report.

A toast to Peter Honeyman

My former Ph.D. advisor, Peter Honeyman won the prestigious Lifetime Achievement Award from the USENIX Association. I first heard about this from Matt Blaze of the USENIX board and a former colleague of mine at AT&T, and I was absolutely thrilled. I can think of nobody more deserving. As the recipient of his mentorship, I am delighted that he was called out for his role mentoring students for this honor. From the USENIX web site:

Dr. Peter Honeyman has had a profound and lasting impact on the field of computer science. While many know Peter for his seminal contributions to computing systems, such as Honey DanBer UUCP and Disconnected AFS, it is his efforts as a mentor that we wish to honor with the USENIX Lifetime Achievement Award. Peter's often highly unconventional stewardship of the countless students, researchers, and advisees he has touched is the stuff of graduate student legend. His penetratingly insightful (and potentially hazardous) questions and comments, combined with a paradoxically unflinching loyalty, consistently have led those under his tutelage to the pinnacle of achievement in security, systems, and networking. Peter's questioning during conferences and doctoral defenses, although sometimes frightening, always demanded better from those of us who attempt to advance science.

Peter has a page with some pictures of the event. I was unable to attend the ceremony when he received his award because I was on vacation with my family in Israel, but I made a video tribute for him that was shown at the conference.

Debunking the "laboratory" defense

Yesterday, there was a hearing in California about the e-voting machines that were studied in the top to bottom review. I watched some of the proceedings that were broadcast on the web, and I read some of the press coverage, such as this article in the San Jose Mercury News. I'm struck (although not surprised) by the way the vendors attack the study results. As the top to bottom review concluded that the systems were highly vulnerable to all kinds of attacks, the vendors stand to lose business and revenue if the machines are decertified, so you would expect them to attack the study with everything they have.

Reading the news coverage of the hearing, it is clear that there is a common theme in the attacks on the study. Quoting the article:

Sequoia Voting Systems, which is used in Alameda, Santa Clara and Santa Cruz counties, called the review an "unrealistic, worst-case scenario" performed in a laboratory environment by computer security experts with unfettered access to the machines.

Several other people use the term "laboratory environment" in criticizing the study. I think these criticisms miss the point. Most, if not all of the vulnerabilities identified in the studies are weaknesses that are well known in the security literature and which can be avoided with proper design and implementation. The source code reviews have not been published yet, so I cannot comment on what was found there, but looking at the red team reviews, I can say that we know how to design systems that avoid the problems that were found there. So, regardless of whether these were broken in a laboratory or in a polling station, the fact is that vendors are not utilizing well-known security technology in designing their systems.

Rather than using technology provided by incompetent vendors who don't bother to hire real security experts to build voting systems, we should insist that these machines be scrapped. The debate should focus on whether or not the machines utilize the best available security, rather than on whether the proof that they are insecure was identified in a lab or somewhere else. If the vendors focused as many resources on improving the security of their systems as they do in criticizing the studies, then they wouldn't have to point out that the studies were done in a laboratory because studies that embarrass them would be less likely to exist.

More on California Top to Bottom

I should point out that only the red team reports have been released so far. (As the SoS web site states, "The document review teams and source code review teams submitted their reports on schedule. Their reports will be posted as soon as the Secretary of State ensures the reports do not inadvertently disclose security-sensitive information.") The red teams are groups of talented white hat hackers who approach the system as though they were mailicious parties looking to disrupt the election. These reports do not take into account flaws in the source code. The source code analysis reports, which are akin to the study that my research team performed in 2003 about Diebold, will be very revealing because they will shed light on how Diebold responded to the flaws that we found four years ago. Considering that I had two (very talented) graduated students looking at the code for about a week, I fully expect that this team of professionals who spent a month will uncover much more serious problems.

It's important to keep in mind, as the California report states, that any security problems reported by them constitute a lower bound on the problems that exist. The reason is that they were limited in both time and in the information available to them. Some of the material they needed was given to them only a couple of weeks before their final deadline. Furthermore, in a real world scenario, hackers would not have a month to do the analysis and produce a report. They would probably skip the report and could spend many months developing their attacks.

California Top to Bottom results

The Secretary of State of California, Debra Bowen has released the results of their top to bottom review of the Sequoia, Diebold, and Hart voting systems. This is perhaps the most anticipated voting system analysis ever. I just read the executive summary of the report, and the results are devastating for these machines. In all cases, the analysts were able to rewrite the firmware on the machines. This means that an attacker could change every aspect of the behavior of the voting systems. In a sense, these voting machines provide no protection against the most basic attack, which is the complete an unobservable reprogramming of the all the functionality of the voting machines.

One of the attacks against Sequoia that got my attention was that the team was able to determine when the machine was in test mode and thus could cheat but behave correctly whenever the machine was not in a real election. This undermines the common argument made by some that the machines are tested extensively. The analysts were able to defeat the physical security, bypassing the seals, on Sequoia and on Diebold. This undermines another argument often made by supporters of the machines that nobody could have undetectable access to the machines.

There are many other examples of attack that are much more serious than what I expected from this report - and I was expecting a lot. I don't see how anybody can possible condone continuing to use these e-voting machines, given the results that are summarized in the executive summary of the report. I will now read the detailed reports, and if I have anything more to say, I'll blog again over the weekend.

What is really disturbing is that these tests are taking place after the machines have been certified and deployed. This kind of top to bottom testing should be done before any voters actually vote on them.

ISE researchers find serious security vulnerabilities in iPhone

The day after the iPhone was released, I purchased mine and blogged about it here. Although I still love my iPhone for its beautiful interface, well thought out features, and incredible screen, I'm now disappointed that it was not built more securely.

Researchers at my consulting company, Independent Security Evaluators (ISE) have found serious security vulnerabilities in the iPhone. They were able to take complete control of the iPhone device and run arbitrary shell code (see NYT article). To demonstrate this, they built an exploit that downloads personal information such as SMS text transcripts, address book entries, and email from the iPhone whenever a user visits a particular web site or connects to a particular WiFi network. However, the vulnerability can be exploited in many other ways. For example, an exploit could be written that would cause the iPhone to make an unnoticeable phone call to an attacker, who would then be able to monitor conversations by the victim. In other words, the iPhone could be turned into a bugging device.

We contacted Apple on July 17 and sent them all of the details of the vulnerability. We also promised not to release any specific technical details of the vulnerability that would allow someone else to exploit it until our Black Hat presentation on August 2. This gave them plenty of time to produce a fix, and we showed Apple how to patch the vulnerability.

However, we are disclosing the fact that the iPhone is vulnerable. Why are we doing that? Well, I believe that there is a social responsibility to report it when a device is vulnerable to attackers. People buy these things and use them in ways that put their identity and their online accounts at risk, and by exposing these vulnerabilities, we can make users better judges of how to use their high tech devices. In addition, vendors are much more likely to produce devices that are more secure if they know that independent security experts such as my team at ISE are likely to try to break them and to expose any vulnerabilities we find. Just look at the history of Microsoft's software security problems. They started paying attention when they were repeatedly embarrassed by the exposure of vulnerabilities. Now they put more effort into writing secure code than almost anyone.

EVT 2007

Our NSF sponsored center, ACCURATE is putting on its second Electronic Voting Technology workshop (EVT '07) on August 6, 2007 in Boston. The program chairs are David Wagner and Ray Martinez, and they have put together a fantastic program. I encourage everyone who can to attend.

Report from Blue Ribbon Panel in Riverside County, California

A report has been released by a Blue Ribbon Panel that was appointed by the Board of Supervisors of Riverside County in California. The panel held several public hearings, meetings with the registrar of voters, a meeting with the Board of Supervisors, three group study and writing meetings, and a presentation by Sequoia Services, the vendor of the DRE with VVPAT that is used in Riverside county.

I found the report to be extremely well thought out and well written. The panel was clearly open minded and considered all of the post 2006 election data and observations. The top conclusion of the panel was:

"Move as quickly as possible to a hybrid voting system whereby able-bodied voters make their preferences on paper ballots which are then counted by optical scanners."

The report details shortcomings and failures in the Sequoia Edge system used in 2006, and explains why the hybrid system would overcome these. I believe that this report, along with the top to bottom review that Secretary of State Bowen is conducting will result in California moving to much more secure, reliable, auditable and transparent election systems. According to this report, the hybrid systems will also result in faster results and less waiting time at the polls.

Giving into the force

After reading endless articles and reviews of the iPhone, I decided that the slow Edge network from AT&T was a non-starter and that I was not going to get an iPhone. Many of my friends were surprised, as I am usually very excited about new gadgets. I was always on the waiting list for the newest Treo, and given what a Mac fanatic I am, an iPhone seemed like a no brainer.

This past week, old friends came out of the woodwork to ask me when I was getting my iPhone and if I was planning on sleeping in line. It was a big topic of conversation at work. I replied that I was going to be patient, and that I thought the drawbacks were serious, so I was not going to do it.

Well, this weekend was Ann's birthday, and I took her to NYC to a couple of Broadway shows while our babysitter stayed home with the kids. (After our 2 week vacation in Israel, a break from the little ones was necessary for our sanity anyway.) On Friday night, the Apple stores opened their doors to the masses for iPhones sales, and all of the major media covered it. Enthusiastic early adopters who waited in line for several days were shown on TV walking out with their new iPhones to massive applause. We watched from our hotel in the city on CNN. Our hotel was several blocks from the Apple store, and on Saturday morning, I was so drawn to it that Ann and I decided to go our separate ways for a few hours. She went shopping for shoes at Macy's, and I walked to the Apple store. It was really quite a sight. I found a table with an iPhone and played with it for about 5 minutes. My heart was racing as I began observing all of the features and the interface first hand. I was soon in line to buy my own without really understanding why. I had decided earlier that I was going to wait until the next version of the phone came out with fewer bugs and hopefully a faster network. After all, it wouldn't kill me to wait a few months. I've been fine with my Treo.

As I walked back to the hotel with my new iPhone bag, people on the street stopped me to talk and ask me if I really had an iPhone in there. Several made me pull out the box and show it to them. In the elevator in the hotel, people asked me about it. By the time I met up with Ann, I had already connected it to my laptop and downloaded a new version of iTunes to my computer that supported the phone. At breakfast this morning, I was playing with it, and the people at the table next to me started asking me about it. I decided that one of the undocumented features of this phone is that it makes people friendly.

Anyway, my Treo 750 that I used to love so much is now a paper weight. Yes, the iPhone has some serious drawbacks, but my love affair with it has begun, and when I leave it in the other room for a few minutes, I already miss it.

David Dill's excellent essay on the Holt Bill

David Dill of Stanford, Verified Voting, and ACCURATE has written a terriffic essay on the Holt Bill. I'm posting it here in its entirety:

IT'S TIME TO OUTLAW PAPERLESS ELECTRONIC VOTING IN THE U.S.
by
David L. Dill
VerifiedVoting.org

Four years ago, when I began publicly opposing paperless electronic
voting, passing a Federal law to require voter-verified paper records
(VVPRs) seemed an impossible dream. Rep. Rush Holt introduced such
a bill in 2003, and another in 2005, but both bills languished in
committee until the clock ran out.

The dream is now achievable, due in part to the unending stream of
problems caused by paperless voting machines in recent years. HR
811, the third incarnation of the Holt bill, is a critical measure
needed to protect the integrity of our elections, and it now has very
good prospects of being enacted. It already has 210 co-sponsors in
the House, where only 218 votes are required to pass it.

There are two provisions in HR 811 that are especially vital for
restoring trust in American elections: A nationwide requirement for
voter-verified paper records, and stringent random manual counts of
those records, to make sure they agree with the announced vote
totals. The requirements in the Holt bill are superior to those in
almostevery state of the country (there are now 22 states with
significant amounts of paperless electronic voting, and only 13
states require random audits of VVPRs).

Success is not assured, however. The forces that have blocked
previous bills are still active, especially vendors of current poorly
performing equipment. Also, various concerns, reasonable and
otherwise, have been raised about the bill by other parties.

Some groups insist on optical scan machines, which read and count hand-marked paper ballots, and are not supporting HR 811 because it still allows the use of touch-screen machines. However, under HR 811, those machines must be equipped with so-called voter-verifiable paper trails, which print a paper copy of the vote that can be reviewed by the voter before being cast. Most of the current generation of inferior paper-trail machines would not be allowed under HR 811, which requires the machines to preserve the privacy of voters and requires the VVPRs to be printed on high-quality paper. This will create a strong incentive for local jurisdictions to purchase optical scan equipment. Furthermore, HR 811 makes the paper records the official ballots of record in audits and recounts, and requires election officials to post a notice explaining to voters the need to verify their VVPRs.

I would personally prefer to see optical scan machines be used
nationwide, if supplemented by equipment to allow voters with
disabilities to vote privately. If groups objecting to HR 811 can
cause such a bill to be introduced and line up the votes in Congress
to get it passed, that bill will have my support. Meanwhile, those of
us who have actually talked to Congressional staff have not seen any
significant support for such a requirement. It seems that we have a
choice between HR 811 or continuation of our current "Kafka-esque"
paperless system (as a French politician recently described it).

Another small but noisy contingent is opposing HR 811, sometimes
without revealing their true agenda, because they will be satisfied
only with a nationwide system of hand-counted paper ballots. In
theory, we could adopt hand-counting of all ballots. However, hand
counting is rarely used now. It is politically unrealistic to believe
that the overwhelming number of jurisdictions that have been using
automated voting in various forms for 40 years or more are going to
go back to hand counting. HR 811 does not prevent hand counting
for those communities who want to do it, but it provides a realistic
solution for the rest of us.

Some are troubled by the role of the Federal Elections Assistance
Commission (EAC) under the bill. Like many others, I, too, lack
confidence in the EAC as currently configured. But HR 811 gives only
minimal responsibilities to the EAC. I can live with that if the
other provisions of the bill are enacted.

Finally, election officials have expressed concern over whether the
timeframe of HR 811 is feasible. On the one hand, I want passionately
to avoid potential meltdowns in the 2008 general election, and I am
not convinced that the possibility of simply purchasing optical scan
equipment has been adequately considered by those jurisdictions
currently using paperless electronic voting. On the other hand, it is
obviously necessary to allow adequate time for implementation of the
bill. Congress has heard all sides of this argument, and I am
confident that they will strike the right balance. If the
implementation date needs to be extended, I hope it will be done in a
way to encourage earliest possible elimination of paperless electronic
voting, so that the maximum number of voters will be protected in
2008.

HR 811 will no doubt change as it travels down the long, winding
legislative road. With some luck, the bill will survive with
the key provisions intact, and may even improve.

A good bill that becomes law is better than a great bill that doesn't.
HR 811 will start moving soon. Please ask your U.S. Representative to
support it.

Paper ballot bill passes Maryland House

I have not seen any press reports about it yet, but according to a source of mine, yesterday, the Maryland House passed an enhanced version of the bill that passed the Maryland Senate last week. The bill requires paper ballots with in-precinct optical scan counting. Some provisions were added addressing disability access. The implementation of audit is left to the board of elections. I have not seen the final bill yet, but if this is all true, then it is a positive step. Now we need some proper audit requirements and for the governor to sign this bill and Maryland will switch from having one of the worst voting systems in the country to having one of the best. The transition to optical scan will happen by the 2010 election. I think it's a shame not to do this by 2008, but on balance, I will take it, considering that without this bill, we'd probably continue using DREs for a long time.

More information on SB392

I have obtained a copy of Senate Bill 392 which I am told passed the Maryland Senate today. I read through it, and I have mixed feelings. On the one hand, it definitely requires paper ballots and optical scanners by 2010. While I would strongly prefer 2008, at this point, I will take a guarantee that we will have this technology by 2010. However, what troubles me is that the required manual randam audit text has been removed from the original bill. While this new system will have audit capability, it is critical that audits be required and random. Hopefully, this can be fixed after the fact. For now, I still view this development as a minor victory.

Good news from Maryland

What a sudden turnaround. The Maryland Senate just passed a paper ballot bill. I have heard from several people (including a comment posted on my previous blog entry) and one reporter, but I have not yet tracked down the text of the new bill. What I hear is that it will require paper ballots with optical scan and accessible ballot marking of paper ballots for disabled voters. I also have it on pretty good authority that there will be an effort within the Maryland House to pass the exact same bill.

The Senate bill passed unanymously! This is absolutely thrilling news.

I will post more once I track down the actual bill that passed and have a chance to read it.

What a great day for Maryland.

Disappointment in Maryland

I'm away with my family in Tennessee for Passover, but I wanted to take a moment to go online and update my readers about Maryland. Unfortunately, once again the state senate did not pass legislation that would have provided for a paper ballot for every voter in the state. I'm not sure why this happened because there seemed to be a uniform support for this bill in the committee when I testified in the senate hearing a few weeks ago. This will set Maryland back in the quest for verifiable and auditable elections. A huge disappointment.

See you in ten

I have decided to leave computer science and to leave civilization and to go live in the woods. I have been ignoring nature for too long, and I would rather hang out with trees and rivers than with computers. You will no longer be able to reach me by email or fax, but if you put a message in a bottle and drop it off in a mountain river stream, I might get it. Take care everyone. I will return in 10 years and blog about my experience.

Shmoocon

I gave the keynote address at the Shmoocon Conference in Washington DC this evening. I promised the audience that I would post my slides here on my blog. Click here to download them.

Encrypting hard drives from Seagate

This week, Seagate technology made headlines with their announcement of a new encrypting hard drive. The idea is that the hard drive will automatically encrypt and decrypt data so that it will always be stored encrypted. That way if a laptop with this hard disk is lost or stolen, the data will not be accessible to an attacker. I performed a search on this story on google news today and came up with over 250 articles covering this announcement.

I think that the drive is an appropriate choice for where to encrypt data, but the limitations of this approach should be addressed, and none of the news stories that I read mentioned the shortcomings of drive-level encryption. On the positive side, data in this scheme is encrypted on the fly so that users and applications do not need to participate in the encryption - it is entirely transparent. A raw hard drive physically extracted from a laptop provides no data to an attacker, assuming a proper encryption key is used. This provides protection for the data at rest, when nobody is using the computer, and no user is logged in.

However, an encrypted drive does not guarantee that attackers can never access the data on the disk. To function properly, the system must allow access to legitimate users. This access must be simple and transparent. My expectation is that the user login password will be used to derive the encryption keys that protect the data on the drive. But, regardless of the scheme used to obtain the key, when a user is active on the machine, the keys must be available to the hard drive so that data can be encrypted and decrypted in the course of normal use. At that time, the data is just as available to malicious code in the form of spyware, Trojan horses and viruses as it is to the legitimate user. If the system is designed well, then the keys will be erased whenever a user logs out. Another problem with login keys to encrypt the drives is that user-level keys are frequently susceptible to dictionary attacks.

I'm not certain, though, that user-level keying makes sense for a drive-level encryption scheme. Drives contain all kinds of data, including system data, and data from many different users. At the disk drive level, there is no notion of a user, just data blocks. So, it would be awkward to use login keys to encrypt the drive. How would system files be decrypted? In fact, all kinds of file system information, such as file permissions, are not supposed to be known at the disk drive level. So, my feeling is that there is not an intuitive key management scheme for the Seagate hard drives. I'd be curious to know what they are doing in that regard. Encryption is great, but without proper key management, its benefits are questionable.

I applaud Seagate for pushing the envelope and encrypting at the drive level. Such a move by the leading manufacturer of disks can only be good news for those concerned about security. But, I caution users not to blindly trust that their data is no longer susceptible to theft. As long as users can access their data, so can attackers, and the security of the data on a lost laptop is to a large extent dependent on what Seagate did for key management - a difficult problem that is often left unsolved.

The FSU report on the ES&S iVotronic used in Sarasota County

On February 23, a team of computer scientists, based out of Florida State University put out an exceptional report analyzing the ES&S iVotronic 8.0.1.2 voting machine firmware. The reason that this particular machine was of interest is that it was used in the 13th Congressional race in Sarasota County last November. As many of you know, this is the machine that was responsible for approximately 18,000 undervotes in that race. The research team was chartered with the task of attempting to determine if anything related to that code could have caused the missing votes due to some bug in the software on the voting machine. Of course, they could only analyze the source code of software that was supposed to be on the machine. They did not have an opportunity to examine whether or not the binaries actually running on those machines corresponded to that source code, nor is such a determination possible today.

When I first heard about this study (and I was even approached about joining it), my first thought was that it is a silly idea to try to figure out what went wrong in Sarasota County by analyzing the source code. So many factors that have nothing to do with the source code could have contributed to the problem, and source code analysis cannot be used to find all problems that may have arisen in the software. There are all kinds of run time conditions such as, for example, race conditions and runtime bounds errors that could cause problems without the ability to be detected by source code analysis.

However, the team, which contains quite a few all stars, proved that even though a source code analysis is not likely to shed any light on what happened in this particular election, it is nonetheless an extremely valuable exercise. I wish more real voting systems were subjected to such careful scrutiny followed by a public report. I have not seen the confidential appendices in this report, but just from the table of contents, it is clear that some serious problems were found in this machine, and once again it boggles the mind that it was ever certified and used in elections. On page 37, section 7.1 begins as follows:

"We identified several buffer overflow vulnerabilities that in a worst case scenario may allow an attacker to take control of a voting machine by corrupting data on a PEB. These create the possibility of a virus that propagates by exploiting the buffer overflow vulenrability."

This is reminiscent of the vulnerability that the Princeton team exploited in the Diebold DRE. I would not suggest reading this report before bed, because it is quite scary. To me, the Princeton work, coupled with this FSU report should serve as wake-up calls to the elections community that these sorts of studies need to take place before voting systems are deployed, not after an election has proven problematic. Studies such as the FSU one should be done as part of the certification process. This report clearly uncovered problems that would have been show stoppers, and yet, relatively little attention has been paid to this.

American Idol - I demand a recount!

For this posting, I have to admit something that will probably lose me the respect of many, and yet I can't help it. Here goes... I am a closet American Idol fan. Every week, my wife and I go downstairs after the kids are in bed and we watch the most recently Tivo'ed episode of American Idol. We don't like the early rounds very much, which are mostly about watching the judges humiliate unfortunate people who don't realize they can't sing. But once the top 24 are chosen, we really enjoy the singing and the drama of who will be eliminated.

As someone who is consumed with voting and voting security, I have more than once wondered about the voting on the American Idol show. How easy would it be to rig the vote that is conducted over the phone? A friend of mine has some pretty good and convincing ideas for ways to tamper with the votes using computers and automated dialing tricks and even taking advantage of some weaknesses in the phone system. I'm not sure if the tricks he has suggested are legal, and I'm certain that most of the population wouldn't know how to do them. Although, it would only take one enterprising attacker to really mess with the votes. I'm convinced of that.

Last night, the unthinkable happened. Sabrina Sloan was eliminated and missed making the top 12. There are several reasons why I find it impossible to believe that the vote was fair. I had Sabrina pegged as #3 in the overall competition, after Lakisha jones and Melinda Doolitle. Okay, you could argue that maybe Stephanie Edwards is up there with Sabrina. But, American Idol is also about popularity and looks. Sabrina is by far the most attractive of the candidates, and in my opinion she has that star quality to her. She is also an absolutely incredible singer. I'm not alone in my thinking. All three judges were completely stunned by this result. Furthermore, Sundance Head (who I don't think was that spectacular) lost out and Sanjaya Malakar advanced. Now Sanjaya seems like a nice kid, but he's totally out of his league on Idol, and Sundance can sing circles around him. Not only that, Sundance has real personality and charm, and is just the kind of person that goes far in this competition. He's better than at least 3 of the guys who advanced. Far better.

So, is it possible that the judges are wrong? They can be wrong, but I don't think they can be that wrong about these two singers that were cut. Considering that Haley Scarnato and Sanjaya Malakar made it to the elite 12 and Sabrina and Sundance did not, I have to figure there was some funny business with the vote. I don't know if it was because somebody hacked the phone lines, somebody read the results wrong, somebody was paid off, or any combination of the above. But there is no way on Earth that America voted this way this week.

Having a non-verifiable vote, like the one on American Idol can result in people like me being upset that we won't get to watch Sabrina Sloan sing any more on Idol. We can be upset that Chris Daughtry did not win last year when he was by far the best singer, as his album sales are demonstrating this year. But, that's about where it ends. Having non-verifiable voting in public elections, with the doubt that such election outcomes can have, is much more serious.

Today's Congressional hearing

I testified today in a hearing of the US House Appropriations Subcommittee on Financial Services and General Government in Washington DC. Here is my written testimony. The hearing was very interesting. I think we've come a long way from the days when members of Congress had no idea what was going on with respect to e-voting security. The questions, for the most part were intelligent, well researched, and to the point. Many of the questions were directed at another witness, Donetta Davidson, who is Chairwoman of the Election Assistance Commission. The Members grilled her about the lack of accountability of the EAC after they provide money to the states. They also asked for some third party research reports that the EAC has kept confidential.

It turns out that the ranking member of the subcommittee is from Diebold's home district. So, predictably, he tried to ask me challenging questions that sounded as though they were written by Diebold. "Voters love these machines, so why am I arguing against them?" I pointed out that none of my complaints against the DREs have to do with whether or not the voters like them. He also asked me why I would want to go back to an error-prone system such as op-scan when Diebold DREs in Maryland virtually eliminated voter error. I explained to him that modern optical scanners in precincts can provide the same level of overvote and undervote detection. He seemed to run out of steam after that.

Another member of the committee gave me the best opening I think I've ever had. He asked me if I thought it was possible to have a trustworthy and secure election using paperless DREs. I replied "no". He then said, "Why?" It was a question I was hoping for. I explained that a software only system, especially one as complex as a DRE where all all of the voter input and vote tabulation takes place in a closed box, cannot possibly be audited. There is no way to know for sure that the totals produced by the machines at the end of the election correspond to the votes that were cast by the voters.

Finally, I was asked if I thought that a DRE with a paper trail was an adequate voting system. I replied that when I first studied the Diebold DRE in 2003, I felt that a Voter Verified Paper Audit Trail (VVPAT) provided enough assurance. But, I continued, after four years of studying the issue, I now believe that a DRE with a VVPAT is not a reasonable voting system. The only system that I know of that achieves software independence as defined by NIST, is economically viable and readily available is paper ballots with ballot marking machines for accessibility and precinct optical scanners for counting - coupled with random audits. That is how we should be conducting elections in the US, in my opinion.

Herald Tribue infected by virus

Today's Southwest Florida's Herald Tribune online has the following disclaimer on the web site:

March 02. 2007 8:36AM
An apology to our newspaper readers

STAFF REPORT

A computer virus crippled parts of the Herald-Tribune's production equipment Thursday night, forcing the newspaper to print Friday's editions without several of its local news, sports and editorial pages. The technical problems also caused papers to be delivered late. We apologize to our readers and advertisers. Our technicians are working diligently to fix the problems that the virus attack created and to ensure that they are not repeated.

Reading this made me think of the times that I and other computer scientists postulated that a virus, such as the one Ed Felten's team wrote at Princeton, could infect a voting system and copy itself through the memory cards and the voting terminals. The voting machine environment might be more difficult to infect than the Herald Tribune, but the possibility definitely exists. Every time I hear people argue that this could never happen, I wonder what these people would have said about the possibility of a virus corrupting a major newspaper's operations such that the paper was printed with several pages missing. What's more, having looked at the Diebold source code, I wonder if the voting machine vendors' security procedures are better or worse than those of this newspaper.

H.R. 811, the new Holt bill

Earlier this month, US Congressman Rush Holt (D, NJ) introduced H.R. 811, a bill to amend the Help America Vote Act of 2002 to require a voter-verified paper ballot. I have read the bill, as well as some of the criticism by various activists.

In my opinion, passage of the Holt bill would be the single most positive development in this country this decade to ensure the security, integrity and verifiability of elections. As a federal law, this legislation would establish a baseline for all states that would exceed the security and audit of elections in most states today.

The bill is well thought out. It addresses the issues of audit, security, privacy, recounts, conflicts of interest, testing, certification, and cost. I was personally privy to discussions on these issues as the text for the bill was being drafted, and I believe that the reason that this bill handles all of these difficult issues so well is that the Holt staffers took their time, acted deliberately, and consulted with the top experts, until they got it right.

The primary criticism from a subset of the activists is that the bill does not go far enough. For example, it does not ban DREs, as long as they are equipped with a voter verified paper record that is not kept in sequential order. Personally, I would support a ban on all DREs, with paper trails or without. However, the lack of such a ban does not detract from the fact that the Holt bill as it reads would do more to improve election integrity, security and audit than anything that anybody else is doing.

Similarly, when I read the NIST report about software independence (SI), and the resulting recommendation that legacy systems be allowed, and that only future systems will require SI, I would have preferred that all non-SI systems be immediately decertified. But, the net result of that report was positive and will ultimately lead to better elections in this country.

As we move forward, it is important to constantly improve our elections. I believe that the Holt bill has the potential to take the biggest step this country can take towards the ultimate goal of minimizing fraud and error, while increasing access, confidence, and thus, hopefully, participation in public elections in the United States.

ACCURATE 2006 annual report available online

I am the director of the NSF ACCURATE center. People often ask me what the center does. I'm asked when our new voting system will be ready, or if we can hack some other voting system. Well, we are not building a voting system, and hacking voting systems is also not in our charter. However, we have prepared an annual report detailing our activities in 2006. The report is available online.

Bad Software All Around

Earlier this week, I took a train up to NYC to give a talk to some potential ISE customers on Wall St. A collection of Chief Information Security Officers and other executives from financial firms. I was asked to speak about software security, and two things happened on this trip that put to rest any doubt that the current state of software security and network security is dismal. I didn't doubt it, but I thought it was particularly humorous that these happened on a trip whose purpose was to give this particular talk.

I arrived at my hotel about an hour before I was scheduled to speak. Since the hotel was only a couple of blocks from Wall St., I figured that I had time to go online and read my email. I opened up my laptop in my room and saw that there was a WiFi base station whose SSID was "Exchange" (which was the name of my hotel) along with several other available base stations. So, I connected to my hotel's access point. I had full bars, so the connection was strong, but I was unable to reach my email server. I had a look at the IP address assigned to me by the network and noticed that it was a factory default address that was probably not what the hotel was using. So, I called the front desk, and I told the woman who had just checked me in that I was having a problem with the wireless network. It seemed that I was not getting a valid IP address. She said something about their street address, and I realized that while this nice lady was very good at checking me into my room, she was not going to be the best tech support person I had ever had.

I explained to the woman that I was able to connect to the wireless network, but that I was unable to read my email because the network was not working. She understood that and said, "Yes, this happens all the time. I will just reboot the thingy. Give it a few minutes and try again." That sounded like a reasonable solution. Meanwhile, I tried the other wireless networks, and none of them would allow a connection without a password. I chalked this up to progress.

Several minutes later, I reconnected to the Exchange network, and I was assigned what looked like a normal NATed IP address. But, I was still unable to connect anywhere. So, I opened up a browser window to see if I needed to log in. What I saw surprised me at first. It looked like some kind of menu console for managing an appliance. I clicked around and realized that I had the ability to configure routing and firewall rules. In fact, I was logged into the hotel's router - the "thingy" if you will. I smiled to myself at the thought of what I could do if I wanted to, but I quit out of that and was able to access the Internet. The connection was pretty slow, and I chuckled at the thought of getting back into the administration console to filter out the other users in the hotel. Of course, I decided against that.

Unbelievable!

But, it gets better.

When I arrived back at Baltimore Penn Station, I left the train and walked to my car. I drove up 2 levels in the parking garage, and I arrived at the exit gate. This parking garage installed an automated system where you use a credit card to get in when you arrive, and if you use the same credit card when you leave, you don't need to take a ticket, and it charges that card and lets you out. At least that's the theory. It didn't work that way on this trip. As I approached the exit, I saw that there were two lanes open for exiting, and that the car in front of me had pulled into one of them. So, went to the other one and inserted my credit card. On my mind was my daughter's school play, which started in about an hour. I had time to grab a quick sandwich and then head to her school. I had planned my trip so that I could be back in time to see her perform.

After about a minute, it seemed odd to me that my credit card had not come out yet. The machine said that it was validating ticket data. But, I had not inserted a ticket. So, I pressed the intercom button, and an attendant asked if she could help me. I told her that I put my credit card in a while ago, and that I wanted to pay and leave. The gentleman in the truck in the other lane yelled to me that he was in the same boat, so I told the woman that neither one of us could leave. She asked us to hold on a second, and in about another minute a woman in a parking attendant uniform appeared. She told me that it might be that the other gentleman and myself inserted our credit cards at the exact same time in the two different machines. I agreed that this was indeed possible. In the meantime, I rather long line of cars had formed behind us.

The parking attendant backed up all of the cars and suggested that I back up about one car length, and that the other gentleman do the same. Then, she suggested that I drive back up to the machine, which I did. My credit card came out, but she said I had to reinsert it. I did, and it said that it was validating ticket data. The attendant said, "oh no." That didn't sound good. I asked what the problem was. She said that every once in a while, when two people insert their credit cards at the exact same time, it crashes their whole system. We did the back up thing again to retrieve our cards. Since the other guy was first, she went and processed his payment manually. That took about 3 minutes. Then, she took my credit card and went to do mine. In the meantime, another car behind me drove into the other lane, which was now available and inserted his card. The system did not respond. It was hosed. A few minutes later, she came back and gave me my credit card and receipt and opened the gate so that I could exit. The line of cars was now very long, and she said she would have to do them all by hand until a technician could come. I have no idea where this technician was coming from, but I was glad to be on my way. I got that sandwich, but because of my delay, I had to eat it in the car on the way to my daughter's play.

What kind of software design results in this kind of crash? The answer is pretty clear to anyone who has worked with software. While they may have tested the system exhaustively, they probably did not test the possibility of putting credit cards in two different machines at the exact same time. Which brings me back (as usual on this blog) to voting machines. They may be tested and tested and certified and verified and validated. But, if on Election Day something unusual happens, a scenario that was not anticipated, something might go very wrong. And, if there is no tangible, physical record of the votes that were cast on the machine, then votes might be lost in an unrecoverable way.

Given what I've seen about voting system standards and voting system testing labs, I would bet money that the parking garage system at Baltimore Penn Station was tested more extensively before it was deployed than the Diebold voting machines that we use in Maryland.