Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results

Before Posting... Please check out the Community Guidelines in the
Announcements and Administration Category.

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.

Comments

  • weilin_jiangweilin_jiang Posts: 29
    Do not use sha1 , just sha256 only.

    ___________________________________________
    God is a boy.

    > 在 2018年6月11日,06:46,xxxxx@gmail.com <xxxxx@lists.osr.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://www.osronline.com/showlists.cfm?list=ntdev>;
    >
    > MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
    > Details at <http://www.osr.com/seminars>;
    >
    > To unsubscribe, visit the List Server section of OSR Online at <http://www.osronline.com/page.cfm?name=ListServer>;
    >
  • Alan_Adams-2Alan_Adams-2 Posts: 46
    > 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

    Peter Viscarola
    OSR
    @OSRDrivers

  • Tim_RobertsTim_Roberts Posts: 12,616
    Alan Adams <xxxxx@novell.com> 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.

    Tim Roberts, [email protected]
    Providenza & Boekelheide, Inc.

  • <quote>
    Are you saying that an attestation-signed driver package still installs
    on Server 2016?

    ...

    But I had assumed that
    Device Manager would refuse to install an attestation-signed driver
    package. Am I wrong?
    </quote>

    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

    Peter Viscarola
    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 :)

    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:

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

    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.

    <quote>
    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.
    </quote>

    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://www.osr.com/blog/2017/07/06/attestation-signing-mystery/>;

    Peter
    OSR
    @OSRDrivers

    Peter Viscarola
    OSR
    @OSRDrivers

  • Alan_Adams-2Alan_Adams-2 Posts: 46
    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
  • Alan_Adams-2Alan_Adams-2 Posts: 46
    > 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
Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!