The Election Software Supply Chain
February 23, 2006 by PingIt wasn’t all that long ago that I first heard the phrase “supply chain attack.” I think the phrase “supply chain” more commonly refers to manufactured goods — a supply chain analysis of a manufactured product would involve questions like: What parts are used to make this product, and from where are they imported? Who makes those parts, and where do they get their supplies from?
The same kind of analysis can be applied to software. In software, everything is produced by using a piece of software to transform something else. The only exception is input that originates from a human being. For example, a compiler transforms a piece of source code into a binary executable. A CPU transforms a machine-language program into a running process. Roughly speaking, the user interface of a text editor transforms user input into a text file.
So I started asking myself these questions. Where does the election result come from? What produces it, and where does that come from? And so on. The result was this big diagram:
(Also available as a 157-kb PDF.)
In this diagram, each arrow is a transformation step. The legend in the upper-left corner looks like this:
Rounded boxes are “original,” that is, they don’t come from a transformation of anything, and as we noted previously, they can only be produced directly by humans. One of these rounded boxes is special — the input from the human voter — in that it must be kept secret in a properly conducted election. Everything else is a rectangle, derived from something else. (The dashed rectangles prevent the whole thing from turning into a hairball; look for the corresponding solid rectangle with the same label to see where each dashed rectangle comes from.)
At various points in the diagram there are boxes without borders, which represent hardware. I stopped chasing down the supply chain whenever I got to a piece of hardware. Presumably one could continue past that point — a fab is a process that transforms a chip specification into a CPU chip; the chip specification is produced by a Verilog or VHDL compiler; and so on. But I didn’t.
Here’s a look at a small part of this diagram, the part that concerns the actual voting on election day:
The voter interacts with the DRE’s user interface to produce a recorded ballot. The user interface is not produced directly by a program, however; what the user interacts with are the UI devices of the DRE (the display, touchscreen, buttons, and so on). These devices transform a running program (a process taking place in the electronics inside the box) into a user interface. The running ballot program is produced by parameterizing the DRE program with information about the ballot. The arrow coming in from the left side in the above picture is the ballot specification, which is produced by a software tool used by the election officials.
Going through this exercise helped me realize that a computerized election system has a huge number of dependencies. In today’s election systems, where none of the software is formally verified and no source code, binaries, or intermediate results are published, every single one of these boxes is a potential point of vulnerability to a design flaw, an implementation flaw, or an attack.
February 27th, 2006 at 01:00
Good clarification!
Electronic voting systems are usually considered to be more or less “single box” (in a graph describing e-voting). Taken the complexity of the system, it is pretty much evidet that most people have absolutely no possibility to understand how e-voting really works. So, trust to voting system must be established independently. It practically requires paper receipt.