Windows 10 Anniversary Update - Digital Signature Question

Discussion in 'Windows 10' started by WildByDesign, Jun 29, 2016.

  1. WildByDesign

    WildByDesign MDL Addicted

    Sep 8, 2013
    659
    316
    30
    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. :)
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
  2. WildByDesign

    WildByDesign MDL Addicted

    Sep 8, 2013
    659
    316
    30
    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.
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
  3. MS_User

    MS_User MDL Guru

    Nov 30, 2014
    2,703
    421
    90
    will soon find out;)
     
  4. 100

    100 MDL Expert

    May 17, 2011
    1,346
    1,542
    60
    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.
     
  5. WildByDesign

    WildByDesign MDL Addicted

    Sep 8, 2013
    659
    316
    30
    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.
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
  6. 100

    100 MDL Expert

    May 17, 2011
    1,346
    1,542
    60
    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.
     
  7. 100

    100 MDL Expert

    May 17, 2011
    1,346
    1,542
    60
    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.
     
  8. Full inu

    Full inu MDL Senior Member

    Jun 9, 2015
    487
    125
    10
    I didn't use UEFI and UEFI Secure Boot whatsoever.
     
  9. 100

    100 MDL Expert

    May 17, 2011
    1,346
    1,542
    60
    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.
     
  10. 100

    100 MDL Expert

    May 17, 2011
    1,346
    1,542
    60
    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.
     
  11. WildByDesign

    WildByDesign MDL Addicted

    Sep 8, 2013
    659
    316
    30
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
  12. 100

    100 MDL Expert

    May 17, 2011
    1,346
    1,542
    60
    #15 100, Sep 3, 2016
    Last edited by a moderator: Apr 20, 2017
    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.
     
  13. WildByDesign

    WildByDesign MDL Addicted

    Sep 8, 2013
    659
    316
    30
    #16 WildByDesign, Mar 30, 2017
    Last edited by a moderator: Apr 20, 2017
    (OP)

    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".
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...