WEBVTT 00:00.000 --> 00:09.680 Hey, hello everyone, thank you for coming to my talk, and today we're going to take 00:09.680 --> 00:13.840 about TPMs and the Linux kernel. 00:13.840 --> 00:22.280 Everyone here knows about TPMs, what are they, okay, yeah, yeah, by the way, my name is Ignat, 00:22.280 --> 00:29.960 I work for CloudFourer, anyone doesn't know CloudFourer, hey, good, so what is the TPM 00:30.520 --> 00:36.920 it's a security chip present a door more than laptops and servers, right, yeah, it's a nice 00:36.920 --> 00:42.600 passive device, it's not intrusive, so it's not like Intel management agents will 00:42.600 --> 00:48.040 which dig into your memory if you don't ask it to do anything it won't, but it is still like 00:48.040 --> 00:52.440 chip enough to put in every piece of hardware, but it's a foundation for platform integrity 00:52.440 --> 00:58.120 authentication and remote as a station, and as a security chip, it can handle cryptographic 00:58.120 --> 01:05.480 keys as security chips can do, so when you hear about TPMs and many talks, you might usually 01:05.480 --> 01:10.920 talk about like remote at a station, right, so, but this talk is not about remote at a station, 01:10.920 --> 01:18.600 it's about an application developers like who develops open source here, do you use TPMs to 01:18.600 --> 01:27.720 store your keys? Why? This partially was actually inspired by two years ago James 01:27.720 --> 01:32.840 Bottomly's talk, he introduced himself as like one of three people who works on TPMs, I think 01:32.840 --> 01:38.840 in the world, right, so yeah, platform integrity is an operating system concept like where 01:38.840 --> 01:45.880 application developers, what do we do? So this is my, sorry, this is my ideal mental model 01:45.880 --> 01:55.640 and there's an application developer how to use TPM, my call TPM use, right? Not that simple, 01:55.640 --> 01:59.880 right, like I run an operating system, so I cannot talk to hardware directly, so probably 01:59.880 --> 02:04.600 I need to do some obstruction more than a link to you, I need to talk to the slash that TPMs 02:04.600 --> 02:10.920 zero device, but it's not that simple, again, because TPMs are very low powered devices, 02:10.920 --> 02:17.400 they can't have concurrent access, so something needs to serialize from multiple applications, 02:17.400 --> 02:22.920 because everyone seems to want to use TPMs, so you need to have a thing called resource manager, 02:22.920 --> 02:28.600 which kind of tracks and allows different applications to not to confuse the TPM, 02:29.320 --> 02:34.600 and way to talk to the resource manager, you need some kind of obstruction layer TPM library, 02:35.480 --> 02:41.160 right, like an interface, so let's focus on the resource manager, traditionally the first 02:41.160 --> 02:46.040 iteration of resource manager was like a demon on the operating system, and it's kind of very 02:46.040 --> 02:51.960 confusing for application developers, right, so like I talk to device, which is definitely present, 02:51.960 --> 02:56.840 but if some service doesn't run, like I can talk to it, or is it crashed because it's written 02:56.840 --> 03:02.680 and see or something like that, which is now like the Linux kernel handles it better, so 03:03.080 --> 03:08.840 now kind of kernel has internal resource manager, so instead of talking to slash the FTPM, 03:08.840 --> 03:15.480 you talk to slash the FTPM RM, which stands for resource manager, and yeah it kind of, 03:15.480 --> 03:20.520 you kernel runs all the time and resource manager runs, if it crashes, your kernel crashes, 03:20.520 --> 03:28.600 so you would notice, we're good here, TPM libraries, well James can talk about it many times, 03:28.600 --> 03:33.160 so like there is like different variations of this, like if I'm an application developer, 03:33.160 --> 03:39.880 I have to take the libraries, you have internal trusted software stack, IBM trusted software stack, 03:39.880 --> 03:44.840 if you're doing on goal, you can use GoTPM, probably there is a rask rate flowing 03:44.840 --> 03:51.400 around somewhere I never researched it, but yeah, but the point here is like all these interfaces 03:51.400 --> 03:57.080 are different, so they're not standardized, so if you'd call your application against one librarian, 03:57.080 --> 04:01.720 you want to distribute it on a Linux distro, which doesn't have your trusted software stack, 04:01.720 --> 04:06.200 you kind of have to do either abstraction by on top of the abstraction layer or think of something else, 04:07.240 --> 04:11.480 so it's confusing, if you go to this website, you will find this picture, 04:13.160 --> 04:17.560 all this you have to understand to this one against TPM, right, which is, 04:20.600 --> 04:26.200 and this is kind of my theory why not a lot of like really open source projects have to 04:26.200 --> 04:31.800 keep in, but this is only part of the story, imagine I figured this all out and I write my code, 04:31.800 --> 04:38.040 right, so this is a bare bones, deb and installation, so like I start talking to the resource manager 04:38.040 --> 04:45.000 and I get permission denied even like I did all the interfaces, well like imagine I'm a go application, 04:45.000 --> 04:50.520 and this is because they both the TPM device and resource manager by default is owned by route only, 04:50.520 --> 04:57.080 right, so you need privileges, more confusingly if you do install something from the 04:57.080 --> 05:03.880 infiltrust versus software stack on deb, you will see that the permission's changed, you're like, 05:05.000 --> 05:10.680 now it's owned by the special TSS group and technically your application can become part of the 05:10.680 --> 05:17.240 TSS group and talk to the TPM, but if you're writing, go, should you still package dependency 05:17.320 --> 05:23.000 your deb and to install infiltrusted software stack just to get the proper permissions, well, 05:23.000 --> 05:34.120 no, right, but again, TPMs are complex devices, you can do many things, what we're focusing 05:34.120 --> 05:39.160 like, can I just get like cryptographic keys, right, for my use case, somehow? 05:40.200 --> 05:45.160 So, and this is where there is another interesting thing which is mentioned in different 05:45.240 --> 05:51.160 presentation Linux kernel key retention service, aka key rings or key store, actually I think 05:51.160 --> 05:57.240 did the presentation about it two years ago here, I don't remember, and the whole point of it is, 05:57.240 --> 06:02.360 you kind of have these multiple applications, you have the Linux kernel and you have three 06:02.360 --> 06:09.400 system calls which kind of allows applications to store keys inside the kernel and the original purpose 06:09.480 --> 06:15.640 was to kind of give keys to the kernel for using to internal crypto systems, like this 06:15.640 --> 06:21.800 encryption and file system encryption, but it was late like standard that you can kind of like 06:21.800 --> 06:27.960 also use these keys as objects, you can read them, you can use these keys to actually encrypt data, 06:28.840 --> 06:36.280 and informally it's very similar to key rings or, you know, key store has key rings, 06:36.280 --> 06:41.880 like collection of keys and key rings can contain keys, the actual objects that have 06:42.840 --> 06:48.840 cryptographic data, and as kernel objects they also have like proper access control and everything, 06:48.840 --> 06:53.800 and it's very very very similar to a file system where keys are files and key rings are 06:53.800 --> 07:01.080 directly, so you can build this like hierarchy very easy. So, for application there wouldn't be 07:01.080 --> 07:07.560 like somehow combine like TPMs and key stores, so like because key store is literally a set of 07:07.560 --> 07:13.800 system calls available to any unprivileged application, if we can like the key store can be this 07:13.800 --> 07:20.920 nice abstraction layer for the TPM keys, right, kernel kind of has that a little bit, so there is a 07:20.920 --> 07:29.160 concept of a trusted key and the whole idea that you don't allow user space to have plain text cryptographic 07:29.240 --> 07:35.720 material in the address space, so like imagine you have some secret or a key wrapped to the TPM 07:35.720 --> 07:44.200 of your machine, you can use a kernel key store API or Cisco to insert that blob into the kernel, 07:44.200 --> 07:50.440 and the kernel will automatically use your TPM to unwrap it, so in the kernel they object is plain 07:50.440 --> 07:57.240 text and you can actually use it for encrypting stuff, but if you try to read it back it will 07:57.400 --> 08:03.640 again wrap, so it's kind of like it's it's similar maybe to maybe a software HSM or something that 08:03.640 --> 08:08.120 you can only get plain text keys inside the kernel, like a more restricted environment. 08:10.440 --> 08:16.040 The restriction of this model is good for keys, but like we're from TPMs from time to time 08:16.040 --> 08:21.560 as we need also like secrets like credentials, like like what if I want my application needs 08:21.560 --> 08:28.520 like an access token to somewhere, right? So I cannot really use that because I can never 08:28.520 --> 08:33.640 for access token you need to kind of access to the plain text secret and you can never get it through 08:33.640 --> 08:40.840 the trusted key. Another problem like what we see in Cloud for Rostris keys is actually management 08:40.840 --> 08:47.640 of extra state, so how would you generate a wrapped key or trusted key, so you have random 08:47.640 --> 08:55.800 non-generator, get your key and you wrap it to your TPM, right? And now we're unlike thousands 08:55.800 --> 09:03.320 of services in production, yeah and what I wanted to say, the extra state is even though 09:04.440 --> 09:12.200 this kind of works this is a stateless system, so if you want your key to be preserved upon 09:12.200 --> 09:19.640 machine we start, you need to store it somewhere, right? But if you build like secure production 09:19.640 --> 09:24.680 system you sometimes want to have like a mutable infrastructure with only file system, 09:25.400 --> 09:31.880 your disk is break, you have to replace them, and the point of here is like, yeah your secrets are 09:31.880 --> 09:39.160 secure, but if you lose it and crypt it below, you lose your secret, right? Our S3 team wants 09:39.160 --> 09:48.040 in a while accidentally wipes a machine as well. Yeah, and another problem is with like scalability 09:48.040 --> 09:52.760 of this extra state, so you have like this works well for one application when you have like 09:53.720 --> 09:58.840 many many services and everyone wants their unique key, so you start in having this like extra 09:58.840 --> 10:03.080 state that you really need to care about, if you don't want to lose these keys you have to 10:03.080 --> 10:11.000 manage these bulbs somehow back to them up and others. So what if we do a different approach? 10:11.000 --> 10:16.840 What if we do a derived key? So TPM has this like secure seed inside which is guaranteed by 10:17.640 --> 10:24.040 the standard, right? And you can never extract it and it has a KDF implementation, yeah and it's 10:24.040 --> 10:29.960 all part of the standard, so every TPM has that. What if we just like provide some public 10:30.040 --> 10:37.640 I call it a mixing or application specific metadata, a unique identifier to that, to just generate 10:37.640 --> 10:43.080 an application specific key application unique key for that particular system. And it's now 10:43.080 --> 10:50.040 it's like perfectly scalable because like every service on your system can have their own keys, 10:50.040 --> 10:56.280 but this kind of state is totally disposable, right? Because the whole thing is full reproducible, 10:56.360 --> 11:00.760 it works in like immutable systems, you don't have to store it anywhere, you can just recover all 11:00.760 --> 11:07.080 your keys every bullet. And this kind of approach is submitted like I think more than a year of the 11:07.080 --> 11:14.840 first iteration of to do like the right keys in the Linux kernel, I received not very action number 11:14.840 --> 11:25.720 feedback. I did receive even though I would argue that I'm not actually inventing anything 11:25.880 --> 11:33.480 you here, so if you ever worked with any Tras Zone implementations, I are proprietary or OPTI, 11:33.480 --> 11:39.400 you have this concept of hardware unique key which kind of does exactly the same thing but for 11:39.400 --> 11:45.400 your trusted applications, right? It's just like I want to bring that concept up or level, so like 11:45.400 --> 11:52.440 I want to just bring that concept to any application that runs on the Linux system. And there is 11:52.440 --> 11:57.880 like a prison, so we kind of already use that approach, but in user space, like 10 years ago I 11:57.880 --> 12:05.400 developed this tool which we kind of like tested this approach in production and it's still being 12:05.400 --> 12:11.480 used for 10 years and it's very scalable in terms of managing secrets for a wide 12:13.320 --> 12:19.960 for a big infrastructure. If you're interested, I have a talk from 2017 on SR Recon, so 12:20.120 --> 12:24.600 it kind of brings you an interesting properties how you can quickly rotate keys across like 12:24.600 --> 12:30.840 a thousand of service with one configuration line change and you can target like either you can 12:30.840 --> 12:35.160 rotate your OLSSH keys, you can rotate all your disk encryption keys, you can rotate all your 12:35.160 --> 12:40.440 machine keys, so like you can have like any slicing and dicing granularity as you wish. 12:41.720 --> 12:48.680 But there was some also useful feedback, so I since then implemented the key derivation approach, 12:48.760 --> 12:56.520 I simplified it much, so I initially used TPM based Hmark from the seed, but I migrated it 12:56.520 --> 13:07.960 to a simple AS 256 counter, random number generator. James luckily he raised a question on my original 13:07.960 --> 13:15.640 patch set, like how do you protect confidentiality when the data transfers on the bus between the 13:15.720 --> 13:21.160 kernel and the TPM, but he since then fixed it by implementing encrypted sessions, so I 13:21.160 --> 13:26.920 added support there, so now the communication between the kernel and the TPM is encrypted as well, 13:27.720 --> 13:34.040 and now it kind of most of it is compiles as a module, so if you still don't like it, you don't 13:34.040 --> 13:41.480 need to enable it, you don't have it, or even like you want to compile it, but not law it, so it's 13:41.480 --> 13:48.760 worked fine, so the way how it works now, so you have a TPM, we use a special command create primary 13:48.760 --> 13:55.720 and create an IS counter key, and to create applications specifically, I have the create primary 13:55.720 --> 14:02.120 may accept an optional unique parameter, so like how to make this key unique for a particular 14:02.120 --> 14:09.320 purpose, and we use some like different kernel metadata identifiers for a particular process, 14:09.320 --> 14:14.840 which allows users to kind of slice and dice how unique that key should be, should be unique 14:14.840 --> 14:20.520 per application per user per user running the application, and you have implemented all these options, 14:20.520 --> 14:26.440 I will just show them, so there are basically all these data as user requests that is being 14:26.440 --> 14:34.760 hashed and provided as a unique value to the create primary, so TPM would create primary key for 14:34.840 --> 14:41.400 AS counter, and we just like extract the cipher stream as our secret for a particular application. 14:43.800 --> 14:51.240 So now I'll show you a demo, which is was copy pasted from a real terminal, but it never fails, 14:53.160 --> 14:59.480 because I tested it, so like here is a simple example, imagine this is my code, but I'm using 14:59.480 --> 15:06.120 the command line bash tool to just show how we call it, so we request to is a wrapper around 15:06.120 --> 15:13.080 request key system call on Linux for Linux course key store, so I'm requesting at the right key, 15:13.080 --> 15:20.760 and I'm saying like I want a key of size 32 bytes, and I want a key unique to my user ID, right, 15:20.760 --> 15:28.200 so, and then I can see the key, and now I'll show like the process is fully reproducible, so I delete 15:28.360 --> 15:34.680 the key now, and we request it again, and you can see like the blue numbers are serial numbers, 15:34.680 --> 15:39.160 it's a unique number of each key in the kernel key store, and you see there are different, 15:39.160 --> 15:44.200 so from a kernel perspective, there are different objects, so the key was destroyed and recreated, 15:44.200 --> 15:50.280 the different key, but the key bytes are the same, so this is how the process is fully reproducible, 15:50.280 --> 15:57.000 and basically any user, anything running as my user ID can recover that key on my system, and the key 15:57.000 --> 16:05.400 is specific to my user ID and specific to the system, right, yeah, and to show it works, 16:05.400 --> 16:10.920 if I run the same corner with pseudo, so I'm changing my user ID to root, root gets a different 16:10.920 --> 16:18.680 key, so technical I cannot steal a key from rule, and the other identifier I can use is a file 16:18.760 --> 16:27.960 system pass, so let's say my tool is located as slash user bin, I get one key, I move my tool 16:27.960 --> 16:34.600 to a different pass, and the same tool I run, I get a different key, and this is how you can bind 16:34.600 --> 16:42.360 your unique key to a particular file system pass, the original feedback that the pass are not really 16:42.360 --> 16:50.760 good at like for security, right, so you can trick those with user namespaces and other stuff, 16:51.480 --> 16:58.440 but based on the latest LPC, so like many other solutions are still preferring to give passes an option 16:58.440 --> 17:06.760 for different policies, because they're kind of like really well understood with users more than ever, 17:07.480 --> 17:14.680 and basically to protect, for example, from unprovedly user namespaces, you can combine user 17:14.680 --> 17:20.520 ID and pass, so user ID in this context means user ID in the initial user namespace, so even if you 17:20.520 --> 17:26.840 bind your key to pass, but somebody creates a unprovedly container and then creates a mount point to 17:26.840 --> 17:32.280 kind of circumvent that pass, they will still get a different key, because in this case, their 17:32.840 --> 17:42.840 user ID in the initial namespace would be like unprovedly, so you technically cannot steal the keys like that. 17:44.040 --> 17:50.840 If you are very concerned, still, and you find pass unreliable, I decided to add it like and 17:50.840 --> 17:56.440 let's say you're managing an immutable infrastructure or embedded device with a read-only file system, 17:56.520 --> 18:03.640 you can technically bind instead to a file system, you ID, and I know number, so in this case, 18:03.640 --> 18:08.680 your key is unique to a particular file system instance, right, no matter where it's mounted, 18:08.680 --> 18:19.640 and you can kind of like rely on that. One thing is also like another interesting option is 18:19.640 --> 18:25.880 application checksum, so what checksum means is the key is unique to a particular binary code 18:25.960 --> 18:31.800 that requested it, so like when you request key in this way, the hash of the key CTL itself will be 18:32.920 --> 18:39.160 hashed by the system or taken from iMASUPSystem, and it will be mixed into the unique key, so in this case, 18:40.120 --> 18:45.880 we can say if somebody accidentally patches your code, right, so I know key CTL has a string 18:45.880 --> 18:55.480 bad message, and I want key patch it to bad massage. If I rerun the comment, I will get a different 18:55.480 --> 19:00.920 key because even though I changed one byte in my requesting application, the key is not not available, 19:00.920 --> 19:06.600 so it's kind of you. It's not very convenient for if you keep updating your code, but like if you 19:06.600 --> 19:11.640 don't update, you feel you don't need to update your code, you can have a unique key specific 19:11.640 --> 19:19.480 to your application binary. James also pointed out that what if the application needs to rotate keys 19:20.760 --> 19:27.640 and you suspect it compromised, for example, so in this case I also added like a free form label 19:27.640 --> 19:33.480 parameter, and instead of applications instead of having one unique key, they can have a whole 19:33.480 --> 19:38.200 key space, right, and they can slice it disinternally, so for example, you can introduce 19:38.920 --> 19:44.920 a simple versioning scheme like label V1, if that key or secret was considered compromised, 19:44.920 --> 19:50.600 you can kind of reconfigure your infrastructure to generate a V2 key and you will have a different 19:50.600 --> 19:59.800 key for each application. The other like useful feedback was that all these mixing values are well 19:59.800 --> 20:07.320 known, so technically, yeah, I can do all the things, but like if I have direct access to TPM, 20:07.320 --> 20:13.480 I can use users by tools to craft the same commands and kind of steal those keys for a particular 20:13.480 --> 20:19.320 machine, like even like a privileged application. So this is where kind of I think still 20:20.120 --> 20:30.120 integrating it within the kernel will be useful because the trick I explored is the fact that 20:30.120 --> 20:35.800 even if you use encrypted sessions which you should, here is how the TPM create primary command 20:35.800 --> 20:43.240 look, so you have like a header and so-called handle area, you have a so-called sensitive area where 20:43.240 --> 20:49.400 if you use an encrypted session, both the request and response will be probably encrypted, 20:49.400 --> 20:54.600 and then you have the public area which is never encrypted, even though you use encrypted session. 20:55.480 --> 21:00.840 So yeah, this is encrypted and the nice thing about that the unique parameters that we use 21:00.840 --> 21:08.040 is in the public area. So we can actually separate within the kernel, 21:08.040 --> 21:13.640 to instead of just using shot to 506 of our mixing application identifiers directly, we can 21:13.640 --> 21:20.840 propend it with the kernel string, for example, or any arbitrary string, right? And then in the driver, 21:20.840 --> 21:27.080 we can look for the in the TPM driver itself which is responsible for passing commands from user space 21:27.160 --> 21:32.600 to the TPM, we can monitor for this command for this string. So for example, in my test 21:32.600 --> 21:39.720 implementation, here I'm using the user space tool to create primary and I'm sending ABC as a unique 21:39.720 --> 21:47.720 parameter so it works, but I can monitor if a unique parameter starts with the kernel, the driver can 21:47.720 --> 21:52.840 be modified to return permission denied. So you only allow the kernel itself to initiate the 21:52.840 --> 21:59.880 great primary command from the kernel space and not allow the user space to kind of seal those keys. 22:01.880 --> 22:09.480 So yeah, I wanted to actually submit the patch set before this talk, but just like the last week, 22:09.480 --> 22:17.240 I found I have a kind of vulnerability that I need to fix. It doesn't change the concept, but like 22:17.240 --> 22:23.480 some minor things that I need to fix before patches, but what else is missing for easy adoptions 22:23.480 --> 22:33.640 of TPM and Linux software, any other make sense, you would find useful, should we support 22:33.640 --> 22:39.000 better separation between generic secrets, the secrets that we are allowed to read as keybites 22:39.000 --> 22:44.440 and like actual cryptographic keys should we make the keys non-exportable, so you can only 22:44.440 --> 22:53.880 like use the keys, but not the C, see the plain text material. If we're using TPM, it would be nice, 22:53.880 --> 22:59.480 somehow to piggyback on the advanced TPM capabilities if I use this way to generate a key or a 22:59.480 --> 23:04.760 secret that I also have like a cryptographic pool which I can send to remote system that this key 23:04.760 --> 23:10.840 was generated by the TPM so I can build like easy provisioning systems for those keys. 23:11.480 --> 23:20.760 Yeah, but the current patch set in this tree, if you're interested and basically that's it, 23:21.800 --> 23:27.240 a little bit of shameless self-promotion, so cloud for a pledge to hire like 23:28.200 --> 23:34.920 1000, 100, 111 interns this year, so we have a big internship program if you're interested in 23:35.880 --> 23:41.000 and all the teams are looking for interns, so if you're interested in internship in any 23:41.880 --> 23:49.480 place in the software stack, so please reach out. Thank you very much, and I think so have time 23:49.480 --> 24:02.120 very close. Do you have any kind of TPM policy on the keys? Because you know, you like one 24:02.120 --> 24:05.480 and one of your last slides, you kind of suggest that you want to do the access control to the 24:05.480 --> 24:10.520 keys by doing the kernel, string pre-fixing and things like this, but that's software access control, 24:10.520 --> 24:14.360 right? Like a bit TPM and the policy language, and this is really important, right? Like because 24:14.360 --> 24:19.800 if I understand this correctly and I boot a kernel that I compile myself, right? Like I get access 24:19.800 --> 24:24.520 to all your keys because I can submit everything I want regardless of the kernel than itself 24:24.520 --> 24:29.560 blocks us to use this place. So what's your like, is there no TPM policy, hook up whatsoever, 24:29.560 --> 24:33.000 and you just have the keys completely accessible or what's the model there? 24:33.000 --> 24:38.440 I try to make it simpler. I think you're right, like TPM policy can be a non-trolantive 24:38.440 --> 24:44.600 thing to restrict, and you're totally right, I consider the case that like, yeah, we rely on the 24:44.600 --> 24:50.200 patch driver, right? And now if I just replace it with the custom kernel, I can still do whatever I want, 24:50.920 --> 24:55.960 but I think it's kind of different areas like, well, if you're concerned about that, you still need 24:56.040 --> 25:04.040 to have secure boot or basically some system integrity. So if you're really concerned about this 25:04.040 --> 25:09.000 case, like you should solve it with something else, right? You shouldn't allow just people to 25:09.000 --> 25:14.040 easily replace it. So just like in my view of the world, right? Like the, you always want to 25:14.040 --> 25:20.040 tie like a verified bootstuff to this, right? Like so that the keys that you have are only unmarkable 25:20.040 --> 25:24.040 on the systems, you actually think they're, they're stressful. That's, I mean, I was just 25:24.040 --> 25:28.680 surprised about the complete absence of TPM policy. Well, they're just more complicated to 25:28.680 --> 25:33.000 understand for users. I'm coming from an application perspective, but maybe you're right, maybe 25:33.000 --> 25:40.600 we should have both options. So I, I just prefer to give more, not have a policy in the kernel, 25:40.600 --> 25:46.760 what is right or wrong, but like give more choices to user, and they can like select what they want. 25:46.760 --> 25:52.920 Yes. So, um, it's a little bit early maybe, but do you have any plans in the future to integrate 25:53.000 --> 25:57.960 these with higher level cryptographic software, like open it's a sale or new TLS? 25:59.240 --> 26:05.400 Well, it could be. Yeah. So like, I know open SSL. I think had a provider to use a kernel key store. 26:05.400 --> 26:11.800 So I don't see why not. Like, here is a question. Yeah. 26:15.000 --> 26:21.560 Hi. Yeah. So again, I think this is in that secure boot chain. What I have seen is that, 26:22.200 --> 26:29.080 usually in the boot loader or somewhere that you use this TPM as a firmware, a talk that the 26:29.080 --> 26:34.920 the boot loader talk to the firmware, and then says that whether it is a secure boot or not, 26:34.920 --> 26:40.840 but when you boot into the Linux kernel system, it generally some verification with some 26:40.840 --> 26:46.680 SSL or some checks or something, right? So do you think that during the boot process or something, 26:46.760 --> 26:52.120 this this could be used, this library could be used as a part of some standard demand, 26:52.120 --> 26:56.520 some system, people will see or something? I think like Lennon, this is better, right? 26:57.320 --> 27:02.120 But I can today transfer this question once you have actually nice ideas about that. 27:03.000 --> 27:06.520 Okay. He didn't pay attention and we're out of time and for thank you.