1
00:00:00,000 --> 00:00:02,660
Hey, everybody, and thanks for coming to this talk.

2
00:00:02,660 --> 00: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.

3
00:00:07,800 --> 00:00:08,720
federal elections.

4
00:00:08,720 --> 00: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.

5
00:00:18,420 --> 00:00:20,120
All right, so let's talk a bit about voting.

6
00:00:20,180 --> 00: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.

7
00:00:27,780 --> 00: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.

8
00:00:41,740 --> 00: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.

9
00:00:51,380 --> 00: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.

10
00:00:58,480 --> 00:01:05,380
For example, according to the CDC, 22% of adults in West Virginia have some serious difficulty walking or climbing stairs.

11
00:01:05,700 --> 00:01:09,020
Another 7.7% have some sort of vision impairment.

12
00:01:10,160 --> 00: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.

13
00:01:19,240 --> 00: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.

14
00:01:27,060 --> 00:01:34,740
In the crypto literature, these are defined as correctness, privacy, receipt freeness, and coercion resistance.

15
00:01:34,740 --> 00: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.

16
00:01:43,200 --> 00:01:49,100
Really interestingly, Votes advertised heavily on the use of cryptography and cryptographic tools.

17
00:01:49,200 --> 00: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.

18
00:01:57,200 --> 00:02:02,360
The question that we had was, you know, is this app meant to be N10 verifiable, right?

19
00:02:02,360 --> 00: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.

20
00:02:10,240 --> 00:02:15,700
And given the use of the tools that were purported to be used here, the expected guarantee of the system.

21
00:02:16,420 --> 00: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.

22
00:02:23,820 --> 00:02:26,640
For instance, they had this bug bounty by HackerOne.

23
00:02:26,640 --> 00:02:31,000
They had undergone a couple of security odds from people outside of the company.

24
00:02:31,120 --> 00:02:33,700
There's even some documentation of how their system worked.

25
00:02:33,700 --> 00:02:36,520
But the more you looked at them, the more red flags you saw.

26
00:02:36,940 --> 00:02:39,720
For instance, let's look a little bit at their documentation.

27
00:02:40,520 --> 00: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.

28
00:02:48,340 --> 00:02:51,620
Importantly, there was no formal description of how their system actually worked.

29
00:02:51,620 --> 00: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.

30
00:02:59,220 --> 00:03:04,140
There was a number of security reviews that were claimed to have occurred, but none were actually made public.

31
00:03:04,640 --> 00: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.

32
00:03:17,000 --> 00: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.

33
00:03:23,820 --> 00:03:27,020
The NCC was sort of interesting to look into as well.

34
00:03:27,180 --> 00: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.

35
00:03:33,360 --> 00: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.

36
00:03:43,740 --> 00: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.

37
00:03:56,740 --> 00:04:00,540
But in reality, there's really no formal definition for any of these things.

38
00:04:00,540 --> 00: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.

39
00:04:08,380 --> 00:04:12,260
So we really weren't clear on what to make of this whole thing.

40
00:04:12,800 --> 00:04:15,400
All right, so let's look a little bit at their bug bounty.

41
00:04:15,680 --> 00: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.

42
00:04:26,920 --> 00: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?

43
00:04:38,520 --> 00: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.

44
00:04:47,460 --> 00:04:49,360
It also had really limited scope.

45
00:04:49,360 --> 00: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.

46
00:04:56,320 --> 00:04:58,400
But they never really defined what physical access meant.

47
00:04:58,400 --> 00: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.

48
00:05:10,060 --> 00:05:13,560
And the test infrastructure provided was also sort of wonky.

49
00:05:13,640 --> 00: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.

50
00:05:21,600 --> 00:05:25,980
And when we first tried the app, it actually wouldn't connect at all.

51
00:05:29,010 --> 00:05:34,030
To make things even worse, both the live and bug bounty version of the apps were obfuscated.

52
00:05:34,430 --> 00:05:39,910
For context, with Android reverse engineering, everything is really an APK.

53
00:05:40,670 --> 00:05:47,330
And APKs themselves are made up of a bunch of Java classes and metadata in the form of XML.

54
00:05:47,390 --> 00: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.

55
00:05:57,410 --> 00:06:00,790
But the Java stuff will almost always decompile to source.

56
00:06:01,030 --> 00: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.

57
00:06:11,010 --> 00: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.

