How does signing with a strong name protect against forging a set of assemblies?

Signing with a strong name (keypair stored in a .snk file) is (among other uses) meant to protect against forging assemblies.

For example: I ship my assembly signed with a strong name, then some other developer uses my assembly and so his assembly now contains a reference to mine, mentioning the public key of my keypair. Some user inst开发者_Python百科alls that developer assembly and my assembly and happily uses that developer's code. If anyone else tries to produce an assembly that looks like a version of mine and convince the user that it's an "update worth installing" that forged assembly won't load because I control my keypair and that forged assembly is not signed with the same keypair. Okay, cool.

But what prevents a malicious party from forging both my assembly and that dependent assembly of the other developer and "shipping" them both? They grab my assembly and that developer's assembly, tamper both, sign the forged version of my assembly with whatever key, then add a reference to it into the forged version of the dependent assembly, sign it too and then ship both. I mean maliciously "shipping" two assemblies should not be much harder than "shipping" one assembly.

How does signing with strong names protect against forging multiple assemblies?

Strong naming an assembly is really not meant to protect the signed assembly. It is to protect the other assembly that is loading the signed assembly.

For example, if an EXE is trusted and wants to load a known DLL from a known location (such as the GAC, a network share, the internet, etc.) it can do so using a strong name with some level of confidence that the assembly has not been tampered with.

But, if the whole set of assemblies is disassembled then re-assembled and re-signed, then yes, you're right they could just re-write the lines of code that load the rest of the assemblies such that it loads them with the new (fake) key.

But this kind of tampering would be evident. In other words, the strong name signing provides clear evidence of tampering, but doesn't prevent it in all cases. Add to that the fact that a local admin can disable strong name verification altogether (for "development" purposes) and it's obvious that strong name signing is not a bulletproof security mechanism.

Same goes for Authenticode and driver signing though. We've all seen a product out there that instructs users to "ignore the security warning". That's basically what the EXE would be doing if strong name verification were disabled or the entire set of assemblies had their signatures stripped - it would be ignoring the warning.

Strong Naming is all about, well ... "naming". I quote from here: Using Strong Name Signatures

"Strong names offer a powerful mechanism for giving .NET Framework assemblies unique identities."

That's all what you'll ever get from this mechanism. It means I can forge your assembly and all assemblies it references, but I will not be able to pretend "you did it". I will not be able to pretend you are the publisher of these assemblies.