This article has been
excerpted from book "The Complete Visual C# Programmer's Guide" from the Authors
of C# Corner.
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:
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
- 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
[assembly:AssemblyKeyFile("mykeypair.dat")]
public
class MyClass
{
//class
}
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.
Conclusion
Hope this article would have helped you in understanding the
SN Tool in .NET. See other articles on the website on .NET and C#.
|
The Complete Visual
C# Programmer's Guide covers most of the major components that make
up C# and the .net environment. The book is geared toward the
intermediate programmer, but contains enough material to satisfy the
advanced developer. |