0

I'm working on making a silent installer of WinpkFilter driver. In my silent installation, I'm always getting a (not so silent) prompt that says "Windows can't verify the publisher of this driver software".

Rightfully so. The cert expired in 2013 and it's cert path is just itself, which isn't a CA.

So how does the real installation do it? When I test the real installation it installs and uses the same expired cert, but there's no aforementioned Windows prompt.

How does it do that?

bzupnick
  • 131
  • 1
  • 2
  • 4
  • Am I right in thinking that you're building (or modifying to create) your own version of the driver? – RoraΖ Mar 04 '15 at 12:31
  • No. I'm trying to follow the real driver's installation using the same exact files, certs, and registry-entries. The end result should look exactly the same; an installed WinpkFilter driver. – bzupnick Mar 04 '15 at 12:58
  • If you're writing a wrapper around the winpkfilter driver then your wrapper would have to be signed. I'm guessing its flagging your wrapper, and not the driver itself. – RoraΖ Mar 04 '15 at 13:08
  • So the process that installs the driver itself needs to be signed....? – bzupnick Mar 04 '15 at 13:29
  • Depending on which Windows version you're installing on, and the settings... yeah. – RoraΖ Mar 04 '15 at 13:48
  • Do you have a source for this? A place to start research on these? I've never heard of this. – bzupnick Mar 04 '15 at 13:53
  • Let us [continue this discussion in chat](http://chat.stackexchange.com/rooms/21635/discussion-between-bzupnick-and-raz). – bzupnick Mar 04 '15 at 13:59
  • Code signing for Windows applications and drivers has been fairly common since Vista/Win7. [Checkout section 6](https://msdn.microsoft.com/en-us/windows/desktop/hh749939.aspx) – RoraΖ Mar 04 '15 at 13:59

1 Answers1

2

From what I read in the comments and in chat I think this is related to timestamping. The driver has been signed at a time the certificate was valid. That signing time was confirmed by a certified timestamp server.

In that case, the driver is considered as trustworthy, since everything was fine at the time of signing.

To check for a timestamp, open the file properties in Windows Explorer, go to "Digital signatures" and check if there is a countersignature with the timestamp. It should look like this:

Digital signatures - countersignatures

Your application (installer), however, was

  • not timestamped at all
  • or the timestamp was not provided by a trusted timestamp server
  • or the certificate itself was revoked to a time before the timestamp was created
  • or the certificate is not trusted by a CA

so that a warning UAC dialog is shown.

Thomas Weller
  • 3,246
  • 3
  • 21
  • 39
  • I have an UMDF driver that was signed with a valid certificate which is now expired. The timestamp in the "Digital Signature" tab shows an old date (2016). However I can still load the driver from my application. So if I understood correctly in this case nothing can prevent me from using the driver. Is it correct ? Is it now only a matter of TSA ? What if the TSA certificate that signed the timestamp expires ? – Bemipefe Aug 28 '19 at 15:48
  • 1
    @Bemipefe: I never read about that, but IMHO it would make sense if that scheme continued the same way "forever". That is: it would not matter if the TSA certificate expires as long as it was valid at the time providing the timestamp. However, if it is revoked for a point in time before that of the timestamp it claims to have proven, that timestamp would not be trusted and as a consequence, the client certificate would become invalid after its expiration. – Thomas Weller Aug 28 '19 at 19:55
  • @Thomas_Weller What checks are then performed during the driver loading ? The signing certificate expiration is not checked and the same applies to the TSA certificate. It looks like the only check performed is if the driver is signed or not. Signed ok, not signed ko ? Are UMDF drivers less restrictive ? – Bemipefe Aug 29 '19 at 08:40
  • 1
    @Bemipefe: there are several options a driver would not load: a) signed, no timestamp, certificate expired b) signed, no timestamp, certificate revoked c) signed, timestamp, certificate revoked before that timestamp d) signed, no timestamp, CA revoked e) signed, timestamp, CA revoked before that timestamp + maybe further more complex scenarios with the CA involved. – Thomas Weller Aug 29 '19 at 09:57
  • 1
    @Bemipefe: AFAIK the procedure is the same for kernel mode drivers and user mode drivers. The difference is just in the type of the certificate. For user mode stuff, you can use a "normal" certificate, while for kernel mode, you need an EV certificate (extended validation). For the EV certificate, they perform more checks of your identity and the cost will be higher. Similar to HTTPS in the browser, whether you see the name in the address bar or not. – Thomas Weller Aug 29 '19 at 09:59