Back to VSLive! San Francisco Show Daily Home

	email article
	printer friendly
	more resources

Secure .NET Source Code
Use free tools to help you secure your .NET code.
by Gabriel Torok

VSLive! San Francisco, March 23, 2004

Note: Gabriel Torok is presenting ".NET Application Code Security" at VSLive! San Francisco on Thursday, March 25. Here, he highlights a few free tools you should use to produce more secure .NET code.

Dotfuscator
Are you aware that you might be shipping your source code with your .NET application? The richness and flexibility of the .NET architecture has the side effect of allowing anyone with access to your binaries to recover a good approximation of the original source code with little effort. With that said, this should not be a risk or a showstopper.

Organizations concerned with protecting their intellectual property or information held in .NET source code should understand that a solution exists to help thwart reverse engineering. Visual Studio .NET includes a tool called Dotfuscator Community Edition that raises the bar against reverse engineering. If you do not want the same group of people who have access to your .NET program to have access to the source code, then take the extra step and obfuscate it. (Dotfuscator Professional Edition, which offers further protection features, is also available.)

FxCop
FxCop is a code analysis tool that checks .NET managed binary assemblies (not source code) for adherence to the Microsoft .NET Framework Design Guidelines. You should consider running FxCop against every assembly you develop. It won't find all your vulnerabilities, but it's a good place to start. Click here for the list of security guidelines.

Strong Naming Tool
It's a good idea to strong-name your .NET applications. A strong name's value lies in the protection it might offer your assemblies. The .NET Framework uses strong names to identify assemblies and help protect them from tampering. Strong names use the cryptographic concepts of hashing and digital signatures. You use hashing to create a unique, compact value for a plain-text message, which in this case, is your assembly.

If two assemblies produce the same hash value, you can assume the assemblies are the same. And if hashing an assembly produces a value inconsistent with a previously computed hash, you know that the assembly's contents have been altered. Knowing the hash value for an assembly lets you verify that no one has tampered with it. But you also need to make sure that someone does not tamper with the hash itself. That's where digital signing comes in.

A digital signature relies on a pair of related numbers: the public key and the private key. When data is encrypted with the public key, it can be decrypted only with the private key and vice versa. So you use your private key (which you keep hidden and super secret) to sign the hash value. Then both your public key and private key are stored with your assembly. When your program is executed, the CLR validates assemblies by comparing the computed hash value from the assembly with the stored value of the hash (after decrypting with the public key). If the two hashes match, the program runs. If they do not, the CLR will not load the assembly.

Understand that this might guarantee the integrity of the assembly, but not its safety. There's nothing to prevent someone from creating a nefarious assembly and signing it with a strong name. The strong name might verify that an assembly came from a particular source and that it wasn't tampered with after it was signed. But it's up to you to decide whether you trust code from that particular source.

Both the .NET Framework SDK and Visual Studio .NET provide tools for assigning strong names.

About the Author
Gabriel Torok is president of PreEmptive Solutions, a leading provider of advanced Java and .NET obfuscation tools offering protection, optimization, and size reduction. He is a book author and active national conference speaker.