1

My company has recently taken over another company and we are currently looking at the problem of making one of the new acquisition's regular releases. The product is a plugin for a third-party software product; the plugin provides functionality (the ability to query a valuable dataset) which is also offered through a dedicated application which is another of the new acquisition's releases.

In the code shared with the dedicated application, we defend against data being extracted from the application in volume by requiring that the assembly invoking our code has to be signed using our certificate. This is done by checking that the public key in the assembly's FullName has the correct value (string representation of our certificate's public key). I do not have a good understanding of security-related matters but I have seen a number of resources specifically discouraging the use of "strong naming" for security purposes, which gives me cause for concern that this may not be a meaningful security measure.

In the plugin, the functionality is exposed through a Plugin class which inherits from a base class defined in DLLs we have been given by the developers of the host application. (The framework used for the host/plugin system is the stuff in the System.AddIn namespace in the .net standard library; the plugin runs as a separate process.) Unfortunately, those DLLs are not signed by the developers of the host. We therefore cannot sign our plugin, and our security check will block the plugin from working unless it is signed. (We are told that the host application executable is signed.)

Does the check on the public key contained in the FullName property of the invoking assembly actually accomplish anything? Could someone spoof it if they wanted to crack our application? If it does in fact accomplish something (if it makes it infeasible to spoof signing of the invoking assembly) then how might we get around the fact that we can't sign our DLL? That is to say, how can we make our plugin work in the host application while keeping control over how our code is executed? It is not enough to "whitelist" the public key used to sign the host application, because it runs as a separate process.

The previous releases of the software are believed to have had this check disabled, but obviously this is not desirable; either the check adds no value and we should remove it everywhere, or it does add value and we would prefer not to remove it from anything.

Hammerite
  • 21,755
  • 6
  • 70
  • 91

1 Answers1

0

If you're verifying the strong name matches the one you're expecting (including public signature), then you are verifying that it has not been tampered with.

That is you are verifying the assembly is what you expect, however unless you know exactly what that assembly is doing you should not trust it.

This holds true as long as the private key has been kept secure. If this has been leaked at any point then an attacker could have used it to sign another assembly.

See this answer for more info.

Community
  • 1
  • 1
SilverlightFox
  • 32,436
  • 11
  • 76
  • 145