|
Okay, the voting is over—and now the fun commences.
December 12, 2006
URL:http://www.drdobbs.com/embedded-systems/root-the-vote-the-hard-and-the-soft/196603544
Ed is an EE, an inactive PE, and author in Poughkeepsie, NY. Contact him at [email protected] with "Dr Dobbs" in the subject to avoid spam filters.
Embedded systems tend to be, well, embedded in everyday life as cable modems, gas pumps, entertainment equipment, watches, hearing aids, automobiles, even light switches. Absent a malfunction, such as having your car's security system lock you inside, we generally ignore the myriad computers surrounding us.
That's changed with the advent of the electronic voting machines now replacing aging mechanical and paper balloting devices across the United States. Esoteric topics such as encryption, paper trails, reliability, back doors, and even human factors have become fodder for the mainstream press. Whether most folks understand the underlying problems remains to be seen, but one branch of embedded systems design is much more visible.
My April 2001 column covered vote-by-wire topics, and unfortunately, we now have real-world results from full-scale deployments and independent (albeit unauthorized) teardown analysis of electronic voting machines to show that some of the predictions have come to pass. The optimistic view, that the worst of the problems hasn't occurred, depends on a lack of evidence; those problems may simply be lying in wait for a propitious moment.
Here's what I see in the current reports, summarized in rules useful for evaluating any proposals that come your way. You should definitely follow the links at the end of this column to read the original reports, where you'll find examples of the points I mention.
By virtue of publication lead time, I'm writing this before the November midterm elections and you're reading it afterward. That gives you the ability to see how my rules apply in practice.
Rule 0: Hardware access trumps software security.
As we've seen with devices ranging from media players to cable modems to routers to game boxes, physical access to a device negates any attempt to secure its software contents. No matter how complex the hardware security, someone will defeat the interlocks, break or bypass the encryption, and gain unlimited control of the device. All it takes is time and motivation.
Voting machines have an extremely low duty cycle, spending nearly their entire lives tucked away in warehouses between elections. Governments, particularly local ones, seem unaware of the need for rigorous security, particularly when a single access can compromise a machine's functions forever afterward. It seems social engineering no more complex than knocking on the door has already gained unsupervised access to a voting machine warehouse. (Editor's Note: Recent news reports bear out this concern to an alarming degree. In some districts, election volunteers take the voting machines home because election officials failed to plan for their storage.)
Rule 1: Debugging access means total control.
Voting machines resemble any other computer-based electronic device, with all the usual parts and connections: CPUs have JTAG ports, boards have debugging ports, and external memory sockets support bootable devices. As a result, side-channel attacks work perfectly well.
Essentially all nontrivial digital chips include features designed to help get a new board up and running. Use of appropriate debugging tools, plus access to the hardware, negates all the security features built into the code, because the attack occurs below the software level.
Huang's 2002 XBox exploit used common electronics lab hardware tapped into the XBox system board's HyperTransport bus, much as an engineer might monitor those signals during development, which means even buses exposed on the circuitboard provide an attack path between well-protected chips.
Rule 2: There's no such thing as a hidden feature.
Omitting the external interface drivers and connectors for debug-enabled chips doesn't make those features go away. As anyone who's developed such hardware can attest, bringing up a board lacking debugging features makes for protracted, late-night, hair-pulling sessions. Shipping two boards, one with debugging hardware and another "identical" one without, doesn't work, either.
Photos of system boards in Diebold voting machines show option-select jumpers, JTAG connectors, several types of socketed memory, and other familiar doodads. Although those features may not be accessible with the covers screwed down for normal use, they provide convenient access for anyone in physical possession of the machine.
Omitting those interface parts and pads makes no difference, as attackers can deploy clamp-on adapters, hand-built extension boards, or in a pinch, flying leads to unsoldered pins. There's simply not enough money in the voting-machine business to design truly one-off chips or hardware.
Security by obscurity, the practice of not documenting circuitry or code, has little value in a design using commodity hardware. Datasheets, app notes, and reference designs festoon manufacturer's web sites, and even if a particular chip isn't well documented, attackers can begin reverse-engineering easily enough by noting where it fits in a hand-drawn schematic extracted from the hardware.
Rule 3: Mass production enables mass attacks.
Voting machines will never reach the mass-market production levels of consumer electronics, but a few thousand of anything starts to look like a standard. A single successful attack can therefore compromise security across an entire line of identical machines. Extending that attack to a line of similar machines requires far less effort than a completely new attack.
For example, the mechanical lock securing the case of the Diebold Accuvote-TS machines resembles those in hotel minibars, filing cabinets, and other low-security enclosures. Keys available from the usual office-supply sources can open the enclosure: It's a standard part with relatively few unique keys.
The knowledge gained by physical possession of a single machine can create a different attack through far less intrusive means. For example, Feldman, Halderman, and Felten developed a proof-of-concept virus that spreads through official Diebold memory cards used in the normal operation of the machines. A single compromised machine can inject an attacker's code into all the machines in an election district, using the district's own hardware, personnel, and standard procedures.
Rule 4: What one engineer can design, another can figure out.
Put differently, nobody's much smarter than anybody else. Voting-machine hardware design must assume an attacker has more knowledge, better equipment, and far higher motivation. The simple fact that no equipment can withstand such an attack should be obvious, but you don't hear that from the vendors.
Increasingly complex hardware and ever-more-baroque encryption do not provide the solution, because voting-machine hardware represents only part of the problem. The overall voting process must achieve documented reliability despite compromised hardware and corrupt personnel; at a minimum, error detection using multiple cross-checks external to the voting machines must be part of normal operation.
Rule 0: Software is not mechanical.
The WIMP (window, icon, menu, and pointer) mode of interaction often convinces us that software has physical reality, with pointers to move, sliders to drag, buttons to push, windows to overlap, and so on. The utter falsity of those metaphors goes unremarked in normal use, because designers expend great effort mimicking what we experience in real life.
The occasional mismatches can be devastating. For example, most people know that deleting a file makes it go away, a few know that the file may subsequently be recovered from the Trash (at least, sometimes), and everyone knows that emptying the Trash makes the file vanish completely. After all, that's what those operations do in real life, don't they?
Perhaps a better metaphor for emptying the Trash would be "putting the can out for curbside pickup by anyone," but it's not clear how to represent that with a glassy icon. Yes, some Trash folders have overwrite-on-delete options, but nobody knows that.
Software's lack of physical attributes invalidates all our metaphors and assumptions. As a consequence, things that should happen don't, things that can't possibly happen do, and our real-world experiences must not guide our assumptions.
Tampering with a mechanical voting machine leaves traces: bent levers, shaved cams, or perhaps filed-off gear teeth. After the fact, a straightforward inspection can reveal that votes were not recorded correctly, and even if you can't recover the correct values, you're aware of the problem.
Attack software running on a voting machine can manipulate the votes during the election, erase itself from both Flash memory and RAM, and leave no trace behind. No examination can find erased software, as nothing remains to be detected: An after-the-vote inspection will show only original, approved, certified software. If the altered vote patterns seem more-or-less reasonable, there will be no reason to suspect foul play.
Rule 1: Software is not visible.
Contrary to the friendly GUI metaphor that lets us think we're in control, we interact with software only on its own terms. Absent any provision for a user interface, software runs silently, invisibly, and uncontrollably.
The user interface of an electronic voting machine won't change after attack software has compromised its function, so simple observation can't detect the problem. Worse, testing the device cannot reveal hidden functions that do not change its behavior. Unless you know what the attack software will do, you almost certainly won't stumble over it through the user interface. You might, if you're lucky, detect anomalous voting patterns.
Conversely, attack software may present an invisible interface of its own: A "secret knock" involving no more than a sequence of taps at specific, albeit nominally inactive, touch-screen coordinates can activate hidden functions. That's not a practical mass-attack interface, but it can activate or control a preinstalled virus on a key machine.
Rule 2: Bad software drives out good software.
Some years ago, I read of an electronic gasoline pump that shortchanged customers by delivering less gasoline than indicated on its LCD panel. Surprisingly, the pump always passed the weights-and-measures inspection by delivering the correct amount to the inspector's 10-gallon can. It simply slowed delivery after 10 gallons, while continuing to tick the digits at the normal rate: If you paid for 20 gallons, you might get 18.
More recently, I attended a meeting that attempted to explain the electronic voting machines that will be used in our local elections. The number of test ballots required for each machine and the manpower required for each election defies description, but it's an effort that seems largely futile: Absent a hardware error, the machines will always produce the expected results during testing.
Testing can reveal the presence of errors that produce deviations from the software specifications, but generally cannot reveal crufty code that's either nonfunctional or is activated by undocumented inputs. Worse, no amount of testing can ferret out attack code designed to remain hidden, if only because of the number of "impossible" input sequences that could activate it.
In the simplest case, attack code can remain dormant until Election Day, move votes from one candidate to another without altering the total number of votes, then erase itself. That would pass every imaginable test administered through the normal UI, while corrupting the election beyond repair.
Worse, after a voting machine has been compromised, it cannot be restored to "factory certified" condition by any update process requiring code running on that machine. Because attack code can gain control during the system's boot process, it can mimic a successful update while remaining in full control.
It should be obvious that the only way to update code on a compromised machine is through a hardware interface that does not execute any code. As we've seen, though, a hardware update socket provides a convenient entry point for an attacker, so overall system security must reside outside the voting machine.
Rule 3: What one programmer can design, another can figure out.
As with hardware, you must assume the attackers are smarter, have better tools, and really want to get inside the voting machine's software. Writing code to compromise ordinary PCs has become a financially rewarding enterprise that attracts criminals, so what can we expect of software that directly affects national politics?
Pulling off a successful vote-fraud attack on electronic voting machines requires considerable skill, which means it won't happen immediately. In fact, I'd be surprised if any of these attacks occur in the next two election cycles, if only because reverse engineering requires both time and testing on a reasonably stable inventory of machines. We haven't deployed enough machines for long enough to make an attack practical.
However, even an "unsuccessful" attack will be devastating if it's widespread enough. An attack that simply crashes a district's voting machines could invalidate an entire local election. Consider the history of PC viruses. The earliest ones displayed amusing (at least, to the creator) messages; subsequent ones either crashed the PC or deleted files; and nowadays, viruses tend to install silent keyloggers or enlist the PC into a botnet. Because the results have economic value, programmers working for money, rather than artistic effect, produce the most recent viruses.
We won't see many amateur voting-machine attacks, except on the local level for relatively small elections. We will see national-scale attacks produced by teams with national-level resources, simply because the stakes are so high and the result is so attractive. Whether those teams work abroad or within our borders remains to be seen.
In reality, we probably won't see those attacks unless we're very, very lucky. We might, possibly, detect an attack after the fact, but the current security surrounding electronic voting machines makes even that fairly unlikely.
Remember: They're smarter, have better resources, and display more motivation than anyone you can hire.
Next month, I'll take a look at the human side of the voting-machine mess. As you might expect, nothing is simple.
A button on the 1994 BMW 535i's RF keyfob activated a double-lock feature that could only be canceled by inserting the key in the door lock. Too bad if you were inside the car with the windows rolled up.
Cell phones use the same misleading metaphors as PCs and their deleted messages remain in flash memory, as described at www.cnn.com/2006/TECH/ptech/08/30/betrayed.byacellphone.ap/index.html.
Cuyahoga County produced a massive report on its electronic voting experience. Read it and weep at www.votingintegrity.org/pdf/cerp_rpt06.pdf. The minibar key incident is described in Felten's blog at www.freedom-to-tinker.com/?p=1064.
Analyze the Diebold hardware at itpolicy.princeton.edu/voting/ts-paper.pdf and www.bbvdocs.org/reports/BBVreportIIunredacted.pdf. A reliability study for some machines: www.votetrustusa.org/pdfs/DRE_Reliability.pdf. Avi Rubin's day at the polls: http:// avi-rubin.blogspot.com/2006/09/my-day-at-polls-maryland-primary-06.html.
Info on my local Dutchess County Verified Voting group is at www.mhvv.org. Legislative gridlock maybe a Good Thing, see www.newscopy.org/voting_machines/index.html.
The NASA Lessons Learned database I mentioned in the last column has moved to www.nasa.gov/offices/oce/llis/home.
The local LUG mailing list provided some numbers for operating systems found on a local arts-and-sciences college campus network: Windows 90 percent, Macintosh 9.6 percent, Linux and UNIX 0.4 percent. However, a friend reports a local liberal-arts campus has Apples at 30-40 percent and yet another reports 60-70 percent. None of that seems relevant to the real world.
Rich Marvin, Onset Computer's Education Manager, ran my e-mail up the flagpole and reports that Onset will be tracking requests for a Linux version of its data logger software. Now it's up to you: Vote early, vote often!
Terms of Service | Privacy Statement | Copyright © 2024 UBM Tech, All rights reserved.