Can I install self-signed drivers on 64-bit Windows without test mode if the self-signed CA root certificate is imported to the machine store? - windows

Here is a great SO answer which covers the creation of self-signed CA and then signing executables with the obtained certificates: How do I create a self-signed certificate for code signing on Windows?.
I have read a lot of discussions online on how the driver signing works and the answer seems to be almost unequivocally that you can't load unsigned or self-signed drivers without having the test mode enabled. However, the answer I linked to and especially one comment by Roger Lipscombe seems to provide a contradicting view:
If you want to use this for signing drivers, you need to import the CA
certificate into the machine store. My example imports it into the
user store, which is fine for most software, for test/internal
purposes.
To me, it looks like I would be able to install drivers with self-signed certificates (issued by a self-signed CA) as long as the CA cert was imported to the machine store. I won't have to make any other changes to the system (disabling test mode by pressing F8 on boot menu, messing with boot configuration flags such as TESTSIGNING or NOINTEGRITYCHECKS).
Am I correct? What are the obstacles, if any, that this method is not used more widely when people need to load drivers that have no proper digital signatures provided (such as old printer drivers etc.). Instead, people rely on booting to test mode or a third-party software (DSEO) which tampers with your system files to run such drivers.
What are the drawbacks of this method? The process described in the above SO question needs admin privileges but installing drivers should need them anyway. Trusting a self-signed CA might be a security risk - but won't disabling all signature checks be even bigger security risk?

No, this is unfortunately not possible, starting from Windows Vista and Windows Server 2008.
The driver has to be cross-signed. Creating your own CA and adding it to the machine store won't be enough because the newly created CA won't be trusted by the Windows chain of trust.
Driver Signing Requirements for Windows
In Windows Vista and Windows Server 2008, new features take advantage of code-signing technologies, and new requirements for security in the operating system enforce the use of digital signatures for some kinds of code.
Components must be signed by a certificate that Windows "trusts" as described in the white papers on this site.
One of the white papers referred is Digital Signatures for Kernel Modules on Windows
which describes the load process and explains why self-signing won't be sufficient:
When a driver is loaded into kernel memory, Windows Vista verifies the digital signature of the driver image file. Depending on the type of driver, this can be either the signed hash value in the catalog file or an embedded signature in the image file itself. The cross-certificates that are used when signing the kernel driver package are used for the load-time signature verification; each certificate in the path is checked up to a trusted root in the kernel. The load-time signature check does not have access to the Trusted Root Certificate Authorities certificate store. Instead, it must depend on the root authorities that are built into the Windows Vista kernel.
As mentioned earlier, this is also outlined on the Requirements for Device Driver Signing and Staging page:
The 64-bit versions of Windows 7 and Windows Server 2008 R2 have special signature requirements for kernel mode device drivers. If you use a 64-bit version of Windows, then you cannot create your own certificate for signing. Instead, you must use a Software Publishing Certificate that chains to an approved certification authority (CA).
The valid CAs for signing kernel mode drivers can be found on the following page:
Cross-Certificates for Kernel Mode Code Signing

User mode drivers will work on Windows 10 X64 with secure boot and everything with self signed certs as long as you add the cert to the Trusted Root CAs. Kerner mode drivers only work with paid MS trusted root CAs.

you are correct, if you create a self signed certificate and save it in user store (or machien store) as a Trusted CA, it will work for you... but keep in mind that:
Secure boot will not work for you.
This is a security breach, if someone get a hold of the certificate, they will have to run kernel mode code on your system.
Other option, is to buy Trusted Code Signing Certificate from GoDaddy :)

Related

Created a storage adapter for windows biometric framework but unable to install and load

