WEBVTT 00:00.000 --> 00:22.680 In an increasingly connected world, workloads may run in any number of environments and locations. 00:22.680 --> 00:32.640 It's necessitates moving the trust boundary out of the data center, out to the edge where 00:32.640 --> 00:39.160 data is being produced and processed. 00:39.160 --> 00:46.040 If we consider networks which is, for instance, deployed across the University campus or 00:46.040 --> 00:56.440 servers within an office or workstations at a retail location, even with in these areas 00:56.440 --> 01:06.960 with sort of physical, limited physical access controls, remote attestation gives us assurance 01:06.960 --> 01:12.920 as to the state of those systems. 01:12.920 --> 01:22.840 So key lime is an open source project which does TPM based at a station and verification. 01:22.840 --> 01:36.360 It has built-in support for UEFI measured boot and Linux IMA file integrity. 01:36.360 --> 01:45.000 And IMA basically sort of reports on the state of files, measures files. 01:45.000 --> 01:51.640 So if somebody boots one of our devices for me USB drive, for instance, an appropriately configured 01:51.640 --> 01:55.880 key lime policy could detect that. 01:55.880 --> 02:03.960 But there is a bit of a problem here because in the current key lime architecture, the protocol 02:03.960 --> 02:12.360 is driven by the server or by the verifier. 02:12.360 --> 02:20.160 What this means is that in these scenarios which we just talked about, that's probably 02:20.160 --> 02:26.160 not going to work because those communications are going to get blocked at the firewall because 02:26.240 --> 02:34.040 you would need to open ports so that the key lime verifier can reach out to a, you know, 02:34.040 --> 02:39.280 attested node and attain obtain the attestation from that node. 02:39.280 --> 02:48.280 So over the last year, the key lime community has undertaken a project to enable attestations 02:48.280 --> 02:55.840 to be pushed from the various nodes on the network instead. 02:55.840 --> 03:03.360 So we've also used this opportunity to sort of modernize the key lime protocols, improve 03:03.360 --> 03:12.680 the security and lay the groundwork for future capabilities. 03:12.680 --> 03:15.920 Before we get into the details, my name is John. 03:15.920 --> 03:22.480 I work for Hulate Packard Labs as a security researcher in the office of the CTO. 03:22.520 --> 03:29.280 I have a master's in information security and procrastination from the University of 03:29.280 --> 03:39.280 Surrey and since last year, I've been working as a contributor on the key lime project 03:39.280 --> 03:46.000 to unlock the features that we're going to talk about today. 03:46.000 --> 03:52.880 So key lime consists essentially of four rough components. 03:52.880 --> 04:04.000 You have first the registrar and the registrar receives a set of identities for a system 04:04.000 --> 04:06.880 that you're trying to attest. 04:06.880 --> 04:19.200 And yes, of course, yeah, I see it, let's try it out. 04:19.200 --> 04:29.640 You want to just know where, okay, you know, I'm glad I can, I see things appreciate it. 04:29.640 --> 04:37.200 Hold it, yeah, I can do that. 04:37.200 --> 04:49.800 Where was I, so, all right, so, you know, I'm not shown on this diagram, the key lime 04:49.800 --> 04:57.840 agent here, but, you know, those identities are being sent by the agent on startup. 04:57.840 --> 05:06.000 And so, we have the endorsement key, which is sort of resonant within the TPM, an additional 05:06.000 --> 05:14.000 attestation key, and, you know, optionally, that might include a device ID as well, which 05:14.000 --> 05:18.040 will talk about in a bit. 05:18.040 --> 05:24.440 The sort of third component here is the key lime verifier. 05:24.440 --> 05:31.240 And the key lime verifiers, main job is to, you know, actually verify the evidence. 05:31.240 --> 05:36.720 But the verifier needs to get access, because these components are separate, right, they're 05:36.720 --> 05:40.280 totally different web services that you deploy. 05:40.280 --> 05:45.200 So you need to get the attestation key to the verifier. 05:45.200 --> 05:53.120 And so, the user does this sort of, as a provisioning step, where they basically invoke 05:53.120 --> 06:00.120 or they query the register or database, you know, 40 identities fetch the AK from there, 06:00.120 --> 06:06.760 and then the user can also provide their policies and reference measurements and, you 06:06.760 --> 06:08.880 know, provide them to the verifier. 06:08.880 --> 06:14.800 And there's this tenant CLI tool, which you can use to do that as well, you don't have 06:14.800 --> 06:20.960 to use the rest APIs directly, but that's how that works. 06:20.960 --> 06:28.800 And then, you know, once that AK is in, those APIs as none of the APIs are both secured 06:28.800 --> 06:41.640 by NTLS with a certificate, you know, that's issued to the, you know, requesting party. 06:41.640 --> 06:48.440 And then once you have that in place, you can now sort of receive evidence from your 06:48.440 --> 06:52.120 helium agents in the push model. 06:52.120 --> 06:59.840 And this includes your TPM quote, your UFI, and I'm a logs. 06:59.840 --> 07:03.400 So we're going to take a look at individual pieces here. 07:03.400 --> 07:09.520 First we're going to start with the sort of register side on the left there. 07:09.520 --> 07:18.400 So if you look at the sort of bits that we're adding to, in the push model, the, 07:18.720 --> 07:24.960 I forgot to mention, sorry, this, you know, push that to station API, we're securing it 07:24.960 --> 07:32.560 with this sort of proof of possession, which is sort of a new authentication protocol, 07:32.560 --> 07:37.440 which I'm going to talk about in a bit, and that's based on the AK. 07:37.440 --> 07:44.520 But if we, if we focus first here on the, on the register side, we're adding this new web 07:44.520 --> 07:45.840 hook mechanism. 07:45.840 --> 07:52.840 So if we take a look at that, effectively, what we're trying to accomplish here is when 07:52.840 --> 07:59.520 when the verifier submits sort of these identities, I'm sorry, we, we, we create them. 07:59.520 --> 08:03.320 When the agents submits these identities to the register are, the register needs to make 08:03.320 --> 08:10.440 a determination as to whether those identities are, you know, to be trusted or not, whether 08:10.480 --> 08:17.560 they're coming from sort of a legitimate expected node. 08:17.560 --> 08:25.000 And, but like, if you, if you're familiar with the AK certificate, FETPM, you know, typically 08:25.000 --> 08:29.600 has this endorsement key, and there's a, a certificate that is issued by the TPM in the 08:29.600 --> 08:33.720 factor with that sort of endorsement key in the certificate, right? 08:33.720 --> 08:40.280 So you may think that that might be sufficient, you know, to, to authenticate the by-sets 08:40.280 --> 08:41.560 registering. 08:41.560 --> 08:50.480 But in fact, if you look at the TPM spec, it contains this statement here, which says that 08:50.480 --> 08:56.600 the TPM reporting state of the platform by quoting the PCR values. 08:56.600 --> 09:03.200 For assurance that these PCR values accurately reflect that state, it is necessary to establish 09:03.200 --> 09:09.800 the binding between the RTR that's a root of trust for reporting and the platform. 09:09.800 --> 09:18.080 So in other words, you need to establish a binding between your TPM and the platform, the 09:18.080 --> 09:26.640 system, you know, in which that TPM is a part of. 09:26.640 --> 09:29.520 So why do you need to do that? 09:30.480 --> 09:35.920 Well, if you look, if you consider this scenario where you're over the register on a verifier 09:35.920 --> 09:41.520 and we have this note on the right, but they were trying to attest the state of, you know, 09:41.520 --> 09:48.880 in this example, we have an attacker here that has, you know, basically compromise that note 09:48.880 --> 09:57.360 in some way, maybe for instance, they're exploiting the black loaders vulnerability to sort 09:57.440 --> 10:07.040 of install, which is for bypassing your boot and install a UEFI, what's the word? 10:07.040 --> 10:14.080 A boot kit, sorry, and, you know, but because we're doing sort of remote attestation, we expect 10:14.080 --> 10:18.080 to be able to detect that scenario, right? 10:18.080 --> 10:24.480 But if our adversary sort of also has control of the network, when that note goes and sort 10:25.120 --> 10:31.600 of sends that message to register its identities with the register, the adversary can just block 10:31.600 --> 10:37.040 that request, right, going through. And then if you have another note and this could be a note, 10:37.040 --> 10:41.520 you know, the gym and node, that's part of your network, or the adversary could, you know, 10:43.200 --> 10:48.560 might have control over this note as to know that they've constructed, but they're leaving 10:48.640 --> 10:58.480 it sort of the state sort of in a known, good state intentionally. And the registration request 10:58.480 --> 11:04.080 for that note goes through just fine, it reaches the register. But on the way there, the adversary 11:04.080 --> 11:10.880 changes the message so that instead of, you know, saying, oh, hi, I'm, I'm node two, you know, 11:10.880 --> 11:17.920 it's claiming that actually this is a message coming from node one. And so, you know, the 11:18.000 --> 11:26.080 registrar will accept that because that EK is an EK that is coming from a legitimate or a genuine 11:26.080 --> 11:33.120 TPM device. So it's going to match against the manufacturer cert just fine. And our sort of 11:33.120 --> 11:37.920 challenge response here where we do this make credential, actually credential process, that's also going 11:37.920 --> 11:44.960 to, you know, proceed as normal without issues. So when the, the user then goes to sort of in 11:44.960 --> 11:52.080 roll this node or it goes to the going to roll node one here for verification with the 11:52.080 --> 11:59.200 verifier, they're going to query the registrar and they're going to get EK2 back, right? And so now 11:59.200 --> 12:08.240 you have this scenario in which the verifier has associated the identity of node one. And importantly, 12:08.320 --> 12:15.840 the policies and reference measurements for node one with actually the attestation key or the 12:15.840 --> 12:24.640 EK4 node two, right? So the mismatch here between what policy is being applied and, and the policy 12:24.640 --> 12:31.360 that we intend to apply apply. So when we're thinking of attestation security as a kind of security 12:31.440 --> 12:42.000 property, you need to, you know, we make the statement that we say that the sort of verification 12:42.000 --> 12:49.200 outcome that is reported by the verifier needs to match the sort of expected verification outcome 12:49.200 --> 12:54.800 for that node. And if you don't do that, that's a vulnerability in your protocol. And the 12:54.800 --> 13:00.720 inverse of that is also true because depending on how you're using this attestation, you know, 13:00.720 --> 13:06.560 that can, you know, if somebody forces an attestation to fail, that could cause the denial of 13:06.560 --> 13:12.560 service, uh, service scenario, consider if you are, uh, you know, provisioning identities with 13:12.560 --> 13:20.640 something like spiffier spire. Um, so there already exists an option in QLum today for sort of 13:20.640 --> 13:26.880 solving this problem. Um, and this is because QLum supports, uh, what are known as dev IDs, 13:27.840 --> 13:34.640 and dev ID is really just an X509 certificate that's issued to a specific device. 13:35.760 --> 13:39.360 And if you issue that certificate at the time of manufacture of that device, 13:39.360 --> 13:46.720 we call it an ID of ID or initial dev ID. There's also this other identity here called the IAK, 13:48.000 --> 13:54.480 very similar concept. It's, again, a certificate, uh, which, you know, is issued for the device. 13:55.440 --> 14:00.960 And the, the corresponding keys for those certificates are both generated by and stored in the 14:00.960 --> 14:14.800 TPL. Um, so what this means is that you have a certificate identity, uh, which is issued by the 14:14.880 --> 14:24.880 device manufacturer, um, with keys that are stored, um, only resident within the TPL, um, and that 14:24.880 --> 14:30.800 certificate identity is, is, you know, typically has a serial number of the device in it, right? 14:32.000 --> 14:37.760 Um, so you can basically identify a particular, uh, server, for example, on your network, 14:38.640 --> 14:46.480 and say, I want to apply this policy to this server, and you can have a assurance that you're actually 14:46.480 --> 14:56.320 applying the policy to the right, uh, node. Um, so, but we're introducing a new, uh, you know, option 14:56.320 --> 15:02.400 here for people, um, if you don't have dev IDs or, or maybe you want to augment, uh, dev IDs, uh, 15:02.400 --> 15:10.720 in this way, um, and so in this sort of new new approach, uh, you have, um, you know, registrar, 15:11.280 --> 15:18.640 uh, basically can, you know, optionally reach out to an external service, uh, to help in this sort of decision 15:18.640 --> 15:25.680 process. So here you have the agents submitting its identities across, um, you have the registrar 15:25.760 --> 15:32.400 comparing those against your, uh, trust store as per usual, um, and it's reaching sort of an initial, 15:33.200 --> 15:39.680 uh, trust decision there. Um, but now, um, it can submit that decision along with all the 15:39.680 --> 15:45.760 identities that's discovered from the agent, uh, to this external service, and that service may, uh, 15:45.760 --> 15:54.000 queries, some type of inventory system, or maybe it reaches out to, uh, your CSPs, uh, rest APIs, 15:54.320 --> 15:59.600 because maybe you're, you're running this workload, um, in the cloud, and, and you don't, 15:59.600 --> 16:07.600 and you actually have a VTPM, and you don't actually have a, um, EK cert, uh, for this particular 16:07.600 --> 16:15.840 node, uh, so you need to verify the, the identity, uh, in some other way, um, and then that service can 16:15.840 --> 16:22.880 reply, uh, either override the decision that the registrar, uh, reached, uh, originally, or it can just 16:22.960 --> 16:27.840 provide additional information that it's discovered. For example, here I'm having it sort of providing an 16:27.840 --> 16:35.360 additional, uh, C.A. cert, um, and the registrar will reevaluate that and, and come to a final decision. 16:37.200 --> 16:44.480 Um, so that was the identity decisions web hook. Um, now we're going to take a look here on the 16:44.480 --> 16:49.920 right on the verifier side. And we're first going to take a look at this, uh, proof of possession, 16:50.240 --> 17:00.800 authentication, protocol. So in key lime today, messages from the agent, um, are authenticated 17:00.800 --> 17:07.440 by a TLS certificate, which is sort of generated by the agent, um, and then it sort of enrolls 17:07.440 --> 17:16.480 that certificate with the verifier via, you know, a particular, uh, uh, uh, you know, protocol. 17:17.200 --> 17:24.480 Um, and so the, and so that's the fundamental way at which your rest APIs are sort of protected 17:24.480 --> 17:30.720 by, from sort of unauthorized access by just sort of anyone on the network, right? Um, where 17:30.720 --> 17:36.640 sort of replacing that in the push, uh, protocol with this proof of possession, uh, mechanism. 17:36.640 --> 17:44.400 So the way that this works is that the, uh, agent, uh, or sorry, there's actually two phases here 17:44.480 --> 17:49.920 that I'm going to talk about. There's a capabilities, no good inflation phase first. And in that phase, 17:49.920 --> 17:57.360 we have the, the agent that is supplying a list of its sort of supported, uh, sort of capabilities, 17:58.720 --> 18:04.320 um, here we're just doing sort of, you know, basic, uh, you know, TPM sort of attestation. So it's been 18:04.320 --> 18:11.840 quite listed, uh, algorithms at the TPM supports, um, and the verifier replies with, um, sort of, a token 18:11.840 --> 18:18.160 that it issues, um, you sort of like a session token, basically, similar to a bearer token in, in a 18:18.160 --> 18:25.600 loft, uh, world, if you're familiar with that concept, um, and it also provides the nons, and it picks 18:25.600 --> 18:31.200 one of the, the algorithms that are, uh, you know, that the, the agent says it has available to use, um, 18:34.800 --> 18:40.400 and then the, we have the second phase here. And the first part of this phase is that this, 18:41.280 --> 18:47.040 agent is going to perform a TPM to certify. Um, we're doing something slightly interesting here, 18:47.040 --> 18:56.080 or something, unconventional, in which we are certifying the key, the AK with itself, if that makes sense. 18:56.080 --> 19:03.520 So we're signing, uh, the TPM object, which is the AK, and we're using the AK to actually perform 19:03.520 --> 19:09.360 that signing operation, um, because we don't really care about so much about what we're signing, 19:09.440 --> 19:14.640 as long as it includes or not. So we're going to include our nons, you know, qualifying data, um, 19:14.640 --> 19:22.880 and, you know, and that gives us, you know, the sort of proof that we need that this, uh, uh, 19:23.680 --> 19:30.720 you know, that we're talking to this agent, uh, or the agent with this TPM, really. Um, and so the, 19:30.720 --> 19:35.920 the agent replies with that sort of sort of occasion, which, uh, the verifier is going to, you know, 19:36.000 --> 19:41.920 check against the AK check against the nons, um, and then, you know, the verifier applies, 19:41.920 --> 19:47.520 uh, with a message saying that, okay, this token is actually now, uh, valid, uh, is now active. 19:48.720 --> 19:57.200 And then we can use that token in sort of subsequent requests. Um, moving along to, now, you know, 19:57.200 --> 20:02.560 the actual interesting portion, or what we're trying to get to here, and this is the, the sort of 20:02.640 --> 20:08.560 push out of station protocol. Um, so we have, again, the two two parties here, and again, 20:08.560 --> 20:13.520 very similar to the, the authentication protocol. We just talked about it. It sort of happens in these two 20:13.520 --> 20:19.920 phases. Um, and again, you know, you submit here, you know, in your first request. Now, you're token 20:19.920 --> 20:25.600 that you've got from your authentication protocol, um, and again, a list of supported algorithms, 20:26.320 --> 20:31.840 um, and other details about the device. Um, and then the verifier can use whatever logic it needs to 20:31.920 --> 20:37.840 determine, uh, you know, which of those capabilities, the, the agent should use to protect, 20:37.840 --> 20:44.080 excuse me, to prepare the evidence, um, and it's going to include, uh, a new nons there as well. Um, 20:47.120 --> 20:56.880 and so the agent can now sort of prepare, um, a quote, uh, using the, uh, those details, um, and it provides 20:56.960 --> 21:02.880 whatever, you know, logs it needs to, and again, it's authenticating that with our session token, 21:03.600 --> 21:10.240 which is just sent sort of in the authorization, uh, header of an HTTP request. Um, and then so 21:10.240 --> 21:16.160 so you're, you're verifier then just sort of replies with an okay response, provided that all these, 21:16.160 --> 21:22.160 sort of bits of data look correct. They sort of validate against sort of surface level, um, 21:22.560 --> 21:28.880 you know, validation tracks. Um, and then the verifier actually after this protocol is complete, 21:28.880 --> 21:35.360 if goes off and actually goes and verifies the evidence that's been provided, um, against our policies 21:35.360 --> 21:47.280 and against our reference measurements, uh, for that device. So, I want to give you all sort of an idea 21:47.920 --> 21:55.200 of what this, these APIs, uh, you know, look like how, what it's like to work with them. Um, um, 21:55.200 --> 22:02.880 and what we've really tried to do here is be kind of forward thinking in how we specify these, 22:02.880 --> 22:08.240 so that, you know, maybe in the future, you know, K-line has other capabilities, maybe we're doing 22:09.280 --> 22:14.080 at a station that is not TPM based, maybe we're doing other forms of TPM, at a station 22:14.160 --> 22:19.920 we're providing different kinds of evidence. So we have, you know, this is the request that you've sent 22:19.920 --> 22:27.040 in, um, when you're sort of creating that, uh, when you're doing that capabilities and negotiation, 22:28.000 --> 22:33.280 first, so this is sort of message one there on this diagram here. Um, so you're saying, okay, 22:33.280 --> 22:40.560 I want to sort of create a new attestation resource on the server, um, and this is the evidence 22:40.640 --> 22:48.560 that I, as the agent, um, support, um, you know, I can give you a TPM code if you want it, um, 22:49.280 --> 22:56.880 and that TPM is running version two, um, and of the other TPM spec, um, and, you know, these are all 22:56.880 --> 23:02.480 hash algorithms, I support these are all signature schemes I support, um, and here are all the keys I have, 23:02.480 --> 23:07.440 you know, knowledge of as the agent, and, you know, in K-line today, of course, it only sort of 23:07.440 --> 23:12.080 contemplates this attestation key, so you're only going to have that one attestation key, uh, 23:12.080 --> 23:18.800 there typically, um, but in the future, maybe you have other keys, maybe you have, um, a, a, a, a 23:18.800 --> 23:25.920 v-sac, for instance, uh, for talking about confidential computing. Um, and if you scroll down here, 23:25.920 --> 23:32.240 we can see, okay, you know, the, you can also sort of specify, okay, I have access to a measured 23:32.320 --> 23:40.240 boot log, I have access to, to I'ma entries. So, this gives us sort of flexibility to expand, 23:41.120 --> 23:50.720 uh, keyline capabilities in the future, um, you know, for various other uses. Um, the last thing I 23:50.720 --> 23:59.520 want to sort of point out here, um, is that in the, the poll model, um, you know, there's less concern 23:59.680 --> 24:07.040 about the verifier, or sorry, about an agent sort of behaving, uh, sort of, you know, misbehaving, 24:07.040 --> 24:12.480 really. Um, but when agents can sort of submit attestation, sort of, of their own deletion, you 24:12.480 --> 24:18.400 have to do sort of additional things here. So, some of the things that we do do sort of, uh, prevent 24:18.400 --> 24:25.360 misuse of these APIs is that we sort of allow the user to configure an interval between which, 24:25.760 --> 24:31.520 quotes are expected to be received. Um, and that's enforced by the verifier, um, 24:33.120 --> 24:38.720 and we also enforce that only one attestation is ever processed for a given agent at any one time. 24:38.720 --> 24:45.200 And then finally, we also have a configurable verification time out. Um, so if a single 24:45.200 --> 24:51.680 attestation is occupying the verifier for too long, um, you know, we can reject that request. 24:52.320 --> 24:59.040 Um, so this is the current status of all of this work. Um, we have one PR that's been merged 24:59.040 --> 25:03.200 which was sort of just a kind of, kind of, kind of, kind of offended, or exceedingly, a foundational 25:03.200 --> 25:10.640 refactor of the existing sort of web code base. Um, and we have sort of three PRs that are sort of, 25:11.520 --> 25:17.280 um, in various stages of maturity. Um, I think they're all currently marked as graphed, I think 25:17.360 --> 25:22.560 that's been a change, a very suit in the very near future, uh, particularly the one that 25:22.560 --> 25:29.920 implements the push at the station protocol. Um, I think that one's reaching, uh, maturity, um, 25:29.920 --> 25:36.240 and, and then the, the pop, uh, authentication protocol will probably follow, uh, shortly thereafter. 25:36.240 --> 25:43.520 Uh, these are all service exchanges so far. Um, we have Anderson and, uh, some folks that 25:43.600 --> 25:48.640 read had that are helping us, you know, come, yeah, that's over the finish line with the sort of 25:48.640 --> 25:54.960 agent side of this. Um, so, so that, that can be expected in the, in the, in the near future, hopefully, 25:54.960 --> 26:00.480 as well. Um, and then, you know, there's this other PR, where sort of extending the docs to 26:00.480 --> 26:05.440 explain sort of the adversarial model or the threat model that we were considering when we designed 26:05.440 --> 26:11.440 uh, these protocols. Uh, so thanks for, uh, listening to me, listening to me ramble, uh, 26:12.080 --> 26:15.680 for half an hour, um, does anyone have any questions? 26:24.240 --> 26:25.360 Yes. 26:25.440 --> 26:43.680 You mentioned that if you use a divine D, you, uh, right, of course, yeah, I've 26:43.680 --> 26:48.560 greeted the question, I'm so sorry. Uh, so the question is that, um, in this scenario in which 26:48.640 --> 26:55.280 you have these two, uh, nodes and you're sort of, you know, you have an adversary that's sort of mixing 26:55.280 --> 26:59.040 up the, the, the, the, the, the, the, the, the, the, the, the attestations or the, or the messages that 26:59.040 --> 27:04.240 are coming from these two nodes. How does a device ID or a dev ID prevent that from occurring? 27:04.240 --> 27:10.160 So the idea here is that instead of using some arbitrary identifier for your node, like, 27:10.160 --> 27:17.200 node one or some random UUID or whatever or a hostname, um, you know, you're, you're, you're, you're 27:17.200 --> 27:20.400 you're using the device as serial number as the identifier. 27:20.400 --> 27:24.000 So you're saying, OK, I know I have this device. 27:24.000 --> 27:25.640 With this serial number, why do I know that? 27:25.640 --> 27:28.800 And I know that because I have an inventory database 27:28.800 --> 27:31.520 of all my systems. 27:31.520 --> 27:36.040 And I want this particular policy to apply to this serial number. 27:36.040 --> 27:38.920 And you have that enforcement from the, 27:38.920 --> 27:41.120 because you trust the device manufacturer 27:41.120 --> 27:46.400 who has issued the certificate, which contains that serial number. 27:46.400 --> 27:47.640 Yeah, does that make sense? 27:55.040 --> 27:56.840 Well, I mean, if, I mean, 27:56.840 --> 28:00.000 anyone can issue a certificate, right? 28:00.000 --> 28:02.600 But you have, it's going to be dependent on what 28:02.600 --> 28:04.320 sort of the ASR to you trust, right? 28:04.320 --> 28:08.800 So it's signed by the manufacturer of cert. 28:08.800 --> 28:10.160 So you're going to add the manufacturer of cert 28:10.160 --> 28:11.280 to your trust store. 28:11.280 --> 28:14.200 And then only that manufacturer can issue those 28:14.200 --> 28:15.640 the ID certificates. 28:15.640 --> 28:16.640 Yeah? 28:16.640 --> 28:19.640 I don't know if the certificate is to your interest. 28:19.640 --> 28:22.200 So that would be when you should get back to cert 28:22.200 --> 28:27.640 versus what they change in the identity piece of the node. 28:27.640 --> 28:30.280 That there would be a free sum security protocol 28:30.280 --> 28:34.440 in place here, actually, because the practical authentication 28:34.440 --> 28:37.880 of the, in this case, of the ID by the, 28:37.880 --> 28:42.200 because otherwise, your choice, replacing the identity 28:42.200 --> 28:45.480 by a new, the identity find a certificate, 28:45.480 --> 28:47.240 which I can again copy from somewhere else, 28:47.240 --> 28:50.280 which I actually found to be from somewhere to please. 28:50.280 --> 28:51.280 Yeah. 28:51.280 --> 28:54.840 So sorry, I didn't get into the details of how that works. 28:54.840 --> 28:57.800 But yes, there is a check that happens. 28:57.800 --> 29:02.120 So you basically prove possession of the, 29:02.120 --> 29:03.000 the, the, the, the, the, the, the, the, 29:03.000 --> 29:06.040 effectively, when you do that registration. 29:06.040 --> 29:11.880 So you use, you prove that the AK is linked to the, 29:12.120 --> 29:16.600 dev ID, basically, during the registration process. 29:17.880 --> 29:20.360 So I think that's all all my time. 29:20.360 --> 29:23.560 If anyone has any further questions, yeah, I'll be around. 29:23.560 --> 29:25.720 So.