Sie sind auf Seite 1von 36

Module 12: Deploying Applications with Security

Contents Overview Lesson: Deploying .NET Applications with Security Settings Lesson: Deploying .NET Applications with Publisher Identity and Code Integrity Review Lab 12: Deploying Applications with Security Course Evaluation 1 2 9 29 31 34

Information in this document, including Uniform Resource Locators (URLs) and other Internet Web-site references, is subject to change without notice. Unless otherwise noted, the example companies, organizations, products, domain names, e-mail addresses, logos, people, places, and events depicted herein are fictitious, and no association with any real company, organization, product, domain name, e-mail address, logo, person, place or event is intended or should be inferred. Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express, written permission of Microsoft Corporation. Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property. !"2004 Microsoft Corporation. All rights reserved. Microsoft, MS-DOS, Windows, Windows NT, Windows Server, Microsoft Press, Active Directory, ActiveX, Authenticode, JScript, MSDN, Outlook, PowerPoint, Visual Basic, Visual C#, Visual Studio, Win32, and Windows Media are either registered trademarks or trademarks of Microsoft Corporation in the United States or other countries, or both. The names of actual companies and products mentioned herein may be the trademarks of their respective owners.

Module 12: Deploying Applications with Security

Overview

Introduction

This module explains the deploying of secure applications. The module explains the various deployment techniques used to deploy .NET applications. It also discusses various techniques, such as Microsoft Authenticode signing and strong-name signing, to authenticate .NET assemblies and verify the publisher identity. After completing this module, you will be able to:
! !

Objectives

Deploy .NET applications with security settings. Deploy .NET applications with publisher identity and code integrity.

Note The procedures provided in this module, except those contained in any practice, demonstration or lab exercise, are generic and have not been customized to support the images built for this course.

Module 12: Deploying Applications with Security

Lesson: Deploying .NET Applications with Security Settings

Introduction

In this lesson, you will learn about the deployment techniques of .NET applications. To run an application on any computer, you must first deploy the application. The deployment technique you choose determines the level of code-access security for the application. After deploying the application, you must ensure that the application runs without throwing security exceptions, for which you need to deploy the application with the updated security policies. This lesson describes the code-access security based on the deployment technique used to deploy an application. The lesson also describes how to deploy an application with modified security policies. After completing this lesson, you will be able to:
! ! !

Objectives

Explain deployment techniques of .NET applications. Explain the use of code-access security with .NET deployment techniques. Deploy .NET applications with updated code-access security.

Module 12: Deploying Applications with Security

Deployment Techniques of .NET Applications

Introduction

To run an application on any computer, you must first deploy the application. To deploy a .NET application, use any of the following deployment techniques:
! ! ! !

XCopy No-touch Microsoft Windows Installer (.MSI) Cabinet-file (.CAB)

XCopy and no-touch are the new deployment techniques introduced in VB.NET. Microsoft Windows applications traditionally use MSI and cabinetfile deployment techniques. XCopy deployment The XCopy deployment technique copies the directory that contains the application to the location from which you must run the application. This technique applies if your application consists only of .NET components, because .NET components do not require further registration when you relocate components. When you use the XCopy deployment technique, you must ensure that you retain the file attributes and ACLs for the files and folders that you copy from the development location to the target location. Example of XCopy deployment You can use the XCopy deployment technique for deploying Web services and ASP.NET Web applications in which you can copy application files from the development computer to the Web server computer where you need to run the application.

Module 12: Deploying Applications with Security

No-touch deployment

The no-touch deployment technique copies the Windows Form application of the VB.NET application that you need to deploy from a Web page. The Web page may be on the Internet or on an intranet. This technique copies the application and its components from the Web page to a special folder, named Internet download cache, on your computer, from where you can run the application. Implementing the no-touch deployment technique requires that you have a continuous Internet connection when you run the application.

Example of no-touch deployment

You can use the no-touch deployment technique when the application is based on Windows Forms and deployed on the Internet. The application can be designed for the automatic download of dependent components to run the application from the Internet. This deployment technique creates a Windows Installer (.MSI) package. This package is a setup that includes a user interface to specify installation options and a directory location where you can copy and install application files. Note To create and edit Windows Installer packages, you can use Orca.exe, which is a database table editor. Orca.exe provides a graphical interface to validate and highlight entries where validation errors occur in a Windows Installer package.

Windows Installer deployment

Example of Windows Installer deployment

The Windows Installer deployment technique is useful when the application contains Microsoft ActiveX or .NET components that require special registration. You can also use the Windows Installer package to deploy an application if the application needs to provide:
! !

Additional configuration settings, such as NTFS security settings. The option to reboot the system as part of the installation procedure or disable a Windows operating system service to install any component of the application. Installation options for the user. Desktop shortcuts or Start menu items. The installation of .NET DLL components on the global assembly cache (GAC). The location of the application directory to be determined by the user.

