WEBVTT 00:00.000 --> 00:02.660 Hey, everybody, and thanks for coming to this talk. 00:02.660 --> 00:07.800 This is The Ballot is Busted Before the Blockchain, a security analysis of votes, the first internet application used in U.S. 00:07.800 --> 00:08.720 federal elections. 00:08.720 --> 00:17.500 My name is Mike Spector, and this is joint work with Jimmy Koppel and Danny Weitzner, and all three of us are from MIT's Computer Science and Artificial Intelligence Laboratory. 00:18.420 --> 00:20.120 All right, so let's talk a bit about voting. 00:20.180 --> 00:27.600 In February, the state of West Virginia abruptly abandoned plans to adopt an internet voting phone app called Votes, and this research is actually why. 00:27.780 --> 00:40.160 I also think this serves as a great case study for explaining why we should be careful before advocating for new technologies and civic processes, and it really highlights the need for transparency and accountability in election systems in particular. 00:41.740 --> 00:51.160 So our story starts in late 2019, when it became clear that West Virginia was going to pass a bill directing their Secretary of State to allow disabled voters to cast their ballots over the internet. 00:51.380 --> 00:57.480 This is really important in the context of West Virginia, because the state has a higher than average number of disabled voters. 00:58.480 --> 01:05.380 For example, according to the CDC, 22% of adults in West Virginia have some serious difficulty walking or climbing stairs. 01:05.700 --> 01:09.020 Another 7.7% have some sort of vision impairment. 01:10.160 --> 01:17.120 Interestingly, West Virginia had already been using Votes for overseas military voters, and we expected that they were going to be used for this expansion as well. 01:19.240 --> 01:26.880 So given the potential impact, we really wanted to know how Votes provided what are often considered to be the essential security requirements of voting. 01:27.060 --> 01:34.740 In the crypto literature, these are defined as correctness, privacy, receipt freeness, and coercion resistance. 01:34.740 --> 01:42.040 These bottom three properties are there to ensure that the voter isn't unduly pressured to vote in any particular way and can't sell their vote. 01:43.200 --> 01:49.100 Really interestingly, Votes advertised heavily on the use of cryptography and cryptographic tools. 01:49.200 --> 01:56.440 In particular, they said they used hardware-backed storage, mixed nets, and of course, because every app has to do this now, the blockchain. 01:57.200 --> 02:02.360 The question that we had was, you know, is this app meant to be N10 verifiable, right? 02:02.360 --> 02:09.920 And N10 verifiability is a guarantee that allows a voter to tell if their ballot was counted correctly in the final tally. 02:10.240 --> 02:15.700 And given the use of the tools that were purported to be used here, the expected guarantee of the system. 02:16.420 --> 02:23.820 What was really interesting about Votes to me is that if you took a look at them from sort of a large distance, they look really good. 02:23.820 --> 02:26.640 For instance, they had this bug bounty by HackerOne. 02:26.640 --> 02:31.000 They had undergone a couple of security odds from people outside of the company. 02:31.120 --> 02:33.700 There's even some documentation of how their system worked. 02:33.700 --> 02:36.520 But the more you looked at them, the more red flags you saw. 02:36.940 --> 02:39.720 For instance, let's look a little bit at their documentation. 02:40.520 --> 02:47.700 Their documentation consisted mostly of this FAQ, and here's a link to the version that we saw in the beginner analysis. 02:48.340 --> 02:51.620 Importantly, there was no formal description of how their system actually worked. 02:51.620 --> 02:59.220 And this was a bit odd, given the fact that the use of the crypto would really imply something novel that might require further explanation. 02:59.220 --> 03:04.140 There was a number of security reviews that were claimed to have occurred, but none were actually made public. 03:04.640 --> 03:16.800 And in fact, there was no public list of fixed vulnerabilities at all, which led us to believe that either the security reviews were just being kept secret, or the security reviews themselves hadn't found anything, in which case it's sort of unclear if they were any good. 03:17.000 --> 03:23.240 These reviews were done by the National Cyber Security Center and Shift State Security, two entities I'd never heard of before. 03:23.820 --> 03:27.020 The NCC was sort of interesting to look into as well. 03:27.180 --> 03:33.060 Their name originally gave me the impression that they were somehow associated with the government, and I was really surprised to learn that they weren't. 03:33.360 --> 03:41.520 They also appeared to me more of a trade association, and I couldn't find a staff cryptographer or security researcher there that I could reach out to and ask further questions. 03:43.740 --> 03:56.640 So, you know, at a first glance, many of the cryptographic guarantees that they tried to claim in the FAQ were sort of interesting, and they look like they're real hard things to achieve. 03:56.740 --> 04:00.540 But in reality, there's really no formal definition for any of these things. 04:00.540 --> 04:07.760 For example, N10 vote encryption really doesn't mean anything, but if you squint at it, it sort of looks like N10 verifiability. 04:08.380 --> 04:12.260 So we really weren't clear on what to make of this whole thing. 04:12.800 --> 04:15.400 All right, so let's look a little bit at their bug bounty. 04:15.680 --> 04:25.980 The FAQ bragged quite a bit about having a bug bounty, and don't get me wrong, having a bug bounty at all is fantastic, except when we took a deeper look, we found it to be sort of less than encouraging. 04:26.920 --> 04:38.520 You were required to use this special version of the Votes app, which connected to a bunch of different servers from the live version, and there was no documentation of the differences between the bug bounty and production, right? 04:38.520 --> 04:46.360 And as a researcher, this is sort of dangerous, because I really would like to know what the actual version of the app is doing versus what's happening in the special environment. 04:47.460 --> 04:49.360 It also had really limited scope. 04:49.360 --> 04:56.180 For instance, we weren't allowed to look into man-in-the-middle attacks, and there was nothing allowed that required physical access. 04:56.320 --> 04:58.400 But they never really defined what physical access meant. 04:58.400 --> 05:09.800 So if I used a jail break to simulate a root exploit and then found a bunch of things that I could do with a piece of malware that happened to have root on the system, it was unclear if that actually was in or out of bounds. 05:10.060 --> 05:13.560 And the test infrastructure provided was also sort of wonky. 05:13.640 --> 05:21.600 There was no binary source for the servers or the server infrastructure to set up yourself, so you had to rely on their systems. 05:21.600 --> 05:25.980 And when we first tried the app, it actually wouldn't connect at all. 05:29.010 --> 05:34.030 To make things even worse, both the live and bug bounty version of the apps were obfuscated. 05:34.430 --> 05:39.910 For context, with Android reverse engineering, everything is really an APK. 05:40.670 --> 05:47.330 And APKs themselves are made up of a bunch of Java classes and metadata in the form of XML. 05:47.390 --> 05:57.410 And what's really cool about APKs is that they, for the most part, will decompile to source, with the exception of C compiled libraries or something like that that are attached in there. 05:57.410 --> 06:00.790 But the Java stuff will almost always decompile to source. 06:01.030 --> 06:10.310 So we popped those into a decompiler, and the first thing that we noticed is that all function names, class names, and variable names had been changed into these random Unicode strings. 06:11.010 --> 06:18.870 This really isn't normal and is the kind of thing that's done as an additional step by some automated obfuscation tool to make static analysis more difficult. 06:18.890 --> 06:24.210 Maybe this was done on accident, but there was other things that led us to believe that it wasn't, right? 06:24.210 --> 06:30.610 So, for instance, later on in our reverse engineering process, we noticed that there was a bunch of string obfuscation going on. 06:30.610 --> 06:38.670 So, for instance, in normal cryptographic code, in Android, you'll see strings like ASGCM used. 06:38.670 --> 06:43.450 And instead, we would see this weird function call with a series of numbers after the fact. 06:43.450 --> 06:45.970 And if we actually looked into the function, what you'll see is this. 06:45.970 --> 06:52.010 And this is a really common runtime string deobfuscation technique. 06:52.350 --> 06:59.810 And I rarely have seen this in the context of consumer software, except out of things like game kits and DRM kits. 07:00.070 --> 07:04.030 I've mostly seen this in cases of, say, hiding malware command and control. 07:04.550 --> 07:07.890 So, this is sort of out of the ordinary and interesting. 07:08.130 --> 07:10.870 And as a reminder, this is the bug bounty version of the app. 07:10.870 --> 07:13.350 And this is the version of the app that they're trying to get us to do analysis on. 07:13.350 --> 07:16.210 And there's all these sort of dodges to make it more difficult. 07:17.430 --> 07:21.050 Things also got a little interesting if you look at their safe harbor provisions. 07:21.050 --> 07:28.890 These are the conditions that they put on researchers before the company agrees not to pursue legal action after you report a bug. 07:29.910 --> 07:32.930 The restrictions I'm reporting seem to be the following. 07:32.930 --> 07:37.110 First, you must give votes reasonable time to patch bugs. 07:37.290 --> 07:41.930 And the second is that votes retains the authority to decide what reasonable time means. 07:41.930 --> 07:45.430 Taken together, this means that votes could just hold on to bugs indefinitely. 07:45.690 --> 07:50.890 And to me, this sort of misses the point of using a bug bounty as a transparency tool altogether. 07:50.970 --> 07:59.990 If the point is to let us security researchers hold the company accountable to actually fix the bugs we discover, then there needs to be some sort of time limit here. 08:01.430 --> 08:09.650 To make matters worse, a previous attempt at security analysis appears to have resulted in a University of Michigan researcher being investigated by the FBI. 08:10.690 --> 08:16.650 In fact, votes' CEO was quoted by CNN taking credit for reporting the researchers to the authorities. 08:16.750 --> 08:23.410 And we never found any indication that the company was bothered that it turned out to be a researcher rather than a malicious entity. 08:23.950 --> 08:33.250 To be fair to votes, though, there was this quote in the bug bounty that explicitly banned examination of the non-bug bounty version of the app. 08:33.970 --> 08:43.010 However, the bug bounty's edit history tells us that this restriction was added after the University of Michigan researcher was reported to law enforcement. 08:45.130 --> 08:51.930 So I can't believe I have to say this, but the first unwritten rule of bug bounties is do not send the law after well-meaning security researchers. 08:52.590 --> 09:00.130 Flashing a bit forward in the talk, this combined with the rhetoric afterward really complicated our ability to disclose the results of our work. 09:00.870 --> 09:03.350 All right, so overall we found a bunch of issues, right? 09:03.350 --> 09:15.070 There's no formal documentation of the system, there was these weird security claims, there were no public security audits, the code itself was really obfuscated, and the bug bounty as a whole seemed kind of dubious. 09:15.530 --> 09:20.230 But really we needed to do this analysis, the impact was too great, so we did it anyway. 09:20.970 --> 09:31.670 All right, so a key challenge here was that we really didn't want to touch anything that could possibly cause harm to an election, and therefore we had to make a number of assumptions about the back end. 09:32.050 --> 09:39.370 Our solution was to manually reverse engineer the app and iteratively re-implement the server to better understand the protocol and app functionality. 09:39.610 --> 09:48.770 For analysis, we always assume the best possible situation for the back end, and whenever we deviated from this assumption, we explicitly discussed why in the paper. 09:49.430 --> 09:53.910 All right, so let's take a very quick tour of the app from the voter's point of view. 09:54.990 --> 09:58.010 Initialization is very similar to any other app. 09:58.010 --> 10:09.330 You're asked to use the sort of standard one-time password, you're asked to provide an eight-digit PIN, then you're asked to log in via fingerprint, and finally you are officially part of the system. 10:11.190 --> 10:22.810 At this point, however, you're still not verified as a real voter, so the way that Votes allows you to become sort of identified in the system is you provide some sort of physical ID. 10:23.670 --> 10:38.230 And how they do this is that they ask you to take a picture of your ID, and they ask you to take a picture of your face, and then they upload it somewhere and do some matching, and eventually the user is told that they have successfully been verified. 10:38.950 --> 10:43.670 Now, at this point, the voter can actually participate in elections, which looks something like this. 10:43.670 --> 10:45.090 Here's an actual ballot. 10:45.370 --> 10:48.270 Finally, they can review and submit their ballot. 10:48.270 --> 10:54.410 They're asked to verify and log in again using their biometrics, and finally they have voted. 10:54.790 --> 11:04.390 From their FAQ and reports from the pilots, we found out that the users emailed an encrypted receipt of their vote, which appears to actually contain their real selections. 11:04.730 --> 11:12.150 It's really not clear how this receipt ends up working in practice, but we did find this screen in the app which provided a password for decryption. 11:12.990 --> 11:19.010 From what we could find in the literature, really there's no intent-verifiable voting system that really works this way. 11:20.370 --> 11:24.130 All right, so let's talk about what happens behind the scenes. 11:25.130 --> 11:33.930 In reality, Votes is for the most part just a REST app, which means it's a bunch of HTTPS GET and PUT requests to a centralized API server. 11:33.930 --> 11:36.930 In addition, there's two other entities that you should be aware of. 11:36.930 --> 11:49.310 The first is Imperium, which is a third-party antivirus which Votes uses to detect all sorts of stuff going on in the system, and a third-party ID verification service called Jumeo. 11:49.370 --> 11:52.350 So if you look at the network itself, it looks something like this. 11:52.390 --> 11:59.390 Solid lines here delineate a connection that we were able to actually observe or find in the documentation. 11:59.850 --> 12:04.490 Dotted lines are things that we sort of suspect exist. 12:05.210 --> 12:07.610 All right, so let's talk a little bit about attacks. 12:08.930 --> 12:14.590 Let's consider this scenario where an attacker has gotten control over a user's device and loaded some malware. 12:15.050 --> 12:19.750 The first thing that this malware would have to do is actually defeat Imperium's malware detection. 12:20.770 --> 12:23.390 Imperium is initialized on app creation. 12:23.490 --> 12:32.130 So when the app first loads, it begins scanning, and then after every app resumes, so if you were to leave the app and go to your web browser and come back, it'll then do another scan. 12:32.130 --> 12:40.050 It looks for a bunch of things like known exploits slash malware, any indicators of jailbreak, debugging, or modding, and it's a bit of a snitch, right? 12:40.050 --> 12:50.890 If you're caught, it will alert both the Votes API server and its Imperium servers, and if we had to guess, this is probably what caused the University of Michigan researcher to be caught. 12:51.470 --> 12:55.370 The thing about Imperium is that it's really not meant to stand up against targeted attacks, right? 12:55.370 --> 12:59.490 Defeating this is really easy, it turns out, if you have root on device. 12:59.630 --> 13:06.630 In particular, we can inject code into Java runtime and modify it to stop Imperium from ever really being initialized. 13:06.710 --> 13:11.690 This might sound super complicated, but this is almost all the code that's actually required. 13:11.790 --> 13:15.470 This sort of thing is really common and well supported by the tools in the modding community. 13:17.070 --> 13:26.070 And without Imperium, right, the attacker has complete control over the user's device, and any receipt that you would receive over email is also likely compromised as well. 13:26.550 --> 13:29.710 And there's really not much that can be done to prevent this. 13:30.210 --> 13:33.550 Again, Votes does not appear to be end-to-end verifiable. 13:35.330 --> 13:42.730 All right, so maybe you don't buy this attack, maybe you think that it's a little difficult to get malware on the system a priori. 13:42.730 --> 13:47.250 You know, what happens if we only get access to the device after a vote has been cast? 13:48.070 --> 13:58.890 All right, so what's really interesting is that there's an encrypted database that contains all of the user's vote history and everything that is needed to authenticate as the user to their server. 13:59.990 --> 14:06.210 This database is encrypted using a secret key, which is derived from the user's PIN and the salt. 14:06.790 --> 14:10.070 The salt is a random value that's stored on disk unencrypted. 14:10.490 --> 14:19.910 The PIN, however, is also stored on disk, but it is encrypted using the Android Keystore, which means the keys are stored in this hardware enclave and never accessible to the app itself. 14:20.010 --> 14:25.130 And it requires a user's fingerprint or biometric to decrypt, and this is actually kind of okay, right? 14:25.130 --> 14:26.530 So it looks great. 14:26.670 --> 14:31.650 Except that the PINs themselves are only eight digits and numeral only. 14:32.370 --> 14:34.310 And of course, you know where this is going. 14:34.310 --> 14:38.330 10 to the 8 combinations means that there's roughly 100 million PINs. 14:38.330 --> 14:53.730 And if we copy the database from the device onto our laptop and create a very short Python script to try to brute force it, we found that it takes roughly 0.05 milliseconds per attempt so that you can try all these PINs in roughly 1.6 hours. 14:54.330 --> 15:07.050 Indeed, we were able to get complete access to the voter's entire vote history and their authentication data, meaning that anyone with forensic access can brute force the PIN, control the voter, and see how they voted. 15:08.350 --> 15:10.250 All right, let's talk about the server. 15:12.070 --> 15:16.150 Now, on device, you can really just get access to one particular user, of course. 15:16.230 --> 15:18.750 The server has access to far, far more. 15:18.750 --> 15:23.790 And what's really interesting is that Votes use this custom crypto protocol between the device and the server. 15:23.790 --> 15:25.190 It looks something like this. 15:25.530 --> 15:30.710 First, the device will establish a standard HTTPS connection to Votes' API server. 15:31.270 --> 15:36.750 Then, on top of HTTPS, it'll perform the following non-standard homeworld crypto algorithm. 15:37.070 --> 15:41.430 First, the device generates 100 ECDSA key pairs. 15:42.050 --> 15:45.810 It'll then immediately discard all but the 57th secret key. 15:46.450 --> 15:49.950 Then, the device sends all 100 public keys to Votes' server. 15:50.070 --> 16:00.150 The server will generate its own 100 keys and perform a key agreement with the center's 57th public key and generate a random value that will later be used as an AES-GCM shared key. 16:01.070 --> 16:11.930 It'll then encrypt this AES-GCM key with the ECDSA shared key, this 57th key, and sends the client, the server's 100 public keys. 16:12.070 --> 16:16.630 Finally, the phone performs its own key agreement and decrypts the AES-GCM key. 16:17.570 --> 16:23.790 So, from this point forward, all communication is additionally encrypted using AES-GCM. 16:24.630 --> 16:30.690 The thing is that was actually 100% of the crypto in the protocol used between the device and the server. 16:30.830 --> 16:34.830 The app actually never sees anything from any blockchain. 16:35.150 --> 16:40.810 And this includes what we would expect to exist in an ecosystem like this, which would be a proof of inclusion. 16:40.990 --> 16:47.530 The app actually never even verifies the server's public key outside of the standard HTTPS connection. 16:47.870 --> 16:51.850 So, active man-in-the-middle attacks are still possible if HTTPS is broken. 16:51.910 --> 16:57.470 There's also no non-ephemeral public keys sent from the device, and nothing is ever even signed. 16:57.530 --> 17:06.270 And the summary here is that the API server can really do anything that it wants, which sort of begs the question, what's the point of having this blockchain? 17:07.310 --> 17:13.430 All right, you know, maybe you think that it's impossible for someone to even get access to votes as servers. 17:13.430 --> 17:15.390 We're not worried about nation-states here. 17:15.390 --> 17:20.030 Let's talk about the least powered possible adversary, a passive network adversary. 17:20.810 --> 17:29.030 Now, that protocol that I mentioned, that I explained before, was non-standard and has unclear security benefits, but it isn't inherently insecure on its own. 17:29.270 --> 17:32.350 But it does make this other attack way worse. 17:32.370 --> 17:34.370 But first, I have to explain how votes are cast. 17:34.410 --> 17:40.610 On the left is what a ballot looks like in-app when the user is selecting their preferred candidate and example election. 17:41.490 --> 17:50.290 This is generated from JSON strings sent by the server, which are variable length, depending on the description of the candidate, various URLs, and other metadata. 17:50.490 --> 17:55.210 For example, you can see the corresponding JSON sent from the server on the right. 17:56.510 --> 18:06.790 When a vote is submitted, you might expect that it just sends some ID numbers, but instead what it does is it sends all metadata for the voter's choice, but only that candidate's metadata. 18:07.330 --> 18:13.350 The result is a textbook side-channel attack, which again is made far worse by votes' custom crypto. 18:13.410 --> 18:17.410 In normal HTTPS, the plaintext is somewhat obfuscated by gzip compression. 18:17.690 --> 18:22.530 In votes' protocol, however, the plaintext is encrypted before gzip even gets a chance. 18:22.610 --> 18:34.250 The result is that if you know the lengths of the ballot options, you can very obviously tell which of the options the voter selected because you cannot effectively compress encrypted data. 18:36.330 --> 18:46.530 This image graphs the size of packets sent from the device to the server immediately after a submission for the candidate with the short description and the candidate with the long description. 18:46.830 --> 18:54.030 Note that you can clearly tell which packet is the vote submission and which run is for the long candidate and or short candidate. 18:54.730 --> 19:05.410 The end result is that a passive network adversary like, say, the user's ISP or the insecure coffee shop Wi-Fi that they're voting from can easily determine ballot selections. 19:06.610 --> 19:07.950 All right, scenario four. 19:07.950 --> 19:11.170 Let's talk a little bit about privacy and informed consent. 19:13.690 --> 19:27.650 Jumeo is this third party that actually does a series of things for votes in this ecosystem, including liveness detection, some machine learning to match the selfie and the voter's ID, and performs OCR on the ID. 19:28.030 --> 19:31.470 What's really interesting here is that none of this is actually done on device. 19:31.470 --> 19:45.110 In fact, Jumeo's servers actually gets both of these images, which include all of the voters' personal information, like their driver's license ID, as well as their location via GPS. 19:45.910 --> 19:59.150 And the only place that we could find either in their votes as documentation at the time, or in the app itself, were these very small translucent logos at the bottom of these two particular screens. 19:59.350 --> 20:07.010 And I'm not normally a privacy nut, but in this case, you got to remember that this app was being used for soldiers in war zones. 20:07.010 --> 20:10.750 So at this point, it's actually somewhat of a national security issue. 20:11.590 --> 20:12.410 All right. 20:12.450 --> 20:18.310 So in sum, we found five high severity vulnerabilities and a really serious privacy issue. 20:18.790 --> 20:23.170 Interestingly, many of the issues we found were really basic implementation failures. 20:23.170 --> 20:33.670 This included a mandated use of weak passwords, their anti-tamper slash AB solution was really easily circumventable, the side channel attack that we described earlier, right? 20:34.450 --> 20:38.470 And again, like the API server had complete control over all users in the election. 20:39.130 --> 20:47.530 It's also really unlikely that any of this is N10 verifiable or, and it's unclear from what we saw that this could possibly be receipt-free or coercion-resistant. 20:48.150 --> 20:56.790 Below is a summary of the powers of a given adversary, and I won't dwell too much on this here, but if you read the paper, we go into much further detail. 20:57.450 --> 21:02.010 What's really frustrating about all this is that none of the attacks we found were really novel. 21:02.210 --> 21:08.810 I really started this research hoping to find some crazy new crypto, and instead I basically found the standard CRUD app. 21:10.350 --> 21:20.670 So at this point, we really needed to talk to somebody, and I'm a huge believer in responsible disclosure, and we really didn't want to hurt an ongoing election, but there was a real sense of urgency. 21:20.670 --> 21:31.890 And remember, for context, the DNC had just announced that it was going to use a voting app to count ballots for Iowa's primary, and as far as we knew, votes was what they were using. 21:32.010 --> 21:37.770 We actually really didn't think that the DNC would be crazy enough to try to launch an app right before an election. 21:38.330 --> 21:48.030 So the first thing that we did is we contacted the MIT BU Law Clinic, who were fantastic, and we sort of ran immediately into this very pernicious problem. 21:48.270 --> 21:52.230 And again, this is why Rule 0 of bug bounties exists. 21:54.110 --> 22:05.490 Both law enforcement and votes seem to have used this rationale for reporting the researcher that it was somehow required due to this designation as critical infrastructure. 22:05.830 --> 22:13.250 And, you know, we actually kind of agree that voting infrastructure is critical infrastructure and really should be treated this way. 22:13.250 --> 22:20.850 So rather than reporting to votes, we reported to CISA, the part of DHS that is responsible for digital critical infrastructure. 22:21.010 --> 22:24.610 CISA here was fantastic, professional, and wonderful. 22:24.610 --> 22:30.770 They allowed us to report the vulnerabilities to both the vendor and those affected without putting ourselves at risk. 22:30.770 --> 22:36.050 Once we had confirmation that there were no active users of the app, we then released a preview of this paper. 22:37.290 --> 22:40.690 The media attention was immediate and effusive. 22:40.690 --> 22:47.050 We got a number of responses from both civil society and other researchers that were all very, very positive. 22:47.830 --> 23:00.290 Senator Ron Wyden spoke in support of our findings and sent a letter to SHIFT State Security asking for further information about why, for instance, they hadn't found the same bugs that we had. 23:00.590 --> 23:09.090 And I think that the reason everyone was immediately so sure of our results actually has a lot more to do with votes' response to us, which, to put it frankly, wasn't very encouraging. 23:09.470 --> 23:11.850 They appeared to have two main concerns with our work. 23:11.850 --> 23:15.590 First, that we somehow used an older version of the app, which, by the way, wasn't true. 23:15.590 --> 23:18.630 I literally have no idea where this 27 version thing came from. 23:18.630 --> 23:21.630 We used the most recent version of the app at the time of analysis. 23:22.130 --> 23:26.110 And the second was that somehow our methodology was flawed. 23:27.150 --> 23:31.230 Interestingly, votes never really denied the vulnerabilities themselves. 23:31.370 --> 23:35.870 And attacking the methodology without denying the results is a really classic dodge. 23:35.870 --> 23:41.830 For example, Diebold did the exact same thing when Princeton's research on the Acuvo TSX came out. 23:41.830 --> 23:48.670 And it's worth noting that third parties were able to independently verify Princeton's findings after the fact. 23:49.750 --> 24:00.790 Speaking of which, about a month after we released our report, Trail of Bits, a really well-known security firm, revealed that it had been contracted to do a full source code review of votes. 24:01.490 --> 24:05.170 And Trail of Bits' report couldn't have been worse for votes, right? 24:05.390 --> 24:11.390 Not only validated our methodology, but also quoted votes as objections to our work and explicitly rejected all of them. 24:11.770 --> 24:21.110 It also confirmed all of our bugs and revealed that the company had been alerted to their veracity before they spoke to the press. 24:21.430 --> 24:25.550 They also revealed that Zemperium wasn't running during the pilots, also that it was a blacklist. 24:25.550 --> 24:30.690 They also found no evidence of a mixed net and confirmed the system was not end-to-end verifiable. 24:31.490 --> 24:34.550 They also found roughly 40 other bugs and vulnerabilities. 24:34.570 --> 24:37.410 So this is all sort of a mess . 24:37.410 --> 24:41.290 It's sort of important to do a little bit of retrospective and figure out how we got here. 24:41.290 --> 24:51.150 I think that there's a tension here that can be summarized pretty well in this quote by Bradley Tusk , who was the philanthropist that funded Votes is Use and seems to be really focused on expanding internet voting. 24:51.830 --> 24:56.150 He says that it's not that cybersecurity people are bad people, per se. 24:57.390 --> 25:01.430 I think that it's that they are solving for one situation and I am solving for another. 25:01.710 --> 25:04.550 They want zero technology risk in any way, shape, or form. 25:04.550 --> 25:07.890 I am solving for the problem of turnout. 25:09.130 --> 25:20.670 And while I really do agree with the overall goal of solving this particular problem, the issue is that introducing new technology tends to introduce new and unexamined risks. 25:21.230 --> 25:25.170 And in this case, this is all really compounded by asymmetric information. 25:25.530 --> 25:27.150 And here's what I mean by that. 25:27.170 --> 25:31.150 Election systems in the US are fractured and purchasing decisions are made locally, right? 25:31.150 --> 25:37.550 Each jurisdiction here shouldn't have to be stuck trying to vet the security of the systems they're purchasing. 25:37.610 --> 25:43.530 And unfortunately, the vendor is always going to know more about the systems they create than those purchasing them. 25:43.890 --> 25:45.830 So what can we do? 25:46.190 --> 25:50.790 The first thing that we should do is try to fight efforts to increase information asymmetry. 25:50.790 --> 25:54.030 Put another way, we should advocate for transparency in this ecosystem. 25:54.210 --> 25:59.490 This can be done through better public analyses of election systems, including reverse engineering like this work. 26:00.190 --> 26:03.970 We must also start demanding software independence in our voting systems. 26:05.070 --> 26:15.630 We don't really know how to do this very well with electronic-only voting, and anything where the voter gets to physically verify their paper ballot before it's sent in is really a better situation here. 26:15.630 --> 26:19.510 For instance, like mail-in ballots, in-person drop-off, and in-person voting are all great. 26:20.230 --> 26:32.770 Electronic-only return or other electronic-only systems like DREs are really, really hard to make and verifiable, and really, really hard to make software-independent, and we're still trying to figure out how to do this at the research level. 26:33.530 --> 26:39.590 And everything that isn't transparent or software-independent, we should examine and really try to develop some replacements. 26:40.730 --> 26:42.630 Finally, it's an election year. 26:42.630 --> 26:43.450 Go vote! 26:43.850 --> 26:45.950 Thanks for watching, and feel free to reach out.