Improving the Secure Boot landscape: sbctl & go-uefi
Linderud, Morten
Łęcki, Jakub
Utilizing secure boot should be simple. Our current tooling is badly integrated, abstractions leaking and the code bases are not reusable. Functionality is spread between several projects and not one covers all your needs. This amounts to a confusing landscape. sbctl and go-uefi is a tool, and a low-level UEFI library, that attempts to push the secure boot landscape forward. In this talk I'll do a short introduction of secure boot and the tooling people normally use. We will look at the different use cases each of them provide and missing functionality. Then I'll do a short demonstration of sbctl and go-uefi. The goal is to try provoke some ideas how we can make secure boot more accessible for users. Currently the tooling assumes some familiarity with secure boot implementation details (signature lists, PK/KEK/db keys and so on) and that shouldn't be needed to have a fairly basic secure boot setup.
 Yo, and welcome to my presentation about Secureboot user space tooling. We'll talk a little bit about what the current state is, what I've been trying to do to improve it, and why Secureboot is difficult. So my name is Morten Linnardö, I go by the nickname of Foxbaron. I work as a security engineer at Defendable, and I've been a free and open source software developer since around 2013. Since 2016, I've been contributing to the Arch Linux distribution, where I've been doing security advice rework, tracking security vulnerabilities. I also do reproducible builds, figure out how we can do bit for bit identical builds of packages, and I also do a lot of packaging in sort of like the Go space and the container space. I also care a lot about supply chain security, and that's where my main interest from Secureboot stems from. So Secureboot is terrible, but it's a shame because Secureboot is terrible for the wrong reasons. And a lot of this stems from the complexity of the current tooling. So if you want to write, if you want to figure out how to encrypt the disk, you'd figure out that, oh, I just format it and then you open it. And that's easy, like if you do a new installation, it's trivial to remember those commands, it's sort of self-explanatory, and it's not really hard. If you want to figure out how we enroll your own Secureboot keys, you end up with like Erudig and Tuvicky, Rod Smith's controlling Secureboot guide, or like ArchVic is a Curb but page. And all of these are fine, but they're extremely long articles, they contain a lot of implementation details, and it's easy to make mistakes. So if you were to set up Secureboot, you'd need three keys, which is a platform key, which is sort of like the main thing that controls the platform. Key exchange keys, which authorizes the key that can sign your EFI executables. And you also want a database key, which is sort of the key which does the signing itself. And to do this, you sort of make three keys with OpenSL, you also do a Durkey, which, while making this presentation, I don't know why do it, I forgot, but apparently you need the Durkey as well, and people copy-paste all of these commands. So all of these commands are virtually the same across the Gintu, ArchVic, pages because they're all copied from the Rod Smith guide. And you see this because it's a 3,650 days expiring on the keys, and usually they all have RSA 2048 bit strength. Then you create a UID, which should be sort of random. You take the PEM keys, and you do an EFI signature list with them, and then you sign the ESL, the PK needs to sign the self, the PK needs to sign the KEK signature list, and the KEK needs to sign the database signature list. And already at this point, you might be asking, what's the EFI signature list? And, well, it's explained in the documentation or the man pages, but you don't really need to, you shouldn't really have to need to know how, what works. And then you need to enroll the keys, which is usually done with the EFI update words. You can also sort of do the key tool, EFI executable, and some mod boards also supports it in their sort of bias set of utilities. And the next part is to sign a kernel, and that's sort of where some people get a snipe because EFI tools does not support kernel signing. You need someone that implements the sort of the PA cough executable signing. You need another set of tools to do the signing. So a lot of people use SAP sign tools, which is maintained by Canonical, and that allows you to sign the keys, no, a kernel, and you reboot and hopefully it works. So that was 17 commands and two packages to set up secure boot, which is a lot, I think, we can do a lot better. And there's no really good reason why it is like this, like SAP sign tools sort of implements most of what EFI tools does, frankly, better, better way. It also does signing because it implements the PA cough library, which is used to sign the EFI executables. And it also actually supports an undocumented key enrollment system, which is called SP key sync, which has no man page, but it exists. And again, EFI tools doesn't provide any signing. There's also the P sign tools, which are maintained by Red Hat. They, I don't think they do all of the things EFI tools and SP sign tools does, but it implements yet another P cough library because see, I guess, people don't, this is sort of not that easy to distribute source libraries, so people either sort of write their own or how to distribute the surnames or the dynamic library for this. And if you want to have like a revocation list, people have been using DBX tool, but this is now deprecated and merged into the firmware update manager tooling. So there's a lot of like separate tools that does a lot of things, not easy to get a grasp of if you're setting this up the first time. So my conclusion has basically been that we can do better. We can do a lot better, actually. So that sort of brings me to the demo, which I have today, which is basically, we're going to do a quick chemo run. So we'll have, we use the OVMF, secure boot parameters with the kernel. So what we currently have is that we have SBCTL, we can run status and then we see we are in setup mode, which allows us to enroll keys, but do not don't have secure but enabled. So we're going to quickly fix that by creating some keys. So this is create, does all of the commands that you previously did. And I'm also going to enroll the keys. So now the keys are synced. So if you run status again, we'll see that we now are out of setup mode and secure is still disabled. So what we're going to do is that we're going to sign our kernel. And then we're also going to just save this for the future. And then we have signed a kernel. So now we can also list all of the files we have done. And sort of this helps us keep all of the files assigned. So now we have signed the kernel, we have enrolled all our keys. So we are now just going to prove to you it works. So this is chemo again. This time we're entering the EFI shell. So do boot manager, EFI tunnel shell, full screen. And we'll quickly go to this. So we have the kernel we have signed. So if we try run this on the kernel EFI, we should say see that this command there is still is access denied because kernel.EFI is not actually signed. However, if we do sign.EFI and we specify the root device as the SDA, we see that we have actually booted Linux. SPCTL status. And you now see that we actually have a setup mode disabled, security is enabled and everything is fine and dandy. So that was quick demonstration how it could be that much better. So if SPCTL, which is secure boot control, I originally wrote EFI roller three, four years ago, which was a huge batch script, we just generate all the keys and enrolls it. It works, but sort of secure boot. Now it bashes a little bit limiting when things get complicated fast. So SPCTL does all of this, it's a sign key management. It does key enrollment. And it also keeps track of what to sign. You can also use this along with EFI stub generation so you can have the interim FS and the kernel signed together, which enables people to not being able to modify the signed image when you're done, because that's still a threat if you only sign a kernel. So there's a few missing features that SPCTL does not implement. It's our key rotation. It doesn't have configuration files and preferably we'd have hardware tokens because most of the guides just expense to have to do sort of like clean keys, no passwords, no hardware tokens. And it works, but if you don't encrypt your disk, then you don't have that much of a secured gain. I've had a lot of help from Erko Rowling, Erko RR, which is a WordLinux package and developer working on SPCTL. And it works, I use it daily, my computer now runs SPCTL, designing kernels. And it's mostly like quality of life features left, I think. But there's still a slight problem. And even though we sort of have written all this in Go and stuff, I still shell out to SPCINE tools to accomplish all of these tasks, and we're not using Bash anymore, we're using a system language. So why are we still showing out? That's sort of what tickled my fancy to try to figure out, is there an easier way for this? So Go UFI is sort of my continuation of the project. And that's basically me at the start of Corona picking up the UFI specification, start reading it. So it implements a lot of the structures from the secure boot, not from the UFI specification. Mostly the things relevant to secure boot is what I've been doing, because the end goal is to have a Go library that supports SPCTL and secure boots and stuff. It implements Microsoft Authenticode, which is what's used for UFI signing. So we can check some of the kernels, we can also sign it, and it mostly works. Those implements a subset of PKS-C7, which is needed for verifying the files and ensuring we can sign stuff. And sort of how it works is that we try to provide some top-level API we can use to pick off text summing. We can read in some certificate and a key, and we can just sign the PECOF executable and write it back out again. And this works. I've booted my computer on this before, so that's very fun the first time that worked. We can also do EFI variable authentication, which is used to update the variables which is signed with. So we can do a string to Go ID. We can then read some X509 search file, we can do a new signature list and define which UID this is. Then a new bytes buffer, we can write a signature list and just sign the variable. This also works. So I've re-implemented most of the ESPiSign tools binaries in Go to just ensure things work and it does, which is a bit fun. So all of this is very much a work in progress. It's not done at all. I'm missing a nice top-level API, so nothing is really stable. The BKS7 code is, it doesn't parse ASM1 structures that well in some cases, so there's still edge cases where it's unable to verify signatures. That's a little bit bad, I think it should probably be fixed. I also wanted how integration tests, so we can ensure that the API and all the stuff actually works with the UFI specification. I've been sort of hammering about doing this with the VM test library from Anatol, which is another Arch Linux developer, and Tiano Core, LashiDK2, I think it's called. So it's also only currently Linux only because we only really care about the EFR files under stash tests. So this is not OS X or Windows compatible, but it works. It's nice. It's nice, it's a nice library. It fulfills its goals, but it needs a lot of work before being stable. The end goal is to move SP serial away from shelling out to SP sign tools, and much more I use GoUFI instead. So that's sort of my short introduction to these tools to try to figure out how we can do better. Both of these, all this is public code, it's all open source. Also I've tried to do sort of a secure.dev website to try to document the relevant things I've learned while working on this, but that's a project that's really not well underway yet. If you're curious about this work or have questions, you have two of my emails here. You can also ping me on Foxpar on free note as well. So Q&A I guess. I hope this was enlightening and I hope people are interested in sort of making it secure, but easier for users. Thank you!
 Yo, and welcome to my presentation about Secureboot user space tooling.  We'll talk a little bit about what the current state is, what I've been trying to do to improve  it, and why Secureboot is difficult.  So my name is Morten Linnardö, I go by the nickname of Foxbaron.  I work as a security engineer at Defendable, and I've been a free and open source software  developer since around 2013.  Since 2016, I've been contributing to the Arch Linux distribution, where I've been doing  security advice rework, tracking security vulnerabilities.  I also do reproducible builds, figure out how we can do bit for bit identical builds  of packages, and I also do a lot of packaging in sort of like the Go space and the container  space.  I also care a lot about supply chain security, and that's where my main interest from Secureboot  stems from.  So Secureboot is terrible, but it's a shame because Secureboot is terrible for the wrong  reasons.  And a lot of this stems from the complexity of the current tooling.  So if you want to write, if you want to figure out how to encrypt the disk, you'd figure  out that, oh, I just format it and then you open it.  And that's easy, like if you do a new installation, it's trivial to remember those commands, it's  sort of self-explanatory, and it's not really hard.  If you want to figure out how we enroll your own Secureboot keys, you end up with like  Erudig and Tuvicky, Rod Smith's controlling Secureboot guide, or like ArchVic is a Curb  but page.  And all of these are fine, but they're extremely long articles, they contain a lot of implementation  details, and it's easy to make mistakes.  So if you were to set up Secureboot, you'd need three keys, which is a platform key,  which is sort of like the main thing that controls the platform.  Key exchange keys, which authorizes the key that can sign your EFI executables.  And you also want a database key, which is sort of the key which does the signing itself.  And to do this, you sort of make three keys with OpenSL, you also do a Durkey, which,  while making this presentation, I don't know why do it, I forgot, but apparently you need  the Durkey as well, and people copy-paste all of these commands.  So all of these commands are virtually the same across the Gintu, ArchVic, pages because  they're all copied from the Rod Smith guide.  And you see this because it's a 3,650 days expiring on the keys, and usually they all  have RSA 2048 bit strength.  Then you create a UID, which should be sort of random.  You take the PEM keys, and you do an EFI signature list with them, and then you sign  the ESL, the PK needs to sign the self, the PK needs to sign the KEK signature list, and  the KEK needs to sign the database signature list.  And already at this point, you might be asking, what's the EFI signature list?  And, well, it's explained in the documentation or the man pages, but you don't really need  to, you shouldn't really have to need to know how, what works.  And then you need to enroll the keys, which is usually done with the EFI update words.  You can also sort of do the key tool, EFI executable, and some mod boards also supports  it in their sort of bias set of utilities.  And the next part is to sign a kernel, and that's sort of where some people get a snipe  because EFI tools does not support kernel signing.  You need someone that implements the sort of the PA cough executable signing.  You need another set of tools to do the signing.  So a lot of people use SAP sign tools, which is maintained by Canonical, and that allows  you to sign the keys, no, a kernel, and you reboot and hopefully it works.  So that was 17 commands and two packages to set up secure boot, which is a lot, I think,  we can do a lot better.  And there's no really good reason why it is like this, like SAP sign tools sort of implements  most of what EFI tools does, frankly, better, better way.  It also does signing because it implements the PA cough library, which is used to sign  the EFI executables.  And it also actually supports an undocumented key enrollment system, which is called SP key  sync, which has no man page, but it exists.  And again, EFI tools doesn't provide any signing.  There's also the P sign tools, which are maintained by Red Hat.  They, I don't think they do all of the things EFI tools and SP sign tools does, but it implements  yet another P cough library because see, I guess, people don't, this is sort of not  that easy to distribute source libraries, so people either sort of write their own or  how to distribute the surnames or the dynamic library for this.  And if you want to have like a revocation list, people have been using DBX tool, but  this is now deprecated and merged into the firmware update manager tooling.  So there's a lot of like separate tools that does a lot of things, not easy to get a grasp  of if you're setting this up the first time.  So my conclusion has basically been that we can do better.  We can do a lot better, actually.  So that sort of brings me to the demo, which I have today, which is basically, we're going  to do a quick chemo run.  So we'll have, we use the OVMF, secure boot parameters with the kernel.  So what we currently have is that we have SBCTL, we can run status and then we see  we are in setup mode, which allows us to enroll keys, but do not don't have secure but enabled.  So we're going to quickly fix that by creating some keys.  So this is create, does all of the commands that you previously did.  And I'm also going to enroll the keys.  So now the keys are synced.  So if you run status again, we'll see that we now are out of setup mode and secure is  still disabled.  So what we're going to do is that we're going to sign our kernel.  And then we're also going to just save this for the future.  And then we have signed a kernel.  So now we can also list all of the files we have done.  And sort of this helps us keep all of the files assigned.  So now we have signed the kernel, we have enrolled all our keys.  So we are now just going to prove to you it works.  So this is chemo again.  This time we're entering the EFI shell.  So do boot manager, EFI tunnel shell, full screen.  And we'll quickly go to this.  So we have the kernel we have signed.  So if we try run this on the kernel EFI, we should say see that this command there is  still is access denied because kernel.EFI is not actually signed.  However, if we do sign.EFI and we specify the root device as the SDA, we see that we  have actually booted Linux.  SPCTL status.  And you now see that we actually have a setup mode disabled, security is enabled and everything  is fine and dandy.  So that was quick demonstration how it could be that much better.  So if SPCTL, which is secure boot control, I originally wrote EFI roller three, four  years ago, which was a huge batch script, we just generate all the keys and enrolls it.  It works, but sort of secure boot.  Now it bashes a little bit limiting when things get complicated fast.  So SPCTL does all of this, it's a sign key management.  It does key enrollment.  And it also keeps track of what to sign.  You can also use this along with EFI stub generation so you can have the interim FS and the kernel  signed together, which enables people to not being able to modify the signed image when  you're done, because that's still a threat if you only sign a kernel.  So there's a few missing features that SPCTL does not implement.  It's our key rotation.  It doesn't have configuration files and preferably we'd have hardware tokens because most of  the guides just expense to have to do sort of like clean keys, no passwords, no hardware  tokens.  And it works, but if you don't encrypt your disk, then you don't have that much of a  secured gain.  I've had a lot of help from Erko Rowling, Erko RR, which is a WordLinux package and  developer working on SPCTL.  And it works, I use it daily, my computer now runs SPCTL, designing kernels.  And it's mostly like quality of life features left, I think.  But there's still a slight problem.  And even though we sort of have written all this in Go and stuff, I still shell out to  SPCINE tools to accomplish all of these tasks, and we're not using Bash anymore, we're using  a system language.  So why are we still showing out?  That's sort of what tickled my fancy to try to figure out, is there an easier way for  this?  So Go UFI is sort of my continuation of the project.  And that's basically me at the start of Corona picking up the UFI specification, start reading  it.  So it implements a lot of the structures from the secure boot, not from the UFI specification.  Mostly the things relevant to secure boot is what I've been doing, because the end goal  is to have a Go library that supports SPCTL and secure boots and stuff.  It implements Microsoft Authenticode, which is what's used for UFI signing.  So we can check some of the kernels, we can also sign it, and it mostly works.  Those implements a subset of PKS-C7, which is needed for verifying the files and ensuring  we can sign stuff.  And sort of how it works is that we try to provide some top-level API we can use to pick  off text summing.  We can read in some certificate and a key, and we can just sign the PECOF executable  and write it back out again.  And this works.  I've booted my computer on this before, so that's very fun the first time that worked.  We can also do EFI variable authentication, which is used to update the variables which  is signed with.  So we can do a string to Go ID.  We can then read some X509 search file, we can do a new signature list and define which  UID this is.  Then a new bytes buffer, we can write a signature list and just sign the variable.  This also works.  So I've re-implemented most of the ESPiSign tools binaries in Go to just ensure things  work and it does, which is a bit fun.  So all of this is very much a work in progress.  It's not done at all.  I'm missing a nice top-level API, so nothing is really stable.  The BKS7 code is, it doesn't parse ASM1 structures that well in some cases, so there's still  edge cases where it's unable to verify signatures.  That's a little bit bad, I think it should probably be fixed.  I also wanted how integration tests, so we can ensure that the API and all the stuff  actually works with the UFI specification.  I've been sort of hammering about doing this with the VM test library from Anatol, which  is another Arch Linux developer, and Tiano Core, LashiDK2, I think it's called.  So it's also only currently Linux only because we only really care about the EFR files under  stash tests.  So this is not OS X or Windows compatible, but it works.  It's nice.  It's nice, it's a nice library.  It fulfills its goals, but it needs a lot of work before being stable.  The end goal is to move SP serial away from shelling out to SP sign tools, and much more  I use GoUFI instead.  So that's sort of my short introduction to these tools to try to figure out how we can  do better.  Both of these, all this is public code, it's all open source.  Also I've tried to do sort of a secure.dev website to try to document the relevant things  I've learned while working on this, but that's a project that's really not well underway  yet.  If you're curious about this work or have questions, you have two of my emails here.  You can also ping me on Foxpar on free note as well.  So Q&A I guess.  I hope this was enlightening and I hope people are interested in sort of making it secure,  but easier for users.  Thank you!
