Should each project being signed with a separate Strong Name Key (.snk)?

Question

Within my Visual Studio solution I have a web site and 4-5 class library projects which are referenced., some of which reference external third party assemblies as well.

I've been given the task of signing the assemblies for these projects.

My understanding is that the purpose of signing is that not everyone being able to use our assembly without providing its public key and version details, right?

Should I use one single Strong Name Key (.snk) to sign all the assemblies of these projects or each assembly should be signed with a separate strong name key?

What's the purpose of password protection for strong name keys?

How would you do that?

Many thanks,

Hypnotism

The purpose to sign assemblies is to ensure they're original unmodified versions. Everyone will be free to use them (for licensing there are other tools used in conjunction with signing) but they can be sure that they has not been modified (for example by malicious software) and they come from you (because the private key used for signing is...private). – Assiduous

Adriano is correct see... msdn.microsoft.com/en-us/library/h4fa028b.aspx For how see... msdn.microsoft.com/en-us/library/xc31ft41.aspx – Suzannasuzanne

Answer 1

that the purpose of signing is that not everyone being able to use our assembly without providing its public key and version details, right?

No. Signing verifies you, the publisher. It prevents others from making 'fake' versions of your assemblies.

Should I use one single Strong Name Key (.snk) to sign all the assemblies of these projects or each assembly should be signed with a separate strong name key?

The key is your signature so use 1 for all your projects.

What's the purpose of password protection for strong name keys?

The whole signing process hinges on you being the only one who possesses the key. There is no certificate involved. Partial signing and protected keys can help you limit the number of people who have access to the key.

Weeper

thanks. where should the .snk file be stored then? It doesn't need to be put on the production server, right? – Hypnotism

The key will be needed on/by the Build server. – Weeper

could I not reference other third party assemblies which are not signed? It's giving me an error Error 1 Assembly generation failed -- Referenced assembly 'NameOfThirdPartyAssembly' does not have a strong name. – Hypnotism

Correct, all underlying assemblies have to be signed too. Worst case you'll have to sign those 3rd party libs. – Weeper

Just to expand on @Henks response re: sub-assemblies being unsigned... There's no point signing your code if code it relies on can be changed - eg your code thinks it's calling a GetUserDetails() method froma 3rd party which has been swapped for a ReformatHardDisk() in a faked assembly pretending to be from the 3rd party. Signing ensures that all code from that point on is the code that you, the publisher, intended to be executing. – Trevethick

This answer is completely wrong. Strong naming is used to determine whether two binaries are different assemblies, or different versions of the same assembly. It is not used for security. In fact, Microsoft even recommends that open source projects check-in the private key to the repo. For more info, see Authenticode vs. Strong Names. – Loutitia

Answer 2

The purpose of strong named assemblies is to be able to differentiate among versions of the same assembly, not to determine the creator of it.

On the other hand, digitally signing an assembly identifies the builder of that assembly.

The difference between the two kind of signatures is that the first one doesn't need to use the same certificate, because it won't be used to recognize the creator, just to differentiate among different versions of the same binary.
That way you would be able to load two versions of the same assembly within the same process, allowing you to use two versions of the same class without collisions.

The other signature, called Code Signing, uses specially crafted certificates just for code signing, and bundles together with the binary the public certificate with a name usually identifying the builder, together with the certificate chain validating the signature up to a Certification Authority, that can be seen in the file properties using Windows Explorer, the first case can't be seen in Windows Explorer and it could use a self signed certificate created in visual studio without any problem.

Actually, digitally signing code is for all kind of code, it doesn't have to be a .NET assembly, it can be a plain Win32 API DLL or EXE.

Dropkick