171

In some C# code I have taken over (in Visual Studio 2005), I have noticed that the assemblies are all signed with the same .snk file.

  • Why would the previous author have signed the assemblies in this way?
  • Is signing assemblies necessary and what would be wrong with not signing?
  • What disadvantages are there in signing assemblies - does it cause delays?
Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Craig Johnston
  • 5,303
  • 8
  • 27
  • 30

6 Answers6

199

Why would the previous author have signed the assemblies in this way?

No idea, maybe he wanted all his assemblies to be signed with the same key.

Is signing assemblies necessary and what would be wrong with not signing it?

No, it is not necessary but it is a mechanism allowing you to ensure the authenticity of an assembly. It allows you to ensure that an assembly hasn't been tampered with and indeed it origins from this author. It is also necessary if you want to put them into the GAC.

What disadvantages are there in signing assemblies - does it cause delays?

Signed assemblies can only load other signed assemblies. Also they are tied to a specific version meaning that you need to use binding redirects or recompile the application if you wanted to use a different version. There's a little performance overhead as well due to the verification of the signature but it is so little that you shouldn't be concerned about.

Darin Dimitrov
  • 1,023,142
  • 271
  • 3,287
  • 2,928
  • 2
    Note that verification of signatures does not take place anymore (since .NET 2.0) when placed in GAC; [it only happens once, when adding it to the GAC](http://davidyardy.com/archive/strong-names-and-signing-assemblies-netaspx/). – Abel Oct 12 '16 at 18:25
  • 1
    What do you think about signing it nowadays? On web based systems? If I'm correct, it was only necessary when talking about installed softwares, right? If I publish my app to Azure using TFS, I know it hasn't been tampered, right? Or am I missing some security part? – Rick Wolff May 08 '17 at 14:12
  • On the first question: he made Project Template from a project that had assembly signature key file, then he used that Project Template to create another stuff and forgot to replace the key file. (just replace "he" with "me" and you know what I was doing this morning :) ). So, it is accidental. – hardyVeles Jun 19 '18 at 16:42
37

You need to sign assemblies if you want to put them in the GAC.

If you sign an executable, then any class libraries it links to also needs to be signed. This can be difficult if you're using a third-party library (especially if you need to use an ActiveX control or similar).

Richard Grimes have written a good workshop about security in .NET and that includes a chapter about this: Security Workshop

The reason for all the assemblies being signed with the same .snk file could be if he used unit testing with code coverage. To be able to do code coverage (at least with the tools built into the testing version of Visual Studio 2005) and if the assemblies are signed, you need to specify what .snk files are used for the signing, but I think you can only specify one .snk file for the whole solution, so if you sign the various class libraries with different .snk files you can only check the code coverage on one of them at a time.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Hans Olsson
  • 54,199
  • 15
  • 94
  • 116
22

A very important reason to sign an assembly is so you can be sure it is your assembly. Since the private key is yours, nobody else can sign an assembly with that same key. This means that when the public key of an assembly is one you know (you can retrieve this using the GetType().Assembly.GetName().GetPublicKey() function), the assembly is yours and it has not been tampered with.

Druid
  • 6,423
  • 4
  • 41
  • 56
Pieter van Ginkel
  • 29,160
  • 8
  • 71
  • 111
7

If you would excuse me for answering an old question. But most of the responses here imply that strong-naming provides security. But Microsoft advises against using it for security.

The docs on strong name signing currently says:

⚠ Warning

Do not rely on strong names for security. They provide a unique identity only.

It is mostly useful for ensuring that you have the binary you expected, and not a different binary that incidentally has the same name and version (or version set by binding redirect)

Microsoft lists reasons for using strong-naming:

  • You want to enable your assemblies to be referenced by strong-named assemblies, or you want to give friend access to your assemblies from other strong-named assemblies.
  • An app needs access to different versions of the same assembly. This means you need different versions of an assembly to load side by side in the same app domain without conflict. For example, if different extensions of an API exist in assemblies that have the same simple name, strong-naming provides a unique identity for each version of the assembly.
  • You do not want to negatively affect performance of apps using your assembly, so you want the assembly to be domain neutral. This requires strong-naming because a domain-neutral assembly must be installed in the global assembly cache.
  • You want to centralize servicing for your app by applying publisher policy, which means the assembly must be installed in the global assembly cache.

It also notes:

For .NET Core, strong-named assemblies do not provide material benefits.

and

If you are an open-source developer and you want the identity benefits of a strong-named assembly for better compatibility with .NET Framework, consider checking in the private key associated with an assembly to your source control system.

So, Microsoft says it's okay to just publish your strong-naming private key along with code. Meaning anyone could create strong-named assemblies with the correct public key. I would it say it is safe to assume that strong-naming is not a secure source of Authenticity.

Read more about it here: https://learn.microsoft.com/en-us/dotnet/standard/assembly/strong-named

Triss Healy
  • 478
  • 5
  • 8
  • If you need security check out SignTool.exe https://learn.microsoft.com/en-us/dotnet/framework/tools/signtool-exe and https://learn.microsoft.com/en-us/windows/win32/seccrypto/cryptography-tools – Triss Healy Sep 14 '20 at 07:59
2

Inspite of all the usages of signing dll, the dll should be signed for only two reasons

1. Versioning

2. Authentication

a. Versioning denotes what version the dll has been build on and while pushing them into GAC two dll with same name can exists but different version

b. Authentication denotes whether the dll is not tampered and does exists the same when it was created.

If you want to understand more about the basics and dll signing you can refer here

Karthikeyan VK
  • 5,310
  • 3
  • 37
  • 50
  • 1
    What do you think about signing it nowadays? On web based systems? If I'm correct, it was only necessary when talking about installed softwares, right? If I publish my app to Azure using TFS, I know it hasn't been tampered, right? Or am I missing some security part? – Rick Wolff May 08 '17 at 14:11
  • 1
    I dont see a reason why we should sign a dll now a days, that will be deployed as Paas solution in azure. But if you are having iaas solution, you might reuse the dll by web application in the same iis. Which i don't recommend. we should be calling them thru api url, rather than using those dll's from GAC(microservice architecture). – Karthikeyan VK May 09 '17 at 04:54
2

In addition to existing answers, I would add that you must use the signing when your DLL is going to be dynamically loaded and consumed by 3rd party software. It is not technical requirement per se but it is rational, therefore very common, that the 3rd party software producer enforces such policy due security concerns.

Examples where you must sign an assembly:

  • development of Windows Shell / Windows Explorer extension, like: context menu extension for Windows Explorer
  • development of Visual Studio extensions, like: Project/Item Template Wizard GUI
hardyVeles
  • 1,112
  • 11
  • 13