Question about driver signing

Hi,

As many of you have already experienced, we are having a really hard time figuring out what to do to release a single driver binary for all Windows versions (XP to Windows 10 - until 1607 build which requires HLK)

What I previously read was dual signing a driver with the command below would make it compatible with Windows Vista to Windows 10 (included).

signtool.exe sign /t http://timestamp.digicert.com /sha1 XXXSHA1THUMBPRINT driver.sys
signtool.exe sign /tr http://timestamp.digicert.com /td sha256 /fd sha256 /as /sha1 XXXSHA256THUMBPRINT driver.sys

The resulting driver has dual signatures but I am still getting the error “Windows requires a digitally signed driver” on a Windows 7, Windows 8.1 and Windows 10 box.

When I sign the binary using DigiCert’s utility by checking “Kernel Mode Code Signing” checkbox, it is signed with a single SHA1 signature and it works as expected in Win 7,8,10.

I understand that Windows 10 - 1607 requires us to pass HLK but what is wrong with the dual signing process? Am I missing something related to date constraints?

As a side note, Microsoft Driver Signing Policy states that SHA2 signature is only required on Windows 10, version 1607+ with Secure Boot on and SHA1 is required all previous versions. See it below:

https://docs.microsoft.com/en-us/windows-hardware/drivers/install/kernel-mode-code-signing-policy--windows-vista-and-later-#signing-requirements-by-version

To summarize, I am totally lost and can not figure out how to proceed.

Any help is appreciated.

Do not use sha1 , just sha256 only.


God is a boy.

在 2018年6月11日,06:46,xxxxx@gmail.com 写道:
>
> Hi,
>
> As many of you have already experienced, we are having a really hard time figuring out what to do to release a single driver binary for all Windows versions (XP to Windows 10 - until 1607 build which requires HLK)
>
> What I previously read was dual signing a driver with the command below would make it compatible with Windows Vista to Windows 10 (included).
>
> signtool.exe sign /t http://timestamp.digicert.com /sha1 XXXSHA1THUMBPRINT driver.sys
> signtool.exe sign /tr http://timestamp.digicert.com /td sha256 /fd sha256 /as /sha1 XXXSHA256THUMBPRINT driver.sys
>
> The resulting driver has dual signatures but I am still getting the error “Windows requires a digitally signed driver” on a Windows 7, Windows 8.1 and Windows 10 box.
>
> When I sign the binary using DigiCert’s utility by checking “Kernel Mode Code Signing” checkbox, it is signed with a single SHA1 signature and it works as expected in Win 7,8,10.
>
> I understand that Windows 10 - 1607 requires us to pass HLK but what is wrong with the dual signing process? Am I missing something related to date constraints?
>
> As a side note, Microsoft Driver Signing Policy states that SHA2 signature is only required on Windows 10, version 1607+ with Secure Boot on and SHA1 is required all previous versions. See it below:
>
> https://docs.microsoft.com/en-us/windows-hardware/drivers/install/kernel-mode-code-signing-policy--windows-vista-and-later-#signing-requirements-by-version
>
> To summarize, I am totally lost and can not figure out how to proceed.
>
> Any help is appreciated.
>
> —
> 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:>

> What I previously read was dual signing a driver with the command below would make it

compatible with Windows Vista to Windows 10 (included).

signtool.exe sign /t http://timestamp.digicert.com /sha1 XXXSHA1THUMBPRINT driver.sys
signtool.exe sign /tr http://timestamp.digicert.com /td sha256 /fd sha256 /as /sha1 XXXSHA256THUMBPRINT driver.sys

The primary thing missing from these command lines is the kernel-mode
signing cross-certificate parameters.

That’s the “Downloading the Code Signing Cross-Certificate” and
/AC-involved command lines shown in “Using Your Standard Kernel-Mode
Code Signing Certificate” sections in DigiCert’s walk through:
https://www.digicert.com/code-signing/driver-signing-in-windows-using-signtool.htm#download_cross_certificate

The command lines you’ve posted here are correct, but are appropriate
for code signing a .DLL or .EXE file and not a kernel-mode driver.
Note you can and probably should continue to use the /SHA1 THUMBPRINT
certificate selection instead of the /A auto-selection shown in the
DigiCert example.

You will need to continue providing an SHA1 code signing certificate
(in addition to your SHA256 certificate) so long as you continue to
target the pre-Windows 7 SP1 platforms. Or alternatively, you would
need to do the appropriate WLK testing (not HCK or HLK) and submission
to have Microsoft sign them using Microsoft’s SHA1 certificate to
satisfy those platforms.

