1 00:00:16,240 --> 00:00:20,160 [Auto-generated transcript. Edits may have been applied for clarity.] Good afternoon everyone. I don't have a mic, so I'll just yell a bit. 2 00:00:20,800 --> 00:00:25,200 Uh. Good afternoon. Uh, welcome to our Michaelmas term stretchy lecture. 3 00:00:25,760 --> 00:00:33,520 It's great to see your poor house today, and it's a great pleasure to introduce Professor Alistair Beresford from the other Place, 4 00:00:34,280 --> 00:00:41,760 where he is a professor of computer security and also head of Department of Computer Science and Technology at the University of Cambridge. 5 00:00:43,320 --> 00:00:51,120 Alistair is a good friend and colleague whose research is on security of large distributed systems, in particular mobile platforms. 6 00:00:52,200 --> 00:00:55,680 He has received numerous awards for his research recently. 7 00:00:57,080 --> 00:01:06,190 2019 Google Security and privacy price and more recently, even 2026 I Tripoli Pervasive Computing Test of Time Award. 8 00:01:06,590 --> 00:01:09,910 For his work, he published 2003, I believe, on location privacy. 9 00:01:10,910 --> 00:01:14,390 So this was the time we just talked. There was not even a 3G network there. 10 00:01:14,670 --> 00:01:22,110 So it was all right, thank you very much. And so in today's talk, Hiding in Plain Sight the Promises of Pitfalls of Secret Communication, 11 00:01:23,150 --> 00:01:31,190 Alistair will discuss coverage Rob developed together with the Guardian, and the challenges of taking privacy research to real world deployments. 12 00:01:31,790 --> 00:01:34,710 Thank you very much. The floor is yours. Thank you, thank you. Welcome to Oxford. 13 00:01:41,790 --> 00:01:48,230 Thank you very much for the invite and also for so many turning out today. So what do we mean by secret communication. 14 00:01:49,270 --> 00:01:54,030 So today I'm going to talk about four different properties and think about them with some care. 15 00:01:54,750 --> 00:02:00,730 So the first is confidentiality. So can we keep something secret or confidential to a small number of parties. 16 00:02:01,610 --> 00:02:06,650 Integrity. To prevent information from being modified by others when we don't want it to be modified. 17 00:02:07,930 --> 00:02:13,370 Authenticity. So how do we know our message is going to or has been coming from a particular entity party? 18 00:02:14,490 --> 00:02:19,770 And finally, anonymity. So can we make sure our communication is anonymous in the sense that maybe we don't know who the sender was, 19 00:02:20,290 --> 00:02:23,650 or that some other third party can't tell who is communicating? 20 00:02:26,090 --> 00:02:32,570 If we think back some time in the past about computer networks and communications in computing, 21 00:02:33,610 --> 00:02:38,770 the internet was mostly unencrypted and in fact not providing these properties back in the 1980s and early 1990s. 22 00:02:40,090 --> 00:02:46,290 It's partly because it was a smaller, more trusted environment. There wasn't a commercial imperative like you might see with banking payments, 23 00:02:47,050 --> 00:02:52,010 but also that encryption in those eras took an awful lot more time and expense in terms of compute. 24 00:02:53,330 --> 00:03:00,120 There are also legal challenges. So export control, for example, applied in some countries, preventing strong encryption from being exported, 25 00:03:00,880 --> 00:03:05,400 and also some of the key algorithms were under patent and therefore there are licensing restrictions. 26 00:03:06,880 --> 00:03:12,640 Another challenge was about the lack of really a defined public key infrastructure. How do we actually make sure we are talking to the right party? 27 00:03:13,080 --> 00:03:20,040 Was a difficult problem. One of the first examples was PGP or Pretty Good Privacy, 28 00:03:20,640 --> 00:03:27,560 which was developed to offer email encryption from 1991 onwards, and this was, for technical users, a real success. 29 00:03:28,720 --> 00:03:34,240 The challenge was that it was pretty hard to use. So in this now famous paper, Why Johnnie Can't Encrypt. 30 00:03:35,480 --> 00:03:43,920 Uh, Whitten and Tyga demonstrated that the majority of novice users were unable to sign an encrypted message successfully, even after 90 minutes. 31 00:03:44,720 --> 00:03:49,160 Okay, so. Well, PGP offered fantastic technical implementation. 32 00:03:50,120 --> 00:04:01,700 It was hard to use. We then saw ourselves move towards the World Wide Web and Secure Sockets Layer, or SSL, was developed by Netscape in the mid 90s. 33 00:04:02,460 --> 00:04:07,220 LED by to hear Al Gamal. And this offered a much better, simpler user interface. 34 00:04:07,620 --> 00:04:10,740 So you simply had to write Https to connect to a service. 35 00:04:11,700 --> 00:04:15,180 And that was enabled by the fact that there was a hierarchical key management 36 00:04:15,700 --> 00:04:18,460 infrastructure to enable that to happen without so much user interaction. 37 00:04:20,180 --> 00:04:26,060 It also meant that you were talking between a client and a server, or namely your desktop computer and a web server. 38 00:04:26,420 --> 00:04:30,500 So the encryption ran or supported and secured communication between those two devices. 39 00:04:33,580 --> 00:04:40,140 This sort of use of SSL was not particularly pervasive well into the noughties and the early 20 tens, 40 00:04:41,180 --> 00:04:46,820 and several things then came to conspire to see us deploy encryption on the web much more pervasively. 41 00:04:48,180 --> 00:04:52,820 The first was the introduction and then use and popularisation of Wi-Fi and wireless networks, 42 00:04:53,820 --> 00:04:57,690 and that meant that other devices could easily listen in on your communications. 43 00:04:58,650 --> 00:05:03,130 So in 2010, uh, Eric Butler developed this, uh, 44 00:05:03,530 --> 00:05:10,050 plugin called Fire Sheep for Firefox to demonstrate the vulnerability that we all experience when using Wi-Fi networks. 45 00:05:10,770 --> 00:05:17,810 And what Fire Sheep would do was listen out for connections to Facebook or Twitter or other popular websites. 46 00:05:18,570 --> 00:05:25,450 And whilst the login aspect. So when you type in a username and password was encrypted, typically the session identifier was not. 47 00:05:25,970 --> 00:05:31,530 And so by listening for those being transmitted on the WiFi, you could then take control of someone's Facebook or Twitter account. 48 00:05:33,850 --> 00:05:36,970 Again, another major event was Edward Snowden and the Snowden leaks, 49 00:05:37,330 --> 00:05:46,130 demonstrating that various governments were listening at scale to network communication, and that really together encouraged the uptake of TLS. 50 00:05:47,970 --> 00:05:49,690 So here is some data from Google. 51 00:05:50,090 --> 00:05:58,470 Looking at percentage of page loads over Https in Chrome so those users want to share some statistical data with Google. 52 00:05:58,950 --> 00:06:04,590 And you can see we've gone from a position about 2016 of 30 to 50% of traffic 53 00:06:04,950 --> 00:06:09,950 being encrypted to between 85 and 100% of traffic being encrypted by 2026. 54 00:06:14,070 --> 00:06:17,670 We've also seen end to end encryption becomes standard in messaging, so WhatsApp, 55 00:06:18,590 --> 00:06:23,910 Apple iMessage and also signal amongst others now offer encryption on their service. 56 00:06:24,510 --> 00:06:28,990 And the difference between this and the web is that information is now encrypted fully end to end. 57 00:06:29,430 --> 00:06:34,430 So the only people who can read the message are the sender and the recipients and the web model. 58 00:06:34,710 --> 00:06:36,790 Of course, the server also can see that communication, 59 00:06:38,070 --> 00:06:44,070 and this has then come to be used for synchronising passwords between devices and increasingly other services too. 60 00:06:46,110 --> 00:06:53,630 Apple recently introduced advanced data protection for iCloud, and this offers then end to end encryption for notes, photo sharing, 61 00:06:54,030 --> 00:06:58,660 etc. When you're sharing information with other users who also have enabled advanced data protection, 62 00:06:59,820 --> 00:07:04,660 and notably, there are ongoing legal proceedings between the UK Government and Apple over the deployment of ADP. 63 00:07:05,540 --> 00:07:11,460 The UK government demands that Apple continues to provide access to iCloud data even when this feature is turned on, 64 00:07:11,900 --> 00:07:15,500 which of course goes against the very principle and the reason for deploying it in the first case. 65 00:07:16,340 --> 00:07:21,420 So currently Apple has withdrawn ADP from the UK while that legal case proceeds. 66 00:07:24,300 --> 00:07:28,100 So we've talked really about confidentiality integrity and authenticity here. 67 00:07:28,460 --> 00:07:36,060 But what about the anonymity piece. And largely we don't have a huge amount of anonymity in terms of who's talking to who on the internet. 68 00:07:37,060 --> 00:07:39,900 They're probably the biggest counterexample to this is Tor, 69 00:07:40,660 --> 00:07:47,220 which offers a mechanism to prevent a local network based adversary from T who you're talking to. 70 00:07:48,020 --> 00:07:56,400 So Tor works on the basis that you install a special piece of software on your machine, like the Tor browser, and through that your computer. 71 00:07:56,800 --> 00:08:04,520 Then get a list of nodes in the tour network, and your computer can then choose some nodes in that network to communicate with. 72 00:08:04,920 --> 00:08:10,120 So might, for example, pick one node at random to start off with, create an encrypted connection to it. 73 00:08:10,800 --> 00:08:15,560 Through that encrypted connection, connect to a second, and through that connection connect to a third. 74 00:08:16,120 --> 00:08:24,240 And in doing so, you've got this hierarchical set of tunnels that prevent any local adversary from seeing who is talking with who. 75 00:08:25,800 --> 00:08:29,040 Tor, however, doesn't protect against a kind of global adversary. 76 00:08:29,840 --> 00:08:36,160 So if you've got, for example, anonymity network here A is sending out more packets or perhaps different size packets. 77 00:08:37,600 --> 00:08:42,880 You can then analyse this setting and conclude that a must be talking with C rather than B. 78 00:08:43,800 --> 00:08:49,800 And so whilst Tor doesn't prevent this kind of attack, there are other systems at which which do. 79 00:08:52,280 --> 00:08:56,910 Let's talk about a particular individual case now. So this is a reality winner. 80 00:08:57,750 --> 00:09:06,430 And she was a US Air Force veteran and former NSA translator and at the time of this case was a contractor working for Pluribus International. 81 00:09:08,110 --> 00:09:14,870 And she was convicted of leaking a report, a secret report on Russia's intent to influence the US election. 82 00:09:16,470 --> 00:09:23,550 The report suggested that the Russian hackers were using email phishing campaigns to access US voter registration records, and when, 83 00:09:23,790 --> 00:09:30,750 as stated on CBS 60 minutes, that she leaked the material because she thought Americans were being misled about Russia's intention. 84 00:09:33,390 --> 00:09:43,110 So how was she found out? Well, metadata and secret communications were used to identify her as a source. 85 00:09:43,990 --> 00:09:53,790 So a news organisation, The Intercept, received an anonymous copy of this report by postal mail and the 30th of September of May 2017, 86 00:09:54,530 --> 00:09:58,810 The Intercept sent a copy of that report to the NSA, and in some ways, 87 00:09:59,730 --> 00:10:04,610 verifying whether a source is true or not is an important thing that journalists do. 88 00:10:05,050 --> 00:10:09,810 In this case, here, arguably sending an actual copy of the report was probably a mistake, 89 00:10:11,170 --> 00:10:15,610 and by the 3rd of June, the FBI had obtained a warrant to search winners electronic devices. 90 00:10:16,050 --> 00:10:20,450 So the action in response to this revelation was very swift. 91 00:10:21,770 --> 00:10:28,770 And later on, it's been suggested that both email correspondence and unique features of the printout may have been used to identify a winner. 92 00:10:29,610 --> 00:10:36,210 So winner was apparently one of only six workers who had access to the report, and only she had sent a personal email. 93 00:10:36,890 --> 00:10:39,290 Not necessarily on this topic to The Intercept. 94 00:10:41,490 --> 00:10:49,450 Secondly, the printout itself was perhaps printed on a colour laser printer and therefore may well have contained a unique device fingerprint. 95 00:10:50,690 --> 00:10:57,400 So Xerox obtained a printer, a patent in the 1980s for including a tracking number in colour printouts. 96 00:10:58,400 --> 00:11:03,200 Motivated by the idea that high quality colour printers may be used to produce counterfeit money, 97 00:11:03,840 --> 00:11:10,400 and the EFF claimed in 2015 that all major manufacturers of colour phrase print outs now include some form of tracking information, 98 00:11:11,560 --> 00:11:12,800 so you can see an example here. 99 00:11:13,520 --> 00:11:21,400 Encoding the serial number of the printer, as well as the time and date of printing in normally almost invisible yellow dots. 100 00:11:24,000 --> 00:11:34,160 So we've seen over this 2030 year period significant advances in the use of technology to provide secret communication. 101 00:11:35,520 --> 00:11:42,280 And one of the critiques of this is from the security services and law enforcement is that they're so-called going dark. 102 00:11:43,040 --> 00:11:46,640 In other words, encryption prevents them from doing their job. 103 00:11:47,480 --> 00:11:54,060 Meanwhile, civil liberties campaigners view this as a positive as it requires due process and protects user privacy. 104 00:11:55,340 --> 00:11:58,620 So I'm going to return to that topic overall. Later on in the lecture. 105 00:11:59,220 --> 00:12:04,900 But I want to now take a bit of time talking about a particular system that we worked on and built to frame that debate. 106 00:12:07,340 --> 00:12:15,300 So I've spent a fair amount of time over the last decade working with journalists and news organisations and computer security issues that they face. 107 00:12:16,500 --> 00:12:23,100 And in a functioning democracy, and the free press plays a vital role in how holding powerful institutions to account. 108 00:12:24,420 --> 00:12:30,940 So for journalism really thrive, however, citizens need a way of communicating and contacting reporters securely, 109 00:12:32,260 --> 00:12:34,780 especially when revealing sensitive or controversial information. 110 00:12:35,780 --> 00:12:40,140 And this is particularly, of course, challenging in an era of significant surveillance. 111 00:12:42,020 --> 00:12:46,060 Now, this is something that is understood widely to be important, in fact, in the UK. 112 00:12:46,660 --> 00:12:51,890 Whereas even an Act of Parliament protecting the disclosure in the public interest. 113 00:12:52,730 --> 00:12:59,370 So if you're a worker who reasonably believes that a criminal offence has taken place or there's been a breach of a legal obligation, 114 00:13:00,250 --> 00:13:05,650 then disclosure is protected. If the disclosure is in a public interest and means certain other tests. 115 00:13:07,490 --> 00:13:13,410 So in exploring this topic about how we could help journalists, we ran some workshops, 116 00:13:14,810 --> 00:13:24,490 and the first workshop we ran in 2019 was displaying some potential technology that we thought might be useful for journalism to over 117 00:13:24,650 --> 00:13:31,650 20 journalists and information security experts that worked in news organisations and used that to identify some reoccurring themes. 118 00:13:33,770 --> 00:13:38,130 One particular idea, which became Cover Drop, was seen as particularly valuable, 119 00:13:38,810 --> 00:13:41,970 and how the second workshop with more journalists, software engineers, 120 00:13:42,530 --> 00:13:51,590 system administrators and security experts in a news organisation to validate those themes and start to sketch out what might be a good design. 121 00:13:53,590 --> 00:13:57,910 These revealed a number of themes that we thought were important. Here are a couple. 122 00:13:58,310 --> 00:14:02,670 So the first is like we saw with PGP. Usability is seen as really key. 123 00:14:03,190 --> 00:14:07,030 How do we make sure that the average user can use this easily and securely? 124 00:14:08,830 --> 00:14:14,070 The second one was that they wanted a means of communication that was a relatively low in latency, 125 00:14:14,950 --> 00:14:18,390 allowed some interaction with the user, and that's because at the time, 126 00:14:19,150 --> 00:14:22,030 another technology secure drop, which is being used by a number of news organisations, 127 00:14:22,710 --> 00:14:27,310 was seen as very high latency, one that required a lot of extra work. 128 00:14:28,590 --> 00:14:30,310 Now, so teardrop has improved since this point. 129 00:14:30,630 --> 00:14:35,270 And in any case, I think what we're trying to do and what secure Drop are trying to do are solving slightly different problems. 130 00:14:38,030 --> 00:14:43,190 So given that existing systems for securely protecting whistleblowers were seen to be hard to use, 131 00:14:43,750 --> 00:14:50,620 we wanted to try and focus on making that easier and we wanted to work on the so-called initial contact problem. 132 00:14:51,100 --> 00:14:57,500 In other words, if you have something that you want to contact a journalist or a news organisation about, you never got in touch with them before. 133 00:14:58,220 --> 00:15:00,980 How do we make that as easy and as secure as possible? 134 00:15:02,380 --> 00:15:09,100 We also wanted to try and avoid the use of bespoke software, because this inevitably makes users stand out of the crowd. 135 00:15:11,620 --> 00:15:15,540 So we came up with this idea called Cover Drop to support initial contact, 136 00:15:16,260 --> 00:15:20,740 and we did that by integrating those features inside an existing news app itself. 137 00:15:22,300 --> 00:15:29,300 And by this, focusing on initial contact enabled us to reduce the set of features that required something that was buildable. 138 00:15:30,620 --> 00:15:37,220 And by using an existing news app, we've got a very large number of users who are using that app every day. 139 00:15:37,460 --> 00:15:43,300 And we provide, therefore, a lot of plausible deniability about whether you, in fact, have used this feature at all. 140 00:15:45,300 --> 00:15:47,120 So what assumptions did we make? 141 00:15:47,960 --> 00:15:58,960 Well, we wanted not to assume that cloud providers or Https or certificate authorities were working correctly and may be compromised. 142 00:16:00,680 --> 00:16:07,560 We wanted to assume that the adversary might be able to observe or record or modify internet traffic, and to do so at scale. 143 00:16:08,960 --> 00:16:13,400 And we wanted also to assume that the smartphone itself might be captured. 144 00:16:15,960 --> 00:16:23,440 We did assume, however, that the news organisation itself is able to run a server in a physically secure location like their head offices, 145 00:16:25,000 --> 00:16:30,520 that smartphones are not compromised by root level malware, so we can trust the runtime of the smartphone itself. 146 00:16:32,360 --> 00:16:38,800 And we assumed that the standard cryptographic algorithms do indeed provide the features they claim to provide. 147 00:16:41,040 --> 00:16:45,870 So what did the design look like? So here's a sort of a sketch of a simplified version of the design. 148 00:16:46,630 --> 00:16:51,630 So we have the news app on the left and the user is looking at, in this case perhaps a news article. 149 00:16:52,670 --> 00:16:57,870 And we have a cover node, which is a physical server inside the Guardian's offices. 150 00:16:58,510 --> 00:17:05,350 And then we have a journalist who has some device to receive messages. So the news app constantly, whether you're using this feature or not, 151 00:17:05,870 --> 00:17:11,790 periodically will emit a short encrypted message encrypted with a key that the cover node can decrypt. 152 00:17:12,830 --> 00:17:16,710 And inside the encrypted message typically is nothing. It's a so-called cover message. 153 00:17:17,390 --> 00:17:23,070 So these messages come out of the news app at regular intervals, regardless of whether you're using the cover drop feature. 154 00:17:24,750 --> 00:17:26,510 If the user wants to send a real message, 155 00:17:27,230 --> 00:17:34,470 then the user types in their message and we encrypt it using the key of the journalist so the message is end to end encrypted. 156 00:17:35,230 --> 00:17:40,710 Then we encrypt that message with the key of the cover node, and we don't send that message straight away. 157 00:17:41,430 --> 00:17:48,810 Instead, we hold on to the message until we would have sent our cover message and we replace that cover message with the real message. 158 00:17:49,490 --> 00:17:54,130 And so for the perspective of the network observer, they cannot tell the difference between cover and real messages. 159 00:17:54,890 --> 00:17:56,850 They can't tell the communications happening at all. 160 00:17:58,170 --> 00:18:02,810 Now at the cover node is receiving this constant stream of messages from many, many mobile devices. 161 00:18:03,890 --> 00:18:08,170 And so most of them, it can take the encryption off and see there's nothing there at all and can discard them. 162 00:18:09,290 --> 00:18:12,210 The real messages, however, are still encrypted with a journalist device. 163 00:18:12,610 --> 00:18:21,010 Key are can be distinguished and those are put to one side, and periodically the cover node can then collect together all of the real messages. 164 00:18:22,010 --> 00:18:31,090 Add on to that list some other fake messages needed so it can publish a dead drop to a cloud service, and the journalist device can download it. 165 00:18:32,050 --> 00:18:36,010 So once downloaded, the journalist device can attempt to decrypt each of the messages inside the dead drop, 166 00:18:36,570 --> 00:18:41,050 find the ones for it, and display them to the user. So in both these parts of this communication, 167 00:18:42,330 --> 00:18:48,080 the number of messages sent and when they're sent is not connected at all with whether any real communication is taking place. 168 00:18:50,200 --> 00:18:56,120 And of course, we can use the same technique to send messages from the journalist's device back through to the user in the other direction. 169 00:18:58,480 --> 00:19:05,600 So we published this design along with some of the details about how it worked in a Petts paper in 2022. 170 00:19:07,360 --> 00:19:13,320 And after doing so, the Guardian was like, hey, this looks really interesting, let's actually build this. 171 00:19:14,120 --> 00:19:17,360 And we all agreed optimistically that it shouldn't take more than a few months. 172 00:19:18,920 --> 00:19:28,440 It took three years. And really key to this process was Daniel Roth, who was the linchpin in all of this spending for many, 173 00:19:29,040 --> 00:19:34,360 most of the time a day, a week at the Guardian's offices, collaborating with them and helping them on the implementation, 174 00:19:35,160 --> 00:19:40,320 and then bring you back some of the most thorny, difficult research problems back to us to try and solve. 175 00:19:42,560 --> 00:19:47,820 So for about a just over a year now, the Guardian has been running a service called Secure Messaging. 176 00:19:48,420 --> 00:19:52,940 And this is embedded in activated in every Guardian app, whether on iOS or Android. 177 00:19:53,580 --> 00:19:57,820 So there are probably, perhaps dozens of you in this room that are using this technology. 178 00:19:58,940 --> 00:20:02,500 Perhaps unwittingly, it sends cover traffic to protect metadata, 179 00:20:03,220 --> 00:20:08,020 a real whistleblower messages alongside along the lines I've described in the overview. 180 00:20:09,540 --> 00:20:13,620 And therefore there is a very large number of users who are providing a large anonymity 181 00:20:14,100 --> 00:20:17,500 set and protecting the identity of anyone who uses this for real communication. 182 00:20:19,220 --> 00:20:22,660 As a result, there is strong plausible deniability for news sources. 183 00:20:24,300 --> 00:20:28,300 So, to give you a sense of what this looks like, let's have a quick walkthrough and how it works. 184 00:20:29,020 --> 00:20:36,300 So first of all, of course you've got to find the uh, this feature. 185 00:20:37,100 --> 00:20:45,930 So if you go to the Guardian com tips you go to this web page and it suggests the thing to use is secure messaging as the way in. 186 00:20:46,050 --> 00:20:48,650 Getting in touch with the Guardian. Step one download the app. 187 00:20:49,170 --> 00:20:52,930 Step two find the secure messaging feature in the menu and then follow the instructions. 188 00:20:55,370 --> 00:20:59,690 So let's have a look at how that works in practice. So you go and find the main menu. 189 00:21:00,130 --> 00:21:06,090 Scroll down to Secure Messaging. Select that option and then you get presented with a different screen. 190 00:21:06,450 --> 00:21:13,370 And you click on Get Started. And you're asked whether you would like to start a new conversation with a journalist. 191 00:21:14,450 --> 00:21:16,850 And you get a little bit of guidance on what actually happens. 192 00:21:18,050 --> 00:21:25,250 And when you've read that, you're then presented with three English words as a passphrase that you need to remember. 193 00:21:25,810 --> 00:21:34,290 So here the passphrase is banana, water and strawberry. You then asked to type those three words back in again to check you out for them, 194 00:21:34,730 --> 00:21:39,010 and perhaps encourage you to think about perhaps writing them down somewhere securely so you don't forget them. 195 00:21:40,130 --> 00:21:43,910 You can then confirm the passphrase and you get the opportunity to then send a message. 196 00:21:44,830 --> 00:21:47,390 So first of all, you choose who you would like to send you a message to. 197 00:21:47,670 --> 00:21:52,710 So you can choose a team or a journalist individually and select the recipient. 198 00:21:54,510 --> 00:21:58,070 This under the hood, then chooses the appropriate cryptographic key material needed to send the message. 199 00:21:58,910 --> 00:22:02,310 There's also some documentation that describes what a good message looks like. 200 00:22:03,310 --> 00:22:06,150 And it turns out that users do really read that documentation, 201 00:22:06,830 --> 00:22:11,670 and the quality of the messages the Guardian are receiving have improved dramatically as a result of that. 202 00:22:12,750 --> 00:22:17,870 So these then types their message into this box, much like sending a message through a messaging platform. 203 00:22:18,830 --> 00:22:30,430 And when they're finished typing, they can click send a message. You're then presented with a brief form that shows you what happens next, 204 00:22:30,870 --> 00:22:33,870 reminding you that you will need to check back at some point later for messages. 205 00:22:35,070 --> 00:22:38,310 If you go and look at the chat at this point, you'll see the message is marked as pending. 206 00:22:39,110 --> 00:22:42,020 So because we're waiting for that next slot when we would have sent a cover message. 207 00:22:42,580 --> 00:22:47,900 The message is held back until that covered message would have been sent. The user can then leave this part of the application. 208 00:22:48,940 --> 00:22:53,140 Use the Guardian app as normal, or indeed use their phone and other apps as normal as they wish. 209 00:22:53,940 --> 00:22:59,940 At some point later, they can come back. I click on Check Message Vault and here they have to type in those three words from before. 210 00:23:01,100 --> 00:23:04,340 So in this case the user mistypes banana water water. 211 00:23:05,500 --> 00:23:10,700 And we know that's not the right passphrase. So we can tell them this. I can then type in strawberry. 212 00:23:11,500 --> 00:23:17,740 And this particular case they made the mistake of misspelling strawberry. We know what the words are so we can highlight that. 213 00:23:18,620 --> 00:23:24,620 Um there's a typo in the word strawberry. And then if typed incorrectly, the message vault unlocks. 214 00:23:25,620 --> 00:23:31,900 They can go back to their chat with the UK business team, and then they can see that a message was both sent and they've now received a reply. 215 00:23:33,380 --> 00:23:40,160 And just like a normal text message application, they can then compose a response and send that off to the journalist. 216 00:23:43,040 --> 00:23:46,080 From the journalist perspective, they have a slightly different interface. 217 00:23:46,960 --> 00:23:54,600 So they have a laptop or desktop interface that allows them to have a communication with multiple different individuals at the same time. 218 00:23:56,080 --> 00:23:59,360 In this case here, we don't know initially who the sender of the message is. 219 00:23:59,600 --> 00:24:03,320 And so a pseudonym is automatically created in this case secret koala, 220 00:24:04,600 --> 00:24:08,760 just to give the journalist some kind of name or handle to think about the conversation that they're having. 221 00:24:09,880 --> 00:24:13,760 And the interface works. As you might expect, you can send and receive messages with it. 222 00:24:15,640 --> 00:24:17,880 So when I gave that initial simplified design, 223 00:24:18,360 --> 00:24:24,760 our kind of naive mental model of how this might work is we're to have some unknown online on premises server, 224 00:24:25,320 --> 00:24:30,240 like have a node, some cloud service to store the dead drops and all the good, all is good. 225 00:24:31,440 --> 00:24:34,480 In reality, we ended up with a much more complicated design. 226 00:24:35,200 --> 00:24:38,520 So news organisation is typically user content delivery network. 227 00:24:39,150 --> 00:24:42,030 So the app is going to talk first of all to that. 228 00:24:42,870 --> 00:24:51,430 We also introduced a cloud based buffer to be able to store messages in case the cover node was unavailable, perhaps for update or servicing. 229 00:24:52,710 --> 00:25:01,630 And we also then made use of an API service in the in the cloud and a database direct to store for example, those dead drops. 230 00:25:03,670 --> 00:25:07,710 This can then be requested through the CDN and available on journalists devices. 231 00:25:09,350 --> 00:25:14,950 A similar kind of path runs in reverse only in this case, the journalists requests are routed via the API service first. 232 00:25:15,590 --> 00:25:21,230 And that's because we want to ensure that the journalists are real, legitimate journalists. 233 00:25:21,790 --> 00:25:26,190 And so one party in every communication is a journalist working at the Guardian. 234 00:25:27,510 --> 00:25:31,830 And then the path is similar as before through the Kinesis stream into the cover node, 235 00:25:32,190 --> 00:25:36,310 back through the API service and then downloaded, ultimately in the dead drop to the users. 236 00:25:38,070 --> 00:25:42,450 We also needed an identity service to manage the key material for this system. 237 00:25:43,290 --> 00:25:51,730 And its a hierarchical key system where there is a root signing key, which is used to sign all the other more temporary keys used in the system. 238 00:25:52,490 --> 00:25:56,250 And that root key is kept on an air gapped device offline. 239 00:25:57,410 --> 00:26:02,570 And then of course, there's all the logging and metrics you need to run any modern online web service as well. 240 00:26:04,370 --> 00:26:10,650 So in terms of what's trusted, all the stuff in the cloud is only required for availability. 241 00:26:11,450 --> 00:26:14,850 We don't place any other trust in those components of the system, 242 00:26:15,450 --> 00:26:19,370 but we do require both the users and journalists devices not to have root level malware. 243 00:26:19,930 --> 00:26:24,610 And for the cover node, identity service and aircraft device to be secure. 244 00:26:26,610 --> 00:26:29,690 Now, given we're not using a certificate authority based mechanism, you might ask, 245 00:26:29,850 --> 00:26:32,690 well, how do we know that we've got the right set of keys or key material? 246 00:26:33,810 --> 00:26:38,240 And a cute trick that we came up with to try and establish trust in that route. 247 00:26:38,440 --> 00:26:43,120 Key for certainly advanced users is we simply print it in the Guardian newspaper. 248 00:26:43,880 --> 00:26:47,200 So if you open the Guardian newspaper, on the first inside page, 249 00:26:47,520 --> 00:26:52,360 you'll see a digest of the secure messaging keys that are in use by the platform at the moment. 250 00:26:55,000 --> 00:26:59,600 So what else do we learn by this collaboration with the Guardian? 251 00:27:00,720 --> 00:27:07,560 Well, we also learnt that we need to think much more carefully about how we provide encrypted storage on the device. 252 00:27:08,200 --> 00:27:13,600 We want to be able to provide plausible deniability that this feature has been used, even if you've got access to the phone. 253 00:27:14,680 --> 00:27:21,600 So when the app is first installed, it automatically creates a message vault with three random words and encrypts it, 254 00:27:21,680 --> 00:27:26,400 inputs it on the device, and that means everyone's phone has an encrypted message store on it. 255 00:27:28,280 --> 00:27:31,480 Secondly, as we described, all users send these encrypted and padded messages, 256 00:27:31,880 --> 00:27:35,280 so that provides plausible deniability for anyone looking at network communication. 257 00:27:37,500 --> 00:27:44,020 And finally, Daniel and colleagues at The Guardian spent a lot of time thinking carefully about the software engineering architecture of the app. 258 00:27:44,620 --> 00:27:49,620 To split out the security critical features into a core and then placing less trust in the UI. 259 00:27:51,820 --> 00:28:00,380 We also had to think pretty carefully about data usage and how much power this, uh, or battery drawer this feature is going to consume. 260 00:28:01,900 --> 00:28:09,220 And therefore, for example, carefully scheduling background jobs as this ended up in us doing some more research work, 261 00:28:09,660 --> 00:28:15,460 including building this lovely, funky bit of custom hardware to try and measure a power consumption of devices. 262 00:28:16,300 --> 00:28:24,220 And this work allowed us to establish that secure messaging uses less than 0.1% of daily battery usage on most devices. 263 00:28:27,260 --> 00:28:36,050 We also wanted to allow users to only have to use three common English words as their passphrase to make the system more usable. 264 00:28:37,170 --> 00:28:39,890 And if we were to do that naively, we would have a problem. 265 00:28:40,290 --> 00:28:48,290 And that's because an adversary could copy off the phone that encrypted message vault, put it on tens or hundreds or thousands of machines, 266 00:28:48,810 --> 00:28:55,690 and try lots of different combinations of those three words in parallel, finding out the passphrase very quickly and pretty cheaply. 267 00:28:57,530 --> 00:29:03,370 So instead, what we did is made use of a secure element on mobile devices. 268 00:29:03,890 --> 00:29:06,770 So many mobile devices now include a special piece of hardware. 269 00:29:07,410 --> 00:29:17,130 It's got its own CPU and own memory and storage for performing cryptographic operations, and they provide for different important services. 270 00:29:17,770 --> 00:29:22,890 So they protect the secure element from physical attacks and tampering. 271 00:29:23,930 --> 00:29:30,490 They can they can generate and store keys internally within their own architecture and perform cryptographic operations with them. 272 00:29:31,330 --> 00:29:36,590 They've got authentication counters, which limit the number of times you can carry out a particular action. 273 00:29:37,470 --> 00:29:42,630 And you also have can enforce timeouts, so limiting the rate at which you can perform particular operations. 274 00:29:44,310 --> 00:29:47,910 Now it turns out that if you're the operating system, you can use all four of these. 275 00:29:48,750 --> 00:29:53,190 If you're a normal application, you only get access or the availability of two of them. 276 00:29:54,150 --> 00:30:00,510 So our task was, can we use the internal key generation feature in cryptographic operations to get some 277 00:30:00,750 --> 00:30:05,470 kind of timeout feature to rate limit the rate at which you're getting passwords? 278 00:30:06,830 --> 00:30:08,430 And it turns out yes we can. 279 00:30:08,790 --> 00:30:15,870 So we can make use of the fact that encryption takes a certain amount of time to run on this platform to give us a time, a timer effectively. 280 00:30:16,590 --> 00:30:19,830 So for example, here is the data for elliptic curve Diffie-Hellman on iOS. 281 00:30:20,430 --> 00:30:26,870 And you can see the operation duration. Whilst over a range of times is a relatively narrow band. 282 00:30:27,510 --> 00:30:33,510 And so by mixing together the three words with an internally held cryptographic key and repeating 283 00:30:34,100 --> 00:30:38,820 encryption a number of times to generate the key used to encrypt or decrypt the message vault. 284 00:30:39,300 --> 00:30:45,940 We can enforce two properties. Firstly, that you have to make the password guess through that particular piece of hardware. 285 00:30:46,740 --> 00:30:49,340 Copying the message vault off the device doesn't help. 286 00:30:50,620 --> 00:30:56,700 And secondly, therefore we can rate limit the the amount of time we can spend guessing passwords. 287 00:30:58,020 --> 00:31:04,620 So that means that we can have a three word passphrase from the f word list, which is about 38 bits. 288 00:31:05,340 --> 00:31:12,780 We can make every attempt take at least 100 milliseconds, and therefore take 800 years before you've guessed the password for the message vault. 289 00:31:14,060 --> 00:31:18,740 And so if you want this feature, you can find out more about it in this academic paper. 290 00:31:19,780 --> 00:31:23,660 And there's also an open source implementation that you can use as well. 291 00:31:24,580 --> 00:31:27,580 And this is the implementation that's used inside the Guardian app. 292 00:31:29,780 --> 00:31:32,740 So this was many many years of work. 293 00:31:33,680 --> 00:31:39,880 We, of course got distracted with other exciting projects along the way, but nevertheless, there was a lot of effort doing this. 294 00:31:40,440 --> 00:31:44,160 So we had the workshops in 2019 and we had a bit of Covid. 295 00:31:44,960 --> 00:31:50,600 We had then the cover drop paper coming out and sent off for publication and then finally published in 2022, 296 00:31:51,640 --> 00:31:54,040 and we started that development work with The Guardian. 297 00:31:55,080 --> 00:32:02,240 Over this period, we also published a white paper and got academics and others to review the design that we were constructing. 298 00:32:03,320 --> 00:32:06,920 And we also had an audit from the Open Technology Fund as well. 299 00:32:07,520 --> 00:32:12,680 And in that development work, we realised we needed these other systems to be built. 300 00:32:12,960 --> 00:32:17,280 We needed to understand the power required on those for for this kind of system. 301 00:32:17,720 --> 00:32:20,960 And we needed this key stretching approach with sloth. 302 00:32:22,640 --> 00:32:33,830 So we finally launched in June 2025. So there's a website coverage org where you can find out more about this system. 303 00:32:34,750 --> 00:32:42,030 You can go and read the original research paper, read the white paper, and also all of the source code for implementing the system. 304 00:32:42,270 --> 00:32:44,150 And the news organisation is also open. 305 00:32:44,830 --> 00:32:49,990 So if you're a news organisation or you're just interested, you can go and read the source code for this system as well. 306 00:32:52,510 --> 00:32:55,710 So I want to return to this topic now of going dark. 307 00:32:56,830 --> 00:33:04,230 So what options are there? As we see more and more of our online computer communications being encrypted? 308 00:33:05,430 --> 00:33:12,870 Well, the community has spent some time, along with governments trying to propose solutions, and I'm going to run through three of them now. 309 00:33:13,350 --> 00:33:22,550 And unfortunately, I don't think any of them are particularly usable. So the first proposal was to use so-called key escrow or exceptional access. 310 00:33:23,590 --> 00:33:29,390 So the idea here is to build a system which, in addition to working in the usual secure manner, 311 00:33:29,870 --> 00:33:36,570 has some kind of master key or some exceptional access which allows the good folk to access data. 312 00:33:38,610 --> 00:33:44,410 I think this is not sensible, and that's because if this method or this key master key is discovered, 313 00:33:45,170 --> 00:33:49,050 that means bad actors can then of course, compromise the security of the entire system. 314 00:33:50,850 --> 00:33:55,010 It is similarly also, unfortunately not true that the good folk are always good. 315 00:33:55,890 --> 00:33:57,450 And so, as seen in this quote, 316 00:33:57,770 --> 00:34:05,250 here are police officers and employees misusing access to the police database now account for over half of all cybercrime prosecutions in the UK. 317 00:34:06,850 --> 00:34:09,730 This is not to say that all police officers are bad. Far from it. 318 00:34:10,010 --> 00:34:14,850 The vast majority are good and hard working, but unfortunately this isn't universally the case. 319 00:34:17,610 --> 00:34:20,250 The second proposed solution is so-called client side scanning. 320 00:34:21,050 --> 00:34:26,610 So rather than coming up with a way to break the communication security directly instead, 321 00:34:27,330 --> 00:34:33,440 this proposal suggests that we simply ask one end of the encrypted conversation to look at the messages once they're decrypted. 322 00:34:34,280 --> 00:34:38,840 So, for example, maybe you look for illegal content such as child sexual abuse imagery. 323 00:34:40,120 --> 00:34:45,080 So if such content is found, this can then be reported to the appropriate authorities and some action then taken. 324 00:34:46,480 --> 00:34:52,160 This too has a number of serious weaknesses. There is, first of all, a potential for scope creep. 325 00:34:52,720 --> 00:34:59,480 So what started as a focus on perhaps clear cases of what we might as a society think as particularly abhorrent, such as child sexual abuse. 326 00:34:59,720 --> 00:35:06,040 Imagery could then be used as a tool, for example, to suppress or monitor political dissent. 327 00:35:07,200 --> 00:35:12,680 And the very nature of this kind of system is one that is opaque and is hard to track what exactly it is that it does. 328 00:35:14,400 --> 00:35:17,080 The second challenge is that the limits in accuracy of machine learning techniques 329 00:35:17,600 --> 00:35:21,800 means that it's likely that we'll see lots of false positives with this kind of system, 330 00:35:22,400 --> 00:35:28,400 because the number of messages that are innocent far, far exceeds the number of messages that are of concern. 331 00:35:29,320 --> 00:35:33,260 And so this can lead to many people having unwanted intrusion in their lives. 332 00:35:33,500 --> 00:35:40,420 So having done ultimately nothing wrong. And finally, the system that turns our own devices seems to be turn them against us. 333 00:35:40,820 --> 00:35:45,420 Right. And so this feels like a bad thing to do. 334 00:35:48,020 --> 00:35:52,980 The third proposed solution is so-called a lawful hacking or target endpoint exploitation. 335 00:35:54,260 --> 00:36:03,460 So in this setting, law enforcement are empowered to hack into devices either locally or remotely and to obtain access to information. 336 00:36:05,060 --> 00:36:08,380 So the technology for this could be supplied by a security service. 337 00:36:08,780 --> 00:36:15,820 Or maybe it's obtained with a contract to a commercial provider such as Cell Brite or NSO Group's Pegasus system. 338 00:36:17,220 --> 00:36:20,900 And this approach is interesting in the sense that it sets up some kind of natural equilibrium. 339 00:36:22,220 --> 00:36:29,570 So these systems to work, of course, need to know about some undisclosed vulnerabilities or flaw in the software that is being run. 340 00:36:30,650 --> 00:36:37,850 And yet every time you use that flaw to hack into a computer, there is some risk that that flaw or vulnerability is discovered. 341 00:36:38,530 --> 00:36:44,130 And if so, the manufacturer may then fix it, right? So there's a rate at which you have to find vulnerabilities, 342 00:36:45,370 --> 00:36:49,610 and a rate at which these vulnerabilities is then being sort of discovered or disclosed and getting fixed. 343 00:36:50,090 --> 00:36:52,570 And therefore there's a rate at which you can actually infect devices. 344 00:36:53,570 --> 00:36:58,650 If you start infected too many devices, all of your back catalogue vulnerabilities get found out. 345 00:36:59,010 --> 00:37:02,130 And suddenly that technology doesn't work for you anymore, at least for a period. 346 00:37:03,130 --> 00:37:07,690 So consequently, this system has a sort of limit, if you like, on the number of devices that can be targeted, 347 00:37:08,450 --> 00:37:12,970 which is perhaps nice if your aim is to limit government surveillance to only the most serious crimes. 348 00:37:14,170 --> 00:37:18,730 Assuming, of course, the tool is used to tackle those crimes that society think are the most worrisome. 349 00:37:21,090 --> 00:37:23,930 This system, of course, unfortunately, still has downsides in that. 350 00:37:24,850 --> 00:37:33,350 That means now there is an incentive for these agencies to hold on to otherwise undisclosed vulnerabilities, making all of our systems less secure. 351 00:37:34,950 --> 00:37:37,150 Systems that could have been patched are then not patched. 352 00:37:38,470 --> 00:37:44,990 Worse, some of those vulnerabilities that are being held on to may then be discovered or obtained. 353 00:37:45,630 --> 00:37:51,390 So, for example, NSO Group develops something called eternal blue, which was an exploiting a bug in windows. 354 00:37:52,470 --> 00:37:56,670 But they didn't report this to Microsoft. And it kept kept this bug for themselves. 355 00:37:57,710 --> 00:38:03,190 Unfortunately, this eternal blue approach was stolen from the NSA by the Shadow Brokers, 356 00:38:03,710 --> 00:38:12,390 and this exploit was subsequently used to build the WannaCry WannaCry ransomware, which itself had a devastating impact on the NHS in 2017. 357 00:38:13,870 --> 00:38:18,270 So there were also downsides outside of this setup. 358 00:38:21,510 --> 00:38:27,420 So when we think about this going dark question, we have to ask ourselves, how do we try and manage this as a society. 359 00:38:28,780 --> 00:38:35,860 I think the first point to make is that whilst we have made lots of improvements improving in implementing secure communication, 360 00:38:37,060 --> 00:38:43,420 many, many of our systems are far, far from secure in what we might think of as a standard as measured by cover drop. 361 00:38:43,940 --> 00:38:51,460 So for example, email whilst being encrypted, perhaps between mail servers, is still stored in plaintext and available for access under warrant. 362 00:38:52,980 --> 00:39:01,580 And very few systems offer any sense of anonymity or metadata privacy, and therefore that might be an angle that law enforcement can use as well. 363 00:39:02,540 --> 00:39:05,260 And sometimes I would like to argue that friction is good. 364 00:39:05,660 --> 00:39:11,460 For example, we have developed the concept of warrants in order to limit the authority that particular entities have. 365 00:39:12,060 --> 00:39:17,580 And so whilst this system might not be the most efficient, we do want a system which is robust to abuse. 366 00:39:19,940 --> 00:39:28,320 As a final kind of comment. What about cover drop itself? I think the tool has many defensible all characteristics that mean it is a good thing. 367 00:39:29,160 --> 00:39:36,920 For example, one end of every communication is a journalist limiting the chance for use of the system by serious or organised crime, 368 00:39:37,560 --> 00:39:44,440 and also its aim, namely to support the operation of the free press, is something that every democracy needs to function. 369 00:39:46,160 --> 00:39:51,960 So I'd like to finish just by thanking the authors, the original research team, 370 00:39:52,440 --> 00:39:57,120 as well as those at the Guardian and contributors who worked on building the system. 371 00:39:57,800 --> 00:39:58,360 And finally, 372 00:39:58,800 --> 00:40:06,880 those supporters and reviewers who looked at the white paper and gave us feedback on the system as we built it alongside the funders Nokia, 373 00:40:07,160 --> 00:40:10,160 Bell Labs and the Open Technology Fund for supporting all of this research. 374 00:40:10,920 --> 00:40:11,360 Thank you very much.