Update:I received an email from Prof. Doug Jones that he felt his comments were being misread, in view of my editorial remarks. I wish to make it quite plain that all remarks outside the specific quotation are mine, and my views must not in any way be construed to represent Prof. Jones' views. I offer this space to him to further clarify his views and I sincerely apologize to him that my comments have caused him distress.
In my opinion, the relationship between Hursti's report and earlier hints at the existance of the problem from the interview with Rob Behler in March 2003 and the RABA report in January 2004 is very similar to the relationship between my own report of Diebold's (well, it was Global Election Systems at the time) inept use of DES to the House Science Committee in May 2001 and the later Hopkins report of 2003 by Kohno, Stubblefield, Rubin and Wallach.
In each case, the earlier reports disclosed a serious security hole, but did so in a way that came nowhere near documenting the extent of the problem. The later reports documented that the security flaws were far worse than the earlier information had hinted. Without these later and far more detailed reports, it appears clear that no corrective action would ever have been taken. Even with them, the vendor and election administrator communities appear intent on downplaying the importance of the problems.
Doug Jones, 5/18/06
Contrary to the claims of Bev Harris' group, the security hole in the Diebold TS and TX systems are not new, and in fact, were identified by programmers in the Spring/Summer of 2003, and by Rob Behler in an
interview in February of 2003.
So the way we did that in the warehouse was, they would post whatever the update was on the FTP site. James would go get the file and put it on the [memory] cards. Because you load everything through the PCMCIA cards. You boot it up using the card and it loads the new software. "This was done in the warehouses -- once the machines were sent out to the county, these updates were done just to make sure the machines were running correctly. I went over to Dekalb [County]. We updated 1800 machines in basically a day and a half. I still remember ol' Rusty, down at the warehouse, we ended up touching every single machine off the pallet, booting 'em up, update it, we had a couple hundred machines done when in comes a new update over the phone.
While the Hursti report does have more detail, it is essentially the same problem found, but not formally documented, until January 2004, by RABA Technologies in their
report to the Maryland General Assembly.
The PCMCIA card can be used to update the software on the AccuVote-TS terminal. This can be done by placing a PCMCIA card with an update file into the terminal and rebooting the terminal. The update file allows an attacker to overwrite any file on the system. Furthermore, by using this technique an attacker can install his own version of the ballot station software giving him the ability to completely invalidate all the results on that terminal. If he compromises the AccuVote-TS terminal used as the accumulator, he can compromise the entire precinct results.
Trusted Agent Report, Page 19
I sent a note to Prof. Doug Jones to verify this and he replied:
This is exactly the same problem! Thanks! I've been wondering whether this vulnerability was hiding in one of those old security evaluations. Now we can say, rather firmly, that Diebold knew about this problem for almost 2 years and did nothing about it.
He elucidates further in a post to a discussion list:
I think it's pretty clear that RABA found the same design flaw that Hursti found in Utah. Therefore, Diebold has been aware that it is a flaw for at least 2 years. The RABA report recommends tamper-evident sealing and prominent posting of legal penalties for tampering with machines, but their final remediation recommendation ends on a strong note:
We see no short term fix for these attacks aside from the clear posting of rules that indicate consequences of such actions.
They ought to have included some kind of authentication and authorization controls in the very first new release of their firmware to go to the ITA's after 2004. Ciber and Wyle completed a cycle of ITA testing on this equipment on May 17, 2005. (AccuVote-TSx firmware v 4.6.2.) I can find no excuse for Diebold not to have reacted to the vulnerabilities pointed out by RABA technologies in all firmware versions after 4.6.2.
It is noteworthy that firmware version 4.6.3 was certified in August 4, 2005, and 4.6.4 also appears to have completed certification in 2005. The frequency of updates makes it clear that Diebold was committing resources to development, and that they had in place a decent fast track through the ITA maze. Therefore, the only explanation I can see for failure to put at least some minimal barriers in place to block unauthorized firmware upgrades must have been a deliberate decision to ignore the findings of the RABA report.
I would actually be willing to bet money that it was documented earlier in the redacted portions of the
SAIC report also commissioned by the state of Maryland (who then went ahead and
bought the junk anyway). Of 280 pages in the report, only about 40 were consided safe for the unwashed masses to read.
The significance of Hursti's report is not that it has documented previously unknown security holes, but the fact that the holes still exist over 2 years after discovery.
What is important about this issue is that despite "re-certification", the security hole was left in place DELIBERATELY. This not only demonstrates that the "certification" process is a complete sham, it also demonstrates that Diebold continues to lie about fixing security problems.
When the RABA Technologies report was issued, this is how
Diebold responded:
Diebold officials could not be reached directly for comment. But in a press release, the company said Thursday that the study "validates" the Diebold election systems for the primary.
Diebold President Bob Urosevich said in the release that the Raba Technologies report confirmed "the accuracy and security of Maryland's voting procedures and our voting systems as they exist today."
Let me re-iterate what this all means:
1) A MAJOR, easy to exploit, security hole has existed in Diebold touchscreen units for at least three years, as far back as the 2002 General Election.
2) Diebold was made aware of that security hole at least two times, probably three.
3) Diebold admits the hole was intentional, being put in as a convenience to users, despite the fact that it poses a major danger to the integrity of the election process.
4) These very same machines, sporting these very same security holes, have been repeatedly certified by "independent" testing authorities who are paid by Diebold, and who refuse to disclose their testing methodology, except that those methodologies seems to involve allowing machines to pass certication which can be tampered with in the field with ease.
5) Diebold's response to reports pointing out security problems is to issue a press release claming that the reports prove its products are secure.
If Diebold had built the
Hindenberg, they would have issued a press release stating that the destruction of the zeppelin validated their view that hydrogen is not flammable.
Update: I have confirmed this with Avi Rubin as well. Here is his repsonse:
That's a good catch. Basically, this is what Harri Hursti did. But he gave a lot more detail on it. Also, he showed that you could get a new bootloader, a new OS or a new voting app, and made it sound easier than Raba did. But, now looking at that paragraph you sent, it's clear RABA knew about this.
Actually, the catch is by Bill Bored, a poster at
DU. There may be more details in the report RABA submitted to Maryland, I am checking into that.
