A long form look on the Estonian iVoting experience and our thoughts on why it’s not feasible here at home.
Viewing entries tagged
Now, let’s turn to Plouffe’s notion of “digital voting.” Honestly, that phrase is confusing and vague. We should know: it catalyzed our name change last year from Open Source Digital Voting Foundation (OSDV) to Open Source Election Technology Foundation (OSET).
…not much we think.
Yesterday’s news of Microsoft co-founder billionaire Paul Allen’s investing $40M in the Spanish election technology company Scytl is validation that elections remain a backwater of innovation in the digital age.
But it is not validation that there is a viable commercial market for voting systems of the size typically attracting venture capitalists; the market is dysfunctional and small and governments continue to be without budget.
And the challenges of building a user-friendly secure online voting system that simultaneously protects the anonymity of the ballot is an interesting problem that only an investor of the stature of Mr. Allen can tackle.
We think this illuminates a larger question:
To what extent should the core technology of the most vital aspect of our Democracy be proprietary and black box, rather than publicly owned and transparent?
To us, that is a threshold public policy question, commercial investment viability issues notwithstanding.
To be sure, it is encouraging to see Vulcan Capital and a visionary like Paul Allen invest in voting technology. The challenges facing a successful elections ecosystem are complex and evolving and we will need the collective genius of the tech industry’s brightest to deliver fundamental innovation.
We at the TrustTheVote Project believe voting is a vital component of our nation’s democracy infrastructure and that American voters expect and deserve a voting experience that’s verifiable, accurate, secure and transparent. Will Scytl be the way to do so?
The Main Thing
The one thing that stood out to us in the various articles on the investment were Scytl’s comments and assertions of their security with international patents on cryptographic protocols. We’ve been around the space of INFOSEC for a long time and know a lot of really smart people in the crypto field. So, we’re curious to learn more about their IP innovations. And yet that assertion is actually a red herring to us.
Here’s the main thing: transacting ballots over the public packet switched network is not simply about security. Its also about privacy; that is, the secrecy of the ballot. Here is an immutable maxim about the digital world of security and privacy: there is an inverse relationship, which holds that as security is increased, privacy must be decreased, and vice-verse. Just consider any airport security experience. If you want maximum security then you must surrender a bunch of privacy. This is the main challenge of transacting ballots across the Internet, and why that transaction is so very different from banking online or looking at your medical record.
And then there is the entire issue of infrastructure. We continue to harp on this, and still wait for a good answer. If by their own admissions, the Department of Defense, Google, Target, and dozens of others have challenges securifying their own data centers, how exactly can we be certain that a vendor on a cloud-based service model or an in-house data center of a county or State has any better chance of doing so? Security is an arms race. Consider the news today about Heartbleed alone.
Oh, and please for the sake of credibility can the marketing machinery stop using the phrase “military grade security?” There is no such thing. And it has nothing to do with an increase in the 128-bit encryption standard RSA keys to say, 512 or 1024 bit. 128-bit keys are fine and there is nothing military to it (other than the Military uses it). Here is an interesting article from some years ago on the sufficiency of current crypto and the related marketing arms race. Saying “military grade” is meaningless hype. Besides, the security issues run far beyond the transit of data between machines.
In short, there is much the public should demand to understand from anyone’s security assertions, international patents notwithstanding. And that goes for us too.
The Bottom Line
While we laud Mr. Allen’s investment in what surely is an interesting problem, no one should think for a moment that this signals some sort of commercial viability or tremendous growth market opportunity. Nor should anyone assume that throwing money at a problem will necessarily fix it (or deliver us from the backwaters of Government elections I.T.). Nor should we assume that this somehow validates Scytl’s “model” for “security.”
Perhaps more importantly, while we need lots of attention, research, development and experimentation, the bottom line to us is whether the outcome should be a commercial proprietary black-box result or an open transparent publicly owned result… where the “result” as used here refers to the core technology of casting and counting ballots, and not the viable and necessary commercial business of delivering, deploying and servicing that technology.
Alaska's extension to its iVoting venture may have raised the interests of at least one journalist for one highly visible publication. When we were asked for our "take" on this form of iVoting, we thought that we should also comment here on this "northern exposed adventure." (apologies to those fans of the mid-90s wacky TV series of a similar name.) Alaska has been among the states that allow military and overseas voters to return marked absentee ballots digitally, starting with fax, then eMail, and then adding a web upload as a 3rd option. Focusing specifically on the web-upload option, the question was: "How is Alaska doing this, and how do their efforts square with common concerns about security, accessibility, Federal standards, testing, certification, and accreditation?"
In most cases, any voting system has to run that whole gauntlet through to accreditation by a state, in order for the voting system to be used in that state. To date, none of the iVoting products have even trying to run that gauntlet.
So, what Alaska is doing, with respect to security, certification, and host of other things is essentially: flying solo.
Their system has not gone through any certification program (State, Federal, or otherwise that we can tell); hasn't been tested by an accredited voting system test lab; and nobody knows how it does or doesn't meet federal requirements for security, accessibility, and other (voluntary) specifications and guidelines for voting systems.
In Alaska, they've "rolled their own" system. It's their right as a State to do so.
In Alaska, military voters have several options, and only one of them is the ability to go to a web site, indicate their choices for vote, and have their votes recorded electronically -- no actual paper ballot involved, no absentee ballot affidavit or signature needed. In contrast to the sign/scan/email method of return of absentee ballot and affidavit (used in Alaska and 20 other states), this is straight-up iVoting.
So what does their experience say about all the often-quoted challenges of iVoting? Well, of course in Alaska those challenges apply the same as anywhere else, and they are facing them all:
- insider threats;
- outsider hacking threats;
- physical security;
- personnel security; and
- data integrity (including that of the keys that underlie any use of cryptography)
In short, the Alaska iVoting solution faces all the challenges of digital banking and online commerce that every financial services industry titan and eCommerce giant spends big $ on every year (capital and expense), and yet still routinely suffer attacks and breaches.
Compared to the those technology titans of industry (Banking, Finance, Technology services, or even the Department of Defense), how well are Alaskan election administrators doing on their shoestring (by comparison) budget?
Good question. It's not subject to annual review (like banks' IT operations audit for SAS-70), so we don't know. That also is their right as a U.S. state. However, the fact that we don't know, does not debunkany of the common claims about these challenges. Rather, it simply says that in Alaska they took on the challenges (which are large) and the general public doesn't know much about how they're doing.
To get a feeling for risks involved, just consider one point, think about the handful of IT geeks who manage the iVoting servers where the votes are recorded and stored as bits on a disk. They arenot election officials, and they are no more entitled to stick their hands into paper ballots boxes than anybody else outside a county elections office. Yet, they have the ability (though not the authorization) to access those bits.
- Who are they?
- Does anybody really oversee their actions?
- Do they have remote access to the voting servers from anywhere on the planet?
- Using passwords that could be guessed?
- Who knows?
They're probably competent responsible people, but we don'tknow. Not knowing any of that, then every vote on those voting servers is actually a question mark -- and that's simply being intellectually honest.
Lastly, to get a feeling for the possible significance of this lack of knowledge, consider a situation in which Alaska's electoral college votes swing an election, or where Alaska's Senate race swings control of Congress (not far-fetched given Murkowski's close call back in 2010.)
When the margin of victory in Alaska, for an election result that effects the entire nation, is a low 4-digit number of votes, and the number of digital votes cast is similar, what does that mean?
It's quite possible that those many digital votes could be cast in the next Alaska Senate race. If the contest is that close again, think about the scrutiny those IT folks will get. Will they be evaluated any better than every banking data center investigated after a data breach? Any better than Target? Any better than Google or Adobe's IT management after having trade secrets stolen? Or any better than the operators of military unclassified systems that for years were penetrated through intrusion from hackers located in China who may likely have been supported by the Chinese Army or Intelligence groups?
Instead, they'll be lucky (we hope) like the Estonian iVoting administrators, when the OCSE visited back in 2011 to have a look at the Estonian system. Things didn't go so well. OCSE found that one guy could have undermined the whole system. Good news: it didn't happen. Cold comfort: that one guy didn't seem to have the opportunity -- most likely because he and his colleagues were busier than a one-armed paper hanger during the election, worrying about Russian hackers attacking again, after they had previously shut-down the whole country's Internet-connect government systems.
But so far, the current threat is remote, and it is still early days even for small scale usage of Alaska's iVoting option. But while the threat is still remote, it might be good for the public to see some more about what's "under the hood" and who's in charge of the engine -- that would be our idea of more transparency.
Wandering off the Main Point for a Few Paragraphs So, in closing I'm going to run the risk of being a little preachy here (signaled by that faux HTML tag above); again, probably due to the surge in media inquiries recently about how the Millennial generation intends to cast their ballots one day. Lock and load.
I (and all of us here) are all for advancing the hallmarks of the Millennial mandates of the digital age: ease and convenience. I am also keenly aware there are wing-nuts looking for their Andy Warhol moment. And whether enticed by some anarchist rhetoric, their own reality distortion field, or most insidious: the evangelism of a terrorist agenda (domestic or foreign) ...said wing nut(s) -- perhaps just for grins and giggles -- might see an opportunity to derail an election (see my point above about a close race that swings control of Congress or worse).
Here's the deep concern: I'm one of those who believes that the horrific attacks of 9.11 had little to do with body count or the implosions of western icons of financial might. The real underlying agenda was to determine whether it might be possible to cause a temblor of sufficient magnitude to take world financial markets seriously off-line, and whether doing so might cause a rippling effect of chaos in world markets, and what disruption and destruction that might wreak. If we believe that, then consider the opportunity for disruption of the operational continuity of our democracy.
Its not that we are Internet haters: we're not -- several of us came from Netscape and other technology companies that helped pioneer the commercialization of that amazing government and academic experiment we call the Internet. Its just that THIS Internet and its current architecture simply was not designed to be inherently secure or to ensure anyone's absolute privacy (and strengthening one necessarily means weakening the other.)
So, while we're all focused on ease and convenience, and we live in an increasingly distributed democracy, and the Internet cloud is darkening the doorstep of literally every aspect of society (and now government too), great care must be taken as legislatures rush to enact new laws and regulations to enable studies, or build so-called pilots, or simply advance the Millennial agenda to make voting a smartphone experience. We must be very careful and considerably vigilant, because its not beyond the realm of reality that some wing-nut is watching, cracking their knuckles in front of their screen and keyboard, mumbling, "Oh please. Oh please."
Alaska has the right to venture down its own path in the northern territory, but it does so exposing an attack surface. They need not (indeed, cannot) see this enemy from their back porch (I really can't say of others). But just because it cannot be identified at the moment, doesn't mean it isn't there.
One other small point: As a research and education non-profit we're asked why shouldn't we be "working on making Internet voting possible?" Answer: Perhaps in due time. We do believe that on the horizon responsible research must be undertaken to determine how we can offer an additional alternative by digital means to casting a ballot next to absentee and polling place experiences. And that "digital means" might be over the public packet-switched network. Or maybe some other type of network. We'll get there. But candidly, our charge for the next couple of years is to update an outdated architecture of existing voting machinery and elections systems and bring about substantial, but still incremental innovation that jurisdictions can afford to adopt, adapt and deploy. We're taking one thing at a time and first things first; or as our former CEO at Netscape used to say, we're going to "keep the main thing, the main thing."
As frequent readers will note, Internet voting as a discussion topic is one we increasingly tire of -- there is so much else to do! that unlike Internet Voting, can actually be done today! Let's talk instead about what tech innovations can do speed up the long lines at polling places, for example. But nevertheless, today, esteemed colleagues were asking for a "definitive statement" on i-voting, having been asked for such by folks who work for legislators interested in the topic. So I thought I'd share what I like to say when legislators, staffers, etc. ask for "definitive". Basically 3 steps.
Look to the National Institute of Standards and Technology (NIST), the U.S. government's top authority on technology issues. They've studied the use of the Internet for everything in elections, including voting.
- Read their conclusion on top half of page 69 of NIST's "Threat Analysis of Voting Systems" (here), supported by analysis in pages 42-46.
- Also briefly flip through NIST's 36 pages of "Information System Security Best Practices" (here) for Internet-connected election support systems.
- Think about whether state or local election officials would have the funding to comply with NIST guidelines, even for the lower bar of distributing blank ballots, much less the higher bar of Internet Voting.
That's pretty much it.
PS: While we're on the topic, my thanks to Jeremy Epstein for tackling another topic on i-voting (botnets, one among several i-voting topics that I am happy to leave to Jeremy and other colleagues in the security world), and for letting me put my 2 cents in for his Freedom To Tinker blog today. Thanks Jeremy, for doing the $0.98, and keep up the good work ! -- ejs
An esteemed colleague noted the news of the USPS stopping weekend delivery, as part of a trend of slow demise of the USPS, and asked: will we get to the point where vote-by-mail is vote-by-Fedex? And would that be bad, having a for-profit entity acting as the custodian for a large chunk of the ballots in an election? The more I thought about it, the more flummoxed I was. I had to take off the geek hat and dust off the philosopher hat, looking at the question from a viewpoint of values, rather than (as would be my wont) requirements analysis or risk analysis. I goes like this ...
I think that Phil's question is based on assumption of some shared values among voters -- all voters, not just those that vote by mail -- that make postal voting acceptable because ballots are a "government things" and so is postal service. Voting is in part an act of faith in government to be making a good faith effort to do the job right, and keep the operations above a minimum acceptable level of sanity. It "feels OK" to hand a marked ballot to my regular neighborhood post(wo)man, but not to some stranger dropping off a box from a delivery truck. Translate from value to feeling to expectation: it's implied that we expect USPS staff to know that they have a special government duty in delivering ballots, and to work to honor that duty, regarding the integrity of those special envelopes as a particular trust, as well as their timely delivery.
- Having re-read all that, it sounds so very 20th century, almost as antique as lever machines for voting.
I don't really think that USPS is "the government" anymore, not in the sense that the journey of a VBM ballot is end-to-end inside a government operation. I'm not sure that Fedex or UPS are inherently more or less trustworthy. In fact they all work for each other now! And certainly in some circumstances the for-profit operations may to some voters feel more trustworthy -- whether because of bad experiences with USPS, or because of living overseas in a country that surveils US citizens and operates the postal service.
Lastly, I think that many people do share the values behind Phil's question -- I know I do. The idea makes me wobbly. I think it comes down to this:
- If you're wobbly on for-profit VBM, then get back into the voting booth, start volunteering to help your local election officials, and if they are effectively outsourcing any election operations to for-profit voting system vendors, help them stop doing so.
- If you not wobbly, then you're part of trend to trusting -- and often doing -- remote voting with significant involvement from for-profit entities - and we know where that is headed.
The issue with USPS shows that in the 21st century, any form of remote voting will involve for-profits, whether it is Fedex for VBM, or Amazon cloud services for i-voting. My personal conclusions:
- Remote voting is lower integrity no matter what, but gets more people voting because in-person voting can be such a pain.
- I need to my redouble efforts to fix the tech so that in-person voting is not only not a pain, but actually more desirable than remote voting.
Much as I admire everybody at the New York Times, I have to disagree with Nick Bilton on his piece Disruptions: Casting a Ballot by Smartphone. I have to say I don't blame him though, especially given the broad range of coverage of the many many kinds election dysfunction that occurred and are still occurring now during state canvassing....
I've spent a fair bit of time over the last few days digesting a broad range of media responses to last week's election's operation, much it reaction to President Obama's "we've got to fix that" comment in his acceptance speech. There's a lot of complaining about the long lines, for example, demands for explanation of them, or ideas for preventing them in te future -- and similar for the difficulty that some states and counties face for finishing the process of counting the ballots. It's a healthy discussion for the most part, but one that makes me sad because it mostly misses the main point: the root cause of most election dysfunction. I can explain that briefly from my viewpoint, and back that up with several recent events. The plain unvarnished truth is that U.S. local election officials, taken all together as the collective group that operates U.S. federal and state elections, simply do not have the resources and infrastructure to conduct elections that
- have large turnout and close margins, preceded by much voter registration activity;
- are performed with transparency that supports public trust in the integrity of the election being accessible, fair, and accurate.
There are longstanding gaps in the resources needed, ranging from ongoing budget for sufficient staff, to inadequate technology for election administration, voting, counting, and reporting.
Of course in any given election, there are local elections operations that proceed smoothly, with adequate resources and physical and technical infrastructure. But we've seen again and again, that in every "big" election, there is a shifting cast of distressed states or localities (and a few regulars), where adminstrative snafus, technology glitches, resource limits, and other factors get magnified as a result of high participation and close margins. Recent remarks by Broward County, FL, election officials -- among those with the most experience in these matters -- really crystalized it for me. When asked about the cause of the long lines, their response (my paraphrase) is that when the election is important, people are very interested in the election, and show up in large numbers to vote.
That may sound like a trivial or obvious response, but consider it just a moment more. Another way of saying it is that their resources, infrastructure, and practices have been designed to be sufficient only for the majority of elections that have less than 50% turnout and few if any state or federal contests that are close. When those "normal parameters" are exceeded, the whole machinery of elections starts grinding down to a snail's pace. The result: an election that is, or appears to be, not what we expect in terms of being visibily fair, accessible, accurate, and therefore trustworthy.
In other words, we just haven't given our thousands of localities of election officials what they really need to collectively conduct a larger-than-usual, hotly contested election, with the excellence that they are required to deliver, but are not able to. Election excellence is, as much as any of several other important factors, a matter of resources and infrastructure. If we could somehow fill this gap in infrastructure, and provide sufficient funding and staff to use it, then there would be enormous public benefits: elections that are high-integrity and demonstrably trustworthy, despite being large-scale and close.
That's my opinion anyway, but let me try to back it up with some specific and recent observations about specific parts of the infrastructure gap, and then how each might be bridged.
- One type of infrastructure is voter record systems. This year in Ohio, the state voter record system poorly served many LEOs who searched for but didn't find many many registered absentee voters to whom they should have mailed absentee ballots. The result was a quarter million voters forced into provisional voting -- where unlike casting a ballot in a polling place, there is no guarantee that the ballot will be counted -- and many long days of effort for LEOs to sort through them all. If the early, absentee, and election night presidential voting in Ohio had been closer, we would still be waiting to hear from Ohio.
- Another type of infrastucture is pollbooks -- both paper, and electronic -- and the systems that prepare them for an election. As usual in any big election, we have lots of media anecdotes about people who had been on these voter rolls, but weren't on election day (that includes me by the way). Every one of these instances slows down the line, causes provisional voting (which also takes extra time compared to regular voting), and contributes to long lines.
- Then there are the voting machines. For the set of places where voting depends on electronic voting machines, there are always some places where the machines don't start, take too long get started, break, or don't work right. By now you've probably seen the viral youtube video of the touch screen that just wouldn't record the right vote. That's just emblematic of the larger situation of unreliable, aging voting systems, used by LEOs who are stuck with what they've got, and no funding to try to get anything better. The result: late poll opening, insufficient machines, long lines.
- And for some types of voting machines -- those that are completely paperless -- there is simply no way to do a recount, if one is required.
- In other places, paper ballots and optical scanners are the norm, but they have problems too. This year in Florida, some ballots were huge! six pages in many cases. The older scanning machines physically couldn't handle the increased volume. That's bad but not terrible; at least people can vote. However, there are still integrity requirements -- for example, the voters needs to put their unscanned ballots in an emergency ballot box, rather than entrust a marked ballot to a poll worker. But those crazy huge ballots, combined with the frequent scanner malfunction, created overstuffed full emergency ballot boxes, and poll workers trying to improvise a way store them. Result: more delays in the time each voter required, and a real threat to the secret ballot and to every ballot being counted.
Really, I could go on for more and more of the infrastructure elements that in this election had many examples of dysfunction. But I expect that you've seen plenty already. But why, you ask, why is the infrastructure so inadequate to the task of a big, complicated, close election conducted with accessibility, accuracy, security, transparency, and earning public trust? Isn't there something better?
The sad answer, for the most part, is not at present. Thought leaders among local election officials -- in Los Angeles and Austin just to name a couple -- are on record that current voting system offerings just don't meet their needs. And the vendors of these systems don't have the ability to innovate and meet those needs. The vendors are struggling to keep up a decent business, and don't see the type of large market with ample budgets that would be a business justification for new systems and the burdensome regulatory process to get them to market.
In other cases, most notably with voter records systems, there simply aren't products anymore, and many localities and states are stuck with expensive-to-maintain legacy systems that were built years ago by big system integrators, that have no flexibility to adapt to changes in election administration, law, or regulation, and that are too expensive to replace.
So much complaining! Can't we do anything about it? Yes. Every one of those and other parts of election infrastructure breakdowns or gaps can be improved, and could, if taken together, provide immense public benefit if state and local election officials could use those improvements. But where can they come from? Especially if the current market hasn't provided, despite a decade of efforts and much federal funding? Longtime readers know the answer: by election technology development that is outside of the current market, breaks the mold, and leverages recent changes in information technology, and the business of information technology. Our blog in the coming weeks will have several examples of what we've done to help, and what we're planning next.
But for today, let me be brief with one example, and details on it later. We've worked with state of Virginia to build one part of new infrastructure for voter registration, and voter record lookup, and reporting, that meets existing needs and offers needed additions that the older systems don't have. The VA state board of elections (SBE) doesn't pay any licensing fees to use this technology -- that's part of what open source is about. The don't have to acquire the software and deploy it in their datacenter, and pay additional (and expensive) fees to their legacy datacenter operator, a government systems integrator. They don't have to go back to the vendor of the old system to pay for expensive but small and important upgrades in functionality to meet new election laws or regulations.
Instead, the SBE contracts with a cloud services provider, who can -- for a fraction of the costs in a legacy in-house government datacenter operated by a GSI -- obtain the open-source software, integrate it with the hosting provider's standard hosting systems, test, deploy, operate, and monitor the system. And the SBE can also contract with anyone they choose, to create new extensions to the system, with competition for who can provide the best service to create them. The public benefits because people anywhere and anytime can check if they are registered to vote, or should get an absentee ballot, and not wait like in Ohio until election day to find out that they are one in a quarter million people with a problem.
And then the finale, of course, is that other states can also adopt this new voter records public portal, by doing a similar engagement with that same cloud hosting provider, or any other provider of their choice that supports similar cloud technology. Virginia's investment in this new election technology is fine for Virginia, but can also be leveraged by other states and localities.
After many months of work on this and other new election technologies put into practical use, we have many more stories to tell, and more detail to provide. But I think that if you follow along and see the steps so far, you may just see a path towards these election infrastructure gaps getting bridged, and flexibly enough to stay bridged. It's not a short path, but the benefits could be great: elections where LEOs have the infrastructure to work with excellence in demanding situations, and can tangibly show the public that they can trust the election as having been accessible to all who are eligible to vote, performed with integrity, and yielding an accurate result.
I came across an interesting article about voter registration: "The Alternative to Universal Voter Registration" where John N. Hall strongly supports Automatic Registration (AR) over Universal Voter Registration (UVR). To people who are not election experts the distinction is a bit subtle. UVR has states proactively try to register everyone to vote, while AR has the federal government somehow use Social Security records to automatically register people.
In Mr Hall's words, AR can be implemented by doing the following:
"Computer programs read through the Social Security Administration database, extract the data of age-eligible citizens, then send that data to the states." (from The Alternative To Universal Voter Registration)
Now that I started writing this post and did some more googling I see that this is already a heavily debated topic that has flown back and forth, starting with John Fund's (of the Wall Street Journal) original talk, to Rep. Barney Frank's angry denunciation that he had nothing to do with the claims that he was involved in any way with Universal Voter Registration, to Mr Fund's retraction of the claim, to more links than you can shake as stick at about the topic.
Anyway as usual I am johnny come lately. Phew. My original thought though was about the original post. You see, John Hall, being a "computer programmer" makes it sounds simple:
"Voila! Why make mandates on all those state agencies and dragoon all that manpower entailed by UVR when a computer program can register everyone? A competent programmer could write the extract program in his sleep." (from The Alternative to Universal Voter Registration)
Any description of this that starts with "Voila" and ends with "in his sleep" is ... well let's just say, it must be a bit of a simplification....
For example I would imagine that there would be major privacy concerns about sending information out of the social security systems out to each of the states. I am not sure that the states registration records even include social security information. And what about all the voters who don't have social security numbers, there must be some, or many? And how quickly are the social security databases updated when people die?
Thanks again to David Jefferson for his post yesterday on the lessons for Internet voting of the Google/China news (NYT: In Rebuke of China, Focus Falls on Cybersecurity). To answer some follow-up questions, I'll explain a bit about the term vote servers that David referred to. Let's start with a little background on Internet voting. Many peoples' cybersecurity concerns about i-voting have a focus on the vulnerability of the voter's Internet-connected computer, on which a Web browser is used for i-voting. The browser communicates with an i-voting Web server (or vote server), displays ballot items, allows the user to make vote selections, and so on (very similar to what many people do with surveymonkey and similar services on the Internet today). The security concerns are valid, whether the client computer is a home PC or a special-purpose kiosk system in a physically controlled polling place set up in a military base overseas.
But just as important is the "server side" of i-voting - the Internet-connected vote server, the Web server front-end, the database it uses, and all the other datacenter infrastructure. That infrastructure is one basket with all the eggs - the data that is used to create an election result. So of course there is concern over that basket being a target itself. After, why trouble with renting botnet time, crafting malware to distribute to already-hacked PCs, and the other work required to tamper with some of the i-ballots at the source? Why bother, if you can tamper with all of the ballots' votes at the single destination? Good question, and the typical answer is that attacking the source is much easier, if you assume that an i-voting datacenter uses "industry best practices" for security, as is the common claim of i-voting vendors and service providers.
But as the continuing Google/China news shows us, dedicated, politically motivated adversaries have been quite able to penetrate the defenses of the I.T. plant of some of the biggest most tech-savvy companies with some of the best I.T. and security staff in the world. That being the case, why should anyone blithely accept any claim that a i-voting datacenter is sufficiently defended to protect the vote data and the election itself?
Now, nobody is suggesting that the Chinese government would try to hack Internet elections for real U.S. government offices. But now look at it from the point of view of a responsible election official, pondering the offers of for-profit vendors of proprietary i-voting solutions, who have indeed run a few election pilots and would like to have the business of running full elections out of their data-centers using their i-voting systems. The vendors claim that they have spent "enough" time, money, and effort on security. The question is whether ...
... some small company that has run a few election pilots has any chance of locking down its vote servers so tightly that it can withstand a similarly determined "highly sophisticated and targeted attack" when Google and these other big company's cannot?
That's not a rhetorical question! The vendors are probably not the right judges about "enough" but there are several U.S. election officials who are currently mulling i-voting for overseas and military voters; they are the ones who need to weigh the risks and benefits, the required security and controls -- hopefully with the advice from some of several the election technology and security experts at work on election tech or policy today.
[My thanks to to election and tech expert David Jefferson for contributing this excellent, pithy, and though-provoking reflection on the day's top tech/policy news story. -- EJS]
Google recently announced in an important change of policy that it will stop censoring search results for queries coming from China. That is interesting in its own right, but is not why I am writing this article.
According to their corporate blog post, what prompted this change of policy was the discovery of "a highly sophisticated and targeted attack on [Google's] corporate infrastructure originating from China". They found similar attacks on "at least twenty other large companies from a wide range of businesses".
Google further said that they "have evidence to suggest that a primary goal of the attackers was accessing the Gmail accounts of Chinese human rights activists". We are not likely to hear more detail in public about the attacks, but this is extraordinary news.
As you can imagine, Google has one of the strongest IT staffs, with among the broadest and deepest security expertise of any company in the world, and presumably the other twenty plus large companies are generally well protected as well. Yet they were all apparently compromised remotely, by agents of a foreign power, and for political purposes!
Is there anyone out there who still believes that some small company that has run a few election pilots and now wants to run infrastructure for Internet voting has any chance of locking down its vote servers so tightly that it can withstand a similar "highly sophisticated and targeted attack" against a U.S. election when Google and these other big companies cannot?
-- David Jefferson
I came across this article, "NIST-certified USB Flash drives with hardware encryption cracked.". The money quote:
"The real question, however, remains unanswered – how could USB Flash drives that exhibit such a serious security hole be given one of the highest certificates for crypto devices? Even more importantly, perhaps – what is the value of a certification that fails to detect such holes?" (from "NIST-certified USB Flash drives with hardware encryption cracked.".)
I was quite intrigued by this article given that we talk blithely about using encrypted, write-once media to transfer information between various components of a voting system. I hadn't followed up with folks who know more about this than me, but I have a hard time understanding exactly encrypted, write-once media are or how they work or don't work.
You should draw your own conclusions about the significance of the linked article. I am actually not sure who "H-Security" is and what their particular angle or grindable axe might be. Also, Whether the security hole they report is big news or old hat among the cognoscenti. Stay tuned.
The Federal Communications Commission (FCC) asked for public comment on the use of the Internet for election-related activities (among other digital democracy related matters). They recently published the responses, including those from OSDV. I'll let Greg highlight the particularly public-policy-related questions and answers, but I wanted to highlight some aspects of our response that differ from some others.
- Like many respondents, we commented on that slippery phrase "Internet voting", but focused on a few of the specific issues that apply particularly in the context of overseas and military voters.
- Also in that context, we addressed some uses of the Internet that could be very beneficial, but are not voting per se.
- We contrasted other countries' experiences with elections and the Internet with the rather different conditions here in the U.S.
For more information, of course, I suggest reading our response. In addition, for those particularly interested in Internet voting and security, you can get additional perspectives from the responses of TrustTheVote advisors Candice Hoke and David Jefferson, which are very nicely summarized on the Verified Voting blog.
The reports of computer viruses in NY voting machines -- though spurious -- cause me to return to a basic mantra of TrustTheVote: we do technology development so that election tech helps inspire public confidence in elections, rather than erode it. The NY case is a great example of erosion, but also a cautionary tale for future inspiration. The caution comes from the significant and ongoing confusion about the term "virus". But first, the situation in question arose in Hamilton County, NY, part of the hotly contested NY 23rd Congressional District race between Hoffman and Owens. It's an ugly scene, because the vote was close, it's already certified, Owen is seated, but re-canvassing efforts highlighted some counting irregularities. These weren't large enough to effect the race, but were enough to spark Hoffman to un-concede defeat, and to issue a letter with some really disturbing claims of the election having been stolen. Now, add to this the claim that the election result is further tainted by the discovery of a computer virus in the voting system used in Hamilton. That's a real example of tech digging the confidence hole that much deeper - ouch!
But the really sad part of this, for me, is that the true story is a good story about election officials doing the right thing: when they found a software bug, they worked with the vendor and created an effective work-around -- maintaining the integrity of the system, the exact opposite of the story about the virus undermining the system. The real virus is that spurious story! The details, provided by NY State election official Doug Kellner, also provide another example of complexity of diligent election administration:
In pre-election testing several counties discovered the Dominion ImageCast machines froze when fed ballots that contained contests with multiple candidates to be elected. It was determined during the week before the election that the cause was a source code programming error in the dynamic memory allocation of the function that stores ballot images--not the counting function. Although only one line of source code needed modification, NYSBOE staff properly refused to approve any modification of source code without proper certification. Dominion developed a work-around by changing the ballot configuration file--not the source code so that the machines using the new configuration files functioned on election day. It is my understanding that a few county officials, who were using the machines for the first time, did not properly revise the configuration files and the machines were used in emergency ballot mode--that is, ballots were inserted in the emergency ballot boxes contained within the machine and were counted manually after the close of the polls.
Kudos to NY for doing their job right, in the real world of flawed equipment, not the fantasy land of viruses and stolen elections. New Yorkers should be thanking the NYSBOE for a job well done!
PS: For a detailed debunking of the virus claims, see the blog of NY election tech expert and advocate Bo Lipari. It's excellent. It got picked up in local press. But it can't catch up to the idea virus, as the tale continues to mutate through the blogosphere that Hoffman was cheated by corrupt election officials, or ACORN, or computer hackers, or viruses, or some combination. ;-(
We now have a federally certified voting system product that has completed the required testing by a federally certified independent test lab. That's a milestone in itself, as is the public disclosure of some of the results of testing process. Thanks to that disclosure, though, we now know that the test lab did practically zero security testing of the Premier product, because of a gross mis-understanding of prior security review. For a complete, accurate, and brief explanation of the whole situation, I urge you to read this letter to the EAC. The letter is from a group of absolutely top-notch voting technology and/or computer security experts, who were involved in California's Top to Bottom Review (TTBR) of voting systems, which included the Premier system that was recently certified.
At the risk of over-simplifying, the story goes like this.
- The TTBR found loads of technical security problems and concluded that
- the security problems were so severe that its technological security mechanisms were unable to protect the system; and
- the problems could be addressed only with strict procedural security - chain of custody, tamper-evident seals, and the like.
- Next, the test lab mis-interpreted these conclusions, assuming that the system's vulnerabilities depended only on effective procedural controls; therefore, no need to test technical security mechanisms!
- The test plan included no additional security tests, and hence the Premier system passed testing despite the many security flaws found in the TTBR.
That's the gist, but do read the letter to the EAC. It's a fine piece of writing in which Joe Hall and Aaron Burstein set out everything fair and square, chapter and verse. I have to say it's astonishing.
Now, maybe this seems exceptionally geeky, with cavils over test plans and test lab results, and so on. Or maybe it seems critical of the EAC/NIST testing program. But in fact that test program is incredibly important as a gate through which computing technology must pass before being used to count votes. In a very real sense, the current testing program is just getting started, so perhaps it's not surprising that there are many lessons to learn. And my thanks go to all these TTBR verterans for speaking out to remind us how much there is to learn on the road to excellence both of voting systems and of the program to test them.
Scanning the news last week, I found rumors of Premier Systems (the voting system vendor formerly known ad Diebold) going open-source, and of the Federal government pondering cases where voting system test results should be confidential. An interesting juxtaposition! The first item I call a rumor not because I disbelieve the blogger in question, but because Premier hasn't announced anything. But the blog article does contain some interesting stuff, including a paraphrase of Premier's CEO opining that releasing source code to the public would be an approach that results in several beneficial outcomes.
At the other end of the spectrum we have some news from a recent meeting of the EAC's standards committee, including discussion of the new Voluntary Voting Systems Guidelines draft, intended for use in Federal certification testing of products like those from Premier. The draft would require that the result of the testing process should include documentation of all attacks the system is designed to resist or detect, as well as any vulnerabilities known to the manufacturer. Some committee members pondered whether the vendors should mark this information as confidential.
Some observers have questioned whether it would be appropriate to certify a system that has known security vulnerabilities. Others have pointed out that every system has vulnerabilities, and that the important issue is to be clear about the definition and boundaries of security, sometimes called a "threat model." Within those defined limits, customers should be very clear about what deployment and operational procedures that they need to adhere to, in order to maintain the integrity of system as defined by the vendor; beyond those limits, caveat emptor.
We might take up that debate another day. But for now, the obvious old adage applies: you can't have it both ways. If a system is truly open, then there are no secrets -- though you can try hushing up issues that can be readily discovered by directly inspecting the open system. However, I think that there is a case to be made that there really are no secrets, especially for systems that are important enough that people really do want to know "whether it really works." Next time, a couple specific examples from recently published voting machine security studies, that have put me in mind of another saying: "Open, Sesame!"
A good question re-surfaced for us as we participated in the National Civic Summit recently. The issue was and remains about identifying a "gold build," that is, when there is a particular system/version that is certified for use as a voting system, how should election officials know that the systems that they deployed are systems that are an instance of the certified system. Previously, we provided some answers of how you could answer the question "How do I know that this voting machine is a good one" and provide in the wiki on a more technical treatment of "field validation" of voting system devices. But the slightly different question that arose recently is: how does open source help?
The simple answer is that open source techniques do not directly help at all. We could build a completely open system that has exactly the same architectural blockades to field validation as the current vendors' product do. However, the TrustTheVote open source project has some advantages. First, we're working on voting systems, which have sufficiently simple functional requirements (compared to general purpose computing systems) that field validation of voting devices isn't as difficult as in the more general case. *
The second advantage allows us to sidestep many of these complexities, given the relative simplicity of voting devices. We were able to go back to the drawing board and use an architecture that simplifies the field validation problems, for the very specific and limited class of systems that are voting devices.
Openness itself didn't create these two advantages; but in conducting a public works project, we have the freedom to start fresh and avoid basic architecture pitfalls that can undermine trust. Therefore, the value of working openly is that the benefit of this work -- increased confidence and trust -- is a bit more easily achieved because field validation is fundamentally a systems trust issue, and we address in a way that can be freely assessed by anyone. And that's where the open source approach helps.
* NOTE: for the detail-oriented folks: in general, the twin problems of Trusted Software Distribution and Trusted System Validation are, in their general form, truly hard problems. Feasible approaches to them usually rely on complex use of cryptography, which simply shifts the burden to other hard problems in practical applied cryptography. For example, with "code signing" my Dad's computer can tell him that it thinks he should trust some new software because is it signed as being from his SW vendor (e.g., Microsoft or HP); but he wonders (rightly) why he should trust his computer's judgment in this matter, given the other mistakes that his computer makes. For more on the non-general voting-system-friendly solution, see the TrustTheVote wiki: https://wiki.trustthevote.org/index.php/Field_Validation_of_Voting_Systems
If you're looking for an entertaining and vigorous discussion of Internet voting, don't look here, but do look to William J. Kelleher, Ph.D's paper "Internet Voting: the Great Security Scare", or to the OpenGove web page that is the short form of his argument that "Internet Voting Is Coming" at IdeaScale:
Don’t be by the self-styled "experts on security." They are just playing on people's fear for their own self-promotion. They claim that their expertise in reading programming codes makes them Oracles on Internet voting security. In fact, they are engaging in very amateurish social science analysis of cyber crime. ... Mature social science thinking about the issues they raise shows that they are fear mongers, bereft of rationality. ... Internet voting has the power to make all public officials directly dependent upon the voters. The days of Superrich Domination in US elections are numbered. Internet voting in all US elections is as inevitable today as the rise of the automobile was 100 years ago.
My point for today is the risk that comes from fuzzy thinking of the sort that Kelleher's paper exemplifies. The rhetoric may be goofy, the thinking may be fuzzy -- but once it's published, it becomes referenced as a published authority. One reason why this can happen, especially with issues touching on Internet security, is that there are many specious arguments that sound sensible to non-technical folks. Eric Rescorla, in his Educated Guesswork blog, does a good job of giving a few examples of Kelleher's plausible mis-representation and specious argumentation. To encourage you to read Eric's blog, I'll provide my favorite bit:
"[Kelleher] ... depends on the ever-popular "argument from incredulity" ... incredulous that there could ever be widely deployed malware that infects a large number of computers. As it happens, however, not only is this possible, we already have several worked examples in the form of large botnets."
I bring this to your attention, not to take a position on Internet voting* but to point out how tricky the public discourse on the topic actually can be. It often gets tricky, because of the technical nature of Internet security, and the general lack of understanding of the relevant technologies. And in particular, to my fellow "experts on security", may I say: please don't just assume that everybody understands both Internet security technology and how U.S. elections actually work. If you do assume that, your otherwise credible remarks will very often be received as though you were "bereft of rationality."
* The term "Internet voting" means a lot of things, but in this case I mean: the use of ordinary home or office PCs to run ordinary software tools like web browsers or e-mailers, to compose ballot information and send it over a public data network.
Election audit was the second lessons-learned topic from the RSA panel that I wrote about earlier. I illustrate with two examples.