File Signatures: How do I make sure that a Windows DLL isn't modified?

Question

Hi all.

I once asked a question here if Windows DLLs are signed by Microsoft. I realized they were, and a good friend told me that the SigCheck utility can provide information about the signature of files; but a question remained:

While SigCheck tells me if a file is signed, I need to be sure that Microsoft signed the file and no one else changed it later on. I mean, what if someone tampers the file, and then signs the file again (with the name of Microsoft on the signature, of course)?

How can I be absolutely sure that the file is genuine?

Answer 1

"I mean, what if someone tampers the file, and then signs the file again (with the name of Microsoft on the signature, of course)?"

This is not possible because of the nature of digital signatures. To generate the digital signature, Microsoft hashed the file and then encrypted that hash with their private key (known only to them). As I understand it, other vendors will use private keys from other Certificate Authorities that Windows is configured to trust by default.

When Windows checks the file, it decrypts the signature using the corresponding public key. This signature is then compared to the current signature. If they match, the file is from Microsoft. If they do not match, the file has been tampered with.

Thus the only way you could make a file look like it was "signed" by Microsoft would be to steal their private key. Read the digital signature article on Wikipedia.

For more details on how the process actually works, read "Signing and Checking Code with Authenticode" and "Introduction to Code Signing" on MSDN.

Answer 2

From memory the signing process uses public key cryptography.

This diagram from wikipedia explains the process best.

In summary,

"a message signed with a sender's private key can be verified by anyone who has access to the sender's public key, thereby proving that the sender had access to the private key (and therefore is likely to be the person associated with the public key used), and the part of the message that has not been tampered with."

ie. Sigcheck performs verification using Microsoft's public key on files that were previously signed using Microsoft's private key (and of course only Microsoft have access to the private key).

Answer 3

To build on to what others have already posted:

Disclaimer: MS usage of public/private key terminology w.r.t Digital Signatures used to confuse me a lot. I've just had an 'Aha!' moment. I'll try to share my thoughts in case it helps someone.

Enter PPK

---

The general Public-Private key scheme works by generating a pair of keys that are asymmetric. You cannot derive one from the other (by viable means). One of them is called the private key and the other, the public key.

For one-to-many communication, you will hold on to the private key and share the public key. Your friends who'd want to share documents with you will sign them with your public key. You will decrypt these with your private key. Note it doesn't matter which particular key you keep and which you distribute. Just don't give out both.

Why are DigSigs different?

---

Digital signatures are a bit odd. It's a many-to-one situation. To continue the previous example: Think of the situation where you'd want to share documents with your friends. You'd need to sign them i.e. encrypt and your friends need to be able to decrypt. So, you still share your public key, but sign with your public key instead and send it out. Your friends already have this key and they happily decrypt. In this case, your public key acts as a private key and your private key acts as a public key.

The above is what MS does with its dlls.

Client side validation

---

Now, for the validation part. A certificate generated by MS is no good until a Certification Authority says it is good. This holds for anyone. If you want to do business securely you have to get a certificate from a CA. Once your client installs your application, the OS's validation program will rip your certificate out and put it to a test by verifying something called a chain of trust . It will check who certified your signature. This is the parent certificate. If the system can identify the parent, they're done and you're accepted. If however, the parent be cannot be verified, the parent's parent is called upon. And the chain continues, until a node can be found that can be verified. If no node is found, they'll report it as unsigned, unsafe.

Note that certificates can be revoked. So, a certificate doesn't mean that you're good. This is another reason why the verification process becomes important.