I have been reading the proper article in MSDN, Strong-Named Assemblies and a related Stack Overflow question, Checking an assembly for a strong name.
- To which extent can a strong-named assembly be verified to avoid tampering?
- Is it possible to use strong-naming to verify an assembly author?
The first question arises after reading the CSharp411 article .NET Assembly FAQ – Part 3 – Strong Names and Signing, which mentions this, among other problems of using strong names:
"Cannot Stop Full Replacement. Strong names cannot prevent a hacker from removing the strong name signature, maliciously modifying your assembly, re-signing it with his own key, and then passing off his assembly as yours."
The second question intends to find the differences between strong naming and other signing schemes like, say, Authenticode. The same MSDN article mentioned early states:
"Note, however, that strong names in and of themselves do not imply a level of trust like that provided, for example, by a digital signature and supporting certificate."
Am I trying to use strong-naming for much more than it was created for? Was strong-naming created just to avoid name clashes or a new kind of "GAC DLL Hell"?
Best Answer
When you sign an assembly with a strong name based on a private key that you create, this has the following benefits:
Yes, as discussed above strong-naming can verify the assembly's latest author. But it doesn't verify the original author. If an attacker replaces your assembly's strong name, then all that can be verified is that you weren't the latest author of the assembly. If he removes the strong name, then no author verification can be done at all.
The following C# code verifies that an attacker hasn't tampered with the public key token that was written to your assembly when you applied the strong name. It doesn't avoid tampering, but it can detect some types of tampering. The method below accepts a byte array containing your public key token, and compares it with the actual token of the assembly. Note that for this technique to be effective, your obfuscator of choice should encrypt the string containing your public key token, and only decrypt it on the fly as it's used. And also be aware that you need to have FullTrust permission for this code to work because it uses reflection underneath the hood.
As long as you're running under a version of the .NET Framework before .NET 3.5 SP1, you can also force verification of the strong name signature in case the strong name was removed by an attacker or the strong name check was disabled in the registry. The following code demonstrates a call into a static method of another class called NativeMethods. This is where the verification will be enforced.
The actual signature verification is done using P/Invoke as shown below. The usage of the StrongNameSignatureVerificationEx API is quite convoluted - for a decent explanation, see this blog entry.
Note that this won't work by default for applications using .NET 3.5 SP1 or higher, which has the strong name bypass feature. It's possible to disable this feature for your application by adding a setting to its config file. But of course any attacker with read/write access to that config file can reverse your decision.