58
00:06:18,890 --> 00:06:24,210
Maybe this was done on accident, but there was other things that led us to believe that it wasn't, right?

59
00:06:24,210 --> 00: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.

60
00:06:30,610 --> 00:06:38,670
So, for instance, in normal cryptographic code, in Android, you'll see strings like ASGCM used.

61
00:06:38,670 --> 00:06:43,450
And instead, we would see this weird function call with a series of numbers after the fact.

62
00:06:43,450 --> 00:06:45,970
And if we actually looked into the function, what you'll see is this.

63
00:06:45,970 --> 00:06:52,010
And this is a really common runtime string deobfuscation technique.

64
00:06:52,350 --> 00: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.

65
00:07:00,070 --> 00:07:04,030
I've mostly seen this in cases of, say, hiding malware command and control.

66
00:07:04,550 --> 00:07:07,890
So, this is sort of out of the ordinary and interesting.

67
00:07:08,130 --> 00:07:10,870
And as a reminder, this is the bug bounty version of the app.

68
00:07:10,870 --> 00:07:13,350
And this is the version of the app that they're trying to get us to do analysis on.

69
00:07:13,350 --> 00:07:16,210
And there's all these sort of dodges to make it more difficult.

70
00:07:17,430 --> 00:07:21,050
Things also got a little interesting if you look at their safe harbor provisions.

71
00:07:21,050 --> 00: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.

72
00:07:29,910 --> 00:07:32,930
The restrictions I'm reporting seem to be the following.

73
00:07:32,930 --> 00:07:37,110
First, you must give votes reasonable time to patch bugs.

74
00:07:37,290 --> 00:07:41,930
And the second is that votes retains the authority to decide what reasonable time means.

75
00:07:41,930 --> 00:07:45,430
Taken together, this means that votes could just hold on to bugs indefinitely.

76
00:07:45,690 --> 00:07:50,890
And to me, this sort of misses the point of using a bug bounty as a transparency tool altogether.

77
00:07:50,970 --> 00: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.

78
00:08:01,430 --> 00: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.

79
00:08:10,690 --> 00:08:16,650
In fact, votes' CEO was quoted by CNN taking credit for reporting the researchers to the authorities.

80
00:08:16,750 --> 00: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.

81
00:08:23,950 --> 00: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.

82
00:08:33,970 --> 00: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.

83
00:08:45,130 --> 00: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.

84
00:08:52,590 --> 00: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.

85
00:09:00,870 --> 00:09:03,350
All right, so overall we found a bunch of issues, right?

86
00:09:03,350 --> 00: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.

87
00:09:15,530 --> 00:09:20,230
But really we needed to do this analysis, the impact was too great, so we did it anyway.

88
00:09:20,970 --> 00: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.

89
00:09:32,050 --> 00: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.

90
00:09:39,610 --> 00: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.

91
00:09:49,430 --> 00:09:53,910
All right, so let's take a very quick tour of the app from the voter's point of view.

92
00:09:54,990 --> 00:09:58,010
Initialization is very similar to any other app.

93
00:09:58,010 --> 00: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.

94
00:10:11,190 --> 00: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.

95
00:10:23,670 --> 00: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.

96
00:10:38,950 --> 00:10:43,670
Now, at this point, the voter can actually participate in elections, which looks something like this.

97
00:10:43,670 --> 00:10:45,090
Here's an actual ballot.

98
00:10:45,370 --> 00:10:48,270
Finally, they can review and submit their ballot.

99
00:10:48,270 --> 00:10:54,410
They're asked to verify and log in again using their biometrics, and finally they have voted.

100
00:10:54,790 --> 00: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.

101
00:11:04,730 --> 00: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.

102
00:11:12,990 --> 00:11:19,010
From what we could find in the literature, really there's no intent-verifiable voting system that really works this way.

103
00:11:20,370 --> 00:11:24,130
All right, so let's talk about what happens behind the scenes.

104
00:11:25,130 --> 00: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.

105
00:11:33,930 --> 00:11:36,930
In addition, there's two other entities that you should be aware of.

106
00:11:36,930 --> 00: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.

107
00:11:49,370 --> 00:11:52,350
So if you look at the network itself, it looks something like this.

108
00:11:52,390 --> 00:11:59,390
Solid lines here delineate a connection that we were able to actually observe or find in the documentation.