I have created a storage adapter for windows biometric framework. Added related keys and parameters in the registry at Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USB\VID_1162&PID_2200\5&376aba2d&0&9\Device Parameters\WinBio\Configurations and Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WbioSrvc\Databases. Copied the dll of my storage adapter in C:\WINDOWS\SYSTEM32\WINBIOPLUGINS directory. Tried to load the storage adapter in the biometric session using winbio.dll's WinBioOpenSession method. Getting the following errors:
1) In biometric event log= "The Windows Biometric Service failed to load an adapter binary: C:\WINDOWS\SYSTEM32\WINBIOPLUGINS\STORAGEADAPTER.DLL.The module was not properly signed".
2) In codeintegrity event log="Windows is unable to verify the image integrity of the file \Device\HarddiskVolume2\Windows\System32\WinBioPlugIns\StorageAdapter.dll because file hash could not be found on the system. A recent hardware or software change might have installed a file that is signed incorrectly or damaged, or that might be malicious software from an unknown source.".
Searched some information on the internet about above errors and found that the dll must be signed to install and load. So tried the test-signing and release-signing(with godaddy's driver signing certificate) both but still getting the same errors. The only thing I failed to do is to sign my dll with a cross certificate and its because I am unable to find the appropriate cross certificate for my driver signing certificate.
Query: Is it necessary to sign the dll with cross certificate and a driver signing certificate both or signing with only a driver signing certificate is sufficient to install it on windows?
Note: Please suggest me if I have missed something here or not following the correct process to load a custom storage adapter in the biometric session.
Modern Windows kernel requires drivers to be signed by specific Certificate Authority (CA) approved by Microsoft (actually it has to be signed with two keys CA and MS, MS for drivers loaded during the boot process). If you are developing driver you should have set up the test machine with disabled TESTSIGNING on test machine. And once you are done developing you and Microsoft need to sign driver before publishing in order for driver to be able to be loaded into kernel.
There is documentation on microsoft site how to prepare drivers test machine in details. But here is the command that will help disable TESTSIGNING in kernel (requires the reboot of system).
PLEASE NOTICE: path to the command may differ from system to system, search for bcdedit.exe on your PC to locate the path.
C:\Windows\winsxs\amd64_microsoft-windows-b..iondata-cmdlinetool_31bf3856ad364e35_6.1.7601.17514_none_e6510234bbcb2a8c\bcdedit.exe -set TESTSIGNING OFF
Also strongly suggest site community.osr.com where most of Windows kernel developers can be found exchanging their knowledge, site is dedicated to the kernel development.
They have helped me alot in the past.
hope this helps you

EV code signing needed for own libusb-win32 driver?

I am trying to get our libusb-win32 driver to work with different Windows OS. I already successfully installed it on 7, 8 and 10 with a selfsigned certificate that I imported into the root and trustedpublisher.
What remains is to buy an official certificate and distribute it. Since Windows 10 there is the need to use EV for kernel mode drivers but libusb already ships the .sys and .dll with valid signature.
Since theres quite a difference in pricing the question is: Do I need an EV certificate to sign the .cat or can Windows differentiate between installing with standard certificate signature in the .cat and loading the kernel module with the embedded kernel module signature?

Sign custom *.cat file that uses WinUSB driver in Windows 10

I need some clarification about driver signing in Windows 10.
We have working driver package that uses Winusb.sys driver that is signed from the start by Microsoft. But to install this driver to customer machine we have our own *.inf and 2 generated *.cat files for each supported platforms. Currently we have no issues using this driver in Windows 10 since modifications for Windows 8 support, but we want to add some additional hardware devices support in near future to driver, so it will be modified and need to be resigned.
The question is what certificate (Extended Validation (“EV”) Code Signing Certificate or just Standard Certificate) do we need to sign these *.cat files, so our driver can be installed correctly at Windows 10. Also is it necessary to submit out driver to Windows Hardware Developer Center Dashboard portal?
I saw this and some other articles that states, EV certificate signing is needed only by kernel-mode drivers (it seems after 90 days of Win10 release also user-mode drivers), but WinUSB driver is kernel-mode and fully supported and initially signed by Microsoft. So again what kind of certificate do we need to sign *.cat files and do we need to submit them to Microsoft portal?
The files structure before signing looks like
driver
|--*.inf
|--*amd64.cat
|--*x86.cat
|--amd64
|--WdfCoInstaller01009.dll
|--winusbcoinstaller2.dll
|--i386
|--WdfCoInstaller01009.dll
|--winusbcoinstaller2.dll
|--ia64
|--WdfCoInstaller01009.dll
|--winusbcoinstaller2.dll
My company also uses WinUSB for one of our devices. We currently use a "driver signing" certificate from Godaddy. Once the certificate is installed on your machine (they have step-by-step instructions for how to do this), you need to generate a pfx file and then you can use the signtool utility to sign the security catalog.
This link was a great resource for me: http://www.davidegrayson.com/signing/

Kernel driver signing

I have done a great deal of looking around, and I can't seem to get a straightforward answer to this issue.
I am hobbyist programmer, I have done a great deal of work with windows drivers, and wrote my own personal 'antivirus' driver for windows XP. So don't get me wrong here, I don't work for any software development firm or anything of the like.
My question is: as far as windows 7 x64 is concerned, is there any possible legit and legal method I can use to release sign my driver that would only be for my own personal use?
Yes I am well aware I can test sign my driver and run it in a virtual machine under windows test mode, which I do quite frequently. However if you have used windows in test mode you know there are some major drawbacks.
So to to sum this all up, is it possible for me ( a hobbyist ) to release sign a driver for my own personal use and not have to deal with windows test mode?
Thanks.
If it's a boot time required driver, I don't think there is a way you can get it to use it without signing it with a certificate from a Microsoft sanctioned provider (Verisign only I think for drivers?).
If this is a normal device driver that isn't required at boot you can create your own certificates and use those instead. I did it myself for Vista x64 to get an HP ScanJet driver to work from XP x64 by signing the .sys and the .inf files.
I used Active Directory Certificate Services on my domain to issue a Code Signing certificate for my use and had my machine trust the ADCS CA certificate. These two actions will cause Windows to trust your signed driver.
I believe you could use OpenSSL to create a CA certificate and issue code signing certificates with that, but I've had no practice with it.
Again, to reiterate, if this driver is required at boot then this method will not work, if it's used for a device which can be attached at anytime, it should work.
You can have the ReactOS Foundation do it for you.
Please refer to my answer to this post: Windows 7 kernel driver signing.
So to to sum this all up, is it possible for me ( a hobbyist ) to release sign a driver for my own personal use and not have to deal with windows test mode?
Yes.
For boot time drivers: Go to VeriSign, buy the (only?) code signing certificate ($500), and sign your driver.
For non-boot drivers: You can self-sign, with appropriate warnings.

Cheap Windows driver signing for 64 bit Windows 7

I need to install the libusb-win32 driver on Windows 7 64 bit machines. This driver is open source so it is not digitally signed so I want to do this myself, but I wonder if this can be done WITHOUT paying lot of money. Is it possible to use a certificate which is NOT signed by Verisign or GlobalSign? Maybe self-signed or by using StartSSL instead?
And if yes, how do I do it? According to a how-to, The Practical Truth About x64 Kernel Driver Signing, I have to use a "cross-certificate" (and there are only six available on the Microsoft list and most of them are for CAs which are no longer active).
I don't care if the user is confronted with a warning message. I can even accept if the user has to install a special CA certificate first. I only require that the driver runs without manually disabling the signature check on each Windows startup.
No, the driver has to be cross signed by one of those specific certificates and thus the driver has to be signed by one of those CAs. You can disable driver signing on the machine for testing purposes, but obviously you don't want to do this on production machines. Sorry, that's just the way it is.
LibUSB_win32 is now already signed, according to http://sourceforge.net/apps/trac/libusb-win32/wiki
It says: "Vista/7/2008/2008R2 64 bit are supported from version 1.2.0.0 since a Microsoft KMCS accepted digital signature is embedded in the kernel driver libusb0.sys."
So the only thing you have to do is update your libusb_win32 driver.
To allow loading into kernel, you have to sign with those CA and have WHDL checked.
The only alternative would be using the user mode driver framework. (but libusb does not support it -- it was discussed, but never implemented)

Resources