Device guard policy for only WHQL signed drivers

NTDEV
1

I have two identical builds of a driver that is capable of passing HLK tests. One is signed with only our code sign cert, the other is signed with our code sign cert + WHQL cert. I have built a Server2016 machine and used device guard code integrity policy to audit (a precursor to deny) drivers that are not WHQL signed. I would have expected my WHQL signed driver to load without audit, however it doesn’t.

The event log entry contains:
“Code Integrity determined kernel module \path\mydriver.sys that did not meet the WHQL requirements is loaded into the system. However, due to a code integrity auditing policy, the image was allowed to load.”

The code integrity policy was created from the following script:
$CIPolicyPath=“C:\jstshare\1”
$InitialCIPolicy=$CIPolicyPath+“.xml”
$CIPolicyBin=$CIPolicyPath+“.bin”
$DriverFiles=Get-SystemDriver -ScanPath “C:\jstshare\drivers”
New-CIPolicy -FilePath $InitialCIPolicy -DriverFiles $DriverFiles -Level WHQL - Audit
ConvertFrom-CIPolicy $InitialCIPolicy $CIPolicyBin

Should I expect my WHQL signed driver to load correctly? Assuming it should, and that my issue lies in how I created the code integrity policy, has anyone had success creating one of these to enforce WHQL signatures?

Thanks,
J

2

Sooooo… more details, please.

Your “WHQL Signed” driver is ATTESTATION SIGNED or WLK Signed? Is it signed specifically for S16?

There’s “WHQL signed” and then there’s “WHQL signed”… it’s never simple.

Peter
OSR
@OSRDrivers

3

Hi Peter, sorry for the slow reply.

The build of my driver that I said is WHQL signed has been submitted as part of a HLK report to sysdev with Server2016 selected after successfully passing the HLK tests. the build is both attestation signed and whql signed (more below).

For completeness I should have also mentioned other signatures on the driver builds.

Build 1:
SHA1 from our SHA1 code signing cert
SHA256 from our SHA256 code signing cert
ATTESTATION signature from attestation process

Build 2:
SHA1 from our SHA1 code signing cert
SHA256 from our SHA256 code signing cert
ATTESTATION signature from attestation process
*WHQL signature from HLK submission process*

My expectation is that since Build 2 is WHQL signed, it should not being causing Audit events with my aforementioned CI policy.
J

4

For the further avoidance of doubt: Your Build 2 is signed FOUR DIFFERENT TIMES? And ALL FOUR of those signatures are evident when you test the signatures for the driver?

Wow. I wasn’t aware you COULD sign the same exe/package FOUR TIMES.

Shows you what I know. I should be asking YOU for help, Mr. Stephenson :wink:

Peter
OSR
@OSRDrivers

5

> SHA1 from our SHA1 code signing cert

SHA256 from our SHA256 code signing cert
ATTESTATION signature from attestation process
*WHQL signature from HLK submission process*

Is it possible that Windows finds the first Microsoft signature, sees that it is attested, and just stops there, not expecting an additional MS signature? Have you tried a build that just has your signatures and the WHQL signature?