Signing .NET assemblies

I'm trying to get a grasp of formal signing of .NET dlls/assemblies.

In particular

• When and how to use private keys
• Best pra开发者_开发问答ctices for creation/control of private keys
• What sort of modules need to be signed/ best practice for going about it

See Using Strong Name Signatures for a very good article on signing.

If we are talking strong naming of assemblies then signing should be used to prevent a third party from "spoofing" your code. The strong name is part of your assembly so another assembly with the same name and a different signature is a different assembly. This also prevents assemblies from being modified and re-signed (without the private key).

To be useful, the private key must be kept private. This is usually done through delayed signing and careful management of private key access.

You can also use Authenticode (to sign your strong named assemblies); this can add confidence about who the assembly is actually from.

1. When you want your consumers to know that the assemblies are indeed from you (and not an imposter)
2. Private keys for an entity/organization should be accessible only to a select few and kept under lock-n-key. Use delay-signing during development.
3. Ideally you should sign all your managed assemblies.

Don't confuse strong name signing with Authenticode signature

As popularly described by Microsoft (I asked a book's author directly about that) strong name is a form of versioning only, not authentication. An assembly is stored in GAC also by strong name public key for reliability purporses (you publish a new version of a library, the previous doesn't get overwritten to prevent regression bugs in the old app).

I'm not 100% sure, but Mono's System assemblies match the Microsoft's public key. Not really a form of security.............

Authenticode signing, instead, is used to perform code authentication. You need a paid certficate from a trusted CA and sign your assemblies with signtool.exe or Visual Studio.

All that has been said here about security, sign servers, etc. applies here. But the point is that you didn't specify what kind of signature you want to put into code.

* When and how to use private keys
* Best practices for creation/control of private keys

You create and use a Key-Pair (file.SNK). Only create it once (for your company/department) and keep it safe.

* What sort of modules need to be signed/ best practice for going about it

You need to sign libraries that go into the GAC. But it is a best practice to sign all assemblies you ship.

When reliability of this signature is very important you use "Partial signing" and a final signing just before shipping. This means that not every developer needs access to the (real/full) key pair.

Usually, code signing is useful for when your product is software or you work in an environment where every piece of software is under scrutiny. By signing your office's custom software, you can place it in a higher trust relationship than others.

Usually, you generate the private key and then when you go to build, you can attach that private key on a build server. This prevents developers around the company having access to the private key.

What you sign is completely up to you. I would say the modules that are most prone to absolutely not working given a certain trust environment need to be signed....for example, DLLs that access file system objects or database connection strings. I would just get in the habit of signing the least amount of code and then build up from there, otherwise, you risk having everything signed and then it is assumed that everything in your organization is safe to run. Again, it all depends on your level of security concerns in your organization.