Setup on Dell XPS 15 7590 (generalize for your use case)

[valinet]

IMPORTANT

This laptop loses the PK EVERY time one changes any setting in the UEFI program (which is really annoying). A quick fix is this:

1. After changing the setting in the UEFI, reboot into Windows, which will have Secure Boot turned off:

Confirm-SecureBootUEFI // <- will return False
sc delete ssde
uuidgen --random > GUID.txt
openssl pkcs12 -in PK.pfx -nocerts -out PK.key
openssl pkcs12 -in PK.pfx -clcerts -nokeys -out PK.crt
cert-to-efi-sig-list -g "$(< GUID.txt)" PK.crt PK.unsigned.esl
sign-efi-sig-list -k PK.key -c PK.crt PK PK.unsigned.esl PK.esl
Set-SecureBootUEFI -Name PK -SignedFilePath PK.esl -ContentFilePath PK.unsigned.esl -Time $(Get-Date -Format "o")

If everything goes well, final output from PowerShell should be something like this:

Name Bytes              Attributes
---- -----              ----------
PK   {230, 7, 9, 14...} NON VOLATILE...

2. Run ssde_enable.exe. Let it reboot in Setup mode.
3. Windows will finally reboot onto the desktop. Confirm-SecureBoot will return True. Register back and start ssde:

sc create ssde binpath=%windir%\system32\drivers\ssde.sys type=kernel start=boot error=normal
sc start ssde

Original write up below:

This is the way I go about setting this up on my XPS 15 7590. Maybe you can use this as general guidance and customize according to your own configuration. The way to set the PK in the UEFI of your machine varies between BIOS brands, so a generic way is hard to list, but you can adapt this guide to suit your needs.

First off, I have a ventoy pen drive where I keep KeyTool.efi (KeyTool is part of the efitools package; the link takes you there; download the deb file, unpack it and find the UEFI application under data.tar\.\usr\lib\efitools\x86_64-linux-gnu\). I highly recommend doing this as it is very convenient.

Steps:

• Prepare an auth file for KeyTool based on your PK.pfx (localhost-pk.pfx) that you have from following this. I also assume that you have the certificates installed into your system root after following the linked tutorial. Under a Linux distro (you can use WSL), run this (on Ubuntu, install efitools package using sudo apt install efitools):

uuidgen --random > GUID.txt
openssl pkcs12 -in PK.pfx -nocerts -out PK.key
openssl pkcs12 -in PK.pfx -clcerts -nokeys -out PK.crt
cert-to-efi-sig-list -g "$(< GUID.txt)" PK.crt PK.esl
sign-efi-sig-list -g "$(< GUID.txt)" -k PK.key -c PK.crt PK PK.esl PK.auth

Credits: https://wiki.archlinux.org/title/Unified_Extensible_Firmware_Interface/Secure_Boot and https://www.ibm.com/docs/en/arl/9.7?topic=certification-extracting-certificate-keys-from-pfx-file

The commands will ask for the PFX password, which you have set when you exported it, and also for a passphrase for the CRT file, which I recommend setting the same as the password for the PFX file.

• Go into the BIOS (F2 at boot). Go to Secure Boot - Expert Key Management, choose PK and click Delete.
• Go to Secure Boot in BIOS and enable it. Disregard the warning about the system not having a PK, you will install it next.
• Boot the ventoy pen drive and from there KeyTool.efi. In there, enroll the PK using the auth file you have generated above. When done, Ctrl+Alt+Del to reboot the machine.
• Boot into the BIOS and make sure your settings stuck: you have Secure Boot enabled. Optionally, verify with KeyTool.efi again that the PK was accepted.
• Boot into Windows. Open PowerShell as admin and make sure Secure Boot is indeed enabled: Confirm-SecureBootUEFI should return True.
• Install the SiPolicy.p7b file (open an administrative command prompt window in the folder where you have the policy file):

mountvol x: /s
copy SiPolicy.p7b x:\EFI\Microsoft\Boot\SiPolicy.p7b
shutdown /t 00 /r

This mounts the EFI partition at X:, installs the policy file and reboots the system.

• Execute ssde_enable.exe. The system will reboot in Setup mode, where the program finishes its job.
• When rebooted, make sure the system is "licensed" to use the feature: open Registry Editor and go to HKEY_LOCAL_MACHINE\system_c\ControlSet001\Control\CI\Protected and check if the Licensed entry is set to 1. If it is, it's all good, if not, try again with ssde_enable.exe or reboot into a WinPE environment (you can throw in a Windows ISO on the ventoy pendrive and boot that), press Shift+F10 to get to a command prompt; in there, type regedit, then select the HKLM key on the left, File - Load Hive and locate the HKLM\System datastore from you Windows install at letter:\Windows\System32\config\System and load that. Try to change the Licensed entry from there and reboot and see if it stuck.
• When you are confident you have Licensed set to 1 and that Secure Boot is enabled (Confirm-SecureBootUEFI) and that the policy file is installed on the EFI partition, then you can move on with installing the ssde.sys driver which should work just fine now and load easily:

1. Compile the ssde.sys driver or download the pre-compiled one here.
2. Sign the downloaded driver using signtool.exe. This either comes with the Windows SDK, either use these instructions to only extract it and install it alone from the SDK: signtool sign /fd sha256 /a /ac .\localhost-root-ca.der /f .\localhost-km.pfx /p password /tr http://sha256timestamp.ws.symantec.com/sha256/timestamp ssde.sys. Replace "password" with the password you have set when you exported the PFX file.
3. Now, copy the signed ssde.sys into C:\Windows\System32\drivers.
4. Install the driver: sc create ssde binpath=%windir%\system32\drivers\ssde.sys type=kernel start=boot error=normal.
5. Start the driver: sc start ssde.

If everything went fine and you did it correctly, the driver will show its status as running:

SERVICE_NAME: ssde
        TYPE               : 1  KERNEL_DRIVER
        STATE              : 4  RUNNING
                                (STOPPABLE, NOT_PAUSABLE, IGNORES_SHUTDOWN)
        WIN32_EXIT_CODE    : 0  (0x0)
        SERVICE_EXIT_CODE  : 0  (0x0)
        CHECKPOINT         : 0x0
        WAIT_HINT          : 0x0

If you did something wrong, you will get the famous driver signature error when you will query the status. Make sure to check again all the steps mentioned above. Again, from what I have seen, the conditions for drivers to load successfully and not throw the signature error are:

• Have the main certificate that you have generated installed into the trusted root certificate store of the machine (localhost-root-ca).
• Have the PK certificate installed as the PK of the machine, a certificate that's a descendant (direct child) of the main certificate you have in the trusted root of the machine (localhost-pk).
• Have any driver that you plan on loading be signed with a certificate that's a descendant (direct child) of the main certificate you have in the trusted root of the machine (localhost-km).
• Have Secure Boot enabled (execute Confirm-SecureBootUEFI in PowerShell to confirm).
• Have a proper policy file (SiPolicy.p7b) copied at the proper location (\EFI\Microsoft\Boot\SiPolicy.p7b) on the EFI partition.
• Have the system be licensed for this functionality: HKEY_LOCAL_MACHINE\system_c\ControlSet001\Control\CI\Protected\Licensed is 1. To maintain this state (the value is reset on every reboot), after we initially trick Windows into having it set to 1 (using ssde_enable.exe or the WinPE trick I described above), we have to load the ssde driver in the system (and have it load on every boot); ssde is a very simple driver which monitors the kernel for changes to the licensed status of this feature and reverts it to being licensed when something in the system changes it (because, with the SKUs of Windows we have, we are not really licensed by Microsoft for this - only the Chinese Government is, so as to spy on its people). This driver is a sure way to have the system always be licensed for this functionality.

To check the status of the driver:

• Execute ssde_info.exe which reports the number of times the licensed status for this feature has been reverted, plus some other info.
• Execute ssde_query.exe to query the licensed status for this feature.

Also note that the XPS 15 seems to forget this custom PK if we mess with settings in the BIOS after we set it up, so after each change, all I do is boot into KeyTool.efi, renroll the PK and reenable Secure Boot in the BIOS, and it seems wot work and Windows continues to load my own signed drivers.

Hope this helps shade more light on how to run this.

[ghost]

@valinet
If I have all certs generated, can I use any of them on other PC as well?

The guide is awesome, thank you so much.
Only missing thing is direct link to KeyTool.efi

[valinet]

The guide is awesome, thank you so much.

You’re welcome, kudos to the original authors that first discovered and published info about this as well. We should really thank them, this approach is great compared to the alternatives, even official ones.

If I have all certs generated, can I use any of them on other PC as well?

Yeah, of course, why not. I do the same thing, I have the same certs for both my laptop and my desktop. That way, I sign the drivers once, on whichever machine I happen to be developing on, and then I load them directly on both machines. I mean, I don’t see why, for personal use, you’d have separate sets.

Only missing thing is direct link to KeyTool.efi

There is a link to a deb file which is just an archive, easily openable with 7zip etc, and in there you find KeyTool.efi. I chose to link to the official package rather than reupload it, idk, that was my mindset at the moment.

[ghost]

If I understood correctly, on other PC I can jump right into the part which starts with dots, right? @valinet

Go into the BIOS (F2 at boot). Go to Secure Boot - Expert Key Management, choose PK and click Delete.

There are still many traps in the process like:

1. remembering to install .pfx certs to personal certificate storage and .der certs to Trusted Root Certification Authority
2. installing Windows 7 SDK to use makecert (or powershell)
3. using ssde instead of EnableCKS to avoid bootlop
4. generating proper .cat files
5. signing drivers with both proper .der and .pfx certs

Efitools_1.9.2-1ubuntu3_amd64.deb contains *.tar.zst files which can not be opened by 7z.

Ventoy author is a genius too.