 I guess we'll just get started. This is increasing the security of your election by fixing it, which, if any of you have ever read Weetsy Venomuk wrote a paper increasing the security of your systems by breaking into them. So it's a bit in homage to that. Just briefly, what this all came out of was the Florida elections in 2000, which hopefully you're familiar with. Depending upon who you ask, some people were very troubled by the events of the Florida election. Others were troubled by the results thereof. But it did highlight that there's a serious problem with the voting systems we have in this country. And in response to this, a number of the commercial voting vendors responded by saying, oh, well, the solution to this is electronic voting. And these are the four major commercial voting vendors. Some of you who have followed security might recognize some of these promises. We've seen this before. These just kind of pie-in-the-sky statements that are just, of course, it's secure. Things like world-class encryption techniques utilized to store election results. And of course, my favorite proprietary firmware and closed system prevents hacker access. So what's the message here? Trust us, we know what we're doing. We have seen this before. But of course, really, these worries, no big deal. The end. Democracy is safe from hackardom or not. Those of you who saw the full disclosure movement arise, this came out for a reason. It's because people were finding bugs in closed software. And they were finding bugs in closed software, and the vendors weren't fixing them. And the vendors could deny that these bugs existed because no one could get a look at the code. So really what this comes down to is verifying that you have a computer that's doing what it claims to be doing. So what's the first thing you do after reading a box? Hide your presence. And the second thing, you patch the hole you came in through so no one else can use it, and so no one else knows the hole is there. So how do you tell someone to read your box? Good question. Forensic analysis is hard, and that's under the best circumstances possible. If you know the system very well and you have access to it and you set it up and you know how it runs, forensic analysis is still hard. So how do you tell if someone's tampering with your electronic voting machine? You don't. And that's because doing forensics analysis on a black box is almost impossible. The fundamental problem here is that we don't have a paper trail. None of the major commercial systems are producing a paper trail. And without that trail, there is no way to tampering. Actually, just one thing I should point out, David Dill, who is a professor at Stanford, jumped on this issue very early on and has been pushing for what he calls a voter verifiable receipt. And that is a piece of paper that shows what you voted for, who you voted for, and that is the record you rely on. So if the computer record is in dispute with the paper record, you go with the paper record. And this is actually something that a lot of people don't find all that intuitive, because they're used to thinking of computers as these sort of magical boxes. Data goes in, you get results out, and of course, the computer doesn't make mistakes, but people do. The problem here is too many secrets. All of the commercial systems are closed. Members of the security community at large cannot scrutinize these systems. And so we just have to trust the vendors. But as I've said, we've seen this before. It doesn't work. Look at Microsoft. Compare Apache to IIS. Apache has had maybe one major exploit in the last two years. IIS, I can't really count them. There's a lot, follow and debug track. The other major problem we have is that we don't really have any data on how these systems work in practice. And it's very difficult to get a realistic test. And first of all, it's because it's expensive. Seeing that actually staging an election is very difficult. Second of all, it's very easy to cheat. It's very easy to put in a system that works for your practice election and does something entirely different under the hood in a real system. And finally, independent third parties can't verify the operations of these systems. And that's because they are closed. The commercial vendors will not allow people to view them without signing non-disclosure agreements. So even if we had good security folks looking at these systems, they can't publish the results. So it's basically worthless. What this really comes down to is that electronic voting systems are arguably worse than paper voting systems. And that's because we understand how you cheat in a paper election. We've been doing it for several hundred years. We know how you can stuff a ballot box and you can make votes disappear. We don't understand how you can cheat in a computer election, because really, it's only limited by the folks at this convention's imagination, which hopefully is very good, but unfortunately is very good. The big thing here is that we don't fully understand the issues for electronic voting, because it's a fairly unique application at the very least because of the non-area requirements. And if we don't understand these, this could leave US federal and state elections open to massive fraud. So we were really, really happy when we got to see a real election system used that was open that we could look at and we could look for holes. So we could see how something performs in the wild and hopefully draw some conclusions about what happens with the closed systems. Because it's very likely that an open system is going to be developed under similar processes to the closed system, and you're going to see similar bugs come into light when you test it. And this was one of the great cavalier quotes by one of the people who was behind the open system used at Berkeley. If paramilitary rebels were to take over voting kiosk and force computer scientists to work day and night, they would still not be able to lodge a single false valid or affect the outcome. As you will see, we didn't need paramilitary rebels, and we didn't really need a team of computer scientists. It was three Berkeley undergraduates. So the Berkeley system is called the online election system. And what's great about it is that we get to see a real election system used in a real scale election. This was used to elect the Berkeley student government. And you should not say, oh, it's just some silly student council election, because Berkeley has 30,000 students. We had 10,000 voters. The student government of Berkeley has a budget that is in the several million dollars range. So there's a lot of money here. It's worth trying to cheat this. So we got to see this in April 2003, which was the first time it was deployed. And it consisted of three pieces. There is the ballot server, which is the actual election piece. There's the authentication layer, which relies on some other technologies deployed at Berkeley, which is basically Cal's Kerberos authentication system, and the polling stations. The ballot server was a web application. It was basically three simple pieces. If needed, redirect the user to CalNet for authentication, send it, check the votes, make sure the user hasn't voted already, make sure they haven't over or under voted, and record the user's vote. This was running on Red Hat 8. And it was implemented using Macromedia Cold Fusion MX and Apache and MySQL. The authentication layer is CalNet. It's Berkeley's Kerberos authentication system, which is employed to be a Microsoft Active Directory. The polling station clients authenticate via Kerberos web proxy. And once they authenticate, they get a signed authentication token. This graphic is probably a bit hard to see from here. But basically what this shows is the path from hitting the ballot server, authenticating, returning the ballot server, and casting a vote. It is on the CD. So if you'd like to take a look at it after the talk, I recommend doing so. The polling stations were just cheap PCs behind a NAT box. And what happened was originally they planned to borrow PCs from students. We suggested this might be a bad idea. And instead, they rented a number of Apple iBooks. And the gateways are just your standard cheap home router gateways. You can buy them for $50 at Fry's. I think they use the links as ones in practice. So one of major assumptions is that the traffic between the clients and the ballot server and the authentication server is secure. It's sent over SSL. So in between, you shouldn't be able to see it. You shouldn't be able to alter it. But one of the key insights to this was that security, the whole system hinges on CalNet. They really emphasized physical security for the ballot server. They had it locked away in a room, under cameras. And I think that's because the folks running this election were used to people trying to steal boxes full of ballots. And they expected someone who was going to try and steal the machine. I don't know what sort of accomplished. But there was some really simple aspects of network security. So when we first looked at it, the database was listening to Outside World. We were like, hmm. And the other piece was that because there are a fixed set of polling stations, they could have very easily limited access to just those stations and basically dropped all traffic from anywhere else. Initially, they weren't doing this. So first of all, it's absolutely trivial to tamper with the ballot server if you have physical access. And we basically walked in and said, here are five really obvious security holes. And you should fix them. And they said, oh, would you do that for us? So you really need to defend social engineering as your first problem. And in fact, that's probably the biggest problem you have with an electronic or otherwise. So of course, all the physical security and cameras and lasers and alarms don't do a damned thing if you can just walk in with a screwdriver and tinker with the machine. And then the next thing we said was, ah, well, you have your database listening to the Outside World. And this is exploitable. We have seen exploits from iSql on the wild. So we fixed the obvious problems. And what this raised the bar to is that now you have to have your exploit prepared in advance. You have to be able to have it on a removal medium, drop it onto a polling station, and execute it, which is a considerable raising of the bar. The next piece we looked at was CalNet. And we were a little bit wary of tampering with CalNet being that it is the central authentication system for Berkeley. Kerberos is fairly well understood. And we imagined that the Berkeley officials would not have liked if we started trying to break their central Kerberos server. But the important and obvious observation we had was that we didn't need to break CalNet to break the system because it was done through a web proxy and we could use the authentication tokens, which are time stamped. But it doesn't matter because if we can grab them in the middle, we have all the time in the world we need to do nasty things. So the big observation was that we could get authentication tokens without compromising CalNet. And then there were the polling stations. So as I said, originally they planned to use PCs, which were rented from students. We suggested against this. Some basic cautions were taken so the iBooks were locked down and the default passwords on the router gateways were changed. So the key observation here is that if you can attack the polling stations, you can break this whole system. But the users have physical access and because they're voting and they're supposed to be able to vote in secret, they've got a fair amount of leeway for tamping. What this really highlights is that you need a way to basically authenticate that the polling station is running the polling station software properly and that the ballot server is running the ballot software property and neither has been tampered with. This is a trusted endpoint problem. But it's hard to implement with conventional hardware because it's not designed to be tamper proof. It's very hard to prove that the code you claim to have loaded is the code that's actually running. But there's another problem here, which is that if we have 70 polling stations, that's a lot of polling stations to tamper with. So even though you can go and sit in your voting booth, it's going to look fairly obvious if you go through 15 stations at once and say, oh, this one's broken. Oh, this one's broken. And somewhere around the fifth or sixth machine, they're probably going to get a little bit curious about what you're doing, which leads to observation. Can we hit an entire polling station when it fell swoop? And that's what we hit upon, which was a man in the middle attack. And I will pass it off to Damon for that. So I'm the second half of this spiel on the ASUC election, and I'm going to be covering the actual man in the middle attack implementation and what we would recommend doing to fix that afterwards. Something important to note is that our actual man in the middle attack is a very old attack with some customizations to make it work in our particular instance here. And so it's not so much interesting attack-wise as it is just lost what I was going to say. The possibilities that this suggests, countries like India, for instance, have just recently gone to entirely electronic-based voting systems. And for the 2004 election, our country is looking at having everybody actually authenticate online and verify that they are not a felon or are actually a citizen allowed to vote. So this is something that's actually coming up that needs to be looked at. So the summary for our attack is that we want to acquire CalMet tokens so we can replay them to the ballot server and then cast fraudulent votes. And that will allow us to pretend that the user is actually casting these votes. It's not possible to sniff these tokens because they're done over SSL. But we can trick the client into giving us ballot tokens by making it believe that our man in the middle is the actual ballot server. And this is how we did that. We make this man in the middle box that hereafter I will call fake ballot. It's a drop-in replacement for each of the router gateways that perform that. So we had an HP Vectra that we set up and just plopped in. To do this attack, here's the following recipe. You need an x86 PC, two network interface cards, one Linux distribution, one DNS server, one DHCP server, one website with SSL support, one SSL certificate featuring the fully qualified domain name of the ballot server signed with a bogus certificate authority. In this case, Verisign Space Inc. instead of Verisign Comma Space Inc. So the NAT and the DHCP work as follows. The Linux box does NAT. It's a really simple IP tables one-line thing. The external IP of fake ballot is the only IP seen by the true ballot server. And since we compromised it, it does all the traffic for us. The internal IP of fake ballot is the typical 192.168.1.1 network, and it offers IPs on that slash 24 to all the polling stations. Fake ballot runs a DHCP server that provides itself as the only name server for all polling stations. That DNS server is only listening to the internal network for requests, so any requests to it from outside the 192.168 will not be responded to. The way DNS is configured is that for all host names, it responds normally, except when it receives a request for the actual ballot server, it says, hey, that's me. Configuring Apache was pretty simple as well. It listens on fake ballots internal IP. There's a small Perl script. It's a proxy. You can find it on the convention CD-ROM. And all it does is forward requests to the real ballot server or to CalNet, and then send them back to the client. Unless that request happens to be a vote, in which case it says, oh, you didn't vote for these people. You voted for these people. And then our fraudulent vote is cast. The way this works is that in all the everything after the CalNet authentication takes place, a authentication token is passed around as a parameter. And so we just pick that up and hold onto it and tack it on to the fake vote and send it back. This diagram right here represents the actual layout of how fake ballot would redirect traffic. Step one is the red arrow across the top, and that's just the typical request for ballot. And then what happens is, let's see, the lower diagonal arrow is step two. Fake ballot redirects the polling station user to CalNet. And then step three and four is that the polling station user authenticates to CalNet and CalNet sends back the token. The important thing to notice here is that the token bounces through fake ballot. Step five is that the user goes through the actual webpage representing the ballot, selects his choices for candidates, submits it, and that also goes through fake ballot. Finally, fake ballot jumbles that up and sends it to the real ballot server. Something we actually had to worry about initially in designing the attack was that part of the OES system was going to be a receipt system so that users could one, see immediately after casting their vote who they voted for, and two, later on request an email from the ballot server asking to make sure who they voted for was who they voted for. It turned out we didn't have to actually pay any attention to this whatsoever because they didn't get it working in time. But the great thing about the receipt system and this highlights why trusting computers is bad was that they'd assume that the receipt was correct. So our legitimately placed bogus votes would have a cryptographically signed receipt that said that's what the person voted for. And that was what they were going to trust. More over on that topic, we actually, we thought a great deal about the receipt system and came up with one of the good ways to foil it in the end would just be to send back as many receipts as you wanted to saying as many possible votes as you wanted to. And that way you just flood the user's email and he gets receipts saying he voted for all sorts of people. Clearly the receipt system's broken. Nobody in the ASUC is going to know enough technically to be able to say what's wrong with it. So what about the whole SSL deal? They have these certificates that guarantee they are who they say they are. Well this is what happens when you go to ballot.berkeley.edu and fake ballot says hey, that's me. You get this little window that pops up and it says do you trust this host? And somebody says yes, I trust this host and that's it. Because the browser's only meant to run for one user pretty much. And after that one user says yes, it's fine for everybody else. So anybody that comes up after that initial user click to continue, they're all just SOL. Another additional part to that was the ASUC poll workers were additionally easily socially engineered. They didn't have much technical know how in the first place, but additionally, they weren't supposed to look over your shoulder while you were casting the votes. It's an anonymous ballot. So there's not much they can do while you're sitting there clicking continue and accepting BOGA certificates. One other point, I mean, the easy way to get around all of this is to just install your evil Verisign Space Inc. certificate authority as a trusted authority on the polling stations. Which again, because the poll workers aren't that technically savvy, come in. Oh, we need to do some work on the polling stations. Go, update each one with their certificate authority. Problem solved. But the other piece in terms of the, assume the user will click okay is that there's some good research that says that's exactly what users do. There was a great paper called Why Johnny Canton Crypt where they studied users trying to use PGP on Mac OS. Which is one of the better PGP GUI interfaces. And consistently they found something like 80% of the users would accidentally send email unencrypted, would send email encrypted with the wrong key. Unfortunately, security software sucks not because the security model is bad, but because we still can't make security software that normal people can use. So the SSL error we have there on the Macintosh is actually the scariest error you'll see. If you look at the equivalent error on Mozilla, or IE, it is a pretty wishy-washy error message. And if you examine the certificate, you'll see this certificate is issued by Verisign Incorporated. It looks legitimate. And that's all we need to do. We just need to be look legitimate enough for one user to click okay. So the final part of our actual talk is the lessons learned. Critical Vental Voters in OES that we discovered were as follows. It was easy to find an exploit. They were common beginner blunders. One of the first things we stumbled across when reviewing the code was a race condition. They were writing users' votes to a text file and then uploading that text, or the information in the text file into the database. But they weren't appending to the file. And so you could just get garbled votes one after another. And lots of people wouldn't have actually been voting if that were the case. We didn't do a complete and thorough review of the code and look at all of it. So that leaves us curious if there were more such sub-tool holes yet to be found. OES versus commercial systems. OES is greatly different from most commercial systems because primarily it's open source. We got to sit down and go through it from day one. Additionally, commercial electronic voting systems don't actually connect to the internet or shouldn't. The one system that has some of its codes to expose the debold system and it does connect to the net under certain circumstances. It also does things like dialing into the central balloting server. And as many of you know, the phone network is not secure. It looks like a man in the middle is a very viable way to attack at least one of the commercial systems. And it's reasonable to believe that it's probably going to work on many of the other systems. Another good point to make is that the lifetime of an open source system in terms of review and evolution is much shorter. OES is probably only going to be around until a better alternative is found for Berkeley election systems. Commercial systems are going to be hard to replace. I mean, it takes a long time to decide to use one let alone get it working and get it in place and get people used to it. And it's going to be a lot longer before somebody comes along and says, hey, we should change this. So in light of OES's flaws, existence of similar bugs in commercial systems are plausible. Primarily because commercial systems are closed. This results in amplified damage from a security bleach. If something goes wrong and whoever finds it doesn't say anything about it, it's going to be going wrong for a long time. Additionally, these vendors appear very, very new to the computer security world. That means mistakes are very likely to happen. Finally, there's much, much higher stakes involved when you're electing the president of the United States or prime minister of Great Britain than when you're electing some senators for Berkeley who, well, who knows what they do. So what can you as concerned people out there do about what's gone wrong with the electronic voting system so far? The first is endorsedverifiedvoting.org's resolution on electronic voting. This is the piece that Dan talked about earlier, David Dill. He's pushing for a paper trail to follow the electronic voting system and the paper trail will be the trusted part of that system. Additionally, you can write to Congress and emphasize the need for the voter verified paper ballot. And for personal preference, encourage the use of open source voting systems. Finally, at the lowest run of the government, you can talk to local officials and tell them the purchasing decisions for voting hardware are often made at the county level. So they should get their act together and push for what should be secure. Lastly, here's a list of our references. These are on the CONCD, so feel free to look them up there. There's a lot of really good work in this area. The two names that can lead to mind are David Dill who's doing the verified voting work. And I apologize, I'm blanking on the other name, but I will be glad to give it to folks after this talk is over. The other thing which has been really recent news that's very interesting to look at is that Dan Wallach who's over at Rice University and Avi Rubin did an analysis of the leaked Debold code and it's not guaranteed or clear that the Debold code is even Debold's code. It's not clear that that is the code that's running on their systems which I've already mentioned as one of the major problems with these systems is proving that the code you just reviewed is the code running on the system is a hard problem. But they did a fantastic right of it which highlights many of these problems and it's interesting to see that some of the predictions we made here while our work was done before they reviewed the Debold code were borne out. The man in the middle attack we predicted is very viable on the Debold code. And you see many of the sort of beginners mistakes that are made by programmers who may be perfectly competent but do not have a history of writing secure software. And so that is basically it. So thank you very much and if there's any questions I'd be glad to take them. I'm sorry, back part to you. When we originally did this we were hoping there would be a write-in candidate and we could elect a fake candidate but one of the difficulties with this is that if you scam an election they have to rerun it. And one of the things we went into this without realizing was that elections are expensive to run. So we very quickly realized that if we elected a fake candidate or cheated the election we could be liable for a lot of damages not to mention having angered the entire political science community at Berkeley which may be a good thing. The election officials, the head of elections of Warsaw County Nevada. No, I'm off, okay? The head of elections of Warsaw County Nevada claims that the electronic touch screen voting system used in Warsaw County Nevada is extremely safe because it stays locked in a vault 362 days a year and only comes out of the vault on primary day and election day when they have elections and then the votes are tabulated and then everything is safe. So if you were on a debate panel with this election official how would you address his, don't worry everything is just fine response? You have to send the votes in some time and it appears that the default votes in many cases are sent either over the telephone network or over the internet. The moment you connect these systems to an external network you have a very serious problem. Also there's the fact that there's still the problem with internal tampering. One of the great things that the Rubin and Wallach paper covered was that the Debal systems use smart cards in a completely brain dead way. For those of you who are not familiar smart cards are similar to credit cards but they also have a small processor on them so they can do cryptographic operations. They use smart cards like credit cards they give each one a unique ID number you need a card with an unseen ID number to vote. That's fairly easy to tamper with you can purchase those cards inexpensively they're available through vendors. So there's many avenues for tampering and the fact that's locked in a vote for 362 days a year doesn't do a tammed thing. So I'm having a hard time understanding how we can have paper receipts of our votes and still remain in a situation where you can't sell your vote. I'm sorry can you repeat that please? I'm having difficulty trying to figure out how we can have paper receipts verifiable paper receipts of our votes and yet not end up in a situation where I can sell my vote because if I can come back and prove to somebody that this is how I voted then I can collect money for having cast my ballot. In the Berkeley system there was a non anonymous piece but they weren't worried too much about selling votes. This is entirely true and you need that anonymity to prevent selling of votes. So one of the subtleties with the voter verifiable receipt is that the voter doesn't get to keep that. The voter should see a piece of paper behind a piece of plastic behind a pane of plastic or glass that shows their votes. If they say yes these are my votes that paper should get whisked into the ballot box and that box should be locked up the way you'd normally handle a paper ballot box. If the voter says no these are not my votes that paper should be destroyed. And this is a check out voter verifyvoting.org. They cover this fairly extensively. I've got the mic over here sir. Just wondering since you guys did study the code what was the mechanism for verifying that a voter didn't vote twice? User ID? CalNet has a, it's an LDAP system basically that keeps all the students information in it and each one has a unique student ID. They call it a UCVCPD ID I believe and that was checked at CalNet authentication and then once the student authenticates that's sent back as part of the token, part of the parameters and then that's checked in the system via LDAP lookup calls. That feels non-changeable like my user ID if for instance I'm female get married my name changes my user ID change. No those IDs are similar to social security numbers they never change. The bigger problem here is one of anonymity and in this case you basically just have to trust the system that it's going to separate your ID from your votes and this is a hard problem with a purely electronic voting system. Even though the commercial electronic voting systems are not relying on the systems themselves to check that the individual is a registered voter that's handled at the precincts and that tends to be a pencil and paper process. You guys pick. Are you guys familiar with cases of suspected abuse in the systems that are in place already? Because I know I've read several places that there was a senator elected in the Northwest who was a long shot in the primary, a long shot in the general election won by a landslide in both who happened to be CEO of the company making the voting machines. So. I suspect though, since I don't want to get sued I am absolutely not talking specifically but I believe you're talking about election systems and software. I don't know the specifics of that. I have read some of the circumstances of it and it certainly raises an eyebrow but again without a paper audit trail you have no way to tell. So as I said, forensic analysis is hard and forensic analysis on a black box is damn near impossible. It was Chuck Hagel in Nebraska. I just wanted to emphasize one thing. I'm Cindy Cohn with the EFF and we support both of the recommendations here. The last point about going to your local officials is really I think the most important one. Representative Holt from New Jersey has a great bill and you should support it but buying of election machines happens by local county officials. It's the local registrar or voters who's making the decisions and they're not hearing from anybody except the snake oil salesman and you need to go talk to them and don't geek out on them. Be really straight with them and convince them about the dangers here because they're not hearing that sign. What they're hearing from is the disabled community and the people who don't speak English who love electronic voting because it will enable more voters and they're an important they're important people. We need to listen to them but the security community needs to really sit down with the local people and talk about the risks of just embracing one of these systems because of the good it might do because there are lots of dangers as well. Yeah, this is a very important point. Something to understand is that voting machines are purchased typically at the county level. This is an entirely local function and you have an unfortunate problem where you have your county official who is very well-meaning and is trying to do their homework but doesn't necessarily have the best information because mostly the information they are getting is coming from the voting vendors and they plunk down $30 million to your place, all of the county's voting machines. To have some smarmy academic or some punk hacker come and say, oh, you just blew $30 million on insecure machines, doesn't make them very happy. So first, you need to talk to them sooner than later and second, how you phrase this is very important. As Paul talked to the earlier discussion of the paper trail, I'm not sure if you can actually answer this but do you know how the commercial vendors guarantee that the vote that appears on the paper is the same vote that got sent over the wire or is actually submitted? Well, this is the whole point of the paper trail is that if there is any dispute, you look at the paper trail and you trust the paper trail. In the case of the Berkeley election, was there any attempt made to authenticate the voters' data to see that the people who were voting were in fact who they said they were to prevent the use of people as ringers, using other people's IDs, that kind of election fraud. So actually, this is one area where the electronic system at Berkeley is better because exactly what you're suggesting which is stealing someone's ID or using it to vote was a serious problem with paper elections. The electronic system requires authentic, authenticating through CalNet which requires knowledge of your student ID which is public knowledge but it also requires basically an individual passphrase which is private knowledge and should be kept secret because if you know someone's passphrase then you can do things like unenroll them. So it's actually a fairly good system in that regard. However, well the requirements on the password are very secure. There are like a couple uppercase letters, couple symbols, couple lowcase letters. So there's strong passwords. There are still people that harvest CalNet passwords. There is a website out there that lists them. It doesn't pass a strong two factor authentication test though. I agree but it's still an improvement over the old system. Passwords are well understood and yes, there are many ways you can improve on it but in this particular case, the trade off for a strong authentication mechanism versus more people voting and using the system was a better engineering trade off. Did you see anything with counter fitting of tokens similar to the default study where they did the homebrew smart cards? No, actually the tokens used by CalNet are Kerberos tokens and current research says they are cryptographic secure and are very hard to forge with the current Kerberos protocol. So no, and if someone was counter fitting tokens it would be a much more interesting talk because someone would have made some very interesting advances in cryptography. Oh yeah, to get back to talking about the receipts essentially. Letting them look at it raises another issue which is that, to use the forward example, if I'm a person who thought I voted for Buchanan that lets me fix that problem but if I'm also someone who voted for Nader I might think to myself, well, God, if I knew it was gonna be that close I would have voted for Gore. Is there an effort in the receipts to try to provide non-repudiability as well or does that get in the way of anonymity? The Berkeley system most certainly did not provide non-repudiability but it actually opens one of my favorite DOS attacks which is that you're part of the evil party and you're a little bit worried about how the election might go. So you get a statistically significant but non-majority number of your party members i.e. the people running to vote for people in some other party and then when the results come out you have all of these people conveniently look at their receipts and say, oh my goodness, I didn't vote for anyone in the evil party. Like, the system must be broken, you have to throw the election out. I was wondering if you had any information as far as trending some of these vendors if it's kind of like the whole Microsoft thing where everybody's using it, so we'll use it too. It seems to be that most government agencies tend to look at what other government agencies purchased and they purchased the same thing. So are we looking at a dominant vendor in these systems? As far as I know, there's no one vendor that is reigning. I believe election systems and software it has the lead in the market but you're actually seeing good competition in the marketplace. The only problem is that it's vaguely like the music industry where everything being sold sucks. So it's not as bad as the Microsoft situation but all of the vendors are turning to the same line. They're not opening their code. They're not allowing security professionals to review them. So you're still kind of stuck. You're not seeing government following each other because no path has been set yet. Yes, you mentioned that there are vendors now working on the paper receipt system. I mean, is that looking good? I mean, could you talk more about that, I guess? What have we seen so far? So I would say check out Verified Voting.org. They will have the most up to date information on this. I believe that the SNS demoed a prototype of a printer that handles the voter verified receipt with the proper protocol where the voter does not walk out. So he can sell his vote with that receipt in hand and it's tucked away and the paper is treated as the hard copy. One of the interesting things I've heard about this though is that one of the first complaints the voting, the pressure voting vendors raised was that in some states producing a paper trail may be illegal. Whether this is a case of well-meaning lawmakers making bad laws, not the first time it's happened, or just the commercial system is trying to stall because developing a paper receipt system is going to cost them money isn't entirely clear. I think we have just a couple minutes left so I think we'll take one last question. If we're to go to our county officials and ask them to reconsider buying electronic voting machines, what alternatives do we tell them are better than the deep holes that are out there? So there's good news and bad news here. The bad news is that the four major commercial vendors are pretty much the big ones in the market and they're probably gonna buy a product from them. The good news is that they make lots of products that aren't shiny direct recording electronic systems. For example, they have Scantron systems which are a market improvement over your paper chat systems but definitely better than a computerized system without an audit trail. Thank you very much.