WEBVTT 00:00.970 --> 00:02.510 Good afternoon, everybody. 00:02.510 --> 00:04.090 My name is Nimit. 00:04.090 --> 00:06.730 I'm one of the co-founders at Votes. 00:07.050 --> 00:17.650 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. 00:17.810 --> 00:22.850 So before we dive into the data, just a quick overview about Votes. 00:22.850 --> 00:29.630 As many of you may know, Votes is the youngest elections company in the US. 00:29.930 --> 00:39.890 We got started almost by accident after winning a hackathon at South by Southwest in Austin, Texas, way back in 2014. 00:39.890 --> 00:43.390 The theme of the hackathon was Hack to the Future. 00:43.410 --> 00:46.630 What's the one thing you would do in the future and how you do it? 00:46.830 --> 01:06.070 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. 01:06.170 --> 01:15.470 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. 01:15.830 --> 01:27.130 So since then, we've done 67 elections so far and 11 of these have been public government election pilots. 01:27.130 --> 01:34.490 We've also done non-governmental elections, primarily with the state political parties in various states. 01:34.490 --> 01:43.810 And so some of the data we're going to share today covers a wide array of our elections from a security perspective. 01:44.010 --> 01:55.730 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. 01:55.750 --> 02:01.670 So I'll begin with a quick introduction about our system. 02:01.670 --> 02:15.290 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. 02:15.290 --> 02:24.670 Then you have the cloud infrastructure where the backend servers are running and also distributed blockchain infrastructure. 02:24.870 --> 02:32.830 And then you have the election administration-specific interfaces to the election jurisdiction. 02:32.870 --> 02:40.430 And then from there, their traditional infrastructure is ballot printers and tabulation equipment. 02:41.010 --> 02:49.970 And the way the entire process works is essentially, right now, the system is being piloted only for absentee voters. 02:49.970 --> 02:59.930 And within absentee voters, a very small subset of people, essentially military voters who are deployed, their families and any U.S. 03:00.790 --> 03:06.330 overseas, they're commonly referred to as Yokawa voters. 03:06.710 --> 03:23.910 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. 03:23.910 --> 03:28.810 And then if you're eligible, they will pre-provision you on the system. 03:29.010 --> 03:36.350 And then you get an invitation to download the application on your smartphone, iPhone or compatible Android device. 03:36.350 --> 03:40.970 So you begin with the email number and email ID and a mobile number. 03:40.990 --> 03:48.190 And then once you've done the initial onboarding, you are asked to do an identity check. 03:48.190 --> 03:52.270 So you'll have to take a picture of a government-issued photo ID. 03:52.590 --> 03:58.130 Right now, you can use a driver's license, state ID or passport. 03:58.130 --> 04:04.910 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. 04:05.930 --> 04:13.310 And then once you've done the scan in the application front and back, then you're asked to take a live video selfie. 04:13.870 --> 04:22.110 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. 04:22.610 --> 04:31.890 Liveness check is done as well to weed out any fakes or any other kind of fraudulent activity. 04:31.950 --> 04:41.950 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. 04:41.950 --> 04:55.310 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. 04:55.310 --> 05:00.070 We don't want to increase the threat surface after that as well. 05:00.230 --> 05:02.270 So at this point, you're ready to receive your ballot. 05:02.270 --> 05:08.270 So as you can see from the flow diagram, that's essentially a 10-step process. 05:08.650 --> 05:24.990 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. 05:25.250 --> 05:30.810 And so you map the ballot on the phone, and then you may be asked to sign an affidavit. 05:30.870 --> 05:48.810 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, 05:48.810 --> 05:54.010 and then also participate in the audit process as well. 05:54.250 --> 06:04.310 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. 06:04.550 --> 06:08.870 And then there's a pre-tabulation audit on election day. 06:08.870 --> 06:17.070 Printed paper ballots are tabulated just like other paper ballots, and there's no hand reproduction required. 06:17.970 --> 06:22.590 And then once the election's over, during the canvas phase, there's a full audit where receipts are prepared. 06:22.590 --> 06:27.130 So end-to-end, that's how the process works. 06:27.850 --> 06:34.510 Now that we've looked at kind of how the system functions, let's look at the threat model. 06:34.510 --> 06:44.170 So as you can see, it's a pretty interesting threat model here, obviously, because it's an internet-connected device. 06:44.170 --> 06:48.270 It is different from traditional methods of voting. 06:48.270 --> 06:55.530 So let's kind of run through the flow, and at each step we can look at some of the threats. 06:55.950 --> 07:04.710 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. 07:04.710 --> 07:21.510 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. 07:21.510 --> 07:23.690 So it's kind of the first stage. 07:23.870 --> 07:33.090 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. 07:33.450 --> 07:43.190 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. 07:43.750 --> 07:49.610 So that's the threat vector, and we'll see how there are ways to mitigate that a little bit later. 07:49.830 --> 08:01.210 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. 08:01.210 --> 08:06.210 So we look at ways as to how that can potentially be mitigated as well. 08:06.210 --> 08:08.370 And then the voter gets a receipt. 08:08.370 --> 08:15.930 So the receipt, there's a chance somebody else may get hold of your receipt if you're not careful. 08:16.210 --> 08:26.150 Obviously, that's an active area of research on how to create self-destructing receipts, but it's a potential threat vector. 08:26.190 --> 08:44.150 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. 08:44.230 --> 08:47.030 Nevertheless, important to keep in mind. 08:47.030 --> 08:51.610 Thank LA Times for making this nice picture available to us. 08:51.610 --> 08:52.770 Very nicely done. 08:52.770 --> 08:54.850 Makes it simple to understand. 08:55.510 --> 09:05.370 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. 09:05.610 --> 09:09.710 So we like to group them into a few different categories. 09:10.090 --> 09:13.170 So there's obviously threats at the device level. 09:13.170 --> 09:15.890 There's threats at the network level. 09:15.890 --> 09:19.750 And so those are kind of user-centric scenarios. 09:19.750 --> 09:25.410 And then overall is the cloud infrastructure, our corporate network. 09:25.410 --> 09:29.030 So obviously those are areas of interest as well. 09:29.270 --> 09:39.950 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. 09:39.950 --> 09:45.050 We've also seen active analysis of our web assets. 09:45.090 --> 09:49.550 So people actually trying to reverse engineer some of that stuff. 09:49.550 --> 09:54.110 And phishing of our staff, clients. 09:55.230 --> 09:58.570 Email spoofing attempts as well. 09:58.790 --> 10:03.650 Social engineering, obviously we're well aware of what happened recently. 10:03.990 --> 10:09.930 We've had attempts, phone calls, people pretending to be who they're not. 10:09.950 --> 10:13.530 We've seen DNS tampering attempts as well. 10:13.530 --> 10:16.490 SIM swap, SIM takeover attempts. 10:16.490 --> 10:21.570 And then reverse engineering of the mobile applications, sometimes partial. 10:21.570 --> 10:26.870 And then through the analysis, mobile API level attacks. 10:26.990 --> 10:32.330 So people actually trying to figure out how the API is working and trying to attack it. 10:32.330 --> 10:40.830 We've also seen on the Android side attempts to compromise the TEE, some of the TEEs are stored. 10:41.330 --> 10:46.950 And then malware, we do come across malware on several devices. 10:46.970 --> 10:54.230 And we'll see later on in one of our lectures, an interesting case that came to light. 10:55.110 --> 11:02.330 So before we dive into some of the data, it's going to be useful to look at the MITRE attack framework. 11:02.390 --> 11:12.310 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. 11:12.390 --> 11:22.150 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. 11:22.690 --> 11:26.230 And then similarly, network-based vectors. 11:26.230 --> 11:29.870 So we already spoke about the SIM swap. 11:29.870 --> 11:37.510 And then 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:51.730 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. 11:51.730 --> 11:55.310 And I'm sure a lot of you are looking at this as well. 11:55.370 --> 12:02.930 Similarly, on the network side for Android, let's look at a few case studies here. 12:03.530 --> 12:10.830 2018 was when we had first opportunity to do public elections in the US. 12:11.210 --> 12:17.430 And so since then, we've had some interesting opportunities to collect data. 12:17.650 --> 12:21.230 So we'll start with something from 2018. 12:21.870 --> 12:39.270 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. 12:39.270 --> 12:49.710 So in that scenario, the mitigation deployed by the system was to treat this as a malicious activity and block office access. 12:50.350 --> 13:04.950 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. 13:05.250 --> 13:09.990 And in one of these cases, we were able to record the traffic through a honeypot. 13:09.990 --> 13:15.810 So some of that is available as part of the open data package and is also available. 13:15.810 --> 13:21.670 We'll share some public links at the end of the presentation, so you can get it from there as well. 13:22.310 --> 13:31.150 The other interesting thing from a case study perspective was people trying to reverse engineer the application. 13:31.510 --> 13:40.710 The system has an initial handshake process and we saw some attempts, manual attempts to engineer that handshake process. 13:40.710 --> 13:52.330 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. 13:52.530 --> 14:01.070 But that's an area where we have some feedback on better approaches to mitigate those kinds of attempts. 14:02.070 --> 14:16.630 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. 14:16.630 --> 14:33.390 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. 14:33.390 --> 14:36.890 So that's where we see a lot of interest. 14:37.750 --> 14:45.770 And then more recently we've had an opportunity to do somewhat larger elections in terms of participation. 14:45.770 --> 14:58.910 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. 14:58.950 --> 15:10.890 But with one of the elections this year, some very interesting data to analyze, and so I'd love to share that. 15:10.890 --> 15:15.850 One focuses around, we call it the mobile threat detection. 15:15.850 --> 15:21.950 We partner with third parties for that capability as well as some stuff we have. 15:22.130 --> 15:29.010 And the way that's structured is, we call it a multi-channel component architecture. 15:29.010 --> 15:36.670 The device is communicating with obviously our back-end, it's also communicating with the third-party system. 15:36.670 --> 15:41.190 Similarly, our back-end is communicating with the third-party system. 15:41.910 --> 15:54.770 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. 15:55.030 --> 16:01.310 You could potentially disrupt two of these channels, but it'd be hard to disrupt the third channel. 16:01.510 --> 16:08.710 So that, in this case, acts as a saving grace and also as a extra detection mechanism. 16:09.410 --> 16:13.330 And so some of this capability is actively deployed. 16:13.970 --> 16:18.610 Next, probably the most interesting part of the presentation. 16:18.610 --> 16:25.130 So this is data from one of our recent elections, where a few thousand people participated. 16:25.790 --> 16:32.290 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:56.050 That could be a function of the devices that were being used, or maybe the unique factors to this election as well. 16:56.150 --> 16:58.910 But something interesting to keep in mind. 16:59.310 --> 17:01.150 Sort of diving one level deeper. 17:01.650 --> 17:07.270 So on the iOS side, let's kind of look at some of the network security threats. 17:07.510 --> 17:11.230 And this data, by the way, is available in the open data set. 17:11.250 --> 17:13.150 I believe it's the part one. 17:13.150 --> 17:17.350 So you can kind of dive in at your convenience as well. 17:17.370 --> 17:25.290 But at the iOS level, we saw 18 devices who were connected. 17:25.290 --> 17:30.910 So this was amongst the few thousand and the 64% who were using iOS. 17:31.070 --> 17:36.870 There were 18 devices detected which the Wi-Fi was deemed to be unsafe. 17:37.290 --> 17:41.970 And so obviously that creates a potential for a man-in-the-middle type of attack. 17:41.970 --> 17:51.130 So the experience was they were not able to complete the process on the device or ask to contact the support team. 17:51.910 --> 17:59.170 In that case, they were requested to either switch to the cellular network or switch to a different Wi-Fi network. 17:59.770 --> 18:04.350 In this case, once they did that, they were able to proceed. 18:06.170 --> 18:11.330 Similarly, on Android, similar number, about 17. 18:11.590 --> 18:17.810 On Android, we also saw an interesting case for potential ARP poisoning. 18:17.810 --> 18:23.170 ARP is address resolution protocols, I'm sure many of you know. 18:23.170 --> 18:33.150 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. 18:33.170 --> 18:41.450 And so it required a little bit of troubleshooting, but eventually turned out to be a media device which was causing this poisoning. 18:41.630 --> 18:46.350 And so the team requested the voter to turn off the media device. 18:46.570 --> 18:50.050 And then the threat went away and they were able to proceed. 18:50.570 --> 18:58.070 So an area we'd love to do a little more research, but it was interesting that we came across this one case. 18:59.090 --> 19:02.430 Next, let's look at some device level threats. 19:03.090 --> 19:07.730 On the iOS side, we did detect a few devices where the pin was not set. 19:07.730 --> 19:15.070 In that case, mitigation and resolution was to force the users to send in or activate the biometrics on the device. 19:15.070 --> 19:17.410 Otherwise, they couldn't really proceed. 19:17.930 --> 19:22.350 And we saw a few cases of side-loaded apps. 19:22.690 --> 19:30.310 And in each of those cases, when a little bit of due diligence was done, they were deemed to be legitimate apps. 19:30.310 --> 19:33.190 And so the voters were able to proceed. 19:33.450 --> 19:38.670 It was good to see them being detected in case they could pose a threat. 19:38.670 --> 19:42.070 So definitely something we'd like to research more on. 19:42.190 --> 19:50.210 On the Android side, a much larger number of devices without pins, which we weren't sure why, but was interesting. 19:50.490 --> 19:59.210 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. 19:59.430 --> 20:09.990 Similarly, on the side-loaded side of things, a lot more side-loaded apps, which kind of made sense given the ecosystem on Android. 20:10.150 --> 20:16.710 So it did take quite a bit of time to go through these, make sure everything was okay. 20:16.730 --> 20:22.470 Luckily, the election went for three days, so our support team had enough time to troubleshoot. 20:22.730 --> 20:28.610 In this investigation, we did find two instances where the device did have malware. 20:29.010 --> 20:32.110 And it was a fairly well-known malware. 20:32.110 --> 20:34.350 I'm sure many of you probably heard about it. 20:34.350 --> 20:46.830 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. 20:47.130 --> 20:54.250 And then once the new checks were confirmed, they were actually able to vote successfully and complete the audit as well. 20:54.990 --> 21:02.270 A couple of other interesting Android-specific things, we did detect some instances of USB debugging being enabled. 21:02.590 --> 21:10.490 Nothing malicious on that front, but during the active voting, the phone was not connected to a computer. 21:10.490 --> 21:11.550 So that was fine. 21:11.550 --> 21:17.650 And then we did have another 21 devices where developer options were enabled. 21:17.650 --> 21:24.610 So once again, no direct impact, but something we'd like to keep track of. 21:25.030 --> 21:31.670 And as I mentioned earlier, this data is available as part of the package we've released. 21:31.670 --> 21:50.490 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. 21:51.330 --> 21:55.730 And you'll notice that the data is, for the most part, anonymized. 21:55.730 --> 21:59.710 And that's true of the collection process as well. 22:00.350 --> 22:06.810 The voter is the one who's asked to initiate and not knowing what exactly has happened. 22:06.810 --> 22:14.850 So the data does not contain any personally identifying information, to the best of our knowledge. 22:15.190 --> 22:21.170 And lastly, love any suggestions and feedback from the community. 22:21.170 --> 22:30.790 We're a young company, the youngest company in this space, trying to do something which is unusual, to say the least. 22:30.810 --> 22:36.730 And so we'd love suggestions and feedback to improve and what things we could do better. 22:37.270 --> 22:40.810 And appreciate the participation of the community. 22:40.810 --> 22:48.450 Thank you for the DEF CON voting village team for giving us this opportunity to share this data. 22:48.990 --> 22:56.250 And we'll be sharing more of this data as we do more election pilots. 22:56.730 --> 23:00.810 And we'd love to continue to get feedback from everybody. 23:01.750 --> 23:08.610 More information is available on our website, especially under white papers and under the security section. 23:08.610 --> 23:17.230 So please feel free to explore and give us feedback and look at the data as it's posted in the future as well. 23:17.230 --> 23:25.510 Once again, thank you and hope you all have a great DEF CON experience this year, especially at the voting village. 23:25.690 --> 23:25.930 Thank you. 23:25.930 --> 23:26.690 Take care.