 |
GuvWurld.org |
Black Box Voting
Did anyone look at the source code?
None of your business!
No one certified the patches — No one is explaining the files in a folder called "rob-georgia"
It's time for Georgia citizens to demand answers. Not PR office answers this time, but specific answers, under oath, fetched by subpoena, exposed to the full depth and breadth of discovery procedures.
CONTACT:
E-mail: david@blackboxvoting.com
WHO REALLY LOOKS AT THE SOURCE CODE?
Speaking of sources: To read detailed interviews of the officials on this topic: INTERVIEWS
Thanks to Scoop for having the courage to print this on its international news service.
"When I learned of Diebold's FTP site I was so stunned that I literally stayed up all night. I called everyone I know: Reporters. Computer people. Activists. What can you even say when you see a blunder like this?" — BEV HARRIS
In early February, 2003, programmers for Diebold Election Systems admitted that they had been parking highly sensitive company files on an unprotected web site, a serious security mistake by anyone's reckoning.
The very next week officials from the state of Georgia admitted that a program "patch" was administered to over 22,000 unauditable touch-screen voting machines in Georgia. This took place shortly before the November 2002 election.
A single, certified, and carefully examined version of the actual vote-counting program is allowed on the voting machines.
However, when a program is "patched," new code is inserted into the existing program, usually correcting a fault, or sometimes adding a feature. If a patch is to be applied to the actual vote-counting program, it should be recertified.
Putting patches on 22,000 voting machines without looking at the underlying code has put the Georgia election results in doubt, for two reasons:
First, when a patch is administered, whatever the explanation, it can make other, unnoticed changes to the way the program operates. In this case, no one bothered to see what the patch did. Instead, certification officials just took the vendor's word for it. They could not have known whether the vote-counting program was altered, and especially after installing the patch, they had no way to find out if rogue programs were being run in the background.
Second, ignoring the possibility of an attack on the voting system through the operating system is completely naive. In fact, in testimony before Congress Douglas W. Jones identified the very real risk of an attack on voting machines through the Windows operating system, specifically with the type of machines (Diebold / Global Election Systems DRE machines) that were used in Georgia!
The purpose of the 22,000 Georgia voting machine patches, says Michael Barnes of the Georgia Secretary of State Election Office, was to correct a problem with video screens freezing up. According to Chris Riggall, the Press Secretary for Cathy Cox, Georgia Secretary of State, Diebold attributed the problem to a "conflict between the unit's firmware and a new release of Windows CE that serves as the units' operating system."
Unfortunately, no certification lab seems to have examined what was actually on this patch.
A patch to the underlying operating system — Windows — can slip through without scrutiny. Testing labs ignore it, yet this kind of patch can contain new, malicious code designed to tamper with vote-counting. Windows CE, especially, (the system used in Georgia), may carry risks when used in voting machine patches, because its interface is very well documented, and this documentation is available online to virtually anybody.
Any reasonably skilled programmer could figure out how to insert hidden code via a patch to the Windows platform, and this would be even more feasible with access to the sensitive files parked on Diebold's unprotected FTP site -- hardware and software configuration files, testing protocols, certification lab reports, vendor lists, source codes, data configuration files. A modification that looks like a Windows patch could be quite subtle: a small change to a touchscreen driver, for example.
Chain of custody of this patch is of paramount importance. Though the patch was said to be a Windows patch, it was not sent to Georgia from Microsoft, but instead was supplied on customized memory cards provided by Diebold. According to Michael Barnes, Diebold supplied memory cards which contained a patch. Twenty teams were deployed across the state of Georgia. They would line up the machines, insert the card, boot up the machine, and in the boot-up process the new programs were installed.
Security procedures for this patch seem a bit murky: Which programmer(s) created the memory cards? What prevented people from overwriting the memory cards with unauthorized program code? Did any of the "rob-georgia" patch files from Diebold's unprotected FTP site make their way onto any of these cards? What security procedures prevented substitution of memory cards in key locations? These are answers that need to be answered, under oath, not via telephone calls or press statements.
As for the security procedures for the memory cards that installed this patch, even Dr. Brit Williams, Georgia's official independent certifier for voting machines, seemed a little uncomfortable.
Conversation with Dr. Brit Williams:
Harris: "What was the security around the creation of the cards used to implement the patch?"
Williams: "That's a real good question. Like I say, we were in the heat of the election. Some of the things we did, we probably compromised security a little bit — Let me emphasize we've gone back since the election and done extensive testing on all this."
For some reason, no one at any level of the certification process bothered to examine this patch.
Conversation with Michael Barnes:
Barnes: "Wyle said it did not affect the certification elements. So it did not need to be certified."
Harris: "Where's the written report from Wyle on that? Can I have a copy?"
Barnes: "I'd have to look for it. I don't know if there was ever a written report by Wyle. It might have been by phone."
Conversation with Dr. Brit Williams:
Harris: "Did you do a line by line examination of the patch?"
Williams: "The patch was to the operating system, not to the program per se."
Harris: "It only changed Windows files? Do you know that it didn't change anything in the other program, did you examine that?"
Williams: "We were assured by the vendor that the patch did not impact any of the things that we had previously tested on the machine."
Harris: "Did anyone look at what was contained in the replacement files?"
Williams: "We don't look at source code on the operating system anyway. On our level we don't look at the source code, that's the federal certification labs that do that."
Harris: "Did you issue a written report to the Secretary of State indicating that it was not necessary to look at the patch?"
Williams: "It was informal — not a report — we were in the heat of trying to get an election off the ground. A lot was done by e-mails."
The other program patch files: "rob-georgia" folder
No official at Diebold or the Georgia Secretary of State's office has provided any explanation at all about the OTHER program patch files — the ones contained in a folder called "rob-georgia" on Diebold's unprotected FTP site. Inside "rob-georgia" were folders with instructions to "Replace what is in the GEMS folder with these" and "Run this program to the C-Program Files Winnt System32 Directory." GEMS is the Diebold voting program software.
Who used the program patches in the "rob-georgia" file?
Barnes: "That FTP site did not affect us in any way shape or form because we did not do any file transferring from it. None of the servers ever connected so no one could have transferred files from it. No files were transferred relating to state elections."
If, as Barnes claims, these files weren't used for anything in particular, exactly why were they there?
Diebold's unprotected FTP site contained exactly the files most important to anyone intent on tampering with an election: source codes, executable vote-counting programs, "patches," hardware and software specifications, technical drawings, and specific testing protocols.
Who accessed the FTP site? Who downloaded the rob-georgia files? Who kept a log to show chain of custody on these files?
- Assume that the FTP folder called rob-georgia was irrelevant to anything.
- Assume that the "replace files with these" folders in it were not used anywhere.
- And assume that all 22,000 program patches did exactly what they said they did: Corrected a conflict between Windows CE and Diebold's firmware to prevent screens from freezing up.
Did it not occur to anyone at Diebold that having a folder called "rob-georgia" on an open FTP site alongside sensitive program files, spec files, and testing protocols might raise a question or two among voters?
If the source code for the voting programs is proprietary and even testing labs and government officials are not permitted to see it, why was it available for download on a public site? Was it an error? If the open FTP site, and the unexamined program patch were errors, what guarantee does the public have that Diebold's security is at all competent? Are there other sites out on the web in which one may find source code and hardware specs for the bank ATMs and alarm systems Diebold also sells?
Did Anyone Look At the Source Code on the 22,000 Voting Machine Patches?
Nowadays it's not just voting that's automated. When you start asking questions, now you get auto-rebuttals, and that's what I got when I asked who looked at the source code — in the patch, and also in the original program.
In the PR industry, we call these auto-rebuttals "Talking Points." Somebody preps everyone: "If they ask so-and-so, answer such-and-such." You dance around wasting meeting time, or talk show time, discussing something that doesn't answer anything.
You've probably heard this auto-rebuttal already: "Why can't we have a voter-verified paper trail that we deposit in a ballot box?"
Talking Point: "Oh, there are very big privacy issues with that, and people might try to buy votes." (Ridiculous: We said "Deposit it in a ballot box," not "Pin it on your forehead and look for a guy to give you twenty bucks.")
When I went looking for some sort of guarantee that these machines cannot be tampered with by someone on the inside, which means at the very least, doing a line-by-line examination of the source code designed specifically to locate tampering, I kept hitting the same official Talking Point:
(Ask whoever): "How do we know how secure these things are from tampering? Who looks at the source code?"
Talking Point: "Oh, they are tested and tested and tested and then tested again."
No wonder they keep trotting this Talking Point out. It worked before: "We have counted and recounted and recounted again."
Could it be that when these machines are tested and tested and tested and then tested again," people aren't really doing a line-by-line examination of the source code (including how it interacts with operating systems and other devices, like video cards?) Do they examine it specifically to make sure it contains no code that could compromise system integrity?
I asked: "Who are the people who test and test and test and then test again?"
Here they are:
- The state
- An independent state certifier
- A national "ITA" (Independent Testing Authority): Wyle Laboratories
- Another national ITA: Ciber, Inc.
Does the state do a line-by-line examination of the source code?
Everyone hurries forward with their next Talking Point: "We do a Logic and Accuracy test." No, that's not what I asked. See the sidebar for why the L & A test doesn't function adequately for fraud protection.
But does anyone at the state look at the source code?
Well, no. At least not in Georgia. My source for this is Michael Barnes.
The "L & A" test is called a Black Box test; examining the source code is called "White Box" testing. And, according to Arnold B. Urken, who founded the first certified voting machine testing lab, you MUST do White Box testing — examine the source code — if your certification is to mean anything. In fact, he was so adamant about this that he refused to certify ES&S (then called AIS), because they would not allow him to look carefully at their code.
L & A testing tells you nothing about tampering. In an L & A test, what you do is this: You run pretend ballots through the machine. If it counts correctly, it passes the test.
When machines lose 103,000 votes, as they did in Broward County, it's pretty clear that the L & A test didn't catch the problem! Go to [this page] for a staggeringly long list of actual election errors that prove you can't depend on L & A tests.
Okay, make that just "tested and tested and then tested."
Does an independent state certifier do a line-by-line examination of the source code?
Well, apparently not. Georgia's independent auditor, Dr. Brit Williams, from Kennesaw University, told me he does not examine the source code.
Well then, I guess they meant they just "test and test."
So I looked up Wyle Laboratories, and I came across a surprising article -- especially since the ES&S web site lists only Wyle as their certifier. It turns out that Wyle decided to stop testing voting machine software in 1996. I called Edward W. Smith, at Wyle Labs, and he confirmed this. Nowadays, Wyle only tests hardware and firmware. Can you drop it off a truck? How does it stand up to being left in the rain? Good things to know, but some of us also want to know that someone has examined every line of the source code to make sure no one tampered with it.
Wyle does test firmware, and Diebold said the patch fixed a firmware conflict, so maybe Wyle tested this!
Harris: "Was that patch certified?"
Barnes: "Yes."
Harris: "By whom?"
Barnes: "Before we put anything on our equipment we run through state certification labs and then in addition to that we forwarded the patch to Wyle labs in Huntsville —"
Harris: "They don't test software, though"
Barnes: "They test firmware...Wyle said it did not affect the certification elements. So it did not need to be certified."
So I guess this stuff is just "tested."
I hunted for Ciber, which tests the software for Diebold. And here's what I learned: When Wyle stopped testing voting machine software, that certification process went to Nichols Research. But they quit doing it and it went to PSInet, and then to Metamor, and now it is done by Ciber.
While looking for names to call at Ciber, I found out that we're not supposed to ask Ciber any questions. In fact, there are specific instructions about this:
"The ITAs DO NOT and WILL NOT respond to outside inquiries about the testing process for voting systems, nor will they answer questions related to a specific manufacturer or a specific voting system. They have neither the staff nor the time to explain the process to the public, the news media or jurisdictions. All such inquiries are to be directed to The Election Center. . ."
So I called The Election Center
Assistant: Doug Lewis is gone for the day — his cell phone is 713-xxx-xxxx. And he is the only one to talk with.
Harris: "Mr. Lewis, I understand that your organization is the one that, basically, certifies the certifiers of the voting machines, is that correct?"
Lewis: "Yes."
Harris: "Do you have anything in writing that shows that a line by line examination of source code was performed by either Ciber or Wyle?"
Lewis: "No. But that's what they do. They go line by line. They're not trying to rewrite it."
Harris: "Where can I get something in writing that says they look at the code line by line?"
Lewis: "I don't know where you'd find that."
Here's another Talking Point:
Bring up anything about protecting voting machines from tampering, and you'll hear this one —
All in unison now: "I'm not going to talk about proving a negative."
I think I'm going to start making ATM machines. When I make my sales presentation, and the bank says "Can anyone tamper with these?" I'm going to reply "I'm not going to talk about proving a negative."
And I'm going to make some slot machines too. When the casino owner asks me, "How do you know these things can't be rigged?" I won't answer. I'll just say, "I'm not going to talk about proving a negative."
Harris: ... "Let me be more precise. Are you saying that Wyle and Ciber do a line by line check on the code, and the way it interacts with the system, to make sure that no one could have put any malicious code into the voting machine software?"
Lewis: "Oh. That's what you're talking about. I don't know if they do a line by line check to see if there's a problem."
Harris: "Who can I speak with at Ciber and Wyle?"
Lewis: "I don't think anyone there could answer your questions."
Harris: "Who do you speak with at those labs?"
Lewis: "Shawn Southworth at Ciber.
. . .
Harris: I have one more question: Prior to taking over The Election Center, you owned a business that sold used computer parts, which ended up going out of business. Shortly after that you took over The Election Center. Did you have any other experience at all that qualified you to handle issues like the security of national elections?
Lewis: "Oh no no no. I'm not going to go there with you."
Harris: I have newspaper articles published shortly after your computer reselling company went out of business, that refer to you as an expert in election systems. What else did you do that qualified you to take over your current position?
Lewis: "My background is that I owned a computer hardware and software business. I've never claimed to be an expert. That's the reason we have laboratories, nationally recognized laboratories."
A very brief discussion ensued about testing, during which Mr. Lewis hung up on me.
So I called Ciber. Shawn Southworth's assistant told me that she was supposed to refer all questions back to The Election Center. The only person at The Election Center who is authorized to answer questions about certification procedures is R. Doug Lewis, see above. I left a message for Southworth anyway, but he did not call me back.
I called Michael Barnes again and left a message asking if we can see a copy of the official opinion from Wyle that it was not necessary to certify that patch. He did not return my call.
I called Michael Barnes again, and left two messages asking who specifically looks at the source code and if we can get something in writing about who looks at the source code. No one returned my call.
I guess the answer is "None of your business."
— Bev Harris, author of Black Box Voting: Ballot-Tampering in the 21st Century. This article is copyright by Bev Harris, but permission is granted for reprint in print, email, or web media so long as this credit is attached.