[Just a Question] Feel free to close this after reading.

[willzyx-hub]

@valinet I tried SSDE and in fact it's working, however I also see that you don't really need to Own PK I just appending my .der to KEK/DB without owning the PK and SSDE still work... If so the Documentation about owning PK doesn't really apply anymore... Can you check if this really the case ? Thank you.

[powellnorma]

@willzyx-hub

Which of these .der did you add?

// self-signed root CA certificate
localhost-root-ca.der

// kernel mode certificate issued by self-signed root CA
localhost-km.der

// UEFI Platform Key certificate issued by self-signed root CA
localhost-pk.der

And did you add it to KEK, DB, or both?

[willzyx-hub]

I added my own der and added both to DB and KEK.

One der used for Kernel signing, UEFI Certificate, etc

[powellnorma]

@willzyx-hub Interesting, so if I understand correctly you signed the SiPolicy.p7b and ssde.sys with the same key, and that key is not trusted by an CA but instead just directly added to the UEFI DB+KEK.

Did you also add that key to "Trusted Root Certification Authorities" (aka Cert:\LocalMachine\Root) or another place? That seems to be required for Test Certificates.

[willzyx-hub]

@willzyx-hub Interesting, so if I understand correctly you signed the SiPolicy.p7b and ssde.sys with the same key, and that key is not trusted by an CA but instead just directly added to the UEFI DB+KEK.

Did you also add that key to "Trusted Root Certification Authorities" (aka Cert:\LocalMachine\Root) or another place? That seems to be required for Test Certificates.

Exactly but I'm not sure maybe it's coincidence to be happened on my Machine, Haven't tested it on other machine though, I did Import my certificate to Trusted Root Certificate Authority with Secure Boot Enabled, Testsigning clearly can't be enabled anyway

[powellnorma]

@willzyx-hub I tried this today, but am not able to append to DB/KEK via UEFI. Very similar to this. Might be Dell related, what company is your PC from?

I was able to add the certificate to the KEK+DB by first converting the .der to a .auth file (via cert-to-efi-sig-list and sign-efi-sig-list). Now it works, so I can confirm that one does not need to replace the PK! Thank you @willzyx-hub for reporting this

[willzyx-hub]

@willzyx-hub I tried this today, but am not able to append to DB/KEK via UEFI. Very similar to this. Might be Dell related, what company is your PC from?

I was able to add the certificate to the KEK+DB by first converting the .der to a .auth file (via cert-to-efi-sig-list and sign-efi-sig-list). Now it works, so I can confirm that one does not need to replace the PK! Thank you @willzyx-hub for reporting this

You're welcome, I would report more if I found more about simplifying the process of ssde

[willzyx-hub]

@willzyx-hub I tried this today, but am not able to append to DB/KEK via UEFI. Very similar to this. Might be Dell related, what company is your PC from?

I was able to add the certificate to the KEK+DB by first converting the .der to a .auth file (via cert-to-efi-sig-list and sign-efi-sig-list). Now it works, so I can confirm that one does not need to replace the PK! Thank you @willzyx-hub for reporting this

Hello I hope you're still active... I Don't know if this affect just me or majority people but Microsoft is publishing new way to load unsigned kernel drivers like this documented here https://learn.microsoft.com/en-us/windows/security/application-security/application-control/app-control-for-business/design/custom-kernel-signers

Also in certain release of Windows I have tried Microsoft seems to patch ssde so newer build may result in ssde not being trusted by CodeIntegrity but Idk this is not yet confirmed though.

[powellnorma]

but Microsoft is publishing new way to load unsigned kernel drivers like this documented here

Hm, I have just flown over it, but it sounds quite similar to what ssde is already doing? E.g. PK/KEK is root of trust, which signs a policy, which allows "kernel signers". Maybe it's not a new way, but they just documented it now officially? Or some details are different that I missed?

But I wonder if that (it now being official) means we don't anymore need hacky ways to enable CodeIntegrity-AllowConfigurablePolicy-CustomKernelSigners (via ssde_enable) + keep it enabled (via ssde.sys)?

Also in certain release of Windows I have tried Microsoft seems to patch ssde so newer build may result in ssde not being trusted by CodeIntegrity but Idk this is not yet confirmed though.

I am using Windows 11 Version 25H2 (OS build 26200.8390), and ssde is working fine. However, I had to disable "Code Integrity" and "Virtualization-based Security (VBS)", see #14 for more details.

If following the readme from ssde, we are using this policy, which simply allows all self-signed kernel signatures (and more). Maybe windows (Code Integrity / VBS) now prevents this, and instead would require us to define a "proper" "Kernel signer" that does not simply allow "everything". This is just a theory though.

But if they now have official docs for it, there should be a way, right? Maybe one could even ask the Microsoft support for help :D. I would not mention ssde though. If they ask, I would act like an IT person from a small company trying to follow their guide, e.g. present a (to them) legitimate use case.

