* skeptical of voting test but will study Sancho's complaint

[kster]

Gov. Jeb Bush said today that Leon County Elections Supervisor Ion Sancho may have a reputation as a "maverick" who uses "unorthodox" methods, but that the state will seriously consider Sancho's complaint that it's easy to cheat on some voting machines.

Earlier this week, Sancho said he will replace voting equipment in a dispute with the Diebold company. Sancho said security tests of 160 voting machines showed that they are vulnerable to hacking and manipulation of vote counts.


But Bush said Sancho sort of rigged the tests by allowing hackers to get computer access that they could never attain in a real election.

"It wasn't perfect," Bush said of the tests. "They gave them the source codes."


http://www.tallahassee.com/apps/pbcs.dll/article?AID=/20051216/NEWS01/512160355

[PDJane]

1. The source code was

available, as I remember, on the web............

[kster]

3. Or atleast it should be

Although a private Australian company designed the system, it was based on specifications set by independent election officials, who posted the code on the Internet for all to see and evaluate. What's more, it was accomplished from concept to product in six months. It went through a trial run in a state election in 2001.

http://www.wired.com/news/ebiz/0,1272,61045,00.html

[aquart]

2. Bush is, of course, disingenuously, deliberately wrong.

He wants us to assume that only outsiders would come in to hack the election. But if the election were being hacked by political operatives with the cooperation of Diebold, i.e. Republicans, then they would have those codes. So, no. The tests were not rigged.

[OnTheOtherHand]

4. it wouldn't require Diebold's cooperation

The folks who demonstrated the Diebold hacks did not get Diebold's cooperation!

Gaping security holes are non-partisan. If I understand correctly, the hack demonstrated in Leon, as implemented, required machine access, so it didn't demonstrate the ability of one person to steal votes statewide. But one person in a particular county BoE probably could do quite a bit of damage.

[kster]

8. At the Central tabulator you could steal statewide

http://www.iwilltryit.com/fixed1.htm

[Wilms]

10. Hey kster. Why ain't that video a separate post? Huh?

:shrug:

[OnTheOtherHand]

12. we need to get clean precinct counts -- then central tab can be handled

Central tab hacks are a problem if they can actually obliterate the possibility of recounting the original votes. Or if somehow no one notices that none of the official vote tallies match the original tallies. Any electoral system needs Many Eyes to guard against the latter.

As I think Wilms was pointing out, the video you linked to would be about programming the DREs to steal votes individually as they are cast, right?

[Neil B Forzod]

21. leon county test

The problem with the Leon County test is that it doesn't actually test a real-world scenario.

There are certain manipulations you can make if you have access to the main server. That's true of any of the major systems out there, it's just more heavily publicized in the Diebold case because they use a plain Microsoft Access database at the back end. But you can make the same fundamental types of manipulations to any of the major EMS systems if you have free access to the main server. *shrug*

Diebold points out (they have a paper on their site) that manipulations at the server would be detected via the built-in checks and balances in the system, namely the comparison of results from the report tapes produced by the voting machines to the data in the central tabulator. In the event of a discrepancy (there will be one, if you only manipulate the server) you investigate and take whatever steps are necessary to resolve (e.g. recount the affected ballots, etc.) OK, fine. That actually makes sense -- you can argue that prevention of result manipulation is required, but that's extremely difficult to pull off. Technically, ensuring detection of any tampering is actually enough to assure the integrity of your results (in the optical-scan, or DRE-with-VVPAT case at any rate), and that's their model.

Obviously that causes a problem if you can manipulate all components of the system such that your tampering wouldn't be detected. If you can do that, then you have a problem with the system. That's the question here, and it doesn't have a good answer because of the way Sancho went about conducting the test.


I'll discuss that statement in more detail below, but first (by way of example) consider various attack vectors against a system (not Diebold's in particular, they're all pretty similar in the ways that are relevant here).

1. An attacker with free access to the main server can manipulate the results in the database (whatever its form) and change them. Right? Not really, because you'd notice the difference between the results printed from the server and the results printed from the voting machines.

