Conversation

I know this fries the brains of my security colleagues involved in election security, but how can you see how much voter disenfranchisement exists and *not* think that the greatest democratic benefit would be from making voting easier? I believe secure mobile voting is possible.

130

Replying to

Wow, a controversial security topic we agree on 😂 I fight enough battles in security that I don't need another one, but I also believe this.

Replying to

and

OK, help -- why do you think mobile voting is securable? Do you believe this in a theoretical future world where platform security is better, or in the current world (and if so, how?)? Because, honestly, it doesn't look very securable to me in this world.

Replying to

and

I don't think securable is a fair bar, it should be the current level of security. I think people say "sure, everything is bad, but this will be bad... at scale", and I don't find that convincing enough to ignore the benefits. 🤷🏻‍♂️

Replying to

and

Hmm. Why? AIUI there's enough diversity in setup that it's not super-easy to hit things remotely at scale. Mobile voting, especially given how many people are on old, insecure versions of Android, seems way easier.

Replying to

and

Straightforward question: what's the minimum version of Android that will generate remotely-verifiable attestations to the OS integrity, the voting app's integrity, and the absence of apps trying to draw above the voting app? I think what you'd want is a "SafetyNet attestation".

Replying to

SafetyNet attestation is not meaningfully verified. It's a much different thing than hardware-based attestation. Devices launched with Android 8 or later have the necessary hardware support for hardware-based attestation. SafetyNet doesn't build on it but rather is pure theatre.

Replying to

If you verify solely based on the attestation root of trust, that would mean compromising the hardware keystore on a single device is a full compromise of the entire attestation system. It's not a solution to this problem since you need do pairing for it to provide good security.

Replying to

Even if you had a way to securely bootstrap, vast majority of devices don't have a secure element providing a StrongBox keystore but rather only a TrustZone-based keystore. TrustZone security is not great. Also, checking patch level in the attestation will rule out most devices.

Replying to

See attestation.app/about if you're interested in it. I built github.com/GrapheneOS/Aud and github.com/GrapheneOS/Att to provide a way for users to use hardware-based attestation with Trust-On-First-Use pairing. It does bootstrap with the root, but that's an incredibly weak check.

github.com

GitHub - GrapheneOS/AttestationServer: attestation.app remote attestation server. Server code for...

attestation.app remote attestation server. Server code for use with the Auditor app: https://github.com/GrapheneOS/Auditor. It provides two services: submission of attestation data samples and a re...

9:26 PM · Mar 4, 2020Twitter Web App

Replying to

Verification based on the attestation root is essentially only useful for implementing anti-cheat / DRM. It can be fooled by anyone able to compromise a single TEE / SE on any device, including one without updated firmware. Bunch of companies also have access to valid batch keys.

Replying to

I don't see another way of doing it for use cases like this with the current implementation. It would certainly be better than not using any hardware-based attestation at all, but unless the devices are going to have pairing done before being distributed to users it's very weak.

Show replies