SN Tool in .NET


Assemblies can be digitally signed with a strong name, which consists of a public key, simple text assembly name, version number, and culture. The public key provides an assembly with a unique name, and strong-name signing assures users that the assembly has not been altered since being signed. Strong names use public-key encryption and digital signature techniques to guarantee secure code distribution. Code signing prevents attacks from hackers who tamper with code or impersonate the identity of a publisher. 

Code signing uses Public-Key Infrastructure (PKI) methods to give your code a unique identity. These PKI methods are complex mathematical functions used to prevent others from assuming the publisher's identity. Code signing ensures that your code has not been tampered with after you signed it. 

You can use the Strong Name command-line tool (Sn.exe) for many purposes when working with shared components that reside in shared assemblies. You can generate a new public-private key pair and write that pair to a file by adding the -k option to the following command: 

sn -k <outputfile> 

You can verify an assembly has a strong-name signature with the -v[f] option, as follows: 

sn -v[f] <assembly> 

You can verify that a particular assembly is signed using a particular key file. 

You can extract a public key from a key pair in a file and export it to a separate file with the -p option, as specified in this command: 

sn -p <inputfile> <outputfile> 

You can verify that the same key pair signed both components if the –t and –T options on the following commands produce the same key token: 

sn -t <outputfile> 

sn -T any.dll 

One last example illustrates the two steps needed when you want to attach a strong-name signature to your code:

  1. Create the strong-name key and compile your assembly with key you generated. You create a key pair and view the public key portion. Then you need to make an identity demand for code signed with the corresponding private key. 

    sn -k mykeypair.dat 
    sn -p mykeypair.dat mypublickey.dat 
    sn -tp mypublickey.dat
  2. Now add a declaration to the code in your assembly to indicate the location of the file generated in step one, as shown in Listing 22.11.

Listing 22.11: AssemblyKeyFile 

public class MyClass

The SN tool offers yet another feature: the delayed signing of an assembly. In simple terms, this feature reserves a place for the signature in the assembly manifest, but you do not initially sign the assembly with a private key. In delayed signing, the SN signature is applied after the assembly has been built and tested. Bear in mind that assembly developing and publishing tasks can be separated and assigned to different people. Delayed signing is helpful when the assembly's developer does not have access to the private key that will be used to generate the signature-a common occurrence during the development and testing phase of applications. (In fact, it is a good security practice to limit the number of people who have access to the private key.) 

When the assembly is built with AssemblyDelaySign set to true, as shown here, the CLR books space for the strong-name signature and stores the public key in the assembly. 

[assembly:AssemblyDelaySign (true)]

Please note that the /delaysign+ and /keyfile options can also be used with the Assembly Generation tool (Al.exe) to create delay-signed assemblies. 


Hope this article would have helped you in understanding the SN Tool in .NET. See other articles on the website on .NET and C#.

visual C-sharp.jpg