[bold maroon emphasis added by]

Tuesday, August 07, 2007

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.