Rough Thoughts on Mobile/Digital Voting

In this guest post, Kunal Anand, CTO at Imperva, reviews some of the challenges facing online voting.

The COVID-19 pandemic is creating an interesting situation for the 2020 US Presidential Election: millions of people are wondering how they're going to vote if quarantines endure through the rest of the year. Voting by postal mail has emerged as the preferred solution proposal - it's an established paradigm with a familiar UX.

There has been a collective push by upstarts and non-profits to get digital and mobile voting efforts deployed at scale, but there have been strong advisories from government agencies against using digital and mobile voting in 2020. While it might be challenging to get a secure and robust digital voting system deployed at scale for 2020, we have to start somewhere and sometime if we want this ability in our lifetime.

If we start now, we could conceivably have beta tests running in cities, counties and states in 2024, with the prospect of deploying it nationally in 2028. We're going to need the tightest and best implementation of "PPT" - people, processes, and technology. With respect to the last two points, I believe we generally know the processes that must be implemented and we have almost all of the technology pieces to make this work.

Before I dive in, here are just some of the back-of-the-napkin risks that such a system would need to address and mitigate:

This might sound pretty daunting but it isn't too different than what regulated organizations in financial services and healthcare already do today. Take the list to a CISO at any bank and you’ll be told that those risks are well known.

While the threat model may be similar, we'll need to design and roll vote-by-mail out differently. For starters, 100% of the code needs to be open source. The mobile applications and server-side code should be open and shared for everyone to poke holes in. To the naysayers, here's a comp for you: cryptography. Cryptographic algorithms like hashing algorithms and symmetric key ciphers have benefited from public review and audit. The same thing applies for voting - we can't expect a single organization operating behind closed doors to get this right. The stakes are too high.

We also need a process to trust and verify votes. We could adopt a two-factor model leveraging an existing ID (SSN, driver's license, real ID or passport) with a generated voter ID that is physically mailed to each eligible citizen. To tamper this at scale, you would have to brute force those voter IDs in conjunction with the personally identifiable information.

The final product that voters will interact with (via the web or mobile device) will need to undergo a significant amount of usability testing. The apps will need to feel natural and help voters understand their actions. It will need to support dozens of languages and scale to voters with disabilities. We will need popular app stores to crack down and work with agencies to prevent unofficial apps and general tampering well in advance of the elections.

Sure, we're going to need to encrypt information in transit and at rest. But the bigger question here isn't about how we store the data - it's about who collects it and what actually is transmitted. We'll need the voter ID for an audit trail while limiting personal information (like an IP address). Will counties or states be responsible for storage? Will we need a federal managed system that states plug into? Will it be done by an independent organization?

In terms of scale, we'll need a robust system to collect votes. The good news here is that one can develop a service on an off-the-shelf laptop that can write hundreds of thousands of events per second. I don't think this concept of "scale" is the problem here. With good architecture and design, a stateless and redundant system can be deployed. Of course, we'll need significant stress testing to get this right.

Finally, we'll need to think about how we add security in every layer: the network, the app and the data store. From a process side, we'll have to build and implement controls to generate and review system audit logs, limit access and apply zero trust (network + data) concepts. Again, I don't think we need to reinvent the wheel - we need to be pragmatic and adapt what we've been doing in the private sector for the last few decades.

Do I think we could have this system ready to go by the end of the year? It's hard to imagine this being done right in time for November 2020 given all the moving parts. I believe that if we start now, we could progress to having a beta in 2024 with a national rollout in 2028.

This post isn’t to trivialize all of the work or to play down all of the risks. It's a thought exercise that's meant to encourage us as Americans that this is just another hard problem that we can solve. We have many of the building blocks and we should start putting them together sooner rather than later.