109
00:11:59,850 --> 00:12:04,490
Dotted lines are things that we sort of suspect exist.

110
00:12:05,210 --> 00:12:07,610
All right, so let's talk a little bit about attacks.

111
00:12:08,930 --> 00:12:14,590
Let's consider this scenario where an attacker has gotten control over a user's device and loaded some malware.

112
00:12:15,050 --> 00:12:19,750
The first thing that this malware would have to do is actually defeat Imperium's malware detection.

113
00:12:20,770 --> 00:12:23,390
Imperium is initialized on app creation.

114
00:12:23,490 --> 00: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.

115
00:12:32,130 --> 00: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?

116
00:12:40,050 --> 00: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.

117
00:12:51,470 --> 00:12:55,370
The thing about Imperium is that it's really not meant to stand up against targeted attacks, right?

118
00:12:55,370 --> 00:12:59,490
Defeating this is really easy, it turns out, if you have root on device.

119
00:12:59,630 --> 00:13:06,630
In particular, we can inject code into Java runtime and modify it to stop Imperium from ever really being initialized.

120
00:13:06,710 --> 00:13:11,690
This might sound super complicated, but this is almost all the code that's actually required.

121
00:13:11,790 --> 00:13:15,470
This sort of thing is really common and well supported by the tools in the modding community.

122
00:13:17,070 --> 00: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.

123
00:13:26,550 --> 00:13:29,710
And there's really not much that can be done to prevent this.

124
00:13:30,210 --> 00:13:33,550
Again, Votes does not appear to be end-to-end verifiable.

125
00:13:35,330 --> 00: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.

126
00:13:42,730 --> 00:13:47,250
You know, what happens if we only get access to the device after a vote has been cast?

127
00:13:48,070 --> 00: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.

128
00:13:59,990 --> 00:14:06,210
This database is encrypted using a secret key, which is derived from the user's PIN and the salt.

129
00:14:06,790 --> 00:14:10,070
The salt is a random value that's stored on disk unencrypted.

130
00:14:10,490 --> 00: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.

131
00:14:20,010 --> 00:14:25,130
And it requires a user's fingerprint or biometric to decrypt, and this is actually kind of okay, right?

132
00:14:25,130 --> 00:14:26,530
So it looks great.

133
00:14:26,670 --> 00:14:31,650
Except that the PINs themselves are only eight digits and numeral only.

134
00:14:32,370 --> 00:14:34,310
And of course, you know where this is going.

135
00:14:34,310 --> 00:14:38,330
10 to the 8 combinations means that there's roughly 100 million PINs.

136
00:14:38,330 --> 00: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.

137
00:14:54,330 --> 00: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.

138
00:15:08,350 --> 00:15:10,250
All right, let's talk about the server.

139
00:15:12,070 --> 00:15:16,150
Now, on device, you can really just get access to one particular user, of course.

140
00:15:16,230 --> 00:15:18,750
The server has access to far, far more.

141
00:15:18,750 --> 00:15:23,790
And what's really interesting is that Votes use this custom crypto protocol between the device and the server.

142
00:15:23,790 --> 00:15:25,190
It looks something like this.

143
00:15:25,530 --> 00:15:30,710
First, the device will establish a standard HTTPS connection to Votes' API server.

144
00:15:31,270 --> 00:15:36,750
Then, on top of HTTPS, it'll perform the following non-standard homeworld crypto algorithm.

145
00:15:37,070 --> 00:15:41,430
First, the device generates 100 ECDSA key pairs.

146
00:15:42,050 --> 00:15:45,810
It'll then immediately discard all but the 57th secret key.

147
00:15:46,450 --> 00:15:49,950
Then, the device sends all 100 public keys to Votes' server.

148
00:15:50,070 --> 00: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.

149
00:16:01,070 --> 00: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.

150
00:16:12,070 --> 00:16:16,630
Finally, the phone performs its own key agreement and decrypts the AES-GCM key.

151
00:16:17,570 --> 00:16:23,790
So, from this point forward, all communication is additionally encrypted using AES-GCM.

152
00:16:24,630 --> 00:16:30,690
The thing is that was actually 100% of the crypto in the protocol used between the device and the server.

153
00:16:30,830 --> 00:16:34,830
The app actually never sees anything from any blockchain.

154
00:16:35,150 --> 00:16:40,810
And this includes what we would expect to exist in an ecosystem like this, which would be a proof of inclusion.