2. Suppose the results are transmitted from the voting machine to election central via unencrypted modem transfer. A man-in-the-middle can intercept and modify the results in-transit. But that's just a variation of (1) above -- you'd detect it trivially because the server would print different results from the voting machine.

3. An attacker could modify the results on the memory card after voting is completed, but that's tough to do logistically because the results are probably printed before he gets the chance. Or the machine might have a redundant internal copy of the results and be equipped to detect the manipulation. Certainly you could incorporate a post-election procedure in which you dump the internal copy and compare to what was uploaded from the memory cards on election night. Anyway, you probably get the point -- there's a discrepancy in the system that you can detect.

4. Suppose an attacker finds a way to manipulate both the memory card and the internal copy of the results undetected after the election. That's pretty problematic! But even then, you have a discrepancy with the physical ballots or the VVPB records, and a big enough audit of those will detect any systematic tampering.


In all of the examples above, it's possible to tamper with various parts of the system and still accomplish nothing because the tampering is detected (or at least "detectable", which is an important distinction -- it implies you need to actually perform the appropriate verification/auditing procedures).


As to the Leon County test. The short description of the test is as follows:

Hursti is able to manipulate the contents of an optical-scan memory card using a memory card reader he was able to purchase on the internet. Fair enough. He specifically performs the following manipulations:

a) replaces the reporting script with one he created himself, and/or
b) modifies vote totals on the card prior to the start of voting;
c) ignores all pre-election testing, or manipulates that testing such that it appears to pass
d) after the polls are closed and results are uploaded from the modified card, he modifies the results at the main server (this step is required for attacks based on (a) above)

That all sounds pretty bad, and may in fact constitute a problem that should be addressed. However, in order to perpetrate his attack in the real world you need:

a) free access to the main server, before and after the election;
b) control of all pre-election machine testing, in order to either ignore the incorrect results that show up there from card manipulation or to manipulate the test results to match what they're supposed to be;
c) access to all the target memory cards after they've passed testing, been locked in the machines and protected with tamper-evident seals, and had their counts reset, as well as sufficient time before the election to manipulate them, and a way to cover-up the destruction of the tamper-evident seals;
d) access to the main election server on election night as results are coming in, in order to manipulate any results before any reports are printed;
e) control over any mandatory audit procedures (e.g. California's 1% manual audit) that would detect the discrepancy in the results; and
e) (for the sake of completeness) access to the targetted memory cards after the election, in order to go back and erase any evidence of the tampered report script.

Given all of those conditions (or ignoring some of the most basic standard procedures entirely, like not performing any pre-election testing, or not examining tamper-evident seals, etc) Hursti's attack succeeds, which is what transpired in Leon County. Bev Harris will hand-wave much of that away, because that sounds pretty bad (for her) when you point it out.

Realistically, no single person has that level of opportunity and inside access throughout the entire election life cycle -- there are typically a lot of people involved in setting things up, and most don't have all the required access. And the people with the most access, i.e. access to the main server, are typically "trusted" election officials. Of course, maybe some of them are (or should be) untrusted. But the reality is that if the people running your election can't be trusted, you have bigger problems than your choice of election equipment. Take absentee ballots. What makes you think this untrusted person will actually count your ballot when it comes in, if you've voted for the wrong person? Take memory cards. Why manipulate them at all? Why not just create fake ones for the machines you want to manipulate, and ignore the real ones when they come in?


I realize after typing all of the above that it's probably too long and complicated. Take a simpler analogy. Suppose you want to protect the Declaration of Independence. You probably want to buy a safe, right? So maybe you go to Diebold... they'll sell you a safe. A really awesome one, I'm sure. (Actually, the Declaration of Independence really is stored in a Diebold safe at the National Archives, lol). Anyway I'll bet that no intruder could ever get into that safe and modify what's written on that piece of paper. Ever. Well, unless the guy running the National Archives actually lets you into the safe, which he can do because he has access to it. Or unless he goes in there himself and does it, because it turns out you shouldn't have trusted him after all. So what do you do to protect yourself? Buy a better safe? Maybe, I guess, although I don't know where you'd find one that prevents someone with access from getting inside. Or you could invent some appropriate operational procedures, and follow them. Silly example, but it's not fundamentally that different from the Leon County thing.