! ! !

Cabinet-file deployment

The cabinet-file deployment technique uses cabinet (.cab) files to distribute ActiveX components on the Internet. If the .cab file contains a .NET component, the deployment technique functions similar to the no-touch deployment technique.

Example of cabinet-file deployment

You use the cabinet-file deployment technique if you want to use an ActiveX component on a Web page.

Module 12: Deploying Applications with Security

.NET Application Deployment and Code-Access Security

Introduction

There are various techniques you can use to deploy .NET applications. The deployment technique you choose determines the level of code-access security for the application. When you deploy a .NET application, the .NET code-access security provides a restrictive environment to run the application. This environment is known as the .NET code-access security sandbox. When you deploy your application on the Internet or intranet, the clients accessing your application identify that the application is from a secure zone and run it in the sandbox environment. If you install and run your application in the My Computer zone, where all permissions are granted to the application, the application is considered to be running outside the .NET code-access security sandbox.

Xcopy deployment and code-access security sandbox

When you deploy a .NET application using the XCopy deployment technique, the application cannot run in the .NET code-access security sandbox environment. This is because when you use the XCopy deployment technique, you copy the entire application to the local computer. Therefore, the application runs from the My Computer zone of the local computer. When you deploy an application using the Windows Installer package, the client cannot run the application in the sandbox environment. This is because the application is installed on the client computer where the application runs in the My Computer zone. Therefore, the application inherits the security settings of the My Computer zone and ignores the original location of the application, which is the Internet. When you deploy an application using the no-touch or cabinet-file deployment techniques, the application is granted permissions based on the zone from which the application runs. For example, if you run the application from a remote location on an intranet, the application has permissions assigned only to the intranet zone. In this situation, the application is said to be inside a sandbox because it can perform only the actions for which it is assigned permissions.

Windows Installer deployment and codeaccess security sandbox

No-touch and cabinetfile deployment and code-access security sandbox

Module 12: Deploying Applications with Security

How to Deploy .NET Applications with Modified Security Policies

Introduction

To run an application on a client computer without throwing security exceptions, you need to deploy the application with the updated security policies at the location where you want to run the application. You can use methods to deploy an application and update the security policies at the target location. For example, you can create a security policy deployment package to register the security policy updates at the target location. To deploy the security setting updates using a security policy deployment package, create a custom development application and package the security updates in an .MSI deployment file. To create a custom .MSI security policy deployment package, perform the following steps: 1. Click Start, point to Administrative Tools, and click Microsoft .NET Framework 1.1 Configuration. 2. Right-click the Runtime Security Policy node. 3. To start Deployment Package Wizard, select the Create Deployment Package option. 4. In the Choose the Policy Level to Deploy dialog box, select the level of security policy for which you want to create a deployment package. 5. Specify the name and location for the new Windows Installer file, and then click Next. 6. Click Finish to create the deployment package. The .MSI deployment package helps you update the security policies required for running the application.

Creating a security policy update package

Module 12: Deploying Applications with Security

Practice: Creating a Sample Security Policy Installer

Introduction Length Instructions

In this practice, you will create an MSI that will deploy the enterprise security policy setting of your computer on to the client computer. 20 minutes Log on to 2840A-LONDON as 2840A-LONDON\Administrator with a password of P@ssw0rd.

! Analyze the existing security policy settings


1. Start the Microsoft .NET Framework 1.1 Configuration tool. 2. Click the Runtime Security Policy node. 3. Expand the Enterprise node, and then expand the Code Groups. Notice that there is only one subnode, All_Code. 4. Close the Microsoft .NET Framework 1.1 Configuration tool.

! Change the security policy using MSI


1. Double-click the fulltrust.msi file from the location given below. install_folder\Practices\Mod12\Practice01\Starter\SampleMsi 2. Using the Microsoft .NET Framework 1.1 Configuration tool, click the Code Groups node under the Enterprise security policy level. Notice that a new subnode, FileAccessApplication_FullAccess, is added to the All_Code node under the Enterprise security policy level.

Module 12: Deploying Applications with Security

! Create an MSI to deploy your current enterprise security settings


1. In the Microsoft .NET Framework 1.1 Configuration tool, right-click the Runtime Security Policy node. 2. To start Deployment Package Wizard, select the Create Deployment Package option. 3. In the Choose the Policy Level to Deploy dialog box, select the Enterprise option. 4. Specify the name of the new Windows Installer file as MyMSI, and specify the following location for saving the file: install_folder\Practices\Mod12\Practice01\Starter\MyMSIFolder 5. Click Save, and then click Next. 6. Click Finish to create the deployment package. 7. Browse to the location using Windows Explorer and make sure the MyMSI file is created in the location.

