This post is the result of additional research started by this comment. A Cryptographic Service Provider (CSP) must be digitally signed by Microsoft before it can be installed and used on Windows. But this digital signature is technically very different from AuthentiCode and serves another goal.
AuthentiCode uses digital certificates, a certificate is a digitally signed document which links a public key to an identity. Code signing is performed to link software to its author and to allow detection of program alteration. AuthentiCode is also used by Microsoft to digitally sign device drivers. In this case, the signature is used to show that the driver passed Microsoft’s testing program (the signer is Microsoft Windows Hardware Compatibility Publisher)
A CSP must also be signed by Microsoft, but the technique is different from AuthentiCode. Microsoft will sign the hash of the CSP. This signature can be stored inside the file as a resource (ID 0x29A or 666) that is 144 bytes long, or inside the registry as a blob of 136 bytes. When I looked at several signatures inside CSPs, I noticed that the first 8 bytes were almost always identical and hence are probably not part of the actual signature (144 – 8 = 136).
Since the length of the signature is constant and very short, it cannot be a certificate. Neither can it be decoded as a certificate. My educated guess is that this signature is nothing more than the cryptographic hash of the file encrypted with a private key kept by Microsoft. Checking the signature is thus done in Windows by calculating the hash of the file, decrypting the signature with the public key and comparing the hash with the decrypted signature. Equality shows that the signature is valid. The use of the cryptographic hash ensures that is virtually impossible to modify the file while keeping the same hash, and the use of the private key guards the hash from forgery.
This is an example of the signature inside CSP rsaenh.dll viewed with the free XN Resource Editor:
A signature for a CSP can only be obtained by providing documents to Microsoft promising to obey various legal restrictions and giving valid contact information. Thus the goal of the signature is to proof that Microsoft and the CSP author promise to obey the restrictions on cryptography. But I’m not a lawyer, the formulation of this goal is the result of my inadequate legal skills.
I was also told that Microsoft will perform some testing, but I haven’t yet received confirmation or details about this.
We had to go thru this a couple of years ago and were only required to provide the hash of the file to be signed. That makes it kinda hard for them to do any testing. On top of this, we just used a stub CSP that then calls the real DLL to do the work. Now we have a signature that we can use on any CSP we care to implement.
Comment by oldami — Wednesday 23 January 2008 @ 13:30
Thanks for the info. That’s a clever trick, I don’t suppose your CSP is public?
Comment by Didier Stevens — Tuesday 29 January 2008 @ 20:08