 Okay. Thank you. And good morning. This is my first presentation here in the Linux Secure Summit. So a brief introduction. So my name is Claudio Secure de Carvalho, but in English they call me Claudio Carvalho or Carvalho or maybe Claudio Cavallo that in Portuguese cavallo means horse. It's a little bit funny, but okay. And so TPM chip, the TPM chip is a crypto processor and it provides several capabilities and if you go to the internet you can see some TPM use cases. But today I want to talk about how we are using the TPM and VRAM to protect secure bird case in open power. In power nine open power systems. This is the outline. So before showing how we protect the secure bird case in open power, I want to give you a brief introduction on open power secure bird and also describe the problem and then show how we protect the secure bird case in open power. So the secure bird team, open power secure bird team, we have several contributors and contributors and I work in the IBM LTC security team and IBM Linux technology center actually and in the security team in the LTC and I'm a secure interested boot developer and I have led the development team, the secure interested boot development team in the LTC security but we also have contributors and other contributors in the LTC security and also in the Linux technology center also IBM power firmer and IBM research. So disclaimer, so this work doesn't represent my view, actually it represents my view not IBM's view and all design points disclosed here are subject to finalization and upstream acceptance and the features which I'm going to describe here, they may not automatically exist or take a described form in the product. So I don't know how familiar you are with secure bird, so secure bird, what is secure bird for? So secure bird aims to prevent untrusted code from loading during the platform boot and for that it uses digital signatures so that only code signed with trusted case are started during the platform boot. But what is open power secure bird? First I should say that open power is open source, open power firmer is open source, you can go to the GitHub, the open power organization in the GitHub and there you can find the source code of all firmer components that we load in the firmer stack. And you also find the OP build project that we use to build an open power image that you can flash, you can clone that OP build repository and use it to build an image and firmer image and also test the firmer image. The instructions is in the readme file. So open power secure boot, it's divided into two domains. Firmer secure boot applies to all the firmer images we load up to the boot loader and OS secure boot applies to the OS kernel images and that gives us some flexibility. For example, we can enable firmer secure boot but disable OS secure boot if you want and we can also sign the kernel with different keys, we don't need necessarily to sign the kernel with the same keys that we use to sign firmer. This is a power nine boot flow. It describes in a high level with the boot flow in a power nine but I think we don't have time to go through all of these components here in this presentation. So if you're interested on this, to know more about the power nine boot flow, you can go to the link down there. Instead, I'm going to use this very simplified boot flow here to explain secure boot and power. So firmer secure boot. In firmer secure boot, the firmer images are signed following the secure boot container layout and in manufacturing, we sign all the firmer images and store them in the processor NOR here. And the processor NOR or PNOR for short. And we use these SB signing tools to build the firmer images and actually to build the secure boot containers. And basically it gets the image and it signs the image with up to three firmer keys and sign the public firmer keys with hardware keys and three hardware keys. And also in manufacturing, we store the hardware key hash because the hardware key hash, the hardware keys are the root of trust in the container. So to make sure that only trusted firmer images are loaded during the boot, we calculate a SHA-512 hash over the public hardware keys and store it in a protected memory so that at boot time we can just check if the only trusted containers, secure boot containers are loaded. And in the container, all this data, the public keys, the signature and the hashes, they are all appended to the image. And that's what we call it as container. And the verification code is responsible, is used to verify the container, the secure boot container. And it is stored in the LTP ROM, which is a one-time programmable ROM. It's stored in the protected memory as well. And the hardware key hash, the verification code and also part of the initial code that kickoffs the platform, they are part of our core root of trust. So they don't need to be verified. We trust them. And secure boot, the firmer secure boot can be enabled by a hardware setting, the motor board, which is platform dependent. And so self-boot engine, part of the self-boot engine, we don't need to verify it because it is stored in the protected memory. But all the other images, subsequent images, open power abstraction layer, all the subsequent images need to be verified, the secure boot container to be verified because they are all stored in the processor. And the firmer secure boot is upstream. Here I took a screenshot, Opal this level. And as we can see, all the images loaded by Opal at both time, they are verified. And but even if the verification failed, in this case, the boot wouldn't be aborted because secure mode here is disabled. So if in any of these stages, host boot, Opal, secure root, if any of these stages, if the verification failed in any of these stages, the boot is aborted and the image is not loaded. We also have the hardware key hash here in the device tree if you want to take a look at the hardware key hash, the trusted hardware key hash actually. OS secure boot. So the OS secure boot is a work in progress. We are still working on the design and also implementation. And the secure boot is a secure boot container and when it's loaded, it's verified. But as you can see, the secure boot is a Linux kernel with embedded in it from a fast that runs Peti boot and Peti boot is our boot loader. It's a Kexac boot loader. It uses Kexac to boot the OS kernel. And it reminds me the panel discussion we had yesterday where they discussed Linux as a firmer. So in the current design, the OS kernel, the host OS kernel is signed with signed kernel file, which is the same tool used to sign kernel modules and the signature is embedded in the file. And we are engaging with distros to provide signed kernel for us. The OS kernel is verified at the secure root kernel space at boot time. Verified at boot time. The secure root kernel space by IMA appraisal. And we are adding support to signature, adding support to appended signatures to IMA appraisal. And we are also defining a platform key ring where we are going to put our case so that IMA appraisal can verify the kernel. So in the current design, we want to reuse the kernel code that supports the file as much as we can. And especially the EFI virus file system. Because with the EFI virus file system, we can use space tools such as the EFI virus space tools to manipulate the secure boot variables. And in order to enable the EFI virus file system, we don't use the EFI system tables. We only need to set these runtime services here, the get, variable get next, variable set, variable query, variable info. And we set them to call open runtime services that will provide access to the key store stored in the PNOR, in the processor NOR. This part is already prototyped. It's still in the current design. We are in the process to request gistros to build the EFI virus package on PORPC64LE. And we use the EFI, as I mentioned, you use the EFI virus to manipulate secure boot variables. And in the secure boot variables, we store X519 certificates. And these are the secure boot variables we use, the platform key, the key exchange key, and the authorized signature database. So, the platform key or PK, for short, it's the root of trust for the OS secure boot. And when it's set, updates to any secure boot variable requires authentication, which means that if I want to update the platform key, the PK, the update, the PK update needs to be signed with the current PK. If I want to update the CAC variable, the CAC update needs to be signed by the current PK. And if I want to update the DB variable, the updates need to be signed by one of the CAC entries, one of the CAC keys. And if the PK is set, it also requires authentication when we try to load a, to boot a kernel, OS kernel. And it means that only outrides OS kernel will be loaded, will be executed, will be booted. And in order to outrides OS kernel to boot, we need to add the certificate that we used to verify the kernel into this DB variable here. So, what are we trying to solve? The Firmware Secure Boot Key, the Firmware Secure Boot Key store, we only need to store the hardware key hash. And it is stored in the CEPROM. It's a good memory. But for the OS Secure Boot Key store, in the OS Secure Boot Key store, we have the PK, the CAC and DB. And these secure boot variables, we reserved a partition in the processor nor to store these variables. But the problem is that the PNOR, the processor nor is unprotected by design. So, attackers could just have their malicious code executed, for example, if you have privilege in the OS, boot privilege in the OS, or if you have privilege in the BMC, or in the open BMC, which is our service processor, you could have access to the processor nor and change the secure boot keys. So, we remember that in the open power systems, we have the trusted platform module, we have the TPM 2.0. And TPM 2.0 also provides non-volatile memory. And we could use that for store the secure boot keys to protect the secure boot keys. But there is no space in the TPM and V to store all the secure boot keys, the secure boot variables. So, we need to store only what we really need in the TPM and V. So, let's see how we use the TPM and V ROM to protect the secure boot keys. Let's discuss these issues here that we are addressing, the integrity, how we alterize access to the TPM and V, and what variable should we store in the TPM and V, and how do we provide atomic variable update. So, integrity. The keys, since the PNOR, the processor nor is not protected, the keys could be modified without notice. And that's why we calculate a hash over the variables we store in the PNOR. And with that hash, we can detect integrity issues. It's also a SHA 512 hash. And we store the hash and also the size in the TPM and V. And the keys would be consumed, the variables would be consumed, only if this integrity check pass. So, only if the keys are valid. Okay, how do we alterize access to the TPM and V? We store data in the TPM and V. So, we need to control access to the NV. There are a few options here. We could, for example, set a policy, TPM policy to access the data, the NV data. We could share secrets with user space because this data should be, we should provide access to this data only for trusted entities. We could provide access to user space, but we would need to share secrets. We would need to define a policy and all that would complicate the design a little bit. So instead, we just write lock the NV memory at boot time until the next boot. And that also adds a restriction in the design because the NV memory we allocate, it will be open only at boot time, which means that if we have an update to the keys, to those variables, those updates should be processed only at boot time because that's the only time frame that we have the NV open. And that's why we also need to have an update queue. So, if user space wants to manage the keys, all the updates should go first to the update queue and then at boot and reboot the system and at boot time, we process those updates. And the security Linux kernel is responsible to process those updates at boot time. And so the security Linux kernel will process the updates and when the security kernel is done with those updates, it will write lock the NV memory allocated until next boot. And what verb should we store in the NV? Well, if the platform key is lost, we lose root of trust. And OSQ boot would be broken because authentication wouldn't be required to modify the keys nor to boot a OS kernel. And that's why we store our root of trust, the platform key in the TPM and NV. What about the other variables we have in the processor nor? Well, the KAC and DB, we continue to store them in the processor nor because we don't have space to store them in the TPM and NV because TPM and NV is small, it's less than 24K. And if the integrity check fails on these variables here, we will not use them, but there is no, we don't need a special procedure to recover those variables. We can just submit new updates to those variables. Atomic variable update. Well, now we have two storages. We have keys in the processor nor and we also have keys in the TPM and NV. And at the time that we are updating one of these, especially the PNOR, the processor nor, the right operation can fail. We can have a power outage. We can have a driver misfunction. And that would be a problem because the keys would be in a bad state if that happens. And that's why we use two banks. And we use one bit in the TPM and NV to indicate which bank is the active, is the current active. And when we have updates to the variables, we process those updates and apply the updates to the staging bank without touching the current active. And when we finish to apply all the updates, we then flip the bit, this bank selector bit, to indicate that, okay, I'm done with all the rights. And now let's reboot the system and use the new keys. Make sure that everybody will use the new keys. Okay, now we know what data we are storing in the TPM and NV. And how do we create, how do we allocate memory in the TPM and NV? We use this NV defined space command, but we don't interact directly with the TPM and NV. With the TPM, actually, TPM chip, we use a TCG software stack and implementation of the TCG software stack. And TCG stands for trusted computing group. And this is a, this TSS is an IBM's TSS implementation. So we need to use this NV defined space to define an index. And we need to provide the handle of the index. And also provide the attributes and the size for this NV index. As you can see here, at the bottom, we need more than 2K bytes. And there is a restriction in the TPM 2.0 that the maximum size for the NV index is 2K. So that's why we need to create three indexes. So we have one index for the header, another index for the bank zero, and another index for the bank one. But they all have the same attributes, but different sizes. And they are all right-locked at boot time until the next boot. So here, we need to provide, to create this, to define these indexes, we need to provide the TPM platform authorization. And also define these NV attributes, define the NV attributes. And there is another command here, NV with public, where we can read the NV index attributes. And here it shows that it's 6 bytes, the size is 6 bytes. And the attributes are NV, P, P write, all these attributes here. And P, P write and all write means that if you provide the platform authorization or the index authorization, you should be able to update this, to write to these indexes, to these indexes here. And they are all ordinary indexes, which means that we can store any data structure in those indexes. Write as clear means that if write lock is called, the write lock bit will be cleared when the TPM is reset or restarted. And platform created means that only the platform authorization, only if we provide the platform authorization, we can undefine these indexes. Firmware secure boot NV index. Well, I didn't mention that we are also storing data for the firmware secure boot. But we are. So we define one index and in this index, we store only the hardware key hash because we have two domains. And if the firmware secure boot domain, if the hardware keys are changed in the firmware secure boot domain, that means we need to invalidate the root of trust of the OS secure boot or in other words invalidate the PK. And that's why we also need to store to have this firmware NV index. We have other commands here. So NV write, we can write to the index and we need to provide the authorization here. I'm using the platform, TPM platform authorization. And I write in this first command, I write Linux secured summit to this index here. And then I read and set the output file to the lss.txt. And after that, I just xdump the lss.txt just to make sure that I have the content that I just wrote. So we can write lock NV index until the next boot, until the next TPM reset or TPM start. And after we write lock the index, if we try to write to the index, it will tell us that it's right-locked. We cannot define an NV index and when it's undefined, in order to undefine any of the indexes we define, you need to provide the platform authorization, the TPM platform authorization. And once after you undefine the index, if you try to read from that index, it no longer exists. There is also command to set the platform authorization to a non-default. It's important because if you leave it with the default password, an attacker could just undefine our index, even if we write lock the index. So this is the OS security architecture with the TPM and NV updates. OPAL is the open power abstraction layer is responsible to define the NV indexes and also write lock the firmware index. And it also provides the OPAL runtime services which in turn provide access to the key storage, the PNOR sec boot. And there is the update queue in the PNOR sec boot, which is processed only at boot time by the secure root Linux kernel. The TPM and NV itself, it can be accessed by OPAL or any subsequent Linux kernels. And they are right-locked. The Linux kernel will process the updates at boot time and at that point the OS and NV index is right-locked. And I had to implement a TSS in the OPAL layer and also TPM drivers to support to interact with the TPM 2.0. So final considerations, the TPM 2.0 has shown a secure and available storage to protect secure boot case. We don't need necessarily to store all the keys in the TPM and NV. So I showed that we can store only some information, some data in the TPM and NV and protect the case. And it has several commands that you can use to interact with the TPM and NV. So we can write lock, we can define, allocate memory, we can deallocate memory. And by using a TPM to provide secure boot that adds a dependency on the TPM 2.0. So open power OS secure boot depends on TPM 2.0. And the TPM 2.0 is available in the Power 9 open power systems. Sharing the TSS code throughout the Firmware Stack is challenging because the Firmware Stack, each component in the Firmware Stack has different requirements and they don't need to have a full TSS implementation and we don't have protected memory to store a TSS implementation, so it's challenging. And verbose mode, well, the IBM's TSS implementation provides verbose mode. You can just pass dash dash V in the command and that will show you all the steps that it goes to send the command to the TPM chip. And I think that's very interesting, that helped me a lot because I could see what's the stream byte, what is the byte stream that was sent and received from the TPM. So it was good for me to validate the commands or the implementation in the Firmware Stack. And here's some references. Open power foundation, you can find more information about open power systems in the open power foundation. And the Firmware is open source, you can find the Firmware in the GitHub. If you want to know more about Power 9 boot flow, you can go to this other one, link here. And in the following one, you have more information about open power secure boot, Firmware open power secure boot, trusted platform module, all the specifications are available in the TSAG website. And IBM's TSS implementation, it's open source, you can find it in this link here. And that's it, unless anybody have any questions. So am I right in understanding that there is no rollback protection in this design? Or if it is, I missed it. Which slide? Do you have rollback protection? No, we don't provide that. It's complicated to have rollback. Initially we thought that we could have, but that's complicated. Thanks for your talk. Please correct me if I'm wrong. So secure boot helps to verify that our operating system kernel is not compromised, right? And can you at the same time use TPM for verifying that your firmware is not compromised? So like boot guard or something like that? Yeah, we provide this feature in the Firmware secure boot here. So all the boxes in yellow is Firmware, is the Firmware stack. The security is bootloader and here is the whole OS kernel. So we use, we provide, we boot only Firmware images that are trusted in this case here. If they are signed with the keys we trust, which means the hardware keys, so they need to be signed with trusted keys. And the trusted, and that hardware key hash, those hardware keys, those keys need to be the trusted one, the keys we trust. So that's how we provide a few more secure boot. Does that answer your question? And does this use TPM for this key, for this root of trust? Where it is stored? I'm not sure if you understand your question. But we use the TPM as a storage and we also use all the capabilities that it provides to restrict access to the NV. Yes, so you use TPM both for keys for firmware verification and both for secure boot. No, we use the TPM only for the OS. So only for stored keys that we use to boot the OS. The other keys are stored in the container. So in the container you find the public keys, the signature, the secure boot container, you find the public keys, the signature, everything that is required to verify that image. Okay, how do I know that that container is trusted? Well, I use this verification code here to check if the container is valid, the format is valid, and also to verify each signature and the root of trust is the hardware keys. So I just calculate a hash of those hardware keys available in the container and compare with the hash that I have here starting the protected memory. If those two hashes match, that's okay. I can trust that container. Thank you. Just two more questions. So maybe I misunderstood, but are you putting the PK as well as the hash of the PK in this NV index? No. Oh, okay. I'm trying to figure out how you're consuming so much space in there. No, let me go to that slide. We put only the, we calculate a hash over what we have in the processor nor, and in the processor nor we don't have the PK. That was a... Yeah. No. Here. So this hash is calculated over KAC and DB only. Right. Okay. But those aren't 2K in size. I'm trying, I mean, you consume a lot of NV space. Yes. Trying to figure out what, I'm not quite understanding what's in there. A hash isn't that big. That's what I asked, and he said no. The key, so why are you putting the PK in the NV? Because we... The hash will protect it. You don't need the whole PK in there. But if we, if we have a, if the hash we can detect integrity issues. You keep the PK outside. Yes. Verify it with what's in NV and then you can use it. The problem is, if the integrity check fails on the variables I store in the processor nor, I can't use those variables anymore. And if the PK is there, well, my root of trust is compromised. I can't trust on any, on any code that is loaded from that point on. So it's a, it's not a, it's a reliability issue you're concerned about. Not necessarily, but you have two banks. Yes, we have. Okay. All right. But if, if the module fails if the PK is wrong and if the code is wrong and the PK doesn't verify it, you're still in a non-boot situation. If someone can attack the PK, they can attack the rest of the code. And then that code won't verify and you're in the same position as if the PK was messed with. So I'm still not seeing the benefit. Yeah. Yeah, in our case, PK is in the TPM and V. I'm trying to understand how could someone change the PK in the TPM and V if we right lock it. I think we're out of time. We can talk offline. Yeah. Yeah, sure. Thank you, Monty. So for the Linux boot work I described yesterday, we're using the Chrome verified boot model, which does do anti-rollback. And I'm just wondering if you looked at that at all, the Chromebook use of TPM. Let me see if I understand. Can you repeat your question, please? So Chromebooks have used the TPM in roughly a similar way, but they do implement anti-rollback protection. And there are just, there are points of correspondence between what you're describing here and how Chromebooks work. I was wondering if you looked at how the Chromebooks implemented the verified boot when you were doing this work. Mm-hmm. Yeah, I'm not aware of the Chrome OS implementation. Okay. I think it would be pretty rewarding. Yeah. This is neat, but I think that would help a little. And your EFI services thing looked really neat. Was that a kernel module? The thing that implemented EFI services and then used the Opal services? Yeah, that part is still in progress. We need to find a way that only, that that part is loaded, that I think it's going to be a module, but not a module, but something that we can disable using a kernel symbol. It is part of the Linux kernel, though. That's neat. Okay, thanks. I was curious about that. Thank you. Yeah. The SQL root is a fork of the vanilla kernel. Okay, so we're a little over time. Thank you. We'll have questions later. Thank you. Obrigado.