Hey guy/gals, This is for some of the more technical users here at MDL who might be more familiar with digitally signing binaries (executables, drivers, etc.) on Windows platforms and specifically regarding Windows 10 Anniversary Update related builds (14366, 14372, etc.). Has there been any major changes in these builds with regard to digital signature requirements? Particularly, I am wondering if Microsoft has made changes to start enforcing SHA-256 signature hashing (in addition to SHA-1) and if this requirement is enforced on kernel-mode drivers as well? If so, could you please point me toward some relevant documentation. Thank you for your time.
Thank you for the link and details. That is what I was suspecting. I am sincerely hoping that we are not nearing another Vista-like nightmare when it comes to kernel-mode drivers. I don't believe that a lot of security software vendors are quite prepared yet as well. Here's hoping that many of the low level developers paid attention to that heads up that they received before 10240. My main system at the moment is approximately 2 years old and I am experiencing a plethora of issues with these 143** series of builds.
Just reporting what I'm seeing on 14393: On a clean install with Secure Boot on, I'm not able to load a driver signed with a 3rd party cross-signed cert that was issued in 12/2015. Loads with Secure Boot off though, and of course any drivers signed with older certs (issued before 2015-07-29, apparently) will also load. Don't know how the "upgrade detection" that supposedly enables drivers signed with cross-signed certs to be loaded works, or what the "registry key" to enable that functionality is, yet.
Very interesting details, 100. Thank you for sharing. I have been playing around with kernel-mode drivers of various dates, with earlier ones working while more recent ones failing validation but I had not figured out the specific date range that was acceptable based on when they were signed, etc. So I appreciate your additional info.
The cutoff date (GA of TH1) is given in the blog post/video I linked earlier. Also, it doesn't matter when the driver itself was signed, but when the driver signing certificate was issued by the CA. So, any certificate from a cross-signed CA that was issued before TH1 GA will continue to work for signing new drivers for as long as the certificate itself is valid.
Yeah, possibly. Easiest way to enable cross-signed drivers to load is to disable Secure Boot then. As mentioned in the linked blog post, there will be some way to enable cross-signed drivers to load with Secure Boot on, but as far as I'm aware that information has not yet been published.
Some technical notes on this: WHQL cert requirement check is done in ci.dll in a function named CipWhqlEnforcementEnabled. The cutoff date is stored in ci.dll as a global variable named g_CiSysDevWhqlEnforcementDateTime (FILETIME), with a hardcoded default value of 2015-07-29.
On the value of g_ciOptions, specifically: Flag 0x20 enforces WHQL requirement for all drivers regardless of certificate issuance date Flag 0x100000 disables WHQL requirement But of course, g_ciOptions isn't something that can be permanently changed without upsetting PatchGuard.
Presumably this is the registry value that gets set on upgraded machines: Code: [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CI\Policy] "UpgradedSystem"=dword:00000001 Edit: The data of the registry value (currently?) isn't actually checked, only the presence of the value. So, having it present with a value of 0 also enables the "upgrade" mode. On my machine this allows cross-signed drivers that would otherwise be blocked from loading to load with Secure Boot on. Of course drivers still need to be signed (and cross-signed) with a valid certificate. This sets the 0x20000 flag of g_CiOptions.
After having upgraded now from Anniversary Update to Creators Update, I am seeing a very similar registry key in the same location: Code: [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CI\Policy] "BootUpgradedSystem"=dword:00000001 Is anyone familiar with this new registry option? I was doing some recent kernel level testing and needed to add and make use of the initial "UpgradedSystem" registry option to fully enable testsigning mode when I came across this new option. I can confirm that the initial "UpgradedSystem" still works well. But what I don't understand yet is the functionality difference between "UpgradedSystem" and "BootUpgradedSystem".