Hello,
I need a kernel driver operable in the SecureBoot environment.
The driver is properly signed by a DigiCert EV certificate and works perfectly on any Windows 7/8/10 without SecureBoot. Looks like SecureBoot is the only reason preventing the driver from running.
https://blogs.msdn.microsoft.com/windows_hardware_certification/2013/12/03/microsoft-uefi-ca-signing-policy-updates/
states that
?3. Microsoft UEFI CA signs only those products which are for public availability ?.. If a product is specific to a particular OEM or Organization and is not available externally then we suggest you sign it with your private key and add the certificate to SecureBoot database.
?
The driver is not intended to be available publicly principally so I?m under impression that there are no reasons to ask SysDev for the driver signing and I actually can solve the problem myself.
Unfortunately I was not able to find any strict instructions for how to achieve that.
Are there any strict instruction for how to do that, i.e. what and how to add into ?the certificate to SecureBoot database?. Any samples would be fine.
Looks like I have missed something implicitly evident in spite of spent already a week
Could you navigate me please.
Thank you for your time,
Serge
xxxxx@mail.ru wrote:
I need a kernel driver operable in the SecureBoot environment.
The driver is properly signed by a DigiCert EV certificate and works perfectly on any Windows 7/8/10 without SecureBoot. Looks like SecureBoot is the only reason preventing the driver from running.
https://blogs.msdn.microsoft.com/windows_hardware_certification/2013/12/03/microsoft-uefi-ca-signing-policy-updates/
states that
?3. Microsoft UEFI CA signs only those products which are for public availability ?.. If a product is specific to a particular OEM or Organization and is not available externally then we suggest you sign it with your private key and add the certificate to SecureBoot database.
?
The driver is not intended to be available publicly principally so I?m under impression that there are no reasons to ask SysDev for the driver signing and I actually can solve the problem myself.
No. That page is talking about UEFI binaries – tools and drivers that
are used during the boot process. None of that applies once the Windows
kernel is running.
As far as I know, there is no exception path for Windows drivers in the
secure boot environment. If these are drivers for internal use only,
why don’t you just instruct your users to turn off “secure boot”?
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
> As far as I know, there is no exception path for Windows drivers in the secure
boot environment. If these are drivers for internal use only, why don’t you
just instruct your users to turn off “secure boot”?
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Isn’t that throwing out the baby with the bathwater?
* Bob
Unless your willing to submit to Microsoft to have it cross signed by them. You’re better off disabling Secure Boot. There is a lengthy process to be compatible with it. I believe this page outlines the requirements for loading a driver on a machine with Secure Boot pretty well:
https://msdn.microsoft.com/en-us/windows/hardware/drivers/install/kernel-mode-code-signing-policy--windows-vista-and-later-
The WHQL cross signing needs done as Secure Boot detects that certificate. Not the EV certificate. To elaborate EFI has a set of approved Secure Boot certificates.
For what it is worth: in order to “solve the problem yourself” since “the driver is not intended to be available publicly”. You’d have to modify the EFI on your hardware and add a certificate to the approved Secure Boot store then sign your driver with that certificate. I’ve never achieved this. I expect it to not be easily achieved as doing so would defeat the purpose of having this protection in place to begin with.
Thank you, Tim
No. That page is talking about UEFI binaries – tools and drivers that are used during the boot process. None of that applies once the Windows kernel is running.
Nevertheless the fact I saw myself is StartService for the driver start returns a not-signed error with SecureBoot on. Switching SecureBoot off (in BIOS) solves the problem.
As far as I know, there is no exception path for Windows drivers in the secure boot environment. If these are drivers for internal use only, why don’t you just instruct your users to turn off “secure boot”?
The internal use means the driver is not available publicly, but it?s a part of commercial corporative product. Every customer has 100+ (as minimum) installations and we definitely have more than one customer. Some installations are made on 1000+ workplaces at once. Not all of them are just Windows10 fortunately so far.
It would definitely not be too good to recommend customers? IT depts. to switch SecureBoot off. It would affect the product reputation negatively.
Yours,
Serge
Thank you, Johnny
Unless your willing to submit to Microsoft to have it cross signed by them.
As I tried to explain previously switching SecureBoot off is not too good solution for me.
Submitting the driver to Microsoft is not too good as well.
We may have some individual the driver builds for specific environments and may need to update the driver promptly. Submitting to Micorsoft may just slow the process down unexpectedly. So I?m looking for an independent solution first of all.
I still believe it?s possible.
You’d have to modify the EFI on your hardware and add a certificate to the approved Secure Boot store then sign your driver with that certificate. I’ve never achieved this. I expect it to not be easily achieved as doing so would defeat the purpose of having this protection in place to begin with.
Honestly that is exactly what I?m looking for, in spite of ?it would defeat the purpose??
There is even a similar recommendation from Intel
https://software.intel.com/en-us/node/606797
I just was not able to achieve something similar myself. Already spent a significant time without any luck so far.
Unfortunately the process can?t be diagnosed on-the-road, for now I just have fails while trying. But I read a lot of UEFI related articles and nearly sure it?s possible.
There is a sense to expect that signing (or double signing) the driver with a proper key and adding the related certificate into the UEFI?s DB database should be enough.
As far as I was able to realize the DB certificates chain is not verified up to the ?root? and probably not verified at all. So if SecureBoot verifies the driver sign on the ?first level? positively it should be enough to confirm the driver is signed correctly.
Unfortunately I?ve still been missing a (probably evident) detail causing my fails.
Thank you,
Serge
As was revealed here a couple of weeks ago, in order to submit a driver
for attestation signing your company will be required to grant MS the
“worldwide, nonexclusive, perpetual, irrevocable, royalty-free, fully
paid up rights to reproduce, distribute, use and import” your driver. I
was wondering what your company thinks of that, Serge.
> in order to submit a driver for attestation signing your company will be required to grant MS?
It?s theoretically possible but not too welcomed.
Formally the entire product and all its parts are subjects of the trade secret.
So generally if there is need to disclose (only) separate component to a third party I need to get a written permission from our law dept.
Sometimes, when the need arises, I?m able to convince the dept that the to-disclose-component does not include any real secrets and may be disclosed, so an individual permission is given finally. Sometimes the law dept declines my requests. It depends on circumstances and has to be settled individually.
So thank you for remaindering me, honestly I missed initially the need ?to grant MS?.
I suspect that will cause a nano-battle with the law dept.
All in all if, I have no other options, the driver must work unconditionally, I will have to convince the law dept more intensively. Granting external permissions formally would require a dedicated written agreement with MS. Undoubtedly I will never have that?.
The only meaningful argument for the law dept is whether we do need Windows 10 1607+ support at all or not?. Or I will have to escalate the problem to the business decision maker and wait for the ?result?.
That?s why first of all I?m looking for a way to stably ?conquer? 1607+'s SecureBoot without a third party involved. That’s why I could (temporary at least) admit a kind of the installation inconveniences (redundant reboots, manual certificate insertions etc)
Thank you,
Serge
xxxxx@mail.ru wrote:
> No. That page is talking about UEFI binaries – tools and drivers that are used during the boot process. None of that applies once the Windows kernel is running.
Nevertheless the fact I saw myself is StartService for the driver start returns a not-signed error with SecureBoot on. Switching SecureBoot off (in BIOS) solves the problem.
Yes, clearly SecureBoot affects the behavior of Windows driver signature
validation. However, the page you referred to was specifically
discussing UEFI binaries that are executed before an operating system
loads. There is a certificate database you can tweak to allow
self-signed UEFI binaries to run, but that doesn’t do anything for Windows.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
The Intel website you mention may or may not give you success. I’m not confident whether Windows pulls from the EFI cert DB or if it detects that Secure Boot is enabled and applies has its own cert list it checks for on the loading drivers. If I had to guess I’d say the latter. But, I could be wrong. If you do go down this route I’d love to hear your results!
/rolls eyes
Just submit it for attestation signing. At best, it takes 30 minutes. At worst, a couple of hours.
I don’t see what the problem is. There’s no testing involved, it’s not terribly inconvenient, and it’s free.
Just sign it.
Peter
OSR
@OSRDrivers
Hi Tim.
There is a certificate database you can tweak to allow self-signed UEFI binaries to run, but that doesn’t do anything for Windows.
Thank you, I have already realized that UEFI binaries are not involved and I will have to sign the drivers as drivers (not UEFI related entities).
So the certificates in the UEFI database are not used for the driver signature validation at all?
So https://software.intel.com/en-us/node/606797 means a genuine UEFI binary to make it operable?
Does that mean that Win10 1607+ driver validation is based on another (OS embedded) certificate instance to validate drivers with?
I would be better to realize how it actually works if possible.
How do you think where the validation happens actually.
As the boot drivers are not validated (always enabled), the validation should be somewhere in the user mode. Right? If it?s in the kernel the boot drivers could be validate as well.
Maybe there is a way to bypass the validation anyhow, by a special driver start procedure when a kernel is involved only (int 2E or so). Out of curiosity
Attn: Johnny Shaw I will report if I have an audible result.
Thank you,
Serge
Hi Peter,
I don’t see what the problem is. There’s no testing involved, it’s not terribly inconvenient, and it’s free.
As I tried to explain above.
in order to submit a driver for attestation signing your company will be required to grant MS the “worldwide, nonexclusive, perpetual, irrevocable, royalty-free, fully paid up rights to reproduce, distribute, use and import” your driver.
But the driver is NOT available publicly by definition.
I?m not sure I will be able to get the required permissions from our law department easily.
If the driver were completely “mine” I would submit the driver for the attestation right away
Thank you,
Serge
This non-issue was discussed earlier.* Consult your lawyers* of course, but
the general and completely unprofessional and unqualified and vastly
ignorant consensus here was that this is a non issue unless you proceed
from getting your driver signed to publishing your driver on msft update,
at which point that clause simply excludes MSFT from any licensing fees you
might want to charge them for having access to your driver binaries. *Consult
your lawyers.*
Mark Roddy
On Mon, Apr 17, 2017 at 9:22 AM, wrote:
> Hi Peter,
>
> >I don’t see what the problem is. There’s no testing involved, it’s not
> terribly inconvenient, and it’s free.
>
> As I tried to explain above.
> ------
> in order to submit a driver for attestation signing your company will be
> required to grant MS the “worldwide, nonexclusive, perpetual, irrevocable,
> royalty-free, fully paid up rights to reproduce, distribute, use and
> import” your driver.
> ------
>
> But the driver is NOT available publicly by definition.
> I?m not sure I will be able to get the required permissions from our law
> department easily.
> If the driver were completely “mine” I would submit the driver for the
> attestation right away
>
> Thank you,
> Serge
>
>
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list online at: http:> showlists.cfm?list=ntdev>
>
> MONTHLY seminars on crash dump analysis, WDF, Windows internals and
> software drivers!
> Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at <
> http://www.osronline.com/page.cfm?name=ListServer>
></http:></http:>
The page:
https://msdn.microsoft.com/en-us/windows/compatibility/secured-boot-signing-requirements-for-kernel-mode-drivers
seems directly relevant to your problem.
Note the first sentence under ‘Manifestation’; it says that kernel mode-drivers must be signed by a trusted CA in secure mode.
Unfortunately, it doesn’t state explicitly *which* ‘Trusted’ certificate store the corresponding certificate must be placed, nor does it guarantee that such a signature is sufficient. It may be worth experimenting, though.
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:bounce-629427-
xxxxx@lists.osr.com] On Behalf Of xxxxx@mail.ru
Sent: 13 April 2017 17:16
To: Windows System Software Devs Interest List
Subject: [ntdev] SecureBoot/Driver signing for corporate usage
Hello,
I need a kernel driver operable in the SecureBoot environment.
The driver is properly signed by a DigiCert EV certificate and works
perfectly on any Windows 7/8/10 without SecureBoot. Looks like
SecureBoot is the only reason preventing the driver from running.
https://blogs.msdn.microsoft.com/windows_hardware_certification/2013/12
/03/microsoft-uefi-ca-signing-policy-updates/
states that
?3. Microsoft UEFI CA signs only those products which are for public
availability ?.. If a product is specific to a particular OEM or
Organization and is not available externally then we suggest you sign
it with your private key and add the certificate to SecureBoot
database.
?
The driver is not intended to be available publicly principally so I?m
under impression that there are no reasons to ask SysDev for the driver
signing and I actually can solve the problem myself.
Unfortunately I was not able to find any strict instructions for how to
achieve that.
Are there any strict instruction for how to do that, i.e. what and how
to add into ?the certificate to SecureBoot database?. Any samples would
be fine.
Looks like I have missed something implicitly evident in spite of spent
already a week Could you navigate me please.
Thank you for your time,
Serge
NTDEV is sponsored by OSR
Visit the list online at:
http:
>
> MONTHLY seminars on crash dump analysis, WDF, Windows internals and
> software drivers!
> Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at
> http:</http:></http:></http:>