Securing an Assembly using Strong Naming                                        
•        Given that an assembly can be so easily altered via roundtrips, how might we prevent evil doers from
tampering with our assembly contents?
•        Strong naming can be used to prevent evil doers from successfully performing a roundtrip and then
claiming the modified assembly came from the original point of origin.
•        When you given an assembly a strong name, others cannot pretend to be you (where ‘you’ could
simply represent your company, a department within your company or literally you).
•        As you may know, the only way to deploy an assembly to the GAC is by assigning the assembly a
strong name.
•        However, it is a .NET best practice to give every assembly a strong name.
•        Even if an assembly is not intended to be shared, strong naming helps prevent successful round trips.
•        A strong name represents a collection of values assigned to an assembly.  Specifically, a strong name
consists of:
•        The friendly name of an assembly (file name minus file extension).
•        The version of an assembly (via the [AssemblyVersion] attribute).
•        The ‘culture’ of the assembly (via the [AssemblyCulture] attribute).
•        The public key value (via the [AssemblyKeyFile] attribute).
•        An embedded digital thumbprint created using a hash of the assembly’s contents and the private key
value.

•        The public and private key values used to create a strong name are obtained using the sn.exe utility.
•        The -k flag generates a new *.snk file which contains the necessary information.
sn.exe –k myKey.snk
•        To inform the compiler where to locate the *.snk file, make use of the [AssemblyKeyFile] attribute:
// C#
[assembly: AssemblyKeyFile(@"C:\MyKey\myKey.snk")]

' VB
<Assembly: AssemblyKeyFile("C:\MyKey\myKey.snk")>
•        Multi-file assemblies can also be supplied with a strong name, however this must be done using the
assembly linker utility (al.exe):
•        The /keyfile flag allows you to specify the *.snk file.
al /out:MyMultiFileAsm.dll /target:library /culture:""
/version:1.0.0.0
/keyfile:myKey.snk LibOne.netmodule LibTwo.netmodule

•        You can also generate key files using Visual Studio.
•        Open the property page for your project and click on the Signing tab.
•        Click on the Sign the Assembly checkbox.  
•        This will enable the drop down list box.  Here you can elect to generate a new *.snk file or browse for
an existing file.
•        Using this approach, there is no need to modify your assemblyinfo.* file using the [AssemblyKeyFile]
attribute.


•        The public and private key values within the *.snk file are processed as so:
•        The public value is fully recorded in the assembly manifest (evil-doers cannot do any harm only
possessing a public key).
•        A digital signature is created based on the private key and a hash code generated using the assembly
contents (CIL code / metadata).
•        This digital signature is encrypted and embedded into the assembly.


•        When loading an assembly, the CLR verifies the digital signature:
•        The embedded digital signature is decrypted using the public key.
•        The current assembly’s hash is then recomputed.
•        If the hash values match, the CLR knows the assembly has not been tampered with after deployment.
•        If the hash codes do not match, the CLR refuses to load the binary and throws a runtime
FileLoadException.

•        This same verification check occurs when installing an assembly into the Global Assembly Cache
(GAC).
•        If the CLR determines an assembly has been tampered with, it will not install into the GAC.

Strong Names as a .NET Identity                                
•        A common mistake regarding strong names is to assume each assembly needs a unique *.snk file.
•        This is (usually) the incorrect approach, as the *.snk file represents your identity in the world of .NET.
•        A single *.snk file is used to sign all assemblies which come from the same point of origin.
•        Large companies may define unique keys on a per department basis.
•        Smaller shops may have a single company wide key.
•        Finally, individual developers may have a unique key for their own projects.
•        Recall that a ‘public key token’ is a hash of a full public key.
•        Given this, consider the GAC.  
•        Same token?  Same *.snk file, same place of origin.
•        Notice how the Microsoft Office assemblies have the same public key token.
Strong Naming
Table of Contents
Copyright (c) 2008.  Intertech, Inc. All Rights Reserved.  This information is to be used exclusively as an
online learning aid.  Any attempts to copy, reproduce, or use for training is strictly prohibited.
Courseware
Training Resources
Tutorials