First of all, sign it to give it a strong name (standard operation with Visual Studio). Please see:
http://msdn.microsoft.com/en-us/library/wd40t7ad.aspx[
^].
To be able to compile the application, you will have to sign all assemblies referenced by your application assembly, but you want it, too.
This simple measure already protects the code from modification: if you change anything in the assembly, if will fail to load, which saves you from, say, infecting the system if some modules are infected by a virus, and it also will indicate that the assembly was modified.
But this is not all. What is someone replaces, say, entry-level assembly of the application (this is just the simplest variant of exploit) with some other assembly, also signed and similar in behavior, with the same name of the executable module (PE file)? Such trick could also be done using reverse engineering.
In this case, you can publish a
public key of the key pair and provide an application for validation that the assembly in question is signed with the authentic key pair. If the assembly passes such verification, it means it is authentic. It is impossible to craft the key pair and sign the fake assembly by the known public key. To make sure the checkup application itself is not fake, it could be, for example, presented in source code. The user does not need Visual Studio or any skills to build it, as MSBuild and compilers are a part of .NET Framework, so a simple batch file would do a build (just an idea, any schema when a use can have some trusted application would work). Please see:
http://blogs.msdn.com/b/shawnfa/archive/2004/06/07/150378.aspx[
^].
Some background: to understand the security scenarios, you need to understand how
public-key cryptography works:
http://en.wikipedia.org/wiki/Public-key_cryptography[
^],
http://en.wikipedia.org/wiki/Digital_signature[
^].
Now, a simpler and cheaper alternative: you can calculate the
cryptographic hash function of all the PE files of your application (or ZIP file containing all the files) and publish it. The user can easily validate that the hash matches the required hash data. It is
infeasible to fake the files the way giving the same hash. Please see:
http://en.wikipedia.org/wiki/Cryptographic_hash_function[
^].
Only, if you really need security, don't use MD5 or SHA-1 as many do. These functions were found broken. But a function from the SHA-2 family, in particular, will do well. Please see:
http://en.wikipedia.org/wiki/MD5[
^],
http://en.wikipedia.org/wiki/SHA-1[
^],
http://en.wikipedia.org/wiki/SHA-2[
^].
With .NET, you have enough algorithms already implemented for you:
http://msdn.microsoft.com/en-us/library/system.security.cryptography.hashalgorithm.aspx[
^].
Even if you use the cryptographic hash function way, still do sign all the assemblies if you deploy them anywhere: won't hurt.
—SA
Submit an article or tip