Good afternoon, everybody. My name is Nimit. I'm one of the co-founders at Votes.
And I'm here to talk about some of the security data we've collected during the course of our
mobile voting pilots over the last couple of years. So before we dive into the data,
just a quick overview about Votes. As many of you may know, Votes is the youngest elections company
in the US. We got started almost by accident after winning a hackathon at South by Southwest
in Austin, Texas, way back in 2014. The theme of the hackathon was Hack to the Future.
What's the one thing you would do in the future and how you do it? And so my brother and I,
he was there and we ended up prototyping this new election system, which used smartphones,
biometrics, real-time identity verification, and then also locked the ballots on a blockchain-based
infrastructure. To our surprise, we ended up winning the first prize and that led to a whole
series of events and eventually the company started in 2015. So since then, we've done 67
elections so far and 11 of these have been public government election pilots. We've also done
non-governmental elections, primarily with the state political parties in various states.
And so some of the data we're going to share today covers a wide array of our elections
from a security perspective. And then we'll also dive in into a couple of really interesting
elections we did recently, where for the first time we were able to collect a lot of interesting
data. So I'll begin with a quick introduction about our system. It's a smartphone app-based
mobile voting platform and the key components here are essentially the voters' smartphone devices,
an iPhone or a compatible Android. Then you have the cloud infrastructure
where the backend servers are running and also distributed blockchain infrastructure.
And then you have the election administration-specific interfaces to the election
jurisdiction. And then from there, their traditional infrastructure is ballot printers
and tabulation equipment. And the way the entire process works is essentially, right now,
the system is being piloted only for absentee voters. And within absentee voters, a very small
subset of people, essentially military voters who are deployed, their families and any U.S.
overseas, they're commonly referred to as Yokawa voters. And so if you're in that eligible group
and your jurisdiction is participating in a pilot, then you sign up normally as an absentee voter
and then submit a form to your election clerk, typically your county clerk, and then they do
a little bit of vetting. And then if you're eligible, they will pre-provision you on the
system. And then you get an invitation to download the application on your smartphone, iPhone or
compatible Android device. So you begin with the email number and email ID and a mobile number.
And then once you've done the initial onboarding, you are asked to do an identity check. So you'll
have to take a picture of a government-issued photo ID. Right now, you can use a driver's
license, state ID or passport. You can use some other forms of ID as well if you don't have
those three, but those are the most commonly used ones. And then once you've done the scan
in the application front and back, then you're asked to take a live video selfie.
Then once you've completed that, it does a matching to make sure the picture you took of yourself
matches the picture on the ID. Liveness check is done as well to weed out any fakes or
any other kind of fraudulent activity. And once everything matches, the data on your ID is compared
to the voter registration file which is provided to us by the jurisdiction for the pilot. All that
matches, your identity is digitized, stored in the secure space on the handset, and all the
documents you've provided are deleted at that point because we don't need them. We don't want
to increase the threat surface after that as well. So at this point, you're ready to receive your
ballot. So as you can see from the flow diagram, that's essentially a 10-step process. And once
you've received the ballot, it's essentially your mobile representation of your actual paper ballot
which you would receive if you went to work in person at your precinct, or if you opted into
vote by mail, essentially the same ballot you'd get here. And so you map the ballot on the phone,
and then you may be asked to sign an affidavit. Sign with the finger on the screen, and then
once you're ready to submit, you confirm your choices, do your biometric verification on the
device again, and at that point your ballot gets submitted to the network, anonymized, and you get
a receipt so you can verify your selections, and then also participate in the audit process as well.
And in the background, the jurisdiction gets an anonymized and anonymized copy of your receipt,
and then close to election day, a paper ballot is printed. And then there's a pre-tabulation audit
on election day. Printed paper ballots are tabulated just like other paper ballots,
and there's no hand reproduction required. And then once the election's over, during the canvas
phase, there's a full audit where receipts are prepared. So end-to-end, that's how the process
works. Now that we've looked at kind of how the system functions, let's look at the threat model.
So as you can see, it's a pretty interesting threat model here, obviously, because it's an
internet-connected device. It is different from traditional methods of voting. So let's kind of
run through the flow, and at each step we can look at some of the threats. This is the first
phase, as you saw, you opted in, the county clerk approves you, and then you've started to download
the app. So obviously, if you're not careful, you could download an incorrect app by mistake, or
the app may already be compromised ahead of time by a bad actor, or there may be malware on your
device which, you know, prevents normal functioning of the application. So it's kind of the first
stage. Next, look at, now you're at the voting stage, so the threats here are maybe the biometric
capability on your phone isn't working as it's supposed to. And obviously, at this stage,
if there's malware, your apps can be reverse engineered, and there can be attempts made to
change how you're voting. So that's the threat vector, and we'll see how there are ways to mitigate
that a little bit later. Then obviously, in the transmission phase, the transmission is not secure,
the transmission channel, that data may never reach the destination or may corrupt it on the
way. So we look at ways as to how that can potentially be mitigated as well. And then
the voter gets a receipt. So the receipt, there's a chance somebody else may get hold of your receipt
if you're not careful. Obviously, that's an active area of research on how to create
self-destructing receipts, but it's a potential threat vector. And so finally, once the ballots
reach the jurisdiction, as they are printing the paper ballot for tabulation,
and they do a pre-tabulation audit, so there is a potential threat vector which would likely get
caught by the pre-tabulation audit. Nevertheless, important to keep in mind.
Thank LA Times for making this nice picture available to us. Very nicely done. Makes it
simple to understand. And so now that we've looked at the high-level threat model,
let's look at what kind of threats we've seen in the wild over the last couple of years.
So we like to group them into a few different categories. So there's obviously threats at the
device level. There's threats at the network level. And so those are kind of user-centric
scenarios. And then overall is the cloud infrastructure, our corporate network. So
obviously those are areas of interest as well. So in terms of what we've seen, passive scanning,
obviously, which happens to pretty much everybody these days who has a public-facing web asset.
We've also seen active analysis of our web assets. So people actually trying to
reverse engineer some of that stuff. And phishing of our staff, clients.
Email spoofing attempts as well. Social engineering, obviously we're well aware of
what happened recently. We've had attempts, phone calls, people pretending to be who they're not.
We've seen DNS tampering attempts as well. SIM swap, SIM takeover attempts. And then
reverse engineering of the mobile applications, sometimes partial. And then through the analysis,
mobile API level attacks. So people actually trying to figure out how the API is working
and trying to attack it. We've also seen on the Android side attempts to compromise the TEE,
some of the TEEs are stored. And then malware, we do come across malware on several devices. And
we'll see later on in one of our lectures, an interesting case that came to light.
So before we dive into some of the data, it's going to be useful to look at the MITRE attack
framework. So recently, MITRE updated the mapping for not just the enterprise side,
which covers the cloud aspects in our case, but also the mobile side. So we mapped that data to
what we've seen, as you can see on iOS, some interesting things to note and the device level.
And then similarly, network-based vectors. So we already spoke about the SIM swap. And then
you'll see some of the other ones in the data head, such as rogue Wi-Fi and things like that.
Similarly, on the Android side, similar to iOS, a couple of different things,
but we find the mapping useful, just as we plan out our work. And I'm sure a lot of you are
looking at this as well. Similarly, on the network side for Android,
let's look at a few case studies here. 2018 was when we had first opportunity to do public
elections in the US. And so since then, we've had some interesting opportunities to collect data.
So we'll start with something from 2018. One of the really interesting things we saw early on
back then was the attempts to use multiple devices with the same adversary and using
different mobile numbers and emails and trying to do the same thing. So in that scenario,
the mitigation deployed by the system was to treat this as a malicious activity and block
office access. We did see people use phone numbers in some telco blacklist,
as well as people using well-known tools like WebSuite to probe the platform, probe the API
endpoints. And in one of these cases, we were able to record the traffic through a honeypot.
So some of that is available as part of the open data package and is also available. We'll share
some public links at the end of the presentation, so you can get it from there as well.
The other interesting thing from a case study perspective was people trying to reverse
engineer the application. The system has an initial handshake process and we saw some attempts,
manual attempts to engineer that handshake process. And so in that scenario as well,
one of the mitigations was to block the IP address ranges or block the device IDs,
depending on the nature of the attack. But that's an area where we have some feedback on
better approaches to mitigate those kinds of attempts. Email spoofing, so we did see,
we continue to see a lot of email spoofing attempts and obviously with DMARC that helps
to mitigate that, but nevertheless we do keep track of it. Another interesting case study was
involved, essentially network-based attempts to scan the passively and then use that information
to actively look at infrastructure, particularly the API endpoints. So that's where we see a lot
of interest. And then more recently we've had an opportunity to do somewhat larger elections
in terms of participation. Some of the early pilots had a very small number of voters, so
the opportunity to collect meaningful data was a little limited from a security,
on-device security, network security perspective. But with one of the elections this year,
some very interesting data to analyze, and so I'd love to share that. One focuses around,
we call it the mobile threat detection. We partner with third parties for that capability as well as
some stuff we have. And the way that's structured is, we call it a multi-channel
component architecture. The device is communicating with obviously our back-end,
it's also communicating with the third-party system. Similarly, our back-end is communicating
with the third-party system. A good example was, somebody tries to reverse-engineer the app
and hooks the specific locations where some of that code is getting triggered to try and bypass
it. You could potentially disrupt two of these channels, but it'd be hard to disrupt the third
channel. So that, in this case, acts as a saving grace and also as a extra detection mechanism.
And so some of this capability is actively deployed. Next, probably the most interesting
part of the presentation. So this is data from one of our recent elections, where a few thousand
people participated. And this was kind of the device split, predominantly more iOS than Android.
And then in terms of the threats we detected, on the network side, it was pretty even, 50-50.
But on the device side, we saw sort of a lopsided share of threats being detected on Android.
That could be a function of the devices that were being used,
or maybe the unique factors to this election as well. But something interesting to keep in mind.
Sort of diving one level deeper. So on the iOS side, let's kind of look at some of the network
security threats. And this data, by the way, is available in the open data set.
I believe it's the part one. So you can kind of dive in at your convenience as well.
But at the iOS level, we saw 18 devices who were connected. So this was amongst the few thousand
and the 64% who were using iOS. There were 18 devices detected which the Wi-Fi was deemed to be
unsafe. And so obviously that creates a potential for a man-in-the-middle type of attack. So the
experience was they were not able to complete the process on the device or ask to contact
the support team. In that case, they were requested to either switch to the cellular network
or switch to a different Wi-Fi network. In this case, once they did that, they were able to proceed.
Similarly, on Android, similar number, about 17. On Android, we also saw an interesting case
for potential ARP poisoning. ARP is address resolution protocols, I'm sure many of you know.
In this case, it was a little hard for a support team to detect because we didn't have visibility
into what the voter's home network looked like. And so it required a little bit of troubleshooting,
but eventually turned out to be a media device which was causing this poisoning. And so the team
requested the voter to turn off the media device. And then the threat went away and they were able
to proceed. So an area we'd love to do a little more research, but it was interesting that we
came across this one case. Next, let's look at some device level threats. On the iOS side, we did
detect a few devices where the pin was not set. In that case, mitigation and resolution was to force
the users to send in or activate the biometrics on the device. Otherwise, they couldn't really proceed.
And we saw a few cases of side-loaded apps. And in each of those cases, when a little bit of
due diligence was done, they were deemed to be legitimate apps. And so the voters were able to
proceed. It was good to see them being detected in case they could pose a threat.
So definitely something we'd like to research more on. On the Android side, a much larger number
of devices without pins, which we weren't sure why, but was interesting. 89 devices didn't have
pins set, so all those voters were forced to set a pin or activate the biometric capability on the
devices. Similarly, on the side-loaded side of things, a lot more side-loaded apps, which kind
of made sense given the ecosystem on Android. So it did take quite a bit of time to go through these,
make sure everything was okay. Luckily, the election went for three days, so our support team
had enough time to troubleshoot. In this investigation, we did find two instances where
the device did have malware. And it was a fairly well-known malware. I'm sure many of you probably
heard about it. But it was interesting that we were able to detect this, inform the voter,
they were able to delete the offending apps, reset the devices, and then proceed. And then
once the new checks were confirmed, they were actually able to vote successfully and complete
the audit as well. A couple of other interesting Android-specific things, we did detect some
instances of USB debugging being enabled. Nothing malicious on that front, but during
the active voting, the phone was not connected to a computer. So that was fine. And then we did
have another 21 devices where developer options were enabled. So once again, no direct impact,
but something we'd like to keep track of. And as I mentioned earlier, this data is available as part
of the package we've released. We'd love more feedback and suggestions on how to collect,
how to analyze this in a better way, especially areas around malware and
other really interesting things we were able to learn from here.
And you'll notice that the data is, for the most part, anonymized. And that's true of the
collection process as well. The voter is the one who's asked to initiate and not knowing what
exactly has happened. So the data does not contain any personally identifying information, to the
best of our knowledge. And lastly, love any suggestions and feedback from the community.
We're a young company, the youngest company in this space, trying to do something which is
unusual, to say the least. And so we'd love suggestions and feedback to improve and what
things we could do better. And appreciate the participation of the community. Thank you for
the DEF CON voting village team for giving us this opportunity to share this data. And we'll be
sharing more of this data as we do more election pilots. And we'd love to continue to get feedback
from everybody. More information is available on our website, especially under white papers and
under the security section. So please feel free to explore and give us feedback and look at the
data as it's posted in the future as well. Once again, thank you and hope you all have a
great DEF CON experience this year, especially at the voting village. Thank you. Take care.