In short: you can obviously manipulate various elements of the system. Diebold (and a lot of election officials) will tell you that you can't perform all the required manipulations while also observing basic (or enhanced, if you prefer) operational procedures. Bev Harris will tell you the system is wide open and can be easily manipulated by pretty much anyone, without any special inside access. It all comes down to who you believe. Ion Sancho didn't answer the question in Leon County because he ignored all operational procedures and said "here's the machines, here's all the memory cards, take as much time as you want, skip all the pre-election testing, and here's free access to the main server too, just for good measure." So... there you have it, and you can formulate whatever conclusions you think are correct.

For my part, I personally think the Leon County test was silly and not especially valid. I also think Diebold should close a couple of the described avenues of attack. Instead what we get is a lot of erroneous PR on both sides, and a lot of misinformation that serves nobody any use. That's just my own 2 cents.


Neil

[OnTheOtherHand]

25. the only dumb q is the one I don't ask, right?

The way I read the report on BBV.org (heh) of the latest test, it doesn't appear to require access to the servers. Did he in fact "modif(y) the results at the main server"?

(The description says: "The results were then uploaded from the optical scan voting machine into the GEMS central tabulator, a step cited by Diebold as a protection against memory card hacking. The central tabulator is the 'mother ship' that pulls in all votes from voting machines. However, the GEMS central tabulator failed to notice that the voting machines had been hacked." That doesn't seem to imply that Hursti had to manipulate the central tab in any strange way. But of course BBV isn't necessarily an authoritative tech source! http://www.bbvforums.org/cgi-bin/forums/board-auth.cgi?file=/1954/15595.html )

A manual audit certainly should catch it, if it's done right.

It seems to me that different exploits potentially evade different safeguards -- and if it is possible to mess with the cards before voting, and then maintain an apparently tight chain of custody on them, that confers certain advantages that simply supplying bogus cards would not. One of them is that you can make sure to have the correct total number of votes.

[Neil B Forzod]

26. slight clarification

I was combining a discussion of their earlier tests and the current one, which probably confuses things. :(

In their first test from several months ago, they'd need access to the GEMS server to modify the election results to match the incorrect results printed as a result of their fake reporting script (because the reporting script itself has no ability to actually modify the results, despite Bev Harris' original claim -- you'll have to take my word for it that people have verified that, and that some of us just did it without issuing a press release ;) ).

In their new test, they don't necessarily need access to the GEMS server (if I interpret their posts correctly, and if their posts reflect reality). They just need access to the memory card after any testing has been concluded and after the counts have been cleared. In the real world, memory cards are locked in their corresponding machines by that point, and protected with tamper-evident seals. Removing the card to mess with it requires breaking the seals, and basic procedures provide for inspection of the seals before opening the polls to check for any tampering. Ion Sancho didn't bother with any of that and simply said "here's the machine, here are the cards, here's the GEMS server if you want, go to town". So it's not an especially real-world scenario. Bev Harris will undoubtedly claim that nobody inspects the seals. Or that she can get by the seals by unspecified magic. Or that she can go to the store and buy new tamper seals, and some tamper-tape with the right serial numbers on it, or how an insider can easily just get around all that in some unspecified way. Like I said, it comes down to who and what you believe. If the seals really are easily bypassed, then buy better ones (there are some good metal crimp-style ones available). Or reset the counts immediately before opening the polls instead of after successful testing, closing the window of opportunity for pre-loading data on the card before the polls are opened. Or revise your chain-of-custody procedures to prevent access to the machines in the sensitive time period. Or whatever. You get the idea... identify the weak point in your protocol, and modify the protocol accordingly.

(And by all means, bring the issue to the vendor's attention, if it's a concern to you as an election administrator. Write a letter to your sales or support rep, saying that you understand the problem (or asking clarification, if need be) and that while you understand that operational procedures are designed to mitigate the risk you still give some credence to the reported vulnerability and would like an update to the system that would also help to mitigate the risk. Escalate as required until you get a satisfactory response -- sales and support flunkies (for any vendor of anything) are instinctively inclined to deny any problems because they don't want to admit that no system (least of all theirs!) is perfect.)


Neil

[OnTheOtherHand]

27. in this respect I am readily confused...

Heck, I'm a public opinion guy. I knew a bit about how boards of elections operated 20 years ago, and I know some stuff about computers now, but my mental map of current tech implementations has Here Be Dragons! written all over it. That said, I'm happy that I managed to evade the Mighty Forzod Boot. ;) We both interpret the BBV writeup the same way, for whatever that is worth.

I would certainly hope that a reporting script can't modify actual results (although I can imagine implementations in which nothing would prevent it from doing so). I will trust and hope that you are right about that.

In the real world, memory cards are locked in their corresponding machines by that point, and protected with tamper-evident seals. Removing the card to mess with it requires breaking the seals, and basic procedures provide for inspection of the seals before opening the polls to check for any tampering.

That's crucial. I wouldn't assume that that actually happens. Violations of basic procedures seem to be very common, so I would not count on this being an exception. (Especially in elections where new technology is being rolled out, I can imagine anarchy being the rule.) But I certainly hope that it happens somewhere, and that should be a constraint on the amount of fraud that can go down via memory cards.

Pardon me if I am asking you to repeat yourself, but since I gather that this exploit doesn't make your list of major security concerns, what does? (I realize that question is a bit like "What worries you about politics?" or "What do you think about weather?" But hey, you'll find something to work with.)

[Neil B Forzod]

28. join the club, lol

That said, I'm happy that I managed to evade the Mighty Forzod Boot.

LOL. :D

That's crucial. I wouldn't assume that that actually happens. Violations of basic procedures seem to be very common, so I would not count on this being an exception. (Especially in elections where new technology is being rolled out, I can imagine anarchy being the rule.) But I certainly hope that it happens somewhere, and that should be a constraint on the amount of fraud that can go down via memory cards.

You're absolutely right on all counts. Following procedures like the one referred to here (and various others) is absolutely crucial, and I'm quite certain you're right that violations of those procedures are probably common. When correct procedures are followed, a lot of potential attack vectors are minimized. When they're not followed, well... you probably deserve whatever you get. By the same token, people should lock their car doors and take their keys with them after exiting. People who don't follow this basic procedure and leave the car unlocked with their keys in the ignition risk having bad things happen to them. It's mostly common sense.

All that said, if there are specific vulnerabilities identified in a particular voting system, those vulnerabilities should be addressed. To treat it like the coming of the apocalypse a la Bev Harris is silly. Microsoft released updates to Windows for three "critical" security issues this week alone. Does this mean nobody should run Windows? Hardly. Does it make Windows a bad system? No, it means somebody missed something in a large, complex system (although I do admit to knowing several Linux purists who will claim everyone should dump Windows and switch to Linux instead, so maybe my example is a poor one ;) ). So if there's a real issue with a Diebold unit, Diebold should simply fix it, then certify and make available a new release containing the fix. Security issues in all kinds of software are reported literally all the time. Big deal.

