Western Australia is heading to the polls on March 11th. The geographically massive Australian state (it encompasses an area larger than Greenland) has opted to introduce online voting in its upcoming election for eligible voters with disabilities.
The system known as iVote was previously deployed in 2015 in New South Whales, and attracted some international notoriety after researchers discovered the client-side voting booth javascript was being delivered over an insecure TLS connection, opening the potential for vote stealing malware to be injected by hackers. Although no such attack is believed to have actually occurred NSW (the flaw was quickly fixed following the disclosure), it speaks to the concern among many security researchers that a major hack of an online election is not a matter of if, but when.
I recently joined up with Australian election security researchers Chris Culnane, Vanessa Teague, Yuval Yarom and Mark Eldridge to take a look at the WA iVote configuration. We disclosed our findings to the Western Australian Election Commission (WAEC), and following their response we shared our findings publicly in an article in the University of Melbourne’s online media outlet Pursuit.
What we Found
We examined public-facing aspects of WAEC’s iVote server and noticed connections being proxied through an Incapsula server based in the U.S., an apparent denial-of-service protection measure. So far no issue. This is a common practice.
One issue, however, can be observed when you visit the election website: the digital certificate you get isn’t owned by WAEC—it’s owned by Incapsula. What that means is there are two separate TLS connections: between the voter and Incapsula, and between Incapsula and the iVote server.
Why is this an issue?
It means internet communications between Western Australian voters and the WAEC are showing up in a decrypted state on a U.S.-based server.
The WAEC, however, was quick to dismiss this concern pointing to the fact that iVote effectively uses two layers of encryption: encryption at the Transport layer (i.e., TLS) and encryption at the Application layer (i.e., client-side encryption of the ballot with javascript).
Surely double encryption, like double rainbows, is better, right? But what is it really doing, and is it secure?
WA iVote Login and Ballot Casting
Let’s take a look at what happens when a voter logs into the iVote system. During a separate registration step each voter is issued an 8-digit ID by the iVote system and chooses their own 6-digit PIN.
At the backend the iVote system generates a symmetric (AES-256) ballot encryption key and digital signature keypair for each voter. These keys are locked inside of a PKCS5 encrypted container using yet another key derived from the voter’s ID and PIN, and the container is stored in a web-facing voter credential database.
The following diagram depicts the login and ballot casting process:
- LOGIN. The voter enters their ID and PIN. Client-side Javascript hashes these values (using PBKDF with SHA-256 and iterations) and sends the hash to the WAEC iVote server.
- RETREIVE CREDENTIALS. The iVote server searches the voter credential database and returns the associate encrypted container to the voter
- RECOVER KEYS. Client-side Javascript uses the ID and PIN to decrypt the container to recover the voter’s ballot encryption key and signature keypair
- CAST BALLOT. The voter makes their selections and clicks cast. The client-side Javascript encrypts and signs the ballot and returns it to the iVote server to be included in the electronic ballot box
So Can Two Layers of Encryption Really Be Less Secure than One?
First of all: yes. Check out e.g. 2ROT13. But what’s going on in iVote? Observe from the diagram above that the PKCS5 container and the encrypted/signed ballot container appear on the cloud provider’s server without any (strong) encryption at the transport layer. So no outer layer of encryption. But what about the inner layer? How strong is it?
First of all it is a custom javascript implementation run on the voter’s computer, which, as we’ve blogged about before can lead to issues. Cracking the inner-layer of encryption involves computing PBKDF2 on an 8-digit ID and 6-digit PIN across 8000 iterations to derive an AES key which, if the PIN and ID were correct, will decrypt the PKCS5 container. This can be accomplished with a brute-force attack of:
or approximately SHA-256 operations to recover the voter’s ballot encryption and signing keys. So the inner layer is providing no more than 60 bits of security, whereas 112 bits is the current recommended minimum. That’s an enormous security gap, and on paper it’s just not secure.
But how realistic is brute forcing in practice? Within the realm of feasibility. At the time of writing the Bitcoin network collectively was performing approximately SHA1 hashes per second, and last week Google reported performing operations toward a SHA1 collision.
Realistically, however, a man-in-the-middle would likely have a much smaller search space than for two reasons:
- Most IDs are unused: it is estimated there are at most a few thousand voters, and the IDs in use show up in other interactions (such as registration).
- PINs are user-chosen and therefore are unlikely to be uniformly distributed.
So Two Layers Is Really Just One Weak Layer?
From the iVote cloud provider’s point of view, yes. To summarize the two layers of encryption used in iVote:
- Inner layer: Encryption at the application layer with a de facto key of no more (and likely less) than 60-bits.
- Outer layer: Encryption at the transport layer with TLS under a 256-bit ciphersuite… that gets stripped off as it passes through the U.S.
To most attackers the hard outer TLS layer is enough to preclude any man-in-the-middle attack. But the inner layer is both cryptographically weak, and directly observable to the cloud provider making it vulnerable to insider attack by non Australian entities.
Still, as WAEC rightly points out the “US server company was a highly reputable supplier of security services.” Let’s be clear: this is not in dispute. But let’s just also be clear about this double encryption business and what it means to security.
Bottom Line
Saying there are two layers of encryption is technically correct…. except the outer layer gets stripped off as it passes through a server in the United States, and, best case scenario, the inner layer is more than a billion billion billion billion billion billion times weaker.
UPDATE (March 8th). WAEC has assured us Incapsula has a PoP in Australia despite the IP nominally having a U.S. geolocation, and that with the exception of “security event data,” voter traffic is not being routed through the U.S. But it has also raised a number of new questions, doesn’t ultimately change the brute-forceablity of the inner encryption layer.
Read more about this work in The Register.