Driver Problems? Questions? Issues?
Put OSR's experience to work for you! Contact us for assistance with:
  • Creating the right design for your requirements
  • Reviewing your existing driver code
  • Analyzing driver reliability/performance issues
  • Custom training mixed with consulting and focused directly on your specific areas of interest/concern.
Check us out. OSR, the Windows driver experts.

OSR Seminars


Go Back   OSR Online Lists > ntdev
Welcome, Guest
You must login to post to this list
  Message 1 of 10  
10 Jun 18 18:46
Emre TINAZTEPE
xxxxxx@gmail.com
Join Date: 19 Sep 2009
Posts To This List: 11
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-cod e-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.
  Message 2 of 10  
10 Jun 18 23:57
weilin jiang
xxxxxx@foxmail.com
Join Date: 30 Nov 2017
Posts To This List: 17
Question about driver signing

Do not use sha1 , just sha256 only. ___________________________________________ God is a boy. > ??? 2018???6???11??????06: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 <...excess quoted lines suppressed...>
  Message 3 of 10  
11 Jun 18 11:12
Alan Adams
xxxxxx@novell.com
Join Date: 20 Dec 2010
Posts To This List: 34
Question about driver signing

> 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.ht m#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-si gning-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
  Message 4 of 10  
11 Jun 18 12:03
Peter Viscarola
xxxxxx@osr.com
Join Date:
Posts To This List: 6259
List Moderator
Question about driver signing

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
  Message 5 of 10  
11 Jun 18 12:37
Tim Roberts
xxxxxx@probo.com
Join Date: 28 Jan 2005
Posts To This List: 12025
Question about driver signing

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.
  Message 6 of 10  
11 Jun 18 12:53
Peter Viscarola
xxxxxx@osr.com
Join Date:
Posts To This List: 6259
List Moderator
Question about driver signing

<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
  Message 7 of 10  
11 Jun 18 16:27
Emre TINAZTEPE
xxxxxx@gmail.com
Join Date: 19 Sep 2009
Posts To This List: 11
Question about driver signing

@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=sharin g 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...
  Message 8 of 10  
11 Jun 18 17:10
Peter Viscarola
xxxxxx@osr.com
Join Date:
Posts To This List: 6259
List Moderator
Question about driver signing

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
  Message 9 of 10  
11 Jun 18 18:55
Alan Adams
xxxxxx@novell.com
Join Date: 20 Dec 2010
Posts To This List: 34
Question about driver signing

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
  Message 10 of 10  
11 Jun 18 19:02
Alan Adams
xxxxxx@novell.com
Join Date: 20 Dec 2010
Posts To This List: 34
Question about driver signing

> 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
Posting Rules  
You may not post new threads
You may not post replies
You may not post attachments
You must login to OSR Online AND be a member of the ntdev list to be able to post.

All times are GMT -5. The time now is 06:50.


Copyright ©2015, OSR Open Systems Resources, Inc.
Based on vBulletin Copyright ©2000 - 2005, Jelsoft Enterprises Ltd.
Modified under license