If you find out more, pls let us know!

[willzyx-hub]

but Microsoft is publishing new way to load unsigned kernel drivers like this documented here

Hm, I have just flown over it, but it sounds quite similar to what ssde is already doing? E.g. PK/KEK is root of trust, which signs a policy, which allows "kernel signers". Maybe it's not a new way, but they just documented it now officially? Or some details are different that I missed?

But I wonder if that (it now being official) means we don't anymore need hacky ways to enable CodeIntegrity-AllowConfigurablePolicy-CustomKernelSigners (via ssde_enable) + keep it enabled (via ssde.sys)?

Also in certain release of Windows I have tried Microsoft seems to patch ssde so newer build may result in ssde not being trusted by CodeIntegrity but Idk this is not yet confirmed though.

I am using Windows 11 Version 25H2 (OS build 26200.8390), and ssde is working fine. However, I had to disable "Code Integrity" and "Virtualization-based Security (VBS)", see #14 for more details.

If following the readme from ssde, we are using this policy, which simply allows all self-signed kernel signatures (and more). Maybe windows (Code Integrity / VBS) now prevents this, and instead would require us to define a "proper" "Kernel signer" that does not simply allow "everything". This is just a theory though.

But if they now have official docs for it, there should be a way, right? Maybe one could even ask the Microsoft support for help :D. I would not mention ssde though. If they ask, I would act like an IT person from a small company trying to follow their guide, e.g. present a (to them) legitimate use case.

If you find out more, pls let us know!

Strange though, let me try SSDE in Very latest Windows 27H2 build Via the Canary Channel (Build 29200.xxx) very likely 27H2 that will be released in 2027

[willzyx-hub]

but Microsoft is publishing new way to load unsigned kernel drivers like this documented here

Hm, I have just flown over it, but it sounds quite similar to what ssde is already doing? E.g. PK/KEK is root of trust, which signs a policy, which allows "kernel signers". Maybe it's not a new way, but they just documented it now officially? Or some details are different that I missed?

But I wonder if that (it now being official) means we don't anymore need hacky ways to enable CodeIntegrity-AllowConfigurablePolicy-CustomKernelSigners (via ssde_enable) + keep it enabled (via ssde.sys)?

Also in certain release of Windows I have tried Microsoft seems to patch ssde so newer build may result in ssde not being trusted by CodeIntegrity but Idk this is not yet confirmed though.

I am using Windows 11 Version 25H2 (OS build 26200.8390), and ssde is working fine. However, I had to disable "Code Integrity" and "Virtualization-based Security (VBS)", see #14 for more details.

If following the readme from ssde, we are using this policy, which simply allows all self-signed kernel signatures (and more). Maybe windows (Code Integrity / VBS) now prevents this, and instead would require us to define a "proper" "Kernel signer" that does not simply allow "everything". This is just a theory though.

But if they now have official docs for it, there should be a way, right? Maybe one could even ask the Microsoft support for help :D. I would not mention ssde though. If they ask, I would act like an IT person from a small company trying to follow their guide, e.g. present a (to them) legitimate use case.

If you find out more, pls let us know!

Oh my god you won't believe this, Windows 27H2 from that Canary channel load my drivers without ssde... Ig that official documentation really work...

[powellnorma]

Wow, nice to hear! I think they are moving in the right direction. Did you get it running with Code Integrity and VBS enabled? I guess you are using this policy ?

[willzyx-hub]

Wow, nice to hear! I think they are moving in the right direction. Did you get it running with Code Integrity and VBS enabled? I guess you are using this policy ?

Unfortunately I don't know what is wrong but it does NOT work with VBS Enabled it does work with CodeIntegrity though let me Ask Microsoft and see what they said. I will post my thread in MSDN soon

[willzyx-hub]

Wow, nice to hear! I think they are moving in the right direction. Did you get it running with Code Integrity and VBS enabled? I guess you are using this policy ?

Here I posted on this
https://learn.microsoft.com/en-us/answers/questions/5913942/hvci-blocks-custom-kernel-signer-(cks)

Also worth noting that new Microsoft Official CKS add additional key on the Registry
HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\CI\Protected\CustomKernelSignerLockedEnabled

When Enabled it set to 1

[willzyx-hub]

Wow, nice to hear! I think they are moving in the right direction. Did you get it running with Code Integrity and VBS enabled? I guess you are using this policy ?

Unfortunately that Thread Advisor gave unhelpful response so any idea why HVCI block it ?

[powellnorma]

No, unfortunately not. But maybe the forum is not the best place to ask, I see at https://developer.microsoft.com/en-us/windows/support/?tabs=Contact-us a specific contact option for "Driver Development and Testing/Certification", maybe they give better answers. Please report back if you find out anything!