! Test the MSI


1. Start the Microsoft .NET Framework Configuration tool. 2. To delete the FileAccessApplication_FullAccess node, right-click the FileAccessApplication_FullAccess node, and select the Delete option. 3. To confirm the deletion of the FileAccessApplication_FullAccess node, click Yes. 4. Close the Microsoft .NET Framework 1.1 Configuration tool. 5. Run MyMSI.msi by double-clicking it. 6. Start the Microsoft .NET Framework Configuration 1.1 tool. 7. Check the Code Groups node under the Enterprise security policy level. You will find that the FileAccessApplication_FullAccess subnode that you deleted is added again under the Enterprise security policy level.

Module 12: Deploying Applications with Security

Lesson: Deploying .NET Applications with Publisher Identity and Code Integrity

Introduction

This lesson describes the various techniques, such as Authenticode signing and strong-name signing, to authenticate applications and to set up packages. The Authenticode-signing technique attaches an X.509 certificate to an assembly to verify the publisher identity, whereas strong-name signing enables you to ensure application integrity. This lesson explains the procedure for creating X.509 certificates and then attaching these certificates to .NET assemblies using Authenticode signing. You use Authenticode signing to ensure the authenticity of applications downloaded from the Internet and verify the identity of publishers. Strong-name signing ensures integrity of assemblies by providing a unique name to .NET assemblies. In this lesson, you will learn how to apply strong-name signing to assemblies. After completing this lesson, you will be able to:
!

Objectives

Create an X.509 certificate for .NET applications by using the MakeCert.exe utility. Explain Authenticode signing. Apply Authenticode signing to setup packages. Apply Authenticode signing to .NET assemblies by using the SignCode.exe utility. Explain strong-name signing. Sign in .NET assemblies using a strong name.

! ! !

! !

10

Module 12: Deploying Applications with Security

How to Create an X.509 Certificate for .NET Applications

Introduction

In the process of cryptography, the sender of a message must provide public key access to the recipients. On a large network, it is difficult to guarantee that the public key belongs to a trusted repository. To solve the problem of public key identification and distribution, you use various certificates. For example, in Microsoft Windows, you use X.509 certificates to authenticate a user, an application, or a computer. An X.509 certificate contains the name of the organization and contact information and is similar to a company logo. This certificate has a Software Publisher Certificate (.spc) format. An example of this certificate is MyCourseCert.spc. You can either create an X.509 certificate or obtain it from a certificate authority (CA). Normally, you obtain this certificate for your organization by signing up for a digital ID from CAs. CAs require a large fee and take a long time to perform an extensive background check. Therefore, for the purpose of this exercise, you will create an X.509 test certificate. However, it is important to note that you should not deploy an application signed with a test certificate because the test certificates, which do not contain the issuer name, are not issued by a trusted authority. You use the MakeCert utility to create an X.509 test certificate. Using the MakeCert utility, you create a public and private key pair and associate the key pair with a specified publisher name. Then you use this utility to create an X.509 certificate that binds a user-defined name to the public part of the key pair. Finally, you package the X.509 certificate in a .spc file.

Creating an X.509 certificate

Module 12: Deploying Applications with Security

11

The following table describes common options that you use with the MakeCert command.
Option -n x509name Description Specifies the name of the certificate, which must conform to the X.500 standard. The name is expressed in double quotes, preceded by CN=; for example, CN=MyCertificate. Description Specifies the location of the container that contains the private key. If a key container does not exist, this option creates it. Specifies the location of the certificate, which can be either the current user or the local computer. Specifies the store name of the output certificate. Specifies a serial number from 1 to 231-1. The Makecert.exe command generates a default number, which you can change per requirements. Specifies the signing authority of the certificate, which must be set to either commercial or individual. Displays the command syntax and the basic options for the MakeCert utility. Displays the command syntax and the extended options for the MakeCert utility. Specifies the private key file name. If the file does not exist, this option creates a private key file using the specified name.

Option -sk keyname -sr location -ss store -# number

-$ authority -? -! -sv

To create an X.509 certificate, complete the following steps: 1. Click Start, point to All Programs, point to Microsoft Visual Studio .NET 2003, click Visual Studio .NET Tools, and then click VS.NET Command Prompt. 2. In the Visual Studio .NET command prompt, change the current directory to the directory where the application to be signed resides.

12

Module 12: Deploying Applications with Security

3. Run the MakeCert.exe utility to create an X.509 certificate named MyCertificate by using the following command:
MakeCert -n "CN=MyCertificate"sv MyPvtKey.pvk MyCourse.cer

The above command also creates a private key named MyPvtKey.pvk and opens a dialog box where you can specify the password for the private key.

