Cross-signing Windows drivers after April 2021

Topics:
Forums
24 Sep, 21
60
2

The Microsoft Trusted Root Program no longer supports root certificates that have kernel mode signing capabilities. However, Eli Billauer (http://www.billauer.co.il/) managed to cross sign using the old method (see below). Do you think this method will continue to work?

--------

I've managed to install a Windows driver which was compiled and cross-signed the old school way after the famous April 15 2021 deadline. I used a certificate that had expired at the the time of signature, but a forged timestamp made it appear to be valid. I installed the driver on a Windows 7 / 32 bit machine as well as a Windows 10 / 64 bit, however it's not clear whether this method can be used for production drivers. This is why I'd like you guys to try this out.

Forging the timsstamp could be a workaround for releasing cross-signed drivers even after April 2021. It requires having a certificate that was valid at some time in the past. By using a timestamp server that allows choosing the desired time, the signature can be made to appear as if it was signed when the certificate chain was valid, but even more important: Making it appear to be a "legacy driver", and hence accepted by all version of Windows, despite being cross-signed.

To install the driver on a computer, it must trust the forged timestamp. This is achieved by temporarily installing a root certificate in that computer's registry. Unlike the code signature itself, for which only the Microsoft Code Verification Root certificate is trusted, the timestamp validation relies on a root certificate in the registry. It can therefore be added by an installation script or wizard for that purpose.

I've set up a timestamp server which allows selecting the timestamp's time through the URL. I've also written a post in my blog on how to sign a driver with this method. Also in this post, I explain why I don't think adding this root certificate poses a problem from a security point of view (if done correctly for a production driver).
.
The said post: http://billauer.co.il/blog/2021/04/windows-drivers-fake-timestamp/

The question is whether this works reliably on the variety of Windows configurations out there. And if there aren't any other possible issues to consider. Please try this out, and report whether you managed to turn back time.
.
I'd like to emphasize that this isn't like self-signed drivers. The method I suggest requires a legit certificate chain for the code signing path. The workaround relies on the certificate check for the timestamp, which appears to be less strict.

2 Comments

24 Sep, 21

I don't have anything handy to replicate this test, but it sounds like as long as the timestamp validates (and this model allows for installing a trusted root that ensures it), I can't see any problems.

Windows 11 may change this (I haven't seen what their driver trust model will be, whether they're making any changes to it), but as long as Microsoft keep their legacy support, they're going to have trouble restricting device drivers (especially where custom root certificates can be installed).

24 Sep, 21

Interesting! Did this work on a fresh install of Windows 10 21H1? I’m aware of Microsoft relaxing restrictions when Windows has been upgraded (versus a fresh install). In particular, does your Windows 10 test machine have some of these registry keys set?

https://www.geoffchappell.com/notes/security/whqlsettings/index.htm