Pardon me if I am asking you to repeat yourself, but since I gather that this exploit doesn't make your list of major security concerns, what does?

That's a good question, but kind of a tough one to answer. I'm actually reserving judgment on the severity of this particular exploit pending some more investigation... I'm not classifying it as major or minor at this time, since it's impossible to tell based on Ion Sancho's willful ignoring of basic procedures.

But in more general terms, major security concerns (to me) include anything that can be perpetrated without detection, assuming realistic operational procedures. The ability to make "wholesale" manipulations of the results (e.g. for a whole jurisdiction at once) versus a more "retail" attack (e.g. for individual machines) increases the severity of an issue, in my view.

Attacks that are described as "an attacker could do X if procedure Y was ignored" aren't that interesting to me. "You can remove and modify a memory card if nobody inspects the tamper seals". OK, fair enough. But "my house could blow up if nobody turns off the gas oven" too, although I'm not going to lose any sleep over it. My statement holds true as long as "Y" is actually reasonable. Inspecting tamper-evident seals is reasonable, in my view. Asking a poll worker to execute a dump of memory card contents to a local computer and perform a binary comparison against a trusted copy of the expected data is something that might equally detect tampering but it isn't a reasonable procedure to require. On the other hand, asking a poll worker to verify a hash value printed on the report tape by the voting machine firmware is something that I'd classify as reasonable.

