1 00:00:00,000 --> 00:00:02,334 DANIEL SELIFONOV: So, thanks for coming. 2 00:00:02,334 --> 00:00:03,751 We are here to talk about full disk encryption, 3 00:00:03,751 --> 00:00:07,334 why you are not as secure as you think you are. 4 00:00:08,999 --> 00:00:11,000 Oh, what just happened? 5 00:00:20,083 --> 00:00:21,999 I am missing a slide. 6 00:00:22,167 --> 00:00:24,375 I will just say what it was. 7 00:00:24,459 --> 00:00:28,334 So how many of you encrypt the hard drives in your computer? 8 00:00:28,334 --> 00:00:29,375 Just a show of hands. 9 00:00:29,375 --> 00:00:30,375 Oh, wow. 10 00:00:31,792 --> 00:00:33,501 Welcome to DEF CON. 11 00:00:33,501 --> 00:00:34,501 (Laughter). 12 00:00:34,501 --> 00:00:37,751 DANIEL SELIFONOV: So I guess 90% of you at least. 13 00:00:38,125 --> 00:00:40,125 How many of you use open source full disk 14 00:00:40,125 --> 00:00:42,375 encryption software as something that you can 15 00:00:42,375 --> 00:00:44,250 potentially audit? 16 00:00:44,375 --> 00:00:46,083 Not as many of you. 17 00:00:46,083 --> 00:00:48,417 But true encryption or, you know, how many 18 00:00:48,417 --> 00:00:52,542 of you always fully shut down your computer whenever you are 19 00:00:52,542 --> 00:00:54,999 leaving it unattended? 20 00:00:55,459 --> 00:00:56,667 Okay. 21 00:00:56,667 --> 00:00:57,667 More of you. 22 00:00:57,667 --> 00:00:58,792 I would say about 20%. 23 00:00:58,792 --> 00:00:59,709 How many of you have ever left your computer 24 00:00:59,709 --> 00:01:01,999 unattended for more than a few hours? 25 00:01:02,125 --> 00:01:04,999 A lot of hands should be up. 26 00:01:04,999 --> 00:01:06,999 You talking about on or off? 27 00:01:06,999 --> 00:01:08,999 DANIEL SELIFONOV: Either on or off. 28 00:01:09,209 --> 00:01:10,626 (Laughter). 29 00:01:10,999 --> 00:01:13,999 DANIEL SELIFONOV: I mean I would be surprised if you are not 30 00:01:13,999 --> 00:01:15,959 because I would have to ask are you 31 00:01:15,959 --> 00:01:19,626 like zombies that don't sleep and then the other answer, of course, 32 00:01:19,626 --> 00:01:22,999 is anyone who leaves their computer unattended for more than 33 00:01:22,999 --> 00:01:26,125 a few minutes, also pretty much everyone. 34 00:01:27,292 --> 00:01:30,999 So why do we encrypt our computer? 35 00:01:31,334 --> 00:01:33,334 And it is hard to find anybody talking 36 00:01:33,334 --> 00:01:37,876 about this which is really weird and I think it is really important 37 00:01:37,876 --> 00:01:41,542 to articulate our motivations why we are doing something, 38 00:01:41,542 --> 00:01:46,125 a particular security practice to and if we don't do that we don't have 39 00:01:46,125 --> 00:01:50,083 a sensible goalpost to see how we are doing. 40 00:01:51,999 --> 00:01:56,999 There is plenty of details in the documentation 41 00:01:56,999 --> 00:02:04,584 of full disk encryption software and I argue that we want we encrypt our 42 00:02:04,584 --> 00:02:08,501 computer because we want some control 43 00:02:08,501 --> 00:02:10,834 of our data. 44 00:02:10,834 --> 00:02:13,083 Some assurances about the confidentiality and integrity 45 00:02:13,083 --> 00:02:16,751 of our data that nobody is stealing our data or modifying our 46 00:02:16,751 --> 00:02:19,459 data without knowing about it. 47 00:02:21,667 --> 00:02:24,751 We want termination over your data. 48 00:02:25,083 --> 00:02:27,959 We want to be able to control what happens to it. 49 00:02:27,959 --> 00:02:32,709 There is situations where you have liabilities for not maintaining 50 00:02:32,709 --> 00:02:35,501 the secrecy of your data. 51 00:02:35,626 --> 00:02:37,751 Lawyers have to have attorney client privileges, 52 00:02:37,751 --> 00:02:40,999 doctors have doctor patient confidentiality. 53 00:02:46,667 --> 00:02:50,542 And so if you are leaking data, there is companies which have 54 00:02:50,542 --> 00:02:53,834 to notify their customers oh, we have someone left 55 00:02:53,834 --> 00:02:56,834 a laptop unencrypted in a van and it got broken 56 00:02:56,834 --> 00:02:58,959 in to and stolen. 57 00:02:58,959 --> 00:03:01,999 So your data might be out there on the Internet. 58 00:03:02,083 --> 00:03:05,792 But it also speaks to and it is really all about physical access 59 00:03:05,792 --> 00:03:10,083 to our computers that we want to protect because full disk encryption 60 00:03:10,083 --> 00:03:13,250 does not do anything if someone owns your machine 61 00:03:13,250 --> 00:03:18,999 but it also gets to a greater point if we want to build secure networks. 62 00:03:18,999 --> 00:03:21,459 If you want to have a secure Internet we can't have that 63 00:03:21,459 --> 00:03:25,083 unless we have end points that are secure. 64 00:03:25,083 --> 00:03:26,751 And you can't build a secure network 65 00:03:26,751 --> 00:03:30,834 without the foundations of the secure end points. 66 00:03:32,999 --> 00:03:36,999 But by and large we figured out the disk encryption theory numbers 67 00:03:36,999 --> 00:03:38,792 of the stuff. 68 00:03:40,999 --> 00:03:45,459 We know all the block cipher modes of operation. 69 00:03:49,999 --> 00:03:52,999 We know how to derive keys from passwords securely. 70 00:03:52,999 --> 00:03:54,918 So mission accomplished, right? 71 00:03:54,918 --> 00:03:57,334 We can all stand on an aircraft carrier, you know. 72 00:03:57,334 --> 00:03:58,334 (Laughter). 73 00:03:58,501 --> 00:04:02,292 DANIEL SELIFONOV: The answer is no, it is not the whole story. 74 00:04:02,292 --> 00:04:05,209 There is still a hell of a lot of cleanup that you need to do. 75 00:04:05,209 --> 00:04:07,334 Even if you have absolutely perfect cryptography, even 76 00:04:07,334 --> 00:04:10,999 if you know it can't be broken in any way you have to implement it 77 00:04:10,999 --> 00:04:14,667 on a real computer where you don't have these nice black box academic 78 00:04:14,667 --> 00:04:17,292 properties of your system, and so you don't attack 79 00:04:17,292 --> 00:04:22,125 the crypto when you are trying to break someone's full disk encryption. 80 00:04:22,417 --> 00:04:25,626 You either attack the computer and trick the user somehow 81 00:04:25,626 --> 00:04:28,125 or you attack the user and convince them 82 00:04:28,125 --> 00:04:32,792 to give you the password or get it by some other means. 83 00:04:34,667 --> 00:04:39,999 And de facto use doesn't really match up with the security models 84 00:04:39,999 --> 00:04:43,999 of the full disk encryption software. 85 00:04:44,417 --> 00:04:47,459 If you are looking at full disk encryption software 86 00:04:47,459 --> 00:04:50,125 they are focused on the disk. 87 00:04:57,083 --> 00:05:00,167 Actual documentation that they do, not secure data on your computer 88 00:05:00,167 --> 00:05:04,876 if someone has ever manipulated it or is manipulating it while it is running. 89 00:05:07,999 --> 00:05:11,167 Basically their security model if it encrypts the disk correctly or 90 00:05:11,167 --> 00:05:14,959 if it decrypts the disk correctly we have done our job. 91 00:05:19,209 --> 00:05:21,999 I apologize for the text, that you probably would not be able 92 00:05:21,999 --> 00:05:23,918 to read very welt. 93 00:05:23,918 --> 00:05:24,999 So I will read it here. 94 00:05:25,250 --> 00:05:28,999 So we note this is an exchange between the true encrypt developers 95 00:05:28,999 --> 00:05:32,417 and another security researcher by the name of Joan Rocosa where 96 00:05:32,417 --> 00:05:36,292 she brought up this attack and tried to talk to them. 97 00:05:37,999 --> 00:05:39,709 This is what they said. 98 00:05:39,709 --> 00:05:40,834 " 99 00:05:40,834 --> 00:05:42,918 We never consider the feasibility of hardware attacks and we have 100 00:05:42,918 --> 00:05:44,876 to assume the worst. 101 00:05:45,584 --> 00:05:48,751 Do you carry your laptop with you all the time? 102 00:05:50,542 --> 00:05:54,542 How the user ensures physical security is not our problem." 103 00:05:54,542 --> 00:06:00,999 And she asks very directly why in the world do I need encryption then. 104 00:06:00,999 --> 00:06:05,209 Ignoring feasibility of an attack you didn't do that. 105 00:06:05,501 --> 00:06:08,167 We live in the real world where we have these systems that we have 106 00:06:08,167 --> 00:06:09,834 to deal with. 107 00:06:09,834 --> 00:06:11,083 We have to implement this. 108 00:06:11,083 --> 00:06:12,083 We have to use them. 109 00:06:12,083 --> 00:06:12,999 And there is no way that you can compare 110 00:06:12,999 --> 00:06:15,999 a ten minute attack that you can conduct just software 111 00:06:15,999 --> 00:06:18,584 like a Flash drive to something where you need 112 00:06:18,584 --> 00:06:22,999 to pull apart the hardware and manipulate the system that way. 113 00:06:23,459 --> 00:06:26,792 And regardless of what they say, physical security and resistance 114 00:06:26,792 --> 00:06:30,751 to physical attack is in the scope of full disk encryption. 115 00:06:30,999 --> 00:06:34,083 It doesn't matter what you disclaim in your security model. 116 00:06:34,083 --> 00:06:36,999 At the very least if they don't want it to claim responsibility they need 117 00:06:36,999 --> 00:06:39,209 to be very clear and unequivocal about how easily 118 00:06:39,209 --> 00:06:41,375 the stuff can be broken. 119 00:06:42,999 --> 00:06:47,834 So this is a diagram of sort of an abstract system diagram 120 00:06:47,834 --> 00:06:52,999 of what is mostly in that modern CPU or modern computer and sort 121 00:06:52,999 --> 00:06:56,334 of what the group process is. 122 00:06:56,334 --> 00:06:56,792 Just so everyone is on the same page 123 00:06:56,792 --> 00:06:58,959 of what actually happens here. 124 00:06:58,999 --> 00:07:01,501 So as we know the boot loader gets loaded 125 00:07:01,501 --> 00:07:04,667 from the secondary storage and gets copied 126 00:07:04,667 --> 00:07:09,125 in to the main memory through a data transfer and boot loader 127 00:07:09,125 --> 00:07:13,876 then asks the user for some sort of authentication credential, 128 00:07:13,876 --> 00:07:19,125 like a password or a key smart card or something like that. 129 00:07:19,751 --> 00:07:22,999 That password is then transformed by some process in to a key which 130 00:07:22,999 --> 00:07:25,375 is then stored in memory for the duration 131 00:07:25,375 --> 00:07:28,999 of the computer being active and another boot loader transfers 132 00:07:28,999 --> 00:07:32,999 control over to the operating system and then both the operating system 133 00:07:32,999 --> 00:07:36,125 and key remain in memory for the transparent encryption 134 00:07:36,125 --> 00:07:38,999 and decryption of the computer. 135 00:07:39,334 --> 00:07:41,083 This is a very idealized view. 136 00:07:41,083 --> 00:07:43,751 Assumes that nobody is trying to screw with it 137 00:07:43,751 --> 00:07:47,999 in different ways where this can be broken. 138 00:07:48,542 --> 00:07:50,918 So let's enumerate a few things that might go wrong 139 00:07:50,918 --> 00:07:53,167 if one is trying to attack you. 140 00:08:01,167 --> 00:08:06,334 (Lost audio) Some other hardware component that you can attach to it, 141 00:08:06,334 --> 00:08:09,375 PCI card or express card or thunder bolt, 142 00:08:09,375 --> 00:08:13,751 the new adapter that gives you naked access to the PCI bus 143 00:08:13,751 --> 00:08:18,417 and consider attacks where a screwdriver might be required where 144 00:08:18,417 --> 00:08:21,375 you have to remove some system component 145 00:08:21,375 --> 00:08:26,999 and soldering wire attacks where you are either adding or modifying system 146 00:08:26,999 --> 00:08:31,542 components in order to try to break these things. 147 00:08:33,542 --> 00:08:37,999 And so one of the first types of attacks, a compromised boot loader or this 148 00:08:37,999 --> 00:08:41,083 is also sometimes known as the evil mate attack where 149 00:08:41,083 --> 00:08:45,375 the boot loader itself since you need to start executing some unencrypted 150 00:08:45,375 --> 00:08:48,876 code as part of the system boot process. 151 00:08:48,918 --> 00:08:51,250 Something which you can bootstrap yourself with and 152 00:08:51,250 --> 00:08:53,999 a few different ways you can do this. 153 00:08:59,626 --> 00:09:02,626 You can physically alter the boot loader 154 00:09:02,626 --> 00:09:05,999 on the storage system and you could compromise 155 00:09:05,999 --> 00:09:09,334 the bios and load a malicious bios that hooks 156 00:09:09,334 --> 00:09:14,876 the disk reading routines and modify it in a way that resists to removing 157 00:09:14,876 --> 00:09:16,999 the hard drive. 158 00:09:16,999 --> 00:09:21,083 In any case you can modify your system. 159 00:09:21,083 --> 00:09:24,792 When the user enters its password it gets written to disk unencrypted. 160 00:09:29,584 --> 00:09:32,918 You can do something similar with the operating system level. 161 00:09:33,167 --> 00:09:39,209 This is especially true if you are not using full disk encryption. 162 00:09:39,959 --> 00:09:44,125 There is the whole operating system that somebody can manipulate 163 00:09:44,125 --> 00:09:48,667 and this can also happen from attack on the system. 164 00:09:49,083 --> 00:09:50,959 Someone gets root on the box and now can read the key 165 00:09:50,959 --> 00:09:52,751 out the main memory. 166 00:09:55,999 --> 00:09:58,918 And then that key could be either transtored on the hard drive 167 00:09:58,918 --> 00:10:01,375 in plain text for later acquisition by the attack or sent 168 00:10:01,375 --> 00:10:04,959 over to the network by the command and control systems. 169 00:10:07,501 --> 00:10:10,042 Another possibility, of course, is capturing 170 00:10:10,042 --> 00:10:14,042 the user input via key logger, software, hardware, something exotic 171 00:10:14,042 --> 00:10:15,999 like a pinhole camera or maybe 172 00:10:15,999 --> 00:10:19,999 a microphone that records them typing in sounds and trying to figure 173 00:10:19,999 --> 00:10:23,999 out what keys they pressed and this is kind of a hard attack to stop 174 00:10:23,999 --> 00:10:28,999 because it potentially includes components outside of the system. 175 00:10:35,250 --> 00:10:38,626 I want to talk about cold boot attack. 176 00:10:38,999 --> 00:10:42,542 If you asked five years ago even people who are very security savvy what are 177 00:10:42,542 --> 00:10:45,292 the data properties, what are the security properties 178 00:10:45,292 --> 00:10:47,999 of main memory they would tell you when it powers 179 00:10:47,999 --> 00:10:51,042 down you lose the data very, very quickly. 180 00:10:51,918 --> 00:10:54,999 And then an excellent paper from Princeton, 2008, 181 00:10:54,999 --> 00:10:58,918 discovered that actually a room temperature you are looking 182 00:10:58,918 --> 00:11:03,501 at several seconds of perfectly good, very, very little data degradation 183 00:11:03,501 --> 00:11:04,999 in RAM. 184 00:11:05,083 --> 00:11:07,999 And if you cool it down to cryogenic temperatures 185 00:11:07,999 --> 00:11:10,459 by using an inverted can duster you can there 186 00:11:10,459 --> 00:11:14,542 are several minutes where you are getting very, very little degradation 187 00:11:14,542 --> 00:11:16,334 in main memory. 188 00:11:16,417 --> 00:11:19,999 And your key is in main memory and someone pulls your modules 189 00:11:19,999 --> 00:11:22,999 out and pulls up the modules from your computer, 190 00:11:22,999 --> 00:11:25,584 they can attack your key by finding where it 191 00:11:25,584 --> 00:11:28,709 is in the main memory in the clear. 192 00:11:29,459 --> 00:11:31,834 You can and those are like some attempts 193 00:11:31,834 --> 00:11:34,334 for resolving this hardware. 194 00:11:34,584 --> 00:11:36,375 Memory modules need to be scubbed. 195 00:11:36,417 --> 00:11:39,083 But it is not going to help you when you take 196 00:11:39,083 --> 00:11:42,918 the module out and puts it on the computer or a dedicated piece 197 00:11:42,918 --> 00:11:46,792 of hardware for extracting memory module content. 198 00:11:50,584 --> 00:11:54,417 Any PCI device on your computer has the ability 199 00:11:54,417 --> 00:12:00,375 to read and write the contents of any sector in main memory. 200 00:12:00,876 --> 00:12:01,959 They dock anything. 201 00:12:01,999 --> 00:12:04,667 And I mean this was designed back when computers were much slower 202 00:12:04,667 --> 00:12:07,918 where we didn't want to have the CPU baby sitting every transfer 203 00:12:07,918 --> 00:12:10,709 from devices to and from main memory. 204 00:12:10,999 --> 00:12:14,375 So devices gain this direct memory access capability to just 205 00:12:14,375 --> 00:12:18,083 they can be issued a command by the CPU and then finish it 206 00:12:18,083 --> 00:12:22,459 and data could be in memory whenever you needed it. 207 00:12:22,999 --> 00:12:26,501 PCI devices can be reprogrammed. 208 00:12:26,501 --> 00:12:29,542 A lot of these things have writable firmware that you can just reflash 209 00:12:29,542 --> 00:12:32,667 to something hostile and compromise the operating system 210 00:12:32,667 --> 00:12:36,626 or execute anyone at any other form of attack of either modifying the OS 211 00:12:36,626 --> 00:12:39,292 or pulling out the key directly. 212 00:12:39,792 --> 00:12:43,876 There is forensic capture hardware that is designed to do this 213 00:12:43,876 --> 00:12:46,584 in criminal investigations. 214 00:12:46,584 --> 00:12:48,918 They like plug something in to your computer and pull 215 00:12:48,918 --> 00:12:51,542 out the contents of memory. 216 00:12:51,542 --> 00:12:54,083 You can do this with fire wire and do this with express card 217 00:12:54,083 --> 00:12:58,250 and do this over thunder bolt, the new Apple adapter. 218 00:12:59,459 --> 00:13:02,999 So these are basically external buses to your these are external ports 219 00:13:02,999 --> 00:13:06,999 to your internal system bus which is very, very powerful. 220 00:13:07,626 --> 00:13:10,959 So wouldn't it be nice if we can keep our key somewhere else 221 00:13:10,959 --> 00:13:13,751 in RAM because we have sort of demonstrated that RAM 222 00:13:13,751 --> 00:13:17,792 is not terribly trustworthy from a security perspective? 223 00:13:17,999 --> 00:13:22,209 Is there any dedicated key storage or cryptographic hardware? 224 00:13:22,751 --> 00:13:25,751 You can find cryptographic accelerators. 225 00:13:29,501 --> 00:13:33,792 And they are tamper resistant or certificate authorities have these 226 00:13:33,792 --> 00:13:37,125 things that hold their top secret keys. 227 00:13:38,292 --> 00:13:42,083 But they are not really designed for high throughput operations 228 00:13:42,083 --> 00:13:44,751 like using disk encryption. 229 00:13:44,999 --> 00:13:46,542 Are there any other options? 230 00:13:48,834 --> 00:13:55,292 Can we use the CPU as sort of a pseudo hardware crypto module. 231 00:13:55,751 --> 00:13:59,417 So can we compute something like AES in a CPU using only something 232 00:13:59,417 --> 00:14:01,709 like CPU registers? 233 00:14:01,751 --> 00:14:05,584 Intel and AIM have rather excellent instructions which take 234 00:14:05,584 --> 00:14:09,334 all the hard work of AES out of your hands. 235 00:14:11,501 --> 00:14:14,125 Just a single assembly instruction. 236 00:14:15,876 --> 00:14:18,167 The question is then can we store can we store our 237 00:14:18,167 --> 00:14:21,667 key in memory and can we actually perform this process without relying 238 00:14:21,667 --> 00:14:23,292 on main memory. 239 00:14:23,999 --> 00:14:28,999 Another fairly large center, I don't know if you have tried adding 240 00:14:28,999 --> 00:14:32,959 up all the bits you have in registers but something 241 00:14:32,959 --> 00:14:37,999 like four kilobytes we can dedicate to key storage and scratch base 242 00:14:37,999 --> 00:14:41,250 for our encryption operations. 243 00:14:42,999 --> 00:14:47,292 One possibility is using the hardware break registers. 244 00:14:47,999 --> 00:14:52,459 There is four of them and in 64 bit mode these are each going 245 00:14:52,459 --> 00:14:55,083 to hold 64 bit pointer. 246 00:14:55,709 --> 00:14:58,667 So 256 bits of potential storage space that most 247 00:14:58,667 --> 00:15:01,584 people will never actually use. 248 00:15:02,999 --> 00:15:05,959 The advantage, of course, to using debug registers is one 249 00:15:05,959 --> 00:15:07,999 of privileged registers. 250 00:15:07,999 --> 00:15:10,250 Only the operating system can access them. 251 00:15:10,334 --> 00:15:14,083 And the other we get other nice benefits like when the CPU is powered 252 00:15:14,083 --> 00:15:17,792 down either by shutting off system or putting in sleep mode you use 253 00:15:17,792 --> 00:15:19,999 all register contents. 254 00:15:20,083 --> 00:15:21,792 You can't cold boot these. 255 00:15:22,459 --> 00:15:25,999 And a guy in Germany actually implemented this 256 00:15:25,999 --> 00:15:32,250 thing as Tresor Forley (phonetic) next in 2011 and it is not any slower. 257 00:15:38,334 --> 00:15:42,999 How about instead of storing a single key we can store 228 bit keys? 258 00:15:43,584 --> 00:15:48,751 This gets us in to more of the crypto module space. 259 00:15:48,751 --> 00:15:51,999 We can store a single master key which never leaves 260 00:15:51,999 --> 00:15:56,459 a CPU on bootup and then load and unload wrapped versions 261 00:15:56,459 --> 00:16:01,834 of keys as we need them for additional task operations. 262 00:16:04,125 --> 00:16:06,999 The problem is this we can have our code, 263 00:16:06,999 --> 00:16:10,501 our keys stored outside of main memory but the CPU 264 00:16:10,501 --> 00:16:13,292 is ultimately still going to be executing 265 00:16:13,292 --> 00:16:15,999 the contents of memory. 266 00:16:16,292 --> 00:16:18,667 DMA transfer or some other manipulation can alter 267 00:16:18,667 --> 00:16:21,334 the operating system and dump. 268 00:16:28,125 --> 00:16:31,876 Can we do anything about the DMA attack? 269 00:16:32,083 --> 00:16:34,876 And as it turns out yes, we can. 270 00:16:34,999 --> 00:16:37,083 And recently as part of new technologies 271 00:16:37,083 --> 00:16:41,417 for enhancing server virtualization for performance reasons people 272 00:16:41,417 --> 00:16:46,626 like being able to attach a network adapter to a virtual server. 273 00:16:46,626 --> 00:16:48,876 So it would need to go through a hypervisor. 274 00:16:49,584 --> 00:16:54,417 New technology was developed so you can sandbox a CPI box. 275 00:16:58,584 --> 00:17:00,375 So this is perfect. 276 00:17:00,375 --> 00:17:04,250 We can set up IOMMU permissions to protect our operating system 277 00:17:04,250 --> 00:17:08,083 and protect it from arbitrary access. 278 00:17:08,417 --> 00:17:13,375 And again our friend from Germany has implemented 279 00:17:13,375 --> 00:17:19,459 a version of Tresor on a microbit visor and it transparently 280 00:17:19,459 --> 00:17:23,876 does this disk access encryption. 281 00:17:27,751 --> 00:17:30,999 Disk access is totally transparent to the OS. 282 00:17:30,999 --> 00:17:33,959 And debug registers cannot be accessed by the OS. 283 00:17:36,250 --> 00:17:38,999 And secure from manipulation. 284 00:17:41,999 --> 00:17:46,792 As it turns out there is kind of other things 285 00:17:46,792 --> 00:17:53,792 in memory where we do container we used to do container encryption 286 00:17:53,792 --> 00:17:58,959 and now we all do full disk encryption. 287 00:17:58,959 --> 00:18:03,167 And we do full disk encryption because it is very, very difficult 288 00:18:03,167 --> 00:18:07,918 to make sure you don't have accidental rights to or caching 289 00:18:07,918 --> 00:18:11,375 in a container encryption system. 290 00:18:11,459 --> 00:18:16,209 Now that we are re evaluating main memory as a not secure, 291 00:18:16,209 --> 00:18:21,250 not trustworthy we need to treat it the same way. 292 00:18:24,334 --> 00:18:27,999 Things that are really important like SSH keys or private keys 293 00:18:27,999 --> 00:18:31,959 or PGP keys or password manager or any top secret documents that you 294 00:18:31,959 --> 00:18:33,751 are working on. 295 00:18:33,999 --> 00:18:38,999 So I had a very, very silly notion, can we encrypt main memory or 296 00:18:38,999 --> 00:18:43,083 at least most of the main memory where we are likely 297 00:18:43,083 --> 00:18:47,751 to keep secrets so we can at least minimize how much we are 298 00:18:47,751 --> 00:18:49,834 going to leak. 299 00:18:50,083 --> 00:18:53,083 Once again surprisingly the answer again is yes. 300 00:18:53,375 --> 00:18:58,999 A, proof of concept in 2010 by a guy named Peter Peterson tried 301 00:18:58,999 --> 00:19:03,292 implementing a RAM encryption solution. 302 00:19:03,292 --> 00:19:05,292 So it wouldn't encrypt all of RAM. 303 00:19:05,292 --> 00:19:08,292 It would basically split main memory in to two components, 304 00:19:08,292 --> 00:19:12,834 a small fix clear which would be unencrypted and then larger sort 305 00:19:12,834 --> 00:19:16,959 of pseudo swap device where all the data was encrypted prior 306 00:19:16,959 --> 00:19:19,918 to being kept in main memory. 307 00:19:20,250 --> 00:19:24,999 And it being quite a bit slower in synthetic benchmarks 308 00:19:24,999 --> 00:19:30,584 but in the real world when you ran like a web browser benchmark, 309 00:19:30,584 --> 00:19:33,999 it actually did pretty well. 310 00:19:34,083 --> 00:19:35,250 10% slower. 311 00:19:35,250 --> 00:19:36,834 I think we can live with that. 312 00:19:36,918 --> 00:19:39,751 The problem with this proof of concept implementation it stored 313 00:19:39,751 --> 00:19:41,709 the key to the encrypt in main memory 314 00:19:41,709 --> 00:19:44,501 because where else would we put it. 315 00:19:44,751 --> 00:19:46,876 The author considered using things like the TPM 316 00:19:46,876 --> 00:19:50,584 for bulk encryption operations, but those things are even slower than 317 00:19:50,584 --> 00:19:53,417 dedicated hardware crypto systems. 318 00:19:53,709 --> 00:19:54,999 Totally unusable. 319 00:19:58,167 --> 00:20:01,083 If we have the capability to use the CPU as sort 320 00:20:01,083 --> 00:20:06,375 of a pseudo crypto module it should be fast enough to do these things. 321 00:20:06,834 --> 00:20:08,999 Maybe we can use something like this. 322 00:20:10,209 --> 00:20:13,626 So let's say we have sort of a system set up. 323 00:20:13,667 --> 00:20:17,209 We have gotten our our keys are not in main memory and our code 324 00:20:17,209 --> 00:20:21,125 for manipulating our keys main memory is encrypted. 325 00:20:28,083 --> 00:20:30,667 Most of our secrets are not going to leak. 326 00:20:33,083 --> 00:20:37,375 But how do we actually get a system booted up to this state? 327 00:20:37,375 --> 00:20:39,000 Because we need to start from an turned off system, 328 00:20:39,000 --> 00:20:42,999 authenticate ourselves to it and get the system up and running. 329 00:20:43,501 --> 00:20:45,999 How do we do this in a trustworthy way? 330 00:20:45,999 --> 00:20:48,626 Because after all someone could still modify the system software 331 00:20:48,626 --> 00:20:51,459 to trick us in to thinking that we are running this 332 00:20:51,459 --> 00:20:54,000 great new system but in reality we are just not 333 00:20:54,000 --> 00:20:55,999 doing anything. 334 00:20:57,999 --> 00:21:02,584 So one of the very important topics is being able to verify integrity 335 00:21:02,584 --> 00:21:04,792 of our computers. 336 00:21:04,792 --> 00:21:10,250 You the user has to verify that the computer has not been tampered 337 00:21:10,250 --> 00:21:14,792 before they verify they can use this. 338 00:21:15,999 --> 00:21:20,709 Trusted module has got a bad rap but it has the capability 339 00:21:20,709 --> 00:21:26,792 to measure your booting sequence in a couple of different ways. 340 00:21:27,125 --> 00:21:31,999 To let you control what data will be revealed to the system 341 00:21:31,999 --> 00:21:38,083 from the TPM unless in two particular configuration states. 342 00:21:38,083 --> 00:21:40,083 So you can seal data to a particular software configuration 343 00:21:40,083 --> 00:21:42,876 that you are running on your system. 344 00:21:43,584 --> 00:21:47,125 And there is a couple of different implementation approaches 345 00:21:47,125 --> 00:21:50,792 to do this and there is fancy cryptography to make it hard 346 00:21:50,792 --> 00:21:52,834 to get around it. 347 00:21:52,834 --> 00:21:53,999 Maybe we can do this. 348 00:21:55,918 --> 00:21:58,083 What is a TPM anyway? 349 00:21:58,334 --> 00:22:02,751 It was originally sort of hailed by the digital lights 350 00:22:02,751 --> 00:22:05,334 by media companies. 351 00:22:05,999 --> 00:22:10,501 Media companies would be able to remotely verify that your system 352 00:22:10,501 --> 00:22:13,209 is running in some approved configuration 353 00:22:13,209 --> 00:22:17,417 before they would let you run the software and unlock the key 354 00:22:17,417 --> 00:22:19,876 to your video files. 355 00:22:19,959 --> 00:22:22,167 It ended up being impractical in practice. 356 00:22:22,167 --> 00:22:25,876 Nobody is even trying to use it for this purpose anymore. 357 00:22:26,334 --> 00:22:29,959 I think a better way to think about it is really a smart card that's fixed 358 00:22:29,959 --> 00:22:31,876 on your motherboard. 359 00:22:37,459 --> 00:22:39,542 And it has physical attack countermeasures 360 00:22:39,542 --> 00:22:41,999 to prevent someone from very easily getting access 361 00:22:41,999 --> 00:22:44,501 to the data that's stored in it. 362 00:22:44,501 --> 00:22:47,918 The only real difference between it and the smart card has the ability 363 00:22:47,918 --> 00:22:51,375 to measure the boot state in two platform configuration registers 364 00:22:51,375 --> 00:22:54,999 and usually a separate chip on the motherboard. 365 00:22:55,542 --> 00:22:58,083 So there is some security implications of that. 366 00:22:58,167 --> 00:23:02,375 There is some kind of fun bits like monotic counters. 367 00:23:07,584 --> 00:23:10,999 There is a small nonvolatile memory range that you could use for well, 368 00:23:10,999 --> 00:23:13,250 really whatever you want. 369 00:23:13,250 --> 00:23:17,375 It is not very big, like a kilobyte but could be useful. 370 00:23:17,751 --> 00:23:19,626 There is a tic counter, use the term of how long 371 00:23:19,626 --> 00:23:23,083 the system has been running since the last startup. 372 00:23:27,292 --> 00:23:29,999 To make it do things on your behalf which include things 373 00:23:29,999 --> 00:23:33,083 like clearing itself if you feel the need to. 374 00:23:35,167 --> 00:23:38,999 So we want to then develop a protocol that a user can run 375 00:23:38,999 --> 00:23:42,375 against the computer so that they can verify that 376 00:23:42,375 --> 00:23:46,751 the computer has not been tampered with before they authenticate 377 00:23:46,751 --> 00:23:50,999 themselves, the computer and then begin using it. 378 00:23:51,167 --> 00:23:52,792 So what sort of things can we try sealing 379 00:23:52,792 --> 00:23:57,250 to platform configuration registers that would be useful for the protocol. 380 00:23:58,876 --> 00:24:03,959 A couple of suggestions that I have is seed to one time password tokens. 381 00:24:06,083 --> 00:24:10,083 Maybe some sort of a unique image or animation like a photograph 382 00:24:10,083 --> 00:24:12,125 of you somewhere. 383 00:24:14,584 --> 00:24:17,292 Something that's difficult to something unique, 384 00:24:17,292 --> 00:24:21,626 not something that someone can easily find elsewhere and then say disable 385 00:24:21,626 --> 00:24:24,083 the video out on your computer when you are 386 00:24:24,083 --> 00:24:25,999 part of this challenge response 387 00:24:25,999 --> 00:24:28,083 authentication mode. 388 00:24:28,459 --> 00:24:30,999 You also want to seal a part of the disk key and a couple 389 00:24:30,999 --> 00:24:33,334 of reasons you want to do that. 390 00:24:33,999 --> 00:24:39,375 It assures that the system within certain security assumptions. 391 00:24:39,375 --> 00:24:41,250 Assures that the system is going to be booting in to be approved 392 00:24:41,250 --> 00:24:43,751 in some software configuration. 393 00:24:46,999 --> 00:24:50,292 Ultimately that means that anyone who wants to attack your system needs 394 00:24:50,292 --> 00:24:53,167 to do it either through the breaking of TPM or needs to do it 395 00:24:53,167 --> 00:24:56,626 within the sandbox that you have created for them. 396 00:24:57,334 --> 00:25:01,125 And this is not very cryptographically strong. 397 00:25:01,125 --> 00:25:03,459 You are not going to have a protocol that allows a user 398 00:25:03,459 --> 00:25:06,751 to securely authenticate to a computer. 399 00:25:09,250 --> 00:25:12,209 But unless you can do something like RSA encryption in your head it 400 00:25:12,209 --> 00:25:14,584 is never going to be perfect. 401 00:25:17,999 --> 00:25:21,999 So I mention that there is a self erase TPM command that you 402 00:25:21,999 --> 00:25:24,999 can issue as in the software. 403 00:25:25,209 --> 00:25:28,417 And since you are also running the since you require 404 00:25:28,417 --> 00:25:32,751 the system TPM requires the system to be in a particular configuration 405 00:25:32,751 --> 00:25:38,834 before it will release secrets you can do something interesting like self destruct. 406 00:25:39,375 --> 00:25:44,334 If you develop the software and set up your protocol to limit say number 407 00:25:44,334 --> 00:25:46,918 of times a computer has been started 408 00:25:46,918 --> 00:25:49,999 up unsuccessfully, have time out once waiting 409 00:25:49,999 --> 00:25:54,125 on password screen for some period of time or limit the number 410 00:25:54,125 --> 00:25:58,083 of times you can enter the password or the amount of time 411 00:25:58,083 --> 00:26:01,876 since the computer has been started up. 412 00:26:01,876 --> 00:26:04,167 Maybe it has been in cold storage for a week or so. 413 00:26:04,626 --> 00:26:08,542 And you can restrict access to the computer for a period. 414 00:26:08,959 --> 00:26:10,999 You are travelling to a foreign country and you want 415 00:26:10,999 --> 00:26:14,876 to lock down your computer for the duration of the trip. 416 00:26:19,709 --> 00:26:22,999 You can do fun things like leave little caners 417 00:26:22,999 --> 00:26:27,999 on the disk which appear to have the critical values for your policy 418 00:26:27,999 --> 00:26:33,501 by just trip wires and you are using the internal TPM values and also create 419 00:26:33,501 --> 00:26:36,375 the a self destruct password, dress code 420 00:26:36,375 --> 00:26:40,542 to automatically issue this recite command. 421 00:26:40,918 --> 00:26:46,167 And since the two options attacker would have would break the TPM 422 00:26:46,167 --> 00:26:52,959 or run your software, you can kind of make them play by these rules. 423 00:26:52,999 --> 00:26:56,334 And you can actually do an effective self destruct. 424 00:26:56,334 --> 00:26:59,959 The TPM is intentionally designed to be very, very hard to copy. 425 00:26:59,959 --> 00:27:02,999 Basically you can't clone it very easily. 426 00:27:03,417 --> 00:27:06,459 So you could use things like monotic counters 427 00:27:06,459 --> 00:27:10,999 to protect write blockers, any disk restore replay attacks 428 00:27:10,999 --> 00:27:15,083 and once the TPM clear command is issued it is game 429 00:27:15,083 --> 00:27:17,918 over for the attacker. 430 00:27:17,918 --> 00:27:19,999 You might want to get access to your data. 431 00:27:19,999 --> 00:27:22,999 There is some similarities to a system that Jacob Applebomb 432 00:27:22,999 --> 00:27:25,709 discussed at the (inaudible). 433 00:27:27,999 --> 00:27:30,667 He proposed using a network remote network server 434 00:27:30,667 --> 00:27:32,999 for many of these options. 435 00:27:33,417 --> 00:27:35,083 But admitted it was going to be brutal and kind 436 00:27:35,083 --> 00:27:37,709 of potentially difficult to use. 437 00:27:37,792 --> 00:27:40,959 Since the TPM is an integrated system component you 438 00:27:40,959 --> 00:27:44,459 can get a lot of these advantages by using the TPM 439 00:27:44,459 --> 00:27:47,167 instead of remote server. 440 00:27:48,083 --> 00:27:51,375 In the hybrid approach you could have a system set up say 441 00:27:51,375 --> 00:27:54,959 as an IT department where you temporarily lock down a system 442 00:27:54,959 --> 00:27:58,918 and it can only become available until you plug it in to the network 443 00:27:58,918 --> 00:28:03,250 and call your IT administrator and unlock the network again. 444 00:28:07,083 --> 00:28:11,709 But it is still a possibility. 445 00:28:13,751 --> 00:28:17,083 So I have sort of qualified all my statements attacker can only 446 00:28:17,083 --> 00:28:18,542 do this. 447 00:28:18,667 --> 00:28:20,542 That's, of course, under the assumption that 448 00:28:20,542 --> 00:28:23,584 they cannot break the TPM very easily. 449 00:28:23,751 --> 00:28:28,834 So this is actually an optical microscope scan of a TPM 450 00:28:28,834 --> 00:28:33,999 or smart card done by Chris Tarnovsky who spoke here 451 00:28:33,999 --> 00:28:35,999 last year. 452 00:28:38,250 --> 00:28:41,292 He has actually done some great work in figuring 453 00:28:41,292 --> 00:28:45,334 out how much how hard these things are to break. 454 00:28:45,334 --> 00:28:48,751 He has enumerated the countermeasures and figured 455 00:28:48,751 --> 00:28:52,125 out what to take to break these things and has gone 456 00:28:52,125 --> 00:28:54,999 and done it and tested it. 457 00:28:54,999 --> 00:28:57,501 So things like light detectors and active meshes and all sorts 458 00:28:57,501 --> 00:29:00,876 of these crazy circuit implementations to throw you off the track 459 00:29:00,876 --> 00:29:02,918 of what it is doing. 460 00:29:03,626 --> 00:29:07,542 But if you spend enough time, you have enough resources 461 00:29:07,542 --> 00:29:10,959 and you are careful enough you can actually get 462 00:29:10,959 --> 00:29:15,834 around these you can actually get around most of these. 463 00:29:15,999 --> 00:29:18,626 So you can encapsulate a chip and put it 464 00:29:18,626 --> 00:29:22,999 in an electron microscope work station and go wild. 465 00:29:23,125 --> 00:29:24,999 You find where the unencrypted data bus 466 00:29:24,999 --> 00:29:30,083 is and glitch it and get the things to spawn out all the secret data. 467 00:29:32,250 --> 00:29:35,209 Even if you have done all the R&D, something that's going 468 00:29:35,209 --> 00:29:37,459 to take hours with an expensive microscope 469 00:29:37,459 --> 00:29:40,334 and you are still going to spend months of R&D to figure 470 00:29:40,334 --> 00:29:43,542 out what the countermeasures are on the chip you can break it 471 00:29:43,542 --> 00:29:47,083 without frying the one chip without attack target. 472 00:29:49,250 --> 00:29:51,501 There is also recent attacks. 473 00:29:51,501 --> 00:29:55,292 I mentioned earlier been that the TPM is a separate chip on the motherboard. 474 00:29:55,292 --> 00:29:58,584 It is very, very low on the system hierarchy and not 475 00:29:58,584 --> 00:30:02,000 up in the CPU like it is for DRM enforcement 476 00:30:02,000 --> 00:30:04,999 in video game consoles. 477 00:30:05,042 --> 00:30:07,999 If you manage to reset it you are really not going 478 00:30:07,999 --> 00:30:11,334 to adversely affect the system that badly. 479 00:30:11,709 --> 00:30:14,083 It is usually a chip that's off the LPC bus 480 00:30:14,083 --> 00:30:18,209 on the computer which itself is sort of a legacy bus that's 481 00:30:18,209 --> 00:30:21,918 off the south bridge or platform hub. 482 00:30:21,999 --> 00:30:24,459 And on monitored systems the only sorts 483 00:30:24,459 --> 00:30:26,999 of things that you are going to find are 484 00:30:26,999 --> 00:30:30,209 the TPM and bios legacy keyboards. 485 00:30:33,501 --> 00:30:36,667 So if you and if you find a way to reset say 486 00:30:36,667 --> 00:30:41,209 the low pin count bus you will reset the TPM in to a fresh system, 487 00:30:41,209 --> 00:30:43,042 boot system. 488 00:30:43,292 --> 00:30:48,999 You will lose your PS2 keyboard but not a big deal and you 489 00:30:48,999 --> 00:30:54,501 will be able to play back the boot sequence of. 490 00:30:54,999 --> 00:30:57,459 A trusted boot sequence of the TPM has data sealed 491 00:30:57,459 --> 00:31:01,334 to without actually executing that boot sequence. 492 00:31:03,083 --> 00:31:06,209 A couple of attacks that have tried to exploit this. 493 00:31:10,792 --> 00:31:14,083 I have not seen any research on a successful attack 494 00:31:14,083 --> 00:31:17,542 against the newer Intel execution technology version 495 00:31:17,542 --> 00:31:19,999 of the TPM activation. 496 00:31:19,999 --> 00:31:23,334 It is likely still possible. 497 00:31:23,334 --> 00:31:26,792 So this is an area that probably needs more research to intercept 498 00:31:26,792 --> 00:31:30,999 the LPC bus and what it is communicating to the CPUs. 499 00:31:30,999 --> 00:31:33,083 That's another way you can attack the TPM. 500 00:31:34,083 --> 00:31:38,709 So let's look at a blueprint, what I think we should have 501 00:31:38,709 --> 00:31:42,417 for getting the system up from a cold boot state 502 00:31:42,417 --> 00:31:47,999 up in to what we have a running trustworthy configuration. 503 00:31:48,083 --> 00:31:50,959 There is a lot of vulnerable legacy components 504 00:31:50,959 --> 00:31:53,542 in our PC, architecture. 505 00:32:05,999 --> 00:32:08,959 Masking out CPU feature registers. 506 00:32:08,959 --> 00:32:12,209 I mean there is plenty of options if you want to mess with people. 507 00:32:12,999 --> 00:32:16,751 And so in my opinion you really want to get out a bios controlled mode 508 00:32:16,751 --> 00:32:19,083 out of real mode in to protected mode as soon 509 00:32:19,083 --> 00:32:22,999 as possible and really just do your measurement stuff. 510 00:32:23,792 --> 00:32:26,999 So once you get in to this preboot mode it 511 00:32:26,999 --> 00:32:31,626 is just your operating system, like a Linux initial RAM disk 512 00:32:31,626 --> 00:32:36,751 and then you start executing your protocol and doing these things, 513 00:32:36,751 --> 00:32:42,584 what someone does at the bios level as far as interrupt tables. 514 00:32:46,999 --> 00:32:50,834 If you know you are running on a core I5, you know it is going 515 00:32:50,834 --> 00:32:54,626 to be supporting things like no execute bit and debug registers 516 00:32:54,626 --> 00:33:00,083 and other stuff that people might try to mask out in capability registers. 517 00:33:03,250 --> 00:33:06,083 So here is the run time blueprint. 518 00:33:06,083 --> 00:33:08,999 What we actually want the system what we actually want 519 00:33:08,999 --> 00:33:12,999 the system to look like once we are in the running configuration, 520 00:33:12,999 --> 00:33:16,626 so there was the previous project Trevisor. 521 00:33:16,626 --> 00:33:20,375 We implemented the security aspects of doing disk encryption 522 00:33:20,375 --> 00:33:25,375 and having IOMMU protections on your main memory and bit visor 523 00:33:25,375 --> 00:33:30,209 is specialty and not very commonly used program. 524 00:33:30,334 --> 00:33:32,334 Zen is sort of like the conical open source 525 00:33:32,334 --> 00:33:34,999 hypervisor where there is a lot of security research going 526 00:33:34,999 --> 00:33:37,834 on and making sure it is not broken. 527 00:33:39,501 --> 00:33:46,501 In my opinion we should use something like Zen, bare level hardware interface 528 00:33:46,501 --> 00:33:50,125 and then use a Linux administrator domain 529 00:33:50,125 --> 00:33:54,334 to do your hardware initialization. 530 00:33:55,999 --> 00:33:59,999 So again in Zen all of your paravirtualized domains are 531 00:33:59,999 --> 00:34:03,918 running in nonprivileged mode in ring 3. 532 00:34:03,918 --> 00:34:08,250 They don't have direct access to things like the debug registers. 533 00:34:08,250 --> 00:34:10,292 So that's one thing that is already done. 534 00:34:10,292 --> 00:34:12,834 Zen exposes things like hyper calls that gives you access 535 00:34:12,834 --> 00:34:15,999 to that sort of stuff but it is something that you can disable 536 00:34:15,999 --> 00:34:17,751 in software. 537 00:34:18,501 --> 00:34:22,292 And so the approach I am taking is we will sort 538 00:34:22,292 --> 00:34:27,751 of do that master key approach in the debug registers. 539 00:34:27,751 --> 00:34:31,834 We will dedicate two debug registers to store master key. 540 00:34:31,999 --> 00:34:37,999 This thing never leaves CPU register and that takes the user credential 541 00:34:37,999 --> 00:34:41,334 and then we use the second two registers 542 00:34:41,334 --> 00:34:45,709 as virtual machine specifics, whatever. 543 00:34:45,709 --> 00:34:48,209 It could be either as ordinary debug registers 544 00:34:48,209 --> 00:34:52,083 or we could use it to encrypt main memory. 545 00:34:52,375 --> 00:34:54,667 In this particular case we still need to have 546 00:34:54,667 --> 00:34:58,167 a few devices that are connected to the main domain. 547 00:35:02,999 --> 00:35:06,959 The key, the TPM, all the stuff needs to be directly accessible. 548 00:35:06,959 --> 00:35:10,417 You can't apply IOMMU protections on this. 549 00:35:10,792 --> 00:35:13,334 But things like the network controller, the storage controller, 550 00:35:13,334 --> 00:35:15,542 arbitrary devices on the PCI bus you can set 551 00:35:15,542 --> 00:35:17,959 up IOMMU protections on it. 552 00:35:17,959 --> 00:35:20,584 So they have absolutely 0 access to your hypervisor, 553 00:35:20,584 --> 00:35:22,999 memory spaces or domain. 554 00:35:25,250 --> 00:35:28,709 You can do similar things by you can get access to things 555 00:35:28,709 --> 00:35:31,167 like the network by actually putting things 556 00:35:31,167 --> 00:35:35,999 like your network controller in to dedicated virtual machines. 557 00:35:35,999 --> 00:35:38,709 So these things are these things get the devices mapped 558 00:35:38,709 --> 00:35:42,417 but have IOMMU protection set up so that devices can only access 559 00:35:42,417 --> 00:35:45,959 the memory space of this virtual machine. 560 00:35:46,250 --> 00:35:49,999 You can do the same thing with storage controller, 561 00:35:49,999 --> 00:35:53,792 and then you actually run all of your applications 562 00:35:53,792 --> 00:35:59,626 in virtual machines that have absolutely 0 direct hardware access. 563 00:35:59,834 --> 00:36:01,626 Even if someone owns your web browser 564 00:36:01,626 --> 00:36:06,125 or sends you a malicious pdf file, they don't get anything that would let 565 00:36:06,125 --> 00:36:10,083 them seriously compromise your disk encryption. 566 00:36:11,125 --> 00:36:14,834 So I can't take the credit for that architecture design. 567 00:36:15,959 --> 00:36:18,999 It was actually the design base is for an excellent project called 568 00:36:18,999 --> 00:36:20,999 the cubes OS project. 569 00:36:21,876 --> 00:36:25,918 They basically describe themselves as a pragmatic formation of Zen 570 00:36:25,918 --> 00:36:30,792 to do custom tools to do a lot of the stuff that I talked about. 571 00:36:30,999 --> 00:36:35,834 Implement these nonprivileged guests and do a nice unified environment. 572 00:36:36,709 --> 00:36:39,083 It is actually a bunch of different virtual machines 573 00:36:39,083 --> 00:36:40,999 under the hood. 574 00:36:40,999 --> 00:36:43,417 I use this as the implementation in my code base and 575 00:36:43,417 --> 00:36:47,334 all the crypto stuff is stuff that I have added on top of it. 576 00:36:48,083 --> 00:36:51,876 And so the tool I am releasing, this is still really proof 577 00:36:51,876 --> 00:36:54,667 of concept experimental code. 578 00:36:54,667 --> 00:36:56,167 I call it phalaxncy (phonetic). 579 00:36:56,292 --> 00:36:58,792 It is a patch to Zen to do the implementation 580 00:36:58,792 --> 00:37:02,999 of the disk encryption stuff as I have described. 581 00:37:03,709 --> 00:37:05,542 Master key in the first two debug registers 582 00:37:05,542 --> 00:37:08,751 and second debug register is totally unencrypted. 583 00:37:19,250 --> 00:37:23,999 And I have also implemented a encrypt key, 584 00:37:23,999 --> 00:37:28,209 encrypted memory using Z RAM. 585 00:37:28,999 --> 00:37:32,083 It has does pretty much everything except for crypto. 586 00:37:37,292 --> 00:37:40,999 (No audio) And so it is the nice thing 587 00:37:40,999 --> 00:37:46,292 about Z RAM it gives you a bunch of the bits that you need 588 00:37:46,292 --> 00:37:51,501 to securely implement things like AS counter mode which 589 00:37:51,501 --> 00:37:53,999 is really great. 590 00:37:53,999 --> 00:37:56,250 Hardware wise you do have a you do have 591 00:37:56,250 --> 00:37:59,501 a few system requirements. 592 00:37:59,501 --> 00:38:03,501 So you need a system that supports the AES new instructions. 593 00:38:03,792 --> 00:38:06,626 Reasonably calm but not every system has it. 594 00:38:06,792 --> 00:38:10,999 Chances are if you have an Intel I5 or I7 all of them support it. 595 00:38:10,999 --> 00:38:12,083 There are odd balls. 596 00:38:12,501 --> 00:38:14,999 Checkout Intel arc. 597 00:38:17,167 --> 00:38:19,999 Data hardware virtualization extensions, these are very common 598 00:38:19,999 --> 00:38:21,584 as of 2006. 599 00:38:21,959 --> 00:38:24,751 IOMMU is a little bit more complicated to find if you are looking 600 00:38:24,751 --> 00:38:26,459 for a computer. 601 00:38:26,542 --> 00:38:29,083 It is not listed as a sticker specification. 602 00:38:29,250 --> 00:38:31,959 There is a lot of people who should know better 603 00:38:31,959 --> 00:38:34,459 but don't about what the differences between VTX 604 00:38:34,459 --> 00:38:36,709 and VTTD and so forth. 605 00:38:38,959 --> 00:38:42,667 You want a system TPM, otherwise you can't implement this 606 00:38:42,667 --> 00:38:45,417 measured boot thing at all. 607 00:38:46,999 --> 00:38:49,999 So usually you want to be looking at like business class machines where 608 00:38:49,999 --> 00:38:52,709 you can verify the sort of stuff exists. 609 00:38:52,709 --> 00:38:57,999 If you look for Intel TXT it will have everything that you need. 610 00:38:57,999 --> 00:38:59,999 The cubes team keeps a great hardware compatibility list 611 00:38:59,999 --> 00:39:03,250 on their Wiki which has details for a lot of systems that do 612 00:39:03,250 --> 00:39:05,250 the sort of stuff. 613 00:39:06,125 --> 00:39:08,999 So security assumptions, in order for the system 614 00:39:08,999 --> 00:39:11,792 to be secure we have a few assumptions about a few 615 00:39:11,792 --> 00:39:14,209 of the existing components. 616 00:39:14,375 --> 00:39:19,209 TPM, very critical component for assuring the integrity of the boot. 617 00:39:19,334 --> 00:39:22,167 You need to make sure that there is no back door capable 618 00:39:22,167 --> 00:39:25,999 of dumping MV RAM or manipulating monotic counters or putting 619 00:39:25,999 --> 00:39:29,999 the system in to a state where it is not trusted. 620 00:39:29,999 --> 00:39:30,999 We think it is. 621 00:39:30,999 --> 00:39:35,334 Resetting the PCR attacks and based on our remarks 622 00:39:35,334 --> 00:39:40,501 by Chernofsky that has reverse engineered these chips 623 00:39:40,501 --> 00:39:47,375 as setting 12 hours abound if you want to do an attack on it. 624 00:39:50,999 --> 00:39:54,751 A few assumptions about the CPU they are not back doored 625 00:39:54,751 --> 00:39:59,083 and directly implemented and some of these might not necessarily be 626 00:39:59,083 --> 00:40:02,792 strong assumptions because Intel could very easily back 627 00:40:02,792 --> 00:40:05,876 door these things and we have no way of finding 628 00:40:05,876 --> 00:40:08,918 on security assumptions of Zen. 629 00:40:09,167 --> 00:40:11,459 It has a good security record and nothing 630 00:40:11,459 --> 00:40:15,999 is perfect and occasionally there is security vulnerabilities. 631 00:40:15,999 --> 00:40:20,751 In the case of Zen that's kind of a big deal. 632 00:40:20,751 --> 00:40:22,375 You want to make sure it is secure. 633 00:40:23,626 --> 00:40:25,876 And so under those security assumptions we 634 00:40:25,876 --> 00:40:28,209 have a, you know, let's sort of put a framework 635 00:40:28,209 --> 00:40:30,417 up for a threat model. 636 00:40:30,417 --> 00:40:32,792 We want to do a realistic threat assessment where we 637 00:40:32,792 --> 00:40:36,459 realize that not every system is threatened. 638 00:40:48,334 --> 00:40:51,999 Not all theoretical attacks and I think a good analogy 639 00:40:51,999 --> 00:40:55,167 is thinking about safe security. 640 00:40:55,250 --> 00:40:58,209 Every safe can be eventually broken and it is a question 641 00:40:58,209 --> 00:41:01,626 of how much time you have to reverse engineer and how much time 642 00:41:01,626 --> 00:41:05,375 you have to break it but eventually it can be broken. 643 00:41:05,751 --> 00:41:07,999 So I think we need to think about our systems in the context 644 00:41:07,999 --> 00:41:11,584 of having physical security defenses in terms of hours rather than minutes 645 00:41:11,584 --> 00:41:13,709 that we have right now. 646 00:41:14,083 --> 00:41:16,167 And as always if I screw up, if I omitted 647 00:41:16,167 --> 00:41:20,999 an assumption that you don't think holds, prove it, verify it, verify mine 648 00:41:20,999 --> 00:41:24,083 and make sure I am right or wrong. 649 00:41:25,667 --> 00:41:28,209 And so expected security, this is what actually gets 650 00:41:28,209 --> 00:41:31,334 a cold boot attack is not going to be effective against keys, 651 00:41:31,334 --> 00:41:33,834 and stuff that you have in main memory is going 652 00:41:33,834 --> 00:41:37,083 to be restricted by whatever you have in clear. 653 00:41:38,626 --> 00:41:41,083 Hardware based RAM acquisition is not going to be effective 654 00:41:41,083 --> 00:41:44,667 because they are going to be IOMMU sandboxed to nothing. 655 00:41:44,667 --> 00:41:46,999 You are not going to get application state or system state 656 00:41:46,999 --> 00:41:50,999 and even if you manage to extract the secrets out of a TPM all it 657 00:41:50,999 --> 00:41:55,167 is going to do is get you back to where we are right now. 658 00:41:55,375 --> 00:41:58,083 Where although it is easily broken you are still not 659 00:41:58,083 --> 00:42:01,667 all the way down to 0 and sort of sending assumption here 660 00:42:01,667 --> 00:42:06,083 if you have a good security habit policy which is reasonable say 12 hours 661 00:42:06,083 --> 00:42:10,167 of no contact to your computer you should be okay. 662 00:42:15,999 --> 00:42:17,834 A couple of attack methods which are really 663 00:42:17,834 --> 00:42:19,792 like these are the main ones that I would attack 664 00:42:19,792 --> 00:42:22,083 if I were trying to break in to a system that use something 665 00:42:22,083 --> 00:42:23,584 like this. 666 00:42:23,584 --> 00:42:29,999 Key loggers and friends are still going to be very much not defended against, 667 00:42:29,999 --> 00:42:36,876 you can do mitigation against this by using one time token, TPM attacks, 668 00:42:36,876 --> 00:42:40,459 MV RAM extraction or LC bus. 669 00:42:41,999 --> 00:42:44,375 Find some way of tricking the TPM in to getting 670 00:42:44,375 --> 00:42:48,417 in to a configuration that thinks is trustworthy but is not. 671 00:42:48,999 --> 00:42:51,334 In RAM manipulation if you have something 672 00:42:51,334 --> 00:42:54,501 like that looks like RAM but is not RAM but it pretends 673 00:42:54,501 --> 00:42:57,292 to be RAM but lets you manipulate externally there 674 00:42:57,292 --> 00:43:00,250 is nothing that you can do because you would be able 675 00:43:00,250 --> 00:43:04,209 to manipulate the content of the system, no problem. 676 00:43:04,709 --> 00:43:08,209 You can try transient pulse injection. 677 00:43:09,667 --> 00:43:15,334 I will do a quick bit about legal notes. 678 00:43:15,334 --> 00:43:16,876 I am not your lawyer. 679 00:43:17,709 --> 00:43:20,083 As far as I know if you have okay. 680 00:43:20,250 --> 00:43:26,626 If you have self destruct as far as I know it is not illegal yet. 681 00:43:26,667 --> 00:43:28,999 But there has been no legal test case of this. 682 00:43:28,999 --> 00:43:30,751 It might be interesting to find out. 683 00:43:31,334 --> 00:43:34,125 But I am not sure I would want to do that test case either. 684 00:43:36,125 --> 00:43:42,918 TPM and strong encryption is not it is illegal in certain jurisdictions. 685 00:43:42,918 --> 00:43:45,792 You can't use a TPM in China or Russia. 686 00:43:45,999 --> 00:43:48,999 In some countries like the United Kingdom you have 687 00:43:48,999 --> 00:43:51,542 mandatory key disclosure. 688 00:43:51,542 --> 00:43:54,125 You will go to prison if you do not hand over a key. 689 00:43:57,375 --> 00:44:01,083 Future work and improvements, production version, stable version, 690 00:44:01,083 --> 00:44:03,751 right now it is not stable. 691 00:44:04,083 --> 00:44:06,999 If you put your computer to sleep, it will emit your data. 692 00:44:09,501 --> 00:44:11,083 I am working on it. 693 00:44:11,999 --> 00:44:13,999 Some other things that might be fun to do in the future 694 00:44:13,999 --> 00:44:15,999 like open SLQ is important. 695 00:44:15,999 --> 00:44:19,999 If some API that you can do to basically let you swap 696 00:44:19,999 --> 00:44:24,417 out your contents of memory very, very quickly. 697 00:44:24,417 --> 00:44:26,167 So your exposure time is very small. 698 00:44:26,959 --> 00:44:30,125 You can all install and maybe upstream the patches to Linux and Zen and 699 00:44:30,125 --> 00:44:33,751 the goons are getting ready to kick me off the stage. 700 00:44:34,542 --> 00:44:36,209 Conclusions. 701 00:44:36,209 --> 00:44:37,209 I am almost done. 702 00:44:37,459 --> 00:44:39,584 So best security in the world goes unused 703 00:44:39,584 --> 00:44:41,501 if it is unusable. 704 00:44:41,834 --> 00:44:45,083 Model needs to account for realistic use patterns. 705 00:44:45,459 --> 00:44:47,584 And it is not just disk encryption. 706 00:44:47,584 --> 00:44:50,792 You need to think about it from the whole system. 707 00:44:51,167 --> 00:44:53,083 It is challenging to do this but I think it is possible 708 00:44:53,083 --> 00:44:54,959 and we should try. 709 00:44:55,167 --> 00:44:56,167 Thank you.