4. In the Create Private Key Password dialog box, enter a password in the Password and Confirm Password fields. This password is associated with the MyPvtKey.pvk private key. 5. In the Enter Private Key Password dialog box, re-enter the password, and then click OK. The sv option extracts the private key, and you need to re-enter the password to gain access to this key.

6. Use the cert2spc MyCourse.cer MyCourseCert.Spc command to run the Cert2Spc.exe utility. The Cert2Spc.exe utility packages the X.509 certificate created in the previous step in a .spc file. The .spc file is the required format that you use to authenticate .NET applications.

Module 12: Deploying Applications with Security

13

Practice: Creating an X.509 Certificate Using the MakeCert.exe Utility

Introduction Length Instructions

In this practice, you will create the X.509 certificate using the MakeCert.exe utility. 20 minutes Log on to 2840A-LONDON as 2840A-LONDON\Administrator with a password of P@ssw0rd.

! Create a private key and X.509 certificate using MakeCert.exe


1. Using Windows Explorer, create a folder, MyCertStore, at the following location: install_folder\Practices\Mod12\Practice02\Starter 2. To start Visual Studio .NET 2003 command window, click Start, point to All Programs, click Microsoft Visual Studio .NET 2003, click Visual Studio .NET Tools, and then click Visual Studio .NET 2003 Command Prompt. 3. Change the current directory to: install_folder\Practices\Mod12\Practice02\Starter\MyCertStore 4. Run the MakeCert.exe utility to create an X.509 certificate with the name MyID.cer and a private key named MyKey.pvk, as shown:
MakeCert -n "CN= MyCertificate" -sv MyKey.pvk MyID.cer

5. In the Create Private Key Password dialog box, enter the appropriate password in the Password and Confirm Password text boxes, and then click OK. 6. In the Enter Private Key Password dialog box, re-enter the same password, and then click OK.

14

Module 12: Deploying Applications with Security

7. To package the X.509 certificate in a Software Publisher Certificate (.spc) file, run the Cert2Spc.exe utility, as shown:
cert2spc MyID.Cer MyCertificate.Spc

8. Using Windows Explorer, browse to the following location to view the Private Key and the Certificate files that are created: install_folder\Practices\Mod12\Practice02\Starter\MyCertStore

Module 12: Deploying Applications with Security

15

What Is Authenticode Signing?

Introduction

When downloading code or software from the Internet, you may face the threat of downloading malicious code. It is difficult for you to identify a harmful piece of software or code before downloading it from the Internet because you do not know the publisher of the software. Internet Explorer 3.0 and later versions use the Authenticode technology, which enables you to identify the publisher of signed software and verify that the software has not been tampered. The Authenticode technology attaches the X.509 certificate to the .exe and .dll files as well as the digital signature that uniquely identifies an application.

Uses of Authenticode signing

Some of the applications of Authenticode signing are:


!

Signing applications or setup packages that you use to install applications from the Web. Examples of setup packages are the .msi and .cab files downloaded from the Internet. Signing the .dll files that the application dynamically downloads from the Internet. Signing the files or installation packages available on File Transfer Protocol (FTP) sites.

When is an Authenticode signature checked?

An Authenticode signature is automatically checked in the following situations:


!

When the .cab file that contains the ActiveX component is downloaded and used as part of a Web page, Internet Explorer checks the Authenticode signature of the ActiveX component. Before installing device drivers, Microsoft Windows checks the Authenticode signature of device drivers. If you are using a Windows setup .exe bootstrapper program to launch a Windows Installer (.msi) package, the bootstrapper checks the Authenticode signature of the .msi file.

16

Module 12: Deploying Applications with Security

How to Apply Authenticode Signing to Setup Packages

Introduction

When you deploy an application using the Internet or you receive the application as an e-mail attachment, you are not sure of the authenticity of the setup packages that you use to deploy the application. In such cases, you should sign the setup packages using Authenticode to verify the integrity of the setup package and the identity of the publisher. To Authenticode-sign a setup package, complete the following steps: 1. Open the Setup Wizard. 2. Specify the options of the Setup Wizard.

Signing Authenticode in .NET applications

Opening the Setup Wizard

To open the Setup Wizard, perform the following steps: 1. Click Start, point to All Programs, point to Microsoft Visual Studio .NET 2003, and then click Microsoft Visual Studio .NET 2003. 2. On the File menu, point to New, and then click Project. 3. In the Project Types list, click Setup and Deployment Projects. 4. In the Templates list, click Setup Wizard. 5. In the Name field, specify the name of the project as MySetup, and then click OK.

Setting the options of the Setup Wizard

