3 ms·

Rereading your question, I realize I may have not actually answered an underlying topic: what is the difference between a certificate and a signature? The shor

by agar 9y ago

Rereading your question, I realize I may have not actually answered an underlying topic: what is the difference between a certificate and a signature? The short answer is: - a "certificate" contains a number of things: a portion of an asymmetric key (either public or private), and a ton of metadata[1] to give information about that key: validity period, algorithms used, version, etc. - a "signature" is the result of a crypto operation on data that proves the data (a) has not changed since the operation, and (b) the person doing the signing owns the private portion of that asymmetric key. As I said in my other message, a signature doesn't expire, but it's related directly (and generated by) the certificate used to create it. So if that creation certificate expires (or is revoked) it calls into question the validity of the signature(s) created from that certificate. Let me know if you're interested in more background on asymmetric cryptography and the relationship between public keys and crypto, private keys and signatures, and the role of certificate authorities vs. a PGP-oriented 'web of trust'. [1] https://en.wikipedia.org/wiki/X.509#Sample_X.509_certificates https://en.wikipedia.org/wiki/X.509#Sample_X.509_certificate...

dlubarov 9y ago
> So if that creation certificate expires (or is revoked) it calls into question the validity of the signature(s) created from that certificate. Are you arguing that already-installed drivers should no longer be trusted? I can't tell. If a cert expires at time T, the usual assumption is that forging signatures before T is not feasible (otherwise the expiration was poorly chosen), while forging signatures after T might be feasible. If it's after T and we see a new update, we don't know whether the signature was crafted before or after T, so we should assume the latter and reject it. But if we've already installed a driver, then we must have received its signature before T, otherwise we wouldn't have installed it at the time. So we should still continue to trust it after T.
- agar 9y ago
  To be clear, I'm not arguing that old, already-installed drivers should fail if not countersigned. This seems like an extreme, and customer-unfriendly failure case. However, I am saying that this appears to be the default implementation of Windows 10 build 1607+. I won't argue it's right or wrong, actually. It's a choice, with different threat models driving different conclusions. Defining the failure modes with respect to security risks is a fraught business, and I hope Microsoft put a great deal of thought into it and has far more visibility into the risks than I. But it's what they appear to do, and we live in their world. I argued elsewhere (in a late, top-level comment somewhere) that - if this is Windows's failure mode - MS should provide tools for devs to integrate into their build process that flags risky or mis-configured signature scenarios. This is too complicated, and used by too many non-security experts, with extreme failure modes, for it to be half-ass-able or easily done wrong.
  - dlubarov 9y ago
    Thanks for clarifying; I didn't realize that was Windows' behavior.
- Vendan 9y ago
  > But if we've already installed a driver, then we must have received its signature before T, otherwise we wouldn't have installed it at the time. So we should still continue to trust it after T. And now you leave open an attack surface of "forge a signature off an old, expired cert and then fool the OS into thinking it's been installed all along."

by agar 9y ago

dlubarov 9y ago

> So if that creation certificate expires (or is revoked) it calls into question the validity of the signature(s) created from that certificate. Are you arguing that already-installed drivers should no longer be trusted? I can't tell. If a cert expires at time T, the usual assumption is that forging signatures before T is not feasible (otherwise the expiration was poorly chosen), while forging signatures after T might be feasible. If it's after T and we see a new update, we don't know whether the signature was crafted before or after T, so we should assume the latter and reject it. But if we've already installed a driver, then we must have received its signature before T, otherwise we wouldn't have installed it at the time. So we should still continue to trust it after T.

agar 9y ago
To be clear, I'm not arguing that old, already-installed drivers should fail if not countersigned. This seems like an extreme, and customer-unfriendly failure case. However, I am saying that this appears to be the default implementation of Windows 10 build 1607+. I won't argue it's right or wrong, actually. It's a choice, with different threat models driving different conclusions. Defining the failure modes with respect to security risks is a fraught business, and I hope Microsoft put a great deal of thought into it and has far more visibility into the risks than I. But it's what they appear to do, and we live in their world. I argued elsewhere (in a late, top-level comment somewhere) that - if this is Windows's failure mode - MS should provide tools for devs to integrate into their build process that flags risky or mis-configured signature scenarios. This is too complicated, and used by too many non-security experts, with extreme failure modes, for it to be half-ass-able or easily done wrong.
- dlubarov 9y ago
  Thanks for clarifying; I didn't realize that was Windows' behavior.
Vendan 9y ago
> But if we've already installed a driver, then we must have received its signature before T, otherwise we wouldn't have installed it at the time. So we should still continue to trust it after T. And now you leave open an attack surface of "forge a signature off an old, expired cert and then fool the OS into thinking it's been installed all along."