Recipe 14.10 Preventing Malicious Modifications to an Assembly

Problem

You are distributing an assembly, but you want to ensure that nobody can tamper with the internals of that assembly. This tampering could result in its use to gather sensitive information from a user or to act as a back-door mechanism to attack a network. Additionally, you do not want other malicious assemblies to be created that look like yours but operate in malevolent ways (e.g., stealing passwords, reformatting a disk drive). In effect, this malevolent assembly is created to spoof your benevolent assembly.

Solution

This can be averted to a certain degree by using a strong name for your assembly. A strong named assembly has a digital signature that is generated from a public/private key pair. The public key is the part of the pair that provides something well known that your assembly can use to identify as being from you. The private key is the part of the pair that you keep secret and that ensures that people can trust that the assembly came from you and hasn't been tampered with.

In order to generate a key pair, you can use the SN.EXE from the Framework SDK:

 SN -k MyKeys.snk

This line creates your key pair in a file called MyKeys.snk . Since this file contains both your public and private keys, you need to guard this file carefully ; generate it only on a machine that's locked down enough to be consider highly trusted. Never make copies of this key, and store it only on a highly trusted machine or on media that is easy to secure.

Now that you have a key pair, you can get the public key from the pair in order to be able to delay sign your assemblies. Delay signing allows day-to-day development to continue on the assemblies while a trusted system holds the public/private key pair file ( MyKeys.snk ) for final signing of the assemblies.

In order to extract the public key from our key pair, we use the -p switch on SN.EXE to produce the MyPublicKey.snk file that holds our public key:

 SN -p MyKeys.snk MyPublicKey.snk

Now we can delay-sign the assembly using the public key by placing the public key in two assembly level attributes, like so:

 [assembly: System.Reflection.AssemblyKeyFile("MyPublicKey.snk")] [assembly: System.Reflection.AssemblyDelaySign(true)]

The AssemblyKeyFile attribute tells the compiler where to find the public key to sign with and the AssemblyDelaySign attribute tells the compiler to use the delay signing method.

In order to finish the signing process, once you are ready to deploy your assembly, use SN.EXE again to add the final signing piece, using the -R option like this:

 SN -R SignedAssembly.dll MyKeys.snk

This line would result in SignedAssembly being fully signed using the private key in MyKeys.snk . This step would normally be performed on a secure system that has access to the private key.

Discussion

Note that in Visual Studio .NET 2002, the private key file location needs to be relative to the EXE or DLL, not the project, or you will get an error when you try to sign the resulting assembly.

If you don't want to delay-sign your assembly, you could use MyKeys.snk as the AssemblyKeyFile instead like this:

 [assembly: System.Reflection.AssemblyKeyFile("MyKeys.snk")]

When you do this, you do not need the AssemblyDelaySign attribute anymore.

In order to use delay signing, you need to prepare the development environments for assemblies that are only partially signed. To do this, instruct the CLR to skip verification of assemblies using a given public key. Once again, we use SN.EXE to accomplish this:

 SN -Vr *,d15f821006850b34

One other approach would be to have a separate key for development and final release versions, which would allow for fully signed development versions without compromising the shipping signed assemblies.

Note that this solution will protect your assembly only as long as the machine it is running on is secure. If the malicious user can access the code that uses the assembly and the assembly itself, he can simply replace them with his own copies. Strong naming ensures that the trusted version of the assembly is deployed, but once it has been installed, it can be modified (as can practically anything else on the system).

Recipe 14.10 Preventing Malicious Modifications to an Assembly