As a side note, Microsoft Driver Signing Policy states that SHA2 signature
is only required on Windows 10, version 1607+ with Secure Boot on and SHA1
is required all previous versions.

That table seems to be describing “supported” rather than “required”,
else “SHA1 or SHA2” in the 1607+ Secure Boot column doesn’t make a lot
of sense. Seems like all columns should say “SHA1 or SHA2” at this
point. Using an SHA1 certificate is certainly not recommended or a
best practice any more.

(Note if you have an SHA1 certificate issues prior to July 2015,
Windows 10 is intentionally grandfathering those signatures. I’m not
aware of what Windows 10 would do with an SHA1-only signed driver
using a certificate issued more recently. But its being worded as
though they may become unrecognized in the future, if not already.
https://docs.microsoft.com/en-us/windows-hardware/drivers/dashboard/get-a-code-signing-certificate)

That document is also unclear in asserting “Starting with Windows 10,
version 1607, Windows will not load any new kernel mode drivers which
are not signed by the Dev Portal.” That statement means “when Secure
Boot is enabled.” So as a driver publisher, “to not ignore any
segment of Windows 10 customers” you need to have a Microsoft-signed
driver for Windows 10 1607 and later. But that’s still different than
saying “a non-Microsoft signed driver won’t run on Windows 10 1607 and
later”, which isn’t true.

The document’s statement of “Windows Server does not load attestation
signed drivers” is also not true. (Yet.) Current shipping Windows
Server 2016 versions continue to load attested signed drivers.

Alan Adams
Client for Open Enterprise Server
Micro Focus
xxxxx@microfocus.com

Post of the week, right there.

Thank you, Mr. Adams. That is about the most clear and definitive statement that I’ve seen anybody author on this forum about today’s state of driver signing.

The only thing I can think to add is that “Assuming you need to attestation sign your drivers, you’ll need an account on the developer dashboard. To get this account, you will need to register an EV Certificate. You may also, optionally, register a non-EV certificate. You may use either of these certificates to sign submissions for Attestation Signing.”

Peter
OSR
@OSRDrivers

Alan Adams wrote:
> The document’s statement of “Windows Server does not load attestation
> signed drivers” is also not true. (Yet.) Current shipping Windows
> Server 2016 versions continue to load attested signed drivers.

Allow me to ask a follow-up question. The Server systems are not on my
radar, so I haven’t tried them.

Are you saying that an attestation-signed driver package still installs
on Server 2016? I have no trouble believing that an attestation-signed
driver binary will load once installed, because I don’t think there’s
any way for the kernel to tell the difference. But I had assumed that
Device Manager would refuse to install an attestation-signed driver
package. Am I wrong?


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

Attestation signed drivers now install, and have ALWAYS installed, on Windows Server systems.

And I have been told there is no specific plan to change this behavior in the foreseeable future.

Of course, just like the mandate requiring server drivers to be HCK tested changed (thank heavens), so can the decision that they do NOT need to be HCK tested change (heaven forbid).

Peter
OSR
@OSRDrivers

@Alan Thanks a lot for your help. That was truly enlightening!

@Tim I tested attestation signed driver on a Windows Server 2016 alongside Win 10 and it worked perfectly. After a long time trying to setup the lab environment described in the post below, I decided to give a try to attestation signing and on my 8th try, I managed to get my driver signed by Microsoft.

http://blog.morphisec.com/windows-drivers-and-digital-signatures

As a side note, attestation signing is not as scary as I thought in the beginning (maybe because I learned all aspects of it after 7 tries). If you pay attention to the items below, it generally takes 10 minutes.

Attestation signing process steps:

  1. If somehow you can not sign into Hardware Dev Center (which was the case in my scenario and took me 3 days to reach Microsoft support + 2 hours phone call) just go create a new Azure AD Account in whatever subscription. This is not important since they will identify you by requiring you to sign a file and upload it to the portal.

  2. Your package needs to have 3 files: SYS, INF, PDB. CAT file is not required and ignored by the portal.

  3. Make sure you create a valid INF file and verify it using INFVERIF.exe. You can find the template I used below:
    https://drive.google.com/file/d/1ysnsGa7w5F7w-YuCQD03zz8iyhVNGepn/view?usp=sharing

  4. If you are in a different timezone, INF file DriverVer value is automatically set to SYS file’s creation time and Portal gives an error such as “driverver set to a date in the future”. Adjust your timezone and build your driver again.

  5. Create a folder in any location and name it let’s say “MyPackage”. Create another sub folder inside it and name it “DriverPackage1”. Copy aforementioned 3 files inside it.

  6. Open IZArc and select File > New. Type “MyPackage.cab” into File name dialog. This will create a cab file and “Add Files” dialog will appear. This dialog is a bit misleading. It won’t open a CAB file, it will create it instead.

  7. Select “MyPackage” folder and you are done. IZArc creates the CAB file for you. Make sure that CAB file only has “DriverPackage1” folder in its root. Portal will fail if it encounters any other file in the root folder!

  8. Sign this CAB file using your SHA256 signature. Do *not* use SHA1 or dual signature else you will wait another 10-15 minutes :slight_smile:

  9. Portal will ask you which OS versions to sign for, please make sure you select the appropriate OS versions for your driver. Note that there are 32, 64 and ARM64 versions. So if you are uploading a 32 bit, only select 32 bit OS versions.

  10. If you are lucky, you will get a notification email in 10 minutes with the signed package.

Enjoy your attestation signed driver.

Hope it helps…

Some good points. Sorry to hear the learning experience was so painful.

There are a couple of small details that could use correcting, however:

Actually, you do NOT need to have the PDB. And I don’t recommend you include it. I have never, not once, provided a PDB for a driver package to be signed.

This is what the DOCs say, but it’s not how the dashboard actually works. I recommend (and do myself) select every available OS target. I select 64-bit for 32-bit drivers, I select 32-bit for 64-bit drivers. Just check every box and be done with it.

I’m not sure what that GETS you, but it works for sure.

I’ve written about this extensively. See here: https:</https:>

Peter
OSR
@OSRDrivers

Thanks for the confirmation on what you learned from Microsoft
regarding the attested signing and Windows Server 2016. Pretty sure
that provides the confirmation Tim Roberts was looking for.

Actually, you do NOT need to have the PDB. And I don’t recommend you include it.
I have never, not once, provided a PDB for a driver package to be signed.

I’ll assume that what he’s referring to is the fact that attested
signing submissions now STOP and PROMPT you with a declaration that
“PDB files were not found in your submission, PDB files should be
included and in the future will be required” or something along those
lines. That’s been happening at least since February 2018, and has
not yet become “required” to my knowledge. There was an earlier post
here in the list regarding the “where” the .PDB files needed to be
located within the .CAB. (Answer: Within the same directory as the
driver binary files themselves.)

Portal will ask you which OS versions to sign for, please make sure you
select the appropriate OS versions for your driver. Note that there are 32, 64
and ARM64 versions. So if you are uploading a 32 bit, only select 32 bit OS
versions.

At least in our case, selecting the recently-offered ARM platform will
trigger requirements that we don’t meet, and must remain de-selected.
So “platforms your submission doesn’t actually contain” isn’t benign
in that case, at least.

As one might already suspect, if you select only the lowest-version
Windows 10 platform (1507), you can expect your signed driver to be
valid for all the later Windows 10 desktop platforms too. Same as if
you had performed attested signing back when 1507 was the only
platform in existence, and you would expect that previously-signed
driver to continue being accepted by later Windows 10 platforms.

Alan Adams
Client for Open Enterprise Server
Micro Focus
xxxxx@microfocus.com

> Are you saying that an attestation-signed driver package still installs

on Server 2016?  I have no trouble believing that an attestation-signed
driver binary will load once installed, because I don’t think there’s
any way for the kernel to tell the difference.  But I had assumed that
Device Manager would refuse to install an attestation-signed driver
package.  Am I wrong?

Our experience matches what Peter has now confirmed as well, which is
that attested signing is accepted by Windows Server 2016, even when
using .INF-based installation methods which will verify the OSAttr of
the .CAT file.

In the driver I have direct signing experience with – which is a
non-PnP “NetClient”-class .INF file installation – the SetupAPI /
NetSetup / INetCfg installation processing of the Microsoft
attestation-signed .INF and .CAT are handled without any interactive
error or warning on the Server 2016 platform. i.e. Encounters the
same successful behavior that they have on the desktop platform.

Agreed that if you remove the Microsoft attested signing-generated
.CAT from the equation, ostensibly there would not be a way for
Windows to tell how the embedded binary signature came into existence,
or that it was intended for use on only a specific platform.

Alan Adams
Client for Open Enterprise Server
Micro Focus
xxxxx@microfocus.com