Hacker News new | ask | show | jobs
by phkahler 3031 days ago
That seems silly. Presumably a cert has an expiration date after which we might assume its been compromised. If it has been compromised then it could have been used to backdate a driver signed with it. In other words, if you don't trust the cert you should not trust anything signed by it. Or is there another layer in this somewhere?
1 comments

The timestamp server is a separate trusted entity that signs the signature asserting the date and time. It's not just metadata, it's effectively a separate signature.
Which just means the expiration date is meaningless.

If the driver was valid when it was signed, then revoking it will break the system. Not installing it is another story.

The expiration date is the fallback if you don't have confirmation from the timestamp server that it was signed prior to expiration.

Ideally it's not used except by the timestamp service, but it seems like a fairly reasonable fallback.

> The expiration date is the fallback if you don't have confirmation from the timestamp server that it was signed prior to expiration.

The fact that the driver was installed locally before the expiration should be taken as proof that the driver was signed before expiration.

Then you would need an internet connection just to install a driver. It would make getting your network driver installed pretty difficult.

You could look at the system clock but that was not designed to be secure for this purpose.

> Then you would need an internet connection just to install a driver.

If you think I'm proposing any changes to how drivers are installed, then you have misread me. I'm proposing a change to how already-installed drivers are handled: absent any new information, the code that was trusted yesterday should be trusted today, and be allowed to keep running.

Even then you only need to verify that once and can save a time stamp in case the cert is revoked afterwards. Breaking system that has already been verified is still unjustified.
Can’t Microsoft give you an error report when they do this, to let you know what you are doing is probably very dumb?

I guess I don’t know the time when Microsoft has their code and heir contact information and is doing some kind of preflight check, or if that ever actually happens, and there are already so many ways to be very dumb with drivers...

>Which just means the expiration date is meaningless.

how so? it merely limits which dates you can sign code, after which the code you signed remain valid, but you can't sign any more code.

> it merely limits which dates you can sign code, after which the code you signed remain valid,

The whole problem here is that the code that was signed is not being treated as valid code beyond the expiration date.