155
00:16:40,990 --> 00:16:47,530
The app actually never even verifies the server's public key outside of the standard HTTPS connection.

156
00:16:47,870 --> 00:16:51,850
So, active man-in-the-middle attacks are still possible if HTTPS is broken.

157
00:16:51,910 --> 00:16:57,470
There's also no non-ephemeral public keys sent from the device, and nothing is ever even signed.

158
00:16:57,530 --> 00: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?

159
00:17:07,310 --> 00:17:13,430
All right, you know, maybe you think that it's impossible for someone to even get access to votes as servers.

160
00:17:13,430 --> 00:17:15,390
We're not worried about nation-states here.

161
00:17:15,390 --> 00:17:20,030
Let's talk about the least powered possible adversary, a passive network adversary.

162
00:17:20,810 --> 00: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.

163
00:17:29,270 --> 00:17:32,350
But it does make this other attack way worse.

164
00:17:32,370 --> 00:17:34,370
But first, I have to explain how votes are cast.

165
00:17:34,410 --> 00: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.

166
00:17:41,490 --> 00: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.

167
00:17:50,490 --> 00:17:55,210
For example, you can see the corresponding JSON sent from the server on the right.

168
00:17:56,510 --> 00: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.

169
00:18:07,330 --> 00:18:13,350
The result is a textbook side-channel attack, which again is made far worse by votes' custom crypto.

170
00:18:13,410 --> 00:18:17,410
In normal HTTPS, the plaintext is somewhat obfuscated by gzip compression.

171
00:18:17,690 --> 00:18:22,530
In votes' protocol, however, the plaintext is encrypted before gzip even gets a chance.

172
00:18:22,610 --> 00: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.

173
00:18:36,330 --> 00: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.

174
00:18:46,830 --> 00: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.

175
00:18:54,730 --> 00: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.

176
00:19:06,610 --> 00:19:07,950
All right, scenario four.

177
00:19:07,950 --> 00:19:11,170
Let's talk a little bit about privacy and informed consent.

178
00:19:13,690 --> 00: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.

179
00:19:28,030 --> 00:19:31,470
What's really interesting here is that none of this is actually done on device.

180
00:19:31,470 --> 00: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.

181
00:19:45,910 --> 00: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.

182
00:19:59,350 --> 00: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.

183
00:20:07,010 --> 00:20:10,750
So at this point, it's actually somewhat of a national security issue.

184
00:20:11,590 --> 00:20:12,410
All right.

185
00:20:12,450 --> 00:20:18,310
So in sum, we found five high severity vulnerabilities and a really serious privacy issue.

186
00:20:18,790 --> 00:20:23,170
Interestingly, many of the issues we found were really basic implementation failures.

187
00:20:23,170 --> 00: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?

188
00:20:34,450 --> 00:20:38,470
And again, like the API server had complete control over all users in the election.

189
00:20:39,130 --> 00: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.

190
00:20:48,150 --> 00: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.

191
00:20:57,450 --> 00:21:02,010
What's really frustrating about all this is that none of the attacks we found were really novel.

192
00:21:02,210 --> 00:21:08,810
I really started this research hoping to find some crazy new crypto, and instead I basically found the standard CRUD app.

193
00:21:10,350 --> 00: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.

194
00:21:20,670 --> 00: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.

195
00:21:32,010 --> 00: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.

196
00:21:38,330 --> 00: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.

197
00:21:48,270 --> 00:21:52,230
And again, this is why Rule 0 of bug bounties exists.

198
00:21:54,110 --> 00: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.

199
00:22:05,830 --> 00:22:13,250
And, you know, we actually kind of agree that voting infrastructure is critical infrastructure and really should be treated this way.

200
00:22:13,250 --> 00:22:20,850
So rather than reporting to votes, we reported to CISA, the part of DHS that is responsible for digital critical infrastructure.

201
00:22:21,010 --> 00:22:24,610
CISA here was fantastic, professional, and wonderful.

202
00:22:24,610 --> 00:22:30,770
They allowed us to report the vulnerabilities to both the vendor and those affected without putting ourselves at risk.

203
00:22:30,770 --> 00:22:36,050
Once we had confirmation that there were no active users of the app, we then released a preview of this paper.

204
00:22:37,290 --> 00:22:40,690
The media attention was immediate and effusive.

