4 ms·

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

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.
    - andrewstuart2 9y ago
      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.
      - wtallis 9y ago
        > 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.
        slededit 9y ago
        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.
        wtallis 9y ago
        > 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.
        slededit 9y ago
        Imagine a scenario where a driver is installed during a network outage and with an incorrect clock. Because you need to be able to install a network driver the system will allow this security flaw. However when the system knows better its reasonable to limit the damage by stopping the driver. You could say that any damage has already been done which is most likely true. But I can't fault them from mitigating it as much as possible. I suppose you could modify the system to get external attestation of the time while the driver is installed and use that as a sticky bit - but its a big complication and its much better if the driver is securely timestamped in the first place.

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.
  - andrewstuart2 9y ago
    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.
    - wtallis 9y ago
      > 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.
      - slededit 9y ago
        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.
        wtallis 9y ago
        > 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.
        slededit 9y ago
        Imagine a scenario where a driver is installed during a network outage and with an incorrect clock. Because you need to be able to install a network driver the system will allow this security flaw. However when the system knows better its reasonable to limit the damage by stopping the driver. You could say that any damage has already been done which is most likely true. But I can't fault them from mitigating it as much as possible. I suppose you could modify the system to get external attestation of the time while the driver is installed and use that as a sticky bit - but its a big complication and its much better if the driver is securely timestamped in the first place.