5 ms·

Under windows, when I sign a binary, I also have the option (well - it's more like a strong recommendation) to time-stamp the signature. That way, windows can

by pilif 11y ago

Under windows, when I sign a binary, I also have the option (well - it's more like a strong recommendation) to time-stamp the signature. That way, windows can check whether the signature was made during a time when the certificate was valid. This means that when your certificate expires, you won't be able to sign new binaries, but at least the existing ones continue to work. This is something Apple should really consider implementing - even just for the sake of archival of old OS versions that people might still want to install for nostalgias sake.

tlrobinson 11y ago
Does Microsoft co-sign the binary or something? If not that feature seems like it would defeat the purpose of expiring certificates.
- flohofwoe 11y ago
  It means that the certificate was valid at the time of signing. Trying to sign an executable after the certificate has expired will not produce a valid code-signed executable. It totally makes sense. That it is possible to make the certificate valid by simply setting the system clock (this works both on Windows and according to the article, OSX) shows that the whole certificate expiration thing is basically useless.
  - tlrobinson 11y ago
    I'm not sure I understand. It doesn't matter if the consumer of the certificate is able to set their clock to make the certificate/signature valid because most people don't do that, but if the producer of the signature can simply set their clock to produce a signature/timestamp combination that's considered valid by a consumer regardless of their clock, then what's the point of expiring the certificate? But yeah, it looks like Microsoft countersigns, assuming this is what that original comment was referring to: https://msdn.microsoft.com/en-us/library/windows/desktop/bb931395(v=vs.85).aspx https://msdn.microsoft.com/en-us/library/windows/desktop/bb9...
    - imron 11y ago
      It gets timestamped by the certificate authority, using their authorized servers. For example, I have a code-signing certificate issued by Comodo, and when I sign my software, it get timestamped by: http://timestamp.comodoca.com http://timestamp.comodoca.com I can't simply set that clock.
    - flohofwoe 11y ago
      Yes I should have been more clear. A user which wants to run a signed executable with expired certificate can trick the validation process on his machine by setting the system clock back into the valid period. But for the code-signer this trick doesn't work, the sign-tool needs to talk to a time-stamp server, usually owned by a certificate authority. I know that the Microsoft signtool.exe and the Java jarsigner can use timestamps, apparently on OSX this works too (search for --timestamp cmdline arg: https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man1/codesign.1.html https://developer.apple.com/library/mac/documentation/Darwin...)
kevincox 11y ago
How does this help? In order to provide any security you would need to limit the time from signing, which would be very similar to just issuing the certificate for that much longer. There is no way to verify that the binary was actually signed at that time.
- makomk 11y ago
  It uses trusted timestamping servers run by certificate authorities to sign the timestamp information.
  - kevincox 11y ago
    Ok, I didn't realize that. But it still doesn't solve the problem of compromising an old certificate and creating a fake signature with your own time.
    - wangweij 11y ago
      Expired and compromised are two different things. If compromised, it will be published in a CRL with a reason flag.
      - kevincox 11y ago
        The reason why certificates expire is because they will become easy to crack as computers get faster. So this would effectively be removing the expiry date. Now you can crack any old certificate and sign things claiming that you did it before the certificate expired.
        markild 11y ago
        As someone above has already said. To do this, you'd need to compromise or convince a trusted timestamping authority to sign your signing request with an old date.
    - khedoros 11y ago
zZorgz 11y ago
Apple's code signing actually has this and it's on by default. Don't ask me why it didn't help with their installers, though..

by pilif 11y ago

tlrobinson 11y ago

Does Microsoft co-sign the binary or something? If not that feature seems like it would defeat the purpose of expiring certificates.

flohofwoe 11y ago
It means that the certificate was valid at the time of signing. Trying to sign an executable after the certificate has expired will not produce a valid code-signed executable. It totally makes sense. That it is possible to make the certificate valid by simply setting the system clock (this works both on Windows and according to the article, OSX) shows that the whole certificate expiration thing is basically useless.
- tlrobinson 11y ago
  I'm not sure I understand. It doesn't matter if the consumer of the certificate is able to set their clock to make the certificate/signature valid because most people don't do that, but if the producer of the signature can simply set their clock to produce a signature/timestamp combination that's considered valid by a consumer regardless of their clock, then what's the point of expiring the certificate? But yeah, it looks like Microsoft countersigns, assuming this is what that original comment was referring to: https://msdn.microsoft.com/en-us/library/windows/desktop/bb931395(v=vs.85).aspx https://msdn.microsoft.com/en-us/library/windows/desktop/bb9...
  - imron 11y ago
    It gets timestamped by the certificate authority, using their authorized servers. For example, I have a code-signing certificate issued by Comodo, and when I sign my software, it get timestamped by: http://timestamp.comodoca.com http://timestamp.comodoca.com I can't simply set that clock.
  - flohofwoe 11y ago
    Yes I should have been more clear. A user which wants to run a signed executable with expired certificate can trick the validation process on his machine by setting the system clock back into the valid period. But for the code-signer this trick doesn't work, the sign-tool needs to talk to a time-stamp server, usually owned by a certificate authority. I know that the Microsoft signtool.exe and the Java jarsigner can use timestamps, apparently on OSX this works too (search for --timestamp cmdline arg: https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man1/codesign.1.html https://developer.apple.com/library/mac/documentation/Darwin...)

kevincox 11y ago

How does this help? In order to provide any security you would need to limit the time from signing, which would be very similar to just issuing the certificate for that much longer. There is no way to verify that the binary was actually signed at that time.

makomk 11y ago
It uses trusted timestamping servers run by certificate authorities to sign the timestamp information.
- kevincox 11y ago
  Ok, I didn't realize that. But it still doesn't solve the problem of compromising an old certificate and creating a fake signature with your own time.
  - wangweij 11y ago
    Expired and compromised are two different things. If compromised, it will be published in a CRL with a reason flag.
    - kevincox 11y ago
      The reason why certificates expire is because they will become easy to crack as computers get faster. So this would effectively be removing the expiry date. Now you can crack any old certificate and sign things claiming that you did it before the certificate expired.
      - markild 11y ago
        As someone above has already said. To do this, you'd need to compromise or convince a trusted timestamping authority to sign your signing request with an old date.
  - khedoros 11y ago

zZorgz 11y ago

Apple's code signing actually has this and it's on by default. Don't ask me why it didn't help with their installers, though..