firmware_itsblsg_0_947.png firmware_itsblsg_948_1499.png firmware_itsblsg_1500_1583.png firmware_itsblsg_1584_2987.png firmware_itsblsg_2988_4103.png firmware_itsblsg_4104_6011.png firmware_itsblsg_6012_11387.png firmware_itsblsg_11388_13475.png firmware_itsblsg_13476_14531.png firmware_itsblsg_14532_16559.png firmware_itsblsg_16560_18155.png firmware_itsblsg_18156_18743.png firmware_itsblsg_18744_19451.png firmware_itsblsg_19452_19763.png firmware_itsblsg_19764_20423.png firmware_itsblsg_20424_21143.png firmware_itsblsg_21144_21395.png firmware_itsblsg_21396_21575.png firmware_itsblsg_21576_22367.png firmware_itsblsg_22368_22511.png firmware_itsblsg_22512_23471.png firmware_itsblsg_23472_25285.png
Yo, and welcome to my presentation about Secureboot user space tooling. We'll talk a little bit about what the current state is, what I've been trying to do to improve it, and why Secureboot is difficult. So my name is Morten Linnardö, I go by the nickname of Foxbaron. I work as a security engineer at Defendable, and I've been a free and open source software developer since around 2013. Since 2016, I've been contributing to the Arch Linux distribution, where I've been doing security advice rework, tracking security vulnerabilities. I also do reproducible builds, figure out how we can do bit for bit identical builds of packages, and I also do a lot of packaging in sort of like the Go space and the container space. I also care a lot about supply chain security, and that's where my main interest from Secureboot stems from. So Secureboot is terrible, but it's a shame because Secureboot is terrible for the wrong reasons. And a lot of this stems from the complexity of the current tooling. So if you want to write, if you want to figure out how to encrypt the disk, you'd figure out that, oh, I just format it and then you open it. And that's easy, like if you do a new installation, it's trivial to remember those commands, it's sort of self-explanatory, and it's not really hard. If you want to figure out how we enroll your own Secureboot keys, you end up with like Erudig and Tuvicky, Rod Smith's controlling Secureboot guide, or like ArchVic is a Curb but page. And all of these are fine, but they're extremely long articles, they contain a lot of implementation details, and it's easy to make mistakes. So if you were to set up Secureboot, you'd need three keys, which is a platform key, which is sort of like the main thing that controls the platform. Key exchange keys, which authorizes the key that can sign your EFI executables. And you also want a database key, which is sort of the key which does the signing itself. And to do this, you sort of make three keys with OpenSL, you also do a Durkey, which, while making this presentation, I don't know why do it, I forgot, but apparently you need the Durkey as well, and people copy-paste all of these commands. So all of these commands are virtually the same across the Gintu, ArchVic, pages because they're all copied from the Rod Smith guide. And you see this because it's a 3,650 days expiring on the keys, and usually they all have RSA 2048 bit strength. Then you create a UID, which should be sort of random. You take the PEM keys, and you do an EFI signature list with them, and then you sign the ESL, the PK needs to sign the self, the PK needs to sign the KEK signature list, and the KEK needs to sign the database signature list. And already at this point, you might be asking, what's the EFI signature list? And, well, it's explained in the documentation or the man pages, but you don't really need to, you shouldn't really have to need to know how, what works. And then you need to enroll the keys, which is usually done with the EFI update words. You can also sort of do the key tool, EFI executable, and some mod boards also supports it in their sort of bias set of utilities. And the next part is to sign a kernel, and that's sort of where some people get a snipe because EFI tools does not support kernel signing. You need someone that implements the sort of the PA cough executable signing. You need another set of tools to do the signing. So a lot of people use SAP sign tools, which is maintained by Canonical, and that allows you to sign the keys, no, a kernel, and you reboot and hopefully it works. So that was 17 commands and two packages to set up secure boot, which is a lot, I think, we can do a lot better. And there's no really good reason why it is like this, like SAP sign tools sort of implements most of what EFI tools does, frankly, better, better way. It also does signing because it implements the PA cough library, which is used to sign the EFI executables. And it also actually supports an undocumented key enrollment system, which is called SP key sync, which has no man page, but it exists. And again, EFI tools doesn't provide any signing. There's also the P sign tools, which are maintained by Red Hat. They, I don't think they do all of the things EFI tools and SP sign tools does, but it implements yet another P cough library because see, I guess, people don't, this is sort of not that easy to distribute source libraries, so people either sort of write their own or how to distribute the surnames or the dynamic library for this. And if you want to have like a revocation list, people have been using DBX tool, but this is now deprecated and merged into the firmware update manager tooling. So there's a lot of like separate tools that does a lot of things, not easy to get a grasp of if you're setting this up the first time. So my conclusion has basically been that we can do better. We can do a lot better, actually. So that sort of brings me to the demo, which I have today, which is basically, we're going to do a quick chemo run. So we'll have, we use the OVMF, secure boot parameters with the kernel. So what we currently have is that we have SBCTL, we can run status and then we see we are in setup mode, which allows us to enroll keys, but do not don't have secure but enabled. So we're going to quickly fix that by creating some keys. So this is create, does all of the commands that you previously did. And I'm also going to enroll the keys. So now the keys are synced. So if you run status again, we'll see that we now are out of setup mode and secure is still disabled. So what we're going to do is that we're going to sign our kernel. And then we're also going to just save this for the future. And then we have signed a kernel. So now we can also list all of the files we have done. And sort of this helps us keep all of the files assigned. So now we have signed the kernel, we have enrolled all our keys. So we are now just going to prove to you it works. So this is chemo again. This time we're entering the EFI shell. So do boot manager, EFI tunnel shell, full screen. And we'll quickly go to this. So we have the kernel we have signed. So if we try run this on the kernel EFI, we should say see that this command there is still is access denied because kernel.EFI is not actually signed. However, if we do sign.EFI and we specify the root device as the SDA, we see that we have actually booted Linux. SPCTL status. And you now see that we actually have a setup mode disabled, security is enabled and everything is fine and dandy. So that was quick demonstration how it could be that much better. So if SPCTL, which is secure boot control, I originally wrote EFI roller three, four years ago, which was a huge batch script, we just generate all the keys and enrolls it. It works, but sort of secure boot. Now it bashes a little bit limiting when things get complicated fast. So SPCTL does all of this, it's a sign key management. It does key enrollment. And it also keeps track of what to sign. You can also use this along with EFI stub generation so you can have the interim FS and the kernel signed together, which enables people to not being able to modify the signed image when you're done, because that's still a threat if you only sign a kernel. So there's a few missing features that SPCTL does not implement. It's our key rotation. It doesn't have configuration files and preferably we'd have hardware tokens because most of the guides just expense to have to do sort of like clean keys, no passwords, no hardware tokens. And it works, but if you don't encrypt your disk, then you don't have that much of a secured gain. I've had a lot of help from Erko Rowling, Erko RR, which is a WordLinux package and developer working on SPCTL. And it works, I use it daily, my computer now runs SPCTL, designing kernels. And it's mostly like quality of life features left, I think. But there's still a slight problem. And even though we sort of have written all this in Go and stuff, I still shell out to SPCINE tools to accomplish all of these tasks, and we're not using Bash anymore, we're using a system language. So why are we still showing out? That's sort of what tickled my fancy to try to figure out, is there an easier way for this? So Go UFI is sort of my continuation of the project. And that's basically me at the start of Corona picking up the UFI specification, start reading it. So it implements a lot of the structures from the secure boot, not from the UFI specification. Mostly the things relevant to secure boot is what I've been doing, because the end goal is to have a Go library that supports SPCTL and secure boots and stuff. It implements Microsoft Authenticode, which is what's used for UFI signing. So we can check some of the kernels, we can also sign it, and it mostly works. Those implements a subset of PKS-C7, which is needed for verifying the files and ensuring we can sign stuff. And sort of how it works is that we try to provide some top-level API we can use to pick off text summing. We can read in some certificate and a key, and we can just sign the PECOF executable and write it back out again. And this works. I've booted my computer on this before, so that's very fun the first time that worked. We can also do EFI variable authentication, which is used to update the variables which is signed with. So we can do a string to Go ID. We can then read some X509 search file, we can do a new signature list and define which UID this is. Then a new bytes buffer, we can write a signature list and just sign the variable. This also works. So I've re-implemented most of the ESPiSign tools binaries in Go to just ensure things work and it does, which is a bit fun. So all of this is very much a work in progress. It's not done at all. I'm missing a nice top-level API, so nothing is really stable. The BKS7 code is, it doesn't parse ASM1 structures that well in some cases, so there's still edge cases where it's unable to verify signatures. That's a little bit bad, I think it should probably be fixed. I also wanted how integration tests, so we can ensure that the API and all the stuff actually works with the UFI specification. I've been sort of hammering about doing this with the VM test library from Anatol, which is another Arch Linux developer, and Tiano Core, LashiDK2, I think it's called. So it's also only currently Linux only because we only really care about the EFR files under stash tests. So this is not OS X or Windows compatible, but it works. It's nice. It's nice, it's a nice library. It fulfills its goals, but it needs a lot of work before being stable. The end goal is to move SP serial away from shelling out to SP sign tools, and much more I use GoUFI instead. So that's sort of my short introduction to these tools to try to figure out how we can do better. Both of these, all this is public code, it's all open source. Also I've tried to do sort of a secure.dev website to try to document the relevant things I've learned while working on this, but that's a project that's really not well underway yet. If you're curious about this work or have questions, you have two of my emails here. You can also ping me on Foxpar on free note as well. So Q&A I guess. I hope this was enlightening and I hope people are interested in sort of making it secure, but easier for users. Thank you!
current tooling. So if you want to write, if you implementation details, and it's easy to make these commands. So all of these commands are PEM keys, and you do an EFI signature list with signature list, and the KEK needs to sign the better. We can do a lot better, actually. So that on the kernel EFI, we should say see that this quick demonstration how it could be that much structures from the secure boot, not from the UFI end goal is to have a Go library that supports provide some top-level API we can use to pick off I'm missing a nice top-level API, so nothing is of my short introduction to these tools to try to secure, but easier for users. Thank you!