Why sign your code binaries or documents?
As a software publisher, there are two reasons to sign your code:
- To prove its Integrity
- To develop its Reputation
Best Practice: Time-stamping.
When signing code, as a publisher, you have the opportunity to timestamp your code. Time-stamping adds a cryptographically-verifiable timestamp to your signature, proving when the code was signed. If you do not timestamp your code, the signature can be treated as invalid upon the expiration of your digital certificate. Since it would probably be cumbersome to re-sign every package you’ve shipped when your certificate expires, you should take advantage of time-stamping. A signed, time-stamped package remains valid indefinitely, so long as the timestamp marks the package as having been signed during the validity period of the certificate
If this is the case, it should be safe to distribute the file (or execute the binaries) even after the original certificate used to generate the digital signature, expired. If the signature was not timestamped, then there is a risk that the file/executable will not pass verifications.
When a file is digitally signed and timestamped, the signature will not expire when the certificate expires. The public key accompanying the executable file will still be valid after the signing certificate expires.
This is how a file that is digitally signed and timestamped will look like in a Windows Client OS (properties of the file):
Signing is there to prove that the assembly or file is created by a known person or company, and not changed by anyone else.
When signing an assembly, a hash is created and signed with the private key of the certificate private/public key pairs. That private key is not distributed with the assembly, it stays with the publisher, in this case Microsoft.
The public key of the certificate is, which is what you showed us, distributed with the executable or assembly. To verify that the assembly has not been tampered, you can calculate the hash using the same hashing algorithm specified on the properties of the assembly, for instance SHA1, and compare this hash with the encrypted hash that the assembly signature has, the latter hash should be decrypted with the certificate public key that is distributed with the assembly. If the hashes match, the assembly is the original one published by the publisher.
If the assembly (executable) is changed, for instance by malware, it is easy to find out by checking the hash of the assembly and its signature using the public key (which is included in the executable or file).
This is a verification that antivirus programs and anti-malware programs do.
Digital signing and timestamping is a layer of protection; however, it doesn’t 100% guarantee security, a bad publisher can still do the same and distribute files that are digitally signed and timestamped. The use of Certificate Authorities provide an additional level of trust on the publishers.
If the private key of the certificate used to digitally sign files, is compromised, other files and executables could, potentially, be signed on behalf of the publisher by a malicious attacker, hoping to distribute malware. This though, won’t affect files or executables signed before the breach happened when there is a timestamp. In this scenario, the Certificate Revocation Lists will also be essential to report to the world the blacklisted-invalid certificate.
Thank you for this easily understandable explanation. It helped me to understand the certificate duration logic I wondered about.