This is inaccurate and suspiciously self-serving.
First of all,
the SAIC report states
very clearly:
The State of Maryland procedural controls and general voting environment reduce or eliminate many of the vulnerabilities identified in the Rubin report.There is simply no way to spin that statement.
Rubin got it substantially wrong. There's an entire appendix devoted to debunking most of his claims, several of which are driven by his stated anti-DRE bias. You've simply ignored
all of that material entirely. Why?
Moreover, you intentionally leave out specific things that are reported in the
Maryland press release to have been specifically addressed by Diebold, to wit:
"Diebold has incorporated three new security features in response to the independent review. The enhancements include 1.) implementing a dynamic assignment of security keys to enable the State to determine the pass codes used by smart cards to access the system, 2.) incorporating encryption into the electronic transmission of election results, 3.) providing personal identification numbers for when election officials access the system."Furthermore, the Maryland press release appears to be missing additional salient details. Yesterday's
Wired story includes the following bit of additional interesting detail:
The report (PDF), prepared by Science Applications International (SAIC), offered an "action list" of 23 items for securing the machines. Six of those items have already been implemented, according to David Heller, project manager for Maryland's board of elections. These include applying encryption to the process of transferring votes from voting machines to state servers via modem and altering Diebold's software so that votes in the system could not be matched to the names of voters.Let us for the sake of convenience refer to the items in the MD press release above as items (1) to (3), and the item in the Wired article about system alterations to prevent votes being matched to voters as item (4). Why is this last item not mentioned in the MD press release? The reasons are unclear (and probably unimportant) at this time, but let's assume for the sake of argument that Wired didn't simply invent the item. It's equally unclear whether any
other security-related modifications were made to the system -- neither Wired nor the MD press release represents a complete functional specification document -- but for the sake of argument let us assume that these four items constitute
all of the code changes implemented by Diebold and that no other "fixes" were implemented in the system. Additional information about the details pertaining to items (1), (3) and (4) would be highly desirable. Item (2) seems fairly self-explanatory. Assuming that items (1) and (3) address smart card authentication issues and/or administrative access (I interpret "for when election officials access the system" as pertaining to administrative functionality) then it's quite plausible that you can "green dot" the following (already debunked) issues from the Rubin report:
(R-1) Vote multiple times using forged smartcardThe Rubin claim is based on the authentication methodology used, and the hard-coding of security keys into the system. This is addressed by item (1) above - updating the smart card authentication mechanism and security keys, and by (S-12). Details would be nice, but that sort of thing sounds like something they wouldn't (intentionally) publish.
(R-2) Access administrative functions or close polling stationThis is addressed by item (1) above - revising the smart card authentication mechanism and security keys, and possibly by item (3) above - providing personal identification numbers for when election officials access the system (clarification would be helpful).
(R-4) Impersonate legitimate voting machine to tallying authorityResolved by (S-5)/item (2) - encryption of result transmission. Rubin's stated claim (section 4.3) is based on the fact that communication between the voting terminal and the server is not encrypted/checksummed. Also addressed by item (S-6) - separate, individual count of the PCMCIA cards (eliminating direct communication between the voting terminal and the server entirely).
(R-5) Modify ballot definitionEliminated by (S-5)/item (2) - encryption of data transfer (if applied to download of election/ballot data as well as result transmission), and additionally addressed by (S-16) as indicated in your matrix (also note: S-16 is a procedural issue, not a flaw in the software). Rubin's stated argument (sections 4.3 and 5.1) is based on the fact that data transfer is not encrypted/checksummed, and that it's performed over the Internet (incorrect assumption) or via removable media such as floppy disk (also incorrect).
(R-6} Cause votes to be miscounted by tampering with configurationEliminated by (S-5)/item (2) - encryption of data transfer (if applied to download of election/ballot data as well as result transmission). Rubin's stated argument is based on the fact that data is not encrypted/checksummed, and the additional (incorrect) presumption that data is transferred over the Internet or by removable media such as floppy disk (also incorrect).
(R-9) Link votes to votersAppears to be addressed very specifically by item (4) above.
(R-10) Delay the start of an electionThis is a straw man based entirely (according to Rubin's paper, section 5.2) on the presumption that the voting terminals are connected to the Internet and subject to a denial of service attack. This claim (often espoused by the BBV crew) has been sufficiently debunked by now, as you well know, and requires no special mitigation.
(R-12) Insert backdoors into codeWe'll simply have to disagree on whether item (S-13) addresses the issue or not. I believe that if you put procedures in place to guarantee the ITA-certified version of the software is what's installed, then someone aside from the manufacturer has inspected the software and has had every opportunity to discover any back doors. You seem unsatisfied. Impasse. I'm prepared to simply disagree peaceably on this point, although I will cheerfully agree that the certification process should be greatly improved and the existing FEC guidelines should be replaced with something more intelligent and relevant.
It's unclear how you came to the decision to place a red, yellow or green dot in each square of your matrix, but the result is certainly very pretty (if not especially accurate). Pending a few confirmatory details about the code changes implemented by Diebold, it's entirely reasonable to state that
10 of 12 Rubin claims have been addressed to date, and your matrix is either erroneous or intentionally misleading (I will of course give you the benefit of the doubt). Of the remaining two items, (R-10) is a straw man based on fallacious assumptions and can simply be dismissed. (R-3) is already addressed by both existing procedure and hardware design, according to SAIC's evaluation.
I fully expect my observations here to be dismissed by the true believers as per usual, but they're fairly demonstrably irrefutable.
JC
Printer-friendly format
Email this thread to a friend
Bookmark this thread
(1000+ posts)
Send PM |
Profile |
Ignore
