----------------------------------------------------------- New Message on MumbaiUserGroup
----------------------------------------------------------- From: hereiam_always Message 1 in Discussion Delay Signing<o:p></o:p> This is where delay signing enters the picture. Delay signing allows you to generate a partial signature during development with access only to the public key. The private key can be stored securely out of the hands of the developers and used to apply the final strong name signature just before shipping your code.<o:p></o:p> To use delay signing, follow these steps: <o:p></o:p> 1. Extract the public key from the key pair. The public key can be distributed to developers in your organization without any security risk. <o:p></o:p> 2. Use the public key to delay sign your assemblies during development. Because the assemblies are not fully signed yet, youll also have to configure your development machines to skip strong name signature verification for your keyotherwise, the .NET Framework will not allow you to load the delay-signed assemblies. <o:p></o:p> 3. When you are ready to ship your code, use the (well guarded) private key to apply the final strong name signature to your delay-signed assemblies.<o:p></o:p> For step one, you can use the sn.exe tool to extract the public key from a key pair. For example, say you have your key pair stored in a securely configured key container named EnterpriseKey on a locked-down machine. You would use the following command to extract the public key to the EnterprisePublicKey.pk file: <o:p></o:p>sn pc EnterpriseKey EnterprisePublicKey.pk<o:p></o:p> You can then distribute EnterprisePublicKey.pk to the developers in your organization. You can usually use the same public key for multiple assemblies because each will have a different simple name. <o:p></o:p> For step two, you use compiler options to delay sign your assemblies with the public key when building them. The example that follows creates a delay-signed application using options for the C# compiler: <o:p></o:p>csc /delaysign+ /keyfile:EnterprisePublicKey.pk myapp.cs<o:p></o:p> Now if you try to run myapp.exe, it will not run because it does not have a valid full strong name signature. You must configure the .NET Framework to skip verification for the delay-signed assemblies using your public key. To do this, you use the sn.exe tool again. The following example configures the .NET Framework to skip strong name signature verification for the myapp.exe assembly on your development machines: <o:p></o:p>sn Vr myapp.exe<o:p></o:p> You can also use the sn.exe tool to skip signature verification for all assemblies signed with a particular key. For example, if you want to configure your machine to skip all assemblies delay signed with the same key as your application, you first do the following on your development machines: <o:p></o:p>sn T myapp.exe<o:p></o:p> This prints out the value of the public key token, a shortened version of the public key that looks something like this: <o:p></o:p>Microsoft (R) .NET Framework Strong Name Utility Version 2.0.50727.42<o:p></o:p>Copyright (c) Microsoft Corporation. All rights reserved.<o:p></o:p><o:p> </o:p>Public key token is b03f5f7f11d50a3a<o:p></o:p> (Note that the actual value of the public key token will vary depending on your public key.) You then execute the following command to skip strong name verification for any assembly using that public key token: <o:p></o:p>sn Vr *,b03f5f7f11d50a3a<o:p></o:p> Any assembly delay signed with that public key will now skip strong name signature verification and run on your development machine. Note that skipping strong name signature verification is something that should only be done on development machines. It should never be done on production computers because it opens up those machines to assembly spoofing attacks.<o:p></o:p> Finally, for step three, you use the real private key to generate the final full strong name signature before shipping your code. Again, you use the sn.exe tool to do this. For example, if your key pair is stored in a key container named EnterpriseKey on your signing computer, you would use the following command to sign a delay-signed assembly: <o:p></o:p>sn Rc myapp.exe EnterpriseKey<o:p></o:p> Now the assembly has a full signature. One of the nice things about delay signing is that it does not require any of the assemblies that use the delay-signed assembly to be rebuilt. Any assemblies that refer to the delay-signed assembly had access to its public key and were therefore able to create a full assembly reference, even though the assembly did not have a full signature.<o:p></o:p> Back to Contents<v:shape id=_x0000_i1032 style="WIDTH: 13.5pt; HEIGHT: 6pt" type="#_x0000_t75" alt="Back to top"> <v:imagedata src="file:///C:\DOCUME~1\Nilesh\LOCALS~1\Temp\msohtml1\01\clip_image001gif" o:href="http://msdn.microsoft.com/msdnmag/images/top.gif";></v:imagedata></v:shape><o:p></o:p> Test Key Signing<o:p></o:p> There is a new feature in the .NET Framework 2.0 called test key signing. This is similar to delay signing. With test key signing, you sign your assembly with an alternate private key during development and then configure your development computers to verify the signatures against the alternate public key that corresponds to the alternate private key. Test key signing is valuable when you want almost the exact same behavior as full signing for testing purposes. For example, with delay signing, assemblies are not verified at all. This could hide performance issues if your application loads many strong-named assemblies because none of the strong name signatures would be verified during test runs when delay signing is turned on.<o:p></o:p> Test key signing involves the following steps: <o:p></o:p> 1. Delay sign your assembly. <o:p></o:p> 2. Create a test key pair with which to sign your assemblies. You can do this using sn.exe with the k option. <o:p></o:p> 3. Test sign your assembly. You can do this using sn.exe and either the TS or TSc option. This will generate a signature for the assembly using the private key from your test key pair. <o:p></o:p> 4. Configure your development machines to use the test public key to verify the test key signed assemblies. You can use the Vr option on sn.exe to do this.<o:p></o:p> When you are ready to ship your assemblies, you sign them with the real private key using sn.exe with either the R or Rc option, just as you would for a delay-signed assembly. The following series of commands creates a test key pair, test key signs a delay-signed assembly, extracts the test public key, and configures a development machine to verify the assembly against the test key: <o:p></o:p>sn k TestKey.snk<o:p></o:p>sn TS myapp.exe TestKey.snk<o:p></o:p>sn p TestKey.snk TestPublicKey.pk<o:p></o:p>sn Vr myapp.exe TestPublicKey.pk<o:p></o:p> When using test key signing, you should still protect the test private key, but you do not have to guard it as closely as the real private key. It is also a good idea to change the test key pair periodically.<o:p> Back to Contents<v:shape id=_x0000_i1033 style="WIDTH: 13.5pt; HEIGHT: 6pt" type="#_x0000_t75" alt="Back to top"> <v:imagedata src="file:///C:\DOCUME~1\Nilesh\LOCALS~1\Temp\msohtml1\01\clip_image001gif" o:href="http://msdn.microsoft.com/msdnmag/images/top.gif";></v:imagedata></v:shape><o:p></o:p> Managing the Private Key <o:p></o:p> It is much easier to keep your private key secure if you are using delay signing or test key signing. You only have to have the private key installed on one or possibly a small number of locked-down signing computers. You can install the private key in a key container using restrictive access control lists (ACLs) to prevent unauthorized access to the key container. Alternatively, you can store the private key on a smart card or other separate hardware device. The sn.exe tool allows you to use a different cryptographic service provider (CSP) for signing. Take a look at the c option in the documentation for sn.exe.<o:p></o:p> Back to Contents<v:shape id=_x0000_i1034 style="WIDTH: 13.5pt; HEIGHT: 6pt" type="#_x0000_t75" alt="Back to top"> <v:imagedata src="file:///C:\DOCUME~1\Nilesh\LOCALS~1\Temp\msohtml1\01\clip_image001gif" o:href="http://msdn.microsoft.com/msdnmag/images/top.gif";></v:imagedata></v:shape><o:p></o:p> Working with Authenticode<o:p></o:p> Authenticode signatures provide more security semantics than strong name signatures. To generate an Authenticode signature, you have to obtain a code-signing certificate from a trusted certificate authority (CA). This can either be a commercial CA or a CA established by your IT department. The CA provides some level of assurance that the person or organization with the certificate is who they say they are, giving you some confidence that the software really came from the publisher listed in the signature. Authenticode also supports expiration and revocation, making it more flexible than strong name signatures. However, like strong name signatures, the presence of an Authenticode signature does not guarantee that you can trust the code. Authenticode simply provides some assurance about who published the code and that the code has not been tampered with since the publisher signed it.<o:p></o:p> Authenticode signatures can co-exist with strong name signatures. However, you must strong-name sign your assembly first, before applying the Authenticode signature. Adding the Authenticode signature will not invalidate a strong name signature.<o:p></o:p> Authenticode signatures can be used to trust applications deployed using the new ClickOnce model in the .NET Framework 2.0. You can use the tools in Visual Studio 2005 or in the SDK to apply an Authenticode signature to the deployment manifest of your ClickOnce application. You then install the certificate used to create the Authenticode signature in the trusted publisher certificate store on the client computers that will run your application; this can be done using Group Policy, Systems Management Server (SMS), or any other deployment mechanism available to you. Any ClickOnce application signed with this Authenticode certificate will run without any prompting. This is a convenient way to trust your enterprises applications.<o:p></o:p> Strong name signatures serve a valuable role in providing a form of identity for managed assemblies. Just remember that private key security is critical for strong names. If you do decide strong name signatures are appropriate for your organization, be sure to use some of the techniques discussed in this column to manage and protect the security of your private key. Regards, Nilesh Joshi</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}