To specify the options of the Setup Wizard, complete the following steps: 1. In the Setup Wizard (1 of 4) dialog box, click Next. The Setup Wizard guides you through the steps to sign a setup package. The Setup Wizard (2 of 4) dialog box enables you to choose a project type. You want to sign a setup package in Windows. As a result, you accept the default settings. 2. Click Next.

Module 12: Deploying Applications with Security

17

3. In the Setup Wizard (3 of 4) dialog box, click Add. You now need to add the strong-name-signed MyApplication.exe, located in the install_folder\LabFiles\Lab12\Exercise02\Starter\MyApplication directory.
4. Click the application name that you need to sign.

5. Click Open. 6. Click Next. 7. In the Setup Wizard (4 of 4) dialog box, click Finish to add the new project to the MyApplication solution. 8. In Solution Explorer, right-click the name of the project that you created, and then click Properties.

9. In the Property Pages, click the Configuration drop-down list box, and then select Release. The Release option indicates that you are shipping a release build of your product, not a debug build, which is not optimized and might contain unnecessary debug code. 10. Select the Authenticode signature check box.

18

Module 12: Deploying Applications with Security

11. In the Certificate file field, type the name of the certificate (.spc file) that you plan to Authenticode-sign, and, in the Private key file field, type the file name that has the private key. Click Next.

12. On the Setup Wizard (4 of 4) dialog box, you can add a timestamp to your setup program. It is good practice to timestamp the setup package as part of the signing process. This ensures that an Authenticode-signed package can be trusted even after the X.509 certificate expires. To timestamp the setup package, in the Timestamp server URL text box, enter the name of the timestamp service provider. 13. Click OK. 14. In the Build menu, click Build MySetup. The result of the operation appears in the Output text box at the bottom. Verify that the project that you created has been built. You can verify that Authenticode signing has been correctly applied to the setup package by navigating to the location where the Mysetup.msi file is created. You can check the properties of the InstMsiA and InstMsiW files to view the X.509 certificate used to Authenticode-sign the setup package.

Module 12: Deploying Applications with Security

19

How to Apply Authenticode Signing to Assemblies

Introduction

You have learned about the Authenticode signing of setup packages. You can also Authenticode-sign an assembly by using the SignCode.exe utility. For example, you can sign 32-bit .exe files, .cab files, .ocx files, and .class files using Authenticode. To Authenticode-sign an assembly with SignCode.exe, you need:
! ! ! !

A user-defined name. An X.509 certificate. A private key used to encrypt a hash digest. The signing authority that issues the certificate, which can be issued either by an individual or a certificate provider. A timestamp (optional).

Authenticode-signing an assembly

To Authenticode-sign an assembly: 1. Launch the SignCode.exe utility. 2. Sign an assembly using Digital Signature Wizard. 3. Verify that the assembly is signed using Windows Explorer.

Launching the SignCode.exe utility

To launch the SignCode.exe utility, complete the following steps: 1. Click Start, point to All Programs, point to Microsoft Visual Studio .NET 2003, point to Visual Studio .NET Tools, and then click Visual Studio .NET 2003 Command Prompt. 2. At the command prompt, type SignCode, and then press ENTER.

20

Module 12: Deploying Applications with Security

Signing an assembly using Digital Signature Wizard

After you launch the SignCode.exe utility, you need to sign an assembly using Digital Signature Wizard. To do so, complete the following steps: 1. In Digital Signature Wizard, click Next. 2. Click Browse and browse to the location where the assembly is stored. 3. Double-click the application name in the folder. 4. In Digital Signature Wizard, click Next. 5. Select Custom signing, and then click Next. 6. To select a certificate to which you will attach the private key, click Select from File. 7. Double-click the X.509 certificate that you want to select, and then click Next. 8. To locate the private key file, click Browse. 9. Double-click the private key file name. 10. Click Next. 11. In the Enter Private Key Password dialog box, enter the password and then click OK. 12. In the Hash Algorithm list box, select md5, and then click Next. 13. In the Certificates in certification path group box, select the Only the signature certificate option, and then click Next. 14. In the Description (optional) text box, enter My Authenticode practice, and then click Next. 15. Click Next. 16. On the last screen of Digital Signature Wizard, click Finish. 17. Re-enter the password in the prompt window, and then click OK.

Verify that the assembly is signed

You have Authenticode-signed an assembly. Next, you need to verify that the assembly has been signed. To do so, complete the following steps: 1. Click Start, point to All Programs, point to Accessories, and click Windows Explorer. 2. Locate the MyApplication.exe file inside the install_folder\LabFiles\Lab12\Exercise02\Starter\MyApplication folder. 3. Right-click the MyApplication.exe file, and then select Properties. 4. Click the Digital Signatures tab, click My Certificate, and then click Details. 5. Review the details of MyCertificate.spc. You can verify that Authenticode signing has been correctly applied to the setup package by navigating to the location where the .exe file is created. You can check the file properties to view the X.509 certificate used to Authenticodesign the setup package.

