- Modules Defined
- Assemblies Defined
- Assembly Names
- Public Keys and Assemblies
- The CLR Loader
- Resolving Names to Locations
- Versioning Hazards
- Where Are We?
This chapter is from the book
This chapter is from the book
This chapter is from the book
Public Keys and Assemblies
The CLR uses public key technology both to uniquely identify the developer of a component and to protect the component from being tampered with once it is out of the original developer's hands. Each assembly can have a public key embedded in its manifest that identifies the developer. Assemblies with public keys also have a digital signature that is generated before the assembly is first shipped that provides a secure hash of the assembly manifest, which itself contains hashes of all subordinate modules. This ensures that once the assembly ships, no one can modify the code or other resources contained in the assembly. This digital signature can be verified using only the public key; however, the signature can be generated only with the corresponding private key, which organizations must guard more closely than their source code. The current builds of the CLR use RSA public/private keys and Secure Hash Algorithm (SHA) hashing to produce the digital signature. Although the private key used to sign the assembly is a unique fingerprint for each organization, it does not provide the same level of nonrepudiation that digital certificates provide. For example, there is no way to look up the developer's identity based solely on an assembly's public key. The CLR does provide support for embedding digital certificates into assemblies, but that is outside the scope of this chapter (for more information, see Chapter 9).
The .NET SDK ships with a tool (SN.EXE) that simplifies working with public and private keys during development and deployment. Running SN.EXE with the -k option creates a new file that contains a newly generated public/private key pair. This file contains your private key, so it is critical that you practice safe computing and do not leave this file in an unsecured location. Because the private key is so critical, most organizations postpone the actual signing of the assembly until just before shipping, a practice called delay signing. To allow all developers in an organization to access the public key without having access to the private key, SN.EXE supports removing the private key portion using the -p option. This option creates a new file that contains only the public key. The conventional file extension for both public/private and public-only key files is .SNK.
The public key produced by SN.EXE is a 128-byte opaque algorithm-specific structure with an additional 32 bytes of header information. To keep the size of assembly references (and their display names) compact, an assembly reference can use a public key token, which is an 8-byte hash of the full public key. The assembly references emitted by most compilers use this token in lieu of the full public key to keep the overall size of the manifest small. You can calculate the token for a public key by using SN.EXE's -t or -T options. The former calculates the token based on an .SNK file containing only a public key. The latter calculates the token based on a public key stored in an assembly's manifest. Figure 2.6 shows the SN.EXE tool in action.
)
Figure
2.6: Managing Public/Private Keys Using SN.EXE
Development tools that support the CLR must provide some mechanism for developers to sign their assemblies, either via custom attributes or command-line switches. The System.Reflection.AssemblyKeyFile attribute tells the compiler where to find the .SNK file that contains the developer's public key. This attribute will work with either the public/private key pair or the public-only key, something that allows developers to build, test, and debug their components without access to the organization's private key. In order to build an assembly using only a public key, you must also use the System.Reflection.AssemblyDelaySign attribute to inform the compiler that no private key is present and that no meaningful digital signature can be produced. When delay signing is used, space is reserved for the digital signature so that a trusted member of the organization can re-sign the assembly without having to replicate the original developer's build environment. In general, assemblies that have a public key but do not have a valid signature cannot be loaded or executed. To allow delay-signed assemblies to be used during development, this policy can be disabled for a particular assembly or public key using the -Vr option to SN.EXE. Figure 2.7 shows the AssemblyKeyFile attribute used from C#. This figure also shows the resultant assembly as well as another assembly that references it. Note that the 128-byte public key is stored in the target's assembly manifest along with a digital signature to protect the assembly from tampering. Also note that the second assembly, which references the target, contains only the 8-byte public key token. Because the target assembly was built with delay signing turned off, the assembly can now be deployed and loaded in secured environments. In contrast, the target assembly produced by the C# compiler shown in Figure 2.8 is not suitable for deployment because it is built with delay signing turned on. However, after a trusted individual signs the assembly with the private key, the assembly is ready to be deployed. Note that in this example, the SN.EXE tool is used with the -R option, which overwrites the digital signature in the target assembly with one based on the public/private key provided on the command line. To manually verify that an assembly has been signed, you can use SN.EXE with the -v or -vf option. The latter overrides any configured settings that might disable signature verification.
)
Figure
2.7: Strong Assembly References
)
Figure
2.8: Delay Signing an Assembly