[00:00.970 --> 00:06.730] Good afternoon, everybody. My name is Nimit. I'm one of the co-founders at Votes. [00:07.050 --> 00:14.010] And I'm here to talk about some of the security data we've collected during the course of our [00:14.010 --> 00:20.010] mobile voting pilots over the last couple of years. So before we dive into the data, [00:20.010 --> 00:27.990] just a quick overview about Votes. As many of you may know, Votes is the youngest elections company [00:27.990 --> 00:36.910] in the US. We got started almost by accident after winning a hackathon at South by Southwest [00:36.910 --> 00:43.390] in Austin, Texas, way back in 2014. The theme of the hackathon was Hack to the Future. [00:43.410 --> 00:49.050] What's the one thing you would do in the future and how you do it? And so my brother and I, [00:49.050 --> 00:56.710] he was there and we ended up prototyping this new election system, which used smartphones, [00:56.710 --> 01:04.590] biometrics, real-time identity verification, and then also locked the ballots on a blockchain-based [01:04.590 --> 01:10.290] infrastructure. To our surprise, we ended up winning the first prize and that led to a whole [01:10.290 --> 01:19.130] series of events and eventually the company started in 2015. So since then, we've done 67 [01:19.130 --> 01:28.310] elections so far and 11 of these have been public government election pilots. We've also done [01:28.310 --> 01:34.490] non-governmental elections, primarily with the state political parties in various states. [01:34.490 --> 01:42.150] And so some of the data we're going to share today covers a wide array of our elections [01:42.150 --> 01:47.970] from a security perspective. And then we'll also dive in into a couple of really interesting [01:47.970 --> 01:54.110] elections we did recently, where for the first time we were able to collect a lot of interesting [01:54.110 --> 02:04.210] data. So I'll begin with a quick introduction about our system. It's a smartphone app-based [02:04.210 --> 02:12.410] mobile voting platform and the key components here are essentially the voters' smartphone devices, [02:12.410 --> 02:17.330] an iPhone or a compatible Android. Then you have the cloud infrastructure [02:18.330 --> 02:24.670] where the backend servers are running and also distributed blockchain infrastructure. [02:24.870 --> 02:31.450] And then you have the election administration-specific interfaces to the election [02:31.450 --> 02:37.610] jurisdiction. And then from there, their traditional infrastructure is ballot printers [02:37.610 --> 02:46.130] and tabulation equipment. And the way the entire process works is essentially, right now, [02:46.130 --> 02:52.950] the system is being piloted only for absentee voters. And within absentee voters, a very small [02:52.950 --> 02:59.930] subset of people, essentially military voters who are deployed, their families and any U.S. [03:00.790 --> 03:09.230] overseas, they're commonly referred to as Yokawa voters. And so if you're in that eligible group [03:09.230 --> 03:15.930] and your jurisdiction is participating in a pilot, then you sign up normally as an absentee voter [03:15.930 --> 03:22.990] and then submit a form to your election clerk, typically your county clerk, and then they do [03:23.130 --> 03:27.770] a little bit of vetting. And then if you're eligible, they will pre-provision you on the [03:27.770 --> 03:34.570] system. And then you get an invitation to download the application on your smartphone, iPhone or [03:34.570 --> 03:40.970] compatible Android device. So you begin with the email number and email ID and a mobile number. [03:40.990 --> 03:48.610] And then once you've done the initial onboarding, you are asked to do an identity check. So you'll [03:48.610 --> 03:54.610] have to take a picture of a government-issued photo ID. Right now, you can use a driver's [03:54.610 --> 04:01.730] license, state ID or passport. You can use some other forms of ID as well if you don't have [04:01.730 --> 04:07.390] those three, but those are the most commonly used ones. And then once you've done the scan [04:07.390 --> 04:13.310] in the application front and back, then you're asked to take a live video selfie. [04:13.870 --> 04:19.890] Then once you've completed that, it does a matching to make sure the picture you took of yourself [04:19.890 --> 04:28.390] matches the picture on the ID. Liveness check is done as well to weed out any fakes or [04:28.390 --> 04:35.730] any other kind of fraudulent activity. And once everything matches, the data on your ID is compared [04:35.730 --> 04:42.530] to the voter registration file which is provided to us by the jurisdiction for the pilot. All that [04:42.530 --> 04:50.790] matches, your identity is digitized, stored in the secure space on the handset, and all the [04:50.790 --> 04:56.150] documents you've provided are deleted at that point because we don't need them. We don't want [04:56.150 --> 05:01.710] to increase the threat surface after that as well. So at this point, you're ready to receive your [05:01.710 --> 05:09.990] ballot. So as you can see from the flow diagram, that's essentially a 10-step process. And once [05:09.990 --> 05:14.890] you've received the ballot, it's essentially your mobile representation of your actual paper ballot [05:14.890 --> 05:21.490] which you would receive if you went to work in person at your precinct, or if you opted into [05:21.490 --> 05:28.230] vote by mail, essentially the same ballot you'd get here. And so you map the ballot on the phone, [05:28.230 --> 05:33.490] and then you may be asked to sign an affidavit. Sign with the finger on the screen, and then [05:33.490 --> 05:38.630] once you're ready to submit, you confirm your choices, do your biometric verification on the [05:38.630 --> 05:45.250] device again, and at that point your ballot gets submitted to the network, anonymized, and you get [05:45.390 --> 05:54.010] a receipt so you can verify your selections, and then also participate in the audit process as well. [05:54.250 --> 06:00.490] And in the background, the jurisdiction gets an anonymized and anonymized copy of your receipt, [06:00.490 --> 06:06.450] and then close to election day, a paper ballot is printed. And then there's a pre-tabulation audit [06:07.170 --> 06:13.230] on election day. Printed paper ballots are tabulated just like other paper ballots, [06:13.950 --> 06:19.870] and there's no hand reproduction required. And then once the election's over, during the canvas [06:19.870 --> 06:26.070] phase, there's a full audit where receipts are prepared. So end-to-end, that's how the process [06:26.070 --> 06:34.510] works. Now that we've looked at kind of how the system functions, let's look at the threat model. [06:34.510 --> 06:42.310] So as you can see, it's a pretty interesting threat model here, obviously, because it's an [06:42.310 --> 06:49.530] internet-connected device. It is different from traditional methods of voting. So let's kind of [06:49.530 --> 06:57.070] run through the flow, and at each step we can look at some of the threats. This is the first [06:57.070 --> 07:03.890] phase, as you saw, you opted in, the county clerk approves you, and then you've started to download [07:03.890 --> 07:10.570] the app. So obviously, if you're not careful, you could download an incorrect app by mistake, or [07:11.150 --> 07:17.550] the app may already be compromised ahead of time by a bad actor, or there may be malware on your [07:17.550 --> 07:22.570] device which, you know, prevents normal functioning of the application. So it's kind of the first [07:22.570 --> 07:28.670] stage. Next, look at, now you're at the voting stage, so the threats here are maybe the biometric [07:28.670 --> 07:35.110] capability on your phone isn't working as it's supposed to. And obviously, at this stage, [07:35.110 --> 07:40.630] if there's malware, your apps can be reverse engineered, and there can be attempts made to [07:41.470 --> 07:47.910] change how you're voting. So that's the threat vector, and we'll see how there are ways to mitigate [07:47.910 --> 07:54.870] that a little bit later. Then obviously, in the transmission phase, the transmission is not secure, [07:54.870 --> 08:00.790] the transmission channel, that data may never reach the destination or may corrupt it on the [08:00.790 --> 08:06.670] way. So we look at ways as to how that can potentially be mitigated as well. And then [08:06.670 --> 08:14.250] the voter gets a receipt. So the receipt, there's a chance somebody else may get hold of your receipt [08:14.250 --> 08:19.790] if you're not careful. Obviously, that's an active area of research on how to create [08:19.790 --> 08:28.570] self-destructing receipts, but it's a potential threat vector. And so finally, once the ballots [08:28.570 --> 08:33.840] reach the jurisdiction, as they are printing the paper ballot for tabulation, [08:34.350 --> 08:41.650] and they do a pre-tabulation audit, so there is a potential threat vector which would likely get [08:41.650 --> 08:47.030] caught by the pre-tabulation audit. Nevertheless, important to keep in mind. [08:47.030 --> 08:53.210] Thank LA Times for making this nice picture available to us. Very nicely done. Makes it [08:53.210 --> 08:59.430] simple to understand. And so now that we've looked at the high-level threat model, [08:59.430 --> 09:05.370] let's look at what kind of threats we've seen in the wild over the last couple of years. [09:05.610 --> 09:11.630] So we like to group them into a few different categories. So there's obviously threats at the [09:11.630 --> 09:18.630] device level. There's threats at the network level. And so those are kind of user-centric [09:18.630 --> 09:25.410] scenarios. And then overall is the cloud infrastructure, our corporate network. So [09:25.410 --> 09:32.870] obviously those are areas of interest as well. So in terms of what we've seen, passive scanning, [09:32.870 --> 09:39.950] obviously, which happens to pretty much everybody these days who has a public-facing web asset. [09:39.950 --> 09:46.950] We've also seen active analysis of our web assets. So people actually trying to [09:46.950 --> 09:54.110] reverse engineer some of that stuff. And phishing of our staff, clients. [09:55.230 --> 10:01.750] Email spoofing attempts as well. Social engineering, obviously we're well aware of [10:01.750 --> 10:09.930] what happened recently. We've had attempts, phone calls, people pretending to be who they're not. [10:09.950 --> 10:16.790] We've seen DNS tampering attempts as well. SIM swap, SIM takeover attempts. And then [10:16.790 --> 10:24.230] reverse engineering of the mobile applications, sometimes partial. And then through the analysis, [10:24.230 --> 10:30.630] mobile API level attacks. So people actually trying to figure out how the API is working [10:30.630 --> 10:37.910] and trying to attack it. We've also seen on the Android side attempts to compromise the TEE, [10:37.910 --> 10:47.150] some of the TEEs are stored. And then malware, we do come across malware on several devices. And [10:47.830 --> 10:54.230] we'll see later on in one of our lectures, an interesting case that came to light. [10:55.110 --> 11:01.130] So before we dive into some of the data, it's going to be useful to look at the MITRE attack [11:01.130 --> 11:07.530] framework. So recently, MITRE updated the mapping for not just the enterprise side, [11:07.530 --> 11:14.750] which covers the cloud aspects in our case, but also the mobile side. So we mapped that data to [11:14.750 --> 11:22.150] what we've seen, as you can see on iOS, some interesting things to note and the device level. [11:22.690 --> 11:30.210] And then similarly, network-based vectors. So we already spoke about the SIM swap. And then [11:30.210 --> 11:37.510] you'll see some of the other ones in the data head, such as rogue Wi-Fi and things like that. [11:38.290 --> 11:45.350] Similarly, on the Android side, similar to iOS, a couple of different things, [11:45.350 --> 11:52.890] but we find the mapping useful, just as we plan out our work. And I'm sure a lot of you are [11:52.890 --> 11:58.850] looking at this as well. Similarly, on the network side for Android, [11:59.790 --> 12:08.570] let's look at a few case studies here. 2018 was when we had first opportunity to do public [12:08.570 --> 12:17.430] elections in the US. And so since then, we've had some interesting opportunities to collect data. [12:17.650 --> 12:25.110] So we'll start with something from 2018. One of the really interesting things we saw early on [12:25.110 --> 12:33.210] back then was the attempts to use multiple devices with the same adversary and using [12:33.910 --> 12:40.710] different mobile numbers and emails and trying to do the same thing. So in that scenario, [12:40.710 --> 12:48.170] the mitigation deployed by the system was to treat this as a malicious activity and block [12:48.170 --> 12:55.790] office access. We did see people use phone numbers in some telco blacklist, [12:56.490 --> 13:03.490] as well as people using well-known tools like WebSuite to probe the platform, probe the API [13:03.490 --> 13:09.990] endpoints. And in one of these cases, we were able to record the traffic through a honeypot. [13:09.990 --> 13:16.310] So some of that is available as part of the open data package and is also available. We'll share [13:16.310 --> 13:21.670] some public links at the end of the presentation, so you can get it from there as well. [13:22.310 --> 13:29.050] The other interesting thing from a case study perspective was people trying to reverse [13:29.050 --> 13:36.910] engineer the application. The system has an initial handshake process and we saw some attempts, [13:36.910 --> 13:42.970] manual attempts to engineer that handshake process. And so in that scenario as well, [13:42.970 --> 13:49.190] one of the mitigations was to block the IP address ranges or block the device IDs, [13:49.190 --> 13:55.630] depending on the nature of the attack. But that's an area where we have some feedback on [13:56.310 --> 14:05.210] better approaches to mitigate those kinds of attempts. Email spoofing, so we did see, [14:05.210 --> 14:11.070] we continue to see a lot of email spoofing attempts and obviously with DMARC that helps [14:11.070 --> 14:19.090] to mitigate that, but nevertheless we do keep track of it. Another interesting case study was [14:19.090 --> 14:28.370] involved, essentially network-based attempts to scan the passively and then use that information [14:28.370 --> 14:35.110] to actively look at infrastructure, particularly the API endpoints. So that's where we see a lot [14:35.110 --> 14:43.650] of interest. And then more recently we've had an opportunity to do somewhat larger elections [14:43.650 --> 14:49.690] in terms of participation. Some of the early pilots had a very small number of voters, so [14:49.690 --> 14:55.750] the opportunity to collect meaningful data was a little limited from a security, [14:55.750 --> 15:05.090] on-device security, network security perspective. But with one of the elections this year, [15:05.090 --> 15:13.250] some very interesting data to analyze, and so I'd love to share that. One focuses around, [15:13.250 --> 15:19.310] we call it the mobile threat detection. We partner with third parties for that capability as well as [15:19.310 --> 15:26.710] some stuff we have. And the way that's structured is, we call it a multi-channel [15:26.710 --> 15:33.170] component architecture. The device is communicating with obviously our back-end, [15:33.170 --> 15:39.090] it's also communicating with the third-party system. Similarly, our back-end is communicating [15:39.090 --> 15:46.470] with the third-party system. A good example was, somebody tries to reverse-engineer the app [15:47.330 --> 15:53.650] and hooks the specific locations where some of that code is getting triggered to try and bypass [15:53.650 --> 16:00.230] it. You could potentially disrupt two of these channels, but it'd be hard to disrupt the third [16:00.230 --> 16:08.710] channel. So that, in this case, acts as a saving grace and also as a extra detection mechanism. [16:09.410 --> 16:16.830] And so some of this capability is actively deployed. Next, probably the most interesting [16:16.830 --> 16:23.550] part of the presentation. So this is data from one of our recent elections, where a few thousand [16:23.550 --> 16:32.290] people participated. And this was kind of the device split, predominantly more iOS than Android. [16:32.290 --> 16:39.990] And then in terms of the threats we detected, on the network side, it was pretty even, 50-50. [16:40.210 --> 16:47.370] But on the device side, we saw sort of a lopsided share of threats being detected on Android. [16:47.370 --> 16:50.810] That could be a function of the devices that were being used, [16:51.450 --> 16:58.910] or maybe the unique factors to this election as well. But something interesting to keep in mind. [16:59.310 --> 17:05.050] Sort of diving one level deeper. So on the iOS side, let's kind of look at some of the network [17:05.650 --> 17:11.230] security threats. And this data, by the way, is available in the open data set. [17:11.250 --> 17:17.350] I believe it's the part one. So you can kind of dive in at your convenience as well. [17:17.370 --> 17:27.570] But at the iOS level, we saw 18 devices who were connected. So this was amongst the few thousand [17:27.570 --> 17:35.490] and the 64% who were using iOS. There were 18 devices detected which the Wi-Fi was deemed to be [17:35.490 --> 17:42.910] unsafe. And so obviously that creates a potential for a man-in-the-middle type of attack. So the [17:42.910 --> 17:49.630] experience was they were not able to complete the process on the device or ask to contact [17:49.630 --> 17:56.410] the support team. In that case, they were requested to either switch to the cellular network [17:56.410 --> 18:04.350] or switch to a different Wi-Fi network. In this case, once they did that, they were able to proceed. [18:06.170 --> 18:14.110] Similarly, on Android, similar number, about 17. On Android, we also saw an interesting case [18:14.110 --> 18:23.170] for potential ARP poisoning. ARP is address resolution protocols, I'm sure many of you know. [18:23.170 --> 18:28.790] In this case, it was a little hard for a support team to detect because we didn't have visibility [18:28.790 --> 18:35.630] into what the voter's home network looked like. And so it required a little bit of troubleshooting, [18:35.630 --> 18:42.710] but eventually turned out to be a media device which was causing this poisoning. And so the team [18:42.710 --> 18:48.970] requested the voter to turn off the media device. And then the threat went away and they were able [18:48.970 --> 18:55.970] to proceed. So an area we'd love to do a little more research, but it was interesting that we [18:55.970 --> 19:05.110] came across this one case. Next, let's look at some device level threats. On the iOS side, we did [19:05.110 --> 19:10.570] detect a few devices where the pin was not set. In that case, mitigation and resolution was to force [19:10.570 --> 19:17.410] the users to send in or activate the biometrics on the device. Otherwise, they couldn't really proceed. [19:17.930 --> 19:26.390] And we saw a few cases of side-loaded apps. And in each of those cases, when a little bit of [19:26.390 --> 19:31.970] due diligence was done, they were deemed to be legitimate apps. And so the voters were able to [19:31.970 --> 19:38.670] proceed. It was good to see them being detected in case they could pose a threat. [19:38.670 --> 19:45.030] So definitely something we'd like to research more on. On the Android side, a much larger number [19:45.030 --> 19:51.890] of devices without pins, which we weren't sure why, but was interesting. 89 devices didn't have [19:51.890 --> 19:58.190] pins set, so all those voters were forced to set a pin or activate the biometric capability on the [19:58.190 --> 20:06.110] devices. Similarly, on the side-loaded side of things, a lot more side-loaded apps, which kind [20:06.110 --> 20:14.250] of made sense given the ecosystem on Android. So it did take quite a bit of time to go through these, [20:14.250 --> 20:20.030] make sure everything was okay. Luckily, the election went for three days, so our support team [20:20.030 --> 20:26.730] had enough time to troubleshoot. In this investigation, we did find two instances where [20:26.730 --> 20:32.990] the device did have malware. And it was a fairly well-known malware. I'm sure many of you probably [20:32.990 --> 20:40.390] heard about it. But it was interesting that we were able to detect this, inform the voter, [20:40.390 --> 20:47.390] they were able to delete the offending apps, reset the devices, and then proceed. And then [20:47.390 --> 20:52.730] once the new checks were confirmed, they were actually able to vote successfully and complete [20:52.730 --> 20:59.010] the audit as well. A couple of other interesting Android-specific things, we did detect some [20:59.010 --> 21:06.070] instances of USB debugging being enabled. Nothing malicious on that front, but during [21:06.070 --> 21:12.830] the active voting, the phone was not connected to a computer. So that was fine. And then we did [21:12.830 --> 21:21.170] have another 21 devices where developer options were enabled. So once again, no direct impact, [21:21.170 --> 21:28.470] but something we'd like to keep track of. And as I mentioned earlier, this data is available as part [21:28.470 --> 21:38.130] of the package we've released. We'd love more feedback and suggestions on how to collect, [21:38.130 --> 21:43.750] how to analyze this in a better way, especially areas around malware and [21:44.710 --> 21:50.490] other really interesting things we were able to learn from here. [21:51.330 --> 21:57.350] And you'll notice that the data is, for the most part, anonymized. And that's true of the [21:57.350 --> 22:05.130] collection process as well. The voter is the one who's asked to initiate and not knowing what [22:05.130 --> 22:13.430] exactly has happened. So the data does not contain any personally identifying information, to the [22:13.430 --> 22:21.170] best of our knowledge. And lastly, love any suggestions and feedback from the community. [22:21.170 --> 22:28.530] We're a young company, the youngest company in this space, trying to do something which is [22:28.530 --> 22:34.670] unusual, to say the least. And so we'd love suggestions and feedback to improve and what [22:34.670 --> 22:41.470] things we could do better. And appreciate the participation of the community. Thank you for [22:41.470 --> 22:50.490] the DEF CON voting village team for giving us this opportunity to share this data. And we'll be [22:50.490 --> 22:59.450] sharing more of this data as we do more election pilots. And we'd love to continue to get feedback [22:59.450 --> 23:06.790] from everybody. More information is available on our website, especially under white papers and [23:06.790 --> 23:13.670] under the security section. So please feel free to explore and give us feedback and look at the [23:13.670 --> 23:20.630] data as it's posted in the future as well. Once again, thank you and hope you all have a [23:20.630 --> 23:26.690] great DEF CON experience this year, especially at the voting village. Thank you. Take care.