205
00:22:40,690 --> 00:22:47,050
We got a number of responses from both civil society and other researchers that were all very, very positive.

206
00:22:47,830 --> 00: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.

207
00:23:00,590 --> 00: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.

208
00:23:09,470 --> 00:23:11,850
They appeared to have two main concerns with our work.

209
00:23:11,850 --> 00:23:15,590
First, that we somehow used an older version of the app, which, by the way, wasn't true.

210
00:23:15,590 --> 00:23:18,630
I literally have no idea where this 27 version thing came from.

211
00:23:18,630 --> 00:23:21,630
We used the most recent version of the app at the time of analysis.

212
00:23:22,130 --> 00:23:26,110
And the second was that somehow our methodology was flawed.

213
00:23:27,150 --> 00:23:31,230
Interestingly, votes never really denied the vulnerabilities themselves.

214
00:23:31,370 --> 00:23:35,870
And attacking the methodology without denying the results is a really classic dodge.

215
00:23:35,870 --> 00:23:41,830
For example, Diebold did the exact same thing when Princeton's research on the Acuvo TSX came out.

216
00:23:41,830 --> 00:23:48,670
And it's worth noting that third parties were able to independently verify Princeton's findings after the fact.

217
00:23:49,750 --> 00: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.

218
00:24:01,490 --> 00:24:05,170
And Trail of Bits' report couldn't have been worse for votes, right?

219
00:24:05,390 --> 00:24:11,390
Not only validated our methodology, but also quoted votes as objections to our work and explicitly rejected all of them.

220
00:24:11,770 --> 00: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.

221
00:24:21,430 --> 00:24:25,550
They also revealed that Zemperium wasn't running during the pilots, also that it was a blacklist.

222
00:24:25,550 --> 00:24:30,690
They also found no evidence of a mixed net and confirmed the system was not end-to-end verifiable.

223
00:24:31,490 --> 00:24:34,550
They also found roughly 40 other bugs and vulnerabilities.

224
00:24:34,570 --> 00:24:37,410
So this is all sort of a mess .

225
00:24:37,410 --> 00:24:41,290
It's sort of important to do a little bit of retrospective and figure out how we got here.

226
00:24:41,290 --> 00: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.

227
00:24:51,830 --> 00:24:56,150
He says that it's not that cybersecurity people are bad people, per se.

228
00:24:57,390 --> 00:25:01,430
I think that it's that they are solving for one situation and I am solving for another.

229
00:25:01,710 --> 00:25:04,550
They want zero technology risk in any way, shape, or form.

230
00:25:04,550 --> 00:25:07,890
I am solving for the problem of turnout.

231
00:25:09,130 --> 00: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.

232
00:25:21,230 --> 00:25:25,170
And in this case, this is all really compounded by asymmetric information.

233
00:25:25,530 --> 00:25:27,150
And here's what I mean by that.

234
00:25:27,170 --> 00:25:31,150
Election systems in the US are fractured and purchasing decisions are made locally, right?

235
00:25:31,150 --> 00:25:37,550
Each jurisdiction here shouldn't have to be stuck trying to vet the security of the systems they're purchasing.

236
00:25:37,610 --> 00:25:43,530
And unfortunately, the vendor is always going to know more about the systems they create than those purchasing them.

237
00:25:43,890 --> 00:25:45,830
So what can we do?

238
00:25:46,190 --> 00:25:50,790
The first thing that we should do is try to fight efforts to increase information asymmetry.

239
00:25:50,790 --> 00:25:54,030
Put another way, we should advocate for transparency in this ecosystem.

240
00:25:54,210 --> 00:25:59,490
This can be done through better public analyses of election systems, including reverse engineering like this work.

241
00:26:00,190 --> 00:26:03,970
We must also start demanding software independence in our voting systems.

242
00:26:05,070 --> 00: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.

243
00:26:15,630 --> 00:26:19,510
For instance, like mail-in ballots, in-person drop-off, and in-person voting are all great.

244
00:26:20,230 --> 00: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.

245
00:26:33,530 --> 00:26:39,590
And everything that isn't transparent or software-independent, we should examine and really try to develop some replacements.

246
00:26:40,730 --> 00:26:42,630
Finally, it's an election year.

247
00:26:42,630 --> 00:26:43,450
Go vote!

248
00:26:43,850 --> 00:26:45,950
Thanks for watching, and feel free to reach out.