John Stewart of Cisco posted a very interesting blog entry discussing the differences among features, bugs, and backdoors. He categorizes them by intent (features and backdoors are intentional, whereas bugs are not) and transparency (features are disclosed to customers “at the start”, bugs are disclosed after being identified, and backdoors are not disclosed). This raises an interesting point about third parties.
Suppose a company builds a product using supplies obtained from a third party (the “supplier”). That supplier inserts something into the software (or hardware) allowing them access to the computer on which it is used. This is a backdoor to that supplier. But how would we classify it, using John’s categories?
In this case, the company and their customer are in effect both “customers” of the supplier. But the company is an intermediary, which makes it both customer and company in the sense that John is talking about. So, the supplier might disclose a feature of its product to the company, which may not disclose that feature to the customer (perhaps it is not something that the customer needs to know, or the company thinks it unimportant). What is it — a feature, bug, or backdoor?
In this case, I think you need to have two answers: one for the supplier to company relationship (in which the company plays the role of customer) and one for the company to customer relationship. Unfortunately, the ultimate customer must rely on the company to protect him or her. And the company must rely on the supplier to protect it, and its customers.
What makes this really tricky is when the “third party” is neither the supplier nor the company and does not disclose the change to anyone. If someone else (the “interceptor”) changes the product on its way to the company (or from the company on the way to the customer), then the change is completely unintentional on the supplier’s or company’s part, but quite intentional on the third party’s part. So, which is it — a feature, bug, or backdoor?
This is most likely not an academic question, as some government agencies have been accused of doing this. The current accusation making headlines is that the U.S. National Security Agency can do this).
Probably the simplest way to handle this is to look at these terms from the point of view of the customer. In this case, the interceptor’s addition is not a feature (as it is not transparent to the end customer), nor is it a bug (as some entity made the change quite intentionally). So it is a backdoor. But this analysis is unfair to the supplier and the company, as they did nothing intentionally. So again, to them too, it is a backdoor, and they are as much victims as the customer.
Monday, December 30, 2013
Friday, June 21, 2013
1982 E-Voting Systems in Science Fiction
I was reading a science fiction book, “The Stainless Steel Rat for President”, by Harry Harrison [1], and came across a passage that I found interesting and, given that the book was written in 1982, surprising.
An opposition candidate has discovered that there was fraud in an election, which was conducted on computers. He quotes from the planet’s constitution [2]:
Due to the nature of electronic voting and due to the necessity of assuring that the voting is always recorded with utmost accuracy and due to the invisibility of the votes once they have been recorded in the voting machine, ...
I found that a remarkably perceptive, and also a very succinct, statement of a key problem with computerized voting systems. To me, that this statement was made in a book that appeared in 1982, makes it even more remarkable.
By the way, the passage goes on to say that if it is proven beyond doubt that the record of votes in a single voting machine is altered, then the election is null and void, and a new one must be conducted using paper and ballot boxes, and no subsequent election can use the computerized voting machines until the newly-elected President has them investigated.
References
- Harry Harrison, The Stainless Steel Rat for President, Bantam Books, New York, NY, USA (1982).
- ibid., p. 166
Sunday, June 2, 2013
Jeffrey Hunker: A Personal Memory
My friend and colleague, Jeffrey Hunker, passed away Friday. This was unexpected, and stunning.
Jeffrey in a dark shirt at NSPW 2009, in Oxford, England.
What follows is not an obituary; others can write about the minutiae of his life, and of his many accomplishments, better than I. These are simply some of my memories.
I met Jeffrey some time in the 1990s, at (I believe) a workshop on incident response. Alan Paller, a mutual friend, introduced us. At the time, Jeffrey was the director of the Critical Infrastructure Assurance Office (the CIAO), and if memory serves me correctly also on the National Security Council. (I may be off on the dates — he was on the NSC, but it may have been after the meeting.)
Jeffrey struck me as very friendly and willing to discuss various aspects of security. He gave a good talk at the workshop.
We reconnected in the mid-2000s, at a meeting for the Institute for Information Infrastructure Protection (I3P); he was the representative for Carnegie-Mellon, and I for UC Davis. Our interests complemented each others’. Jeffrey knew quite a bit about technology, and far more about politics, how governments worked and interacted with one another, and about national security — topics I was very interested in. I knew a lot about the technology he was interested in, and I was learning about the other aspects he was an expert in. So we became friends, and colleagues.
Jeffrey was very good-natured, and seemed to be constantly amused at life. He was a joy to work with; he was very perceptive, and could get to the heart of an issue very quickly. He also asked questions that caused us to look at something in a new way. Talking to him was usually exciting, and I looked forward to it.
Our work on attribution sprang from a workshop on the Global Environment for Network Innovation (GENI) project, held in Davis. He was one of the attendees, and joined several others to come to my house for a small get-together; then we all went to dinner. He was charming to my wife Holly, and she immediately liked him.
That workshop also produced the only time I ever saw him irritated with me. He, another friend and colleague, and I were discussing attribution, and we decided to meet at 8am, before the workshop workday, to consider some ideas. Well, I overslept, and our friend was also late — and Jeffrey had been up since 6am working on the ideas. He quickly forgave us, though.
The work wound up in a paper on what attribution requirements the future Internet might require. His political expertise combined with our technical expertise to develop what I thought were interesting (and somewhat unexpected) results. We chose a rather impish title for the paper: “The Sisterhood of the Traveling Packets”. It was great fun to see him handle the questions about the title at the workshop — he ended up suggesting that the questioners ask any parent of a teenage girl!
Since then, Jeffrey and I worked together on topics ranging from attribution to the insider problem. Indeed, when he passed away, we had just completed a short write-up on whether the Internet could be controlled, and we were sending it around to see if we could get funding to explore that issue in more depth.
Jeffrey could take a complex political and governance issue and explain it in very simple terms. His book, Creeping Failure: How We Broke the Internet and What We Can Do to Fix It, did a nice job of explaining how we wound up with the Internet we have today, and how the problems arose and were magnified during its growth. His comparison of this to the evolution of cities was quite enlightening, and one I’d never heard of before.
He also enjoyed talking about books and history. I remember when we were at a workshop in New Hampshire. I was telling him about a book I was reading (The Illuminatus! Trilogy), and he seemed to enjoy the idea behind the book; I recommended it very highly. The same happened a couple of years later, when we were talking about counterfactual history. I told him about another book, Pastwatch: The Redemption of Christopher Columbus, which is an alternate history of Columbus' voyage. I hope he did read them; he would have enjoyed them very much.
I remember him being the general chair of the Workshop on Governance of Technology, Information, and Policies (GTIP) held in 2009. There were problems with the organization of the workshop, through no fault of anyone in particular. What they were are not relevant, but what is relevant is how Jeffrey adapted to the problems and out of them moulded a very successful workshop. His vision and skill in working with people, and his determination, made the workshop successful.
I spoke with Jeffrey on the Wednesday before he died; he told me he had been in the hospital for some time, which was why he was so hard to get hold of, but he thought he was getting better. But he wasn’t sure, and was still very, very tired. So we talked a bit, made plans to finish up a project we were working on, and agreed to talk on Thursday. I called at the prearranged time, and he told me he needed to rest, so could we talk on Friday? Of course, I said; and called him then. He didn’t answer. He never will.
There is an expression we use when we talk about people who are very, very good deep inside; we say they have a good soul. He had a good soul. My life was much richer for knowing Jeffrey — both professionally and, more importantly, personally. I will miss him very much.
What follows is not an obituary; others can write about the minutiae of his life, and of his many accomplishments, better than I. These are simply some of my memories.
I met Jeffrey some time in the 1990s, at (I believe) a workshop on incident response. Alan Paller, a mutual friend, introduced us. At the time, Jeffrey was the director of the Critical Infrastructure Assurance Office (the CIAO), and if memory serves me correctly also on the National Security Council. (I may be off on the dates — he was on the NSC, but it may have been after the meeting.)
Jeffrey struck me as very friendly and willing to discuss various aspects of security. He gave a good talk at the workshop.
We reconnected in the mid-2000s, at a meeting for the Institute for Information Infrastructure Protection (I3P); he was the representative for Carnegie-Mellon, and I for UC Davis. Our interests complemented each others’. Jeffrey knew quite a bit about technology, and far more about politics, how governments worked and interacted with one another, and about national security — topics I was very interested in. I knew a lot about the technology he was interested in, and I was learning about the other aspects he was an expert in. So we became friends, and colleagues.
Jeffrey was very good-natured, and seemed to be constantly amused at life. He was a joy to work with; he was very perceptive, and could get to the heart of an issue very quickly. He also asked questions that caused us to look at something in a new way. Talking to him was usually exciting, and I looked forward to it.
Our work on attribution sprang from a workshop on the Global Environment for Network Innovation (GENI) project, held in Davis. He was one of the attendees, and joined several others to come to my house for a small get-together; then we all went to dinner. He was charming to my wife Holly, and she immediately liked him.
That workshop also produced the only time I ever saw him irritated with me. He, another friend and colleague, and I were discussing attribution, and we decided to meet at 8am, before the workshop workday, to consider some ideas. Well, I overslept, and our friend was also late — and Jeffrey had been up since 6am working on the ideas. He quickly forgave us, though.
The work wound up in a paper on what attribution requirements the future Internet might require. His political expertise combined with our technical expertise to develop what I thought were interesting (and somewhat unexpected) results. We chose a rather impish title for the paper: “The Sisterhood of the Traveling Packets”. It was great fun to see him handle the questions about the title at the workshop — he ended up suggesting that the questioners ask any parent of a teenage girl!
Since then, Jeffrey and I worked together on topics ranging from attribution to the insider problem. Indeed, when he passed away, we had just completed a short write-up on whether the Internet could be controlled, and we were sending it around to see if we could get funding to explore that issue in more depth.
Jeffrey could take a complex political and governance issue and explain it in very simple terms. His book, Creeping Failure: How We Broke the Internet and What We Can Do to Fix It, did a nice job of explaining how we wound up with the Internet we have today, and how the problems arose and were magnified during its growth. His comparison of this to the evolution of cities was quite enlightening, and one I’d never heard of before.
He also enjoyed talking about books and history. I remember when we were at a workshop in New Hampshire. I was telling him about a book I was reading (The Illuminatus! Trilogy), and he seemed to enjoy the idea behind the book; I recommended it very highly. The same happened a couple of years later, when we were talking about counterfactual history. I told him about another book, Pastwatch: The Redemption of Christopher Columbus, which is an alternate history of Columbus' voyage. I hope he did read them; he would have enjoyed them very much.
I remember him being the general chair of the Workshop on Governance of Technology, Information, and Policies (GTIP) held in 2009. There were problems with the organization of the workshop, through no fault of anyone in particular. What they were are not relevant, but what is relevant is how Jeffrey adapted to the problems and out of them moulded a very successful workshop. His vision and skill in working with people, and his determination, made the workshop successful.
I spoke with Jeffrey on the Wednesday before he died; he told me he had been in the hospital for some time, which was why he was so hard to get hold of, but he thought he was getting better. But he wasn’t sure, and was still very, very tired. So we talked a bit, made plans to finish up a project we were working on, and agreed to talk on Thursday. I called at the prearranged time, and he told me he needed to rest, so could we talk on Friday? Of course, I said; and called him then. He didn’t answer. He never will.
There is an expression we use when we talk about people who are very, very good deep inside; we say they have a good soul. He had a good soul. My life was much richer for knowing Jeffrey — both professionally and, more importantly, personally. I will miss him very much.
Monday, May 20, 2013
A Thought on the Proposed Built-In Wiretap Capability
The paper CALEA II: Risks of Wiretap Modifications to Endpoints raises very good points about the dangers of requiring vendors to build a wiretap capability into communications technology. I wanted to add a thought.
Let’s say that this capability is built in. As the above paper noted, an attacker can exploit the wiretap capability (which is, of course, simply a known, built-in vulnerability) to monitor the conversation. This may, or may not, alarm law enforcement authorities who are pushing for adding this capability. What should alarm them is that their conversations can also be monitored — that is, the attackers can keep tabs on the law enforcement authorities who are trying to catch the attackers! In other words, the tool intended for catching criminals can also be used to monitor the attempts to catch them.
Saying that vendors can build the vulnerability in such a way that only authorized eavesdroppers (read: law enforcement authorities) can use it underestimates the resourcefulness of attackers, and overestimates the capacity of humans both to design procedures that are flawless, and to carry out those procedures. Quoting from another report [1]:
So, the alternative is to give law enforcement communications tools without these eavesdropping capabilities. Now, there are two sets of communications technology out there: those with built-in wiretaps, and those without built-in wiretaps. How long the market for the latter can be restricted to law enforcement is anyone’s guess, but there is no doubt that those wiretap-free tools will become available to people not engaged in active law enforcement. Restrictions on that type of technology fail quickly.
This point, I think, strengthens what the above paper is saying. Not only does it pose “serious consequences for the economic well-being and national security of the United States” as the paper says, it also hampers the effectiveness of law enforcement.
References
Let’s say that this capability is built in. As the above paper noted, an attacker can exploit the wiretap capability (which is, of course, simply a known, built-in vulnerability) to monitor the conversation. This may, or may not, alarm law enforcement authorities who are pushing for adding this capability. What should alarm them is that their conversations can also be monitored — that is, the attackers can keep tabs on the law enforcement authorities who are trying to catch the attackers! In other words, the tool intended for catching criminals can also be used to monitor the attempts to catch them.
Saying that vendors can build the vulnerability in such a way that only authorized eavesdroppers (read: law enforcement authorities) can use it underestimates the resourcefulness of attackers, and overestimates the capacity of humans both to design procedures that are flawless, and to carry out those procedures. Quoting from another report [1]:
Finally, no security should ever rely solely on secrecy of defensive mechanisms and countermeasures. While not publishing details of security mechanisms is perfectly acceptable as one security mechanism, it is perhaps the one most easily breached, especially in this age of widespread information dissemination. Worse, it provides a false sense of security. Dumpster diving, corporate espionage, outright bribery, and other techniques can discover secrets that companies and organizations wish to keep hidden; indeed, in many cases, organizations are unaware of their own leaking of information. A perhaps classic example occurred when lawyers for the DVD Copyright Control Association sued to prevent the release of code that would decipher any DVD movie file. They filed a declaration containing the source code of the algorithm. One day later, they asked the court to seal the declaration from public view — but the declaration had been posted to several Internet web sites, including one that had over 21,000 downloads of the declaration! [2] More recently, Fox News reported that information posing “a direct threat to U.S. troops … was posted carelessly to file servers by government agencies and contractors, accessible to anyone online” [3], and thefts of credit card numbers and identities are reported weekly and growing in number.
So, the alternative is to give law enforcement communications tools without these eavesdropping capabilities. Now, there are two sets of communications technology out there: those with built-in wiretaps, and those without built-in wiretaps. How long the market for the latter can be restricted to law enforcement is anyone’s guess, but there is no doubt that those wiretap-free tools will become available to people not engaged in active law enforcement. Restrictions on that type of technology fail quickly.
This point, I think, strengthens what the above paper is saying. Not only does it pose “serious consequences for the economic well-being and national security of the United States” as the paper says, it also hampers the effectiveness of law enforcement.
References
- M. Bishop, “Overview of Red Team Reports”, Office of the Secretary of State of California, 1500 11th St, Sacramento, CA 95814 (July 2007); available at http://www.sos.ca.gov/voting-systems/oversight/ttbr/red-overview.pdf
- Declan McCullagh, “DVD Lawyers Make Secret Public”, Wired News (Jan. 26, 2000); available at http://www.wired.com/politics/law/news/2000/01/33922
- Associated Press, “Government Agencies Posting Sensitive ‘Need to Know’ Material Online”, Fox News (July 12, 2007); available at http://www.foxnews.com/story/0,2933,289011,00.html
Friday, May 10, 2013
Internet Voting? Not Yet -- From an Election Point of View
[[This blog post discusses Internet elections from the point of view of how the election process might work. It’s similar to my blog entry of Monday, April 22, 2013, but presented from a different point of view (and has additional information.]]
The time for Internet voting has not yet arrived. Someday it may be a good idea, but we have many security problems to solve, and we will have to decide whether to change how elections are run.
To see why, let’s look at how Internet voting will work. When you go to vote, you will use your home computer, a work computer, or some other device to connect to an election server. That server will transmit a ballot back to you. You mark the ballot appropriately to cast your votes, and then the computer transmits the completed ballot back to the election server. The election server then processes the ballot, counting the votes.
Now let’s look at each step in this process.
First, you need to get the ballot from the election server. You have to connect to the election server and provide information to ensure you get the right ballot. In order to do this, you will need to supply your voting address and, possibly, prove your identity.
Let’s see what this means. During Election Day, when you open your browser and type in the Election Office’s web site, you get a message saying the web site is unavailable. You’re thrilled so many people are voting, so you go to work. While there, you try to vote again, with the same result. This happens whenever you try to cast your vote throughout the day. That evening, at 7:55pm (just before the polls close), you try to vote from home one last time. Again, the web site is “unavailable”. Oh, well.
What you just read is a description of a “denial of service”" attack. They are actually fairly common, and extremely easy to launch. In fact, recently many banks (such as U.S. Bank, Bank of America, Wells Fargo Bank, CitiBank, and American Express) [1-3] were victims of such attacks. But the banks have an advantage that election offices don't: lots of servers and lots of money. They can hire teams of cybersecurity experts to respond to these attacks, and can reroute traffic to geographically widely distributed servers to mitigate some of the effects of the attack. Even so, the banks all experienced slow-downs that affected customer use of their web sites.
Given that most Election Offices have 1 or 2 people whose job involves cybersecurity (among other functions) and would have a single server to handle Internet voting, not being able to connect to the election server over the Internet is very realistic. And as the above news articles note, these attacks are easy to launch — from anywhere in the world.
In fact, this has happened. During Hurricane Sandy, New Jersey allowed voters to request email ballots by sending an email to county email addresses set up for this purpose. But the email addresses which received the emails were quickly overwhelmed, and email requests for ballots were bouncing [4,5]. And this was not an attack; it was simply voters requesting email ballots — requests that were never received.
Next, let’s look at how you would retrieve a ballot. You give your voting address, and the election server transmits the appropriate ballot. But how do you know you are talking to the correct election server, and not a fake one?
Someone could send you a fake ballot from a bogus election server. Such a ballot could cause the votes you cast through that ballot to be changed before the ballot is transmitted to the election server. This sounds surprising, but remember that PDF files contain programming instructions that tell the computer how to draw the image on the screen. And that same language can tell the program reading the image to count votes differently than displayed; or they can add markings and cover them up when displayed.
So how do you know the votes you enter on your computer are what is sent to the server? Aside from rigging the ballot files, it is very easy to write programs that alter information; indeed, the infamous computer virus does exactly this. And while antivirus programs are very effective in countering viruses that they know about, they do not protect you against new viruses or other nasty programs on your system. There are many ways to introduce these programs, including having you go to a web site that looks like your bank’s (for example). When you get there, the site has you download something to improve service — and presto!, the malefactors have just put a virus on your system.
With smartphones this is even easier, because we all download apps and run them. The protection most smartphones offer is minimal, so writing an app to cast your vote (suitably doctored, of course) is easy. To get you to download it, the perpetrator sends you an email saying that your election official has set up a web site that you can go to for the app — and when you download it, you really download the doctored app. The election official, of course, did not send this letter.
So you need to be sure that, once you have marked the ballot, the marks you make are the ones that the vote counting system and software will count.
Now let’s say you supply your authentication information to validate who you are, so the election server will send you the right ballot. If you are communicating with a bogus election server, it now has all the information it needs to vote for you — it simply discards your ballot, logs in to the real election server as you, and casts its votes.
How can you be sure you are talking to the right election server? Presumably the county will supply that web address. But if the address comes in an email, it would be easy for some group to send you specially crafted email that displayed the right address as a link — but when you click on the link, it takes you to a completely different web site. This technique is called phishing (or, in this context, spearphishing) and is remarkably effective. This is widely believed to be the way attackers recently took over the Associated Press twitter news feed — and they then posted a fake news story about President Obama being injured by explosions at the White House, causing Wall Street to panic [6].
Instead, if the address doesn’t come in an email, the attackers may send an email on the night before the election that looks like it comes from the elections office, but is an attack as described above. This would probably trick a large number of people, who would be grateful that the elections office was providing a more convenient way of getting to the web page rather than forcing the user to type the full web address into the browser.
Okay, let's assume you are now talking to the real election server. Once you have cast your votes, they have to be transmitted to the election server. (If you haven't given the authentication information yet, you will have to do so now.) This means the ballot must be sent through the Internet. How does it get there? This is called “routing”, and the route the ballot takes depends on a lot of factors that change constantly. Unless specific methods are used to transmit the ballot, the ballot could get lost, or altered, or someone along the way could read it.
The method that has to be used is the same one that you use to talk to your bank — basically, it is an encrypted connection. These connections require the server to send something called a “certificate” that is signed by a trusted agency. But what agency, and how will you know that the certificate is valid? If the certificate is too old, your browser will tell you, and may refuse to allow you to proceed. But many institutions don’t keep their certificates up to date (it costs money for that), so when you see a notice saying “certificate expired”, you may be talking to the right election server. You don't know. Worse is the situation where the certificate is valid but from an unknown agency. How much can you trust that the agency really checked that the elections office asked for the certificate? Someone once had a highly reputable agency issue a new certificate for Microsoft — but he had no connection to Microsoft [7]. (The problem was discovered quickly, and no harm appeared to have been done. We may not be so fortunate in a Presidential election.)
Okay, now your vote has arrived at the election server. The election server has a lot to do, and must do it correctly. That you have voted now needs to be recorded, and in a way that does not indicate which ballot you case. Somehow the two must be decoupled. So, when your ballot arrives at the server, your name is marked as having voted, and the ballot must be digitally signed by the election server to ensure it is not changed after it is received. Then the ballot must be counted or moved to a system that will do the counting. Any error in all this will compromise your vote, your privacy, and/or the accuracy of the results.
The election server is connected to the Internet, of course — and the Internet that you use to connect to the election server is the same one that people around the world can use to connect to it. This includes attackers who want to break into the server, see the data that is there, and change it or the programs on the server to corrupt the results of the election. And attackers succeed at breaking into very well-maintained computers at high-security government agencies, and covering their tracks well. U.S. defense contractors, the Pentagon, other government agencies, financial institutions, and many major corporations have had their systems and web servers compromised [8-11]. These organizations have lots of security expertise and lots of money. They can hire teams of cybersecurity experts to detect attacks, analyze them, repair or reinstall corrupted systems, (attempt to) recover corrupted data, and figure out how to prevent the attacks from recurring. Of course, these responses take time to carry out. Election offices simply do not have these financial, human, or technical resources. Nor do they have the time, because during an election people vote for a fixed period of time (usually 14 hours or so). Thus, ensuring that an election server connected to the Internet is secure simply is infeasible.
Finally, the procedures to be followed to maintain the server's security must be well thought out and followed meticulously. This is a critical, and often overlooked, point: security experts know that a “system” is not secure; a “system” is secure when used in a specific way. A good way to think of this is to consider how safe a car is. When the driver obeys the traffic laws, she is (usually) quite safe. But if she runs red lights, she is not. Similarly, if the Internet voting system procedures are poorly done, or do not take into account the bad things that can prevent voting or corrupting the ballots, poor "system" security is the least of the problems.
It's tempting to assume that you can simply have someone get a ballot, fill it in, scan it into a PDF (or somehow get it into electronic form), and email it back to the county Elections Office. But the same problems arise. Change “election server” to “email server” above, and the description of how someone returns the ballot is the same whether a web browser on a home computer sends it to the (election) server, or a mail program sends it to the (email) server. And if the ballot is to be downloaded or emailed to the voter by an election official, you again have all the problems of getting the ballot as before.
The quest for Internet voting is a good one; but before the body politic decides that it should be implemented, the dangers and problems of it must be known, discussed openly, and a conscious decision made that the consequences of those problems are acceptable. A pilot study using a real election does not provide this information for several reasons. First, no reputable computer security expert will ever attack a voting system during an election (it’s a crime), so we cannot test the security of the system and its procedures as actually used. Second, enabling detection of some attacks requires a complete record of what happens — including how you voted. Before this type of recording is done, the body politic must decide that how you voted can become known, and accept the attendant risks of vote selling and voter intimidation. Third, a very sophisticated attack could well be undetectable — so how would we know the votes were compromised? And so forth. (See my blog entry for Wednesday, April 24, 2013 for a more detailed explanation of this.)
Whether these difficulties can ever be overcome is a very deep, complex question requiring research in technology, human behavior, social organization, political considerations, and legal matters. What is absolutely certain is that, until they are overcome, we should not conduct civic elections over the Internet.
As for my credentials: I am a professor of computer science at the University of California at Davis, where I am a co-director of the Computer Security Laboratory. I have been in the field since 1978. I have been studying electronic and Internet voting since 2004, when I participated in the RABA study of electronic voting systems for the State of Maryland [12]. I was also one of the co-leaders of the technical part of the California Secretary of State's Top-to-Bottom Review of voting systems certified for use in the State of California [13]. Currently, the National Science Foundation is funding our research on election processes [14,15]. Our group works with election officials in Yolo and Marin Counties.
Any opinions expressed in this note are those of the author, and not necessarily those of anyone else.
[ 1] "3 More Major US Banks Report Possible Cyber Attacks," NBC News (Sep. 27, 2012); available at http://www.nbcnews.com/technology/technolog/3-more-major-us-banks-report-possible-cyber-attacks-6126050
[ 2] M. Lennon, "Wells Fargo Says DDoS Attack Disrupting Online Banking Website," Security Week (Mar. 26, 2013); available at http://www.securityweek.com/wells-fargo-says-ddos-attack-disrupting-online-banking-website
[ 3] B. Acohido, "Amex Latest U.S. Major Bank to Get Knocked Offline," USA Today (April 2, 2013); available at http://www.usatoday.com/story/tech/2013/03/29/american-express-denial-of-service-hack/2030197/
[ 4] "Christie Administration Announces E-Mail and Fax Voting Available to New Jerseyans Displaced by Hurricane Sandy," State of New Jersey (Nov. 3, 2012); available at http://www.state.nj.us/governor/news/news/552012/approved/20121103d.html
[ 5] B. Sullivan, "New Jersey's Email Voting Suffers Major Glitches, Deadline Extended to Friday," NBC News (Nov. 6, 2012); available at http://usnews.nbcnews.com/_news/2012/11/06/14974588-new-jerseys-email-voting-suffers-major-glitches-deadline-extended-to-friday
[ 6] J. Steinberg, "Twitter, The Associated Press, and Phishing: Why Breaches Still Occur," Forbes (Apr. 26, 2013); available at http://www.forbes.com/sites/josephsteinberg/2013/04/26/twitter-the-associated-press-and-phishing-why-breaches-still-occur/
[ 7] "Unauthentic 'Microsoft Corporation' Certificates," CERT Advisory CA-2001-04, Pittsburgh, PA (Mar. 30, 2001); available at http://www.cert.org/advisories/CA-2001-04.html
[ 8] M. Riley & B. Elgin, "China Cyberspies Outwit U.S. Stealing Military Secrets," Bloomberg (May 1, 2013); available at http://www.bloomberg.com/news/2013-05-01/china-cyberspies-outwit-u-s-stealing-military-secrets.html
[ 9] G. Wyler, "Pentagon Admits 24,000 Files Were Hacked, Declares Cyberspace A Theater Of War," Business Insider (July 14, 2011); available at http://www.businessinsider.com/pentagon-admits-24000-files-were-hacked-declares-cyberspace-a-theater-of-war-2011-7#ixzz2SAYL2pqp
[10] M. Schwartz, "U.S. Labor Dept. Website Hacked, Serves Malware," Information Week (May 1, 2013); available at http://www.informationweek.com/security/attacks/us-labor-dept-website-hacked-serves-malw/240153984
[11] D. Smith, "Bank of America Hacked By Anonymous: Hackers Leak 'Secrets' About Executives, Salaries, And Spy Activities," International Business Times (Feb. 28, 2013); available at http://www.ibtimes.com/bank-america-hacked-anonymous-hackers-leak-secrets-about-executives-salaries-spy-activities-1107947
[12] "Trusted Agent Report Diebold AccuVote-TS Voting System," RABA Innovative Solution Cell, Columbia, MD (Jan. 20, 2004); available at http://nob.cs.ucdavis.edu/~bishop/notes/2004-RABA/2004-RABA.pdf
[13] M. Bishop, "Overview of Red Team Reports," Office of the California Secretary of State (July 2007); available at http://www.sos.ca.gov/voting-systems/oversight/ttbr/red-overview.pdf
[14] "TC:Medium:Collaborative Research: Technological Support for Improving Election Processes," award from the National Science Foundation tot he University opt California at Davis (Sep. 15, 2009); abstract available at http://www.nsf.gov/awardsearch/showAward?AWD_ID=0905503
[15] "EAGER: Collaborative: Process-Based Technology to Support Comparison and Evaluation of the Security of Elections," award from the National Science Foundation tot he University opt California at Davis (Oct. 1, 2012); abstract available at http://www.nsf.gov/awardsearch/showAward?AWD_ID=1258577
The time for Internet voting has not yet arrived. Someday it may be a good idea, but we have many security problems to solve, and we will have to decide whether to change how elections are run.
To see why, let’s look at how Internet voting will work. When you go to vote, you will use your home computer, a work computer, or some other device to connect to an election server. That server will transmit a ballot back to you. You mark the ballot appropriately to cast your votes, and then the computer transmits the completed ballot back to the election server. The election server then processes the ballot, counting the votes.
Now let’s look at each step in this process.
First, you need to get the ballot from the election server. You have to connect to the election server and provide information to ensure you get the right ballot. In order to do this, you will need to supply your voting address and, possibly, prove your identity.
Let’s see what this means. During Election Day, when you open your browser and type in the Election Office’s web site, you get a message saying the web site is unavailable. You’re thrilled so many people are voting, so you go to work. While there, you try to vote again, with the same result. This happens whenever you try to cast your vote throughout the day. That evening, at 7:55pm (just before the polls close), you try to vote from home one last time. Again, the web site is “unavailable”. Oh, well.
What you just read is a description of a “denial of service”" attack. They are actually fairly common, and extremely easy to launch. In fact, recently many banks (such as U.S. Bank, Bank of America, Wells Fargo Bank, CitiBank, and American Express) [1-3] were victims of such attacks. But the banks have an advantage that election offices don't: lots of servers and lots of money. They can hire teams of cybersecurity experts to respond to these attacks, and can reroute traffic to geographically widely distributed servers to mitigate some of the effects of the attack. Even so, the banks all experienced slow-downs that affected customer use of their web sites.
Given that most Election Offices have 1 or 2 people whose job involves cybersecurity (among other functions) and would have a single server to handle Internet voting, not being able to connect to the election server over the Internet is very realistic. And as the above news articles note, these attacks are easy to launch — from anywhere in the world.
In fact, this has happened. During Hurricane Sandy, New Jersey allowed voters to request email ballots by sending an email to county email addresses set up for this purpose. But the email addresses which received the emails were quickly overwhelmed, and email requests for ballots were bouncing [4,5]. And this was not an attack; it was simply voters requesting email ballots — requests that were never received.
Next, let’s look at how you would retrieve a ballot. You give your voting address, and the election server transmits the appropriate ballot. But how do you know you are talking to the correct election server, and not a fake one?
Someone could send you a fake ballot from a bogus election server. Such a ballot could cause the votes you cast through that ballot to be changed before the ballot is transmitted to the election server. This sounds surprising, but remember that PDF files contain programming instructions that tell the computer how to draw the image on the screen. And that same language can tell the program reading the image to count votes differently than displayed; or they can add markings and cover them up when displayed.
So how do you know the votes you enter on your computer are what is sent to the server? Aside from rigging the ballot files, it is very easy to write programs that alter information; indeed, the infamous computer virus does exactly this. And while antivirus programs are very effective in countering viruses that they know about, they do not protect you against new viruses or other nasty programs on your system. There are many ways to introduce these programs, including having you go to a web site that looks like your bank’s (for example). When you get there, the site has you download something to improve service — and presto!, the malefactors have just put a virus on your system.
With smartphones this is even easier, because we all download apps and run them. The protection most smartphones offer is minimal, so writing an app to cast your vote (suitably doctored, of course) is easy. To get you to download it, the perpetrator sends you an email saying that your election official has set up a web site that you can go to for the app — and when you download it, you really download the doctored app. The election official, of course, did not send this letter.
So you need to be sure that, once you have marked the ballot, the marks you make are the ones that the vote counting system and software will count.
Now let’s say you supply your authentication information to validate who you are, so the election server will send you the right ballot. If you are communicating with a bogus election server, it now has all the information it needs to vote for you — it simply discards your ballot, logs in to the real election server as you, and casts its votes.
How can you be sure you are talking to the right election server? Presumably the county will supply that web address. But if the address comes in an email, it would be easy for some group to send you specially crafted email that displayed the right address as a link — but when you click on the link, it takes you to a completely different web site. This technique is called phishing (or, in this context, spearphishing) and is remarkably effective. This is widely believed to be the way attackers recently took over the Associated Press twitter news feed — and they then posted a fake news story about President Obama being injured by explosions at the White House, causing Wall Street to panic [6].
Instead, if the address doesn’t come in an email, the attackers may send an email on the night before the election that looks like it comes from the elections office, but is an attack as described above. This would probably trick a large number of people, who would be grateful that the elections office was providing a more convenient way of getting to the web page rather than forcing the user to type the full web address into the browser.
Okay, let's assume you are now talking to the real election server. Once you have cast your votes, they have to be transmitted to the election server. (If you haven't given the authentication information yet, you will have to do so now.) This means the ballot must be sent through the Internet. How does it get there? This is called “routing”, and the route the ballot takes depends on a lot of factors that change constantly. Unless specific methods are used to transmit the ballot, the ballot could get lost, or altered, or someone along the way could read it.
The method that has to be used is the same one that you use to talk to your bank — basically, it is an encrypted connection. These connections require the server to send something called a “certificate” that is signed by a trusted agency. But what agency, and how will you know that the certificate is valid? If the certificate is too old, your browser will tell you, and may refuse to allow you to proceed. But many institutions don’t keep their certificates up to date (it costs money for that), so when you see a notice saying “certificate expired”, you may be talking to the right election server. You don't know. Worse is the situation where the certificate is valid but from an unknown agency. How much can you trust that the agency really checked that the elections office asked for the certificate? Someone once had a highly reputable agency issue a new certificate for Microsoft — but he had no connection to Microsoft [7]. (The problem was discovered quickly, and no harm appeared to have been done. We may not be so fortunate in a Presidential election.)
Okay, now your vote has arrived at the election server. The election server has a lot to do, and must do it correctly. That you have voted now needs to be recorded, and in a way that does not indicate which ballot you case. Somehow the two must be decoupled. So, when your ballot arrives at the server, your name is marked as having voted, and the ballot must be digitally signed by the election server to ensure it is not changed after it is received. Then the ballot must be counted or moved to a system that will do the counting. Any error in all this will compromise your vote, your privacy, and/or the accuracy of the results.
The election server is connected to the Internet, of course — and the Internet that you use to connect to the election server is the same one that people around the world can use to connect to it. This includes attackers who want to break into the server, see the data that is there, and change it or the programs on the server to corrupt the results of the election. And attackers succeed at breaking into very well-maintained computers at high-security government agencies, and covering their tracks well. U.S. defense contractors, the Pentagon, other government agencies, financial institutions, and many major corporations have had their systems and web servers compromised [8-11]. These organizations have lots of security expertise and lots of money. They can hire teams of cybersecurity experts to detect attacks, analyze them, repair or reinstall corrupted systems, (attempt to) recover corrupted data, and figure out how to prevent the attacks from recurring. Of course, these responses take time to carry out. Election offices simply do not have these financial, human, or technical resources. Nor do they have the time, because during an election people vote for a fixed period of time (usually 14 hours or so). Thus, ensuring that an election server connected to the Internet is secure simply is infeasible.
Finally, the procedures to be followed to maintain the server's security must be well thought out and followed meticulously. This is a critical, and often overlooked, point: security experts know that a “system” is not secure; a “system” is secure when used in a specific way. A good way to think of this is to consider how safe a car is. When the driver obeys the traffic laws, she is (usually) quite safe. But if she runs red lights, she is not. Similarly, if the Internet voting system procedures are poorly done, or do not take into account the bad things that can prevent voting or corrupting the ballots, poor "system" security is the least of the problems.
It's tempting to assume that you can simply have someone get a ballot, fill it in, scan it into a PDF (or somehow get it into electronic form), and email it back to the county Elections Office. But the same problems arise. Change “election server” to “email server” above, and the description of how someone returns the ballot is the same whether a web browser on a home computer sends it to the (election) server, or a mail program sends it to the (email) server. And if the ballot is to be downloaded or emailed to the voter by an election official, you again have all the problems of getting the ballot as before.
The quest for Internet voting is a good one; but before the body politic decides that it should be implemented, the dangers and problems of it must be known, discussed openly, and a conscious decision made that the consequences of those problems are acceptable. A pilot study using a real election does not provide this information for several reasons. First, no reputable computer security expert will ever attack a voting system during an election (it’s a crime), so we cannot test the security of the system and its procedures as actually used. Second, enabling detection of some attacks requires a complete record of what happens — including how you voted. Before this type of recording is done, the body politic must decide that how you voted can become known, and accept the attendant risks of vote selling and voter intimidation. Third, a very sophisticated attack could well be undetectable — so how would we know the votes were compromised? And so forth. (See my blog entry for Wednesday, April 24, 2013 for a more detailed explanation of this.)
Whether these difficulties can ever be overcome is a very deep, complex question requiring research in technology, human behavior, social organization, political considerations, and legal matters. What is absolutely certain is that, until they are overcome, we should not conduct civic elections over the Internet.
As for my credentials: I am a professor of computer science at the University of California at Davis, where I am a co-director of the Computer Security Laboratory. I have been in the field since 1978. I have been studying electronic and Internet voting since 2004, when I participated in the RABA study of electronic voting systems for the State of Maryland [12]. I was also one of the co-leaders of the technical part of the California Secretary of State's Top-to-Bottom Review of voting systems certified for use in the State of California [13]. Currently, the National Science Foundation is funding our research on election processes [14,15]. Our group works with election officials in Yolo and Marin Counties.
Any opinions expressed in this note are those of the author, and not necessarily those of anyone else.
[ 1] "3 More Major US Banks Report Possible Cyber Attacks," NBC News (Sep. 27, 2012); available at http://www.nbcnews.com/technology/technolog/3-more-major-us-banks-report-possible-cyber-attacks-6126050
[ 2] M. Lennon, "Wells Fargo Says DDoS Attack Disrupting Online Banking Website," Security Week (Mar. 26, 2013); available at http://www.securityweek.com/wells-fargo-says-ddos-attack-disrupting-online-banking-website
[ 3] B. Acohido, "Amex Latest U.S. Major Bank to Get Knocked Offline," USA Today (April 2, 2013); available at http://www.usatoday.com/story/tech/2013/03/29/american-express-denial-of-service-hack/2030197/
[ 4] "Christie Administration Announces E-Mail and Fax Voting Available to New Jerseyans Displaced by Hurricane Sandy," State of New Jersey (Nov. 3, 2012); available at http://www.state.nj.us/governor/news/news/552012/approved/20121103d.html
[ 5] B. Sullivan, "New Jersey's Email Voting Suffers Major Glitches, Deadline Extended to Friday," NBC News (Nov. 6, 2012); available at http://usnews.nbcnews.com/_news/2012/11/06/14974588-new-jerseys-email-voting-suffers-major-glitches-deadline-extended-to-friday
[ 6] J. Steinberg, "Twitter, The Associated Press, and Phishing: Why Breaches Still Occur," Forbes (Apr. 26, 2013); available at http://www.forbes.com/sites/josephsteinberg/2013/04/26/twitter-the-associated-press-and-phishing-why-breaches-still-occur/
[ 7] "Unauthentic 'Microsoft Corporation' Certificates," CERT Advisory CA-2001-04, Pittsburgh, PA (Mar. 30, 2001); available at http://www.cert.org/advisories/CA-2001-04.html
[ 8] M. Riley & B. Elgin, "China Cyberspies Outwit U.S. Stealing Military Secrets," Bloomberg (May 1, 2013); available at http://www.bloomberg.com/news/2013-05-01/china-cyberspies-outwit-u-s-stealing-military-secrets.html
[ 9] G. Wyler, "Pentagon Admits 24,000 Files Were Hacked, Declares Cyberspace A Theater Of War," Business Insider (July 14, 2011); available at http://www.businessinsider.com/pentagon-admits-24000-files-were-hacked-declares-cyberspace-a-theater-of-war-2011-7#ixzz2SAYL2pqp
[10] M. Schwartz, "U.S. Labor Dept. Website Hacked, Serves Malware," Information Week (May 1, 2013); available at http://www.informationweek.com/security/attacks/us-labor-dept-website-hacked-serves-malw/240153984
[11] D. Smith, "Bank of America Hacked By Anonymous: Hackers Leak 'Secrets' About Executives, Salaries, And Spy Activities," International Business Times (Feb. 28, 2013); available at http://www.ibtimes.com/bank-america-hacked-anonymous-hackers-leak-secrets-about-executives-salaries-spy-activities-1107947
[12] "Trusted Agent Report Diebold AccuVote-TS Voting System," RABA Innovative Solution Cell, Columbia, MD (Jan. 20, 2004); available at http://nob.cs.ucdavis.edu/~bishop/notes/2004-RABA/2004-RABA.pdf
[13] M. Bishop, "Overview of Red Team Reports," Office of the California Secretary of State (July 2007); available at http://www.sos.ca.gov/voting-systems/oversight/ttbr/red-overview.pdf
[14] "TC:Medium:Collaborative Research: Technological Support for Improving Election Processes," award from the National Science Foundation tot he University opt California at Davis (Sep. 15, 2009); abstract available at http://www.nsf.gov/awardsearch/showAward?AWD_ID=0905503
[15] "EAGER: Collaborative: Process-Based Technology to Support Comparison and Evaluation of the Security of Elections," award from the National Science Foundation tot he University opt California at Davis (Oct. 1, 2012); abstract available at http://www.nsf.gov/awardsearch/showAward?AWD_ID=1258577
Wednesday, April 24, 2013
Why An Internet Voting Pilot Project Won’t Tell Us What We Need to Know
Why A Pilot Internet Voting Project Won’t Tell Us What We Need to Know
Lots of folks have suggested running some elections using Internet voting as pilots, to see whether Internet voting will work. A pilot will not tell us this.
To see why, ask what makes an election “work”? Counting votes accurately is one thing. Another is recording the votes accurately — that is, each vote cast is counted correctly, and no votes are changed. Further, each person gets one vote, just as in a non-Internet election. The computer or smartphone used to cast the vote, casts the vote without change. And so forth.
Now, how can we tell when it “works”? How do we know the results are correct and have not been altered? This is the heart of the problem.
Let’s say we try an Internet voting pilot project in which people can vote from their home computer or a smartphone. If either contains a computer virus that will change the vote after the user casts it, but before it is transmitted to the vote counting system, how can we tell this? The only way is to record the vote of each voter as the voter casts it, and compare that with the election totals. And we can’t simply store the vote on the computer it is cast on; that could be tampered with. We would have to have an impartial, trusted observer watch each person vote, and record the votes cast on paper or on a separate, trusted system. Aside from being impractical, this means that how someone voted can (and undoubtedly will) become known, allowing vote selling and voter intimidation.
So that’s one problem. We have no way of verifying that the Internet voting system recorded and counted votes correctly — that is, we cannot check its accuracy.
So let’s ask a different question: will the pilot tell us if Internet voting is secure?
The “pilot” is really a test of Internet voting. Unfortunately, a basic principle of testing is that testing can never prove the absence of problems; it can only prove the presence of problems. When you test drive a car, you’re looking for problems that the car may have — perhaps it doesn’t accelerate fast enough, or the brake pedal is too stiff. You don’t buy the car. But if you don’t find any problems, you might well buy it — not realizing that the braking system will fail in a year or so due to a manufacturing defect. Your test drive didn’t show the car had no problems — that is, it didn’t prove the absence of problems. It simply showed you that you didn’t find any problems.
Back to the Internet voting pilot. If security folks analyze the pilot system after the election, they may find evidence of an attack that could have altered ballots or vote totals. This would prove the Internet voting system is not secure. But suppose they find nothing — there still could have been a successful attack, but one in which the attackers “cleaned up” after themselves, leaving nothing behind to be detected. The absence of evidence proves nothing.
There’s another issue. Suppose a company built a safe that they believed no-one could crack. They give a safe to anyone who asks, so that these people can try to crack the safe in the privacy of their home. The company has asked people who succeed to report it, and they will receive a check for $10,000. Now, some people who succeed will report it and get the money. But others who succeed will ask, “If a bank believes this safe to be uncrackable, might not the bank install the safe? And if so, think of how much money I could get by cracking the safe in the bank rather than here at home! I just find banks that use the safe, crack it, and take the money.”
This points out another problem. If someone did figure out how to compromise the Internet voting system, why do it on a pilot? Think of what would happen if that malefactor waited, and then compromised a gubernatorial or presidential election! And in history, a very few votes have made a difference; witness LBJ’s election to the U.S. Senate by 87 votes — an event that, had it not occurred, would have changed the course of American history drastically.
Finally, in a real test, experts (and, possibly, others) would attack the Internet voting system to see if they could change votes or block voters from voting. But no reputable computer security expert will ever attack a voting system during an election (it’s a crime), so we cannot test the security of the system and its procedures as actually used. If it's a “pilot” in a real election, the laws about trying to rig elections apply. So the pilot prevents people from testing the system for security and accuracy. It sounds strange, but it’s quite true.
So, we cannot tell if the Internet voting system counts votes correctly in the pilot; we cannot be sure that the voting system wasn’t broken into; and we can’t legally test the system by attacking it. But these are the purposes of a pilot project. Hence the pilot, done in a real election, is not useful. This is why I think having a pilot election using an Internet voting system is a bad idea: we learn nothing from it, and worse, if the pilot seems to go well as far as we can tell, people will (incorrectly) assume the system is secure and accurate. And that gives a completely false sense of security.
As for my credentials: I am a professor of computer science at the University of California at Davis, where I am a co-director of the Computer Security Laboratory. I have been in the field since 1978. I have been studying electronic and Internet voting since 2004, when I participated in the RABA study of electronic voting systems for the State of Maryland. I was also one of the co-leaders of the technical part of the California Secretary of State’s Top-to-Bottom Review of voting systems certified for use in the State of California. Currently, the National Science Foundation is funding our research on election processes. Our group works with election officials in Yolo and Marin Counties.
Any opinions expressed in this note are those of the author, and not necessarily those of anyone else.
Lots of folks have suggested running some elections using Internet voting as pilots, to see whether Internet voting will work. A pilot will not tell us this.
To see why, ask what makes an election “work”? Counting votes accurately is one thing. Another is recording the votes accurately — that is, each vote cast is counted correctly, and no votes are changed. Further, each person gets one vote, just as in a non-Internet election. The computer or smartphone used to cast the vote, casts the vote without change. And so forth.
Now, how can we tell when it “works”? How do we know the results are correct and have not been altered? This is the heart of the problem.
Let’s say we try an Internet voting pilot project in which people can vote from their home computer or a smartphone. If either contains a computer virus that will change the vote after the user casts it, but before it is transmitted to the vote counting system, how can we tell this? The only way is to record the vote of each voter as the voter casts it, and compare that with the election totals. And we can’t simply store the vote on the computer it is cast on; that could be tampered with. We would have to have an impartial, trusted observer watch each person vote, and record the votes cast on paper or on a separate, trusted system. Aside from being impractical, this means that how someone voted can (and undoubtedly will) become known, allowing vote selling and voter intimidation.
So that’s one problem. We have no way of verifying that the Internet voting system recorded and counted votes correctly — that is, we cannot check its accuracy.
So let’s ask a different question: will the pilot tell us if Internet voting is secure?
The “pilot” is really a test of Internet voting. Unfortunately, a basic principle of testing is that testing can never prove the absence of problems; it can only prove the presence of problems. When you test drive a car, you’re looking for problems that the car may have — perhaps it doesn’t accelerate fast enough, or the brake pedal is too stiff. You don’t buy the car. But if you don’t find any problems, you might well buy it — not realizing that the braking system will fail in a year or so due to a manufacturing defect. Your test drive didn’t show the car had no problems — that is, it didn’t prove the absence of problems. It simply showed you that you didn’t find any problems.
Back to the Internet voting pilot. If security folks analyze the pilot system after the election, they may find evidence of an attack that could have altered ballots or vote totals. This would prove the Internet voting system is not secure. But suppose they find nothing — there still could have been a successful attack, but one in which the attackers “cleaned up” after themselves, leaving nothing behind to be detected. The absence of evidence proves nothing.
There’s another issue. Suppose a company built a safe that they believed no-one could crack. They give a safe to anyone who asks, so that these people can try to crack the safe in the privacy of their home. The company has asked people who succeed to report it, and they will receive a check for $10,000. Now, some people who succeed will report it and get the money. But others who succeed will ask, “If a bank believes this safe to be uncrackable, might not the bank install the safe? And if so, think of how much money I could get by cracking the safe in the bank rather than here at home! I just find banks that use the safe, crack it, and take the money.”
This points out another problem. If someone did figure out how to compromise the Internet voting system, why do it on a pilot? Think of what would happen if that malefactor waited, and then compromised a gubernatorial or presidential election! And in history, a very few votes have made a difference; witness LBJ’s election to the U.S. Senate by 87 votes — an event that, had it not occurred, would have changed the course of American history drastically.
Finally, in a real test, experts (and, possibly, others) would attack the Internet voting system to see if they could change votes or block voters from voting. But no reputable computer security expert will ever attack a voting system during an election (it’s a crime), so we cannot test the security of the system and its procedures as actually used. If it's a “pilot” in a real election, the laws about trying to rig elections apply. So the pilot prevents people from testing the system for security and accuracy. It sounds strange, but it’s quite true.
So, we cannot tell if the Internet voting system counts votes correctly in the pilot; we cannot be sure that the voting system wasn’t broken into; and we can’t legally test the system by attacking it. But these are the purposes of a pilot project. Hence the pilot, done in a real election, is not useful. This is why I think having a pilot election using an Internet voting system is a bad idea: we learn nothing from it, and worse, if the pilot seems to go well as far as we can tell, people will (incorrectly) assume the system is secure and accurate. And that gives a completely false sense of security.
As for my credentials: I am a professor of computer science at the University of California at Davis, where I am a co-director of the Computer Security Laboratory. I have been in the field since 1978. I have been studying electronic and Internet voting since 2004, when I participated in the RABA study of electronic voting systems for the State of Maryland. I was also one of the co-leaders of the technical part of the California Secretary of State’s Top-to-Bottom Review of voting systems certified for use in the State of California. Currently, the National Science Foundation is funding our research on election processes. Our group works with election officials in Yolo and Marin Counties.
Any opinions expressed in this note are those of the author, and not necessarily those of anyone else.
Monday, April 22, 2013
About Internet Voting
About Internet Voting
California Assembly Bill 19 (Ting, D-San Francisco) [1] proposes to allow Internet voting. The bill has two serious problems.The first is in Section 4502(b)(2), which describes what the Internet voting system is to be tested for. They must check that no-one can make the system report inaccurate tallies or change votes. But the bill does not require testing to ensure that all parts of the voting system will be available during the voting period.
Let’s see what this means. During Election Day, when you open your browser and type in the Election Office’s web site, you get a message saying the web site is unavailable. You’re thrilled so many people are voting, so you go to work. While there, you try to vote again, with the same result. This happens whenever you try to cast your vote throughout the day. That evening, at 7:55pm (just before the polls close), you try to vote from home one last time. Again, the web site is “unavailable”. Oh, well.
What you just read is a description of a “denial of service” attack. They are actually fairly common, and extremely easy to launch. In fact, recently many banks (such as U.S. Bank, Bank of America, Wells Fargo Bank, CitiBank, and American Express [2,3,4]) were victims of such attacks. But the banks have an advantage that election offices don’t: lots of servers and lots of money. They can hire teams of cybersecurity experts to respond to these attacks, and can reroute traffic to geographically widely distributed servers to mitigate some of the effects of the attack. Even so, the banks all experienced slow-downs that affected customer use of their web sites.
Given that most Election Offices have 1 or 2 people whose job involves cybersecurity (among other functions) and would have a single server to handle Internet voting, the possibility of Internet voting with an inaccessible server is very realistic. And as the above news articles note, these attacks are easy to launch — from anywhere in the world.
In fact, this has happened. During Hurricane Sandy, New Jersey allowed voters to request email ballots by sending an email to county email addresses set up for this purpose [5]. But the email addresses which received the emails were quickly overwhelmed, and email requests for ballots were bouncing [6]. And this was not an attack; it was simply voters requesting email ballots.
Thus, any proposed Internet voting system needs to be able to handle a denial of service attack. But the bill does not require they be tested for this ability.
The second problem is much more basic: what is an “Internet voting system”? The bill defines it in Sec. 4500(2). It includes the election office server, of course, and the Internet. But what else does it include? The system or device you cast your vote on, and that then transmits the vote to the election server.
Let’s assume you are voting on your home computer. How do you know the votes you enter on your computer are what is sent to the server? It is very easy to write programs that alter information; indeed, the infamous computer virus does exactly this. And while antivirus programs are very effective in countering viruses that they know about, they do not protect you against new viruses or other nasty programs on your system. There are many ways to introduce these programs, including having you go to a web site that looks like your bank’s (for example). When you get there, the site has you download something to improve service — and presto!, the malefactors have just put a virus on your system.
With smartphones this is even easier, because we all download apps and run them. The protection most smartphones offer is minimal, so writing an app to cast your vote (suitably doctored, of course) is easy to write. To get you to download it, the perpetrator sends you an email saying that your election official has set up a web site that you can go to for the app — and when you download it, you really download the doctored app. The election official, of course, did not send this letter.
And there are even more problems. The bill doesn’t require the Secretary of State to certify the system, despite what the legislative counsel’s digest says. It simply requires that the report say the system meets “the standards of accuracy, security, integrity, efficacy, and accessibility”; then it is deemed certified (4502(c)). What “the standards” are is nowhere defined. Also, the bill says nothing about certifying the procedures under which the system is to be used.
This last point is critical. Security experts know that a “system” is not secure; a “system” is secure when used in a specific way. A good way to think of this is to consider how safe a car is. When the driver obeys the traffic laws, she is (usually) quite safe. But if she runs red lights, she is not. Similarly, if the Internet voting system procedures are poorly done, or do not take into account the bad things that can prevent voting or corrupting the ballots, poor “system” security is the least of the problems. Yet the bill does not require these be checked.
The quest for Internet voting is a good one; but before the body politic decides that it should be implemented, the dangers and problems of it must be known, discussed openly, and a conscious decision made that the consequences of those problems are acceptable. A pilot study using a real election does not provide this information for several reasons. First, no reputable computer security expert will ever attack a voting system during an election (it’s a crime), so we cannot test the security of the system and its procedures as actually used. Second, enabling detection of some attacks requires a complete record of what happens — including how you voted. Before this type of recording is done, the body politic must decide that how you voted can become known, and accept the attendant risks of vote selling and voter intimidation. Third, a very sophisticated attack could well be undetectable — so how would we know the votes were compromised? And so forth.
I applaud Assemblyman Ting’s desire to increase voter turnout. But this bill isn’t the way to do it.
As for my credentials: I am a professor of computer science at the University of California at Davis, where I am a co-director of the Computer Security Laboratory. I have been in the field since 1978. I have been studying electronic and Internet voting since 2004, when I participated in the RABA study of electronic voting systems for the State of Maryland [7]. I was also one of the co-leaders of the technical part of the California Secretary of State’s Top-to-Bottom Review of voting systems certified for use in the State of California [8]. Currently, the National Science Foundation is funding our research on election processes [9,10]. Our group works with election officials in Yolo and Marin Counties.
Any opinions expressed in this note are those of the author, and not necessarily those of anyone else.
References
[1] “Internet Voting Pilot Program,” Assembly Bill No. 19, California State Assembly (Apr. 16, 2013); available at http://www.leginfo.ca.gov/pub/13-14/bill/asm/ab_0001-0050/ab_19_bill_20130416_amended_asm_v97.htm[2] “3 More Major US Banks Report Possible Cyber Attacks,” NBC News (Sep. 27, 2012); available at http://www.nbcnews.com/technology/technolog/3-more-major-us-banks-report-possible-cyber-attacks-6126050
[3] M. Lennon, “Wells Fargo Says DDoS Attack Disrupting Online Banking Website,” Security Week (Mar. 26, 2013); available at http://www.securityweek.com/wells-fargo-says-ddos-attack-disrupting-online-banking-website
[4] B. Acohido, “Amex Latest U.S. Major Bank to Get Knocked Offline,” USA Today (April 2, 2013); available at http://www.usatoday.com/story/tech/2013/03/29/american-express-denial-of-service-hack/2030197/
[5] “Christie Administration Announces E-Mail and Fax Voting Available to New Jerseyans Displaced by Hurricane Sandy,” State of New Jersey (Nov. 3, 2012); available at http://www.state.nj.us/governor/news/news/552012/approved/20121103d.html
[6] B. Sullivan, “New Jersey’s Email Voting Suffers Major Glitches, Deadline Extended to Friday,” NBC News (Nov. 6, 2012); available at http://usnews.nbcnews.com/_news/2012/11/06/14974588-new-jerseys-email-voting-suffers-major-glitches-deadline-extended-to-friday
[7] “Trusted Agent Report Diebold AccuVote-TS Voting System,” RABA Innovative Solution Cell, Columbia, MD (Jan. 20, 2004); available at http://nob.cs.ucdavis.edu/~bishop/notes/2004-RABA/2004-RABA.pdf
[8] M. Bishop, “Overview of Red Team Reports,” Office of the California Secretary of State (July 2007); available at http://www.sos.ca.gov/voting-systems/oversight/ttbr/red-overview.pdf
[9] “TC:Medium:Collaborative Research: Technological Support for Improving Election Processes,” award from the National Science Foundation to the University of California at Davis (Sep. 15, 2009); abstract available at http://www.nsf.gov/awardsearch/showAward?AWD_ID=0905503
[10] “EAGER: Collaborative: Process-Based Technology to Support Comparison and Evaluation of the Security of Elections,“ award from the National Science Foundation to the University of California at Davis (Oct. 1, 2012); abstract available at http://www.nsf.gov/awardsearch/showAward?AWD_ID=1258577
Tuesday, March 19, 2013
Our Trip to India, Feb 22 – Mar 4, 2013
Travel Entry #1: February 25, 2013: Arrival
We left Sacramento in the morning of February 23. We flew to Los Angeles, then boarded a KLM flight to Amsterdam. We chose bulkhead seats in the economy compartment (we couldn’t get them in economy plus) — a big mistake. Because they are bulkhead row, the trays are built into the side of the seats, so the video controls cannot be recessed. The video is also built into the seat, so the tray table can’t be moved. The result is a loss of about 1 inch of seat width — and boy, do you feel it! I couldn’t sit down directly; I had to sit on the front and slide backwards. Even so, I never got all the way in. The plane is a Boeing 747; if you’re big like me, avoid the bulkhead rows in economy.
The plane that took us from Amsterddam to New Delhi.
We arrived in India safely today, at 12:15AM! Our friend Shawn had arranged for a driver to meet us at the airport and take us to our hotel. It is a very nice hotel, in the better section of New Delhi — although there is construction near the hotel entrance, you’d never know it. One amusing note: we were very hungry when we arrived, and looking over the menu all they had was Western food—so we had cheeseburgers and French fries! It brought back memories of a wonderful visit to Iran, where we would have an afternoon snack of French Fries amid the lunches and dinners of delicious Persian food. Here are some photos of the hotel.
The grounds of the Imperial Hotel.
We got up in the morning and met our driver, who took us around Delhi. He was an excellent guide. First, we went to the Quwwatul-Islam Masjid, which is the earliest extant mosque in India. It has a huge tower, the Qutb Minar, which we could not climb, and the architecture of which is spectacular. The age of the mosque, and that the tower still stood, is a testament to the love and care the architects and builders put into it. Not surprising, given it was a house of worship.
The Qutb Minar.
We spent some time at Humayun’s Tomb. In addition to the large central building, the grounds include broad grassy fields and four smaller buildings, one at each direction of the compass. This was a traditional Indian layout, with the building at the center dominated by the gardens. The Taj Mahal, though, has a different arrangement.
Humayun’s Tomb.
Along the way, we saw lots of dogs. They wander all over the place, playing and (mostly) sleeping in the sun. On the way out of the Indian restaurant where we ate lunch, we saw a cobra charmer. He was good! And the traffic reminded us of traffic in Dhaka, but we thought the drivers in India took fewer risks. That’s not saying much! I understand why PK told us not even to think of driving in India. Good advice!
The dogs of New Delhi.
A charming snake charmer.
Travel Entry #2: February 26, 2013: Delhi to Agra and Sights at Both
The next day, we spent the morning at the Red Fort. As we wandered around, we sometimes thought we were in Iran, due to the Persian architecture and art. Not surprising, as Shah Jahan had Persian architects, artists, and workers building the Fort.
The Red Fort.
Is this India or Iran (Persia)? Yes!
The people in India were wonderful — very warm and friendly. As we were leaving the Red Fort, about 200 schoolchildren and their teachers were entering. They waved to us; we replied, “namaste“ and waved back. They smiled and said “Hello!” and “Welcome to India!”. It was a lot of fun.
Schoolchildren entering the Red Fort.
We then were driven to Agra. Driving in India is quite an experience. We were warned not to drive, and IIT Kanpur very kindly provided a driver from Delhi until we got to IIT Kanpur. The roads are rough in many places; the driver wove in between cars and trucks, through gaps we didn’t think he could make. But it was all perfectly safe. Also, the trucks we saw were piled high with their cargo — very high; so high that it was a wonder the dump trucks didn’t lose gravel or dirt.
A heavily-loaded truck on the road from Agra to Kanpur.
At Agra, the hotel we stayed in had a really cool lamp. It looked like the phones in the Village of the TV show The Prisoner (the 1967 version starring Patrick McGoohan). We splurged and had a delicious dinner by the pool.
“Yes, Number 2, I know that I am not indispensible.”
Before that, though, we went to visit the Taj Mahal. You can’t drive directly there. You stop about a kilometer away, and walk, or ride a pedicab or horse-drawn wagon. We chose the latter. Our horse, Raju, was festooned with ornaments, and got us quickly to the gate. The driver even let Holly control the horse.
I have wanted to see the Taj Mahal ever since I read about it in Richard Halliburton’s Book of Marvels, and it exceeded anything I imagined. The four minarets surround a central tomb. The minarets are not vertical; they are angled outward. We were given two reasons: (1) if there is an earthquake, they will fall out, avoiding damage to the central tomb; and (2) when you look at them from afar they look vertical. By the way, that’s Holly looking at the camera in the lower picture.
The Taj Mahal.
The Taj Mahal is at the edge of the grounds, unlike most other Indian architectures. It dominates the grounds. There are other buildings there too. The grounds are quite well kept, with lots of water in the fountains. In order to get to the base of the Taj Mahal, you either need to remove your shoes or cover them. They have shoe covers, which we used.
Some other buildings on the Taj Mahal grounds.
Here’s a photo of Holly on the grounds of the Taj Mahal.
We visited the Taj Mahal on February 26, and went back on February 27. Next stop: the Agra Fort.
Travel Entry #3: February 27, 2013: More Agra and Agra to IIT Kanpur
Many years ago, India was governed by the mughals who lived in the Agra Fort. It has a number of palaces, and is the same reddish color as the Red Fort in Delhi. You enter through a portal that looks like a castle entry, go up a ramp (that’s Holly in the foreground of the picture) and at the top, once you go under another arch, you get to a large grassy square (really, a rectangle). From there, you can wander around and see lots of buildings of interesting architecture. We could also see the Taj Mahal in the distance.
Agra Fort portal.
Agra Fort ramp (that’s Holly in the foreground).
Grassy square in the Agra Fort..
Some buildings in the Agra Fort.
Taj Mahal as seen from the Agra Fort.
Our driver then took us to IIT Kanpur. The Institute is its own little city, and you can see the difference when you enter it; the contrast between its well-kept grounds and those of the impoverished town is quite stark. The Institute grounds are completely safe, with faculty, staff, and students housed mostly on campus. There are schools for their children on campus too, as well as security. It’s well lighted, so it is even safe at night.
We were housed in the Guest House, a set of rooms for visitors. Below are pictures of the courtyard and of the grounds. The flowers were a blaze of color; here is the entrance to the building where the conference was held. Note the flowers lining the entrance.
The courtyard at the Guest House.
The IIT Kanpur grounds.
The entrance to the conference building.
Travel Entry #4: February 28 – March 2, 2013: The Conference
I won’t say much about this because I was focused on what was being said (and what I was saying). Suffice it to say it was quite exhilarating. The attendees are very sharp, and asked excellent questions. The students in particular were very perceptive, and their posters were well done and illustrated their work well.
The auditorium as it fills up.
Travel Entry #5: March 2, 2013: Rambling Around Campus
The conference ended around 2:00PM on March 2, so we had some free time. Our hosts arranged us on a tour of the campus with a student guide. We went to the Institute airport, where there is a very active flying club. There is a new building being built for the Computer Science Department. Peacocks also decorate the lawns.
The IIT Kanpur air field.
The new computer science building (under construction).
Here there be peacocks!
Travel Entry #6: March 3, 2013: Lucknow and Back to Delhi
Our plans then took us to Lucknow; again, the Institute was kind enough to provide a driver. The trip to Lucknow was relatively uneventful, except for a large number of people walking on the road dressed very colorfully. We think they might have been going to some sort of festival.
The people walking.
At Lucknow, we went first to the Bara Imambara. Several buildings surrounded a lovely square with gardens, and the big building, three stories high, was a mosque; you had to take your shoes off to enter. They had no shoe coverings, though, so we decided to wander around the grounds. On our way out, we were asked to sign the guest book, which we were happy to do.I mention this because it’s the only place where we were asked to do this.
The Bara Imambara.
We then went to the Residency, the ruins of a place where a battle between British soldiers and Indians during the Indian Rebellion of 1857. The Residency is still in ruins. There is a museum on the grounds that tells the story of the rebellion and what happened at the Residency.
Some battle-scarred buildings at the Residency.
The Residency Museum.
We also met two people who chatted with us about the Residency, and about Islam; they were delightful gentlemen! Here is a picture of them with Holly:
In the middle of Lucknow are some fast food places; keeping with our custom of photographing them (yes, we’re weird!), here are a couple of pictures. So far we’ve seen them in Bologna, Moscow, Lucknow, Budapest, and a number of other places.
Fast food places in Lucknow.
We then went to the airport at Lucknow to catch an airplane to New Delhi, where we would board an Air France flight to Paris, and then a Delta flight home (via Los Angeles). The plane left Lucknow about 2 hours late; fortunately we had a 6 hour layover scheduled in New Delhi. When we got there, an Air France ticket agent gave us a pass to a lounge which had a shower — a true blessing, because after our wanderings around Lucknow, we were hot and sticky.
Holly wanted to bring home an elephant; I pointed out we wouldn’t have to pack it, as it had its own trunk (yes, she let me live). But we couldn’t figure out how to sneak one onto the plane, so she had to settle for a picture of two.
Statue of 2 elephants in the New Delhi airport.
Much refreshed, we came home, arriving on the same day we left (thanks to the difference in time zones). We had a glorious time; but like all wanderers, it’s always good to come home.
Subscribe to:
Posts (Atom)
