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.
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.
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:
- RETREIVE CREDENTIALS. The iVote server searches the voter credential database and returns the associate encrypted container to the voter
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?
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.
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.