WEBVTT 00:00.000 --> 00:11.600 All right, good morning and welcome to the second edition of the E-match based Linux and 00:11.600 --> 00:17.360 boot integrity devroom. On the first edition, we were down in the basement, the underground 00:17.360 --> 00:21.160 and now we've been promoted up and we're in a window which is great, yes, you cannot hear me 00:21.160 --> 00:26.640 that is fine. There's no speakers, this is for the livestream, but thank you, this is just 00:26.720 --> 00:32.240 for the livestream. Now we're not important enough to have speakers or other microphones, 00:32.240 --> 00:36.800 so if you have questions, please raise your hand, we welcome questions and discussions, 00:36.800 --> 00:40.960 but then I'm going to have the speakers and to please repeat the question or the comment 00:40.960 --> 00:45.840 before answering because we want people on the livestream or watching the recording to hear 00:45.840 --> 00:50.000 the question. Otherwise, it looks like the speaker is talking to himself like a crazy person. 00:50.880 --> 00:55.520 A bit of logistics and then we will start, so all the talks of the same format, 00:55.520 --> 01:01.040 speakers have 20 minutes for content, plus 5 minutes for Q&A at the end, so speakers like 01:01.040 --> 01:06.080 12 questions during the talks, my clarinet, so please do that if they allow it, and then we 01:06.080 --> 01:11.360 have a 5 minutes buffer at the end for spillover and for changing the speaker. If you need to leave 01:11.360 --> 01:16.000 the room or reinvent it, please it's possible wait for this 5 minutes buffer at the end because 01:16.000 --> 01:21.120 it's a small room, sits on noisy, doesn't noisy, it stops the procedure, if 20 people start 01:21.200 --> 01:24.880 leaving the room or the talk, so we'll defame here for the end, please leave it at the time, 01:24.880 --> 01:32.400 it's possible. Then on top of that, we have a great set of talks today, we have an even greater set 01:32.400 --> 01:37.280 of speakers, and none of them are controversial tech billionaires, you know, it's not a given, 01:37.280 --> 01:44.320 these days are for them, so I think that's good. And finally, we are also organizing not just these 01:44.320 --> 01:49.840 devil, but another conference, all systems go, is going to happen in Berlin on the 31st of September 01:49.840 --> 01:55.600 and 1st of October, we are going to open the CFP in a month already looking for sponsors, 01:55.600 --> 01:59.520 though, so if you work for a company in the sitting on a big pile of cash and don't know what to do 01:59.520 --> 02:04.800 with it, please go on the office and go website, and this sponsors link is open. And with that, 02:04.800 --> 02:10.160 let me introduce the first speaker, my colleague Leonard, and he's going to tell us everything you 02:10.240 --> 02:13.840 are wanting to know, and then some about the PMs. Thank you, let's work on Leonard. 02:20.880 --> 02:28.080 Okay, can you? Yeah, this thing seems to work. I don't know a lot of slides, I have no 02:28.080 --> 02:33.440 reasons, I'm not going to be able to go through all of them, because it's just too much stuff. 02:33.440 --> 02:38.960 Also, it's going to be fairly technical, I really hope that at least some of you have a basic understanding 02:38.960 --> 02:47.200 of what a TPM is. I did this in one talk, in past years, it passed conferences, so I kind of hope 02:47.200 --> 02:53.200 that one of the other already has a rough idea what we actually do with TPMs in system development. 02:53.200 --> 02:59.280 But yeah, to live in this, what are actually the goals with a TPM work that I personally and 02:59.280 --> 03:06.160 others have been doing in the system, like the big goal that I have is that we catch up with 03:06.160 --> 03:12.560 other OSIS, because right now, it's like all the big OSIS that are not classic learning 03:12.560 --> 03:17.760 system, you tend to have some form of TPM hookup that just works. And if it's not TPM, 03:17.760 --> 03:22.560 and at least some other kind of security and cliff, a thing that works like a TPM. So if you look 03:22.560 --> 03:28.000 at Android, if you look at Windows, if you look at all these things, they all have this. So for me, 03:28.000 --> 03:32.560 it's kind of the pointing that we don't have the same level of support on generic learning 03:32.560 --> 03:40.960 distributions. My goal is that we can, in particular, default to measured boot. So yeah, 03:40.960 --> 03:45.360 to catch it up in that regard, and not just have secondary but also measured boot. 03:46.560 --> 03:52.240 So that we can body fault like Windows does it with a bit locker, do this encryption lock 03:52.240 --> 03:58.800 to TPM, so it's not just about that, but also about service credentials so that we can do more 03:58.880 --> 04:05.680 than just a description of locked to TPM, and actually pass secrets or how we call them 04:05.680 --> 04:11.680 a little bit more generically. So it's credentials to services in a relatively secure way and can 04:11.680 --> 04:19.680 authenticate them and equip them in a way that locked to TPM. That we have a method to do second 04:19.680 --> 04:24.400 parameterization of the boot, because there's always this problem that if you have a further 04:24.400 --> 04:30.080 locked down boot, that typically means that you run stuff that is signed or you lock 04:30.080 --> 04:33.920 your description to stuff that is what you think it should be, but that makes parameterization 04:33.920 --> 04:38.400 a little bit harder, because it basically parameters are usually something locals, something, 04:38.400 --> 04:44.400 but not the vendors controls, but the local and the local user controls. So doing the 04:44.400 --> 04:49.040 securely in a way that everything's authenticated and they crypt it if needed, it's not trivial. 04:49.920 --> 04:53.920 One of it goes also to make confidential computing a thing, like confidential computing 04:55.840 --> 05:01.600 you need to basically make sure that any input to your system is in some way authenticated 05:02.880 --> 05:08.880 and encrypted and TPM's play, or at least TPM like things, play at major role in that. 05:10.240 --> 05:17.040 And then also provided PIS that others can start making use of TPM and a more reasonable way. 05:17.760 --> 05:24.480 I mean, TPM stacks have existed for a long time, but the problem is that if you actually 05:24.480 --> 05:31.360 want to write a application that uses TPM and has a sensible policy that locks to the system state, 05:32.160 --> 05:38.400 that's very hard for the simple reason, but there are no big-time measurements or traditionally 05:38.400 --> 05:44.560 the wind. So, and the definite goal of all of this is to make the TPM stuff something that can be 05:44.640 --> 05:50.880 turned on by default on generic Linux. The same way, when it's just TPM, TPM is available, 05:50.880 --> 05:55.440 we should do the same, because right now none of the distributions generally do that. 05:58.080 --> 06:04.080 This, the work on that has been progressing quite substantially, so these are a bunch of 06:04.080 --> 06:07.280 the components of the system that already have been hooked up. 06:07.280 --> 06:14.960 Yes, the given explanation, brief of what all these is, clips and up is like the thing that 06:15.760 --> 06:20.240 unlocks a disk and can do this against the TPM, crypt and roll is the other side that you enroll, 06:20.240 --> 06:26.640 but you can encrypt a disk against TPM. PCR extends about the measurements so that we can 06:28.080 --> 06:34.320 measure the boot status, so that the TPM has an idea how far has a system progressed booting. 06:34.560 --> 06:39.760 I guess it still has a left in it already and things like that. It's kind of relevant so that you can 06:39.760 --> 06:43.040 bind secrets to these systems states. So, for example, that you can say, 06:43.040 --> 06:50.160 if you can build from a secret shell, it'll be accessible to the OS during early boot, during the 06:50.160 --> 06:54.960 inner-ready phase, but not later, so that anyone who can explore its system later has no chance 06:54.960 --> 07:03.840 to actually get access to the disk encryption volume key, at least not from the TPM directly. 07:04.560 --> 07:10.480 PCR machines and PCRFS are kind of like they're actually just a multi-culting for PCRFase, 07:10.480 --> 07:17.200 they measure identity of the system in a way, so that you can write policies that are generic, 07:17.200 --> 07:22.880 but also unlock only and specific systems. PCR machine measures the at-see machine ID, 07:23.440 --> 07:27.600 and system PCRFS, and measures the UID of the filesystems that you booted from. 07:28.400 --> 07:33.360 This is when you stop is this UFI stuff that runs during, like from UFI, 07:33.360 --> 07:37.440 like before the kernel initialized, it does the measurements of the kernel itself. 07:37.440 --> 07:41.840 It's like, I didn't have another talk about UKI's, it's kind of related to that. 07:42.400 --> 07:46.960 This is an imagine or something that can predict the measurements that are going to happen 07:46.960 --> 07:52.240 if you build a certain kernel up at UKI, but it here. UKI files this little Python tool that allows 07:52.240 --> 07:58.400 us to build UKI's, so they glue together a kernel inner-ready and so on, and then do invoke system 07:58.400 --> 08:01.840 the measure to get the measurements and then get that kind of blah, blah, blah. 08:01.840 --> 08:06.640 This is a BPCR lock, it's a major component of all of this, more recent addition, 08:06.640 --> 08:15.600 it's about management of PCRFase policies for TPM that cover all the stuff that is inherently 08:15.600 --> 08:22.720 local to the system, right? Like because if you want to bind disk encryption to TPMs, 08:23.600 --> 08:30.000 what do you actually do is like, like parts of it, the measurements cover stuff that the 08:30.000 --> 08:33.440 YSVANA controls, right? You have deviant distribution, you have a door distribution, 08:34.000 --> 08:37.360 but then there's all the other stuff that covers stuff that is inherently local to a system, 08:37.360 --> 08:41.680 right? Like that the YSVANA cannot predict, right? Like because you have a different graphics card, 08:41.760 --> 08:46.080 different CPU, different firmware version, and so on. So actually the parts of the vena controls 08:46.080 --> 08:51.040 are actually small, but it's really nice, really predictable, that's where systemy measure is about, 08:51.040 --> 08:55.840 and then all the massive other stuff, which is really chaotic because there are so many different 08:55.840 --> 09:00.240 stakeholders, right? Like there are firmware developers and Intel is always in there and there's 09:01.840 --> 09:06.800 so a system piece of Alex of us to help you manage that. Systemy required is this thing, 09:06.800 --> 09:11.680 I mean it's a dynamic repetition, but one of the nice things it does is that on first build you can 09:11.680 --> 09:17.440 create petitions for you and actually lock them to TPM, so it cannot just grow in petitions, 09:17.440 --> 09:22.480 but you can also set them up and do that in really smart and cryptographic enhanced way if you 09:22.480 --> 09:26.960 so well. Since it requires this, like this too, I mentioned this earlier about system credentials, 09:26.960 --> 09:32.720 how we can securely monitor our services and systems, in a way that is locked to TPM. 09:33.600 --> 09:37.840 Import credentials kind of the other side, it's systemy credit tools that you generalize these, 09:37.840 --> 09:42.720 encrypted authenticated credentials, things and import credentials, it's like how you then 09:42.720 --> 09:48.320 consume them in a service, so it's very easy for for systemy services to just have secrets, 09:48.320 --> 09:52.080 like, I don't know, key material, but also configuration that is locked to TPM. 09:52.880 --> 09:57.360 Systemy as B sign is a recent addition to systemy, it's just a second good signing, 09:58.000 --> 10:05.200 does pretty much the same thing that the PE sign do or SP sign do? Well, I don't have much time left. 10:07.200 --> 10:11.840 Systemy key you does, yeah, also something, let's not go into that. One of the point is, 10:11.840 --> 10:16.080 it goes to the hypothesis that we put more focus on magic, we're not seconded, you know, 10:16.080 --> 10:19.920 seconded is the thing where everybody signs their stuff with ultimately some key that is 10:19.920 --> 10:24.480 controlled by Microsoft. Imagine if it is these other things where you just let do everything 10:25.120 --> 10:29.680 and then however you bind your description to that over this kind of software has one. 10:30.400 --> 10:34.240 I find there's a lot more democratic, right? Like because it doesn't make any restrictions 10:34.240 --> 10:38.160 about your boot, it just says, yeah, if you do not boot what I chose earlier when I 10:38.160 --> 10:43.120 encrypt in my disk, you will not get access to the disk. So it makes, like it should actually 10:43.120 --> 10:48.800 something that opensource people should really love because it's democratic, it's free, 10:48.800 --> 10:54.240 it makes no restriction on controlling anything prohibiting anything, all the, all 10:54.240 --> 10:58.160 it says is that, yeah, this doesn't need to be in this specific state where the disk could be 10:58.160 --> 11:02.960 accessible. And that's a good thing. And for this model, like a tofu model, like instead of having 11:02.960 --> 11:07.040 the central database of certificates where everything's side, it does it the other way around, 11:07.040 --> 11:10.400 basically, yeah, when you install your system, you lock everything down at that moment, 11:10.400 --> 11:14.000 you trust your system and from that point on, you know, it's going to only be unlockable of 11:14.000 --> 11:20.320 system still in relatively similar state. So to me, yeah, I mentioned it was way more interesting. 11:20.400 --> 11:25.120 Secondly, it's kind of add on, you can also do this reasons to do this, but I find 11:25.120 --> 11:29.440 measured through just like, yeah, it's, it's a lot more focused because it actually allows you to 11:29.440 --> 11:35.040 control what you want instead of what some big organization, big distribution, it wants to do, 11:35.040 --> 11:40.640 and it's, it's more democratic. This is my taken things, look at for example, love, 11:40.640 --> 11:47.920 second, yeah. So, I can actually, in the last five minutes, to really interesting stuff, 11:48.000 --> 11:51.840 something that we recently added is actually that we can combine the system, EPCR lock. I 11:51.840 --> 11:56.800 mentioned earlier, already, it's like a thing for managing all the local things of the system, 11:56.800 --> 12:00.400 like the local measurements that are specific to the local device, and combine the 12:00.400 --> 12:04.560 same PCR policies, which are these policies that cover all the measurements of the last window 12:06.080 --> 12:10.320 controls. It was really hard to combine these two things, but to me, this was always a holy grail, 12:10.320 --> 12:15.760 because the basically means yes, the last one that can lock down things, that the last 12:15.760 --> 12:19.520 window controls, and you can lock down the stuff that your local system is, and then you can 12:19.520 --> 12:24.160 combine them both and have a security policy where you basically can say, yeah, my laptop can only be 12:25.600 --> 12:30.720 unlocked if the system is still in that state where I installed it plus anything from federal 12:30.720 --> 12:39.600 runs on it. This is actually impossible to implement on TPMs, because the policy language that 12:39.600 --> 12:44.800 TPMs support then allows us, I talked to a lot of TPM people and nobody could come up with an 12:44.800 --> 12:51.360 ized version. Ultimately, the way I found this by sharding, so basically, we have a risk of encryption 12:51.360 --> 12:55.760 that's done with a large key, and one half is protected by the PCR lock stuff, and the other stuff 12:55.760 --> 13:00.720 is protected by the CIS, CIS, CIS policies, so the TPM doesn't actually know that there are two policies 13:00.720 --> 13:06.640 involved. It's a nice hack. I think it delivers pretty nicely what we want. It's not as good as if 13:06.640 --> 13:13.280 the TPM would support this natively, because yeah, these things can be authenticated out of 13:13.280 --> 13:17.600 some, basically, and would be better if the TPM could do the same thing, but it's still 13:17.600 --> 13:22.560 kind of nice. There's very tough not to crack to figure out how this works. But I'm kind of happy with 13:22.560 --> 13:27.120 this. Other things that we've recently added to TPM2 to target, it's like this, we finally 13:27.120 --> 13:31.840 have a synchronization point. One, the TPMs actually have shown up during good, because we are 13:31.840 --> 13:38.160 like, normally on my laptop, for example, TPMs are just there, what was that? TPMs are just there, 13:38.160 --> 13:42.880 right, because they are discreet hardware that is probably doing all the boot, and it's just 13:42.880 --> 13:48.080 there. But the thing is, in real life, it's not always that way, like a political and arm, 13:49.360 --> 13:55.200 TPM is kind of planet and wire software, thingies and enclaves, and the needs to first 13:55.200 --> 14:00.720 run some software in user space, so that the TPM devices can actually show up, and it's because 14:00.720 --> 14:06.000 they don't have storage, and then this OS component needs to provide storage to the 14:06.320 --> 14:11.200 enclave. So long story short, this actually, yeah, doing other boot attacks a while until 14:11.200 --> 14:16.240 TPM shows up. And now the reasons why TPMs show up right, because I don't know, the drivers 14:16.240 --> 14:20.800 that compile those modules are loaded only on demand, because generic distribution tends to 14:20.800 --> 14:25.840 want to support a lot of systems and not just one. So this was actually kind of weird, like 14:25.840 --> 14:30.560 figuring out that, oh my god, we cannot assume that a TPM is there all the time, because that 14:30.560 --> 14:35.200 means doing all the boot TPMs are there, doing right boot at TPMs are there, but in the middle 14:35.520 --> 14:40.640 there isn't simply because, yeah, what the firmware found, and what user space found, 14:40.640 --> 14:45.200 and rather gap in the middle until we actually manage to set up things as the same way as the 14:45.200 --> 14:52.640 firmware already added. Yeah, one other thing, probably the last thing I'm going to talk about 14:52.640 --> 14:58.640 is, before we switch to questions, the system credentials are available on privilege, or service 14:58.640 --> 15:05.120 credentials. I mentioned what these credentials are, right? We extended this a little bit 15:05.120 --> 15:15.920 so that it's not only something that you can parameterize the whole system and system services 15:15.920 --> 15:20.240 was, but also user stuff. And it's actually quite nicely implemented, because it actually 15:22.160 --> 15:29.440 involves the user ID of the user and has to set it into the policy, like basically into the 15:29.440 --> 15:35.600 key that we actually use for the encryption authentication. So that basically means even though 15:35.600 --> 15:39.920 the concept of users and operating system concept, like the TPM has no concept of users or anything 15:39.920 --> 15:45.680 like this, you can nicely lock your system credentials to that and then also to the TPM. So yeah, 15:45.680 --> 15:51.280 the actual encryption authentication basically takes a key that is ultimately released by the TPM, 15:51.280 --> 15:57.520 but it also contains material from that we acquire from the current self in a secure way. 15:58.320 --> 16:03.440 And that basically means, yeah, if I walk in as user Lennon, I can ask the system to unlock the 16:03.440 --> 16:10.000 secrets for me, but any other user couldn't do the same thing. Yeah, that's kind of nice. 16:10.800 --> 16:14.720 There's so much other stuff that we recently had. I'd like multi-profile you guys. I talked about 16:18.080 --> 16:24.000 all kind of small things. I make it really nice to work with this, so that you actually can 16:24.000 --> 16:29.200 build stuff much nicer. And it goes on and goes on and, like, confidential computing support, 16:29.200 --> 16:34.080 we now support natively in during food loading. We can measure which is something that is not 16:34.080 --> 16:40.320 TPM. We have this offline modes as distributions can actually build all that stuff in the build system 16:40.320 --> 16:46.080 and then have this signature logic in some other system that is very much secured and then you 16:46.080 --> 16:53.120 can get the signature back and then merge it again. Yeah, we have modeling IPC, IPC, IPI's nowadays, 16:54.880 --> 16:59.360 one of the last things is really hard actually to do right like the PCI works that, you know, 16:59.360 --> 17:02.640 we need a lot of meta information to implement these kind of policies and the meta information 17:02.640 --> 17:06.800 needs to be somewhere for the root file system, but we can't put it on root file system because 17:06.800 --> 17:11.120 it's supposed to unlock the root file system so we need to put it in the ESP, but then you also need 17:11.120 --> 17:17.280 to figure out how to authenticate that and things like that. Yeah, we figured out all of this out 17:17.280 --> 17:21.920 more. There's so much more, so much more, so much more. As I mentioned right in the beginning, 17:21.920 --> 17:26.880 we aren't going to call ourselves up. So let's talk about questions. 17:41.520 --> 17:46.880 So the question once regarding if I buy in five years or laptop and I want to transfer my data 17:46.880 --> 17:50.880 from the old one because the new one that is actually worked, you know, the TPM stuff is just 17:50.880 --> 17:55.520 one way to unlock your disk in the same way as the other operating systems usually give you 17:55.520 --> 18:00.240 a recovery key or something like this. We do too, right like you should not lock your disk exclusive 18:00.240 --> 18:08.160 to the TPM if you want to be able to get access to without the TPM. So TPM is one way to get it in 18:08.160 --> 18:14.480 the same way as photo keys, the pass keys are another way to get it the same way as your password 18:14.480 --> 18:20.000 might be another one and the recovery key. I would assume that in future the same way as photo 18:20.000 --> 18:25.440 other pushes you to using TPM by default and then combine it with a recovery key we would kind of do 18:25.440 --> 18:30.160 the same thing. And incessantly we added this for this the high level concept of a recovery key 18:30.880 --> 18:35.840 to disk encryption and it's actually the exact same thing as a password. The only difference is that 18:35.840 --> 18:40.960 we generated from the computer so it has high guaranteed high entropy instead of letting the user pick 18:40.960 --> 18:58.960 it which generally is usually not at that high entropy. Okay, my question. 19:00.000 --> 19:05.600 So the question was regarding what do we do with like for microcode and for my stuff I presume 19:05.680 --> 19:11.200 that I was doing early boot and the changes that have and how like the effect the PCR management 19:11.200 --> 19:14.880 and then the policies we generate. This is precisely the system you picture all across about. 19:14.880 --> 19:20.480 It's like this management tool to deal with this kind of stuff. So yes, firmware updates, 19:20.480 --> 19:27.360 microcode update, blah blah blah blah blah, this will all affect the PCRs. So what system do you 19:27.360 --> 19:32.720 picture all across the list to help you is that we have a clear way how in a good case is in the best 19:32.720 --> 19:37.840 cases we will know how the PCRs are going to be influenced. I mean we don't know right now 19:37.840 --> 19:43.760 generally because the state is simply not available from the firmware lens but my hope is that 19:43.760 --> 19:49.760 eventually after we update the carry some of this information related to the PCRs zero result. 19:49.760 --> 19:54.800 They kind of hope that these kind of information will soon or later be available for them. 19:54.800 --> 19:59.200 They would be the idea case but of course it's going to be at least initially the absolute exception. 19:59.280 --> 20:03.440 The common case will be we just have no. How are what we do know is that there's going to be a 20:03.440 --> 20:09.920 firmware update going to take place. So it comes out with all the infrastructure to actually 20:10.480 --> 20:15.920 relax the policies when in a firmware update is expected and then you reboot and then we'll 20:15.920 --> 20:19.920 need to lock it down. So this is kind of what one of those two except we do in much nicer because we 20:19.920 --> 20:26.480 can do it's more fine grain and we don't drop all the protections. We just drop the protections 20:26.480 --> 20:32.960 of the stuff where we just look at what the new measurements are and look against that. 20:37.200 --> 20:43.920 If you put it measured or secure and you have a con-laptate or something other that influences 20:43.920 --> 20:49.120 of the week how do you get the new measurement into your food chain, 20:49.120 --> 20:56.400 food ones whether we cover a key? No, like if you update like so the questions regarding what 20:56.400 --> 21:00.640 if you update a kernel or something like this how does that reflect in the PCR policies. 21:00.640 --> 21:06.960 So we don't do this like we don't have to that's a good thing because the other thing that I 21:06.960 --> 21:13.680 talked about like the sign PCR policies, this is about like kernels if they build the way we think 21:13.680 --> 21:23.840 like as UKI they can come with a signed gold measurement JSON thing built in right and this is 21:23.840 --> 21:29.520 signed and we can pass a signature to the TPM and then anything was with the public keep behind 21:29.520 --> 21:34.480 the signature will be accepted for unlocking the disk right so that basically means we never have 21:34.480 --> 21:40.720 to re-enroll as long as it changes to the PCR's are controlled by the Westlander because 21:40.720 --> 21:45.440 the Westlander really just predict what's the changed measurement is going to be sign of risk 21:45.440 --> 21:50.640 their own key and that's the signature key is going to be accepted by the TPM and hence we are good right 21:50.640 --> 21:55.600 so this is fundamental difference on how Windows does it because in Windows they don't have 21:55.600 --> 22:01.360 this support because they designed for TPM one or two instead of TPM two right and TPM two there's 22:01.360 --> 22:05.840 this concept of sign PCR policies and TPM one or two it wasn't so when those doesn't this case 22:05.840 --> 22:10.720 that turn off all the protections you boot and then lock again right so that basically we enroll 22:10.720 --> 22:15.920 we don't have to do this because we have the luxury of coming late and just being able to rely on 22:15.920 --> 22:20.960 TPM two so I'm sorry for the Windows people that they're kind of stuck with this city model 22:20.960 --> 22:27.200 so that's this also means the system will help us get the initial provisioning of the TPM 22:27.200 --> 22:33.200 often running because personally I still find TPM to not something I would like to order 22:33.200 --> 22:38.720 the reels they're deal with so the way we're getting TPM provisioning like setting up the 22:38.720 --> 22:45.920 original TPM on on first put like we all have to do this like as called TPM to set up or something 22:45.920 --> 22:52.320 it's like a service that we ship but once we're going to set up an S.R.K. like a storage 22:52.320 --> 22:59.040 would keep the thing that you have to do if there's none so I'm pretty sure we can polish this 22:59.040 --> 23:03.760 like a little bit more that we can I don't know give you nice ways to reset the TPM via Chrome 23:03.760 --> 23:07.760 come online think like that there are a couple of things to do this good about this but we're doing 23:07.760 --> 23:12.640 enough already to get this like make this invisible to users there was some 23:22.320 --> 23:32.560 design about this yeah yeah I'm I'm a war like the sort of the the what was said there 23:32.560 --> 23:37.200 is that the T.C.G group like the people behind TPM are preparing a spec regarding the gold 23:37.200 --> 23:43.600 measurements I'm a war of this but talking to some people from the TPM like from the T.C.G 23:45.200 --> 23:49.360 they are not entirely sure this is actually going to happen like in real life so 23:50.320 --> 23:54.960 you know I find out a way of a design we need something much simpler like for like the 23:54.960 --> 24:02.320 stuff that we need like it's so trivial that I don't know yeah I think when that appears it's 24:02.320 --> 24:07.680 going to be trivial to consumers too right that let's bet until actually appears otherwise 24:07.680 --> 24:09.680 there's no point in supporting it 24:09.680 --> 24:39.600 so yeah yeah so yeah yeah so I'm very good with he mentioned that like the T.C.G people are 24:39.600 --> 24:45.200 like some people try to get the firmware wonders to provide these gold measurements 24:45.200 --> 24:50.800 of the book and so far they're never succeeded and in particular he claimed that the PCR 24:50.800 --> 24:55.920 zero stuff that I mentioned was not actually provided by anybody to FW update the things 24:57.440 --> 25:03.120 so mine knowledge like they're talking to to which it used like the guy behind FW update the 25:03.120 --> 25:08.160 or L what's called LV anyway the the call the thing they said and one of the one that does 25:08.160 --> 25:09.680 the PCR is the one stuff 25:33.120 --> 25:43.760 yeah so yeah I'm not going to repeat that but they think what I'm I let we still 25:43.760 --> 25:48.400 say that yeah the I think the data that they have about PCR zero is it's kind of uninteresting 25:48.400 --> 25:53.360 ultimately it's not what I want because what they carry what the one field that they have 25:53.360 --> 25:59.200 covers the system state and then tells you the final PCR value what I want to know 25:59.200 --> 26:02.560 is the measurements that got into that value to be able to replicate that