Recipe17.10.Preventing Malicious Modifications to an Assembly

Recipe 17.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 backdoor mechanism in attacking a network. Additionally, you do not want other malicious assemblies that look like yours but operate in malevolent ways (e.g., stealing passwords, reformatting a disk drive) to be created. 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 identifies your assembly as being from you. The private key is the part of the pair that you keep secret. It ensures that the assembly came from you and hasn't been tampered with.

In order to generate a key pair, you 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 it carefully; store it only on a machine that's locked down enough to be considered highly trusted. Never make copies of this key, and store it only on a highly trusted machine or on media that are 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 your key pair, use the -p switch on SN.exe to produce the MyPublicKey.snk file that holds your public key:

 SN -p MyKeys.snk MyPublicKey.snk

Now you can delay-sign the assembly using the public key. You should not place the public key in two assembly-level attributes shown here, as you would have done in previous versions of VS.NET:

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

Microsoft has deemed this a security risk. Instead, there is now a tab on the project properties that allows you to add the public key to the project. To add the public key, right-click on the project in the Solution Explorer tab in the IDE and choose Properties. The project properties will be displayed in the IDE in its own window. Click on the Signing tab on the lefthand side of this window; see Figure 17-1. This is the tab that allows you to add the public key to this project. To finish this process, check the Sign the Assembly checkbox and select the public key file that you created by clicking on "<Browse…>" in the "Choose a strong name" key file drop-down box. If this assembly will be delay-signed, check the Delay Sign Only checkbox.

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 results in SignedAssembly being fully signed using the private key in MyKeys.snk. This step is normally performed on a secure system that has access to the private key.

Discussion

Note that in Visual Studio .NET 2005, the private-key file location needs to be relative to the .exe or .dll or you will get an error when you try to sign the resulting assembly.

Figure 17-1. The Signing tab of the project properties

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, use SN.exe to accomplish this:

 SN -Vr *,d15f821006850b34

One other approach is to have separate keys for development and final release versions, which allows for fully signed development versions without compromising the signed assemblies that you ship to customers.

Note that this solution will protect your assembly only as long as the machine it is running on is secure. If a malicious user can access the code that uses the assembly and the assembly itself, he can simply replace them with his own copies.