----------------------------------------------------------- New Message on MumbaiUserGroup
----------------------------------------------------------- From: hereiam_always Message 1 in Discussion Hi All, This is what i found out on some website regarding Strong names and assemblies. I think this will help in understanding the issues... Strong name signatures (and signing in general) are a key facet of Microsoft® .NET Framework security. But regardless of how well designed .NET signatures may be, they wont offer the maximum benefit if you dont know how to use them properly. This installment of CLR Inside Out talks about strong names, strong name signatures, and how to use them.<o:p></o:p> A Short Refresher<o:p></o:p> Digital signatures are used to verify the integrity of data being passed from the originator (the signer) to a recipient (the verifier). The signatures are generated and verified using public key cryptography. The signer of a message has a pair of cryptographic keys: a public key, which everyone in the world knows, and a private key, which is kept secret by the signer. The verifier knows only the public key, which is used to verify that the signer knew the private key and the message.<o:p></o:p> In some cases, when some additional infrastructure is in place, digital signatures can also be used to reliably learn the name of the signer, and to ensure some chunk of data (a message, some code, or so on) has not been modified after the signer created the signature for the data.<o:p></o:p> Various mechanisms are used to implement digital signatures. The current implementation of strong names in the .NET Framework relies on the RSA public key algorithm and the SHA-1 hash algorithm.<o:p></o:p> Back to Contents<v:shapetype id=_x0000_t75 stroked="f" filled="f" path="[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@5xe" o:preferrelative="t" o:spt="75" coordsize="21600,21600"> <v:stroke joinstyle="miter"></v:stroke><v:formulas><v:f eqn="if lineDrawn pixelLineWidth 0"></v:f><v:f eqn="sum @0 1 0"></v:f><v:f eqn="sum 0 0 @1"></v:f><v:f eqn="prod @2 1 2"></v:f><v:f eqn="prod @3 21600 pixelWidth"></v:f><v:f eqn="prod @3 21600 pixelHeight"></v:f><v:f eqn="sum @0 0 1"></v:f><v:f eqn="prod @6 1 2"></v:f><v:f eqn="prod @7 21600 pixelWidth"></v:f><v:f eqn="sum @8 21600 0"></v:f><v:f eqn="prod @7 21600 pixelHeight"></v:f><v:f eqn="sum @10 21600 0"></v:f></v:formulas><v:path o:connecttype="rect" gradientshapeok="t" o:extrusionok="f"></v:path><o:lock aspectratio="t" v:ext="edit"></o:lock></v:shapetype><v:shape id=_x0000_i1025 style="WIDTH: 13.5pt; HEIGHT: 6pt" type="#_x0000_t75" alt="Back to top"><v:imagedata o:href="http://msdn.microsoft.com/msdnmag/images/top.gif"; src="file:///C:\DOCUME~1\Nilesh\LOCALS~1\Temp\msohtml1\01\clip_image001gif"></v:imagedata></v:shape><o:p></o:p> Strong-Name Signing<o:p></o:p> Strong names offer a powerful mechanism for giving .NET Framework assemblies unique identities. The strong name for an assembly consists of five parts: a public key, a simple name, a version, an optional culture, and an optional processor architecture. The public key is an RSA public key. The simple name is just a text stringusually the name of the file (without the extension) that contains the assembly. The version is a four-part version number, in the form of Major.Minor.Build.Revision (for example, 1.0.0.1).<o:p></o:p> To get a valid strong name, an assembly is strong-name signed during the build process. This is done using the private key that corresponds to the public key in the strong name. The strong name signature can then be verified using the public key. There are a few different techniques for creating a strong name signature and for managing the private key used in signing. Ill discuss these various techniques later in the column.<o:p></o:p> When one assembly references a strong-named assembly, the referring assembly captures the strong name information for the referenced assembly. When the .NET Framework loads a strong-named assembly, it verifies the strong name signature. If the strong name signature of the assembly cannot be verified, the .NET Framework will not load the assembly.<o:p></o:p> One exception to this process has to do with strong-named assemblies that come from the Global Assembly Cache (GAC). These are not verified each time the .NET Framework loads them. This is because assemblies in the GAC are verified when installed in the GAC. Since the GAC is a locked-down, admin-only store, assemblies located here do not need to be verified each time they are loaded.<o:p></o:p> Back to Contents<v:shape id=_x0000_i1026 style="WIDTH: 13.5pt; HEIGHT: 6pt" type="#_x0000_t75" alt="Back to top"> <v:imagedata o:href="http://msdn.microsoft.com/msdnmag/images/top.gif"; src="file:///C:\DOCUME~1\Nilesh\LOCALS~1\Temp\msohtml1\01\clip_image001gif"></v:imagedata></v:shape><o:p></o:p> Why Use Strong Names?<o:p></o:p> Strong names prevent spoofing of your code by a third party (that is, of course, as long as you keep the private key secure). As mentioned, the NET Framework verifies the signature either when loading the assembly or when installing it in the GAC. Without access to the private key, a malicious user cannot modify your code and successfully re-sign it.<o:p></o:p> Given that strong names prevent spoofing, they can be used to make certain security decisions. An enterprise, for example, could choose to trust all code that comes from the enterprises intranet and has been signed with the enterprises strong name key. But strong name signatures do not contain any reliable information about the publisher, so while it is safe to trust keys you control, it is dicier to trust keys from other organizations unless you have a secure channel to get their public key.<o:p></o:p> It is also important to note that strong names do not have any revocation mechanism that can be used if the private key is compromised. It goes without saying that if you plan to use your enterprises strong name for trust, keep the private key private! (Ill have tips for this later in the column.) Its a good idea to scope the trust of a strong name to a particular location (such as your enterprises application server) or at least a zone (such as your intranet zone). This provides some mitigation in case your private key is ever compromised or a buggy version of a signed assembly makes its way to some bad guys and they try to lure users into running it from outside the intranet.<o:p></o:p> Back to Contents<v:shape id=_x0000_i1027 style="WIDTH: 13.5pt; HEIGHT: 6pt" type="#_x0000_t75" alt="Back to top"> <v:imagedata o:href="http://msdn.microsoft.com/msdnmag/images/top.gif"; src="file:///C:\DOCUME~1\Nilesh\LOCALS~1\Temp\msohtml1\01\clip_image001gif"></v:imagedata></v:shape><o:p></o:p> What Strong Names Cant Do<o:p></o:p> Strong-name signing is useful for preventing a malicious user from tampering with an assembly and then re-signing it with the original signers key. It cannot do anything, however, to prevent a malicious user from stripping the strong name signature entirely, modifying the assembly, re-signing it with his own key, and then passing off the assembly as his own code. Digital signatures in general and strong name signatures in particular cannot help with this problem. Watermarking is a more appropriate solution for protecting against this scenario.<o:p></o:p> Strong names are secure only when the strong name private key is kept secure. As I mentioned earlier, they have no revocation capabilities and they dont expire. Nor do strong names inherently provide any way to securely map a public key to a particular publisher. Thus, strong names should be used very cautiously when making security decisions. Ideally, these security decisions should only be made when you can be sure the strong name public key corresponds to a particular publisher (for example, when the public keys are generated by your organizations IT department). You should note that more sophisticated signing schemes (for example, Authenticode®) are available that do offer revocation and publisher verification capabilities.<o:p></o:p> Back to Contents<v:shape id=_x0000_i1028 style="WIDTH: 13.5pt; HEIGHT: 6pt" type="#_x0000_t75" alt="Back to top"> <v:imagedata o:href="http://msdn.microsoft.com/msdnmag/images/top.gif"; src="file:///C:\DOCUME~1\Nilesh\LOCALS~1\Temp\msohtml1\01\clip_image001gif"></v:imagedata></v:shape><o:p></o:p> Working with Strong Names<o:p></o:p> Strong-name signing is a good idea for most applications, especially those that are deployed over a network or any medium not fully controlled by the deployer. The anti-spoofing and anti-tampering benefits are quite valuable. However, there are some challenges to be aware of when using strong-name signing.<o:p></o:p> First, all assemblies referenced by a strong-named assembly must also be strong-named. If you reference an assembly written by a third party that is not strong-name signed, you cannot strong-name sign your assembly.<o:p></o:p> Second, strong-name signing makes servicing more complicated. Under current versioning policy, an assembly will always attempt to load the exact version of the assembly it was built against. If, for example, your application was built against version 1.0.0.0 of a strong-named assembly and you fix a bug in the assembly, bumping the version number to 1.0.0.1, the existing application will not find the updated assembly.<o:p></o:p> There are a few ways to deal with this situation. You can rebuild the application against the new assembly. Obviously, this is an annoying process for just picking up a bug fix and it may not be an option in some situations. Still, it works fine when your code is not widely deployed or the assembly being serviced is not widely shared across applications.<o:p></o:p> Another option is if the assembly is installed in the GAC, you can use publisher policy to redirect loads for version 1.0.0.0 to version 1.0.0.1. However, publisher policy is complicated.<o:p></o:p> Yet another option is to fix the bug and not change the assembly version number, so existing applications can still find the assembly. This is the approach the .NET Framework uses for bug fixes, although its not appropriate for new features or anything that breaks compatibility. If you are adding new features, you should bump the assembly version up and have applications rebuild to opt in to the new features.<o:p></o:p> Needless to say, strong-name signing adds some complexity to your development and build processes. But this is necessary to keep the private key secure. Ill discuss how to deal with this complexity in a moment.<o:p></o:p> Now lets take a quick look at a simple signing scenario: creating a random key pair and storing it in a file. Im only using this particular approach as a way to introduce you to how strong-name signing works. Obviously, storing the private key in a file next to your code is not a good way to protect your key so you generally should not use this approach in production.<o:p></o:p> If you are using command-line tools, you can create a key pair with sn.exe in the SDK. Then you pass that key pair to the compiler when compiling your code. The following commands create a new random key pair using sn.exe and build a strong-name signed assembly with csc.exe: <o:p></o:p>sn k mykey.snk<o:p></o:p>csc /keyfile:mykey.snk myapp.cs<o:p></o:p> This produces a strong-name signed application named myapp.exe. You can do the same thing with Visual Studio® 2005. The Signing pane on the project properties page controls strong-name signing for your project (see Figure 1). To create a simple key file, select the "Sign the assembly" option, and create a new key file that is not password protected. Visual Studio will add the key file to your project and use it to sign your application. <o:p></o:p> <v:shape id=_x0000_i1029 style="WIDTH: 300pt; HEIGHT: 186.75pt" type="#_x0000_t75" alt="Figure 1 Signing the Assembly"><v:imagedata o:href="http://msdn.microsoft.com/msdnmag/issues/06/07/CLRInsideOut/fig01.gif"; src="file:///C:\DOCUME~1\Nilesh\LOCALS~1\Temp\msohtml1\01\clip_image002gif"></v:imagedata></v:shape> Figure 1 Signing the Assembly<o:p></o:p> As I mentioned, storing the private key in a file next to your code is not a secure way to protect your private key. Fortunately, Visual Studio allows you to password-protect the key file. When you create a new strong name key for your project, just leave the "Protect my key file with a password" option selected and enter a password for your key file (see Figure 2). Visual Studio adds a personal certificate, a PFX file, to your project. This file includes your encrypted private key, protected by the password you selected.<o:p></o:p> <v:shape id=_x0000_i1030 style="WIDTH: 225pt; HEIGHT: 142.5pt" type="#_x0000_t75" alt="Figure 2 Creating a Key"><v:imagedata o:href="http://msdn.microsoft.com/msdnmag/issues/06/07/CLRInsideOut/fig02.gif"; src="file:///C:\DOCUME~1\Nilesh\LOCALS~1\Temp\msohtml1\01\clip_image003gif"></v:imagedata></v:shape> Figure 2 Creating a Key<o:p></o:p> While password-protecting your key files is a much better solution than storing them in the clear, it is still not ideal. You would still have to distribute the PFX file to all of your developers, and they would all have to know the password for the PFX file. Secrets that are widely shared like this do not tend to stay secret for very long. Ideally, you should not have to distribute the private key to build and test your code during development.<o:p></o:p> Back to Contents<v:shape id=_x0000_i1031 style="WIDTH: 13.5pt; HEIGHT: 6pt" type="#_x0000_t75" alt="Back to top"> <v:imagedata o:href="http://msdn.microsoft.com/msdnmag/images/top.gif"; src="file:///C:\DOCUME~1\Nilesh\LOCALS~1\Temp\msohtml1\01\clip_image001gif"></v:imagedata></v:shape><o:p></o:p> ----------------------------------------------------------- To stop getting this e-mail, or change how often it arrives, go to your E-mail Settings. http://groups.msn.com/MumbaiUserGroup/_emailsettings.msnw Need help? If you've forgotten your password, please go to Passport Member Services. http://groups.msn.com/_passportredir.msnw?ppmprop=help For other questions or feedback, go to our Contact Us page. http://groups.msn.com/contact If you do not want to receive future e-mail from this MSN group, or if you received this message by mistake, please click the "Remove" link below. On the pre-addressed e-mail message that opens, simply click "Send". Your e-mail address will be deleted from this group's mailing list. mailto:[EMAIL PROTECTED]
![http://msdn.microsoft.com/msdnmag/images/top.gif"](http://msdn.microsoft.com/msdnmag/images/top.gif"){kind=link}
![http://msdn.microsoft.com/msdnmag/issues/06/07/CLRInsideOut/fig01.gif"](http://msdn.microsoft.com/msdnmag/issues/06/07/CLRInsideOut/fig01.gif"){kind=link}
![http://msdn.microsoft.com/msdnmag/issues/06/07/CLRInsideOut/fig02.gif"](http://msdn.microsoft.com/msdnmag/issues/06/07/CLRInsideOut/fig02.gif"){kind=link}