Module 12: Deploying Applications with Security

21

Practice: Applying Authenticode Signing to an Assembly

Introduction

In this practice, you will use the SignCode.exe utility to sign an assembly with X.509. After signing the assembly you will use Windows Explorer to confirm that the file is signed. 20 minutes Log on to 2840A-LONDON as 2840A-LONDON\Administrator with a password of P@ssw0rd.

Length Instructions

! Launch the Signcode.exe utility


1. Click Start, point to All Programs, click Microsoft Visual Studio .NET 2003, click Visual Studio .NET Tools, and then click Visual Studio .NET 2003 Command Prompt. 2. Type SignCode, and then press ENTER.

! Use Digital Signature Wizard to sign an assembly


1. In Digital Signature Wizard, click Next. 2. In the File Selection dialog box, click the Browse button, and then browse to the following location: install_folder\Practices\Mod12\Practice03\Starter\MyApplication 3. Double-click MyApplication.exe in the folder. 4. In the File Selection dialog box, click Next. 5. In the Signing Option dialog box, select the Custom type, and then click Next. 6. In the Signature Certificate dialog box, click Select from File.

22

Module 12: Deploying Applications with Security

7. Select the file MyCompanyCerts.spc from the following location, click Open, and then click Next. install_folder\Practices\Mod12\Practice03\Starter\CertStore 8. In the Private Key dialog box, select the MyPrivateKey.pvk file using the Browse button from the following location, and then click Next. install_folder\Practices\Mod12\Practice03\Starter\CertStore 9. In the Enter Private Key Password dialog box, enter the password as P@ssw0rd, and then click OK. 10. In the Hash Algorithm dialog box, select md5, and then click Next. 11. In the Additional Certificates dialog box, select the Only the signature certificate option, and then click Next. 12. In the Data Description dialog box, enter My Authenticode practice in the Description text box, and then click Next. 13. In the Timestamping dialog box, retain the default state (unchecked) of the Add a timestamp to the data option, and then click Next. 14. In completing Digital Signature Wizard, click Finish. 15. In the Enter Private Key Password dialog box, re-enter the password, and then click OK. 16. Click OK on the message box indicating that the digital signing was successful.

! Use Windows Explorer to confirm that the file is signed


1. Launch Windows Explorer. 2. Locate the file MyApplication.exe inside the folder MyApplication. 3. Right-click MyApplication.exe, and then select Properties. 4. To view the details of MyCertificate.spc, select the Digital Signatures tab, select My Certificate, and then click Details.

Module 12: Deploying Applications with Security

23

What Is Strong-Name Signing?

Introduction

A strong name provides a way to uniquely identify an assembly. A strong name of an assembly is the combination of the assembly name, the hash digest value that is encrypted using the private key, the version number, and the culture value. The hash digest uniquely identifies the assembly and you encrypt it with a private key. When the assembly is loaded, you use the public key to decrypt the hash value. If the decrypted hash value does not match the original hash value of the assembly, the data integrity of the assembly may have been compromised. Therefore, by using a strong name, you can ensure the integrity of the assembly. However, using a strong name does not verify publisher identity. In addition to using strong-name signing to ensure the integrity of an assembly, you can also use Authenticode signing, as discussed in the previous topics. However, the two signing methods are different in some aspects. The following table compares the two methods.
Supported by Feature Verifying application integrity of application when loaded in Internet Explorer Supporting application executable files, such as .exe and .dll files Providing limited lifespan Providing a mechanism to trust the application publisher Providing compatibility with installation packages, such as Windows Installer (.msi) and cabinet (.cab) files Authenticode signing Yes Yes Yes Yes Yes Strong-name signing Yes Yes

Comparing strong name and Authenticode

24

Module 12: Deploying Applications with Security (continued) Supported by Feature Verifying application integrity when loaded in Windows Requiring a regular enrollment fee Yes Authenticode signing Strong-name signing Yes

The Sn.exe utility

To strong-name-sign an assembly, you use the Sn.exe utility. Sn.exe is a command window utility that provides various options to manage the publicprivate key combination, generate a digital signature, and verify the signature. The following table describes some of the options available with the Sn.exe utility. It is important to note that these options are case-sensitive.
Option -c [csp] Represents Specifies the Cryptographic Service Provider (CSP) to use for strong-name signing. After you specify a CSP, it becomes the default CSP for the computer. Deletes the container specified in containername. Verifies that two assemblies differ only by their signatures. Extracts the public key from the assembly and stores it in outfile. Displays the syntax for the SN command and lists various options of the SN tool. This option provides help for the tool. Generates a new public-private key pair and writes it to the file specified in outfile. Extracts the public key from infile and stores it in outfile. Extracts the public key from infile and stores it in outfile, which is in the .csv (comma separated value) format.

