5 ms·

Because it was the certificate for the Windows driver, and Windows requires signed drivers.

wtallis 9y ago
The problem isn't that Windows requires drivers to be signed. The problem is that Windows allows drivers to have an expiration date. If Windows verifies a driver's signature at the time the driver is installed, the driver should be considered trustworthy for as long as it remains installed on that system. There's no reason to re-verify the signature every time the driver is used.
- hesdeadjim 9y ago
  Perhaps as a malware defense?
  - AnimalMuppet 9y ago
    Perhaps, but it would be better to trigger that with some knowledge of an attack, rather than at a fixed date. [Edit: It may not be this simple. See the top-level comment by r1ch about timestamp servers.]
  - kbenson 9y ago
    I think that's better handled through a Certificate Revocation List (CRL), especially in this case where's it's fairly easy to enforce and keep up to date.
    - jsmthrowaway 9y ago
      CRLs are pretty difficult to scale resiliently, though, for a number of applications. Same problem that led to OCSP stapling after OCSP became a thing. With CRLs you can at least take advantage of a CDN of some kind, but there are tradeoffs with your ability to operate a CRL securely doing that, too. CRL in the driver install flow implies being online (at some point) to install drivers too. As we move into the future it’s hard to imagine not having Internet access, but we also don’t design Windows. It’s definitely a case they’ve considered, though I did see mention of a timestamp server in this thread (I don’t know much about Windows signing, just X.509 PKI in general).
      - wtallis 9y ago
        Are driver CRLs any more challenging than the virus definitions already distributed through Windows Update?
  - gruez 9y ago
    if you by "malware defense" mean preventing stolen expired certificates from being used to sign code, then yes. if you mean by only allowing code to be "signed" for the duration of the certificate, then no.
- NateyJay 9y ago
  Recommended practice is to timestamp windows drivers (and software) when they are signed. Without a timestamp, the driver is not trusted after the signing cert expires, which I guess is what happened here. With a timestamp, as long as the signing date was within the signing cert's validity period, the signed driver continues to be trusted beyond the signing certificate expiration.
  - phkahler 9y 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?
    - ScottEvtuch 9y ago
      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.
      - Retric 9y ago
        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.
        gruez 9y ago
        >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.
        wtallis 9y ago
        > 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.
- 21 9y ago
  Stuxnet used malicious drivers signed with a stolen Realtek certificate.
- tptacek 9y ago
  Part of what driver expiry does is to prevent attackers from trivially banking older vulnerable versions of drivers and using them to bypass kernel protections.
  - tedunangst 9y ago
    But that's only relevant/necessary to check at install time. Attackers aren't banking the drivers that I've already installed last year.
    - MertsA 9y ago
      Checking at install time is effectively useless. The whole point of running signed code is that you can't just load some rootkit. Secure Boot only loads a signed bootloader which only loads a signed kernel which only loads signed kernel modules. You can't do what you're suggesting without fundamentally breaking this chain of trust. What's to stop a rootkit from just spoofing that it was installed months ago?
      - wtallis 9y ago
        > What's to stop a rootkit from just spoofing that it was installed months ago? The fact that if a rootkit is in a position to performing that spoofing, it doesn't need to, because it already has the power to make arbitrary modifications to the system image.
        MertsA 9y ago
        The whole point of signing everything from the bootloader on down is to make sure that even ring 0 control over the computer can't persist through a reboot. Allowing signatures to work the way it was suggested would break any hope of something like Secure Boot ever working. As it is you're already trusting timestamping certificates to effectively live forever.
      - dannyw 9y ago
        The signed kernel keeps track of when it first has seen a certificate. That is signed by a kernel, so a rootkit can’t spoof unless the system is already compromised.
- mulmen 9y ago
  Is that true though? Could a malicious driver be signed with a compromised key and distributed? Seems like a useful feature to be able to mark drivers as compromised.
  - wtallis 9y ago
    > Seems like a useful feature to be able to mark drivers as compromised. Putting expiration dates on non-malicious drivers is not a particularly effective way to protect against malicious drivers.
    - mulmen 9y ago
      > There's no reason to re-verify the signature every time the driver is used. I was replying to this part of your comment. It does seem worthwhile to validate the signature of the driver every time the driver is used if that check would reveal when a certificate has been revoked for having been compromised. Agreed that the expiration time is not particularly useful for this purpose.
      - wtallis 9y ago
        > It does seem worthwhile to validate the signature of the driver every time the driver is used if that check would reveal when a certificate has been revoked for having been compromised. It would be much more efficient to scan the list of installed drivers every time a certificate revocation list is updated, because certificates are revoked much less often than operating systems are booted. And there's nothing gained by just checking timestamps if you don't have a new certificate revocation list. If the driver is already installed and was trusted and running yesterday, you gain no security by deciding to not load and run that driver today, unless overnight you acquired new information that the driver is insecure or malicious. The ticking of a clock does not convey any such information.
