0 00:00:00,000 --> 00:00:30,000 Dear viewer, these subtitles were generated by a machine via the service Trint and therefore are (very) buggy. If you are capable, please help us to create good quality subtitles: https://c3subtitles.de/talk/564 Thanks! 1 00:00:10,510 --> 00:00:12,999 And now our first talk here today 2 00:00:13,000 --> 00:00:15,099 will be about an evil made at 3 00:00:15,100 --> 00:00:17,169 us. We'll find out how to actually 4 00:00:17,170 --> 00:00:19,599 make sure that the piece of software 5 00:00:19,600 --> 00:00:21,699 that you type in, for example, your hard 6 00:00:21,700 --> 00:00:23,739 drive password every morning, is actually 7 00:00:23,740 --> 00:00:25,569 a piece of software that you think it is. 8 00:00:25,570 --> 00:00:27,460 So please welcome Matthew. 9 00:00:34,600 --> 00:00:36,879 Good morning. So first of all, I'd like 10 00:00:36,880 --> 00:00:38,859 to say that it's wonderful that so many 11 00:00:38,860 --> 00:00:41,079 of you have been able to make it to this 12 00:00:41,080 --> 00:00:42,549 completely unreasonable time in the 13 00:00:42,550 --> 00:00:43,550 morning. 14 00:00:46,220 --> 00:00:48,469 I appreciate this quick 15 00:00:48,470 --> 00:00:50,149 introduction. My name's Matthew Garita, 16 00:00:50,150 --> 00:00:52,699 I'm a security developer at Choros, 17 00:00:52,700 --> 00:00:54,769 but I'm also on the board of 18 00:00:54,770 --> 00:00:56,209 directors of the Free Software 19 00:00:56,210 --> 00:00:57,199 Foundation. 20 00:00:57,200 --> 00:00:59,839 So while I'm very interested in 21 00:00:59,840 --> 00:01:02,209 security, especially very 22 00:01:02,210 --> 00:01:04,549 low level security, securing the 23 00:01:04,550 --> 00:01:06,349 platform before we even get to the point 24 00:01:06,350 --> 00:01:08,539 of running applications, I focus 25 00:01:08,540 --> 00:01:10,609 as far as possible on ensuring 26 00:01:10,610 --> 00:01:12,739 that any security work 27 00:01:12,740 --> 00:01:14,809 I do still 28 00:01:14,810 --> 00:01:16,909 permits the owner of the computer 29 00:01:16,910 --> 00:01:18,529 to be the person who makes the ultimate 30 00:01:18,530 --> 00:01:19,909 decision about what they want their 31 00:01:19,910 --> 00:01:22,069 security policy to be, what software they 32 00:01:22,070 --> 00:01:23,449 want to be able to run. 33 00:01:23,450 --> 00:01:25,519 Because it's unfortunate when 34 00:01:25,520 --> 00:01:27,229 we make security choices that make it 35 00:01:27,230 --> 00:01:29,509 impossible for people to have 36 00:01:29,510 --> 00:01:31,430 free control of their own systems. 37 00:01:33,320 --> 00:01:35,629 So the quick just 38 00:01:37,100 --> 00:01:38,180 so the quick 39 00:01:39,800 --> 00:01:42,079 corporate sponsorship thing, we just 40 00:01:42,080 --> 00:01:44,419 opened an office in Berlin. 41 00:01:44,420 --> 00:01:46,249 Chat to me if you are interested in 42 00:01:46,250 --> 00:01:47,269 working on this kind of stuff. 43 00:01:48,380 --> 00:01:50,269 Well, as we talked about today is the 44 00:01:50,270 --> 00:01:52,339 problem of how you 45 00:01:52,340 --> 00:01:54,409 can fundamentally know that your 46 00:01:54,410 --> 00:01:56,329 computer is trustworthy. 47 00:01:57,950 --> 00:01:59,569 In this case, when I say trustworthy, 48 00:01:59,570 --> 00:02:01,459 what I mean is the computer will not 49 00:02:01,460 --> 00:02:03,619 betray you. The computer is 50 00:02:03,620 --> 00:02:05,569 operating in your best interest. 51 00:02:05,570 --> 00:02:08,029 The computer is not choosing 52 00:02:08,030 --> 00:02:10,728 to circumvent your decisions 53 00:02:10,729 --> 00:02:13,069 and make life easier for 54 00:02:13,070 --> 00:02:15,319 people who are not you. 55 00:02:15,320 --> 00:02:17,479 And so we've seen cases where, for 56 00:02:17,480 --> 00:02:19,639 instance, in DRM computers are 57 00:02:19,640 --> 00:02:21,529 untrustworthy because they refuse to let 58 00:02:21,530 --> 00:02:22,909 you do what you want to do. 59 00:02:22,910 --> 00:02:25,129 But from a security perspective, we also 60 00:02:25,130 --> 00:02:27,499 want to be sure that a computer 61 00:02:27,500 --> 00:02:29,959 is taking your secrets 62 00:02:29,960 --> 00:02:32,209 and holding them and treating them 63 00:02:32,210 --> 00:02:33,329 in a trustworthy manner. 64 00:02:33,330 --> 00:02:34,669 It's not releasing those secrets to 65 00:02:34,670 --> 00:02:35,629 anybody else. 66 00:02:35,630 --> 00:02:37,789 It's not holding 67 00:02:37,790 --> 00:02:40,219 onto them and then using them 68 00:02:40,220 --> 00:02:41,690 to leak data about you. 69 00:02:43,900 --> 00:02:46,119 So part of that positive thinking 70 00:02:46,120 --> 00:02:48,279 about how we define the trustworthiness 71 00:02:48,280 --> 00:02:50,529 of the computer is knowing when we trust 72 00:02:50,530 --> 00:02:51,639 a computer. 73 00:02:51,640 --> 00:02:53,769 And up until the point where you 74 00:02:53,770 --> 00:02:55,989 start putting secrets into 75 00:02:55,990 --> 00:02:57,879 a computer, it doesn't matter whether 76 00:02:57,880 --> 00:02:59,829 it's trustworthy or not, it doesn't have 77 00:02:59,830 --> 00:03:01,539 any way to harm you. 78 00:03:01,540 --> 00:03:03,639 Now, secrets are obviously things 79 00:03:03,640 --> 00:03:05,109 like passwords, past freezes. 80 00:03:05,110 --> 00:03:06,699 Secrets are also things like your 81 00:03:06,700 --> 00:03:07,779 browsing history. 82 00:03:07,780 --> 00:03:09,849 Secrets are anything 83 00:03:09,850 --> 00:03:12,039 that is not information 84 00:03:12,040 --> 00:03:12,969 that you would necessarily wish to 85 00:03:12,970 --> 00:03:14,019 publish entirely. 86 00:03:14,020 --> 00:03:15,069 I'm only going to be talking about the 87 00:03:15,070 --> 00:03:17,379 former stuff, but in terms 88 00:03:17,380 --> 00:03:19,779 of building a fully trustworthy platform, 89 00:03:19,780 --> 00:03:22,509 you need to have trustworthiness 90 00:03:22,510 --> 00:03:24,579 from the very beginning of the book 91 00:03:24,580 --> 00:03:26,799 process before you enter 92 00:03:26,800 --> 00:03:28,899 any secrets. Your computer must 93 00:03:28,900 --> 00:03:30,559 be in a trustworthy state. 94 00:03:30,560 --> 00:03:31,779 You need to be able to look at your 95 00:03:31,780 --> 00:03:33,879 computer and say, I trust this 96 00:03:33,880 --> 00:03:34,880 computer. 97 00:03:36,920 --> 00:03:39,199 Because if that's not true, 98 00:03:39,200 --> 00:03:41,359 how do you know that the software that 99 00:03:41,360 --> 00:03:43,489 you're typing your password into 100 00:03:43,490 --> 00:03:46,189 is operating in your best interests 101 00:03:46,190 --> 00:03:47,269 and the free software world? 102 00:03:47,270 --> 00:03:48,649 We can examine the source codes. 103 00:03:48,650 --> 00:03:50,689 We can have a lot of people independently 104 00:03:50,690 --> 00:03:51,919 reviewing it. And that means that there 105 00:03:51,920 --> 00:03:54,169 is perhaps a higher probability 106 00:03:54,170 --> 00:03:56,359 of us being able to look at this software 107 00:03:56,360 --> 00:03:58,159 and say, yes, this software is 108 00:03:58,160 --> 00:03:59,269 trustworthy. 109 00:03:59,270 --> 00:04:01,099 But once that's been compiled, once 110 00:04:01,100 --> 00:04:02,659 that's on disk, if someone is able to 111 00:04:02,660 --> 00:04:05,239 modify that software 112 00:04:05,240 --> 00:04:07,139 on your hard drive, then it's may 113 00:04:07,140 --> 00:04:09,199 transition from being trusted 114 00:04:09,200 --> 00:04:10,879 to untrusted. 115 00:04:10,880 --> 00:04:12,499 So if someone is able to get access to 116 00:04:12,500 --> 00:04:13,939 your system and then modify the contents 117 00:04:13,940 --> 00:04:15,919 of that, then you're in an unfortunate 118 00:04:15,920 --> 00:04:16,920 position. 119 00:04:19,220 --> 00:04:21,499 But it's worse than that because 120 00:04:21,500 --> 00:04:23,809 that software is running on top of 121 00:04:23,810 --> 00:04:25,309 an operating system, Colonel. 122 00:04:25,310 --> 00:04:27,679 And how do you know that the colonel 123 00:04:27,680 --> 00:04:30,139 itself has not modified 124 00:04:30,140 --> 00:04:31,140 that software? 125 00:04:33,370 --> 00:04:35,949 A sufficiently modified 126 00:04:35,950 --> 00:04:38,109 currently back Col is 127 00:04:38,110 --> 00:04:40,269 able to arbitrarily modify 128 00:04:40,270 --> 00:04:42,189 the behavior of any userspace 129 00:04:42,190 --> 00:04:44,319 applications, even if you had 130 00:04:44,320 --> 00:04:46,419 some way to verify that your userspace 131 00:04:46,420 --> 00:04:47,919 application was trustworthy, that the 132 00:04:47,920 --> 00:04:50,199 passphrase had the program 133 00:04:50,200 --> 00:04:51,639 taking your description, passphrase had 134 00:04:51,640 --> 00:04:53,379 not been modified. If the kernels be 135 00:04:53,380 --> 00:04:55,299 modified, it doesn't matter. 136 00:04:55,300 --> 00:04:57,100 The kernel can still subvert that. 137 00:04:58,540 --> 00:05:00,909 But say you have some mechanism to verify 138 00:05:00,910 --> 00:05:02,469 that the kernel is good when it's right 139 00:05:02,470 --> 00:05:03,549 off disk. 140 00:05:03,550 --> 00:05:05,879 How do you know that the bootloader 141 00:05:05,880 --> 00:05:07,629 that ripped the kernel off disk and then 142 00:05:07,630 --> 00:05:09,939 verified kernel states didn't then modify 143 00:05:09,940 --> 00:05:12,159 the kernel, which could then 144 00:05:12,160 --> 00:05:14,319 modify the application and 145 00:05:14,320 --> 00:05:16,419 then stoya passphrase or send it off 146 00:05:16,420 --> 00:05:17,499 to somewhere and pleasant? 147 00:05:19,180 --> 00:05:21,429 The bootloader, OK, say we have a means 148 00:05:21,430 --> 00:05:23,469 of verifying the bootloader, how do we 149 00:05:23,470 --> 00:05:25,659 ensure that the firmware that launched 150 00:05:25,660 --> 00:05:27,609 the bootloader didn't tamper with the 151 00:05:27,610 --> 00:05:29,629 bootloader that launches the kernel that 152 00:05:29,630 --> 00:05:31,479 can then be tampered with to tamper with 153 00:05:31,480 --> 00:05:33,249 the software that reads your passphrase? 154 00:05:36,420 --> 00:05:38,639 And fine, OK, we solve all of that 155 00:05:38,640 --> 00:05:40,919 and then, well, fundamentally, at some 156 00:05:40,920 --> 00:05:43,119 point, the CPU itself is obviously 157 00:05:43,120 --> 00:05:45,359 executing this code is capable of doing 158 00:05:45,360 --> 00:05:46,559 whatever it wants. 159 00:05:46,560 --> 00:05:49,079 And if the CPU is not trustworthy, then 160 00:05:49,080 --> 00:05:51,059 there is no way to trust the firmware in 161 00:05:51,060 --> 00:05:52,229 the way. Trust the bootloader that we 162 00:05:52,230 --> 00:05:54,449 trust the kernel. No way to trust the 163 00:05:54,450 --> 00:05:55,450 password prompt. 164 00:05:59,760 --> 00:06:01,619 Figuring out how to trust the CPU is a 165 00:06:01,620 --> 00:06:02,609 hard problem. 166 00:06:02,610 --> 00:06:03,610 I'm going to ignore it. 167 00:06:09,190 --> 00:06:11,079 But figuring out the trustworthiness of 168 00:06:11,080 --> 00:06:13,149 the rest of the system is more 169 00:06:13,150 --> 00:06:15,009 practical, not necessarily to the extent 170 00:06:15,010 --> 00:06:17,349 that everybody would like, but 171 00:06:17,350 --> 00:06:18,369 to a reasonable extent, 172 00:06:20,170 --> 00:06:22,539 trusted computing was a phrase 173 00:06:22,540 --> 00:06:24,669 that started appearing a little 174 00:06:24,670 --> 00:06:26,919 over 10 years ago in the early 2000s, and 175 00:06:26,920 --> 00:06:28,419 at that point, trusted computing. 176 00:06:28,420 --> 00:06:30,879 It was clear it was going to be used as 177 00:06:30,880 --> 00:06:33,669 a mechanism to ensure 178 00:06:33,670 --> 00:06:35,949 that our computers, the computers 179 00:06:35,950 --> 00:06:38,109 we owned, could be trusted 180 00:06:38,110 --> 00:06:40,209 by media companies, 181 00:06:40,210 --> 00:06:42,669 could be trusted by proprietary 182 00:06:42,670 --> 00:06:43,689 software developers. 183 00:06:43,690 --> 00:06:45,519 We felt that the way that trusted 184 00:06:45,520 --> 00:06:48,099 computing was inevitably going to be used 185 00:06:48,100 --> 00:06:50,229 was for 186 00:06:50,230 --> 00:06:52,569 our computers to be 187 00:06:52,570 --> 00:06:54,759 out of our control, that people 188 00:06:54,760 --> 00:06:56,289 would use this technology to restrict 189 00:06:56,290 --> 00:06:58,299 what we could do with our computers. 190 00:06:58,300 --> 00:07:00,729 Thankfully, none of that's happened. 191 00:07:00,730 --> 00:07:02,919 And there's various technological and 192 00:07:02,920 --> 00:07:04,659 political reasons for that, which I'm not 193 00:07:04,660 --> 00:07:05,660 going to go into today. 194 00:07:07,300 --> 00:07:09,609 At the heart of trusted computing is 195 00:07:09,610 --> 00:07:12,129 a component called a trusted platform 196 00:07:12,130 --> 00:07:13,130 module. 197 00:07:13,690 --> 00:07:15,459 Most of the time, a trusted platform 198 00:07:15,460 --> 00:07:16,990 module is a small, 199 00:07:18,250 --> 00:07:19,269 discrete. 200 00:07:19,270 --> 00:07:21,129 I see. That's on your system 201 00:07:21,130 --> 00:07:23,199 motherboards. It's typically on the LPC 202 00:07:23,200 --> 00:07:25,449 bus. The TPM 203 00:07:25,450 --> 00:07:27,699 does not have any ability 204 00:07:27,700 --> 00:07:30,039 to access system memory directly. 205 00:07:30,040 --> 00:07:32,289 The TPM can only do what 206 00:07:32,290 --> 00:07:34,329 is asked to do. The TPM cannot 207 00:07:34,330 --> 00:07:36,579 independently modify system state. 208 00:07:36,580 --> 00:07:38,949 The TPM has no way 209 00:07:38,950 --> 00:07:40,779 of reaching out and looking at the 210 00:07:40,780 --> 00:07:42,549 contents of RAM and figuring out what 211 00:07:42,550 --> 00:07:43,749 you're running. 212 00:07:43,750 --> 00:07:46,149 The TPM can only do 213 00:07:46,150 --> 00:07:47,169 what it's told to do. 214 00:07:47,170 --> 00:07:49,539 It can only know what it's explicitly 215 00:07:49,540 --> 00:07:50,540 told about. 216 00:07:51,470 --> 00:07:53,599 If you never run 217 00:07:53,600 --> 00:07:56,029 any code that touches the TPM, the TPM 218 00:07:56,030 --> 00:07:58,249 can do nothing to TPM, cannot phone home 219 00:07:58,250 --> 00:08:00,649 on its own, the TPM cannot 220 00:08:00,650 --> 00:08:01,939 interfere with your ability to run 221 00:08:01,940 --> 00:08:02,940 software. 222 00:08:04,690 --> 00:08:06,189 For the most part, on free software 223 00:08:06,190 --> 00:08:08,349 platforms, we have completely ignored 224 00:08:08,350 --> 00:08:10,509 the TPM because 225 00:08:10,510 --> 00:08:12,429 most things we can think of to do with it 226 00:08:12,430 --> 00:08:14,410 were not particularly beneficial to us. 227 00:08:16,940 --> 00:08:19,099 At the TPM has one 228 00:08:19,100 --> 00:08:21,709 fascinating feature, which is inherent 229 00:08:21,710 --> 00:08:23,869 to the trusted computing goal, the 230 00:08:23,870 --> 00:08:25,669 idea that we can define whether a 231 00:08:25,670 --> 00:08:27,799 computer is in a trusted state, and 232 00:08:27,800 --> 00:08:29,540 that's something called measurement. 233 00:08:31,670 --> 00:08:32,899 Insecure about 234 00:08:34,010 --> 00:08:36,109 each component verifies a 235 00:08:36,110 --> 00:08:38,058 cryptographic signature on the following 236 00:08:38,059 --> 00:08:40,249 components and refuses to run it 237 00:08:40,250 --> 00:08:41,839 if that signature doesn't match 238 00:08:43,039 --> 00:08:45,529 in trusted computing, 239 00:08:45,530 --> 00:08:47,929 your ability to run arbitrary 240 00:08:47,930 --> 00:08:49,639 software is in no way restricted. 241 00:08:49,640 --> 00:08:51,499 There is no validation of signatures. 242 00:08:51,500 --> 00:08:53,389 There are no keys involved in this at 243 00:08:53,390 --> 00:08:54,379 this stage. 244 00:08:54,380 --> 00:08:56,449 Instead, every 245 00:08:56,450 --> 00:08:59,089 component measure is the next component. 246 00:08:59,090 --> 00:09:00,950 And stores that in the TPM. 247 00:09:02,800 --> 00:09:05,079 And measurements in this case is just 248 00:09:05,080 --> 00:09:06,940 a sha one hash and. 249 00:09:09,280 --> 00:09:11,439 Just as a brief clarification here, 250 00:09:11,440 --> 00:09:13,749 TPM version of the TPIMs version, 251 00:09:13,750 --> 00:09:15,519 one point two is what I'm most going to 252 00:09:15,520 --> 00:09:17,829 be talking about. TPM 2.0 253 00:09:17,830 --> 00:09:19,929 is now available and devices 254 00:09:19,930 --> 00:09:21,969 are beginning to appear. 255 00:09:21,970 --> 00:09:24,099 But pretty much every single TPM 256 00:09:24,100 --> 00:09:25,419 that's currently available in the wild is 257 00:09:25,420 --> 00:09:27,489 a one point two device and they 258 00:09:27,490 --> 00:09:29,919 uninfluential one more. 259 00:09:29,920 --> 00:09:32,019 TPM to devices have support 260 00:09:32,020 --> 00:09:33,969 for basically arbitrary hash algorithms, 261 00:09:33,970 --> 00:09:35,590 including some that are actually good. 262 00:09:38,920 --> 00:09:41,019 So in a measured Bhoot. 263 00:09:42,750 --> 00:09:44,939 The first component looks 264 00:09:44,940 --> 00:09:47,489 at the next component to be executed 265 00:09:47,490 --> 00:09:49,619 and before executing, it 266 00:09:49,620 --> 00:09:51,539 takes a shower, one of that. 267 00:09:52,670 --> 00:09:54,739 And then it's right that 268 00:09:54,740 --> 00:09:56,959 sha one value into a 269 00:09:56,960 --> 00:09:59,029 platform configuration register 270 00:09:59,030 --> 00:10:00,379 or a PCR. 271 00:10:02,160 --> 00:10:03,870 When we say it's written, 272 00:10:05,460 --> 00:10:07,679 extend is a meaningful words hit 273 00:10:07,680 --> 00:10:09,869 when a value is written, it does not 274 00:10:09,870 --> 00:10:12,179 replace the existing value. 275 00:10:12,180 --> 00:10:14,369 It's not possible to arbitrarily 276 00:10:14,370 --> 00:10:16,559 overwrite the existing contents of 277 00:10:16,560 --> 00:10:19,410 a PCR instead. 278 00:10:22,490 --> 00:10:25,070 The existing content of the PCR. 279 00:10:26,140 --> 00:10:28,599 Is prepend it to the new value, 280 00:10:28,600 --> 00:10:31,359 so you had 20 points in the picture, 281 00:10:31,360 --> 00:10:33,519 you wrote a 20 Blanka one, 282 00:10:33,520 --> 00:10:35,979 and now you have a 40 283 00:10:35,980 --> 00:10:36,999 byte value. 284 00:10:38,160 --> 00:10:40,439 And that 40 point value is 285 00:10:40,440 --> 00:10:42,719 then again hashed 286 00:10:42,720 --> 00:10:44,999 again with Shahd one and the 287 00:10:45,000 --> 00:10:47,099 PCR is set 288 00:10:47,100 --> 00:10:48,389 to that value. 289 00:10:49,650 --> 00:10:51,929 So this means that the new 290 00:10:51,930 --> 00:10:54,149 value of the PCR depends on 291 00:10:54,150 --> 00:10:55,150 the previous value, 292 00:10:56,250 --> 00:10:58,709 which means that there is basically three 293 00:10:58,710 --> 00:11:01,019 ways to get a specific 294 00:11:01,020 --> 00:11:02,020 PCR value. 295 00:11:03,170 --> 00:11:04,170 And those are. 296 00:11:06,240 --> 00:11:07,240 Bring shall one. 297 00:11:09,210 --> 00:11:11,489 So if you are able to figure out 298 00:11:11,490 --> 00:11:13,709 a way to add 20 299 00:11:13,710 --> 00:11:15,599 bytes of arbitrary data to the existing 300 00:11:15,600 --> 00:11:18,659 PCR value such that you control 301 00:11:18,660 --> 00:11:20,939 the new shall one value, then you 302 00:11:20,940 --> 00:11:22,409 can completely break trusted boot. 303 00:11:24,230 --> 00:11:26,510 If any of you know how to break SHA one. 304 00:11:27,720 --> 00:11:29,579 I'm going to be a little bit unhappy. 305 00:11:30,750 --> 00:11:32,879 And various other people are going to be 306 00:11:32,880 --> 00:11:34,139 very, very unhappy. 307 00:11:35,330 --> 00:11:37,399 And we're all going to have bad 308 00:11:37,400 --> 00:11:38,689 days. 309 00:11:38,690 --> 00:11:40,819 So, again, I'm going 310 00:11:40,820 --> 00:11:43,249 to ignore this possibility because 311 00:11:43,250 --> 00:11:45,349 it's far too terrifying and we can't do 312 00:11:45,350 --> 00:11:46,350 anything about it anyway. 313 00:11:48,080 --> 00:11:49,969 Another is to trigger execution of 314 00:11:49,970 --> 00:11:52,340 arbitrary code through unmeasured data. 315 00:11:53,870 --> 00:11:56,449 Measurements typically only measures 316 00:11:56,450 --> 00:11:58,669 the code 317 00:11:58,670 --> 00:12:00,559 at a few exceptions, but basically it 318 00:12:00,560 --> 00:12:01,560 measures the code. 319 00:12:02,810 --> 00:12:04,880 That code has to operate on data. 320 00:12:07,150 --> 00:12:09,459 As a species, we're pretty 321 00:12:09,460 --> 00:12:10,899 bad at writing code. 322 00:12:12,060 --> 00:12:14,399 We're even worse at writing code 323 00:12:14,400 --> 00:12:16,589 that deals with data 324 00:12:16,590 --> 00:12:19,049 and we're astonishingly bad at writing 325 00:12:19,050 --> 00:12:21,119 code that deals with arbitrary use of 326 00:12:21,120 --> 00:12:22,120 provider data. 327 00:12:24,930 --> 00:12:27,089 A break 328 00:12:27,090 --> 00:12:29,339 in trusted computing process 329 00:12:29,340 --> 00:12:31,619 was demonstrated by the Invisible Things 330 00:12:31,620 --> 00:12:33,929 labs through the simple 331 00:12:33,930 --> 00:12:35,519 expedient of noticing that. 332 00:12:38,170 --> 00:12:40,359 The firmware allows you to 333 00:12:40,360 --> 00:12:42,429 provide a boots picture 334 00:12:42,430 --> 00:12:43,430 in the firmware. 335 00:12:44,650 --> 00:12:45,999 And this meant the people buying the 336 00:12:46,000 --> 00:12:48,189 boards from Intel could 337 00:12:48,190 --> 00:12:50,619 replace the boots with something, 338 00:12:50,620 --> 00:12:52,809 including their company brands, rather 339 00:12:52,810 --> 00:12:54,460 than just having a generic Intel logo. 340 00:12:55,630 --> 00:12:57,909 The problem was the format's was 341 00:12:57,910 --> 00:13:00,189 BNP, the Microsoft 342 00:13:00,190 --> 00:13:02,259 bitmap format, and 343 00:13:02,260 --> 00:13:04,029 that includes run length encoding 344 00:13:04,030 --> 00:13:06,699 support, i.e., you can say 345 00:13:06,700 --> 00:13:09,609 the next value represents 346 00:13:09,610 --> 00:13:11,529 256 of these values. 347 00:13:11,530 --> 00:13:13,790 So it's a lossless compression mechanism. 348 00:13:14,890 --> 00:13:17,499 There was nothing in the code 349 00:13:17,500 --> 00:13:19,839 to check that the 350 00:13:19,840 --> 00:13:23,229 coding did not result in you overrunning 351 00:13:23,230 --> 00:13:25,599 the buffer that the 352 00:13:25,600 --> 00:13:27,939 bitmap was being decompressed into, 353 00:13:27,940 --> 00:13:30,309 which let you overwrite arbitrary code 354 00:13:30,310 --> 00:13:31,389 in the firmware. 355 00:13:31,390 --> 00:13:33,519 And then since 356 00:13:33,520 --> 00:13:35,709 the bitmap was on measures, you then 357 00:13:35,710 --> 00:13:37,659 had arbitrary codes execution, which 358 00:13:37,660 --> 00:13:40,689 meant that you could then modify 359 00:13:40,690 --> 00:13:43,179 the following stage, but right 360 00:13:43,180 --> 00:13:46,299 the correct one value into the PCR 361 00:13:46,300 --> 00:13:47,380 so everything would look good. 362 00:13:49,870 --> 00:13:51,249 If your phone was not trustworthy, if 363 00:13:51,250 --> 00:13:53,439 your firm was not competent, 364 00:13:53,440 --> 00:13:54,879 then your firm where cannot be 365 00:13:54,880 --> 00:13:56,139 trustworthy. 366 00:13:56,140 --> 00:13:58,239 So the fact that the majority of us 367 00:13:58,240 --> 00:14:00,579 are running proprietary firmware 368 00:14:00,580 --> 00:14:02,439 with no available source code and we 369 00:14:02,440 --> 00:14:04,599 can't verify this, any of it is any use 370 00:14:04,600 --> 00:14:06,729 whatsoever is a minor problem 371 00:14:06,730 --> 00:14:07,730 here. 372 00:14:08,860 --> 00:14:10,809 And finally, you can perform exactly the 373 00:14:10,810 --> 00:14:12,399 same sequence of rights to the picture, 374 00:14:12,400 --> 00:14:13,599 and this is what happens in the normal 375 00:14:13,600 --> 00:14:15,909 boot, if nothing's been modified, 376 00:14:15,910 --> 00:14:17,979 then the one of every components will 377 00:14:17,980 --> 00:14:18,879 match. 378 00:14:18,880 --> 00:14:21,189 You perform the same 379 00:14:21,190 --> 00:14:23,559 sequence of PCR 380 00:14:23,560 --> 00:14:25,899 updates and you end up with the same PCR 381 00:14:25,900 --> 00:14:26,799 values. 382 00:14:26,800 --> 00:14:28,119 So that's great. 383 00:14:28,120 --> 00:14:30,849 If the system Boutte's correctly, 384 00:14:30,850 --> 00:14:32,979 then the PCR values 385 00:14:32,980 --> 00:14:34,359 will always be the same. 386 00:14:34,360 --> 00:14:36,489 As long as no systems have been, as 387 00:14:36,490 --> 00:14:37,539 long as not components of being 388 00:14:37,540 --> 00:14:38,540 interfered with. 389 00:14:40,220 --> 00:14:41,719 But there's a minor problem here. 390 00:14:44,050 --> 00:14:46,209 Has we read those values 391 00:14:46,210 --> 00:14:48,279 and the straightforward answer 392 00:14:48,280 --> 00:14:50,529 is very simple, we 393 00:14:50,530 --> 00:14:51,530 just. 394 00:14:52,480 --> 00:14:54,579 Ask the hospital what the 395 00:14:54,580 --> 00:14:55,629 PCR values are. 396 00:14:55,630 --> 00:14:57,309 There's a command you send to it and then 397 00:14:57,310 --> 00:14:58,419 it gives you that. 398 00:14:58,420 --> 00:15:00,819 So that seems like a straightforward 399 00:15:00,820 --> 00:15:01,719 answer. 400 00:15:01,720 --> 00:15:03,999 But the TPM is hardware 401 00:15:04,000 --> 00:15:05,619 if we talk to hardware through the 402 00:15:05,620 --> 00:15:06,620 kernel. 403 00:15:08,070 --> 00:15:10,169 The colonel can just lie to 404 00:15:10,170 --> 00:15:11,279 us. 405 00:15:11,280 --> 00:15:13,559 The colonel could give back whatever PCR 406 00:15:13,560 --> 00:15:15,269 values the colonel wanted to. 407 00:15:17,170 --> 00:15:19,509 And this, again, is kind 408 00:15:19,510 --> 00:15:21,879 of a problem, the entire point of this is 409 00:15:21,880 --> 00:15:23,589 to determine whether we can trust the 410 00:15:23,590 --> 00:15:25,239 colonel and if the colonel's 411 00:15:25,240 --> 00:15:27,549 untrustworthy, we have no means 412 00:15:27,550 --> 00:15:29,529 of determining whether the answer is 413 00:15:29,530 --> 00:15:30,530 accurate or not. 414 00:15:31,960 --> 00:15:33,849 If we get back incorrect values, we know 415 00:15:33,850 --> 00:15:35,199 something's wrong, but getting back 416 00:15:35,200 --> 00:15:36,669 correct values does not mean that 417 00:15:36,670 --> 00:15:37,670 everything's OK. 418 00:15:39,820 --> 00:15:41,409 It's the standard way of dealing with 419 00:15:41,410 --> 00:15:43,129 this. Well, something called remote 420 00:15:43,130 --> 00:15:45,279 station, and this was 421 00:15:45,280 --> 00:15:46,779 the thing that we were most concerned 422 00:15:46,780 --> 00:15:49,029 about in terms of trusted computing 423 00:15:49,030 --> 00:15:51,489 back in the early 2000s. 424 00:15:51,490 --> 00:15:54,129 Remote as a station is a protocol 425 00:15:54,130 --> 00:15:56,529 where the TPM 426 00:15:56,530 --> 00:15:58,629 has a cryptographic conversation 427 00:15:58,630 --> 00:16:00,009 with a remote server. 428 00:16:00,010 --> 00:16:02,319 Every TPM has what's called an 429 00:16:02,320 --> 00:16:04,479 endorsement key built in and the 430 00:16:04,480 --> 00:16:06,959 endorsement key has a certificate. 431 00:16:06,960 --> 00:16:09,129 It's the change back to the TPM 432 00:16:09,130 --> 00:16:11,289 manufacturer so you can 433 00:16:11,290 --> 00:16:13,299 ask the TPM to sign something with its 434 00:16:13,300 --> 00:16:15,819 endorsement key. You can ask the TPM for 435 00:16:15,820 --> 00:16:17,589 the endorsement certificates. 436 00:16:17,590 --> 00:16:19,119 You can verify that the endorsement 437 00:16:19,120 --> 00:16:20,469 certificate changed back to the TPM 438 00:16:20,470 --> 00:16:22,659 vendor. You can verify that the 439 00:16:22,660 --> 00:16:24,909 TPM is able to sign something 440 00:16:24,910 --> 00:16:27,039 with that key, and that means that 441 00:16:27,040 --> 00:16:29,139 the TPM has control of 442 00:16:29,140 --> 00:16:31,179 that specific endorsement key. 443 00:16:31,180 --> 00:16:33,039 You know that you're talking to a real 444 00:16:33,040 --> 00:16:34,070 TPM at that point. 445 00:16:35,140 --> 00:16:36,699 So there are a reasonably complicated 446 00:16:36,700 --> 00:16:38,799 chain of events. You can then create 447 00:16:38,800 --> 00:16:40,719 a secure cryptographic communication 448 00:16:40,720 --> 00:16:42,579 channel between the TPM and a remote 449 00:16:42,580 --> 00:16:44,439 system, I might say, between the TPM, the 450 00:16:44,440 --> 00:16:46,209 remote system. This is all mediated by 451 00:16:46,210 --> 00:16:47,109 your operating system. 452 00:16:47,110 --> 00:16:48,579 If you're operating system doesn't want 453 00:16:48,580 --> 00:16:50,199 this to happen, it won't happen. 454 00:16:50,200 --> 00:16:52,539 This can't be done against your will if 455 00:16:52,540 --> 00:16:53,889 you're running an operating system you 456 00:16:53,890 --> 00:16:54,890 control. 457 00:16:58,000 --> 00:17:00,609 The local operating system has no means 458 00:17:00,610 --> 00:17:02,709 of interfering with remote 459 00:17:02,710 --> 00:17:04,779 at the station if the remote 460 00:17:04,780 --> 00:17:07,059 system gets a set of values from 461 00:17:07,060 --> 00:17:08,060 your team. 462 00:17:08,829 --> 00:17:10,389 It knows that those are the values that 463 00:17:10,390 --> 00:17:11,799 the TPM hangs over. 464 00:17:11,800 --> 00:17:13,539 All the operating system can do is 465 00:17:13,540 --> 00:17:15,338 basically perform a denial of service. 466 00:17:15,339 --> 00:17:16,659 It can prevent this from happening at 467 00:17:16,660 --> 00:17:17,660 all. 468 00:17:19,640 --> 00:17:21,709 The remote the remote system can 469 00:17:21,710 --> 00:17:23,959 then look at the PCR values and 470 00:17:23,960 --> 00:17:26,088 can decide whether the system is in a 471 00:17:26,089 --> 00:17:28,129 trustworthy state and that could be based 472 00:17:28,130 --> 00:17:29,690 on any kind of arbitrary policy. 473 00:17:31,540 --> 00:17:33,459 Different components are measured into 474 00:17:33,460 --> 00:17:34,899 different pieces. So you can look at the 475 00:17:34,900 --> 00:17:36,849 system and say, OK, I recognize this 476 00:17:36,850 --> 00:17:38,979 firmware version because the PCR that 477 00:17:38,980 --> 00:17:40,959 contains the firmware measurement is 478 00:17:40,960 --> 00:17:41,919 disvalue. 479 00:17:41,920 --> 00:17:43,599 And I recognize this bootloader. 480 00:17:43,600 --> 00:17:46,569 And I don't care what Col's being booted, 481 00:17:46,570 --> 00:17:47,590 you can do something like that. 482 00:17:49,540 --> 00:17:51,639 From there is you need to trust 483 00:17:51,640 --> 00:17:54,279 the remote's machine and 484 00:17:54,280 --> 00:17:56,439 you don't have any particular 485 00:17:56,440 --> 00:17:58,149 reason to trust the eight remote's 486 00:17:58,150 --> 00:18:00,729 machine has not been subverted 487 00:18:00,730 --> 00:18:02,710 and is now operating outside. 488 00:18:04,110 --> 00:18:06,389 Your decisions 489 00:18:06,390 --> 00:18:07,739 about trust. 490 00:18:07,740 --> 00:18:11,039 If someone compromises this machine, then 491 00:18:11,040 --> 00:18:13,139 you could have a setup where your 492 00:18:13,140 --> 00:18:15,419 computer access to the remote machine 493 00:18:15,420 --> 00:18:17,159 and then a remote machine might send you 494 00:18:17,160 --> 00:18:19,469 an SMS back saying your computer is 495 00:18:19,470 --> 00:18:21,279 good or your computer is bad. 496 00:18:21,280 --> 00:18:23,129 If someone can interfere with the 497 00:18:23,130 --> 00:18:25,259 machine, then it can always just 498 00:18:25,260 --> 00:18:26,489 say your computer is good. 499 00:18:27,600 --> 00:18:29,849 And obviously, you also need network 500 00:18:29,850 --> 00:18:31,589 access, so this means that if you're 501 00:18:31,590 --> 00:18:33,539 using remote station, there's no way for 502 00:18:33,540 --> 00:18:35,729 you as a local user to figure 503 00:18:35,730 --> 00:18:37,920 out whether your system is trustworthy. 504 00:18:39,210 --> 00:18:40,829 If you're on a plane without Wi-Fi, if 505 00:18:40,830 --> 00:18:42,179 you're in the middle of the countryside 506 00:18:42,180 --> 00:18:44,339 or if you just don't feel like connecting 507 00:18:44,340 --> 00:18:46,329 to the network, you can't do remote 508 00:18:46,330 --> 00:18:47,399 isolation. 509 00:18:47,400 --> 00:18:50,039 So it's not ideal. 510 00:18:50,040 --> 00:18:51,419 And then how's the remote machine 511 00:18:51,420 --> 00:18:53,389 communicate back to you? 512 00:18:53,390 --> 00:18:55,859 Esme's maybe, but then someone 513 00:18:55,860 --> 00:18:58,319 could just interfere with 514 00:18:58,320 --> 00:19:00,179 that and send you a fix this mess. 515 00:19:00,180 --> 00:19:02,279 We know that the phone networks are 516 00:19:02,280 --> 00:19:03,449 not as secure as we would like them to 517 00:19:03,450 --> 00:19:06,359 be, especially if your 518 00:19:06,360 --> 00:19:08,130 adversary is a government. 519 00:19:10,120 --> 00:19:12,639 And over 520 00:19:12,640 --> 00:19:14,709 some sort of secure connection, well, 521 00:19:14,710 --> 00:19:17,529 if you're running on your local system, 522 00:19:17,530 --> 00:19:19,689 then fine, you open 523 00:19:19,690 --> 00:19:21,879 the browser, the browser says, 524 00:19:21,880 --> 00:19:23,649 yes, everything's fine because your 525 00:19:23,650 --> 00:19:26,259 browser is being compromised by the 526 00:19:26,260 --> 00:19:27,819 car and also your points. 527 00:19:27,820 --> 00:19:29,319 And so you can't trust what it's telling 528 00:19:29,320 --> 00:19:30,489 you about. Everything looks OK here as 529 00:19:30,490 --> 00:19:31,490 well. 530 00:19:32,620 --> 00:19:35,049 So remote isolation is a problem because 531 00:19:35,050 --> 00:19:37,209 it relies on you having to trust a 532 00:19:37,210 --> 00:19:38,979 large number of systems that aren't in 533 00:19:38,980 --> 00:19:39,969 your control. 534 00:19:39,970 --> 00:19:42,369 And that's not the kind of situation 535 00:19:42,370 --> 00:19:43,370 we want. 536 00:19:45,280 --> 00:19:46,479 We're asserting that the CPM is 537 00:19:46,480 --> 00:19:48,279 trustworthy. Everything I'm talking about 538 00:19:48,280 --> 00:19:50,109 is completely pointless if the team isn't 539 00:19:50,110 --> 00:19:51,759 trustworthy. So if you'd like to treat 540 00:19:51,760 --> 00:19:53,229 this as an academic exercise, that's 541 00:19:53,230 --> 00:19:54,909 completely fine. I understand your point 542 00:19:54,910 --> 00:19:55,910 of view. 543 00:19:57,550 --> 00:19:59,619 But if the TPM is trustworthy, then we 544 00:19:59,620 --> 00:20:02,679 can take advantage of any other 545 00:20:02,680 --> 00:20:05,199 features that the TPM offers to 546 00:20:05,200 --> 00:20:06,819 control secrets. 547 00:20:08,050 --> 00:20:09,819 And this is good because one thing that 548 00:20:09,820 --> 00:20:12,129 TPIMs can do is control data 549 00:20:12,130 --> 00:20:13,689 release based on the state of the 550 00:20:13,690 --> 00:20:14,690 pickle's. 551 00:20:16,380 --> 00:20:18,659 As well as measurements, teams are able 552 00:20:18,660 --> 00:20:21,599 to encrypt small quantities of data, 553 00:20:21,600 --> 00:20:23,799 you can ask a TPM to generate 554 00:20:23,800 --> 00:20:25,889 Banaszak and 555 00:20:25,890 --> 00:20:28,199 you can then ask the TPM to encrypt 556 00:20:28,200 --> 00:20:29,200 something with that. 557 00:20:32,390 --> 00:20:34,849 And the cool thing here is you can 558 00:20:34,850 --> 00:20:36,919 ask the TPM to encrypt that 559 00:20:36,920 --> 00:20:39,589 data along with information 560 00:20:39,590 --> 00:20:41,510 about the PCR values. 561 00:20:43,220 --> 00:20:45,319 Now, the key to decrypt this data 562 00:20:45,320 --> 00:20:48,109 is kept on the TPM, 563 00:20:48,110 --> 00:20:51,409 the decrypt, the private key is never 564 00:20:51,410 --> 00:20:53,569 in system ran, it's never on 565 00:20:53,570 --> 00:20:55,219 your hard drive. 566 00:20:55,220 --> 00:20:57,469 This data is encrypted with 567 00:20:57,470 --> 00:21:00,559 a key that is in the TPM. 568 00:21:00,560 --> 00:21:01,560 So. 569 00:21:02,280 --> 00:21:04,169 There's no straightforward way for 570 00:21:04,170 --> 00:21:06,299 someone to get hold of the private 571 00:21:06,300 --> 00:21:07,649 key that they need to decrypt this. 572 00:21:08,910 --> 00:21:11,099 If you have the PCR value sets, 573 00:21:11,100 --> 00:21:14,009 then when you put the data into the TPM, 574 00:21:14,010 --> 00:21:16,079 the TPM decrypts it and then looks 575 00:21:16,080 --> 00:21:18,329 at the PCR values and compares those 576 00:21:18,330 --> 00:21:21,059 to the values that it has recorded. 577 00:21:21,060 --> 00:21:23,189 And if they match, it 578 00:21:23,190 --> 00:21:25,859 will return the encrypted data 579 00:21:25,860 --> 00:21:27,329 to decrypt the data. 580 00:21:27,330 --> 00:21:29,609 And if they don't match, it 581 00:21:29,610 --> 00:21:30,610 will return an error. 582 00:21:31,860 --> 00:21:34,139 So this means that it's possible to have 583 00:21:34,140 --> 00:21:36,599 a secret that will only be released 584 00:21:36,600 --> 00:21:38,999 if the TPM is in a 585 00:21:39,000 --> 00:21:41,309 if the measurements are good, 586 00:21:41,310 --> 00:21:42,779 which then should indicate that your 587 00:21:42,780 --> 00:21:43,780 system is trustworthy. 588 00:21:48,100 --> 00:21:50,379 So you could use this, for instance, 589 00:21:50,380 --> 00:21:52,569 as a way of storing 590 00:21:52,570 --> 00:21:54,729 your desk decryption key, 591 00:21:54,730 --> 00:21:56,949 and that means that someone who if 592 00:21:56,950 --> 00:21:59,169 your boot process is interfered with, if 593 00:21:59,170 --> 00:22:01,569 the measurements no longer match, 594 00:22:01,570 --> 00:22:04,059 the TPM will not release 595 00:22:04,060 --> 00:22:05,289 the decryption key. 596 00:22:06,600 --> 00:22:08,939 And as a result, your bootloader will 597 00:22:08,940 --> 00:22:11,039 not be able to decrypt your hard 598 00:22:11,040 --> 00:22:12,779 drive and your system will not boot. 599 00:22:15,840 --> 00:22:17,299 Now, this doesn't protect against the 600 00:22:17,300 --> 00:22:18,589 case where someone just steals your 601 00:22:18,590 --> 00:22:20,929 laptop, if that's all you're doing, then 602 00:22:20,930 --> 00:22:22,909 all they need to do is turn your laptop 603 00:22:22,910 --> 00:22:23,910 on. 604 00:22:24,680 --> 00:22:26,989 And it'll boot the 2pm 605 00:22:26,990 --> 00:22:29,299 is not verifying that you 606 00:22:29,300 --> 00:22:30,889 are the person using the system, all the 607 00:22:30,890 --> 00:22:34,159 TPM is doing in this case is verifying 608 00:22:34,160 --> 00:22:36,589 that the boot state 609 00:22:36,590 --> 00:22:37,770 has not been tampered with. 610 00:22:38,950 --> 00:22:41,119 So, OK, we can deal 611 00:22:41,120 --> 00:22:42,120 with this. 612 00:22:42,660 --> 00:22:45,029 You enter a passphrase as well, 613 00:22:45,030 --> 00:22:46,199 so the system Boutte's. 614 00:22:47,490 --> 00:22:50,339 The 2pm decrypts the key, 615 00:22:50,340 --> 00:22:52,439 if the 2pm successfully decrypts the 616 00:22:52,440 --> 00:22:54,629 key, that's half of the process. 617 00:22:54,630 --> 00:22:56,699 We still need you to type in a 618 00:22:56,700 --> 00:22:58,769 passphrase in order to 619 00:22:58,770 --> 00:23:00,959 decrypt the key through a second 620 00:23:00,960 --> 00:23:03,059 stage and actually allow you to 621 00:23:03,060 --> 00:23:04,060 access your hard drive. 622 00:23:05,430 --> 00:23:07,979 So this seems safe because 623 00:23:07,980 --> 00:23:09,569 if someone steals your machine and turns 624 00:23:09,570 --> 00:23:11,789 it on, then they still can't 625 00:23:11,790 --> 00:23:12,839 get access to your system without your 626 00:23:12,840 --> 00:23:14,939 passphrase. And if the boot process 627 00:23:14,940 --> 00:23:17,279 is tampered with, then the first 628 00:23:17,280 --> 00:23:19,469 step of this will fail and the 629 00:23:19,470 --> 00:23:20,819 system will not prompt you for the 630 00:23:20,820 --> 00:23:21,820 passphrase. 631 00:23:22,740 --> 00:23:23,759 There's a problem with this line of 632 00:23:23,760 --> 00:23:25,599 thinking, which is fine. 633 00:23:25,600 --> 00:23:27,569 You boot your system and you get the 634 00:23:27,570 --> 00:23:30,809 password prompt and you think, OK, 635 00:23:30,810 --> 00:23:33,149 the system is in a secure state. 636 00:23:33,150 --> 00:23:35,249 I can trust the system, I can type in 637 00:23:35,250 --> 00:23:37,319 my password and you type in 638 00:23:37,320 --> 00:23:39,449 your password and you hit enter and it 639 00:23:39,450 --> 00:23:40,649 looks like the system is missing. 640 00:23:40,650 --> 00:23:42,269 And then. Oh, no. 641 00:23:43,640 --> 00:23:44,640 Linux's bad. 642 00:23:45,960 --> 00:23:48,269 This happens, I'll try turning 643 00:23:48,270 --> 00:23:49,559 it off and turning it on again. 644 00:23:52,310 --> 00:23:54,259 And you turn this off and you turn this 645 00:23:54,260 --> 00:23:56,029 on again and you get your passport prompt 646 00:23:56,030 --> 00:23:57,619 again and you type in your passport again 647 00:23:57,620 --> 00:23:58,639 and the system boots. 648 00:23:58,640 --> 00:24:00,349 And so everything is fine. 649 00:24:00,350 --> 00:24:02,509 Software is bad with writing 650 00:24:02,510 --> 00:24:04,339 software. This is unsurprising. 651 00:24:04,340 --> 00:24:06,919 This happens. How many of you have never 652 00:24:06,920 --> 00:24:08,569 seen a Colonel Panicker Boot? 653 00:24:12,580 --> 00:24:14,979 Awesome, nobody put their hands up so 654 00:24:14,980 --> 00:24:17,079 great, this seems 655 00:24:17,080 --> 00:24:19,149 like something that might just happen 656 00:24:19,150 --> 00:24:21,339 right now. 657 00:24:21,340 --> 00:24:22,340 The problem is 658 00:24:23,470 --> 00:24:25,689 how do you know what's actually printing 659 00:24:25,690 --> 00:24:26,690 that? 660 00:24:28,020 --> 00:24:30,179 You have no way at this point 661 00:24:30,180 --> 00:24:31,919 of knowing that this passport is 662 00:24:31,920 --> 00:24:32,920 legitimate. 663 00:24:33,840 --> 00:24:34,840 Now, you do know. 664 00:24:35,900 --> 00:24:37,999 That if the boot process has been 665 00:24:38,000 --> 00:24:40,579 Ifti boot process has been tampered with, 666 00:24:40,580 --> 00:24:42,649 that the TPM 667 00:24:42,650 --> 00:24:44,289 will not release the secret, so the 668 00:24:44,290 --> 00:24:46,060 passphrase on its own is useless. 669 00:24:48,290 --> 00:24:50,209 But you still don't know that that's a 670 00:24:50,210 --> 00:24:52,369 real possibility, that someone could 671 00:24:52,370 --> 00:24:54,979 have infected your system 672 00:24:54,980 --> 00:24:56,659 with some code that modified your boot 673 00:24:56,660 --> 00:24:58,729 process and then put up a fake 674 00:24:58,730 --> 00:24:59,730 passport print. 675 00:25:01,070 --> 00:25:03,109 Waited for you to type in a password, 676 00:25:03,110 --> 00:25:05,329 saved that password 677 00:25:05,330 --> 00:25:06,330 somewhere. 678 00:25:08,770 --> 00:25:10,930 Printed a fake kernel panic 679 00:25:12,190 --> 00:25:14,529 and then uninstalled itself, 680 00:25:14,530 --> 00:25:16,329 you reboot and now everything works 681 00:25:16,330 --> 00:25:18,009 correctly because your boot process is 682 00:25:18,010 --> 00:25:19,059 not trustworthy. 683 00:25:19,060 --> 00:25:21,189 The problem is there's now a copy of your 684 00:25:21,190 --> 00:25:23,439 passphrase somewhere on your system 685 00:25:23,440 --> 00:25:24,969 that's an attacker can get hold of. 686 00:25:24,970 --> 00:25:27,399 And now they walk in, steal your laptop. 687 00:25:27,400 --> 00:25:29,529 They have your secret and they have 688 00:25:29,530 --> 00:25:30,530 your passphrase. 689 00:25:32,280 --> 00:25:34,379 So this is not 690 00:25:34,380 --> 00:25:35,639 ideal. 691 00:25:35,640 --> 00:25:37,319 The problem here is that you're still 692 00:25:37,320 --> 00:25:39,389 typing in a secret before you 693 00:25:39,390 --> 00:25:40,779 know that the system is trustworthy. 694 00:25:42,300 --> 00:25:44,489 Now, the idea here is the evil major 695 00:25:44,490 --> 00:25:46,739 tank is one where, say, your 696 00:25:46,740 --> 00:25:49,019 laptop is in a hotel room and 697 00:25:49,020 --> 00:25:51,149 an adversary enters your hotel room while 698 00:25:51,150 --> 00:25:53,129 you're out, tampers with your system and 699 00:25:53,130 --> 00:25:55,049 then leaves your system has now 700 00:25:55,050 --> 00:25:56,519 transitioned from being trustworthy to 701 00:25:56,520 --> 00:25:58,019 not being trustworthy. 702 00:25:58,020 --> 00:26:00,179 And the evil made was a 703 00:26:00,180 --> 00:26:01,769 technology developed by you and the 704 00:26:01,770 --> 00:26:04,289 Rakowski, the invisible things 705 00:26:04,290 --> 00:26:06,389 that was intended to make 706 00:26:06,390 --> 00:26:07,390 it. 707 00:26:08,320 --> 00:26:10,719 Less practical for this, rather 708 00:26:10,720 --> 00:26:13,299 than just blindly typing in a secret, 709 00:26:13,300 --> 00:26:15,729 you would instead have a mechanism 710 00:26:15,730 --> 00:26:17,709 by which the system would prove to you 711 00:26:17,710 --> 00:26:19,260 that it was trustworthy in advance. 712 00:26:20,380 --> 00:26:22,029 And this time, rather than just 713 00:26:22,030 --> 00:26:24,849 encrypting a disk encryption 714 00:26:24,850 --> 00:26:27,039 secret, you encrypt a 715 00:26:27,040 --> 00:26:29,289 phrase that's only known to the user. 716 00:26:29,290 --> 00:26:31,539 So when you install and even 717 00:26:31,540 --> 00:26:33,909 made you type in a secret 718 00:26:33,910 --> 00:26:35,649 phrase that nobody should be able to 719 00:26:35,650 --> 00:26:36,650 guess. 720 00:26:38,300 --> 00:26:40,399 That's then encrypted with the TPM and 721 00:26:40,400 --> 00:26:42,529 again sealed with the specific set of 722 00:26:42,530 --> 00:26:43,549 PCR values. 723 00:26:45,280 --> 00:26:46,280 So. 724 00:26:47,660 --> 00:26:48,660 System, Boutte's. 725 00:26:49,720 --> 00:26:51,849 And then if 726 00:26:51,850 --> 00:26:53,500 the system's in a trustworthy state. 727 00:26:55,460 --> 00:26:57,589 That secret can be decrypted 728 00:26:57,590 --> 00:26:58,609 and then printed. 729 00:26:59,640 --> 00:27:01,769 And if you see that phrase, then you know 730 00:27:01,770 --> 00:27:03,899 that your systems in a trustworthy state, 731 00:27:03,900 --> 00:27:06,029 if you don't see that phrase, then 732 00:27:06,030 --> 00:27:07,649 you should not consider the system 733 00:27:07,650 --> 00:27:08,999 trustworthy and you should not type 734 00:27:09,000 --> 00:27:11,069 anything into it as 735 00:27:11,070 --> 00:27:12,779 a couple of problems with this. 736 00:27:12,780 --> 00:27:14,909 And the first is that if it's always 737 00:27:14,910 --> 00:27:16,559 Princip's, if you have this as part of 738 00:27:16,560 --> 00:27:19,109 your normal boot process, then someone 739 00:27:19,110 --> 00:27:21,239 can just walk up, reboot your 740 00:27:21,240 --> 00:27:24,059 system, read the freeze off the screen, 741 00:27:24,060 --> 00:27:26,249 and then install some malware 742 00:27:26,250 --> 00:27:28,169 that prints the same phrase, even if your 743 00:27:28,170 --> 00:27:30,479 system's not in a trustworthy state. 744 00:27:30,480 --> 00:27:32,339 So there's a way around that, which is 745 00:27:32,340 --> 00:27:34,379 that rather than having the secret stored 746 00:27:34,380 --> 00:27:35,460 on the system. 747 00:27:36,570 --> 00:27:39,269 You stole the secrets on a USB stick, 748 00:27:39,270 --> 00:27:41,399 and then when you boot the system with 749 00:27:41,400 --> 00:27:44,219 the USB stick, then the secret can be 750 00:27:44,220 --> 00:27:46,349 decrypted and printed, but that 751 00:27:46,350 --> 00:27:47,999 relies on the user. 752 00:27:49,160 --> 00:27:51,439 Carrying around a USB stick, it relies 753 00:27:51,440 --> 00:27:54,409 on the user having the discipline 754 00:27:54,410 --> 00:27:56,269 to always boot with the USB stick if 755 00:27:56,270 --> 00:27:57,439 there's a risk that that system's been 756 00:27:57,440 --> 00:27:58,549 tampered with. 757 00:27:58,550 --> 00:28:00,649 And so you could potentially end up in 758 00:28:00,650 --> 00:28:02,719 a situation where a user forgets to do 759 00:28:02,720 --> 00:28:04,939 this and 760 00:28:04,940 --> 00:28:07,000 then that system has been compromised. 761 00:28:09,970 --> 00:28:12,429 So exposing a static 762 00:28:12,430 --> 00:28:14,499 secret is a little bit 763 00:28:14,500 --> 00:28:15,500 suboptimal. 764 00:28:17,380 --> 00:28:19,749 Ideally, we would not have a static 765 00:28:19,750 --> 00:28:21,849 secrets, we would think of some sort of 766 00:28:21,850 --> 00:28:23,979 dynamic exposure, something 767 00:28:23,980 --> 00:28:24,980 that. 768 00:28:25,990 --> 00:28:28,449 Changes over time, something 769 00:28:28,450 --> 00:28:31,149 where nearly having possession 770 00:28:31,150 --> 00:28:33,309 of a single instance of the 771 00:28:33,310 --> 00:28:35,769 secret being presented does not allow 772 00:28:35,770 --> 00:28:37,689 you to present the correct secrets in 773 00:28:37,690 --> 00:28:39,999 future once a shared secret 774 00:28:40,000 --> 00:28:43,299 with some sort of dynamic component 775 00:28:43,300 --> 00:28:44,300 and. 776 00:28:47,540 --> 00:28:49,669 I would really hope that all of you 777 00:28:49,670 --> 00:28:52,099 are already using something along 778 00:28:52,100 --> 00:28:54,499 these lines, if you're not, 779 00:28:54,500 --> 00:28:56,689 you should feel bad and then you should 780 00:28:56,690 --> 00:28:59,719 go into Nieblas immediately, because 781 00:28:59,720 --> 00:29:01,909 this is basically the design 782 00:29:01,910 --> 00:29:04,429 goal of top 783 00:29:04,430 --> 00:29:06,499 the protocol 784 00:29:06,500 --> 00:29:08,179 that's used for the majority of 785 00:29:08,180 --> 00:29:09,440 Two-Factor authentication. 786 00:29:10,700 --> 00:29:12,679 You have a secret when you're looking 787 00:29:12,680 --> 00:29:13,680 into a website. 788 00:29:14,600 --> 00:29:16,969 When you are unable to hefe, the website 789 00:29:16,970 --> 00:29:18,739 generates the secrets and stores it, and 790 00:29:18,740 --> 00:29:21,079 the website typically prints 791 00:29:21,080 --> 00:29:23,299 a QR code and 792 00:29:23,300 --> 00:29:25,339 you enroll that QR codes on your phone 793 00:29:25,340 --> 00:29:27,139 and now your phone also has a copy of The 794 00:29:27,140 --> 00:29:28,399 Secret. 795 00:29:28,400 --> 00:29:31,159 But the authentication that you present 796 00:29:31,160 --> 00:29:33,349 is based not just on that secret, but 797 00:29:33,350 --> 00:29:35,809 also on the current time. 798 00:29:35,810 --> 00:29:36,810 So 799 00:29:37,940 --> 00:29:40,279 there's a algorithm 800 00:29:40,280 --> 00:29:41,959 by which you take the secret at the time 801 00:29:41,960 --> 00:29:44,599 and then you generate a six digit number. 802 00:29:44,600 --> 00:29:46,429 You present that six digit number to the 803 00:29:46,430 --> 00:29:47,359 website. 804 00:29:47,360 --> 00:29:49,639 The website then verifies 805 00:29:49,640 --> 00:29:51,709 that that's the great number 806 00:29:51,710 --> 00:29:53,089 because the website also knows the 807 00:29:53,090 --> 00:29:55,339 secrets. And with luck, the website 808 00:29:55,340 --> 00:29:57,389 also knows the time of day. 809 00:29:57,390 --> 00:29:59,210 That's pretty much a problem. 810 00:30:02,590 --> 00:30:04,929 And this is nice because it's very easily 811 00:30:04,930 --> 00:30:07,299 available, you can get lots of Two-Factor 812 00:30:07,300 --> 00:30:08,859 authentication that you can get free 813 00:30:08,860 --> 00:30:10,629 software, Two-Factor authentication apps, 814 00:30:10,630 --> 00:30:12,609 you can run free software authentication 815 00:30:12,610 --> 00:30:15,039 apps on free software operating systems. 816 00:30:15,040 --> 00:30:16,869 You can even run them on free software 817 00:30:16,870 --> 00:30:18,879 operating systems that run on top of 818 00:30:18,880 --> 00:30:20,229 basically free firmware. 819 00:30:20,230 --> 00:30:21,459 So that's nice. 820 00:30:21,460 --> 00:30:23,949 Users have been trained to understand 821 00:30:23,950 --> 00:30:26,019 this kind of thing fairly well. 822 00:30:26,020 --> 00:30:27,249 Lots of people use Two-Factor 823 00:30:27,250 --> 00:30:28,989 authentication and somehow the world 824 00:30:28,990 --> 00:30:29,979 hasn't ended. 825 00:30:29,980 --> 00:30:32,079 So we can probably assume that users are 826 00:30:32,080 --> 00:30:33,639 reasonably familiar with the idea that 827 00:30:33,640 --> 00:30:35,409 you have this magic six digit number, 828 00:30:35,410 --> 00:30:36,519 even if they don't understand the 829 00:30:36,520 --> 00:30:37,609 technology behind it. 830 00:30:38,980 --> 00:30:40,779 So what we can do is. 831 00:30:42,250 --> 00:30:44,349 SEAL the top secrets 832 00:30:44,350 --> 00:30:45,350 to the TPM. 833 00:30:48,960 --> 00:30:51,629 Print a QR code that then allows 834 00:30:51,630 --> 00:30:53,789 the user to share the secrets between 835 00:30:53,790 --> 00:30:56,729 their laptop and, say, their phone 836 00:30:56,730 --> 00:30:57,960 and then on Bhoot. 837 00:30:59,400 --> 00:31:02,109 We print a six digit number. 838 00:31:02,110 --> 00:31:04,329 And then the user checks their phone 839 00:31:04,330 --> 00:31:05,739 and checks, whether it's the same six 840 00:31:05,740 --> 00:31:07,989 digit number and if 841 00:31:07,990 --> 00:31:10,239 the two numbers match, then 842 00:31:10,240 --> 00:31:12,239 the system is trustworthy. 843 00:31:12,240 --> 00:31:14,189 Or, you know, there's a one in a million 844 00:31:14,190 --> 00:31:15,809 chance that the system was compromised 845 00:31:15,810 --> 00:31:16,709 and you just happen to get the right 846 00:31:16,710 --> 00:31:18,599 secrets if you use longer numbers, if you 847 00:31:18,600 --> 00:31:20,789 want to give a 848 00:31:20,790 --> 00:31:22,319 quick demo of this. 849 00:31:32,740 --> 00:31:34,809 As you can see, I have a 850 00:31:34,810 --> 00:31:36,879 wonderful source 851 00:31:36,880 --> 00:31:37,880 control. 852 00:31:40,840 --> 00:31:43,359 So simply run 853 00:31:43,360 --> 00:31:45,639 the application, 854 00:31:45,640 --> 00:31:48,009 this case, I'm running this route because 855 00:31:48,010 --> 00:31:49,509 this version of it talked to the TPM 856 00:31:49,510 --> 00:31:51,249 directly through the external interface 857 00:31:51,250 --> 00:31:53,259 rather than using the TPM daemon. 858 00:31:57,720 --> 00:31:59,849 And then, well, escargots 859 00:31:59,850 --> 00:32:01,259 isn't Nancy wonderful? 860 00:32:03,930 --> 00:32:05,609 So if I make that a bit smaller, anybody 861 00:32:05,610 --> 00:32:07,019 with a phone in the audience can now 862 00:32:07,020 --> 00:32:08,639 steal a copy of The Secret to anybody 863 00:32:08,640 --> 00:32:09,640 watching it on. 864 00:32:10,320 --> 00:32:12,749 So I'm then going to, 865 00:32:12,750 --> 00:32:14,879 you know, not actually use 866 00:32:14,880 --> 00:32:16,229 this secret for anything important. 867 00:32:17,390 --> 00:32:18,920 Because I'm not an idiot. 868 00:32:21,330 --> 00:32:23,190 And then if I run. 869 00:32:28,840 --> 00:32:31,150 OK, I guess a six digit number. 870 00:32:32,170 --> 00:32:34,359 And if I had enrolled that QR 871 00:32:34,360 --> 00:32:36,429 codes on my phone and looked at it 872 00:32:36,430 --> 00:32:38,079 now, it would show the same six digit 873 00:32:38,080 --> 00:32:39,080 number. 874 00:32:40,200 --> 00:32:41,519 I'll leave it up to the audience to 875 00:32:41,520 --> 00:32:42,779 verify whether this is the case 876 00:32:42,780 --> 00:32:44,939 afterwards, I just 877 00:32:44,940 --> 00:32:47,309 as a reminder, if you're attempting 878 00:32:47,310 --> 00:32:49,109 to do this while watching the video 879 00:32:49,110 --> 00:32:51,719 later, it won't work because 880 00:32:51,720 --> 00:32:52,769 time has passed. 881 00:32:52,770 --> 00:32:53,849 And that's kind of the point. 882 00:32:57,110 --> 00:32:59,179 So back to this, so 883 00:32:59,180 --> 00:33:00,739 a couple of problems with this, and the 884 00:33:00,740 --> 00:33:02,869 first is that the secret 885 00:33:02,870 --> 00:33:04,579 exists in RAM. 886 00:33:04,580 --> 00:33:07,279 The TPM itself cannot do the top 887 00:33:07,280 --> 00:33:09,799 generation. And so we have to allow 888 00:33:09,800 --> 00:33:12,619 the TPM to decrypt the secrets 889 00:33:12,620 --> 00:33:15,799 and then release the secret into RAM. 890 00:33:15,800 --> 00:33:17,929 And that means that anybody who's able 891 00:33:17,930 --> 00:33:20,269 to access the contents of RAM 892 00:33:20,270 --> 00:33:22,339 is able to access the secret. 893 00:33:22,340 --> 00:33:23,569 Now, if they've compromised the boot 894 00:33:23,570 --> 00:33:24,979 process, this isn't a problem because the 895 00:33:24,980 --> 00:33:26,929 TPM will refuse to release the secrets, 896 00:33:26,930 --> 00:33:28,369 but they're a memory based attacks that 897 00:33:28,370 --> 00:33:31,129 you can perform even if 898 00:33:31,130 --> 00:33:33,439 the system's in a trusted state, 899 00:33:33,440 --> 00:33:34,939 like if you have any externally 900 00:33:34,940 --> 00:33:37,159 accessible DMA capable busses 901 00:33:37,160 --> 00:33:39,469 like Express Cards or Thunderbolt, 902 00:33:39,470 --> 00:33:41,839 you can just DMA the secret 903 00:33:41,840 --> 00:33:43,129 out of RAM. 904 00:33:43,130 --> 00:33:45,769 So you really want the economy 905 00:33:45,770 --> 00:33:47,959 to be enabled. Unfortunately, many free 906 00:33:47,960 --> 00:33:49,879 operating systems still disable the 907 00:33:49,880 --> 00:33:52,189 Ioannina by default, even if the hardware 908 00:33:52,190 --> 00:33:54,529 supports it because we're bad 909 00:33:54,530 --> 00:33:55,530 at software. 910 00:33:56,290 --> 00:33:58,569 Also, intel bad at 911 00:33:58,570 --> 00:34:00,849 GPU design, but that's another story. 912 00:34:02,860 --> 00:34:05,169 So we can think about alternatives, 913 00:34:05,170 --> 00:34:07,569 and one option is that TPM 914 00:34:07,570 --> 00:34:09,549 keys themselves when we generate a TPM 915 00:34:09,550 --> 00:34:11,738 key, we can ask the TPM 916 00:34:11,739 --> 00:34:14,109 to restrict that key to specific 917 00:34:14,110 --> 00:34:15,189 PCR state. 918 00:34:15,190 --> 00:34:17,289 That is, the TPM will not 919 00:34:17,290 --> 00:34:18,879 be able. 920 00:34:18,880 --> 00:34:21,279 Well, sorry, will refuse to perform 921 00:34:21,280 --> 00:34:23,499 any encryption, decryption 922 00:34:23,500 --> 00:34:25,689 or signing operations with that key 923 00:34:25,690 --> 00:34:28,359 unless the PCR state matches 924 00:34:28,360 --> 00:34:30,340 so we could generate a key. 925 00:34:32,030 --> 00:34:34,639 We can see all that to the 2pm 926 00:34:35,659 --> 00:34:37,819 and then we can ask the 2pm to 927 00:34:37,820 --> 00:34:39,589 sign the current time of day. 928 00:34:41,690 --> 00:34:44,599 And the team can then 929 00:34:44,600 --> 00:34:46,729 provide that signed object to us 930 00:34:46,730 --> 00:34:48,408 in some way, like maybe printing another 931 00:34:48,409 --> 00:34:50,479 QR code and then you can verify that 932 00:34:50,480 --> 00:34:51,439 the signature matches. 933 00:34:51,440 --> 00:34:53,509 So we may, for instance, enroll, have an 934 00:34:53,510 --> 00:34:55,638 application where we enroll the public 935 00:34:55,639 --> 00:34:58,129 key on your phone, 936 00:34:58,130 --> 00:35:00,619 have the TPM 937 00:35:00,620 --> 00:35:02,809 sign the time, print 938 00:35:02,810 --> 00:35:03,589 QR code. 939 00:35:03,590 --> 00:35:05,149 You scan that QR code with this 940 00:35:05,150 --> 00:35:06,829 application. The application then 941 00:35:06,830 --> 00:35:09,230 verifies that the QR code is. 942 00:35:11,170 --> 00:35:13,599 Signs correctly remains that requires 943 00:35:13,600 --> 00:35:14,919 us to write new software. 944 00:35:14,920 --> 00:35:16,689 I really dislike writing software, so 945 00:35:16,690 --> 00:35:17,889 it's unfortunate that I have to do that 946 00:35:17,890 --> 00:35:18,999 for a living. 947 00:35:19,000 --> 00:35:21,099 It's less familiar to users. 948 00:35:21,100 --> 00:35:23,229 And one of the big problems with 949 00:35:23,230 --> 00:35:25,389 security is making things as easy 950 00:35:25,390 --> 00:35:27,399 for the users as possible, asking them to 951 00:35:27,400 --> 00:35:28,869 do something new and different and 952 00:35:28,870 --> 00:35:29,949 exciting every time they boot. 953 00:35:29,950 --> 00:35:33,039 That system is not ideal. 954 00:35:33,040 --> 00:35:35,109 So is there anything else we can do? 955 00:35:35,110 --> 00:35:37,269 And we could generate a key 956 00:35:37,270 --> 00:35:39,339 outside the TPM. 957 00:35:39,340 --> 00:35:41,259 We could then impulses into the TPM. 958 00:35:41,260 --> 00:35:44,529 So it's now under control. 959 00:35:44,530 --> 00:35:46,389 Rather than signing the final day, week 960 00:35:46,390 --> 00:35:48,579 is encrypt the time of day, hash it and 961 00:35:48,580 --> 00:35:50,979 then extract six digits and print them. 962 00:35:50,980 --> 00:35:53,289 Now this is very like Togepi, 963 00:35:53,290 --> 00:35:54,449 but it's incompatible. 964 00:35:55,450 --> 00:35:57,039 You could then, so you'd still need a 965 00:35:57,040 --> 00:35:58,419 different application on the phone. 966 00:35:58,420 --> 00:35:59,859 But in this case the behavior would be 967 00:35:59,860 --> 00:36:00,819 very similar. 968 00:36:00,820 --> 00:36:02,619 It would be probably easier to train 969 00:36:02,620 --> 00:36:04,839 users. The downside to this is that 970 00:36:04,840 --> 00:36:06,789 the in order to verify this, because 971 00:36:06,790 --> 00:36:09,099 we're doing encryption, the phone 972 00:36:09,100 --> 00:36:11,409 also needs a copy of the same private 973 00:36:11,410 --> 00:36:12,789 key, which is why we have to generate the 974 00:36:12,790 --> 00:36:14,649 key outside the TPM rather than in the 975 00:36:14,650 --> 00:36:15,759 TPM. 976 00:36:15,760 --> 00:36:18,189 And the problem with encrypt 977 00:36:18,190 --> 00:36:20,079 generating key outside TPM and then 978 00:36:20,080 --> 00:36:22,299 imposing it into the TPM is that 979 00:36:22,300 --> 00:36:25,329 due to some unfortunate design decisions, 980 00:36:25,330 --> 00:36:28,239 any key that's been imported into a TPM 981 00:36:28,240 --> 00:36:30,999 can then be exposed from the TPM. 982 00:36:31,000 --> 00:36:32,000 So. 983 00:36:32,890 --> 00:36:34,989 Anybody could then ask the 984 00:36:36,100 --> 00:36:38,199 TPM to just release a copy 985 00:36:38,200 --> 00:36:39,200 of this key. 986 00:36:40,380 --> 00:36:42,509 So if anybody is able to get hold of your 987 00:36:42,510 --> 00:36:44,399 system and excuse electrico, they could 988 00:36:44,400 --> 00:36:46,529 then just extract that private key 989 00:36:46,530 --> 00:36:48,809 from the TPM and then they'd be able 990 00:36:48,810 --> 00:36:51,179 to fake things at a later point. 991 00:36:53,340 --> 00:36:55,169 And maybe where overcomplicating things 992 00:36:55,170 --> 00:36:57,479 little, maybe there's benefits in 993 00:36:57,480 --> 00:36:59,969 additional simplicity, because 994 00:36:59,970 --> 00:37:01,610 apparently simplicity is a virtue. 995 00:37:04,240 --> 00:37:07,029 Something that is repeatedly stated 996 00:37:07,030 --> 00:37:09,549 by operating system authors and 997 00:37:09,550 --> 00:37:11,679 apparently they don't understand either 998 00:37:11,680 --> 00:37:13,150 the word simplicity or virtue. 999 00:37:15,650 --> 00:37:18,079 Times have a bunch of weapons. 1000 00:37:18,080 --> 00:37:20,089 This is nice, you can attach interesting 1001 00:37:20,090 --> 00:37:21,679 bits of hardware to your TPM. 1002 00:37:21,680 --> 00:37:23,869 Now, it's not immediately obvious why 1003 00:37:23,870 --> 00:37:25,849 you want to do that, because you can't 1004 00:37:25,850 --> 00:37:28,309 use arbitrary code on the CPM, but 1005 00:37:28,310 --> 00:37:30,499 access to the pins can be 1006 00:37:30,500 --> 00:37:32,869 restricted based on the PC 1007 00:37:32,870 --> 00:37:33,870 state. 1008 00:37:34,610 --> 00:37:36,679 You can set things up such 1009 00:37:36,680 --> 00:37:38,869 that you can only write to the 1010 00:37:38,870 --> 00:37:40,969 GPO if. 1011 00:37:42,000 --> 00:37:43,229 The PCR state is correct. 1012 00:37:44,850 --> 00:37:47,219 So you, for instance, attach 1013 00:37:47,220 --> 00:37:49,829 a small led to the pin 1014 00:37:49,830 --> 00:37:52,199 and then at boot, the operating system 1015 00:37:52,200 --> 00:37:54,299 attempts to rights to that led, if 1016 00:37:54,300 --> 00:37:56,699 the PCR values are correct, it can do so. 1017 00:37:56,700 --> 00:37:58,619 The lead turns on and your systems in a 1018 00:37:58,620 --> 00:37:59,620 good state. 1019 00:38:00,420 --> 00:38:01,649 So. Right. 1020 00:38:01,650 --> 00:38:03,449 This seems pretty awesome. 1021 00:38:03,450 --> 00:38:05,699 We can just and this is a very easy 1022 00:38:05,700 --> 00:38:06,959 modifications. Make the laptops. 1023 00:38:06,960 --> 00:38:09,179 We just need an extra led that's tied 1024 00:38:09,180 --> 00:38:11,190 to line on. 1025 00:38:12,750 --> 00:38:14,160 The mother was so cool. 1026 00:38:15,580 --> 00:38:17,819 Turns out that is quite easy to just 1027 00:38:17,820 --> 00:38:19,889 attach things to LEDs to 1028 00:38:19,890 --> 00:38:20,890 make them turn on. 1029 00:38:22,840 --> 00:38:25,419 So the hardware that you would require 1030 00:38:25,420 --> 00:38:27,369 in order to attack this is not 1031 00:38:27,370 --> 00:38:28,780 particularly complicated. 1032 00:38:30,100 --> 00:38:32,529 Yes. So it's kind of a nice idea, 1033 00:38:32,530 --> 00:38:34,059 but it's not ideal. 1034 00:38:35,640 --> 00:38:36,640 Nothing is. 1035 00:38:37,650 --> 00:38:38,790 We've been thinking about. 1036 00:38:40,490 --> 00:38:42,619 Using the screen or using an 1037 00:38:42,620 --> 00:38:43,969 LED for communication. 1038 00:38:45,110 --> 00:38:46,280 We could instead 1039 00:38:47,450 --> 00:38:49,819 use some other interface and 1040 00:38:49,820 --> 00:38:52,429 example of that is NFC, 1041 00:38:52,430 --> 00:38:55,359 so you could, for instance. 1042 00:38:55,360 --> 00:38:57,640 Basically perform remotes, attestation 1043 00:38:58,900 --> 00:39:01,119 over NFC, your 1044 00:39:01,120 --> 00:39:03,309 system boots to a certain point, and 1045 00:39:03,310 --> 00:39:05,859 then some sort of prompt appears, 1046 00:39:05,860 --> 00:39:09,039 you walk along, you tap 1047 00:39:09,040 --> 00:39:10,389 a physical object you have in your 1048 00:39:10,390 --> 00:39:13,329 possession against the machine 1049 00:39:13,330 --> 00:39:14,330 and then. 1050 00:39:16,120 --> 00:39:19,299 Communications performed, the TPM 1051 00:39:19,300 --> 00:39:21,819 produces some sorts of 1052 00:39:21,820 --> 00:39:24,099 signs, material passes that 1053 00:39:24,100 --> 00:39:26,199 to the device, the device verifies that 1054 00:39:26,200 --> 00:39:27,269 this is correct. 1055 00:39:27,270 --> 00:39:28,809 Some of the nice things about this is 1056 00:39:28,810 --> 00:39:29,810 that. 1057 00:39:30,870 --> 00:39:32,849 You can now also move away from things 1058 00:39:32,850 --> 00:39:34,589 like having a passphrase, you can have a 1059 00:39:34,590 --> 00:39:36,629 secret that's embedded in the physical 1060 00:39:36,630 --> 00:39:38,819 device, and if you don't 1061 00:39:38,820 --> 00:39:40,019 tap the physical device against the 1062 00:39:40,020 --> 00:39:42,899 system, that secret is not provided. 1063 00:39:42,900 --> 00:39:45,119 And so the system refuses to boot. 1064 00:39:45,120 --> 00:39:47,099 Another nice features about this approach 1065 00:39:47,100 --> 00:39:49,709 is that you can't 1066 00:39:49,710 --> 00:39:51,780 just ignore the prompt. 1067 00:39:53,770 --> 00:39:55,239 If I get a six digit number on the 1068 00:39:55,240 --> 00:39:57,669 screen, then I can still 1069 00:39:57,670 --> 00:40:00,069 just skip verification and go ahead 1070 00:40:00,070 --> 00:40:01,270 and type in my secret. 1071 00:40:02,950 --> 00:40:05,049 In this case, if I if 1072 00:40:05,050 --> 00:40:07,299 I always have to tap my phone 1073 00:40:07,300 --> 00:40:09,389 or something else against the laptop, 1074 00:40:10,810 --> 00:40:13,179 and if that does not automatically 1075 00:40:13,180 --> 00:40:14,709 result in the system, then booting 1076 00:40:14,710 --> 00:40:15,710 completely. 1077 00:40:17,800 --> 00:40:19,899 There's no 1078 00:40:19,900 --> 00:40:21,459 way for me to forget to do this if I 1079 00:40:21,460 --> 00:40:23,349 don't do this. The system doesn't boot 1080 00:40:23,350 --> 00:40:26,699 and this means that you can engrain. 1081 00:40:26,700 --> 00:40:29,070 Appropriate behavior into your uses? 1082 00:40:30,160 --> 00:40:32,229 It's much easier to train users if 1083 00:40:32,230 --> 00:40:33,900 there's no way they can get it wrong. 1084 00:40:35,150 --> 00:40:37,699 I have previously worked as a sysadmin, 1085 00:40:37,700 --> 00:40:40,099 so this is, unfortunately, 1086 00:40:40,100 --> 00:40:41,360 personal experience. 1087 00:40:44,720 --> 00:40:45,720 And. 1088 00:40:46,570 --> 00:40:49,599 Problem here is, well, 1089 00:40:49,600 --> 00:40:50,979 you're still. 1090 00:40:54,490 --> 00:40:56,649 Limited in terms of hardware, supports 1091 00:40:56,650 --> 00:40:58,839 the majority of laptops, don't have 1092 00:40:58,840 --> 00:41:00,429 any NFC capability. 1093 00:41:01,440 --> 00:41:03,299 And even the majority of phones don't 1094 00:41:03,300 --> 00:41:04,680 have any NFC capability, 1095 00:41:05,730 --> 00:41:07,709 but where you do have this hardware, this 1096 00:41:07,710 --> 00:41:09,539 is a potentially interesting avenue to 1097 00:41:09,540 --> 00:41:11,279 explore. And when I say it's an 1098 00:41:11,280 --> 00:41:13,079 interesting avenue to explore, I mean, it 1099 00:41:13,080 --> 00:41:14,579 would be very nice if someone else would 1100 00:41:14,580 --> 00:41:15,960 write the code to support this. 1101 00:41:19,130 --> 00:41:21,679 It's my usual approach to trying to get 1102 00:41:21,680 --> 00:41:22,680 new software. 1103 00:41:23,960 --> 00:41:25,879 However, even with all of these things, 1104 00:41:25,880 --> 00:41:28,189 we're still vulnerable to certain kinds 1105 00:41:28,190 --> 00:41:29,489 of attack. 1106 00:41:29,490 --> 00:41:31,879 Now, previously, I mentioned DNA 1107 00:41:31,880 --> 00:41:34,559 capable devices and. 1108 00:41:34,560 --> 00:41:37,079 If you have no Ayumu, 1109 00:41:37,080 --> 00:41:39,899 if you have no way to 1110 00:41:39,900 --> 00:41:41,610 prevent DMA based attacks, 1111 00:41:42,630 --> 00:41:43,630 just give up. 1112 00:41:44,630 --> 00:41:46,579 That's not going to work out well for 1113 00:41:46,580 --> 00:41:47,580 you. 1114 00:41:48,680 --> 00:41:50,569 Unfortunately, there is one device that 1115 00:41:50,570 --> 00:41:52,309 is always on your system and is always 1116 00:41:52,310 --> 00:41:54,559 capable of performing DNA, and that's the 1117 00:41:54,560 --> 00:41:56,779 management engine that's built into 1118 00:41:56,780 --> 00:41:59,149 all recent intel systems, 1119 00:41:59,150 --> 00:42:01,459 AMD will be shipping something 1120 00:42:01,460 --> 00:42:03,709 equivalent at some point, I'm sure. 1121 00:42:03,710 --> 00:42:04,999 So, you know, 1122 00:42:06,260 --> 00:42:08,689 in the 86 world, we're basically stuck 1123 00:42:08,690 --> 00:42:10,519 with this idea that there is a device 1124 00:42:10,520 --> 00:42:12,409 that can do arbitrary DNA. 1125 00:42:12,410 --> 00:42:14,689 And if it can do arbitrary DNA, 1126 00:42:14,690 --> 00:42:17,059 then even if your system 1127 00:42:17,060 --> 00:42:19,939 appears trustworthy until that point, 1128 00:42:19,940 --> 00:42:21,439 someone because of injected arbitrary 1129 00:42:21,440 --> 00:42:23,209 codes into the management engine at some 1130 00:42:23,210 --> 00:42:25,669 point. And that person 1131 00:42:25,670 --> 00:42:26,779 who injected those into the management 1132 00:42:26,780 --> 00:42:28,999 engine may work 1133 00:42:29,000 --> 00:42:31,969 for a three letter organization, 1134 00:42:31,970 --> 00:42:32,970 for instance. 1135 00:42:34,100 --> 00:42:36,259 And that's going to have the ability 1136 00:42:36,260 --> 00:42:38,629 to steal your secrets, or even 1137 00:42:38,630 --> 00:42:39,919 if it doesn't steal your secrets, it can 1138 00:42:39,920 --> 00:42:41,989 just compromise your operating system 1139 00:42:41,990 --> 00:42:43,169 after it's booted off. 1140 00:42:43,170 --> 00:42:44,329 You thought you were in a completely 1141 00:42:44,330 --> 00:42:45,330 trustworthy state. 1142 00:42:46,560 --> 00:42:48,929 There's no good answer 1143 00:42:48,930 --> 00:42:50,729 to this at the moment. 1144 00:42:50,730 --> 00:42:52,829 This is a problem in a variety of ways. 1145 00:42:52,830 --> 00:42:54,149 It's a problem in terms of us having a 1146 00:42:54,150 --> 00:42:56,159 trustworthy firm, where it's a problem in 1147 00:42:56,160 --> 00:42:57,419 terms of us having a trustworthy 1148 00:42:57,420 --> 00:42:59,069 operating system. 1149 00:42:59,070 --> 00:43:01,019 We do not know. 1150 00:43:02,150 --> 00:43:04,849 For sure how tightly controlled 1151 00:43:04,850 --> 00:43:07,249 access to the management engine is, 1152 00:43:07,250 --> 00:43:09,439 we do not know how 1153 00:43:09,440 --> 00:43:11,599 secure it the management engine is, how 1154 00:43:11,600 --> 00:43:14,059 competent the developers were, 1155 00:43:14,060 --> 00:43:16,699 all we have is Intel's assertion 1156 00:43:16,700 --> 00:43:18,619 that the management engine is written by 1157 00:43:18,620 --> 00:43:19,620 top men. 1158 00:43:24,790 --> 00:43:26,050 Having seen. 1159 00:43:27,100 --> 00:43:29,019 Various bits of code that Intel have 1160 00:43:29,020 --> 00:43:31,149 reduced over the years, I would not want 1161 00:43:31,150 --> 00:43:33,309 to state that Intel 1162 00:43:33,310 --> 00:43:35,170 are always good at writing software. 1163 00:43:37,460 --> 00:43:39,349 And obviously, you can attack the TPM 1164 00:43:39,350 --> 00:43:40,350 itself. 1165 00:43:41,090 --> 00:43:43,399 CPMs are not intended 1166 00:43:43,400 --> 00:43:45,079 to be tamper resistance, the 1167 00:43:45,080 --> 00:43:48,349 specification explicitly leaves 1168 00:43:48,350 --> 00:43:50,899 any kind of Tempah stuff up to either 1169 00:43:50,900 --> 00:43:53,269 the platform specification or 1170 00:43:53,270 --> 00:43:55,339 for individual vendors to compete 1171 00:43:55,340 --> 00:43:56,359 over. 1172 00:43:56,360 --> 00:43:58,429 And yeah, 1173 00:43:58,430 --> 00:44:00,229 this is not ideal. 1174 00:44:00,230 --> 00:44:02,599 A lot of them define 1175 00:44:02,600 --> 00:44:05,329 tamper evidence and 1176 00:44:05,330 --> 00:44:07,099 8pm is tamper evident. 1177 00:44:07,100 --> 00:44:09,049 If if someone tampers with it, you can 1178 00:44:09,050 --> 00:44:10,219 see that. 1179 00:44:10,220 --> 00:44:12,859 And a lot of vendors interpret this as 1180 00:44:12,860 --> 00:44:14,149 well. Look at the motherboard. 1181 00:44:14,150 --> 00:44:15,499 Is the TPM still there? 1182 00:44:17,420 --> 00:44:19,369 If so, it hasn't been tampered with. 1183 00:44:21,440 --> 00:44:23,839 Which is not ideal, TVs 1184 00:44:23,840 --> 00:44:25,429 are not intended to be particularly 1185 00:44:25,430 --> 00:44:27,499 resistant to attacks, it's almost 1186 00:44:27,500 --> 00:44:29,569 certainly the case that if someone 1187 00:44:29,570 --> 00:44:31,369 did capture 2pm, they're going to be able 1188 00:44:31,370 --> 00:44:33,559 to read the data 1189 00:44:33,560 --> 00:44:34,729 out of it. 1190 00:44:34,730 --> 00:44:36,409 This is something that governments would 1191 00:44:36,410 --> 00:44:37,489 certainly be able to do. 1192 00:44:37,490 --> 00:44:39,109 It's something that a sufficiently 1193 00:44:39,110 --> 00:44:40,609 skilled amateur would probably be able to 1194 00:44:40,610 --> 00:44:42,880 do for not that much money or time. 1195 00:44:44,090 --> 00:44:46,699 So that's not really 1196 00:44:46,700 --> 00:44:47,749 ideal. 1197 00:44:47,750 --> 00:44:49,729 It's OK, though. We have a good solution 1198 00:44:49,730 --> 00:44:52,159 to this intel have come up with the idea 1199 00:44:52,160 --> 00:44:54,289 that rather than having a physical 2pm on 1200 00:44:54,290 --> 00:44:56,389 the motherboard, you can have a software 1201 00:44:56,390 --> 00:44:58,609 team that runs on the management 1202 00:44:58,610 --> 00:44:59,610 engine. 1203 00:45:04,320 --> 00:45:06,449 Awesome and obviously 1204 00:45:06,450 --> 00:45:08,219 all of this also relies on you having a 1205 00:45:08,220 --> 00:45:09,220 2pm. 1206 00:45:10,860 --> 00:45:12,929 As of July 1207 00:45:12,930 --> 00:45:15,509 this year, all systems 1208 00:45:15,510 --> 00:45:17,729 with Windows 10 certification will be 1209 00:45:17,730 --> 00:45:20,009 required, all new systems keep windows 1210 00:45:20,010 --> 00:45:21,719 and certification will be required to 1211 00:45:21,720 --> 00:45:22,769 ship the TPM. 1212 00:45:22,770 --> 00:45:24,389 So that's nice. 1213 00:45:24,390 --> 00:45:26,579 Thanks, Microsoft, if 1214 00:45:26,580 --> 00:45:27,539 you've got an Apple. 1215 00:45:27,540 --> 00:45:29,009 Well, that's unfortunate. 1216 00:45:29,010 --> 00:45:31,169 If any of you are actually doing 1217 00:45:31,170 --> 00:45:34,169 any kind of confidential work on Apple's 1218 00:45:34,170 --> 00:45:36,449 Stop for the love of God, please, 1219 00:45:36,450 --> 00:45:37,559 please stop. 1220 00:45:39,000 --> 00:45:41,129 The absence of any kind of 1221 00:45:41,130 --> 00:45:43,349 plausible security on 1222 00:45:43,350 --> 00:45:45,149 Apple's is a disaster. 1223 00:45:45,150 --> 00:45:46,439 There's no secure boot. 1224 00:45:46,440 --> 00:45:48,509 There's no way to do a measured boot. 1225 00:45:48,510 --> 00:45:50,369 So you can't verify the trustworthiness 1226 00:45:50,370 --> 00:45:51,749 of the system later. 1227 00:45:51,750 --> 00:45:52,979 Even if you're using full disk 1228 00:45:52,980 --> 00:45:55,289 encryption, the password prompt could 1229 00:45:55,290 --> 00:45:57,599 be written by anything 1230 00:45:57,600 --> 00:45:59,129 it can then man in the middle, you store 1231 00:45:59,130 --> 00:46:01,139 your description, freeze, and then allow 1232 00:46:01,140 --> 00:46:02,429 anybody to have access to your system 1233 00:46:02,430 --> 00:46:05,219 later. Don't use Apple laptops 1234 00:46:05,220 --> 00:46:06,659 if you have anything. 1235 00:46:06,660 --> 00:46:08,159 You want to keep secrets in any way 1236 00:46:08,160 --> 00:46:09,160 whatsoever. 1237 00:46:16,560 --> 00:46:17,999 But obviously, if hardware isn't 1238 00:46:18,000 --> 00:46:19,649 trustworthy, we have no mechanism to 1239 00:46:19,650 --> 00:46:20,969 build trust of the sea if you can't be 1240 00:46:20,970 --> 00:46:21,970 trusted. 1241 00:46:22,550 --> 00:46:23,959 There's no way we can build a trustworthy 1242 00:46:23,960 --> 00:46:26,089 laptop if your hardware has been 1243 00:46:26,090 --> 00:46:27,559 designed by the manufacturer to be 1244 00:46:27,560 --> 00:46:29,479 untrustworthy, you can't do anything 1245 00:46:29,480 --> 00:46:31,219 about that afterwards. The only real 1246 00:46:31,220 --> 00:46:32,809 improvement you can make there is 1247 00:46:32,810 --> 00:46:34,609 eventually to have more control over the 1248 00:46:34,610 --> 00:46:35,779 entire process. 1249 00:46:35,780 --> 00:46:37,399 And that's still going to be cases where 1250 00:46:37,400 --> 00:46:40,010 even if we have fully. 1251 00:46:41,240 --> 00:46:43,549 Opensource CPU's, if 1252 00:46:43,550 --> 00:46:45,799 we have the ability to verify the status 1253 00:46:45,800 --> 00:46:47,809 of every transistor in the design and 1254 00:46:47,810 --> 00:46:49,519 ensure that the system is completely 1255 00:46:49,520 --> 00:46:52,039 trustworthy, when it was Fab's, 1256 00:46:52,040 --> 00:46:53,119 it could still have has a back door 1257 00:46:53,120 --> 00:46:55,369 introduced. Solving this is a very, 1258 00:46:55,370 --> 00:46:56,569 very difficult problem. 1259 00:46:56,570 --> 00:46:58,759 And I'm going to say that 1260 00:46:58,760 --> 00:47:01,039 I have no idea how to solve it. 1261 00:47:01,040 --> 00:47:03,349 But incremental improvements in security 1262 00:47:03,350 --> 00:47:05,959 are still improvements in security. 1263 00:47:05,960 --> 00:47:08,149 We can't just sit there 1264 00:47:08,150 --> 00:47:10,279 and say we can't solve the really hard 1265 00:47:10,280 --> 00:47:12,559 problems, so therefore we should ignore 1266 00:47:12,560 --> 00:47:13,519 every other problem. 1267 00:47:13,520 --> 00:47:15,799 We still need to do what 1268 00:47:15,800 --> 00:47:18,049 we can to make it easier for people 1269 00:47:18,050 --> 00:47:20,449 to verify that to the maximum 1270 00:47:20,450 --> 00:47:22,459 extent possible, that system is 1271 00:47:22,460 --> 00:47:23,460 trustworthy. 1272 00:47:24,170 --> 00:47:25,170 So. 1273 00:47:31,470 --> 00:47:32,969 There is some code available 1274 00:47:34,050 --> 00:47:36,239 for this to work for you to be able 1275 00:47:36,240 --> 00:47:38,099 to do trusted, but 1276 00:47:39,390 --> 00:47:41,729 you need a bootloader that does full TPM 1277 00:47:41,730 --> 00:47:44,699 measurements. I have a 1278 00:47:44,700 --> 00:47:47,369 set of patches to the shim first 1279 00:47:47,370 --> 00:47:49,529 Loeser that supports doing measurements. 1280 00:47:49,530 --> 00:47:51,899 I have some patches for grub that 1281 00:47:51,900 --> 00:47:53,279 also support doing measurements. 1282 00:47:53,280 --> 00:47:54,719 The combination of these means that you 1283 00:47:54,720 --> 00:47:56,429 can then have a completely measured 1284 00:47:56,430 --> 00:47:58,859 process up to the point where 1285 00:47:58,860 --> 00:48:00,359 the kernel starts. 1286 00:48:00,360 --> 00:48:01,649 So the energy is measured. 1287 00:48:01,650 --> 00:48:02,939 The Cardinals measured, grub's measured, 1288 00:48:02,940 --> 00:48:04,889 Chim's measured. Any module grubbed loads 1289 00:48:04,890 --> 00:48:07,199 are measured. I'm even measuring 1290 00:48:07,200 --> 00:48:09,059 the commands that you type into grubbed, 1291 00:48:09,060 --> 00:48:11,909 which is maybe overkill. 1292 00:48:11,910 --> 00:48:13,979 And then the code, as I demonstrated for 1293 00:48:13,980 --> 00:48:16,309 generating and encrypting the 1294 00:48:16,310 --> 00:48:18,839 top secrets and then decrypting 1295 00:48:18,840 --> 00:48:21,059 those, is available there as well. 1296 00:48:22,470 --> 00:48:24,899 Ideally, we would integrate these 1297 00:48:24,900 --> 00:48:27,059 into systems such that it's 1298 00:48:27,060 --> 00:48:29,219 very straightforward for users to 1299 00:48:29,220 --> 00:48:30,769 just enable this functionality. 1300 00:48:32,160 --> 00:48:33,689 There are some additional complexities 1301 00:48:33,690 --> 00:48:36,599 around this, which I'm happy to talk to 1302 00:48:36,600 --> 00:48:38,549 people about if they're interested, but 1303 00:48:38,550 --> 00:48:40,829 it's sufficiently subtle that it's 1304 00:48:40,830 --> 00:48:42,509 probably not worth it right now. 1305 00:48:42,510 --> 00:48:44,759 Anyway, we have about ten 1306 00:48:44,760 --> 00:48:46,889 minutes left, so if 1307 00:48:46,890 --> 00:48:49,199 we could go to some questions. 1308 00:48:59,690 --> 00:49:01,909 As always, if you have questions, please 1309 00:49:01,910 --> 00:49:03,949 line up at the mikes, there are three 1310 00:49:03,950 --> 00:49:06,079 mikes on each side and two 1311 00:49:06,080 --> 00:49:07,789 mikes on the top. 1312 00:49:07,790 --> 00:49:09,199 And also if you're on the stream, of 1313 00:49:09,200 --> 00:49:11,599 course, as always, go to the ISC 1314 00:49:11,600 --> 00:49:13,999 general, go on Twitter and people 1315 00:49:14,000 --> 00:49:16,629 will read out. Your questions for you 1316 00:49:16,630 --> 00:49:18,139 will actually start from the Internet, 1317 00:49:18,140 --> 00:49:19,189 please. 1318 00:49:19,190 --> 00:49:20,209 Thank you. 1319 00:49:20,210 --> 00:49:22,849 We had some discussion on the IOC 1320 00:49:22,850 --> 00:49:25,009 whether it would be possible to 1321 00:49:25,010 --> 00:49:27,439 use the NFC approach, but instead 1322 00:49:27,440 --> 00:49:29,509 replace it with, for 1323 00:49:29,510 --> 00:49:31,759 example, a QR code so 1324 00:49:31,760 --> 00:49:33,979 that the TPM presents some signed 1325 00:49:33,980 --> 00:49:35,689 material and a QR code. 1326 00:49:35,690 --> 00:49:37,969 The phone verifies the signatures produce 1327 00:49:37,970 --> 00:49:40,339 a six digit number. 1328 00:49:40,340 --> 00:49:42,889 You have to enter in your computer to 1329 00:49:42,890 --> 00:49:44,239 proceed with a secure about. 1330 00:49:45,280 --> 00:49:47,769 Yeah, I don't see any reason that that 1331 00:49:47,770 --> 00:49:48,770 wouldn't work. 1332 00:49:50,130 --> 00:49:51,130 Sure. 1333 00:49:54,150 --> 00:49:56,369 Yes, so you would need to ensure 1334 00:49:56,370 --> 00:49:58,049 that the application didn't just provide 1335 00:49:58,050 --> 00:49:59,729 a six digit number, but the application 1336 00:49:59,730 --> 00:50:01,229 also, Princesa, an indication as to 1337 00:50:01,230 --> 00:50:03,779 whether the cert verified 1338 00:50:03,780 --> 00:50:05,579 just. But, yeah, I don't see any reason 1339 00:50:05,580 --> 00:50:06,580 that that wouldn't work. 1340 00:50:08,430 --> 00:50:10,989 Microphone number eight, please. 1341 00:50:10,990 --> 00:50:13,079 Yes, thanks for the great talk. 1342 00:50:13,080 --> 00:50:15,329 I would like to know how, you know, 1343 00:50:15,330 --> 00:50:17,429 if you like, see the TPM stuff 1344 00:50:17,430 --> 00:50:19,619 to the configuration registers, like 1345 00:50:19,620 --> 00:50:21,869 with your bootloader signature and stuff. 1346 00:50:21,870 --> 00:50:24,149 How does this or does this even handle 1347 00:50:24,150 --> 00:50:25,150 updates? 1348 00:50:25,740 --> 00:50:28,019 That was the subtlety that I was 1349 00:50:28,020 --> 00:50:30,659 hoping to just conveniently allied. 1350 00:50:30,660 --> 00:50:32,729 Right now there 1351 00:50:32,730 --> 00:50:34,019 are a few ways of doing this. 1352 00:50:34,020 --> 00:50:36,899 So, for instance, you could pass 1353 00:50:36,900 --> 00:50:38,609 when you perform an update, when you know 1354 00:50:38,610 --> 00:50:41,159 that the measurement is going to change, 1355 00:50:41,160 --> 00:50:43,259 you could have a mechanism for passing 1356 00:50:43,260 --> 00:50:45,179 that information back to the bootloader. 1357 00:50:45,180 --> 00:50:46,919 The bootloader could then rather than 1358 00:50:46,920 --> 00:50:49,289 loading the kernel, and anybody 1359 00:50:49,290 --> 00:50:51,689 could instead just extend 1360 00:50:51,690 --> 00:50:53,339 the perform the same measurements. 1361 00:50:53,340 --> 00:50:55,259 But rather than booting the kernel, it 1362 00:50:55,260 --> 00:50:57,689 can then unseal the secret 1363 00:50:57,690 --> 00:51:00,209 reseal. It's the new values and then 1364 00:51:00,210 --> 00:51:02,339 reboot. And then that was 1365 00:51:02,340 --> 00:51:04,019 work. That means that you need to have a 1366 00:51:04,020 --> 00:51:06,599 secure communication channel between the 1367 00:51:06,600 --> 00:51:08,819 operating system and bootloader. 1368 00:51:08,820 --> 00:51:10,079 I think there's a couple of ways you 1369 00:51:10,080 --> 00:51:12,029 could potentially do that with EFI 1370 00:51:12,030 --> 00:51:13,649 authenticated variables. 1371 00:51:13,650 --> 00:51:15,630 But this is a thing where 1372 00:51:17,070 --> 00:51:19,229 the way that most existing 1373 00:51:19,230 --> 00:51:21,239 implementations get around this is that 1374 00:51:21,240 --> 00:51:23,309 when you do an update, the 1375 00:51:23,310 --> 00:51:25,379 secret is unsealed 1376 00:51:25,380 --> 00:51:27,629 and then say to the hard drive, you then 1377 00:51:27,630 --> 00:51:30,089 boot without verification 1378 00:51:30,090 --> 00:51:31,229 and then you receive it. 1379 00:51:31,230 --> 00:51:33,119 And that's not entirely ideal. 1380 00:51:33,120 --> 00:51:35,279 I think that maybe ends up encouraging 1381 00:51:35,280 --> 00:51:37,439 users to behave in a 1382 00:51:37,440 --> 00:51:38,440 reckless manner. 1383 00:51:40,010 --> 00:51:42,109 But, yeah, the 1384 00:51:42,110 --> 00:51:44,599 state of the arts here is mixed, 1385 00:51:44,600 --> 00:51:46,789 even proprietary operating systems 1386 00:51:46,790 --> 00:51:48,889 don't do a great job of it. 1387 00:51:48,890 --> 00:51:50,659 I think that that's something where we 1388 00:51:50,660 --> 00:51:52,669 could come up with something better, but 1389 00:51:52,670 --> 00:51:54,199 it's going to be some work figuring out 1390 00:51:54,200 --> 00:51:55,879 exactly how to integrate this with update 1391 00:51:55,880 --> 00:51:57,829 mechanisms. It's possible, but it's not 1392 00:51:57,830 --> 00:51:58,830 convenient. 1393 00:52:00,450 --> 00:52:02,449 Microphone number one, please. 1394 00:52:02,450 --> 00:52:04,559 I'm sorry if 1395 00:52:04,560 --> 00:52:06,709 you already answered this, I was late 1396 00:52:06,710 --> 00:52:08,549 to the talk, but have you ever looked at 1397 00:52:08,550 --> 00:52:10,859 the crummiest security design 1398 00:52:10,860 --> 00:52:13,179 and their use of TPIMs and secure 1399 00:52:13,180 --> 00:52:14,879 but I mean, they control the hardware 1400 00:52:14,880 --> 00:52:16,169 platform as well, so. 1401 00:52:16,170 --> 00:52:17,129 Right. So cheap. 1402 00:52:17,130 --> 00:52:20,159 And Chrome OS is. 1403 00:52:21,560 --> 00:52:23,369 Based in the states that the TPM is the 1404 00:52:23,370 --> 00:52:26,029 abuse of trust, and you then have 1405 00:52:26,030 --> 00:52:27,379 secrets for things like hard drive 1406 00:52:27,380 --> 00:52:29,749 encryption since the TPM, this is still. 1407 00:52:31,290 --> 00:52:33,629 This does ensure that if the system 1408 00:52:33,630 --> 00:52:35,249 is no longer trustworthy, that you do not 1409 00:52:35,250 --> 00:52:37,349 have access to your secrets, but it's 1410 00:52:37,350 --> 00:52:39,329 still vulnerable to the state where you 1411 00:52:39,330 --> 00:52:41,099 have a compromised system that then 1412 00:52:41,100 --> 00:52:43,229 presents a fake prompt 1413 00:52:43,230 --> 00:52:45,599 for you to type in your passphrase 1414 00:52:45,600 --> 00:52:48,059 or something and then reboots itself. 1415 00:52:48,060 --> 00:52:49,060 So. 1416 00:52:51,060 --> 00:52:53,249 Cruz gets a lot of the way there, but 1417 00:52:53,250 --> 00:52:54,629 it's still vulnerable to certain classes 1418 00:52:54,630 --> 00:52:56,819 of attack, the laptop 1419 00:52:56,820 --> 00:52:58,469 doesn't do a good job of proving to you 1420 00:52:58,470 --> 00:53:00,089 that it's in a trustworthy state. 1421 00:53:00,090 --> 00:53:02,249 It merely asserts that it is 1422 00:53:02,250 --> 00:53:04,069 OK. I'm not entirely sure if that will 1423 00:53:04,070 --> 00:53:05,300 work, but I'll think about it. 1424 00:53:07,260 --> 00:53:08,760 Microphone number two, please. 1425 00:53:10,350 --> 00:53:12,479 OK. I have two small questions. 1426 00:53:12,480 --> 00:53:15,089 The first one would be, why is the TPM 1427 00:53:15,090 --> 00:53:16,319 on the one, the water, not just 1428 00:53:16,320 --> 00:53:18,779 integrating the C.P.U to prevent 1429 00:53:18,780 --> 00:53:20,939 a while to just remove 1430 00:53:20,940 --> 00:53:22,049 it or something? 1431 00:53:22,050 --> 00:53:23,130 And the second, 1432 00:53:24,570 --> 00:53:26,639 wouldn't it be a very 1433 00:53:26,640 --> 00:53:28,050 simple 1434 00:53:29,070 --> 00:53:31,199 solution to just restart 1435 00:53:31,200 --> 00:53:33,299 a computer of the TPM 1436 00:53:33,300 --> 00:53:35,309 decides that isn't trustworthy and start 1437 00:53:35,310 --> 00:53:37,739 off well, doing a quick 1438 00:53:37,740 --> 00:53:39,869 code and or a 1439 00:53:39,870 --> 00:53:41,459 LED light or something. 1440 00:53:41,460 --> 00:53:42,690 So the first question. 1441 00:53:46,710 --> 00:53:48,419 The short answer is international 1442 00:53:48,420 --> 00:53:50,669 geopolitics, the 1443 00:53:50,670 --> 00:53:53,369 long answer is TPIMs 1444 00:53:53,370 --> 00:53:55,469 fall into the kinds of categories 1445 00:53:55,470 --> 00:53:57,419 of hardware that it's difficult to export 1446 00:53:57,420 --> 00:53:58,799 in certain countries. 1447 00:53:58,800 --> 00:54:00,869 If Intel integrated 1448 00:54:00,870 --> 00:54:03,029 teams into their hardware, Intel would 1449 00:54:03,030 --> 00:54:04,709 not be able to sell those CPU's in 1450 00:54:04,710 --> 00:54:06,419 certain countries. 1451 00:54:06,420 --> 00:54:07,420 Also. 1452 00:54:08,260 --> 00:54:10,419 Various people relying on teams do not 1453 00:54:10,420 --> 00:54:12,459 necessarily trust U.S. 1454 00:54:12,460 --> 00:54:14,679 manufacturers, teams are 1455 00:54:14,680 --> 00:54:16,479 pretty much all Penkin possible. 1456 00:54:16,480 --> 00:54:18,789 You can just swap them out. 1457 00:54:18,790 --> 00:54:20,919 If you look at the tables 1458 00:54:20,920 --> 00:54:23,049 for a Lenovo, you can actually see 1459 00:54:23,050 --> 00:54:25,119 that Lenovo supports on the same 1460 00:54:25,120 --> 00:54:27,219 system CPMs from four different 1461 00:54:27,220 --> 00:54:28,329 manufacturers. 1462 00:54:28,330 --> 00:54:30,039 And some of that's just for convenience 1463 00:54:30,040 --> 00:54:31,179 in terms of 1464 00:54:32,260 --> 00:54:33,939 choosing whoever is cheapest for a 1465 00:54:33,940 --> 00:54:35,109 particular production run. 1466 00:54:35,110 --> 00:54:36,699 But some of that is because certain 1467 00:54:36,700 --> 00:54:38,979 customers will want teams 1468 00:54:38,980 --> 00:54:41,229 from a certain manufacturer because 1469 00:54:41,230 --> 00:54:43,059 they trust that country. 1470 00:54:43,060 --> 00:54:45,249 Some of them will want 1471 00:54:45,250 --> 00:54:46,659 teams from a certain country because 1472 00:54:46,660 --> 00:54:47,769 they're legally required to. 1473 00:54:47,770 --> 00:54:49,959 In China, you're probably going to want 1474 00:54:49,960 --> 00:54:51,089 a Chinese TPM. 1475 00:54:52,480 --> 00:54:54,819 So things are a little more complicated 1476 00:54:54,820 --> 00:54:55,789 than you might imagine. 1477 00:54:55,790 --> 00:54:57,759 The upside of this is that if your CPU's 1478 00:54:57,760 --> 00:54:58,760 untrustworthy. 1479 00:54:59,740 --> 00:55:01,839 Someone would still need to compromise 1480 00:55:01,840 --> 00:55:03,999 your TPM as well, and if your 1481 00:55:04,000 --> 00:55:06,219 TPM comes from, say, Infineon, 1482 00:55:06,220 --> 00:55:08,049 if it's a German KPM and if you're CPU's 1483 00:55:08,050 --> 00:55:10,239 from Intel, you're going to 1484 00:55:10,240 --> 00:55:12,669 either need someone with compromised both 1485 00:55:12,670 --> 00:55:15,129 manufacturing in Germany and the U.S. 1486 00:55:15,130 --> 00:55:17,169 or you're going to have needed to have 1487 00:55:17,170 --> 00:55:19,689 screws up badly enough that both the NSA 1488 00:55:19,690 --> 00:55:21,849 and Germany are really upset that 1489 00:55:21,850 --> 00:55:22,850 you. 1490 00:55:24,190 --> 00:55:25,929 The second question, why can't people 1491 00:55:25,930 --> 00:55:27,339 just reboot the system? 1492 00:55:27,340 --> 00:55:29,619 The TPM has no mechanism to 1493 00:55:29,620 --> 00:55:31,449 operate on its own. The TPM just does not 1494 00:55:31,450 --> 00:55:33,589 have that ability. 1495 00:55:33,590 --> 00:55:35,289 It's impossible to do that with existing 1496 00:55:35,290 --> 00:55:36,290 hardware. 1497 00:55:38,230 --> 00:55:39,630 Signal angel, please. 1498 00:55:43,030 --> 00:55:44,030 Thank you. 1499 00:55:45,040 --> 00:55:46,839 Are there any operating system project 1500 00:55:46,840 --> 00:55:48,999 that would be happy to implement this 1501 00:55:49,000 --> 00:55:51,069 as their standard? 1502 00:55:51,070 --> 00:55:53,199 I don't see any reason why 1503 00:55:53,200 --> 00:55:54,609 any free software operating system 1504 00:55:54,610 --> 00:55:55,869 couldn't have this functionality added to 1505 00:55:55,870 --> 00:55:58,029 it. It's really just a matter of 1506 00:55:58,030 --> 00:55:59,050 people putting in the work. 1507 00:56:00,100 --> 00:56:02,109 I keep meaning to get round to it, but 1508 00:56:02,110 --> 00:56:03,610 I'm also incredibly lazy. 1509 00:56:07,280 --> 00:56:10,189 No one plays a 1510 00:56:10,190 --> 00:56:12,289 a tool, a tool 1511 00:56:12,290 --> 00:56:14,239 called the Evil Abigael was released 1512 00:56:14,240 --> 00:56:16,639 recently, that model that automates 1513 00:56:16,640 --> 00:56:18,889 modifying the unit to insert a back 1514 00:56:18,890 --> 00:56:21,469 door. I was wondering if you had 1515 00:56:21,470 --> 00:56:23,659 looked at that tool or had any comment on 1516 00:56:23,660 --> 00:56:24,769 it. 1517 00:56:24,770 --> 00:56:26,869 So that is basically 1518 00:56:26,870 --> 00:56:28,129 the kind of attack that this is intended 1519 00:56:28,130 --> 00:56:30,259 to protect against if the NSA is 1520 00:56:30,260 --> 00:56:31,669 modifieds than the measurements of the 1521 00:56:31,670 --> 00:56:32,729 NSA will change. 1522 00:56:32,730 --> 00:56:34,129 And so the secret won't be released. 1523 00:56:34,130 --> 00:56:36,919 So evil Abigael will just not work. 1524 00:56:36,920 --> 00:56:37,920 Thank you. 1525 00:56:38,540 --> 00:56:40,269 Number two, please. 1526 00:56:40,270 --> 00:56:42,559 Thanks to the 1527 00:56:42,560 --> 00:56:43,759 implementation of the idea, you mentioned 1528 00:56:43,760 --> 00:56:45,319 that one of the problems was you had to 1529 00:56:45,320 --> 00:56:47,119 pull the secret out of the TPM in order 1530 00:56:47,120 --> 00:56:50,239 to actually perform the operation. 1531 00:56:50,240 --> 00:56:51,320 But the algorithms, 1532 00:56:52,340 --> 00:56:53,839 it's like H.R. one or something like 1533 00:56:53,840 --> 00:56:55,579 that. Is the TPM capable of doing it 1534 00:56:55,580 --> 00:56:56,929 directly? No more 1535 00:56:58,940 --> 00:57:00,619 upsetting, but yeah, there's been a lot 1536 00:57:00,620 --> 00:57:01,620 easier in that case. 1537 00:57:03,050 --> 00:57:06,149 And to again, please, hello, 1538 00:57:06,150 --> 00:57:08,239 what prevents the following attack, 1539 00:57:08,240 --> 00:57:10,249 an attacker steals your laptop, creates 1540 00:57:10,250 --> 00:57:12,739 an identical copy where your laptop was, 1541 00:57:12,740 --> 00:57:15,019 and then when the laptop when 1542 00:57:15,020 --> 00:57:17,149 you put the fake laptop, it shows you 1543 00:57:17,150 --> 00:57:19,279 a secret and the attacker is 1544 00:57:19,280 --> 00:57:21,199 booting your legitimate laptop at the 1545 00:57:21,200 --> 00:57:23,119 same time communicating with the fake 1546 00:57:23,120 --> 00:57:24,739 laptop and showing that same secret. 1547 00:57:26,150 --> 00:57:28,399 OK, so basically the 1548 00:57:28,400 --> 00:57:29,959 system is compromised such that rather 1549 00:57:29,960 --> 00:57:32,419 than talking to the TPM 1550 00:57:32,420 --> 00:57:34,549 locally, it's talking to a remote TPM, 1551 00:57:34,550 --> 00:57:35,550 correct? 1552 00:57:36,120 --> 00:57:37,120 Oh 1553 00:57:38,420 --> 00:57:39,739 yeah, that sounds upsetting. 1554 00:57:40,930 --> 00:57:42,979 I make sure you put your laptop in the 1555 00:57:42,980 --> 00:57:43,980 Faraday cage. 1556 00:57:46,280 --> 00:57:47,280 Thank you. 1557 00:57:47,690 --> 00:57:49,549 I use lots of stickers on your laptop, 1558 00:57:49,550 --> 00:57:51,859 maybe microphone number 1559 00:57:51,860 --> 00:57:52,860 eight, please. 1560 00:57:53,730 --> 00:57:56,179 Are there any remote attestation 1561 00:57:56,180 --> 00:57:58,219 or hardware boot measurement features 1562 00:57:58,220 --> 00:58:00,650 available on NYNEX 86 systems? 1563 00:58:03,580 --> 00:58:05,979 CPMs are not fundamentally ties to 1564 00:58:05,980 --> 00:58:08,679 Eighty-six, there are certainly 1565 00:58:08,680 --> 00:58:10,869 systems in existence that have TPN base 1566 00:58:10,870 --> 00:58:13,179 functionality, in some cases a hardware 1567 00:58:13,180 --> 00:58:15,339 TPN, in some cases a software 1568 00:58:15,340 --> 00:58:17,049 team that's running in trust. 1569 00:58:17,050 --> 00:58:19,389 Truslow, which is again utterly 1570 00:58:19,390 --> 00:58:20,649 terrifying. 1571 00:58:20,650 --> 00:58:21,650 But 1572 00:58:22,810 --> 00:58:24,549 in that case, you can do exactly the same 1573 00:58:24,550 --> 00:58:26,739 operations in terms of whether 1574 00:58:26,740 --> 00:58:29,019 there are other implementations 1575 00:58:29,020 --> 00:58:31,089 based on completely different 1576 00:58:31,090 --> 00:58:32,949 technology, but basically solving the 1577 00:58:32,950 --> 00:58:35,229 same problem. None that I know of. 1578 00:58:35,230 --> 00:58:36,939 I'd say this if this is a problem you're 1579 00:58:36,940 --> 00:58:39,099 trying to solve, the easiest way to do 1580 00:58:39,100 --> 00:58:41,329 it is just to drop a among the system. 1581 00:58:41,330 --> 00:58:43,629 There is nothing specific about 1582 00:58:43,630 --> 00:58:45,759 them. You could quite happily have 1583 00:58:45,760 --> 00:58:47,469 a TPM attached to a MIPS if you wanted. 1584 00:58:48,760 --> 00:58:49,760 Thanks. 1585 00:58:50,190 --> 00:58:51,289 Internet, please. 1586 00:58:54,940 --> 00:58:56,649 Thank you. What is the difference between 1587 00:58:56,650 --> 00:58:58,749 your coat compared to secure gear up 1588 00:58:58,750 --> 00:59:00,879 to Miko's and 1589 00:59:00,880 --> 00:59:02,829 secure grub to so security? 1590 00:59:02,830 --> 00:59:05,049 Is that the one from the government 1591 00:59:05,050 --> 00:59:07,090 that the French organization? 1592 00:59:11,180 --> 00:59:12,180 OK, anyway, 1593 00:59:13,490 --> 00:59:14,490 that's 1594 00:59:15,560 --> 00:59:17,449 my recollection, is that other 1595 00:59:17,450 --> 00:59:20,449 implementations only support 1596 00:59:20,450 --> 00:59:22,519 TPIMs on Biosystems, 1597 00:59:22,520 --> 00:59:24,829 my implementation also adds support for 1598 00:59:24,830 --> 00:59:25,729 EFI. 1599 00:59:25,730 --> 00:59:27,649 So you can combine this with vesicular 1600 00:59:27,650 --> 00:59:29,749 boots and you can have verification 1601 00:59:29,750 --> 00:59:31,849 of the status of the nice things about 1602 00:59:31,850 --> 00:59:33,169 these your boots. 1603 00:59:33,170 --> 00:59:35,329 If plantation's this is that your 1604 00:59:35,330 --> 00:59:37,819 key database is hashed into 1605 00:59:37,820 --> 00:59:39,199 a PCR as well. 1606 00:59:39,200 --> 00:59:41,179 So you can verify in the same way that 1607 00:59:41,180 --> 00:59:43,129 nobody's tampered with the key database. 1608 00:59:43,130 --> 00:59:44,750 And if you're really. 1609 00:59:46,200 --> 00:59:47,519 This allows for some interesting 1610 00:59:47,520 --> 00:59:50,159 policies, like you can only 1611 00:59:50,160 --> 00:59:52,319 seal against the firmware 1612 00:59:52,320 --> 00:59:54,719 and the key database, 1613 00:59:54,720 --> 00:59:56,819 and then you can just assert that 1614 00:59:56,820 --> 00:59:59,069 secure boot resulted in everything 1615 00:59:59,070 --> 01:00:00,209 else being trustworthy. 1616 01:00:00,210 --> 01:00:03,209 All that makes updates simpler because 1617 01:00:03,210 --> 01:00:05,339 sign stuff just boots magically without 1618 01:00:05,340 --> 01:00:06,340 you having to interfere with this. 1619 01:00:07,660 --> 01:00:09,429 Anyway, yeah, I think that's the main 1620 01:00:09,430 --> 01:00:11,559 difference, and that's 1621 01:00:11,560 --> 01:00:13,360 it, please, once again, thank Matthew.