 So I'm Pankaj Gupta, working as a principal engineer in an XP security technical group. I'm here to talk about the coupling of kernel keyring with Linux crypto framework and how this coupling will enhance the robustness of crypto operations performed by LCF. LCF is Linux crypto framework that I will be using in the slides going forward. This session will be divided in four sections, understanding the security requirement security, implementing implementation gaps in current Linux, brief about kernel keyring and kernel Linux crypto framework, and finally the coupling is between Linux crypto framework and keyring. During the session, I will brief you about security requirement and context of IoT device and IoT Edge, highlighting the implementation gaps, brief about kernel keyring and how this coupling will enhance the robustness of Linux crypto framework. By the end of this session, the attendees will be able to appreciate the motivation behind the proposed coupling. To better understand the special needs of IoT security, as compared to the need of IoT security with IoT, IoT security, not only IoT devices are not only connected to physical world, most of the time exposed to the hostile environment. Significant variety of IoT devices exist and because of that variety, there's a security requirement to get multitude. Real-time system requirements could not afford classic IT solutions of using antivirus. They are not always under the supervision of humans and security concerns in the IoT device and the data they generate needs best security practices. They have longer expected lifetime than IT assets and these security practices need to maintain throughout the complete device lifecycle. Security is now the industry top priority. IoT industry is committed to it and trying to bridge the gap lag behind the rate of digital transformation, the speed of securing the ecosystem. One such effort is by ARM, where ARM standardized the platform security architecture to address the shortcomings in IoT security. It holds great potential in unifying the entire IoT value chain into a singular holistic approach to security. It gained traction nowadays. So let's start with the basic principle of IoT device. There are three types of cryptographic keys that have been dealt here would be used throughout the device lifecycle, from device provisioning to end-of-life. With each of these keys, few additional key attributes are associated to restrict the usage of key to prevent wider security impact. For instance, like service keys. Keys used to encrypt the data collected by the IoT device from a particular service sensor communicate it over cloud to be stored in users database. IoT device only has to collect and encrypt the data as you can see in the right side. There is a key attributes mentioned so if the usage is encryption only, for instance, for one example, then there's a network keys that are used to encrypt the data to be shared using the network of IoT device to prevent the eavesdropping within the IoT network. For instance, IoT device shared data to the IoT hub not establishing the session created using the network key to prevent eavesdropping. Then there's third type of operation being performed that's device software integrity. Using the software validation keys. These keys are fused into the IoT devices some in some of the cases and only to allow the authenticate this will help us to allow running the authenticated software on the IoT device. By validating the image, for instance, validating the image signing certificate followed by image validating the image certificate before loading the image onto the device. So you can see in the right side each of these keys have tried to save the key attributes to it like the usage would be signed only or decrypted only in the software key. The network keys would be for encryption because the data from the IoT node to IoT hub will be encrypted data only. Then there is a service key where the service data will be encrypted and only be decrypted by the IoT service or the end user database. Let's got a little deep dive into the individual operations. Network inclusion. The security network keys being generated are the volatile key during the session of sharing the key sharing the data from the IoT device to the IoT hub. The type of the key attribute would be most suited would be encryption only to the IoT node and for the decryption only to the IoT hub because it is decrypting the data received from the IoT device. For instance, device configuration operations in which the remote enrollment and configurations being done, the typical keys or the key IDs will be fused in the fuses of the IoT device. Before sharing the diagnostic data of the device the device security state will be validated. Device software integrity for instance where we are validating the secure boot whether the security state must be checked before doing any crypto operations on this device. Before receiving the, getting the OT upgrades and validating the OT upgrades against the fused keys, using the fused keys runtime integrity checkers. There are many operations which IoT device do using the keys and the additional key attributes helps them to identify, to narrow down the crypto operation being done there. Secure channel connections, the TLS handshake where the persistence keys part of the certificate quality key part of the record layers being generated and used. Device authentication registration in the device authentication the fused in the public keys will be used for this purpose. The device life cycle state, the device life cycle state is closed then you can't refuse or you can't go ahead with certain operations. The role of cryptography in the IoT device is same for any cryptography is a confidence to maintain the confidentiality of authenticity, integrity and non-repedition. Keeping the secrets within the trusted entities from the IoT node till the IoT server. Verifying the entities for the source of data before providing the software, validated software to the valid IoT device. If ensuring the data transport preventing from the e-dropping safe software executions before validating the security state of the IoT device before executing the software. As identifying the device uniquely among the IoT network. These are the one of the cases where over productions can be curbed down having the unique device identification. IoT devices that is running on Linux uses Linux subsystems for one or the other cases. These kind of features like KTLS, IME, VMD, MQ these two inputs to two inputs, key buffer and plain text for the input data to Linux crypto frame. This with what I say as a loose coupling between subsystem and the crypto framework that impacts the robustness. To achieve these, to achieve the additional robustness need to map the keys on different areas depending on the lifetime and the sensitivity sensitivity of the operation. We have to map before doing the operation to accomplish that the additional key attributes being provided to the key so that when Linux crypto operation sorry, the Linux crypto framework performs any crypto operations, it also validate the sensitivity of the keys before doing any crypto operation. That's what I'm trying to put here. Let's take an example of TLS handshake for an IoT device. It's one of the typical example highlighting the key attributes in play. Session keys, lifetime is volatile. Teamaster keys are volatile. Device, private keys, persistent keys fuse in the fuse. Server public, a persistent keys fuse in the fuses of the device. Server public key or persistent keys fuse in the fuses of the device. Session keys are key usage and kept only for service data to the server when the client is sending data, it will be encrypt only to the server. And when this operation is performed by the IoT node and when it received at the server, it can be encrypted crypto. The key attributes can be both. Here I try to highlight the gap in the current implementation. LCF gets following two up. V buffer and key length and data to do any crypto up. This is the existing Linux crypto framework where when we provide a plain text or encrypted text along with the key we call as an output encrypted text or decrypted text. But the gap in current implementation is crypto operations are not constrained to the intended sensitivity level of the key. For instance, if we provide some key attributes along with the plain text or encrypted text, the output would be encrypted text or decrypted text or it could be none. So LCF may not give any output depending on the sensitivity of the key. If it is the sensitivity of the key, meet the criteria of crypto operation that output will come. For instance, let's take an example of key usage. If there is an encrypted text key and the key attribute which says encrypt only, then the output would be none because the text is encrypted only. If the data is plain text, then only the encrypted output will come. Similarly, if we have an encrypted, permitted algo as AACBC only, if the operation is asked for ECB, there will be no output. But if it will be CBC, the output will be there. So what I'm trying to achieve here is that Linux crypto framework, we need to add, we need to feed to Linux crypto framework the additional key attributes which constrained the Linux crypto framework, crypto operations to the sensitivity of key. Tunnel key ring is a Linux subsystem for key management. Various kernel components used to retain or cache their keys like trusted key authentication keys or encryption keys and other data using this. So I'm taking an example of trusted key ring here where we have a key payloads in that key ring. And what I am proposing here that this key payload we have, currently we have key buffer, sorry, we have key buffer and key block. I'm proposing to have another attribute, another member as a key attribute list which stores the key, additional key attributes like it can be, it's not limiting to these, it can be made more. But like key usage, key promoted elbow, key lifetime, key wrap EID, or key device date. Existing implementation, there is no way Linux subsystem like DM crypto, DM crypto can either fetch the key sensitive additional key attributes or send them to a Linux crypto framework. As you can see, in the existing framework, we can, DM crypto can propose the elbow name, the key buffer, key length, and the plain text to the Linux crypto framework. While what I'm proposing here, what we need is the key usage, the additional key attribute, which constrains the Linux crypto framework for doing any crypto operations. That is missing, currently. Next slide, I will show you proposed solution to share this key additional attributes to a Linux crypto framework. Here, taking an example of SK Cypher only, though it can extend to other crypto ops as well. As part of crypto elox SK Cypher, called by kernel subsystems like KTLS or DM crypto, where we are calling the crypto TFM, we are a structure for crypto TFM, what allocated. As part of this structure, proposes a proposal is to add two members, one for identifying the key type, is it the key as of key, trusted key, logon key, or any user defined key. Other one member is key payload, the reference to the key payload, where the point reference to the key payload will be stored before passing it to Linux crypto frame. So for instance, this is the key, there's a trusted key ring where the key payload is there as part of the key payload structure. Like let's here is the example of trusted key payload is being taken, where I'm proposing to add another static array for storing the attributes. And while the kernel component like DM flip or any other kernel management layer, fetch the key payload, set the key type based on the key ring, set the reference of the key payload to this before passing it to Linux crypto framework. That's what I'm proposing as a coupling between Linux crypto framework and kernel key ring for fetching key attributes. Let me take an example of DM Crypt in the next slide. Here, in the user space, when user gives logo name with the DM setup command along with the key ring name as well as the key name, DM Crypt first search for the key from the key ring. The key payload being searched and fetched and stored in the local structure of DM Crypt. Then the logo on, working on the logo name, the Linux crypto DM Crypt calls the crypto elox SK side for command and I'll get the crypto TFM allocated as part of this call. The fetched key payload and the key type are being set by the DM Crypt in this structure. After this population of crypto TFM, DM Crypt call SK Cypher set key where the crypto TFM key and key length has been passed. In this, you can see I have taken an example of, I've taken an example of an XP hardware IP called CAM, is a hardware accelerator for crypto operations. As part of the key loading, the additional key attributes are stored by CAM in key payload of the trusted key in. So when the key serial command is being used to load the key from the key block in the key ring, CAM puts the CAM specific attribute structure and populate the values to it. As you can see. And when as part of SK Cypher set key, when this function get offloaded to CAM, for performing the Linux crypto operation, the CAM fetches the key attributes which were populated by CAM itself during loading of the key in the key ring. CAM fetches that key attributes from the key payload part of the crypto TFM and enforce the conditional crypto operation. This way, we can achieve the tight coupling which is a necessity for IoT devices. IoT devices, so I'm coming to the, I'm here coming to the concluding points. Enhancing the robustness of Linux crypto framework based on key attribute means making the system security more robust. Increased security robustness makes it more compelling for LCF key ring that stores key attribute. That's my proposed and my RFC fetches also ready. I will be putting up this patch in coming days. Looking forward for the comments from the commentator. Thanks, I'm open to questions. So this is David Howells. So I own the key ring stuff. Would it be helpful if I added a new, an additional add key system called it's allowed you to pass attributes as well as a payload to pass them separately. And a key cuddle to read attributes from the key, from a key. So what I understood from you is that you, if you add a key CTL, an option in key CTL to list the attributes. And a new add key system called that could take an extra parameter that it's a list of attributes. Would that be useful for this? Yes, in a sense, yes, it will be useful to it. But what I propose as part of this slide, if I go back here, then these attributes being generated are being populated by the blob. So what I also look for the integrity of these attributes. So if the last time when the block, this key was generated and packed as part of blob, that is the integrity is within it. So only nobody else or no unauthorized user can change the attributes which are freeze to this blob. So when key CTL is loading this blob, these attributes being populated by the driver which generated that blob. So the integrity of those attributes are there in that. So Pankaj, what you're suggesting is that the key CTL call itself is sufficient right now for passing the attributes, right? So I think David is saying that if, I mean, if there is something additional that can be added to the add key system call, would it be required? So maybe I think, David, we need to think about that. We did not consider that particular point because so basically what we were testing, we've been doing is with the key CTL and there are, and I believe there is a mechanism to pass the attributes along with that. But yeah, so if your proposal of adding a new system call, we need to think as to what all can be achieved with that and what we, I mean, if something, if there is something that we can't still do with key CTL the way it is. Okay. But yeah, we can think about it. Another comment on your crypto TFM structure, is that actually safe what you've done there? You should probably pin the key as well, otherwise your, you've got a point to the payload, that might, the payload may disappear, and you, that's- It might disappear. Be de-allocated, unless you're pinning it in some way. Mm-hmm. Okay. Okay. That's just a technical thing. So I think Pankaj is going to post the patch and maybe can have a little, we can review it on the meaningless and see if there are issues there. Okay, yep. Yeah. I think we're good. Thank you very much. Thank you. Thank you. Thanks a lot.