-d containername -D assembly1 assembly2 -e assembly outfile -h -k outfile -P infile outfile -o infile [outfile]

Module 12: Deploying Applications with Security

25

How to Sign .NET Assemblies Using a Strong Name

Introduction

You have learned that, by using strong-name signing, you can assign a unique name to an assembly and ensure its integrity. If an assembly is strong-name signed, it cannot be duplicated by another assembly. To strong-name-sign an assembly, you use the Sn.exe utility. The steps to create a strong-named application are: 1. Click Start, point to All Programs, point to Microsoft Visual Studio .NET 2003, point to Visual Studio .NET Tools, and then click Visual Studio .NET 2003 Command Prompt. 2. In the Visual Studio .NET command prompt, change the current directory to the directory where you want to create the private-public key pair. 3. To generate a public-private key pair for a file, run the Sn.exe strongnaming tool with the k option as follows:
SN k [filename]

Signing .NET applications using a strong name

The k option generates a new public-private key pair and writes it to the file specified in filename. For example, the following command generates a public-private key pair in the MySNkey file:
SN k MySNkey.pvk

26

Module 12: Deploying Applications with Security

4. Open the AssemblyInfo.vb file in a VB.NET project for the application that you want to strong-name-sign and add the following attribute declaration to the file:
<Assembly: AssemblyKeyFile("[filepath\filename]")>

Adding this declaration strong-name-signs the assembly when you build the assembly. VB.NET will pick the private key from the file specified in filename. 5. On the Build menu, click Build Solution. 6. To verify that the assembly has been strong-name-signed, write the following command at the VB.NET command prompt:
sn tp WindowsApplication1.exe

The execution of the above command displays the public key, which indicates that the assembly has been strong-name-signed.

Module 12: Deploying Applications with Security

27

Practice: Applying Strong-Name Signing to an Assembly Using the Sn.exe Utility

Introduction Length Instructions

In this practice, you will use the Sn.exe utility to create a private key, MyKey.pvk, and then use MyKey.pvk to sign your application. 20 minutes Log on to 2840A-LONDON as 2840A-LONDON\Administrator with a password of P@ssw0rd.

! Create a private key using the Sn.exe utility


1. Click Start, point to All Programs, point to Microsoft Visual Studio .NET 2003, point to Visual Studio .NET Tools, and then click Visual Studio .NET 2003 Command Prompt. 2. Change the current directory to either of the following locations based on the language in which you prefer to work: install_folder\Practices\Mod12\Practice04\C#\Starter\MyApplication install_folder\Practices\Mod12\Practice04\VB\Starter\MyApplication 3. Create a private key using Sn.exe. For example, the following command creates the mykey.pvk file (private key) in your current directory:
SN /k mykey.pvk

4. Using Windows Explorer, browse to either of the following locations: install_folder\Practices\Mod12\Practice04\C#\Starter\MyApplication install_folder\Practices\Mod12\Practice04\VB\Starter\MyApplication Notice that the mykey.pvk file is created in the MyApplication folder.

28

Module 12: Deploying Applications with Security