I could go on, but it's late and I'm tired. Besides, I don't have any specific vulnerabilities to post here about any voting system I'm familiar with -- and even if I did, it would be foolish and irresponsible for me to post them here anyway. :) More responsible would be to document the issue and any exploit of it, and to submit that to the vendor in question so that they can investigate and/or fix it. Trying to ambush a vendor (whether it's Microsoft, or Apache, or the Linux group, or Diebold, or whoever) by publishing a perceived exploit without notifying that vendor first is irresponsible and juvenile.


Neil

[kster]

29. The truth about the election theft machines will get out, WATCH

Good Luck to you.

[OnTheOtherHand]

30. fair enough; I have at least some differences of emphasis

At some point we might need a codicil to Godwin's Law to cover Bev Harris -- somehow she keeps commandeering all the arguments. ;) Just as a general matter, there are a couple of (overlapping?) circumstances in which I think it would be reasonable to publish a perceived exploit, although probably not in excruciating detail. One is if one thinks that DREs (or perhaps the current implementations) are inherently misbegotten, and so any chance to make them look bad ought to be seized. Another is if one thinks that election officials are unaware of the equipment's vulnerabilities, and that widely publicizing them is mostly likely to shock them into enforcing the basic procedures that secure the machines.

In Ohio, we saw recount protocols subverted in county after county, in my opinion because boards of elections hadn't given the least bit of thought to why actual random selection would be important to enhance public confidence in the result of the recount -- or why it would be a problem to have election techs tinkering with the machines and posting cheat sheets. That's the benign interpretation. For various reasons I don't think there was massive vote count fraud in Ohio. But -- although I take your point about reasonable procedures that secure the system, we also have to anticipate reasons that the reasonable procedures might not be followed. I don't mean that we should assume that everyone is crooked and/or incompetent, just that we need to take the wetware seriously. Hey, when poll workers roll out of bed at 4:30 AM to set up, do they know the "X" most important things they should do to ensure a fair election? or are they just blearily hoping that everything will at least look like it works? (And likewise for all the other people who, by and large, are making good-faith efforts to do the right thing within a system that they may not understand.)

It would be foolish and irresponsible to post specific how-to-hack-an-election instructions here, for sure. I tend to be of the school that says that the Bad Guys have probably figured out the holes already, so the Good Guys need to know what they might have to defend against. At the same time, I think your analogy to Microsoft is apposite. Folks who publicly reveal specific Windows vulnerabilities -- rather than quietly reporting them to Microsoft, in circumstances where Microsoft has both the means and the incentive to patch them -- are probably feeding their egos at other people's expense. Or they might be members of the Linux Liberation Front, as it were... which still might amount to feeding their egos at other people's expense. Whatever.

[eomer]

33. But the problem is that someone else is in charge of the keys to my car.

"When correct procedures are followed, a lot of potential attack vectors are minimized. When they're not followed, well... you probably deserve whatever you get. By the same token, people should lock their car doors and take their keys with them after exiting. People who don't follow this basic procedure and leave the car unlocked with their keys in the ignition risk having bad things happen to them. It's mostly common sense."

That would be a fine way to look at it if the person being careless with the keys is the one to suffer the consequences. Unfortunately in this case when the keymaster is careless then the consequences are borne by the citizens, not by the SOE.

To modify your analogy a bit to make it more representative of our situation, if my SOE doesn't follow the correct procedures... do I probably get what I deserve?

And what about the situation (which surely has happened somewhere in the country sometime in recent years) where the SOE is getting a result that (s)he desires, which is a fraudulent result. Do I get what I deserve in that case?

As OTOH can tell you, I'm pretty disgusted with the performance of various BOEs and SOEs, especially those involved in the Ohio recount. I'm thinking we're going to have to take away the keys to the car until they can learn to behave more responsibly than a bunch of drunken teenage boys.

[OnTheOtherHand]

34. since Mr. Forzod can no longer continue the conversation...

Right, the analogy of protecting personal property really breaks down when multiple actors are involved. The car analogy isn't totally useless if one interprets it more generally: that in risk assessment and management, it's important to think systemically. Of all the threats that are posed by unreliable elections officials, vulnerability to the Hursti Hack may not be in the top ten, and highlighting -- and even preventing -- the Hursti Hack might not get us any closer to verifiably honest elections. But as far as whether "you probably deserve whatever you get" (and I do hear people say that "we get the government we deserve"), well, at best that is confusing the issue.

If our problem is that we can't trust our elections officials, then that doesn't mean that we don't have a problem. To the extent that e-voting (or anything else) makes it harder for even the best elections officials to run verifiably clean elections, and/or makes it harder to detect dishonest officials, of course it makes matters even worse.

[Karmakaze]

31. Hmm such a detailed analysis - yet you missed somthing... why?

"c) access to all the target memory cards after they've passed testing, been locked in the machines and protected with tamper-evident seals, and had their counts reset, as well as sufficient time before the election to manipulate them, and a way to cover-up the destruction of the tamper-evident seals;"

OR

The tampering could happen AT the testing stage? Did you not think of that? So the people who test the cards actually tamper with them, then hand them over to be locked away so no one else can check them. Seems like a single point of failure to me. And we know that there have been funny goings on at this stage in the past, including uncertified patches being made to machines just before the election.

Tell me, are Diebold employees involved at the testing stage? It seems from past experience they are.

[OnTheOtherHand]

32. I've been (ow) thinking about this

The first thing that occurred to me is that it is of limited value to ponder whether Forzod is a reliable source on this point, because there may be no reliable source: perhaps no one in the world can say definitively who is "involved at the testing stage." Different states and counties have various policies about what is supposed to happen, and then there is the question of what actually happens. So one might believe that a particular person is reporting what s/he knows to be the procedure in a particular jurisdiction, or what s/he has seen in several jurisdictions, or what s/he has been told is procedure in many jurisdictions, or what s/he would nefariously like us to believe is procedure universally, or whatever.

Conceptually, the way it is "supposed" to work is that public Logic and Accuracy testing is done, then the systems are zeroed out and sealed. (http://www.cs.uiowa.edu/~jones/voting/testing.shtml) Conceptually, there is no reason for vendors to be involved in the testing. Testing is a distributed process, so tampering at the L&A stage is not a single point of failure.

Ah, here's a snippet of a Florida FAQ. This is about touchscreens, not optical scanners, but the approach "should" be the same regardless:

Q. Is an audit conducted on touchscreen machines prior to an election?

A. Each, individual machine must be certified by the state and is subjected to rigorous
logic and accuracy testing by local Supervisors of Elections and their staff before every
election. The public is invited to attend and witness this testing to assure public
confidence. Once the logic and accuracy testing is completed, all of the machines are
secured for the election.

http://election.dos.state.fl.us/pdf/undervotefactsheet.pdf

Sounds good. Is it as good as it sounds? Probably not. Is it radically vulnerable to distributed attack by a hypothetical nefarious vendor? Umm, possibly, although it doesn't seem to me that the Hursti Hack would likely be the H.N.V.'s method of choice for an attack during or prior to L&A. (Incidentally, in Georgia 2002, it seems that Diebold probably could have done just about anything.)

[Peace Patriot]

5. "...the state will seriously consider Sancho's complaint..."

Right.

[driver8]

6. I feel better now that Jeb is on the case. I am sure we will get to

the bottom of this ASAP. I am also pretty sure that there will be no problems found.

[kster]

9. Yes, Jeb is on the case

[sunshinekathy]

7. Insiders are the biggest threat to any system

Bev, Hari, et al did not have the source code to my knowledge.

However, any reasonable test of a system requires insider access since insiders are the biggest threat to any system and are where the vast majority of hacking attempts against any system comes from.

Jeb's objection just shows pure ignorance of the principles of protecting any computerized system - which involve evaluating the risk to the system from insiders where the tampering most often comes from.

That is why "independent" audits are performed for all other institutions in America - performed in a way that is independent of insiders within the system, and that is why any serious attempt to test a system gives the testers everything.

Obviously Bev and Hari were not even given the source code like they should have been, because they would need Diebold's cooperation to obtain the source code. The source is compiled into machine language on the Diebold machines which they tested and I know they did not reverse engineer the machine code into assembly language and then decipher the assembly language because that takes many months to do for all the programs on the Diebolds, especially as they run on Windows and any one of the operating system software or hardware drivers can be corrupted.

So, even without full insider access, the two computer scientists Blackboxvoting used in Florida found out that Diebolds are a hacker's dream.

[Neil B Forzod]

18. not entirely accurate

Bev, Hari, et al did not have the source code to my knowledge.

Actually, they do have the source code to the old AccuVote-OS firmware, and to the ABasic report compiler that was used to prepare the fraudulent report scripts used in the test. Hursti points that out in his original paper.

Neil

[foo_bar]

11. source codes?

Do the Bushes just pluralize everything to be safe, like the internets?

So, about the hack (hacks?):

The Hursti Hack requires a moderate level of inside access. It is, however, accomplished without being given any password and with the same level of access given thousands of poll workers across the USA. It is a particularly dangerous exploit, because it changes votes in a one-step process that will not be detected in any normal canvassing procedure, it requires only a single a credit-card sized memory card, any single individual with access to the memory cards can do it, and it requires only a small piece of equipment which can be purchased off the Internet for a few hundred dollars.

http://www.bbvforums.org/cgi-bin/forums/board-auth.cgi?file=/1954/15595.html

So it's the "switch the briefcase" scheme? If you need one insider, one programmer, and a doppelganger memory stick, it's not the most elegant hack (especially if you have to physically remove the original card, unobserved, then destroy all evidence of its existence). It comes down to the same "chain of custody" problem, you don't need a hacker and a hundred memory sticks to spirit away the optiscan ballots in the first place; setting things on fire has been nearly perfected since the neolithic. If nobody is watching the watchers, all systems, even paper-only ones, are intrinsically hackable (per Bruce Schneier, and Katherine Harris by implication).

[OnTheOtherHand]

13. probably the biggest danger is a BoE tech

who presumably could set up a lot of machines wrong the night before. (If I interpret Sancho right, that's what bothered him.)

It's not so elegant as a way of stealing lots of votes in lots of places, but if you can get away with it in a few big counties, you could steal more than enough for many purposes.

Yeah, every system has vulnerabilities, but that one is bad, because there is (apparently) nothing poll workers can do about it.

[foo_bar]

14. damn that Board of Ed!

I knew those Regents were up to no good!

In fact, however, Hursti had pre-loaded the memory card with plus and minus votes.

The eight ballots were run through the optical scan machine. The standard Diebold-supplied "ender card" was run through as is normal procedure ending the election. A results tape was run from the voting machine.

Correct results should have been: Yes:2 ; No:6

However, just as Hursti had planned, the results tape read: Yes:7 ; No:1

Why 7-1, not 700-1? Well, because there's only 8 living voters in the scenario. You'd also end up with negative vote totals if you overestimated your opponent's turnout (e.g., preloading -700 Kerry +700 Bush in a precinct with 500 Kerry votes), and also if you underestimated your faux-candidate's votes (the counter wraps around at 65535 according to the BBV whitepaper). The laboratory hack has foreknowledge of the "correct results", so +5/-5 is known not to violate these contraints. If the hacker got greedy and preloaded -10/+10, the report would spit out Yes: 12, No: -4, which would hopefully raise some kind of red flag. So close elections can be stolen (per usual), but you can't just swap the totals beyond n% without reliable poll numbers, or swapping the briefcases after the election but before the count (which puts a damper on night-before scenarios).

technical edit: if the counter really is an unsigned 2-byte integer, the +10/-10 scenario would show "Yes: 12, No: 65531"

[OnTheOtherHand]

15. helpful distinctions

What this hack doesn't begin to demonstrate is some ability to Just Make Up the election results without being detected. The negative-vote constraint is just an extreme case: a (say) 40% swing anywhere would tend to stick out.

(Some folks are thinking: hey, how about Ohio 2005? Answer: county by county, the results line up pretty well, and that is across various voting technologies. Despite the mail poll, Ohio 2005 doesn't look like fraud at all, unless one thinks that the evildoers control every county board, in which case it probably doesn't matter what the voting technology is.)

One probably can steal oh maybe 5% net? in any county without it becoming a gross outlier, but if one can't do that in a lot of counties, it really is only likely to determine close races. (And I don't mean to imply that stealing 5% in an entire county, via this particular hack, is a slam dunk.)

And then, ironically, the 2004 exit polls tend to indicate that this didn't happen (at least on a large scale) in 2004 -- but let's not go through that again.

Still, it would be nice to know that if a zero tape reads zero, that means that the candidates are starting at zero. (Or, failing that, that a random recount is liable to catch any systematic 'anomalies.')

[foo_bar]

16. the smoking gun wouldn't just be a statistical anomaly

In the 2-6 example (let's say Dixville Notch NH), preloading +-7 would leave negative votes in one column and undead voters on the other. So the lower bound for plausible negative ballot-stuffing is (the actual turnout for your candidate), which you need to guess correctly in advance. So the +-5 hack would have failed if the correct results were Yes: 5, No: 3 (-> Yes: 10, No: -2 or 655..). It's like the Producers, you have to be sure your candidate is a flop (or isn't).

[OnTheOtherHand]

17. well, Dixville Notch is rather the anomalous case

Just as a basis of comparison: the average Ohio precinct had about 480 votes. So in _almost_ every precinct, one could safely flip, oh, 20 votes without fear of going negative -- although not necessarily without fear of detection.

Of course, if one doesn't know where each machine is going, then one might have a problem.

[foo_bar]

19. agreed, but that's the analogous BBV scenario

Their test case changed 2:6 to 7:1, evidently to illustrate a 'flipped' outcome (75-25 No to 88-12 Yes). Without extrapolating it to an Ohio precinct, the hack would be immediately exposed if the "correct vote" had more than 3 Yes's, which is 5 of the 9 scenarios:

0, 8 -> 5, 3
1, 7 -> 6, 2
2, 6 -> 7, 1
3, 5 -> 8, 0
4, 4 -> 9, -1
5, 3 -> 10, -2
6, 2 -> 11, -3
7, 1 -> 12, -4
8, 0 -> 13, -5

So yeah, a 126 point swing isn't the greatest example. A 20/480 swing in Ohio makes more sense, but it probably doesn't make as good press coverage.

[OnTheOtherHand]

20. natch -- but I won't fault Hursti

(or whoever, but Hursti implemented it, right?) for demonstrating a clear-cut case. Percentage-wise it might be more "realistic" if he had switched 6:3 to 5:4 -- but it might also have given some people the impression that one could only shift one vote at a time.

The problem is that some folks have a syllogism going: 'The Bushies woulda stolen it if they could; fraud was possible; ergo, the Bushies stole it.' With a little rhetorical goo, one can make it sound tautological, but it does actually skip a lot of steps, as you and I agree. The demonstration is more compelling as a warning of what we should protect against in the future, than as evidence of what happened last time. (And I also agree that if we just get stuck on Electronic Bad, Paper Good, that will cause all sorts of problems.)

[foo_bar]

22. why demo a precinct with 8 people, anyway?

Whitehat props to Hursti, but the reality seems to be high risk/high gain vs. low/low, not switching 63% on the assumption that your issue always loses, which would backfire more than not.

[OnTheOtherHand]

23. at least one of us perhaps is being too literal?

Seems to me, you demo 8 people because it is a lot quicker than demoing 500 people -- you want to illustrate a hypothetical full day of voting on a machine. The specific number of votes is really not the point, at least for Hursti.

That said, let me stare long and hard at Neil's latest post. It's one thing to second-guess the nuances of the demo, another to figure out what the demo Really Means.

[foo_bar]

24. it's always a possibility

I defer to the blueprint analysis, I only wonder if/how the simulation reflects reality.