With optical scan voting machines, there were still some drawbacks from the point of view of election administration. First, there were all those ballots to print up, distribute to polling places, make sure there were enough of them if there were multiple languages that needed to be supported you need to, needed to make sure there were ballots and all of them you needed large print ballots for people who had poor vision. Then at the end of the election you had all of these physical paper ballots to store and watch out for and, and take care of. Because of these issues the next generation of voting machines to be introduced, eliminated the paper ballot entirely. These are what are, are known as DRE voting machines. Dre stands for direct recording electronic. And direct recording, means that the machines function in a, a similar way to a lever machine. Inside the machine there's a, an electronic computer controlled counter that maintains a record of each vote. But unlike an optical scan machine in a DRE generally the only record of the vote is something that's stored in a computer's memory. It's the equ, the computerized equivalent of that mechanical counter on the back of the lever machine. And the first generation of theories to be introduced. And they, they started to be introduced around the, the late 70's and early 80's, looked like this device on the left. Very, very similar to a lever machine. It's a gigantic refrigerator size device, but in this style of machine, there's a piece of paper that indicates all of the voter choices, the ballot choices that is overlaid on top of the grid of mechanical switches, buttons the voter can press. In this way the entire ballot can be presented without any kind of computer output device. You just need the, the switches has a kind of input device to figure out where the voters to, to sense the voters choices. So this was the, the original style, very relatively simple to construct. But inside that box, instead of gears and levers, like in the lever machines, we have a computer and computer memory. Around the 1990s a new style of DRE came into use. And this was the, the touch screen DRE. The late 90's, these were first coming to market. And, they became, in very widespread use. After the 2000 presidential election, when many states replaced their punch card machines and other older styles of technology like lever machines with DREs like these. The touch screen machine displays the ballot usually page by page like the butterfly ballots we saw with the punch scan system with the punch card system rather. In this way the information on the ballot can be adapted to, to the voter. The DRE can, the touch screen DRE can show a larger or smaller font size or a ballot in a different language or a different kind of ballot depending on the voters' party or where they live. All of this even further simplifies the process of election administration. So I want to walk through the process of conducting an election with a typical DRE. And this is going to be this model, the Diebold AccuVote TS which was for a while the most widely used DRE voting machine in the U.S. When voters come to the polling place they sign in and then the election officials make sure they are registered to vote in that jurisdiction and then each voter is handed a plastic card, a smart card that has a chip in it. This is used to authenticate the voter to the voting machine and allow them to cast one vote. The voter inserts the card into a slot on the machine and the machine presents the voter's ballot. This is the screen the voter sees before they insert the card. After inserting the card, they're presented with a series of choices like this one. So they just have to touch the target area there on the left, for the candidate they want to vote for. Here you see a vote for George Washington. The voter clicks next to go to the next page, and so forth through each of the races. And at the end of the election, the voter's presented with, a review screen or a summary screen like this. That shows all of their choices for each of the races. In this example we just have one race, and so that's all that's displayed. You can see this is much smaller than the text on each other screen of the ballot. But it's trying to show all the races in one place. At that point the voter touches the cast ballot button there on the bottom, and the vote is cast. Other voters come in to the polling place and work the, vote the same way. All of these votes are being recorded inside the machine's memory. At the end of the election, one of the poll workers has a special kind of card that's a supervisor card. They insert that into the machine. And the supervisor card gives them a special screen with some other features, including the ability to close the election and to print out a paper tape that has the results. So here's a machine printing a tape that looks like a cash register receipt. These aren't very durable but the advantage to this style of printing is it doesn't require separate ink. It's called thermal paper. When the election officials print this tape, they sign it the signatures of witnesses and the, the tape is sent to the election headquarters to be totaled up with total, with votes from other machines. But note that this tape only shows the total number of votes for each candidate. It doesn't show any record of each individual vote. In addition to the tape, the machine has a another copy of the votes that it's maintaining on the memory card like the optical scan machines that we talked about. So the election officials remove that memory card with it's record of the votes and send that with the tape to the election headquarters. At election HQ, the officials have another kind of machine, a card reader attached to a computer into which they insert each of these cards and they have special software at the head quarters that totals up the votes from every machine. Those totals are the basis for what they announce at the end of the election night the, the results the results of the count. So now you have some sense of the procedural components of DRE voting. I want to ask one more time, what could go wrong? It turns out there's so many problems with DRE voting machines that I'm going to need the rest of this lecture and all of the next lecture to tell you about them. But to get started, I'd like to begin with a story. And this is a parable about DRE voting machines that was created by a group of Dutch activists who were opposing the nationwide use of DRE voting machines in the Netherlands. The story begins when a voter walks into the polling place. And he's used to voting the old fashioned way, with a piece of paper and a ballot box. The election officials greet him and hand him his ballot which he fills out in the voting booth as usual. But then he's surprised to learn that the ballot box is gone. The officials explained that it's been upgraded. They've installed the new magic vote black box two, a DRE voting machine. The process now is that the voter takes his ballot up to the machine and a hand reaches out from behind a curtain. The machine announces that the voter has voted and then shreds the paper ballot. At the end of the polls, the voter gets to observe as the election officials close the election. They go up to the voting machine and ask it for the results. After a minute, a hand pops out from behind the curtain again, this time holding a piece of paper with the election results. But, aren't the election officials supposed to be counting these ballots, the voter protests, and how are we to know that they're right? But the officials explain that the machine has been thoroughly tested and government approved, so nothing could go wrong. So the voter in this case is left wondering whether he can really trust the process, and this is actually a very close analogy to what's happening with the DRE voting machine. But instead of a man behind the curtain, we have a secret piece of software developed by a private company that voters usually aren't allowed to see. So to see why this is a very good analogy for DRE voting in practice and why, why this essential objection of not being able to trust secret software and a secret process inside a machine to count votes is actually a very strong objection. I want to back up a little bit and talk about software. So why can't we just write a computer program that counts votes correctly and then just trust it to, to give us the election results. Why, why isn't that adequate. Well it turns out that there, there's several problems. First, writing software that even does something simple as counting up election results correctly turns out to be really, really difficult. And it's a much more complicated problem than we might initially think. Real voting machines turn out to have, have software have instructions for the machines that are, are may be a million instructions long. So if you think about software it's, it might be a little bit like a recipe for making a cake. But here we have a recipe that's a million lines long. Are each of those steps correct? Have we left out any steps? Are there any typos, any misprints? Well these turn out to be very, very challenging things to get right with software of this complexity. To understand why software is hard to get correct we, we can use an, another analogy. And every programmer in the audience is immediately going to know what I am talking about when I say, any complicated software is going to have problems. But, but for the rest of you let, let's think about trying to write a set of instructions for a machine to follow. Now machines, computers are very, very good at following instructions to the letter. They don't have any ability, of course, to, to exercise judgement, to realize on their own that something is wrong, and take the take some sane course of action in response. Instead, we have to supply all of that for them. So you might imagine trying to give a set of instructions to a robot. Let's say, we want to ask it to go downstairs to the vending machine and bring me a Coke. It's not enough to just say, robot, go get me a Coke. I have to tell the robot how to get to the vending machine step by step, how to open the door, how to go down the stairs. I have to explain to it how a vending machine works. You have to insert the money into the slot. How much money to insert. That you need to push a button, how long to hold the button. How hard to press, when to let go. And how long to wait for the can to come out. And then how to find the can slot. How to insert it's metal arm, or whatever into the slot. How hard to pull to pick up the can. How hard to squeeze it. Have to bring it back to me. And of course much, much more detail than that in real practice. We also have to explain to the robot what to do when an unexpected situation arises. Let's say the machine is all out of Coke. Well how does it detect that? How does it choose another, another option instead. Like maybe I want to tell it to bring me a root beer instead in that case. What if it's out of root beer too? Et cetera, et cetera. What happens in, in other unusual cases. Let's say, the, the vending machine isn't working properly. It's takes the money and doesn't give any, any drink in return. Is the robot going to wait forever? No, we have explain to it, after a certain amount of time to stop and come back and report the problem. Writing real software is a lot like writing a set of instructions like that. We have to anticipate the cases that can arise, test for them and, and write instructions for handling all of them. And, in a, in a real situation even in, in actually asking a robot to go and get a Coke, we'd have to bring, have to anticipate an enormous number of potential complications. So writing correct software that handles all of these cases in, in a sensible way is a problem that is at the very limits of, of human capability. We have just a very small number of cases in which we've written correct software or close to correct software for complicated projects. It's things like a guiding system for the space shuttle, the avionics on an aircraft. Those kinds of software costs tens, hundreds sometimes thousands of times more to develop than consumer grade software like your web browser or the operating system inside a voting machine. And even then occasionally problems slip through. So we can't just expect that the developers who are writing software for a voting machine are going to get it right. It might still have glitches that cause in certain cases for things to go wrong. So writing software that is correct is hard. But writing software that's secure is even harder. Because exactly what an attacker does is look for situations that the developers and testers have not accounted for. And ensure that those situations are going to be the ones that the attacker causes to occur. So it's not just a natural failure, it's a failure that's been forced on the machine by the attacker. And most of the next lecture is going to be for, be focused on looking at some of these failure situations that, that we can make occur in real voting machines in the lab. But even harder than just writing secure software in general, is writing secure software for voting. Because voting turns out to be a very specialized kind of problem. And that's because of this tension between integrity and ballot secrecy. Because we demand a secret ballot, when things go wrong, when there's an error in the count or when there's an attack, it's often very, very hard to catch that. Something could go wrong and we won't even know because the counting process is supposed to be happening in secret. We can't just go back to the voters and make sure each of their votes has been counted correctly. That kind of, of failure detection or correction mechanism is not something that's typically engineerable within the confines of a DRE. So, to focus on some of the things that can go wrong as a result of this, first software running in a DRE can have errors. These errors could be based on design flaws, that the machine is working the way it's designers intended but the way they intended fails to take into account certain major requirements or things that the machine needs to do or there could be implementational glitches or bugs, that is the machine is not doing what the designers thought it would do. All of this adds up to the, the potential for miscounting, for reliability problems. There have been cases where voting machines have been tremendously unreliable and just haven't been able to function within the, the demands of a poling place because of errors in the software development process. The second category of problems are vulnerabilities, security problems, places where an attacker could manipulate the machine to make things go wrong. Software security is the, the, the place we usually focus on. It might also be possible to sabotage the hardware, to manipulate the data if the data's integrity is not protected. The Hursti attack we just talked about with optical scan is an example of a data manipulation attack. There can also be vulnerabilities that lead to privacy leaks, and we'll see a lot of those soon. Finally, just knowing that the integrity of the system is being preserved is a very difficult challenge with voting machines in itself. Even if the, the company that built the machine posts its software to the internet and says everyone can look at it, fundamentally there is no way that we can know that, that software that's asserted to be the voting machine software is actually the software running in the machine. There have been many, many cases where software that's never been tested or certified by a government ends up being the software running in a machine on election day. That's just another opportunity for sabotage for error to be introduced and undetected. Some software in voting machines is also what's called COTS software or commercial off the shelf, a software package developed by someone else and used in other purposes. This just provides a further opportunity for, for problems with integrity because these packages have to be updated every time they change in order to fix bugs and other glitches that have been discovered in them. And they usually in, in U.S. Practice did not have to be re-approved, retested or in some cases even tested at all as part of the voting machine development process. A final integrity problem is, how, how do you even know that, that voting machine in use on election day, is a real voting machine? And next week I'll give you an example of an attack, where look alike voting machines could be subsituted at the poling place and produce dishonest counts. So, all of these are conceptually, things that could go wrong with DRE voting machines, since the only count of the election is something that's been maintained by fundamentally untrustworthy software. But, a, after DREs were introduced, although many computer scientists objected on these grounds there was not any opportunity to, to have independent experts test and verify that these problems did or did not exist in DREs. In the next segment, I'm going to tell you a bit about the first chance that the academic community got to do those tests and what went wrong.