- anonymfus 9y ago
  Is there such thing as a driver installation for the kernel, or it's just few filesystem operations?

The problem isn't that Windows requires drivers to be signed. The problem is that Windows allows drivers to have an expiration date. If Windows verifies a driver's signature at the time the driver is installed, the driver should be considered trustworthy for as long as it remains installed on that system. There's no reason to re-verify the signature every time the driver is used.

hesdeadjim 9y ago
Perhaps as a malware defense?
- AnimalMuppet 9y ago
  Perhaps, but it would be better to trigger that with some knowledge of an attack, rather than at a fixed date. [Edit: It may not be this simple. See the top-level comment by r1ch about timestamp servers.]
- kbenson 9y ago
  I think that's better handled through a Certificate Revocation List (CRL), especially in this case where's it's fairly easy to enforce and keep up to date.
  - jsmthrowaway 9y ago
    CRLs are pretty difficult to scale resiliently, though, for a number of applications. Same problem that led to OCSP stapling after OCSP became a thing. With CRLs you can at least take advantage of a CDN of some kind, but there are tradeoffs with your ability to operate a CRL securely doing that, too. CRL in the driver install flow implies being online (at some point) to install drivers too. As we move into the future it’s hard to imagine not having Internet access, but we also don’t design Windows. It’s definitely a case they’ve considered, though I did see mention of a timestamp server in this thread (I don’t know much about Windows signing, just X.509 PKI in general).
    - wtallis 9y ago
      Are driver CRLs any more challenging than the virus definitions already distributed through Windows Update?
- gruez 9y ago
  if you by "malware defense" mean preventing stolen expired certificates from being used to sign code, then yes. if you mean by only allowing code to be "signed" for the duration of the certificate, then no.
NateyJay 9y ago
Recommended practice is to timestamp windows drivers (and software) when they are signed. Without a timestamp, the driver is not trusted after the signing cert expires, which I guess is what happened here. With a timestamp, as long as the signing date was within the signing cert's validity period, the signed driver continues to be trusted beyond the signing certificate expiration.
- phkahler 9y 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?
  - ScottEvtuch 9y ago
    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.
    - Retric 9y ago
      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.
      - gruez 9y ago
        >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.
        wtallis 9y ago
        > 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.
21 9y ago
Stuxnet used malicious drivers signed with a stolen Realtek certificate.
tptacek 9y ago
Part of what driver expiry does is to prevent attackers from trivially banking older vulnerable versions of drivers and using them to bypass kernel protections.
- tedunangst 9y ago
  But that's only relevant/necessary to check at install time. Attackers aren't banking the drivers that I've already installed last year.
  - MertsA 9y ago
    Checking at install time is effectively useless. The whole point of running signed code is that you can't just load some rootkit. Secure Boot only loads a signed bootloader which only loads a signed kernel which only loads signed kernel modules. You can't do what you're suggesting without fundamentally breaking this chain of trust. What's to stop a rootkit from just spoofing that it was installed months ago?
    - wtallis 9y ago
      > What's to stop a rootkit from just spoofing that it was installed months ago? The fact that if a rootkit is in a position to performing that spoofing, it doesn't need to, because it already has the power to make arbitrary modifications to the system image.
      - MertsA 9y ago
        The whole point of signing everything from the bootloader on down is to make sure that even ring 0 control over the computer can't persist through a reboot. Allowing signatures to work the way it was suggested would break any hope of something like Secure Boot ever working. As it is you're already trusting timestamping certificates to effectively live forever.
    - dannyw 9y ago
      The signed kernel keeps track of when it first has seen a certificate. That is signed by a kernel, so a rootkit can’t spoof unless the system is already compromised.
mulmen 9y ago
Is that true though? Could a malicious driver be signed with a compromised key and distributed? Seems like a useful feature to be able to mark drivers as compromised.
- wtallis 9y ago
  > Seems like a useful feature to be able to mark drivers as compromised. Putting expiration dates on non-malicious drivers is not a particularly effective way to protect against malicious drivers.
  - mulmen 9y ago
    > There's no reason to re-verify the signature every time the driver is used. I was replying to this part of your comment. It does seem worthwhile to validate the signature of the driver every time the driver is used if that check would reveal when a certificate has been revoked for having been compromised. Agreed that the expiration time is not particularly useful for this purpose.
    - wtallis 9y ago
      > It does seem worthwhile to validate the signature of the driver every time the driver is used if that check would reveal when a certificate has been revoked for having been compromised. It would be much more efficient to scan the list of installed drivers every time a certificate revocation list is updated, because certificates are revoked much less often than operating systems are booted. And there's nothing gained by just checking timestamps if you don't have a new certificate revocation list. If the driver is already installed and was trusted and running yesterday, you gain no security by deciding to not load and run that driver today, unless overnight you acquired new information that the driver is insecure or malicious. The ticking of a clock does not convey any such information.
anonymfus 9y ago
Is there such thing as a driver installation for the kernel, or it's just few filesystem operations?