WEBVTT 00:00.000 --> 00:11.000 Thank you very much indeed. 00:11.000 --> 00:13.000 So as you said, my name is James Bottenley. 00:13.000 --> 00:15.000 I've been a long-time criminal developer. 00:15.000 --> 00:18.000 It's because he subsists the maintainer, peer-risk architecture, 00:18.000 --> 00:20.000 maintainer, done containers. 00:20.000 --> 00:24.000 And now I'm doing whatliness calls my midlife provision, 00:24.000 --> 00:26.000 which is TPMs. 00:26.000 --> 00:29.600 And I also have done a lot of open source advocacy, 00:29.600 --> 00:32.000 but I won't be talking to you anything about that, 00:32.000 --> 00:36.000 because I did my main track talk yesterday about it. 00:36.000 --> 00:40.000 This talk also is a talk I gave in Japan 00:40.000 --> 00:42.000 and a slightly longer time frame. 00:42.000 --> 00:44.000 So I'm going to try and whip through it. 00:44.000 --> 00:46.000 If there's anything you don't understand, 00:46.000 --> 00:48.000 I may leave time for questions, 00:48.000 --> 00:50.000 but if you want to see me screw up with a live demo, 00:50.000 --> 00:52.000 don't ask too many questions otherwise 00:52.000 --> 00:54.000 we won't get to the demo. 00:54.000 --> 00:56.000 So history and background is that TPMs, 00:56.000 --> 00:58.000 you probably all heard of them by now, 00:58.000 --> 01:00.000 because Microsoft is mandating them. 01:00.000 --> 01:02.000 They're a discrete chip, 01:02.000 --> 01:04.000 often, sometimes they can be in firmware, 01:04.000 --> 01:06.000 but they sit on a system bus 01:06.000 --> 01:09.000 and usually a laptop can be a server somewhere else. 01:09.000 --> 01:11.000 They look a bit like that. 01:11.000 --> 01:13.000 This is a TPM20, 01:13.000 --> 01:16.000 you can actually see it's SLB9665, 01:16.000 --> 01:18.000 which is an affinity on TPM. 01:18.000 --> 01:20.000 So this is what little things look like. 01:20.000 --> 01:22.000 As I said, 01:22.000 --> 01:24.000 they can also be firmware based. 01:24.000 --> 01:25.000 For my means, 01:25.000 --> 01:28.000 they technically run on either your main CPU 01:28.000 --> 01:31.000 or an adjacent processor to your CPU. 01:31.000 --> 01:34.000 The way most AMD and Intel firmware TPMs 01:34.000 --> 01:37.000 work is they actually run on a separate CPU 01:37.000 --> 01:39.000 that runs the management engine. 01:39.000 --> 01:42.000 So Intel firmware TPMs run on the management engines, 01:42.000 --> 01:44.000 AMD firmware TPMs run on what's called 01:44.000 --> 01:45.000 the security processor, 01:45.000 --> 01:48.000 which is also an adjacent arm chip 01:48.000 --> 01:51.000 that's built into the AMD core. 01:52.000 --> 01:55.000 Threats of the TPM include things like 01:55.000 --> 01:57.000 Man in the Middle or Interposer Attack. 01:57.000 --> 02:00.000 So when we first started doing TPMs in Linux, 02:00.000 --> 02:02.000 we were completely oblivious to all of this. 02:02.000 --> 02:05.000 The standard assumption is the Linux kernel runs 02:05.000 --> 02:06.000 on top of the hardware. 02:06.000 --> 02:08.000 It can communicate directly over a hardware bus 02:08.000 --> 02:10.000 to the TPM, 02:10.000 --> 02:12.000 and because it's communicating directly over hardware bus, 02:12.000 --> 02:14.000 just like a PCI card, 02:14.000 --> 02:16.000 there's no need for any security, 02:16.000 --> 02:18.000 so we didn't build any into the kernel. 02:18.000 --> 02:21.000 And then if you fast forward several years, 02:21.000 --> 02:22.000 a guy from Canada, 02:22.000 --> 02:24.000 the Canadian Security Research Institute 02:24.000 --> 02:25.000 came along and said, 02:25.000 --> 02:26.000 you know, 02:26.000 --> 02:28.000 with a very simple piece of hardware, 02:28.000 --> 02:31.000 I can just plug into the bus that your TPM is on. 02:31.000 --> 02:33.000 I can snoot all of the transactions 02:33.000 --> 02:34.000 and worse than that, 02:34.000 --> 02:36.000 I can actually modify those transactions. 02:36.000 --> 02:37.000 And therefore, 02:37.000 --> 02:39.000 if you route your security view laptop 02:39.000 --> 02:41.000 in your TPM, 02:41.000 --> 02:44.000 I can pretty much break any form of security you have. 02:44.000 --> 02:46.000 And if you look at what's been happening for 02:46.000 --> 02:48.000 security nowadays, 02:48.000 --> 02:50.000 Microsoft really routes the TPM, 02:50.000 --> 02:52.000 the security in the TPM, 02:52.000 --> 02:53.000 and the system day in line up 02:53.000 --> 02:56.000 are forcing us to route the security in the TPM as well, 02:56.000 --> 02:58.000 with this system DTPM2 krypton role, 02:58.000 --> 03:00.000 and so on. 03:00.000 --> 03:02.000 So, the intoposer, 03:02.000 --> 03:03.000 he built, 03:03.000 --> 03:04.000 is of two types. 03:04.000 --> 03:06.000 There's something called a passive intoposer, 03:06.000 --> 03:07.000 which just sits on the bus 03:07.000 --> 03:09.000 and it's the transaction. 03:09.000 --> 03:11.000 So, if you're passing things like passwords 03:11.000 --> 03:13.000 or disc keys in the clear, 03:13.000 --> 03:15.000 it just quietly snoops them 03:15.000 --> 03:19.000 off to your local foreign enforcement agency. 03:19.000 --> 03:21.000 And then there's these things called active intoposer. 03:21.000 --> 03:23.000 So, passive intoposer only listens, 03:23.000 --> 03:25.000 but an active intoposer can actually 03:25.000 --> 03:28.000 alter the transactions on the bus as well. 03:28.000 --> 03:29.000 And this gives it the scope 03:29.000 --> 03:31.000 to see what you're doing 03:31.000 --> 03:33.000 for, say, you request the information, 03:33.000 --> 03:34.000 take it off, 03:34.000 --> 03:36.000 and substitute something of its own desire. 03:36.000 --> 03:38.000 This allows it to do things like 03:38.000 --> 03:40.000 intercept, 03:40.000 --> 03:42.000 do do man in the middle of deception, 03:42.000 --> 03:44.000 even of security PN transactions. 03:44.000 --> 03:49.000 And I'll actually explain how that happens in a while. 03:49.000 --> 03:52.000 So, TPM security depends on 03:52.000 --> 03:54.000 something called sessions. 03:54.000 --> 03:59.000 This is a fairly abstract concept, 03:59.000 --> 04:01.000 but it's based on a shared session key 04:01.000 --> 04:02.000 between the TPM and the user. 04:02.000 --> 04:04.000 This is almost identical to the way things 04:04.000 --> 04:06.000 like TLS work over the network. 04:06.000 --> 04:09.000 You have a mechanism for generating a shared key 04:09.000 --> 04:11.000 that's only known between the two parties 04:11.000 --> 04:13.000 and then you communicate over 04:13.000 --> 04:17.000 and encrypt a channel using that key. 04:17.000 --> 04:20.000 The TPM is actually tries to be very clever about this. 04:20.000 --> 04:22.000 It derives a rolling key 04:22.000 --> 04:24.000 from what a call the H Mac keys 04:24.000 --> 04:26.000 that were initially exchanged. 04:26.000 --> 04:27.000 And then every transaction, 04:27.000 --> 04:28.000 the TPM, 04:28.000 --> 04:29.000 exchanges and norms, 04:29.000 --> 04:31.000 and the keys for the next transaction 04:31.000 --> 04:33.000 are based on those nonsense. 04:33.000 --> 04:35.000 So, basically you use a different 04:35.000 --> 04:37.000 symmetric key for every transaction. 04:37.000 --> 04:38.000 This is somewhat similar. 04:38.000 --> 04:41.000 Again, TLS does something like this, 04:41.000 --> 04:43.000 but usually it has a time period 04:43.000 --> 04:45.000 for rolling your security keys 04:45.000 --> 04:47.000 of the encrypted channel. 04:47.000 --> 04:49.000 So, TLS tends to roll the key every two minutes. 04:49.000 --> 04:51.000 The TPM rolls them on every transaction. 04:51.000 --> 04:55.000 And this is what makes it think it's really secure. 04:55.000 --> 04:57.000 The problem, of course, 04:57.000 --> 05:00.000 is that you need an initial shared secret 05:00.000 --> 05:03.000 to actually start this encrypted channel. 05:03.000 --> 05:05.000 So, the initial shared secret is called 05:05.000 --> 05:06.000 the session key, 05:06.000 --> 05:08.000 and in a TPM it's either bound, 05:08.000 --> 05:10.000 which is a shared secret. 05:10.000 --> 05:13.000 It means that, and nobody in the internet 05:13.000 --> 05:14.000 works like this anymore. 05:14.000 --> 05:15.000 If party A knows a secret, 05:15.000 --> 05:16.000 party B knows a secret. 05:16.000 --> 05:18.000 They can use that secret 05:18.000 --> 05:20.000 to the driver shared key to communicate. 05:20.000 --> 05:22.000 But usually, 05:22.000 --> 05:24.000 party A and party B don't know a shared secret. 05:24.000 --> 05:26.000 So, they have to actually come up 05:26.000 --> 05:27.000 with a way of getting on. 05:27.000 --> 05:30.000 So, the TPM also has a mechanism called 05:30.000 --> 05:31.000 salted sessions, 05:31.000 --> 05:33.000 which are basically where you manage 05:33.000 --> 05:35.000 to encrypt a secret 05:35.000 --> 05:37.000 and send it from one party to the other. 05:38.000 --> 05:42.000 So, when we add a TPM security to Linux 05:42.000 --> 05:45.000 in the face of all these interpersonal attacks, 05:45.000 --> 05:48.000 we actually included support for salted sessions 05:48.000 --> 05:49.000 because there's no way 05:49.000 --> 05:51.000 that a newly booted kernel 05:51.000 --> 05:52.000 has a shared secret 05:52.000 --> 05:55.000 that it shares with the TPM and nobody else knows. 05:55.000 --> 05:57.000 So, the only way of communicating 05:57.000 --> 05:58.000 securely with the TPM 05:58.000 --> 06:00.000 was for the kernel to make up a secret 06:00.000 --> 06:02.000 encrypted to a key in the TPM 06:02.000 --> 06:03.000 and then send it in, 06:03.000 --> 06:05.000 which is how salted session work. 06:06.000 --> 06:08.000 But there are significance, 06:08.000 --> 06:10.000 and I have to say that the kernel 06:10.000 --> 06:12.000 isn't unique in doing this. 06:12.000 --> 06:14.000 Pretty much everybody who uses a TPM 06:14.000 --> 06:16.000 in a kernel-like system 06:16.000 --> 06:17.000 or a boot-like system. 06:17.000 --> 06:19.000 So, Microsoft BitLocker 06:19.000 --> 06:21.000 works exactly like this as well. 06:21.000 --> 06:23.000 So, it wasn't just us. 06:23.000 --> 06:26.000 So, the first question with salted sessions 06:26.000 --> 06:29.000 is, where do you get the public key to encrypt the salty? 06:29.000 --> 06:30.000 Well, it turns out, 06:30.000 --> 06:32.000 the TPM has a load of public keys 06:32.000 --> 06:34.000 and it derives several in hierarchies, 06:34.000 --> 06:36.000 which I'll talk about later, 06:36.000 --> 06:38.000 and you can simply ask the TPM, 06:38.000 --> 06:39.000 and it tells you what its public key is, 06:39.000 --> 06:41.000 you encrypt the salt for the public key 06:41.000 --> 06:43.000 and send it to TPM, you're done. 06:43.000 --> 06:45.000 All TSSs, which are trusted secure stacks 06:45.000 --> 06:48.000 that run TPMs, currently do this. 06:48.000 --> 06:50.000 What's the problem with this 06:50.000 --> 06:52.000 in an active and deposit situation? 06:52.000 --> 06:54.000 You have asked the TPM for a public key, 06:54.000 --> 06:55.000 it's given you one back, 06:55.000 --> 06:58.000 and you encrypt it your salt for that public key. 06:58.000 --> 06:59.000 An active and deposit can say, 06:59.000 --> 07:01.000 hey, he's just asked for a key. 07:01.000 --> 07:03.000 Take the transaction off the bus 07:03.000 --> 07:05.000 and go, here's a duplicate key. 07:05.000 --> 07:07.000 I've just substituted that is, 07:07.000 --> 07:09.000 one, I have the private key to 07:09.000 --> 07:11.000 and that can therefore decrypt, 07:11.000 --> 07:13.000 and that means that the active and deposit 07:13.000 --> 07:15.000 can actually work as a man and the middle 07:15.000 --> 07:17.000 for all of these transactions. 07:17.000 --> 07:19.000 And therefore, it supplies its own public key. 07:19.000 --> 07:21.000 It can now decrypt the encrypted secret 07:21.000 --> 07:25.000 that you are using to protect all of your sessions. 07:25.000 --> 07:27.000 And this means it can decrypt the salt, 07:27.000 --> 07:29.000 decrypt every session, all it has to do 07:29.000 --> 07:31.000 is keep track of the rolling nonsense. 07:31.000 --> 07:33.000 The fact that you use a different key for every session 07:33.000 --> 07:35.000 doesn't matter because it has the master secret 07:35.000 --> 07:39.000 that allows it to deduce what the next key will be. 07:39.000 --> 07:41.000 So pretty much, in this situation, 07:41.000 --> 07:43.000 all security is gone. 07:43.000 --> 07:45.000 This is a bit of a disaster, 07:45.000 --> 07:47.000 especially as most trusted secure stacks 07:47.000 --> 07:49.000 don't ever make clear to any program 07:49.000 --> 07:51.000 that is written to use a TPM 07:51.000 --> 07:53.000 that they've actually done something 07:53.000 --> 07:57.000 as stupid as just asking the TPM for public key. 07:57.000 --> 07:59.000 And none of the trusted secure stacks 07:59.000 --> 08:01.000 that are currently sitting in the world today 08:01.000 --> 08:03.000 and there are several of them. 08:03.000 --> 08:05.000 The windows one, there's the Intel one, 08:05.000 --> 08:07.000 there's the IBM one. 08:07.000 --> 08:09.000 None of them actually provides you 08:09.000 --> 08:11.000 with an easy method of verifying the key 08:11.000 --> 08:13.000 that you've got. 08:13.000 --> 08:15.000 So we also have other problems 08:15.000 --> 08:17.000 when we begin to pose that. 08:17.000 --> 08:19.000 Because it sits often 08:19.000 --> 08:21.000 on the same bus as the TPM, 08:21.000 --> 08:23.000 it has access to a lot of other bus lines 08:23.000 --> 08:25.000 as well as just the data lines. 08:25.000 --> 08:28.000 So it's snooping the data by looking at the data lines. 08:28.000 --> 08:31.000 But it has access to the bus reset lines as well. 08:31.000 --> 08:34.000 And part of the problem is that TPM policies, 08:34.000 --> 08:36.000 you've probably, if you've gone to one 08:36.000 --> 08:38.000 of Linux talks about how you use TPM's 08:38.000 --> 08:40.000 of system D, you'll have heard them 08:40.000 --> 08:42.000 talk about these things called PCRs, 08:42.000 --> 08:44.000 platform control registers, 08:44.000 --> 08:46.000 which are effectively registers 08:46.000 --> 08:48.000 that can be wound forwards, 08:48.000 --> 08:49.000 but never backwards. 08:49.000 --> 08:51.000 So you're building up an immutable 08:51.000 --> 08:54.000 list of transactions that goes on in these PCRs. 08:54.000 --> 08:57.000 And the key assumption of these PCRs 08:57.000 --> 08:58.000 is they can never be reset. 08:58.000 --> 09:00.000 They can never go back to zero, 09:00.000 --> 09:01.000 and you can never rebuild them again. 09:01.000 --> 09:03.000 So you can extend them by building on top of them. 09:03.000 --> 09:05.000 It's a cryptographic extension, 09:05.000 --> 09:08.000 but you can't reset them and start building again 09:08.000 --> 09:10.000 unless you reset the entire machine. 09:10.000 --> 09:13.000 This is the fundamental assumption of how PCRs work. 09:13.000 --> 09:16.000 Unfortunately, if you've got access to the reset line 09:16.000 --> 09:20.000 on the bus and you toggle the TPM's reset, 09:20.000 --> 09:23.000 all of these PCRs will go back to zero. 09:23.000 --> 09:26.000 And unfortunately, that means that if your security 09:26.000 --> 09:28.000 and system D security does, 09:28.000 --> 09:31.000 depend on the fact that you can't reset the PCRs, 09:31.000 --> 09:34.000 a clever intaposer working in concert 09:34.000 --> 09:36.000 with an adversary at the keyboard of this machine 09:36.000 --> 09:37.000 can actually do that. 09:37.000 --> 09:39.000 And therefore, they can rebuild the PCRs 09:39.000 --> 09:42.000 to any state that you've locked any piece of information 09:42.000 --> 09:45.000 in the system too, which means that 09:45.000 --> 09:48.000 often when you set up system D, 09:48.000 --> 09:51.000 crypt and roll, you actually enroll certain PCRs 09:51.000 --> 09:53.000 that tell you it's secure booted 09:53.000 --> 09:55.000 and it boots exactly this kernel, 09:55.000 --> 09:57.000 and therefore, you just unlock the disk 09:57.000 --> 09:59.000 without asking for a password. 09:59.000 --> 10:02.000 And therefore, that means that I can reset your PCRs 10:02.000 --> 10:04.000 rebuild them to exactly the same state 10:04.000 --> 10:06.000 this unlock will occur, 10:06.000 --> 10:08.000 and I will get access to your password 10:08.000 --> 10:11.000 because I now have the PCRs in the correct state. 10:16.000 --> 10:19.000 So, how do you actually establish trust 10:19.000 --> 10:22.000 in any old key that the TPM has? 10:22.000 --> 10:24.000 The fundamental problem that trusted secure stacks 10:24.000 --> 10:26.000 don't solve for you. 10:26.000 --> 10:29.000 A long time ago, and currently today, 10:29.000 --> 10:32.000 TPM ship with a manufacturer 10:32.000 --> 10:35.000 a science certificate that actually validates 10:35.000 --> 10:38.000 something called the endorsement key. 10:38.000 --> 10:42.000 But the key it actually certifies 10:42.000 --> 10:45.000 can't be used to certify any other TPM objects. 10:45.000 --> 10:47.000 This is really annoying. 10:47.000 --> 10:51.000 TPMs actually generate what are called primary keys 10:51.000 --> 10:53.000 in these things called seats. 10:53.000 --> 10:57.000 This is TPM 202 has something called agile cryptography, 10:57.000 --> 11:01.000 which means that any old TPM can do RSA, 11:01.000 --> 11:04.000 can do elliptic curve for several curves and so on. 11:04.000 --> 11:06.000 There's talk of actually adding 11:06.000 --> 11:09.000 some of the cyber algorithms to make them post quantum. 11:09.000 --> 11:12.000 But the point is that in order to have agile cryptography, 11:12.000 --> 11:15.000 it doesn't quite, a TPM never knows 11:15.000 --> 11:17.000 what key you're going to be requesting, 11:17.000 --> 11:20.000 what algorithm you're going to be requesting. 11:20.000 --> 11:23.000 So instead of having key stored in the TPM, 11:23.000 --> 11:25.000 it has these things called seats, 11:25.000 --> 11:27.000 and then it runs a key derivation function 11:27.000 --> 11:29.000 on the seat based on the algorithm 11:29.000 --> 11:31.000 to derive the actual key. 11:31.000 --> 11:34.000 So usually TPMs don't actually come 11:34.000 --> 11:36.000 pre-programmed with keys. 11:36.000 --> 11:38.000 They come pre-programmed with a set of numbers 11:38.000 --> 11:40.000 and they derive those keys from the number. 11:40.000 --> 11:43.000 Now this sounds like it's all standard cryptography. 11:43.000 --> 11:44.000 It's very easy. 11:44.000 --> 11:45.000 There is a problem here, 11:45.000 --> 11:47.000 and that TPMs are very, 11:47.000 --> 11:49.000 very non-powerful systems. 11:49.000 --> 11:51.000 They're tiny little microchips. 11:51.000 --> 11:53.000 If you're asking for RSA keys, 11:53.000 --> 11:54.000 part of the KDF, 11:54.000 --> 11:56.000 the key derivation function, 11:56.000 --> 11:58.000 involves finding prime numbers. 11:58.000 --> 12:00.000 So it can actually take a TPM 12:00.000 --> 12:03.000 enormously long time to find a prime number. 12:03.000 --> 12:05.000 So if you're asking a TPM for an RSA 12:05.000 --> 12:07.000 in 1948 key, 12:07.000 --> 12:10.000 it can actually take it up to 60 seconds to generate that key. 12:10.000 --> 12:12.000 And this sort of goes up exponentially 12:12.000 --> 12:16.000 with the size of the keys that you're asking for. 12:16.000 --> 12:18.000 Yep, question. 12:18.000 --> 12:22.000 Yeah, the key derivation functions 12:22.000 --> 12:23.000 are deterministic. 12:23.000 --> 12:25.000 It will always generate the same key, 12:25.000 --> 12:27.000 but the problem is the generate RSA keys. 12:27.000 --> 12:29.000 You do need to guarantee a primeality, 12:29.000 --> 12:31.000 which is why it has to do a prime number search. 12:31.000 --> 12:33.000 It always finds the same prime number 12:33.000 --> 12:36.000 but it still has to do the search. 12:36.000 --> 12:39.000 So the point about that is always 12:39.000 --> 12:41.000 use a lip to curve keys with TPMs 12:41.000 --> 12:43.000 because they're much faster. 12:43.000 --> 12:45.000 RSA keys are pretty terrible. 12:45.000 --> 12:50.000 One of the properties that stored with these keys 12:50.000 --> 12:53.000 is whether they're signing or encryption keys. 12:53.000 --> 12:55.000 So all primary keys in a TPM 12:55.000 --> 12:58.000 there are actually come in two different types 12:58.000 --> 13:00.000 and there was mutually exclusive. 13:00.000 --> 13:04.000 They can either be a signing key or they can be an encryption key 13:04.000 --> 13:05.000 but they can't be both. 13:05.000 --> 13:09.000 And the TPMs can only certify objects with signing keys. 13:09.000 --> 13:10.000 And if you remember, 13:10.000 --> 13:13.000 the TPM certificate is certifying an encryption key 13:13.000 --> 13:14.000 or the signing key. 13:14.000 --> 13:16.000 That's why the TPM certificate 13:16.000 --> 13:21.000 can't be used certifying any other objects in the TPM. 13:21.000 --> 13:23.000 The EK certificate, 13:23.000 --> 13:27.000 like I said, was certifying an encryption key. 13:27.000 --> 13:30.000 There is a, I mean, the industry is observed 13:30.000 --> 13:32.000 that this is a bit of a problem 13:32.000 --> 13:35.000 and why don't EK certificates just certify a signing key 13:35.000 --> 13:37.000 and then everything would just work. 13:37.000 --> 13:38.000 And this is history 13:38.000 --> 13:41.000 because the trusted computing group 13:41.000 --> 13:45.000 got badly burned by a backlash against TPMs, 13:45.000 --> 13:48.000 led by none other than the Free Software Foundation, 13:48.000 --> 13:50.000 who called it treacherous computing, 13:50.000 --> 13:52.000 designed to track you, designed to do everything else. 13:52.000 --> 13:56.000 And they got criticized the TPM as an agent 13:56.000 --> 13:59.000 in your PC acting on behalf of another party. 13:59.000 --> 14:02.000 And they claimed that all of these certificates 14:02.000 --> 14:05.000 could be used to track you because if it's just a sign 14:05.000 --> 14:07.000 certificate certifies a signing key, 14:07.000 --> 14:10.000 the signing key is used certify all operations of the TPM. 14:11.000 --> 14:13.000 All anybody who's tracking you has to do 14:13.000 --> 14:15.000 is look at what he was used to sign 14:15.000 --> 14:18.000 whatever attestation I wanted out of this laptop 14:18.000 --> 14:21.000 and that uniquely identifies the laptop and the person. 14:21.000 --> 14:23.000 So to counter this, 14:23.000 --> 14:25.000 because of what the FSF has said, 14:25.000 --> 14:28.000 the TCG tried to introduce privacy-preserving features 14:28.000 --> 14:32.000 and TPM to O that would prevent all of these nasty people 14:32.000 --> 14:34.000 in the world tracking you. 14:34.000 --> 14:37.000 And not allowing manufacturers to ship 14:37.000 --> 14:39.000 signing certificates was one of these measures. 14:39.000 --> 14:42.000 If you only ship an encryption certificate, 14:42.000 --> 14:44.000 there's no way that anybody can use that 14:44.000 --> 14:47.000 to certify anything else, they have to use other means. 14:47.000 --> 14:53.000 And then the TCG went on to elaborately come up with other means. 14:53.000 --> 14:57.000 The other means is that what you need to do in your TPM 14:57.000 --> 15:01.000 is create an ephemeral, what is called an attestation key. 15:01.000 --> 15:06.000 Then each attestation key can be sent to a privacy-CA, 15:06.000 --> 15:10.000 which is a party trusted by both you and the person 15:10.000 --> 15:14.000 who's relying on whatever certification you're doing. 15:14.000 --> 15:18.000 And the privacy-CA would then certify your attestation key. 15:18.000 --> 15:21.000 It would give you back a little certificate that says, 15:21.000 --> 15:24.000 either privacy-CA certify this attestation key 15:24.000 --> 15:26.000 belongs to a genuine TPM. 15:26.000 --> 15:29.000 And then the point is you can use this signing attestation key 15:29.000 --> 15:32.000 to do the certification of pretty much anything 15:32.000 --> 15:35.000 with TPM's supposed to be telling a relying party. 15:36.000 --> 15:38.000 You send along the attestation certificate, 15:38.000 --> 15:40.000 the relying party looks at it and says, 15:40.000 --> 15:43.000 okay, I trust the privacy-CA, this must be a genuine TPM, 15:43.000 --> 15:44.000 I believe you. 15:44.000 --> 15:47.000 And the point about privacy-preserving is, 15:47.000 --> 15:49.000 these attestation keys are ephemeral. 15:49.000 --> 15:51.000 I can generate as many of them as I want. 15:51.000 --> 15:54.000 I could generate one per transaction if I really wanted to. 15:54.000 --> 15:57.000 So if I certify a couple of different things to the same CA, 15:57.000 --> 16:00.000 it doesn't necessarily know I'm even the same laptop doing it. 16:00.000 --> 16:03.000 That was supposed to be their solution. 16:04.000 --> 16:11.000 And the, oh, let's skip the mechanisms, 16:11.000 --> 16:13.000 because I'm running out of time. 16:13.000 --> 16:16.000 There are several problems, so I was going to explain how it all works, 16:16.000 --> 16:18.000 but you don't really need to know that. 16:18.000 --> 16:20.000 The explanation I gave is sufficient. 16:20.000 --> 16:24.000 First problem, although the privacy-CA is an ice idea, 16:24.000 --> 16:28.000 none exists in nature today, so they can't be used physically. 16:28.000 --> 16:31.000 We have no means of actually doing. 16:31.000 --> 16:35.000 It means we have currently, if you look at anything that uses a TPM as a relying party, 16:35.000 --> 16:38.000 is it acts as its own privacy-CA. 16:38.000 --> 16:41.000 So that's just basically bust the veil of secrecy, 16:41.000 --> 16:46.000 because anything you attest to and rely on also certifies the attestation keys. 16:46.000 --> 16:48.000 It still does this attestation key thing, 16:48.000 --> 16:52.000 but because the relying party and the privacy-CA are exactly the same body, 16:52.000 --> 16:55.000 it always knows who you are and how many keys you've generated. 16:55.000 --> 16:58.000 This is a bit of an oopsie, but it's because, 16:58.000 --> 17:03.000 for us, no actual independent privacy-CA has ever been set up, 17:03.000 --> 17:08.000 and the TPM needs these attestation keys for certifications. 17:08.000 --> 17:11.000 Even if privacy-CA is did exist, 17:11.000 --> 17:14.000 early boot can't use them, 17:14.000 --> 17:17.000 because they exist on the internet, and we can't talk to the internet. 17:17.000 --> 17:22.000 Oopsie, because most of the TPM problems are then to pose as a currently boot. 17:22.000 --> 17:24.000 Oh dear. 17:24.000 --> 17:28.000 Early boot also can't validate E.K. certificates, 17:28.000 --> 17:32.000 because E.K. certificates don't have a central certificate authority. 17:32.000 --> 17:38.000 Every manufacturer has a self-scient certificate that certifies their own E.K. 17:38.000 --> 17:41.000 And, I mean, this is somewhat not true, 17:41.000 --> 17:45.000 because there aren't an infinite number of TPM manufacturers in the world. 17:45.000 --> 17:47.000 There are only about a handful. 17:47.000 --> 17:49.000 I believe there are less than 10. 17:49.000 --> 17:53.000 It's not impossible to embed less than 10 certificates into the kernel, 17:53.000 --> 17:57.000 but it does mean that if another manufacturer arises in an old kernel, 17:57.000 --> 18:01.000 it just wouldn't work, because we'd embedded the wrong set of certificates. 18:01.000 --> 18:03.000 So, although we could theoretically use this, 18:03.000 --> 18:06.000 it's just a dangerous thing to do. 18:06.000 --> 18:09.000 And the other problem is that a lot of you in the room 18:09.000 --> 18:11.000 will have firmware TPMs, 18:11.000 --> 18:14.000 firmware TPMs don't come shipped with E.K. certificates anyway, 18:14.000 --> 18:16.000 so you can't use this. 18:16.000 --> 18:18.000 So, given all the issues, 18:18.000 --> 18:22.000 we needed a new scheme to come to actually make TPM's work 18:22.000 --> 18:23.000 securely with the kernel. 18:23.000 --> 18:26.000 It's not enough just to secure the transactions, 18:26.000 --> 18:28.000 which is the patch I got up into 6.10. 18:28.000 --> 18:33.000 We also have to ensure that the key that I used to secure these transactions 18:33.000 --> 18:38.000 is actually trustworthy and hasn't been intercepted by an entrepreneur. 18:38.000 --> 18:42.000 So, the first thing I'd chose to do is to use the null primary session of solting. 18:42.000 --> 18:45.000 So, here's some more TPM trivia. 18:45.000 --> 18:48.000 The TPM has actually four separate hierarchies. 18:48.000 --> 18:53.000 The endorsement hierarchy, or let's start with the platform hierarchy, 18:53.000 --> 18:56.000 which is only accessible from BIOS, so you can forget about it. 18:56.000 --> 18:59.000 The endorsement hierarchy, which is where the endorsement key lives. 18:59.000 --> 19:02.000 This is the permanent identity hierarchy of the TPM. 19:02.000 --> 19:05.000 The owner hierarchy, which can theoretically change 19:05.000 --> 19:07.000 when you change the owner of your laptop. 19:07.000 --> 19:10.000 So, if you sold your laptop on, what you should do is 19:10.000 --> 19:13.000 wipe the owner hierarchy and it would generate a new key 19:13.000 --> 19:15.000 and owner keys would do that. 19:15.000 --> 19:18.000 And then the null hierarchy, which is normally not used. 19:18.000 --> 19:22.000 The reason it's normally not used is because the null seed changes on every boot. 19:22.000 --> 19:26.000 So, the master key of this hierarchy is different on every boot. 19:26.000 --> 19:29.000 And usually if you're storing keys in a TPM, 19:29.000 --> 19:33.000 they're all encrypted to the master key of the hierarchy under some algorithm. 19:33.000 --> 19:37.000 And that means that any key you're encrypted to the null hierarchy 19:37.000 --> 19:40.000 can only be used for the lifetime of the machine. 19:40.000 --> 19:43.000 Once the machine reboots, the null hierarchy seed changes, 19:44.000 --> 19:49.000 the key you derived can't be decoded anymore and it's shredded effectively. 19:49.000 --> 19:51.000 But this is actually a useful property. 19:51.000 --> 19:54.000 If you only want to key the last of the lifetime of the boot. 19:54.000 --> 19:58.000 That's why we use the null seed in secure, 19:58.000 --> 20:00.000 for securing transactions. 20:00.000 --> 20:05.000 And an even more interesting property is because it changes on every reset. 20:05.000 --> 20:08.000 The null hierarchy would be invalidated on a reset. 20:08.000 --> 20:13.000 That means if I'm using it to secure transactions encrypted to the TPM, 20:13.000 --> 20:17.000 and some interposables of reset, all of those transactions start failing 20:17.000 --> 20:21.000 because I'm communicating on the wrong key because the null seed has changed. 20:21.000 --> 20:29.000 This means we can actually detect whether we can detect a reset 20:29.000 --> 20:34.000 and we can also protect all transactions against the reset as well. 20:35.000 --> 20:38.000 You're shaking your head. What wasn't clear about that? 20:52.000 --> 20:58.000 So what I'm assuming is that I've somehow certified the null key in whatever way 20:58.000 --> 21:01.000 to make sure it's genuinely attached to the TPM. 21:01.000 --> 21:05.000 So the thing I'm trying to protect against is somebody pulls the reset line. 21:05.000 --> 21:09.000 I don't know about it, my PCRs in the real TPM or reset, 21:09.000 --> 21:12.000 and they rebuild the values to what they want. 21:12.000 --> 21:15.000 And the point about using the null seed, I've certified it, 21:15.000 --> 21:19.000 so I know it belongs to the TPM, but once that TPM is reset, 21:19.000 --> 21:23.000 it gets a different null key and I can send the communication to the TPM, 21:23.000 --> 21:25.000 but it won't understand it. 21:25.000 --> 21:28.000 So I will get an error back when I try and communicate on this null key. 21:28.000 --> 21:30.000 That's the point. 21:31.000 --> 21:34.000 So what we do is we save this null key once on boot, 21:34.000 --> 21:37.000 and then we use it for solving every session. 21:37.000 --> 21:41.000 Now, we still have the problem that the kernel can't certify this null key. 21:41.000 --> 21:44.000 But if there's ever a reset, we'll know it immediately, 21:44.000 --> 21:46.000 or at least not quite immediately. 21:46.000 --> 21:49.000 We know it the next time we communicate with the TPM. 21:49.000 --> 21:53.000 This is a somewhat of a problem because there is a gap between us, 21:53.000 --> 21:55.000 the kernel communicating with the TPM, 21:55.000 --> 21:58.000 and therefore finding out the TPM's been reset, 21:58.000 --> 22:01.000 and somebody in user space who isn't the security conscious, 22:01.000 --> 22:04.000 doesn't use the null seed and didn't notice. 22:04.000 --> 22:07.000 But once we detect a reset attack, 22:07.000 --> 22:09.000 we can immediately disable the TPM. 22:09.000 --> 22:13.000 And what we do for trying to certify the TPM is, 22:13.000 --> 22:16.000 we export the null primary name in a surface file. 22:16.000 --> 22:20.000 And so if you have a way of certifying TPM keys, 22:20.000 --> 22:23.000 you can certify this null key using that surface file. 22:23.000 --> 22:26.000 This is what the kernel tells you it's using, 22:26.000 --> 22:28.000 to impose a kernel defect this. 22:28.000 --> 22:32.000 You can actually genuinely certify that. 22:32.000 --> 22:34.000 Like I said, we export the name. 22:34.000 --> 22:36.000 The name is simply the hash and public key, 22:36.000 --> 22:40.000 so it gives a shortest, but unique ID for that public key. 22:40.000 --> 22:44.000 And we verify this by more sophisticated means after boot, 22:44.000 --> 22:48.000 meaning the kernel doesn't know it's safe when it booted. 22:48.000 --> 22:51.000 But if you verify the key after boot, 22:51.000 --> 22:53.000 and it verifies correctly, 22:53.000 --> 22:56.000 that the kernel was not intercepted or trapped. 22:56.000 --> 22:59.000 So every communication the kernel has done up to that point 22:59.000 --> 23:00.000 with secure. 23:00.000 --> 23:05.000 And you know this because you certify the key after the fact, 23:05.000 --> 23:11.000 but the certification was valid for when the kernel first started. 23:11.000 --> 23:16.000 Okay, so I developed a set of tools to try and make this easy, 23:16.000 --> 23:19.000 and what I'll actually do is try and demo that. 23:19.000 --> 23:23.000 So the main, it comes from something called the OpenSL TPM engine. 23:23.000 --> 23:26.000 These links in my presentation are actually clickable. 23:26.000 --> 23:30.000 It actually sits on get.kunnel.org if you want to actually download it. 23:30.000 --> 23:34.000 But the tool you need is a test TPM2 primary. 23:34.000 --> 23:38.000 What it can do is EK sign, which is export the name of the signing EK. 23:38.000 --> 23:41.000 This is what, so in order to do signatures, 23:41.000 --> 23:44.000 we're not going to bother with the privacy CA crap, 23:44.000 --> 23:47.000 because it's your laptop, you know who you are. 23:47.000 --> 23:51.000 You don't need to hide yourself from yourself. 23:51.000 --> 23:54.000 We don't need privacy CA, so we'll just use the signing EK, 23:54.000 --> 23:57.000 the thing that nobody was supposed to use for privacy reasons, 23:57.000 --> 24:02.000 because the person that certifying to in the end of the laptop of the same person. 24:02.000 --> 24:06.000 EK sign will derive the signing key and give you the name of it. 24:06.000 --> 24:12.000 A test is a command you can use easily to verify that EK signing key directly 24:12.000 --> 24:14.000 against the EK certificate. 24:14.000 --> 24:17.000 What it actually does under the covers, it takes quite a while, 24:17.000 --> 24:22.000 as it runs the full privacy CA protocol, verifies that that key is actually correct. 24:22.000 --> 24:26.000 Once it's given you the anticipation that the EK signing key is correct, 24:26.000 --> 24:29.000 you can actually then use that EK signing key forever, 24:29.000 --> 24:34.000 because that key is derived from the EK seed, which never changes in the TPM. 24:34.000 --> 24:39.000 And then there's a certify which allows you to use the signing EK that you've already deduced 24:39.000 --> 24:43.000 to certify any other key in the system. 24:43.000 --> 24:46.000 So let's see if we can actually do a demo. 24:46.000 --> 24:51.000 I have six minutes, this is going to be tight. 24:51.000 --> 24:54.000 Let's see. 24:54.000 --> 25:00.000 So I'm going to start a software TPM. 25:00.000 --> 25:02.000 There's a software TPM. 25:02.000 --> 25:04.000 I am going to start my intaposer. 25:04.000 --> 25:07.000 This is also available on get.com.org. 25:07.000 --> 25:10.000 All it's doing is actually sitting listening. 25:10.000 --> 25:14.000 I've got the TPM is communicating over the network. 25:14.000 --> 25:17.000 The intaposer is listening at one network port and 25:17.000 --> 25:20.000 snapping the transactions passing it to the other network port. 25:20.000 --> 25:24.000 And then the virtual machine startup file is told to connect to the intaposer port. 25:24.000 --> 25:29.000 So theoretically I know there's an intaposer there, but this is just the purpose of demonstration. 25:29.000 --> 25:32.000 Then I'm going to start a virtual machine. 25:32.000 --> 25:37.000 And this is actually a fully secure TPM. 25:37.000 --> 25:42.000 It's actually system D using the TPM. 25:42.000 --> 25:46.000 Actually, can I reduce the size of that a bit? 25:46.000 --> 25:48.000 So you can see it's booted up. 25:48.000 --> 25:50.000 Come on, I didn't hear. 25:50.000 --> 25:53.000 It gives me a console and I can log into it. 25:53.000 --> 26:06.000 So this is my system. 26:06.000 --> 26:09.000 I'm actually using system D scripts and roll. 26:09.000 --> 26:14.000 You notice that it didn't ask me for a password on bootup and that's because I've used the TPM key. 26:14.000 --> 26:19.000 So the intaposer itself actually is activated. 26:19.000 --> 26:22.000 It's been snooping. 26:22.000 --> 26:27.000 It hasn't activated. 26:27.000 --> 26:38.000 This is the problem of doing live demos, isn't it? 26:38.000 --> 26:39.000 Yes. 26:39.000 --> 26:41.000 I told it's contact the TPM directly. 26:41.000 --> 26:48.000 So now we'll boot and the intaposer will stand between us and the booting system. 26:49.000 --> 26:50.000 There it goes. 26:50.000 --> 26:54.000 So the intaposer is actually seeing all the TPM transactions here. 26:54.000 --> 26:55.000 It's not doing anything. 26:55.000 --> 26:57.000 It's just quietly watching them. 26:57.000 --> 27:06.000 The system still booted up still released the key. 27:06.000 --> 27:11.000 So I can log in. 27:11.000 --> 27:16.000 This software TPM has actually been programmed with a real TPM certificate. 27:16.000 --> 27:17.000 All TPM certificates. 27:17.000 --> 27:19.000 This is an RSS certificate. 27:19.000 --> 27:24.000 So it sits in this NV index zero one C, zero zero zero zero two. 27:24.000 --> 27:28.000 And I can just pull it out and I can show it to you. 27:28.000 --> 27:30.000 So this is what it looks like. 27:30.000 --> 27:33.000 The TPM I'm using is an IBM software TPM. 27:33.000 --> 27:40.000 So actually my TPM certificate is self sign by IBM because they provide a nice little service for doing this. 27:40.000 --> 27:45.000 But I would verify the certificate usually through the usual X509 means back to its route. 27:45.000 --> 27:48.000 To verify that this is a proper TPM. 27:48.000 --> 27:49.000 We'll see my done that. 27:49.000 --> 28:00.000 I can extract that TPM. 28:00.000 --> 28:02.000 To the EK certificate. 28:02.000 --> 28:07.000 This is actually reading all the bytes in the index and then just putting them in. 28:07.000 --> 28:13.000 I could actually if I read that back it's just a standard certificate. 28:13.000 --> 28:16.000 It says exactly the same one that it told me it was. 28:16.000 --> 28:18.000 And now I can use this to certify the key. 28:18.000 --> 28:23.000 So the first thing I do is I get the EK. 28:23.000 --> 28:28.000 And I'll put it into a little file called EKSign.name. 28:28.000 --> 28:34.000 So all that file is it's hash of the first four digits actually identify the hash. 28:34.000 --> 28:37.000 So HXB is actually shartif6 hash. 28:37.000 --> 28:42.000 And then this is a shartif6 hash of the EK signing key. 28:42.000 --> 28:50.000 And now I can use this to attest. 28:50.000 --> 28:59.000 So what I'm going to do is I'm going to attest TPM2 primary using the EKS certificate and the EKS signing name. 28:59.000 --> 29:06.000 And this should verify using the EKS certificate and that little privacy-ca thing that this is actually correct. 29:07.000 --> 29:11.000 You can see it took, there was a slight pause there. 29:11.000 --> 29:16.000 Even though I've got a software TPM which should be as fast as lightning. 29:16.000 --> 29:21.000 It does take a while to do all of the transactions that are acquired by the privacy-ca. 29:21.000 --> 29:29.000 But what this proves to me now is that the EKSigning name that I've got hold of is genuine and belongs to the TPM. 29:29.000 --> 29:32.000 I think it does that is certified by the certificate. 29:32.000 --> 29:37.000 I can identify the null name. 29:37.000 --> 29:46.000 And this tells me now that the system is booted correctly and I don't have an intaposa that's actually intercepted any of these transactions. 29:46.000 --> 29:53.000 So the TPM booted system booted securely without intaposa actually intercepting any of my transactions. 29:53.000 --> 30:01.000 The reason it didn't even know I do have an intaposa is because the intaposa is told cleverly do not intercept any of these transactions otherwise it will be detected. 30:01.000 --> 30:09.000 So the own transaction it can actually detect is system-descript and roll transactions. 30:09.000 --> 30:16.000 So out of time. 30:16.000 --> 30:24.000 Okay, so let's just do this quickly, sorry. 30:25.000 --> 30:29.000 Give the key for the passphrase. 30:29.000 --> 30:32.000 And I'll stop the demonstration here. 30:32.000 --> 30:38.000 That is system-desview of the private key that was stored in the TPM. 30:38.000 --> 30:40.000 And I've just extracted that. 30:40.000 --> 30:45.000 If you want proof of this, do I have time for you one more? 30:45.000 --> 30:51.000 Well, let's do it anyway, because it's fun. 30:51.000 --> 30:54.000 That's the key I just got from the TPM. 30:54.000 --> 30:58.000 This is, so that's where it tries to use this as a password for the TPM. 30:58.000 --> 31:01.000 And it says I've successfully unlocked key slot one. 31:01.000 --> 31:04.000 So I've correctly intercepted system-desviewed boot key. 31:04.000 --> 31:08.000 And with that, I'll say thank you very much and I have no time for question here. 31:08.000 --> 31:09.000 Thank you. 31:15.000 --> 31:17.000 Thank you.