1 00:00:00,390 --> 00:00:12,019 *preroll music* 2 00:00:12,019 --> 00:00:15,290 Herald: I’m really glad that you’re all here and that today 3 00:00:15,290 --> 00:00:19,350 I can introduce Joanna Rutkowska to you. 4 00:00:19,350 --> 00:00:25,000 She will be talking about reasonably trustworthy x86 systems. 5 00:00:25,000 --> 00:00:30,150 She’s the founder and leader of the Invisible Things Lab 6 00:00:30,150 --> 00:00:37,149 and also – that’s also something you all probably use – the Qubes OS project. 7 00:00:37,149 --> 00:00:41,600 She presented numerous attacks on Intel based systems and also 8 00:00:41,600 --> 00:00:46,829 virtualization systems. But today she will not only speak about the problems 9 00:00:46,829 --> 00:00:52,329 of those machines but will present some solutions to make them more secure. 10 00:00:52,329 --> 00:00:54,550 Give it up for Joanna Rutkowska! 11 00:00:54,550 --> 00:01:03,329 *applause* 12 00:01:03,329 --> 00:01:09,300 Joanna: Okay, so, let’s start with stating something obvious. 13 00:01:09,300 --> 00:01:14,210 Personal computers have become really the extensions of our brains. 14 00:01:14,210 --> 00:01:18,000 I think most of you will probably agree with that. 15 00:01:18,000 --> 00:01:21,159 Yet the problem is that they are insecure 16 00:01:21,159 --> 00:01:25,869 and untrustworthy, 17 00:01:25,869 --> 00:01:29,299 which personally bothers me al lot. 18 00:01:29,299 --> 00:01:32,250 And here I want to make a quick digression 19 00:01:32,250 --> 00:01:38,149 for the vocabulary I’m gonna be using during this presentation. 20 00:01:38,149 --> 00:01:41,170 When we say, well, there are three adjectives related to trust 21 00:01:41,170 --> 00:01:45,140 and people will often confuse them. When we say something is “trusted”, 22 00:01:45,140 --> 00:01:49,740 that means by definition something can compromise the security of 23 00:01:49,740 --> 00:01:54,770 the whole system, which means we don’t like things to be trusted. 24 00:01:54,770 --> 00:02:00,329 “Trusted third party”, “Trusted CA” we don’t like that. 25 00:02:00,329 --> 00:02:02,320 When we say something is... 26 00:02:02,320 --> 00:02:06,500 because “trusted” doesn’t necessarily mean that it is “secure”. 27 00:02:06,500 --> 00:02:12,730 So, what is secure? Secure is something that is resistant to attacks. 28 00:02:12,730 --> 00:02:18,829 Perhaps this laptop might be resistant to attacks. 29 00:02:18,829 --> 00:02:22,610 If I open [an] email attachment and the email attachment compromises my system 30 00:02:22,610 --> 00:02:28,540 or maybe that if I plug USB for the slide changer 31 00:02:28,540 --> 00:02:33,700 I might be hoping that this action will not compromise 32 00:02:33,700 --> 00:02:37,159 my whole PC. 33 00:02:37,159 --> 00:02:40,999 And yet something can be secure but not trustworthy. 34 00:02:40,999 --> 00:02:45,360 A good example of this might be e. g. 35 00:02:45,360 --> 00:02:49,750 Intel Management Engine (ME), that I’m gonna be talking about more later. 36 00:02:49,750 --> 00:02:54,180 So it might be very resistant to attacks, so it might be a backdoor. 37 00:02:54,180 --> 00:02:57,180 A backdoor that is very resistant to attacks, 38 00:02:57,180 --> 00:03:02,480 yet it is not acting in the interests of the user. 39 00:03:02,480 --> 00:03:09,170 So it’s not “good”, whatever good means in your assumed, 40 00:03:09,170 --> 00:03:12,969 moral reference. 41 00:03:12,969 --> 00:03:18,750 So, there’s been of course a lot of work 42 00:03:18,750 --> 00:03:24,110 in the last 20 years and maybe more 43 00:03:24,110 --> 00:03:27,540 to build solutions that provide 44 00:03:27,540 --> 00:03:30,750 security and trustworthiness 45 00:03:30,750 --> 00:03:35,640 and most of this work has focused on the application layer and things like 46 00:03:35,640 --> 00:03:38,709 GnuPG and PGP first, 47 00:03:38,709 --> 00:03:45,490 TOR, all the secure communication protocols and programs. 48 00:03:45,490 --> 00:03:49,720 But of course, 49 00:03:49,720 --> 00:03:55,750 it is clear that any effort on the application level 50 00:03:55,750 --> 00:04:00,810 is just meaningless if we can not assure, if we can not trust 51 00:04:00,810 --> 00:04:06,579 our operating system (OS). Because the OS is the trusted part. 52 00:04:06,579 --> 00:04:12,680 So if the OS is compromised then everything is lost. 53 00:04:12,680 --> 00:04:18,260 And there has been some efforts, notably the project I started 5 years ago 54 00:04:18,260 --> 00:04:24,130 and now this is like more than a dozen of people working on it: Qubes OS. 55 00:04:24,130 --> 00:04:28,360 It tries to address the problem of OS’s 56 00:04:28,360 --> 00:04:32,230 being part of the PCB, so what we try to do is 57 00:04:32,230 --> 00:04:37,750 shrink the amount of trusted code to an absolute minimum. 58 00:04:37,750 --> 00:04:41,510 There’s been also other efforts in this area. 59 00:04:41,510 --> 00:04:46,730 But OS’s is not something I’m gonna be discussing today. 60 00:04:46,730 --> 00:04:54,250 What I’m gonna be discussing today is the final layer, is the hardware. 61 00:04:54,250 --> 00:05:00,700 Because what was OS to applications it is hardware to the OS. 62 00:05:00,700 --> 00:05:05,380 Again, most of the effort so far 63 00:05:05,380 --> 00:05:07,720 to create secure and trustworthy OS, 64 00:05:07,720 --> 00:05:14,000 they have always been assuming that the hardware is trusted. 65 00:05:14,000 --> 00:05:18,850 That means that... usually that means for most OS’s that 66 00:05:18,850 --> 00:05:24,100 a single malicious peripheral on this laptop, 67 00:05:24,100 --> 00:05:30,530 like a malicious Wi-Fi module or maybe embedded controller 68 00:05:30,530 --> 00:05:34,810 can compromise again my whole PC, 69 00:05:34,810 --> 00:05:39,340 my whole digital life. 70 00:05:39,340 --> 00:05:42,760 So what to do about it? 71 00:05:42,760 --> 00:05:46,500 Before we discuss what to do about it 72 00:05:46,500 --> 00:05:52,550 we should quickly 73 00:05:52,550 --> 00:05:59,050 recap all the problems with present PC platforms 74 00:05:59,050 --> 00:06:03,180 and specifically I’m gonna be focusing on x86 platform 75 00:06:03,180 --> 00:06:09,850 and specifically with Intel x86 platform, which means: laptops. 76 00:06:09,850 --> 00:06:17,340 This picture shows how a typical modern laptop looks like. 77 00:06:17,340 --> 00:06:23,160 You can see that it consists of 78 00:06:23,160 --> 00:06:28,260 a processor in the center, and then there is memory, 79 00:06:28,260 --> 00:06:32,120 some peripherals, keyboard and monitor. 80 00:06:32,120 --> 00:06:36,210 Very simple. 81 00:06:36,210 --> 00:06:41,060 It can be very simple, because 82 00:06:41,060 --> 00:06:47,250 if we look at present Intel processors 83 00:06:47,250 --> 00:06:53,130 they really integrate everything and the kitchen sink. 84 00:06:53,130 --> 00:07:00,300 Ten years ago we used to have a processor, a Northbridge, a Southbridge 85 00:07:00,300 --> 00:07:03,640 and perhaps even more discrete elements on the motherboard. 86 00:07:03,640 --> 00:07:11,830 Today nearly all these elements have been integrated into one processor package. 87 00:07:11,830 --> 00:07:13,780 This is Broadwell 88 00:07:13,780 --> 00:07:19,710 and this long element here is the CPU and GPU 89 00:07:19,710 --> 00:07:26,490 and the other one it is said to be the PCH. 90 00:07:26,490 --> 00:07:30,960 PCH is what used to be the platform controller hub, 91 00:07:30,960 --> 00:07:34,930 which is what used to be called the Southbridge and Northbridge. 92 00:07:34,930 --> 00:07:39,850 The line has somehow blurred between these. 93 00:07:39,850 --> 00:07:42,060 Of course there is only one company making these. 94 00:07:42,060 --> 00:07:46,050 It’s an American company called INTEL. 95 00:07:46,050 --> 00:07:51,410 It is a completely opaque construction. 96 00:07:51,410 --> 00:08:00,080 We have absolutely no ways to examine what’s inside. 97 00:08:00,080 --> 00:08:04,520 That obviously... The advantage is that 98 00:08:04,520 --> 00:08:09,030 it makes construction of computers, of laptops very easy now. 99 00:08:09,030 --> 00:08:13,410 And lots of vendors can produce little sexy laptops, 100 00:08:13,410 --> 00:08:17,510 like the one I have here. 101 00:08:17,510 --> 00:08:23,820 On this picture we see now some more elements that are in this processor. 102 00:08:23,820 --> 00:08:28,620 So, when you say processor today, it’s no longer CPU. 103 00:08:28,620 --> 00:08:34,470 Processor is now CPU, GPU, memory controller, hub, PCIe, 104 00:08:34,470 --> 00:08:38,800 root, some Southbridge, 105 00:08:38,800 --> 00:08:46,110 so e.g. SATA controller and so on, as well as something 106 00:08:46,110 --> 00:08:52,900 that is called Management Engine (ME), which we discuss in a moment. 107 00:08:52,900 --> 00:08:56,920 There are few more elements here that are important. 108 00:08:56,920 --> 00:09:02,270 The most important for us is the SPI flash element. 109 00:09:02,270 --> 00:09:07,780 Because what’s interesting is that with this whole integration 110 00:09:07,780 --> 00:09:11,960 that has happened to the processor and the other peripherals, 111 00:09:11,960 --> 00:09:15,640 still the storage for the firmware, 112 00:09:15,640 --> 00:09:21,550 so the storage where your BIOS as well as other firmware is stored, 113 00:09:21,550 --> 00:09:29,980 is still a discrete element. 114 00:09:29,980 --> 00:09:34,460 We’ll see this element in one of the next slides. 115 00:09:34,460 --> 00:09:39,280 So let’s now consider first 116 00:09:39,280 --> 00:09:46,080 the problem of boot security. 117 00:09:46,080 --> 00:09:49,960 Obviously everybody understands that boot security is something 118 00:09:49,960 --> 00:09:54,330 - how to start the chain of trust for whatever software 119 00:09:54,330 --> 00:10:03,370 is gonna be running later - is of a paramount importance. 120 00:10:03,370 --> 00:10:15,510 I think I’m out of range. 121 00:10:15,510 --> 00:10:18,520 Connected with boot security is malicious peripherals, 122 00:10:18,520 --> 00:10:22,760 that I mentioned shortly before. 123 00:10:22,760 --> 00:10:27,520 So we’ll be now thinking: Can we assure 124 00:10:27,520 --> 00:10:30,890 only good code is started 125 00:10:30,890 --> 00:10:38,000 and how the peripherals might interfere here. 126 00:10:38,000 --> 00:10:41,920 Again, we will look at this SPI flash. 127 00:10:41,920 --> 00:10:47,530 If we're now considering the boot security we would like to understand 128 00:10:47,530 --> 00:10:54,150 what code is loaded on the platform. And if we now think where this code is stored, 129 00:10:54,150 --> 00:10:57,880 it seems that the code is stored on the SPI Flash and potentially also 130 00:10:57,880 --> 00:11:03,310 on some of the discrete elements. 131 00:11:03,310 --> 00:11:08,330 Let me state it again that this whole integrated processor package 132 00:11:08,330 --> 00:11:13,110 has everything and the kitchen sink except for the flash, 133 00:11:13,110 --> 00:11:21,560 so except for the storage of the firmware. 134 00:11:21,560 --> 00:11:25,650 Here we have one of the SPI flash chips. 135 00:11:25,650 --> 00:11:28,460 This is from my Laptop actually. 136 00:11:28,460 --> 00:11:32,110 It’s a little microcontroller 137 00:11:32,110 --> 00:11:38,900 and it typically stores the firmware for these things, that are written here. 138 00:11:38,900 --> 00:11:47,340 Now the question is, let's say I have got this laptop from a store. 139 00:11:47,340 --> 00:11:55,720 How can I actually verify what firmware is really on this chip? 140 00:11:55,720 --> 00:12:00,940 Well I can perhaps boot it into some minimal Linux and try to ask it. 141 00:12:00,940 --> 00:12:05,120 But of course if there is some malicious something on the motherboard, 142 00:12:05,120 --> 00:12:12,950 not necessarily this chip, I will not get reliable answers. 143 00:12:12,950 --> 00:12:20,900 Another question: Let’s say I somehow know that there’s something trustworthy 144 00:12:20,900 --> 00:12:27,020 on this SPI chip. Can I somehow enforce read-only’ness of this program? 145 00:12:27,020 --> 00:12:30,020 There have been some efforts to do that. 146 00:12:30,020 --> 00:12:36,630 Like some projects by Peter Stuge who just took a soldering iron 147 00:12:36,630 --> 00:12:43,680 and connected one of the pins - one of these 8 pins is called “write protect”. 148 00:12:43,680 --> 00:12:50,430 If you ground it, it will be telling the chip to discard any Write commands. 149 00:12:50,430 --> 00:12:54,710 But again, remember, this chip is still a little microcontroller, 150 00:12:54,710 --> 00:12:59,440 it’s a little computer. So it might ignore whatever you requested to do. 151 00:12:59,440 --> 00:13:05,320 It’s not like you are cutting off a signal for Write commands. 152 00:13:05,320 --> 00:13:09,630 You are merely asking the processor to ignore it. 153 00:13:09,630 --> 00:13:16,330 So if you don’t trust the chip in the first place, this doesn’t provide you 154 00:13:16,330 --> 00:13:19,810 a reliable way to enforce read-only’ness. 155 00:13:19,810 --> 00:13:26,010 Finally can I upload my own firmware? Can I choose to use whatever BIOS I want? 156 00:13:26,010 --> 00:13:30,570 Again, we don’t seem to have luck here. 157 00:13:34,530 --> 00:13:38,110 And as I mentioned, this is just one of the places on the platform 158 00:13:38,110 --> 00:13:42,200 where the state is stored. Embedded controller would be 159 00:13:42,200 --> 00:13:49,020 a whole another microcontroller having its own internal flash. 160 00:13:49,020 --> 00:13:54,040 Or if not, using another SPI chip to get flash from. 161 00:13:54,040 --> 00:13:59,270 A disk would be another microcontroller with a small computer, 162 00:13:59,270 --> 00:14:05,190 having its own - typically - flash for its own firmware. 163 00:14:05,190 --> 00:14:11,190 And perhaps the same with the Wi-Fi module. 164 00:14:11,190 --> 00:14:18,150 Now for many years, myself and lots of other people believed that 165 00:14:18,150 --> 00:14:25,080 technologies like TPM, trusted execution technology... like UEFI Secure Boot 166 00:14:25,080 --> 00:14:29,300 I never really liked, but many people did - they believed that they could 167 00:14:29,300 --> 00:14:32,410 somehow solve the problem of secure boot. 168 00:14:32,410 --> 00:14:38,370 But all of these technologies have been shown to fail horribly 169 00:14:38,370 --> 00:14:44,440 in this... on this premise. 170 00:14:44,440 --> 00:14:47,090 And then we have... So these were problems, 171 00:14:47,090 --> 00:14:52,590 the tip of the iceberg of problems of the secure boot. 172 00:14:52,590 --> 00:15:01,640 The short story is: Today we can not really assure secure boot. 173 00:15:01,640 --> 00:15:08,050 Maybe before we move on to Intel ME: e.g. Intel TXT: 174 00:15:08,050 --> 00:15:12,160 Trusted Execution Technology was introduced by Intel in the hope 175 00:15:12,160 --> 00:15:19,029 to put the BIOS outside of the TCB, trusted computing base for the platform. 176 00:15:19,029 --> 00:15:26,440 So, the idea was that if you use TXT which you can think of as 177 00:15:26,440 --> 00:15:32,710 a special instruction of the processor, that was the root of trust. 178 00:15:32,710 --> 00:15:37,220 So, the promise was that when using Intel TXT 179 00:15:37,220 --> 00:15:45,089 you can start the chain of trust 180 00:15:45,089 --> 00:15:50,370 without trusting the BIOS. As well as other peripherals 181 00:15:50,370 --> 00:15:54,320 like Wi-Fi card, which might be malicious perhaps. 182 00:15:54,320 --> 00:16:01,210 And that was just great. And I really like the technology. 183 00:16:01,210 --> 00:16:04,940 With my team we have done lots of research on TXT. 184 00:16:04,940 --> 00:16:10,940 But one of the first attacks that we have presented, and that was back in like 2009, 185 00:16:10,940 --> 00:16:16,500 was that we could bypass TXT by having a malicious SMM. 186 00:16:16,500 --> 00:16:20,190 SMM was loaded by the BIOS. 187 00:16:20,190 --> 00:16:26,640 So apparently it turned out, that the BIOS could not be really put outside of the TCB 188 00:16:26,640 --> 00:16:32,080 so easily, because if it was really malicious it would provide a malicious SMM 189 00:16:32,080 --> 00:16:38,440 and then the SMM could bypass TXT. So the response from Intel was: “OK, 190 00:16:38,440 --> 00:16:46,190 but worry not, we have a technology called STM - Secure Transfer Monitor.” 191 00:16:46,190 --> 00:16:54,589 That is a little hypervisor to sandbox the SMM which might be malicious. 192 00:16:54,589 --> 00:17:02,480 So they wanted to boot a special dedicated... 193 00:17:02,480 --> 00:17:09,209 they built it actually... they built a special technology to sandbox this SMM. 194 00:17:09,209 --> 00:17:14,420 And then it turned out this is not so easy. 195 00:17:14,420 --> 00:17:17,050 Because as usual they were missing the details. 196 00:17:17,050 --> 00:17:22,050 And it is 6 years, 6 years has passed and 197 00:17:22,050 --> 00:17:28,369 we still have not seen any real STM in the wild. 198 00:17:28,369 --> 00:17:35,880 Which just is an example how hopeless this approach in building, 199 00:17:35,880 --> 00:17:44,079 in trying to provide secure boot is for the x86 platform. 200 00:17:44,079 --> 00:17:47,330 Another problem with x86 that 201 00:17:47,330 --> 00:17:52,210 has risen to prominence in the recent years is the Intel Management Engine. 202 00:17:52,210 --> 00:17:58,530 One of these things, that Intel 203 00:17:58,530 --> 00:18:04,800 has put into this integrated processor is called Management Engine (ME). 204 00:18:04,800 --> 00:18:12,140 And this ME is a little microcontroller that is inside your processor. 205 00:18:12,140 --> 00:18:18,900 It has its own internal RAM, it has its own internal peripherals. 206 00:18:18,900 --> 00:18:26,850 Like DMA engine, which has access to the host RAM. 207 00:18:26,850 --> 00:18:34,120 And of course, it loads only Intel-signed firmware. 208 00:18:34,120 --> 00:18:40,610 And it has also its own private ROM inside the processor, that nobody can inspect. 209 00:18:40,610 --> 00:18:45,230 And nobody knows what it does. 210 00:18:45,230 --> 00:18:51,200 And it runs a whole bunch of proprietary programs. 211 00:18:51,200 --> 00:18:58,500 And it runs even Intel’s own proprietary OS. 212 00:18:58,500 --> 00:19:03,630 And this all is happening all the time when you have some power connected 213 00:19:03,630 --> 00:19:07,460 to your processor. Even if it’s in a sleep mode. 214 00:19:07,460 --> 00:19:10,970 It’s running all the time here on my computer. 215 00:19:10,970 --> 00:19:17,830 It can be doing anything it wants. 216 00:19:17,830 --> 00:19:21,520 Obviously when I say something like that the first thought for, 217 00:19:21,520 --> 00:19:25,220 at least for security people is: “This is an ideal 218 00:19:25,220 --> 00:19:30,660 backdooring or rootkitting infrastructure.” Which is true. 219 00:19:30,660 --> 00:19:33,860 However there is another problem and it’s Zombification. 220 00:19:33,860 --> 00:19:38,330 I call it Zombification of personal computing that I will discuss in a moment. 221 00:19:38,330 --> 00:19:50,390 I’m just stressing these are two somehow independent problems with this ME. 222 00:19:50,390 --> 00:19:57,120 About 10 or more years ago I used to be a very active malware researcher or 223 00:19:57,120 --> 00:20:03,010 scout malware researcher. Especially rootkit researcher and back then when, 224 00:20:03,010 --> 00:20:09,040 if I was to imagine an ideal infrastructure for writing rootkits, 225 00:20:09,040 --> 00:20:16,600 I couldn’t possibly imagine anything better than ME. 226 00:20:16,600 --> 00:20:22,830 Because ME has access to essentially everything that is important. 227 00:20:22,830 --> 00:20:27,160 As I mentioned it has unconstrained access to DRAM, 228 00:20:27,160 --> 00:20:31,130 to the actual CPU, to GPU. 229 00:20:31,130 --> 00:20:36,180 It can also talk to your networking card, 230 00:20:36,180 --> 00:20:39,930 especially to the Ethernet card 231 00:20:39,930 --> 00:20:45,900 which controller is also in the Southbridge in the processor. 232 00:20:45,900 --> 00:20:50,610 It can also talk to the SPI flash and asks the SPI flash. 233 00:20:50,610 --> 00:20:54,670 It has its own dedicated partition on the SPI flash, 234 00:20:54,670 --> 00:21:02,260 which can be used to store whatever ME wants to store there. 235 00:21:02,260 --> 00:21:07,830 This is really problematic and we don’t know what it runs. 236 00:21:11,080 --> 00:21:15,470 But the other problem, that is perhaps less obvious, 237 00:21:15,470 --> 00:21:27,360 is what I call zombification of the General Purpose Computing. 238 00:21:27,360 --> 00:21:32,830 About a year ago there was a book published by 239 00:21:32,830 --> 00:21:39,120 one of the Intel architects, one of the architects who designed Intel ME. 240 00:21:39,120 --> 00:21:41,790 I highly recommend this book. 241 00:21:41,790 --> 00:21:51,570 It’s the only somehow official source of information about Intel ME. 242 00:21:51,570 --> 00:21:58,240 And what the book has made clear is that 243 00:21:58,240 --> 00:22:03,740 the model of computing that Intel envisions in the future, 244 00:22:03,740 --> 00:22:08,840 is to take the model, that we have today, which looks like this. 245 00:22:08,840 --> 00:22:13,990 The size of the boxes somehow attempts to present 246 00:22:13,990 --> 00:22:21,330 the amount of logic or involvement of each of the layers 247 00:22:21,330 --> 00:22:25,290 in processing of the user data. 248 00:22:25,290 --> 00:22:29,610 Obviously we have most of this processing done in the applications. 249 00:22:29,610 --> 00:22:37,050 But we also have some involvement from the OS and also from the hardware, of course. 250 00:22:37,050 --> 00:22:42,150 For example, when we want to generate a random number 251 00:22:42,150 --> 00:22:56,820 we would usually ask an OS to 252 00:22:56,820 --> 00:22:59,200 return us the random number. 253 00:22:59,200 --> 00:23:05,490 Because the OS can generate it using timings and interrupts, whatever. 254 00:23:05,490 --> 00:23:10,890 But again, most of the logic, most of the code is in the application’s layer. 255 00:23:10,890 --> 00:23:14,240 And this is good, because 256 00:23:14,240 --> 00:23:19,549 thanks to computing being general purpose computing, 257 00:23:19,549 --> 00:23:22,620 everyone of us can write applications. 258 00:23:22,620 --> 00:23:28,890 We can argue what is the best way to implement some crypto. 259 00:23:28,890 --> 00:23:33,910 Some people can write it one way, some other people can write it another way. 260 00:23:33,910 --> 00:23:36,500 And that’s good. 261 00:23:36,500 --> 00:23:42,000 Now this is the model that Intel wants to go to. 262 00:23:42,000 --> 00:23:48,250 It essentially wants to eliminate all the logic that touches data 263 00:23:48,250 --> 00:23:54,950 from apps and OS even and move it to Intel ME. 264 00:23:54,950 --> 00:24:03,830 Because, remember, Intel ME is also an OS. 265 00:24:03,830 --> 00:24:10,710 It’s a separate OS. Only that this is an OS that nobody knows how it works. 266 00:24:10,710 --> 00:24:13,730 It’s an OS, that nobody has any possibility 267 00:24:13,730 --> 00:24:18,040 to look at the source code or even reverse engineer. 268 00:24:18,040 --> 00:24:21,590 Because even we can not really analyse the binaries. 269 00:24:21,590 --> 00:24:29,590 It’s the OS that is fully controlled by Intel. And not to mention that 270 00:24:29,590 --> 00:24:34,240 any functionality it offers is also fully controlled by Intel. 271 00:24:34,240 --> 00:24:42,880 Without anybody being able to verify what they do. 272 00:24:42,880 --> 00:24:45,360 That might not even be malicious. 273 00:24:45,360 --> 00:24:48,179 They may not even be doing malicious things. 274 00:24:48,179 --> 00:24:51,730 Perhaps they are just implementing something wrong. 275 00:24:51,730 --> 00:24:57,230 Bugs. Security bugs, right? 276 00:24:57,230 --> 00:25:00,820 But of course Intel believes that whatever Intel writes 277 00:25:00,820 --> 00:25:06,520 must be secure. 278 00:25:06,520 --> 00:25:12,220 For some reason the must have missed 279 00:25:12,220 --> 00:25:17,040 a number of papers that my team and others 280 00:25:17,040 --> 00:25:25,450 have published in the recent 10 years. 281 00:25:25,450 --> 00:25:30,730 The questions are: Can we disable Intel ME or can we control what code runs there? 282 00:25:30,730 --> 00:25:34,470 Can we see at least what code is there? 283 00:25:34,470 --> 00:25:39,799 And as far as I’m aware the answer is unfortunately: Not. 284 00:25:39,799 --> 00:25:44,350 As I mentioned, I have this cool laptop it runs Qubes OS, of course, 285 00:25:44,350 --> 00:25:51,970 but still it not only runs Qubes OS. It also runs side by side Intel ME. 286 00:25:51,970 --> 00:25:54,919 Intel ME proprietary OS. 287 00:25:54,919 --> 00:26:06,000 And I can’t do anything about it. 288 00:26:06,000 --> 00:26:14,330 About 6 or 7 years ago my team has done some work on Intel AMT. 289 00:26:14,330 --> 00:26:17,850 I believe this was the first and probably the only work where we managed 290 00:26:17,850 --> 00:26:23,570 to actually inject code into ME. That was back in times 291 00:26:23,570 --> 00:26:29,270 when Intel ME was not in the processor. It was in the Northbridge. 292 00:26:29,270 --> 00:26:35,740 It was in the Q35 or Q45 chipset, if I remember correctly. 293 00:26:35,740 --> 00:26:42,320 So we demonstrated how we can inject a rootkit into ME. 294 00:26:42,320 --> 00:26:46,470 Of course Intel then patched it. 295 00:26:46,470 --> 00:26:51,049 Now they continue to think that whatever they write will be always secure. 296 00:26:51,049 --> 00:26:55,270 But, the problem is... 297 00:26:55,270 --> 00:27:00,590 For a number of years after that presentation I used to believe 298 00:27:00,590 --> 00:27:09,220 that we could use VTD - an INTEL IMMU technology with TXT - 299 00:27:09,220 --> 00:27:11,900 perhaps to effectively sandbox ME. 300 00:27:11,900 --> 00:27:15,360 Because some of the specifications I saw, 301 00:27:15,360 --> 00:27:21,059 suggested that VTD should be able to 302 00:27:21,059 --> 00:27:25,830 sandbox ME accesses to host memory. 303 00:27:25,830 --> 00:27:32,580 And because we used VTD heavily on Qubes, thanks to Xen using it, 304 00:27:32,580 --> 00:27:42,730 I was pretty much not that worried about ME. 305 00:27:42,730 --> 00:27:51,000 Unfortunately it turned out that ME can just bypass VTD. 306 00:27:51,000 --> 00:27:58,940 And this is a feature of this ME. 307 00:27:58,940 --> 00:28:04,570 Which brings us to this rather sad conclusion that perhaps 308 00:28:04,570 --> 00:28:14,760 if we look at Intel x86 platform, then the war is lost here. 309 00:28:14,760 --> 00:28:18,260 It might be lost even if we didn’t have ME. 310 00:28:18,260 --> 00:28:24,460 Even if we somehow manage to convince Intel to get rid of ME, 311 00:28:24,460 --> 00:28:31,279 or at least to offer OEMs, Laptop vendors, an option to disable it, 312 00:28:31,279 --> 00:28:35,100 by fusing something. 313 00:28:39,190 --> 00:28:44,630 The problem with secure boot that I mentioned earlier, 314 00:28:44,630 --> 00:28:49,840 and that I analysed in more detail in a paper I released 2 months ago, 315 00:28:49,840 --> 00:28:53,120 is that it really is hopeless, 316 00:28:53,120 --> 00:28:58,289 because of the complexity of the architecture 317 00:28:58,289 --> 00:29:03,900 where we have ring 3, ring 0, okay. Then we have SMM, then we have virtualisation, 318 00:29:03,900 --> 00:29:09,640 then we have STM to sandbox SMM, and the interactions between these. 319 00:29:09,640 --> 00:29:20,030 This all doesn’t look really like it could be solved effectively, 320 00:29:20,030 --> 00:29:26,809 which of course bothers me a lot. 321 00:29:26,809 --> 00:29:29,020 At least on purely egoistic reasons, 322 00:29:29,020 --> 00:29:34,910 because I spent the last 5 years of my life on this Qubes project. 323 00:29:34,910 --> 00:29:41,940 And of course with such a state of things it makes my whole Qubes project 324 00:29:41,940 --> 00:29:47,090 somehow meaningless. 325 00:29:47,090 --> 00:29:52,360 If the situation is so bad, 326 00:29:52,360 --> 00:29:58,250 perhaps the only way to solve the problem is to change the rules of the game. 327 00:29:58,250 --> 00:30:06,070 Because you can not really win under the old rules. 328 00:30:06,070 --> 00:30:14,390 That’s why I wanted to share this approach with you today. 329 00:30:14,390 --> 00:30:21,610 That starts with recognizing that 330 00:30:21,610 --> 00:30:27,610 most of the problems here is related to the persistent state, 331 00:30:27,610 --> 00:30:32,630 that is stored pretty much everywhere on your platform, 332 00:30:32,630 --> 00:30:42,280 which usually keeps the firmware, but not only. 333 00:30:42,280 --> 00:30:50,549 So let’s imagine, that we could do a clean separation of state from hardware. 334 00:30:50,549 --> 00:30:59,079 So this is the current picture. This is your laptop. 335 00:30:59,079 --> 00:31:05,870 The reddish boxes are state, the persistent state. 336 00:31:05,870 --> 00:31:11,659 That means these are places where malware can persist. 337 00:31:11,659 --> 00:31:17,510 So you reinstall the OS, but the malware still can re-infect. 338 00:31:17,510 --> 00:31:23,280 There are also places where malware can store secrets, 339 00:31:23,280 --> 00:31:29,539 once it steals them from you. So imagine I can have malware, 340 00:31:29,539 --> 00:31:36,210 that might only be stealing my disk encryption key. 341 00:31:36,210 --> 00:31:42,530 And it can store it somewhere on the disk or maybe on SPI flash. 342 00:31:42,530 --> 00:31:48,979 Or maybe in the Wi-Fi module firmware, or maybe in the embedded controller firmware, 343 00:31:48,979 --> 00:31:56,860 somewhere. Somewhere there in those red rectangles. 344 00:31:56,860 --> 00:32:00,100 Now if the malware does it, that is a pretty fatal situation, 345 00:32:00,100 --> 00:32:03,960 because if my laptop gets stolen or seized, 346 00:32:03,960 --> 00:32:10,390 perhaps then the adversary who gets 347 00:32:10,390 --> 00:32:13,850 a key to the malware can just decrypt the blobs. 348 00:32:13,850 --> 00:32:21,809 And the blobs would reveal my disk decryption key. And then the game is over. 349 00:32:21,809 --> 00:32:25,960 And also another problem with this state is that it might be 350 00:32:25,960 --> 00:32:34,200 revealing many of the user and personally identifiable information. 351 00:32:34,200 --> 00:32:39,580 How ever you read this PI shortcut. 352 00:32:39,580 --> 00:32:43,720 These are for example MAC addresses. 353 00:32:43,720 --> 00:32:48,179 Or maybe processor serial number. 354 00:32:48,179 --> 00:32:51,340 Or maybe ME serial number. Whatever! 355 00:32:51,340 --> 00:32:57,850 Or maybe the list of SSID networks, that ME has seen recently. 356 00:32:57,850 --> 00:33:01,850 How do you know it’s not being stored somewhere on your SPI flash? 357 00:33:01,850 --> 00:33:07,069 You don’t know what is stored there. Even though I can’t take off my SPI flash 358 00:33:07,069 --> 00:33:14,419 or just connect a programmer to my SPI flash - an EEPROM programmer - 359 00:33:14,419 --> 00:33:27,010 I can read the contents of the SPI flash, but all of this will be encrypted. 360 00:33:27,010 --> 00:33:31,460 Now we recognize, that the state might be problematic. 361 00:33:31,460 --> 00:33:36,700 And now imagine a picture, that we have the laptop, which has 362 00:33:36,700 --> 00:33:44,340 no persistent state storage. Which is this blue rectangle. 363 00:33:44,340 --> 00:33:47,669 Let’s call it stateless laptop. 364 00:33:47,669 --> 00:33:53,659 And then we have another element, that we’re gonna call trusted stick 365 00:33:53,659 --> 00:33:57,850 for lack of any more sexy name for it. 366 00:33:57,850 --> 00:34:04,749 That’s gonna be keeping all the firmware, all the platform configuration, 367 00:34:04,749 --> 00:34:09,719 all the system partitions, like boot and root, 368 00:34:09,719 --> 00:34:14,789 all the user partitions. 369 00:34:14,789 --> 00:34:18,889 Now we see that... and of course the firmware and system partitions 370 00:34:18,889 --> 00:34:22,549 will be exposed in a read only manner. 371 00:34:22,549 --> 00:34:28,009 So even if malware, perhaps a traditional malware, that got into my system 372 00:34:28,009 --> 00:34:35,339 through a malicious attachment, even if it found a weakness in the BIOS, 373 00:34:35,339 --> 00:34:40,359 or maybe in the chipset, allowing it to re-flash normally, allowing it 374 00:34:40,359 --> 00:34:51,228 to re-flash the BIOS - we have seen plenty of such attacks in the recent several years. 375 00:34:51,228 --> 00:34:54,698 Now it would not be able to succeed, because 376 00:34:54,698 --> 00:34:59,940 the trusted stick, which gonna be a simple FPGA implemented device, 377 00:34:59,940 --> 00:35:07,599 will just be exposing the read-only storage. 378 00:35:07,599 --> 00:35:13,390 You see that firmware injection can be prevented this way. 379 00:35:13,390 --> 00:35:17,109 Also there is no places to store stolen secrets. 380 00:35:17,109 --> 00:35:21,869 Again, the same malware running in the ME 381 00:35:21,869 --> 00:35:27,640 still can steal my disk encryption key or my PGP private key. 382 00:35:27,640 --> 00:35:31,099 But it has no place to store it. 383 00:35:31,099 --> 00:35:35,880 So if somebody now takes my laptop, will not be able to find it there. 384 00:35:35,880 --> 00:35:39,719 You might say, maybe it will be able to store it on the stick. 385 00:35:39,719 --> 00:35:45,219 But then, again, the stick, the firmware and system partitions are read-only. 386 00:35:45,219 --> 00:35:49,359 And the user partitions are encrypted by the stick. 387 00:35:49,359 --> 00:35:56,769 So even if ME can send something to be stored there, nobody besides the user 388 00:35:56,769 --> 00:36:02,910 can really get hands on this blob. 389 00:36:02,910 --> 00:36:06,900 Also we get a reliable way to verify what firmware we use. 390 00:36:06,900 --> 00:36:11,219 Or ability to choose what firmware we want to use. 391 00:36:11,219 --> 00:36:17,650 Because we can just take this stick, plug into our trustworthy computer, 392 00:36:17,650 --> 00:36:26,009 some, I don’t know, Lenovo X60 from 15 years ago, that we have running Coreboot 393 00:36:26,009 --> 00:36:30,249 and we just analysed all the elements, whatever. 394 00:36:30,249 --> 00:36:39,080 So we finally a have a way to upload firmware in a reliable way. 395 00:36:39,080 --> 00:36:45,580 Thanks to the actual laptop having no state, we can have something like Tails 396 00:36:45,580 --> 00:36:54,680 finally doing what it advertises. I can boot Tails or something like that. 397 00:36:54,680 --> 00:37:02,660 I can use it, I can shut it down and there is no more traces of my activity there. 398 00:37:02,660 --> 00:37:08,329 I can give my laptop to somebody other. Or I can boot some other environment. 399 00:37:08,329 --> 00:37:19,900 Perhaps some, I don’t know, Windows to play games, or whatever. 400 00:37:19,900 --> 00:37:27,499 So what would it take to have such a stateless laptop? 401 00:37:27,499 --> 00:37:32,910 This is the simplest version which shows that the only modification 402 00:37:32,910 --> 00:37:37,920 that has been made here was to take the SPI flash chip 403 00:37:37,920 --> 00:37:42,710 and essentially put it outside the laptop on a trusted stick. 404 00:37:42,710 --> 00:37:49,509 And just route the wiring, just 4 wires, to the trusted stick. 405 00:37:49,509 --> 00:37:50,749 And that’s pretty much it. 406 00:37:50,749 --> 00:37:55,989 That’s the simplest version. Oh, and I also got rid of the disk. 407 00:37:55,989 --> 00:38:02,779 And also I had to ensure, that whatever discrete devices, 408 00:38:02,779 --> 00:38:06,260 which are in that case embedded controller and Wi-Fi module, 409 00:38:06,260 --> 00:38:10,819 they do not have flash memory but use something like OTP memory. 410 00:38:10,819 --> 00:38:14,420 We can further get rid of the Wi-Fi, and use 411 00:38:14,420 --> 00:38:18,400 an external USB connected one if that is not possible. 412 00:38:18,400 --> 00:38:22,559 And for the embedded controller that should be possible, much more easier, 413 00:38:22,559 --> 00:38:27,289 because embedded controller is always something that the OEM chooses. 414 00:38:27,289 --> 00:38:33,779 So we can just talk to whatever OEM, who would like to implement 415 00:38:33,779 --> 00:38:39,069 this stateless laptop, and ask the OEM to use an embedded controller 416 00:38:39,069 --> 00:38:45,259 with essentially ROM, instead of flash. 417 00:38:45,259 --> 00:38:51,680 So that’s the simplest version, which is really simple. 418 00:38:51,680 --> 00:38:57,269 This is a more complex version where we also fit something 419 00:38:57,269 --> 00:39:04,669 that I call here SPI Multiplexer. Which allows to share the firmware 420 00:39:04,669 --> 00:39:09,130 not just to the processor, but also to the embedded controller. 421 00:39:09,130 --> 00:39:12,329 And perhaps also with the disk. 422 00:39:12,329 --> 00:39:16,329 Because maybe we actually would like to have internal disk. 423 00:39:16,329 --> 00:39:22,989 Because internal disk will always be faster and will always be bigger 424 00:39:22,989 --> 00:39:29,400 than whatever disk we will put on our trusted stick. 425 00:39:29,400 --> 00:39:36,489 You might object, that, come on, disk is actually not a stateless thing! Right? 426 00:39:36,489 --> 00:39:44,480 Because disk is made especially to store state persistently. 427 00:39:44,480 --> 00:39:50,099 But it’s a special disk, that I will mention in just a few minutes. 428 00:39:50,099 --> 00:39:54,530 It’s a special disk running trusted firmware and doing read-only 429 00:39:54,530 --> 00:39:59,319 and encryption for everything. 430 00:39:59,319 --> 00:40:05,059 And now for the trusted stick: 431 00:40:05,059 --> 00:40:10,900 As I mentioned, the trusted stick is envisioned to have 432 00:40:10,900 --> 00:40:14,160 read-only and encrypted partitions. 433 00:40:14,160 --> 00:40:22,739 And the read-only partitions are for firmware and the system code. 434 00:40:22,739 --> 00:40:29,289 So the first block is something that we would like to export over SPI, typically, 435 00:40:29,289 --> 00:40:34,479 and the system partition is something that we make visible 436 00:40:34,479 --> 00:40:42,969 to the OS using something like pretending being USB mass storage 437 00:40:42,969 --> 00:40:52,559 or actually implementing USB mass storage protocol. 438 00:40:52,559 --> 00:40:57,680 And the encrypted partition - again, the important thing here is 439 00:40:57,680 --> 00:41:06,309 that encryption should be implemented by the stick itself. 440 00:41:06,309 --> 00:41:10,589 So we have some key here, 441 00:41:10,589 --> 00:41:14,319 the question is how this key should be... 442 00:41:14,319 --> 00:41:22,150 What input should be taken to derive this key from. 443 00:41:22,150 --> 00:41:27,849 It could be something that is persistent to the stick. 444 00:41:27,849 --> 00:41:31,239 It could be combined with a passphrase, that the user enters 445 00:41:31,239 --> 00:41:37,819 using a traditional keyboard, plus maybe a secret from the TPM. 446 00:41:37,819 --> 00:41:44,079 And when I say TPM I think about the firmware TPM inside the processor 447 00:41:44,079 --> 00:41:47,190 that is using storage provided by 448 00:41:47,190 --> 00:41:57,050 encrypted firmware partition. 449 00:41:57,050 --> 00:42:01,829 The optional internal disk that I just mentioned, 450 00:42:01,829 --> 00:42:07,279 it should essentially do the same as the stick, 451 00:42:07,279 --> 00:42:11,209 and because it will be running trusted firmware 452 00:42:11,209 --> 00:42:15,739 that it will be fetching from the trusted stick itself 453 00:42:15,739 --> 00:42:19,640 the disk will not have any flash memory. 454 00:42:19,640 --> 00:42:24,109 So because we will trust the hardware of the disk 455 00:42:24,109 --> 00:42:28,160 and because we will trust the firmware, we will trust the firmware 456 00:42:28,160 --> 00:42:32,789 to provide read-only and encrypted partitions just like those ones 457 00:42:32,789 --> 00:42:39,119 I mentioned on the stick, which is nice because it reveals the stick from acting 458 00:42:39,119 --> 00:42:44,140 as a mass storage device, which has 459 00:42:44,140 --> 00:42:50,630 practical consequences which are nice. 460 00:42:50,630 --> 00:42:59,209 So there’s a picture with the internal trusted disk, which you see just here. 461 00:42:59,209 --> 00:43:04,009 As you can see, it takes also the firmware from the trusted stick. 462 00:43:04,009 --> 00:43:09,509 And there is even an open source project, OpenSSD. And it looks like 463 00:43:09,509 --> 00:43:18,200 people have already built an open hardware open firmware SSD, a very performant disk. 464 00:43:18,200 --> 00:43:28,520 So this is not just science fiction, even for this SSD. 465 00:43:28,520 --> 00:43:34,909 Okay, so that looks all very nice, but there is one problem. 466 00:43:34,909 --> 00:43:42,700 Even though malware may not have any place on the laptop to leak the secrets, 467 00:43:42,700 --> 00:43:46,549 it still might try to do it over networking. 468 00:43:46,549 --> 00:43:52,660 And let’s differentiate now between classic malware and sophisticated malware. 469 00:43:52,660 --> 00:43:59,499 Classic malware is something you get with an attachment or some drive-by-attack 470 00:43:59,499 --> 00:44:04,070 which we’ll discuss in a moment. Now, let’s focus on sophisticated malware. 471 00:44:04,070 --> 00:44:17,399 So, a hypothetical rootkit in ME. 472 00:44:17,399 --> 00:44:23,999 Before we move on, for obvious reasons, such a sophisticated malware 473 00:44:23,999 --> 00:44:30,130 would not be interested in getting caught easily. 474 00:44:30,130 --> 00:44:37,580 So, it would not be establishing a TCP connection to NSA.gov server 475 00:44:37,580 --> 00:44:44,849 or whatever, right? That would be plain stupid. 476 00:44:44,849 --> 00:44:49,619 Having that in mind, let’s consider a few scenarios. 477 00:44:49,619 --> 00:44:54,739 Scenario number 0 is an air-gapped system. 478 00:44:54,739 --> 00:44:58,079 Even though it might be an air-gapped system, 479 00:44:58,079 --> 00:45:01,519 still remember there is ME running there. 480 00:45:01,519 --> 00:45:11,619 If the computer is not inside a Faraday cage, 481 00:45:11,619 --> 00:45:18,559 there is still plenty of other networks or devices around it. 482 00:45:18,559 --> 00:45:25,539 Which means that ME can theoretically use your Wi-Fi card or even speaker 483 00:45:25,539 --> 00:45:33,019 to establish a covert channel with, say, your phone, that might be just nearby. 484 00:45:33,019 --> 00:45:39,450 So, in order to make such a system truly air-gapped, 485 00:45:39,450 --> 00:45:42,880 knowing that we can not get rid of the ME, 486 00:45:42,880 --> 00:45:48,299 we really need to have kill-switches for any transmitting devices, 487 00:45:48,299 --> 00:45:53,569 including the speakers, and apparently even that might not be enough, 488 00:45:53,569 --> 00:45:58,200 because some people showed covert channels that used 489 00:45:58,200 --> 00:46:04,420 things like power fluctuations 490 00:46:04,420 --> 00:46:11,670 or temperature fluctuations but let’s leave that exotic examples aside. 491 00:46:11,670 --> 00:46:18,609 A more interesting scenario is a closed network of trusted nodes. 492 00:46:18,609 --> 00:46:24,019 In that scenario we assume that all these people are trusted. 493 00:46:24,019 --> 00:46:27,660 Again, by definition that means that any of these people can compromise 494 00:46:27,660 --> 00:46:33,180 the security of anybody else. We really don’t like trusted things, 495 00:46:33,180 --> 00:46:38,229 but, well, let’s start with something. 496 00:46:38,229 --> 00:46:46,420 Now, even though each of these trusted peers which run state-less laptops, 497 00:46:46,420 --> 00:46:52,869 even each of these have this malicious ME in itself 498 00:46:52,869 --> 00:46:58,079 because we gonna fit a small proxy 499 00:46:58,079 --> 00:47:02,920 so a modification that we are... that we should additionally do, 500 00:47:02,920 --> 00:47:08,259 that I have not shown you before, is that rather than connecting 501 00:47:08,259 --> 00:47:13,599 your Wi-Fi module directly to the processor which is not good, 502 00:47:13,599 --> 00:47:19,009 because it gives full authority of the processor over this Wi-Fi module. 503 00:47:19,009 --> 00:47:23,670 Instead we would like to connect it to some proxy. 504 00:47:23,670 --> 00:47:27,709 It would be doing some kind of tunnelling. 505 00:47:27,709 --> 00:47:34,199 Something like VPN or maybe TORifying any traffic that is generated there. 506 00:47:34,199 --> 00:47:40,309 So even though ME might be willing to be sending some traffic 507 00:47:40,309 --> 00:47:42,630 maybe not explicit traffic, 508 00:47:42,630 --> 00:47:48,390 maybe will be piggybacking on some user generated traffic, 509 00:47:48,390 --> 00:47:56,239 by only modifying, I don’t know, TCP initial sequence numbers, or something. 510 00:47:56,239 --> 00:48:00,530 It still all will be happening inside the tunnel. 511 00:48:00,530 --> 00:48:05,589 Again, some people might be saying “Yeah, but still ME 512 00:48:05,589 --> 00:48:09,869 might be modulating the timings of the generated packets 513 00:48:09,869 --> 00:48:18,629 and this way try to convey some information using timing.” 514 00:48:18,629 --> 00:48:21,650 We can’t truly do much about that but on the other hand it would be 515 00:48:21,650 --> 00:48:27,870 extremely difficult for ME to do that, implementation wise. 516 00:48:27,870 --> 00:48:32,769 Finally a scenario where we want to use any... 517 00:48:32,769 --> 00:48:38,140 when we want to connect with anybody not just with a trusted computer. 518 00:48:38,140 --> 00:48:44,469 So, say, with some website on the internet that might or might not be trusted. 519 00:48:44,469 --> 00:48:52,119 Again, by having this proxy which by the way might be implemented inside 520 00:48:52,119 --> 00:48:57,089 this embedded controller that we know, if you remember, 521 00:48:57,089 --> 00:49:05,569 it runs the trusted firmware because it fetches firmware from our trusted stick. 522 00:49:05,569 --> 00:49:11,759 So the proxy again is tunnelling any potential leakage from ME 523 00:49:11,759 --> 00:49:18,130 which means that a malicious ISP or any part of the infrastructure here 524 00:49:18,130 --> 00:49:23,529 still can not really retrieve the secrets that ME tries to leak. 525 00:49:23,529 --> 00:49:28,239 But of course at some point we need to terminate the stunnel that might be 526 00:49:28,239 --> 00:49:36,069 the VPN server or might be a TOR exit node or maybe the server itself if it’s, 527 00:49:36,069 --> 00:49:45,709 say, maybe an onion server, in which case anybody here can still 528 00:49:45,709 --> 00:49:55,129 presumably get the secrets from ME in this cloud here. 529 00:49:55,129 --> 00:49:58,489 Which unfortunately we can do nothing about. 530 00:49:58,489 --> 00:50:05,180 Except for hoping that at least if we used perhaps TOR 531 00:50:05,180 --> 00:50:09,219 for this first part of the equation 532 00:50:09,219 --> 00:50:13,690 then at least a malicious administrator of, say, this server 533 00:50:13,690 --> 00:50:17,029 would not be able to correlate whose decryption... 534 00:50:17,029 --> 00:50:19,880 whose disk decryption key it really is. 535 00:50:19,880 --> 00:50:24,039 Although this is very tricky. That would only work if this computer was 536 00:50:24,039 --> 00:50:27,739 a special purpose computer. If you used something like Qubes here 537 00:50:27,739 --> 00:50:32,150 and if you wanted to have different partitions, one for your personal 538 00:50:32,150 --> 00:50:37,580 and only one of these partitions would be special secret partitions. 539 00:50:37,580 --> 00:50:41,859 That wouldn’t work, because ME still would be able to gather 540 00:50:41,859 --> 00:50:47,259 your identification information from whatever partitions you have. 541 00:50:47,259 --> 00:50:53,259 Because again, it has unconstrained access to all the personal, all the host memory. 542 00:50:53,259 --> 00:51:01,199 But still this... using this proxy pushes adversary, 543 00:51:01,199 --> 00:51:05,869 hypothetical adversary, in the ME, into extreme difficulty 544 00:51:05,869 --> 00:51:11,579 of needing to piggy-back on some higher-level protocols 545 00:51:11,579 --> 00:51:18,119 establishing exotic cover channels. Comparing to what they can do today 546 00:51:18,119 --> 00:51:23,039 one can... they simply steal the key and store it on SPI first partition. 547 00:51:23,039 --> 00:51:28,910 Or maybe on your disk. This is like orders of magnitude more difficult 548 00:51:28,910 --> 00:51:34,589 for them to do. 549 00:51:34,589 --> 00:51:37,569 We mentioned the sophisticated malware and I mentioned 550 00:51:37,569 --> 00:51:44,319 the classic malware is a different story. The classic malware doesn’t need 551 00:51:44,319 --> 00:51:51,549 to be shy against leaking something through whatever means you can think of. 552 00:51:51,549 --> 00:51:59,380 Perhaps by sending email to somebody. But obviously to address the classic malware 553 00:51:59,380 --> 00:52:07,229 problem we can address it quite reasonably well on the OS level. 554 00:52:07,229 --> 00:52:14,209 For example using compartmentalization. But here comes the problem, 555 00:52:14,209 --> 00:52:20,680 is, that a malicious BIOS... 556 00:52:20,680 --> 00:52:24,609 Let me get back a little bit. Because so far we having assuming that 557 00:52:24,609 --> 00:52:28,959 we don’t really need to trust the BIOS. Because having this stateless laptop 558 00:52:28,959 --> 00:52:34,420 and trusted stick, even if the BIOS was malicious, it still, again, would not 559 00:52:34,420 --> 00:52:40,199 be able to change anything in its own firmware partition, would not be able to 560 00:52:40,199 --> 00:52:45,180 store any stolen secrets anywhere. So it’s convenient 561 00:52:45,180 --> 00:52:51,260 to figure that the BIOS might not be trusted. 562 00:52:51,260 --> 00:52:59,320 But then, again, a compromised BIOS might instead be providing 563 00:52:59,320 --> 00:53:07,979 privilege escalation backdoors for classic malware that executes on your 564 00:53:07,979 --> 00:53:12,900 compartmentalised OS. Such as to do VM escape. 565 00:53:12,900 --> 00:53:16,229 Such things are trivial to implement. 566 00:53:16,229 --> 00:53:21,199 And we don’t want classic malware which means we want to ensure 567 00:53:21,199 --> 00:53:27,559 that the BIOS does not provide such backdoors. 568 00:53:27,559 --> 00:53:35,239 And to make it short, we need open-source BIOS. Something like Coreboot. 569 00:53:35,239 --> 00:53:40,199 It’s great that we have Coreboot and we could help Coreboot 570 00:53:40,199 --> 00:53:43,789 to become such a BIOS for this stateless laptop. 571 00:53:43,789 --> 00:53:50,200 Even though Coreboot is not fully open- source - it relies on so-called Intel FSP, 572 00:53:50,200 --> 00:53:56,279 the firmware support package, which is a Intel blob that is needed to 573 00:53:56,279 --> 00:54:04,519 initialize your DRAM and other silicon - still it should be reasonably easy to 574 00:54:04,519 --> 00:54:10,650 ensure that FSP does not provide SMM backdoors. 575 00:54:10,650 --> 00:54:16,460 So this is a solvable problem. 576 00:54:16,460 --> 00:54:25,139 Finally there’s this question: So let’s say half a year from now 577 00:54:25,139 --> 00:54:30,239 or a year from now pure reason or somebody will tell you 578 00:54:30,239 --> 00:54:37,549 here is the stateless laptop. You can order, just a 1000 dollars. 579 00:54:37,549 --> 00:54:43,619 So you got the laptop. But how do you know it really IS a stateless laptop? 580 00:54:43,619 --> 00:54:50,309 Maybe it is full of state-caring elements. Maybe it’s full of 581 00:54:50,309 --> 00:54:56,239 radio devices that are emanating radios everywhere. 582 00:54:56,239 --> 00:55:04,009 This comes down to the problem of: How do we compare 2 different PCBs? 583 00:55:04,009 --> 00:55:06,499 Two different Printed Circuit Boards? 584 00:55:06,499 --> 00:55:13,900 As far as I’m aware right now our industry has no ways to compare two different PCBs 585 00:55:13,900 --> 00:55:17,859 and to state: yes they look identical. 586 00:55:17,859 --> 00:55:26,249 Because if we had that, then we could have the vendor, the laptop vendor 587 00:55:26,249 --> 00:55:33,079 which would obviously have to be open-hardware to publish the schematics 588 00:55:33,079 --> 00:55:37,979 and pictures of the boards and then anybody who ordered this laptop 589 00:55:37,979 --> 00:55:43,699 would have an opportunity to always, say, photograph the board and 590 00:55:43,699 --> 00:55:51,170 have a diff tool to compare it. If it really looks the same. 591 00:55:51,170 --> 00:55:56,859 Sure we would not be able to see inside the chips but at least the geometry-wise 592 00:55:56,859 --> 00:56:06,269 comparison would be a tremendous step to making such malicious modifications 593 00:56:06,269 --> 00:56:09,579 by vendors very difficult. 594 00:56:09,579 --> 00:56:13,900 This is a vision problem, kind of, right? You take 2 photos, have 2 photos 595 00:56:13,900 --> 00:56:20,910 of 2 PCBs and you have a tool to compare it. And I believe Jake Applebaum 596 00:56:20,910 --> 00:56:26,989 has already mentioned it, some... a year ago probably, 597 00:56:26,989 --> 00:56:37,999 it’s a great research project for all you academic people sitting here. 598 00:56:37,999 --> 00:56:43,809 That’s an example of a board that... I have no idea, I got this laptop, 599 00:56:43,809 --> 00:56:52,660 I opened it, I see this board. Sure, I can identify some IC elements 600 00:56:52,660 --> 00:56:55,980 like this embedded controller here... 601 00:56:55,980 --> 00:56:59,729 But, really, maybe it’s connected somehow differently, 602 00:56:59,729 --> 00:57:02,819 maybe there is some other flash elements there, I don’t know. 603 00:57:02,819 --> 00:57:09,009 I would like to have an ability now to check this with a called-in image 604 00:57:09,009 --> 00:57:18,419 that some experts will analyze in-depth and say it’s safe to use. 605 00:57:18,419 --> 00:57:26,469 Many people say that perhaps we should all give up on Intel x86 because ME e.g. 606 00:57:26,469 --> 00:57:34,039 *applause* 607 00:57:34,039 --> 00:57:39,309 Yet this is not such a nice idea. 608 00:57:39,309 --> 00:57:47,809 Or maybe this is not such a silver bullet, I should have said. 609 00:57:47,809 --> 00:57:53,459 First, we have ARM. Everybody says “Why not ARM? Let’s go to ARM!” 610 00:57:53,459 --> 00:57:57,910 First: There’s no such thing as an ARM processor. Okay? 611 00:57:57,910 --> 00:58:04,199 ARM just sells the specifications, or IP. 612 00:58:04,199 --> 00:58:12,319 And then the vendors, like Samsung, Texas Instruments etc. who take this IP 613 00:58:12,319 --> 00:58:18,199 and design and make very own SOC. This is still a proprietary processor 614 00:58:18,199 --> 00:58:24,789 that they can put whatever they want inside. E.g. we have Trust Zone 615 00:58:24,789 --> 00:58:30,869 that by itself is not as closed as ME. That there is nothing that would 616 00:58:30,869 --> 00:58:36,390 prevent a vendor to actually take Trust Zone and lock it down 617 00:58:36,390 --> 00:58:41,200 and end up with something like ME very easily. 618 00:58:41,200 --> 00:58:45,620 Just a matter of the vendor willing to do that. 619 00:58:45,620 --> 00:58:53,059 Also the diversity of the processors make it difficult for OS’s like Qubes 620 00:58:53,059 --> 00:58:58,599 that would like to use advanced technologies like IMMU for isolation 621 00:58:58,599 --> 00:59:04,019 to actually support all of them because different PSOCs might be implementing 622 00:59:04,019 --> 00:59:11,739 completely different versions or even technologies doing that. 623 00:59:11,739 --> 00:59:17,240 Another alternative, a much better one is to use open-hardware processors. 624 00:59:17,240 --> 00:59:24,809 Currently that means FPGA- implemented processors. 625 00:59:24,809 --> 00:59:29,199 In the future maybe we will have 3D printers that will allow everybody 626 00:59:29,199 --> 00:59:33,709 to print it. That will be great. But probably is not coming any time, 627 00:59:33,709 --> 00:59:37,170 in the coming 10 or 20 years. 628 00:59:37,170 --> 00:59:44,609 And meanwhile the performance and lack of really any security technologies 629 00:59:44,609 --> 00:59:51,089 like IOMMU or virtualization doesn’t make this a viable solution 630 00:59:51,089 --> 00:59:56,410 for the coming say 5 years at least. 631 00:59:56,410 --> 00:59:59,259 And even then, even if we have such an open-source processor 632 00:59:59,259 --> 01:00:06,490 this clean separation of state still makes lots of sense. 633 01:00:06,490 --> 01:00:11,789 Right? Again, because firmware infections can be easily prevented 634 01:00:11,789 --> 01:00:16,630 because malware, if it gets there somehow still has no places 635 01:00:16,630 --> 01:00:22,920 to store stolen secrets because it provides reliable way to verify 636 01:00:22,920 --> 01:00:29,229 or upload firmware. And makes it easy to boot multiple environments. 637 01:00:29,229 --> 01:00:31,789 And share laptops with others. 638 01:00:31,789 --> 01:00:38,420 I know that most of you will now say: “Yeah, that may be cool idea but 639 01:00:38,420 --> 01:00:48,489 the market will never buy into that!” Right? 640 01:00:48,489 --> 01:00:55,159 Understanding that PCs are really, as I said, extension of our brains, 641 01:00:55,159 --> 01:01:02,900 we should stop thinking about market forces as the ultimate force 642 01:01:02,900 --> 01:01:08,289 shaping how our personal computing looks like. 643 01:01:08,289 --> 01:01:13,900 Just like we didn’t desert to market forces 644 01:01:13,900 --> 01:01:19,599 to give us human rights. Right? 645 01:01:19,599 --> 01:01:26,280 We should not count on the market forces to give us trustworthy personal computers. 646 01:01:26,280 --> 01:01:28,689 Because that might just not be really... 647 01:01:28,689 --> 01:01:34,569 *applause* 648 01:01:34,569 --> 01:01:40,299 That just might not be in the interest of the market forces! 649 01:01:40,299 --> 01:01:44,459 So, hopefully, some legislation could be of help here. 650 01:01:44,459 --> 01:01:48,969 Maybe EU could do something here. 651 01:01:48,969 --> 01:01:56,289 Because it’s really fun, when I often talk with other engineers, 652 01:01:56,289 --> 01:02:03,019 and we all know that our world now really runs on computers, 653 01:02:03,019 --> 01:02:06,999 and yet it apparently... Almost every engineer I talked to 654 01:02:06,999 --> 01:02:12,619 says something like “Yeah but the sales people will never do that, 655 01:02:12,619 --> 01:02:15,809 the business will never agree to that.” 656 01:02:15,809 --> 01:02:23,579 But if the world runs on computers shouldn’t it be us, the engineers, 657 01:02:23,579 --> 01:02:28,809 who should actually have the final say how this should... 658 01:02:28,809 --> 01:02:33,030 how the computer technology should look like? 659 01:02:33,030 --> 01:02:37,509 Yeah, I’ll just leave it here with this. Thank you very much! 660 01:02:37,509 --> 01:02:40,499 *final applause* 661 01:02:40,499 --> 01:02:44,569 *postroll music* 662 01:02:44,569 --> 01:02:50,799 subtitles created by c3subtitles.de in 2016