5. Open the solution file MyApplication.sln from either of the following locations: install_folder\Practices\Mod12\Practice04\C#\Starter\MyApplication install_folder\Practices\Mod12\Practice04\VB\Starter\MyApplication 6. Open the AssemblyInfo.cs or AssemblyInfo.vb file by double-clicking it and add the following line to the file after the comment Add the private key information here:
[C#] [assembly: AssemblyKeyFile("..\\..\\mykey.pvk")] [VB.NET] <Assembly: AssemblyKeyFile("..\..\mykey.pvk")>

7. To build the application, click the Rebuild MyApplication option on the Build menu. Now your assembly is strong-name-signed.

Module 12: Deploying Applications with Security

29

Review

1. You are planning to deploy an application that has ten features, four of which are optional. Which of the following deployment techniques would you use to deploy the application? a. No-touch deployment technique b. MSI deployment technique c. Cabinet files deployment technique d. XCopy deployment technique

2. You created a local file manager application that manages files on the local computer. The local file manager is granted full access to all files on the local computer. Now, to deploy the local file manager on client computers, you decide to use MSI to deploy the required security settings on the client computer. You will create a security update for which of the following security policy levels? a. Enterprise b. Machine c. User d. Custom

30

Module 12: Deploying Applications with Security

3. You have strong-name-signed all the assemblies in your application. Which of the following security risks would still persist if you make your application available on the Internet for deployment? a. Spoofing b. Data Tampering c. Repudiation d. Elevation of Privileges

4. You plan to develop software and make it available on the Internet. You need to ensure that clients who deploy this software are safeguarded through sandbox protection. Which of the following deployment techniques would you use? a. XCopy b. MSI c. No-touch d. Zip file

5. As a software publisher, which of the following techniques will you use to add your identity to a deployment package? a. Strong-name signing b. Authenticode c. Password protection

Module 12: Deploying Applications with Security

31

Lab 12: Deploying Applications with Security

Objectives

After completing this lab, you will be able to:


! !

Perform Authenticode signing on an application. Perform the deployment of a security policy using MSI.

Prerequisites

Before working on this lab, you must have:


!

The knowledge and skills to create an X.509 certificate using the MakeCert.exe utility. The knowledge and skills to use the SignCode.exe utility to sign an application. The knowledge and skills to use Deployment Package Wizard.

Estimated time to complete this lab: 30 minutes

32

Module 12: Deploying Applications with Security

Exercise 1 Creating a Package for Deploying Machine-Level Security Policies


In this exercise, you will create an MSI that will deploy the enterprise security policy setting of your computer onto the client computer.

Scenario
The student will use the Microsoft .NET Framework 1.1 Configuration to add a new code group and permission set to the machine-level security policy. Student will then create an MSI which will deploy this new machine-level security setting to a new machine. Log on to 2840A-LONDON as 2840A-LONDON\Administrator with a password of P@ssw0rd.

Tasks
1.

Additional information
a.

Add a new code group and permission set to the machine-level security policy using the Microsoft .NET Framework 1.1 Configuration tool. Use Deployment Package Wizard to create an MSI for deploying the machine-level security policy.

For more information about adding a new code group and permission set using the Microsoft .NET Framework 1.1 Configuration, see the following resource: # Module 10, Configuring .NET Security. For more information about creating an MSI using Deployment Package Wizard, see the following resource in this module: # Practice 01: Creating a Sample Security Policy Installer

2.

a.

b. For more information about how to create an MSI using

Deployment Package Wizard, see the following resources: # The Visual Studio .NET Help documentation. For additional information about adding references, in Search, select the Search in titles only check box, then search by using Deployment Package Wizard phrase.

3.

Run the MSI on a computer and check if the security settings are deployed correctly.

Module 12: Deploying Applications with Security

33

Exercise 2 Authenticode-Signing an Assembly


In this exercise, you will perform Authenticode signing on an assembly. Log on to 2840A-LONDON as 2840A-LONDON\Administrator with a password of P@ssw0rd.

Tasks
1.

Additional information
a.

Launch Visual Studio .NET 2003 Command Prompt.

For more information about launching the Visual Studio .NET 2003 Command Prompt, see the following resource in this module: # Practice: Creating an X.509 Certificate Using the MakeCert.exe Utility.

2.

Use the MakeCert utility to create a certificate and a pair of public and private keys.

a.

For more information about the MakeCert.exe utility, see the following resource: # The Visual Studio .NET Help documentation. For more information about the MakeCert.exe utility, in Search, select the Search in titles only check box, and then search by using the Certificate creation tool phrase. Practice: Creating an X.509 Certificate Using the MakeCert.exe Utility, for more information on creating a certificate using the MakeCert.exe utility.

3.

Convert the CERT file created at the end of the previous step to an SPC file using the Cert2Spc.exe utility.

a.

For more information about the Cert2Spc.exe utility, see the following resource: # The Visual Studio .NET Help documentation. For more information about the MakeCert.exe utility, in Search, select the Search in titles only check box, then search by using the Software Publisher certificate phrase. See the Practice, Creating an X.509 Certificate Using the MakeCert.exe Utility, for more information on how to convert .cert files to .spc files using the Cert2Spc.exe utility.

4.

Use the SignCode.exe utility to sign the application in the following location: install_folder\Labfiles\Lab12\ Exercise02\Starter\MyApplication

a.

For more information about the SignCode.exe utility, see the following resource: # The Visual Studio .NET Help documentation. For more information about the SignCode.exe utility, in Search, select the Search in titles only check box, and then search by using the Authenticode signing tool phrase. See Practice 3, Applying Authenticode Signing to an Assembly, for more detailed information about how to sign an assembly using the SignCode.exe utility.

5.

Test the application to check if the signing is successful.

a.

See Practice 3, Applying Authenticode Signing to an Assembly, for more detailed information about how to test the Authenticode-signing process.

34

Module 12: Deploying Applications with Security

Course Evaluation

Your evaluation of this course will help Microsoft understand the quality of your learning experience. To complete a course evaluation, go to http://www.CourseSurvey.com. Microsoft will keep your evaluation strictly confidential and will use your responses to improve your future learning experience.

Das könnte Ihnen auch gefallen