Deploying PKI-Enabled Applications for Smart Cards

This paper is part of a series of white papers known as " The Smart Card Deployment Cookbook. "

For information on Enterprise Services, see https://www.microsoft.com/es/

On This Page

Introduction
Smart Card Logon
Secured Sockets Layer Configuration
S/MIME
VPN Configuration
The Code Signing Configuration

Introduction

Hay Buv Toys (HBT) recognizes that using smart cards can significantly improve their users' experience, because smart cards are easy to use and can be seamlessly integrated into their preferred applications. As part of smart card deployment, HBT must enable their core applications for smart cards. This includes implementing the following processes:

• Smart card logon

• Client authentication with smart cards for Web applications

• Encrypting and signing e-mail with smart cards

• Virtual private network (VPN) authentication with smart cards

• Digitally signing macros with smart cards

Smart Card Logon

When a PC/SC-compatible smart card reader has been installed on a computer running Microsoft Windows 2000, the logon dialog box provides the option for the user to insert a smart card.

Press Ctrl+Alt+Del to display the logon dialog box.

Enter your PIN instead of your user name and password. For example, GemPLUS cards use the default PIN 1234.

The administrator can configure user settings so that a user must log on to the system by using a smart card. HBT administrators decide to implement strong security by enforcing a mandatory smart card logon to the HBT network. The following procedure describes how to configure user settings for mandatory smart card logon.

1. Click Active Directory Users and Computers management console. Browse to the user account you want to change settings for, right-click the account, and then select Properties.

   

2. Click the Account tab, and then under Account options, select Smart card is required for interactive logon.

   

3. Click OK to enforce mandatory logon with a smart card.

System administrators can also configure system response when a user removes the smart card from the reader while logged on to the system. Administrators can choose from three options for how the system responds when a smart card is removed while a user is logged on:

• No Action This is the default setting. When you select this option, nothing happens when the user removes the smart card.

• Lock Workstation CTRL + ALT + DEL and then press Lock Workstation.

• Force Logoff When you select this option, the user is automatically logged off the system when the smart card is removed. Use this option for high security.

HBT decides to enforce the highest security for all their users. The following procedure describes how HBT can change the setting to Force Logoff for all users in a group.

1. Under Active Directory Users and Computers management console, right-click uswest.haybuv.com.

   

2. Select the appropriate Group Policy Object Links, and then click Edit.

   

3. Click Computer Configuration, click Windows Settings, click Security Settings, click Local Policies, click Security Options, and then select Smart card removal behavior.

   

4. In the Security Policy Setting dialog box, click Force Logoff, and then click OK.

   

The following illustration shows the Group policy after Lock Workstation is selected. After this policy is replicated to the appropriate computers, every computer with a PC/SC-compatible smart card reader locks the workstation when the smart card is removed from the reader.

Secured Sockets Layer Configuration

Secured Sockets Layer (SSL) encryption is a method for encrypting connections over the network. It is also a mechanism that enables a server to authenticate to a client computer. SSL is the most frequently used encryption method, because, unlike Internet Protocol security (IPSec), an application must recognize SSL to use it. Windows 2000 uses Microsoft Internet Information Services (IIS) and Microsoft Internet Explorer because both use SSL.

As part of their network updates, HBT decides to take advantage of the Windows 2000 SSL encryption services. Before HBT can configure an SSL connection, they must install a certificate on the Web server that can provide the identity to the client. Clients are thus protected from Domain Name Server (DNS) spoofing, in which somebody changes the IP Address for a computer and acts on behalf of this official server.

Web Server Certificate Enrollment

To complete certificate enrollment, HTB requests a certificate from the USWest user and machine enterprise subordinate authority.

1. Open the IIS management console.

   

2. Right-click Hay Buv Toys USWEST, and then click Properties.

   

3. In the Hay Buv Toys USWEST Properties dialog box, click the Directory Security tab. Under Secure communications, click Server Certificate, and then click OK. The Web Server Certificate Wizard opens.

   

   

4. Click Create new certificate, and click Next. To obtain the certificate from a floppy disk, click Assign an existing certificate. This is the most common way to assign an existing certificate, especially when you change the hardware for a Web server and have to import the old certificate.

   

5. If you are using an Enterprise subordinate certificate authority (CA), such as the USWEST Hay Buv Toys Users & Machine CA, click Send the request immediately to an online certification authority. When you get your certificate from an offline CA, you have to save the request and import the certificate later. Click Next.

   

6. Type the name for the certificate in the Name box, and set the length in the Bit length box.

7. In countries and regions where encryption restrictions exist, click Server Gated Cryptography (SGC) certificate (for export versions only). For example, in Germany, United States software was limited to 40-bit/56-bit symmetric key encryption, while in Germany 128-symmetric key encryption was allowed. Therefore, software vendors in the United States were not allowed to export strong encryption to Germany. Because these export regulations have been changed, Microsoft offers a high encryption pack for Microsoft Windows NT 4.0 in Service Pack 6.0a and Windows 2000, in which 128-bit symmetric encryption is provided for the operating systems. If a high encryption pack is installed on the client, you do not have be concerned with SGC certificates.

   

8. Type the organization information, and click Next.

   

9. Type the Web site's name for the organization in the Common name box. The common name is the name of the computer on which you install the certificate. Click Next.

   

   Clients such as Internet Explorer 5.0 compare the name in the certificate to the URL address. If the name in the URL address does not match the common name in the certificate, the user receives a warning which states that the certificates are valid but the names do not match.

   For example, if you issued a certificate with the common name dcclab31 and then addressed the SSL site dcclab31.uswest.haybuv.com, you will get following error, even though the site uses the same server.

   

10. Provide the necessary geographic information, and click Next.

    

11. In Certification authorities, select the appropriate CA. With the Active Directory, the wizard will only show certificate authorities that can issue certificates for the Web server. Click Next.

    

12. The IIS Certificate Wizard provides a summary of the information you have provided on the Certificate Request Submission page. Click Next to submit your request, and then click Finish to close the wizard.

    

Configure the Web Server for Secure Sockets Layer Communication

Now that the appropriate certificate is installed on the Web server, HBT can configure the SSL connection.

1. In the Hay Buv Toys USWESTProperties dialog box, click the Directory Security tab. Under Secure Communications, click Edit, and then click OK.

   

2. Select the Require secure channel (SSL) check box if you want this site or virtual directory to be secured with encryption.

3. Click Accept client certificates or Require client certificates to ensure that clients also have to authenticate to the server, and then click OK.

   

Configure the Web Server for Certificate Mapping

In a Windows network environment, authentication is simplified because IIS has several authentication mechanisms. Authentication through certificates is a popular option for clients that cannot authenticate through NTLM.

The following procedures describes how HBT maps specific certificates to a specific Windows 2000 user account.

1. In the Secure Communications dialog box, select the Enable client certificate mapping check box, and then click Edit.

   

2. In the Account Mappings dialog box, click the 1-to-1 tab if it is not already selected, and then click Add to select a certificate to map to a specific user. Browse to the certificate to which you want to map to a user account, and then click OK.

   

3. Type the Map Name for the certificate, and then click Browse.

   

4. From the Names box, click the user account that you want to map to the certificate, and click OK.

   

5. Enter the appropriate password, and then click OK. The mapping is activated immediately.

   

Many-to-many mapping is an alternative to mapping one user account to one certificate. In a Many-to-1 relationship, several clients with a certificate can be mapped to one Windows 2000 user account. This feature is very popular because users with a certificate are more trustworthy than those without a certificate.

It is possible to map the anonymous user to the anonymous user account that IIS uses (IUSR_machinename), or to a special user account. HBT

1. In the Account Mappings dialog box, click the Many-to-1 tab, and then click Add to select a certificate to map to a specific user.

   

2. Browse to the certificate to which you want to map to a specific user account. Select the Enable this wildcard rule check box, provide a brief description of the wildcard matching rule, and then click Next.

   

3. In the Edit Rule Element dialog box, select the criteria for the CA. For example, type Hay Buv Toys to look for certificates from the Hay Buv Toys certificate authority. Click OK.

   

4. In the Mapping dialog box, click Accept this certificate for Logon Authentication, type USWEST\certmap in the Account box to ensure that this is the account that IIS selects whenever a certificate from the Hay Buv Toys CA is presented to the Web site, and then click Finish.

   

Another option is global mapping of Windows 2000 accounts to Active Directory. With global mapping, each time an anonymous user enters the Web server over an SSL connection and shows a certificate, the certificate is mapped to the Active Directory. Depending on the certificate template, the certificate will automatically be published in Active Directory when the enrollment is completed through an enterprise CA. The following procedure describes how HBT configures their system to enforce global mapping.

1. Run the Administration module for IIS, and then right-click the Web server name and select Properties.

   

2. Under Master Properties, select WWW Service, and then click Edit.

   

3. Under Secure communications, click Enable the Windows directory service mapper, and click OK. When this option is selected, user accounts are authenticated against the Windows 2000 directory. For more information on this option, see the Windows 2000 documentation.

   

Client Authentification over an SSL-secured http Connection

When an administration sets require a secure channel to a Web site or a virtual directory, users have to communicate through https://. The following illustration indicates what users see when they log on to an SSL-configured Web site with a smart card. Client authentication is required before users can view the site. The following procedure describes how a user initiates the authentication process.

1. Type the address you are trying to reach, preceded by https://. When the Security Alert dialog box appears, click OK to continue.

2. In the Client Authentication dialog box, select the client certificate that the SSL Web server must authenticate against, and then click OK. This is only required when the administrator specifies that client authentication is required.

   

3. Insert one of the smart cards from the Open Gemplus GemSAFE smart card dialog box, and then click OK.

   

4. Type your PIN, and then click OK.

When the user provides the PIN and authentication occurs, an SSL connection is established, and the following page appears.

The following illustration shows an unencrypted connection with network monitor.

This following illustration shows an encrypted connection with network monitor.

S/MIME

One of the most popular applications used at Hay Buv Toys is e-mail. HBT wants to establish a secure communication infrastructure that provides confidentiality, authentication, and integrity for internal and external e-mail communications. To secure the investment, HBT has already made smart cards for authentication, e-mail encryption, and signing. HBT deploys a secured Secure/Multipurpose Internet Mail Extensions (S/MIME) infrastructure by using Microsoft Outlook.

The following section describes how HBT enables Outlook for S/MIME while using smart cards.

Note: Microsoft Outlook 97 and Outlook Web Access (OWA) do not support S/MIME**.** S/MIME clients can also be enrolled with Key Management Services in Microsoft Exchange 5.5 or Exchange 2000 or with the CA services Web client.

Outlook Configuration for S/MIME

Before you configure S/MIME in Outlook, be sure to register the smart card. To register smart cards, copy the smart card e-mail certificate to the local certificate store.

1. Open Microsoft Outlook.

2. Fom the Tools menu, click Options, and then click the Security tab.

3. Under Secure e-mail, click Settings.

   

4. The stored S/MIME certificate is retrieved from the local certificate store and the S/MIME configuration is done automatically.

5. If you are using multiple key sets (dual key pairs), you must specify the certificate for encryption and the certificate for signing. Under Certificate and Algorithms, next to Signing Certificate, click Choose, and then select the signing certificate you want. Then, next to Encryption Certificate, click Choose, select the encryption certificate you want, and then click OK.

   

   Note: The encryption algorithm used for e-mail privacy may vary. The "strongest" available algorithms of sender and recipient are always negotiated by PKCS#7, regardless of the algorithm chosen before. Also, the strongest algorithms are determined by the available encryption pack for Outlook (40-Bit or 128-Bit Outlook Encryption Pack).

   In this example, only one key set, and therefore only one corresponding certificate is available for signing and encryption.

   

   The following illustration shows the S/MIME certificate issued to user mail1. The certificate is used for e-mail encryption and signing verification. The corresponding private key to this certificate is stored on the smart card.

   

Sending an encrypted and signed message with smart cards

The following section describes how a user encrypts and signs messages with smart cards. The user tasks are similar with KMS-enrolled S/MIME clients, but require users to insert a smart card and enter the smart card PIN.

Window 2000 High Encryption Pack is not sufficient to acquire strong e-mail encryption for Outlook. Because Outlook uses its own cryptographic service provider (CSP), Outlook 98 and Outlook 2000 provide their own High Encryption Packs. Outlook High Encryption Pack CSP (O2KDOM.EXE, O98DOM.EXE) is available at: https://office.microsoft.com/

The following illustration shows an e-mail message that includes signing and encryption buttons on the Standard toolbar.

Users can also perform signing and encryption tasks from the Message Options dialog box, as shown in the following illustration.

When encrypting or signing an e-mail message, the user is prompted to insert a smart card.

After inserting the smart card, the user is prompted to type a PIN to access the private key stored in the smart card.

After the user enters the correct PIN, the e-mail message is digitally signed with the private key stored in the user's smart card, and then encrypted with the public key extracted from the recipient's e-mail certificate, which may be stored in the directory or the Global Address List (GAL).

Decrypting and signature verification with smart cards

The following section describes the user experience when decrypting and verifying a digital signature with smart cards.

When attempting to open a signed and encrypted e-mail message, the recipient is prompted to insert a smart card and then type the smart card PIN.

The private key from the recipient's smart card performs decryption of the message. The public key extracted from the sender's certificate performs signature validation. The Security line and the two icons located in the top right corner of the following illustration indicate that this e-mail message has been signed and encrypted.

VPN Configuration

HBT plans to connect the HBT USWest sales force through the Internet to corporate resources. HBT decides to use an Internet connection because Remote Access Service (RAS) services are costly, and do not provide the transport security of select ISPs.

HBT chooses an ISP that provides points of presence (POP) over the Western United States and allows dial-up connections in every location for local call rates. The selected ISP supports user authentication and accounting Remote Authentication Dial-In User Service (RADIUS). HBT plans to integrate RADIUS into their environment so they can manage their user accounts rather than rely on the authentication services provided by the ISP.

This means that the HBT Active Directory must validate user access whenever an HBT user initiates authentication after completing a dial-up connection on the POP or a tunneling connection on a VPN server. Although transport is provided by third parties, all authentication is managed centrally by HBT and the account database is owned by HBT.

To enforce dial-up and VPN logon, HBT provides customized smart cards to the pilot mobile users. When a user inserts the smart card and types the PIN, the dial-up or VPN connection is established. No user name or password is required.Dial-up connection is established when the user is authenticated and authorized by the POP. The ISP POP sends the authentication request in a RADIUS package to the ISP Radius Proxy. ISP Radius Proxy forwards the authentication request to the HBT Radius server. HBT Radius server then validates the authentication request with the HBT Active Directory account. If the account is validated and authorized at the HBT site, the mobile user gains access to the ISP POP. This user authentication method is only supported by Extensible Authentication Protocol; it is not supported by default authentication methods, such as Challenge Handshake Authentication Protocol (CHAP), MS CHAP, or MS CHAP v2.

HBT corporate network is connected to the Internet through a Microsoft Internet Security and Acceleration Server (ISA) enterprise firewall. Located in the DMZ are the Microsoft Radius Server (Internet Authentication Service IAS) and also Microsoft VPN Server. The Radius client for the HBT Radius server is the ISP Radius Proxy, that proxies all HBT authentication requests from the POPs to the HBT Radius server.

For tunneling, HBT uses L2TP/IPSec, which provides additional security during transport. All packages are authenticated and encrypted with triple Data Encryption Standard (DES). Also, the tunnel endpoints (VPN Server Mobile Laptop) are authenticated with certificates. Building a VPN connection (tunnel) requires authentication to the corporate VPN server. Alternatively, Point-to-Point Tunneling Protocol (PPTP) and MS-CHAPv2 (User name and Password Logon) is provided for non-W2K clients. The following illustration shows the HBT corporate network connections.

The following section describes the setup, configuration, and smart card logon for the VPN connection. The setup and configuration for dial-up connections is similar.

VPN Server Setup and Configuration

Routing and Remote Access Services (RRAS) on Windows 2000 provides the HBT VPN service. The setup of Windows 2000 RRAS is installed by default but not configured.

When you start the RRAS service for the first time, you are prompted to configure the service. Use the RRAS Setup Wizard to configure the RRAS service as a RAS Server or a network router.

Before you configure RRAS as a VPN server, verify that IP is installed on the RRAS server machine and on all VPN clients. VPN service will not start without the IP protocol installed on the client.

Be sure to specify which network card is connected to the ISP, and also the network card that is connected to the HBT corporate network.

VPN tunnels need their own IP addresses for tunnel endpoints. IP addresses can be assigned from the HBT corporate Dynamic Host Configuration Protocol (DHCP) services or from a specific IP pool. The following illustration shows a specific IP pool with an address range of 10.0.0.51-10.0.0.60 for ten concurrent VPN connections. If a DHCP for IP assignment is used on a VPN machine acting as a router, a DHCP relay agent must be installed.

VPN service does not authenticate users by sending authentication requests directly to the domain controller; RADIUS authentication is required, as indicated by the following illustration.

The following illustration shows DCCLAB31 with the VPN server implemented and running.

RADIUS Server Setup and Configuration

Microsoft RADIUS server or IAS is responsible for granting or denying access to the ISP POPs and to the HBT VPN services. The HBT RADIUS server does not have an account database. It queries Active Directory for user authentication through LDAP. RADIUS clients consist of the RADIUS proxies and HBT VPN servers provided by the ISP. RADIUS service is not installed by default.

To install RADIUS service, start the Components Wizard, and then under Subcomponents of Networking Services: select the Internet Authentication Service (IAS) check box to install IAS.

After IAS installation is complete, RADIUS server is running. The next step is to specify the RADIUS clients for the RADIUS server. HBT decides to declare all VPN servers as RADIUS clients to this server. The ISP RADIUS proxy also acts as a RADIUS client.

Specify a Shared secret, and then check the Client must always se the signature attribute in the request check box.

IAS is now configured with the RADIUS clients. In this example, just the VPN servers are operational.

VPN Server Configuration for RADIUS and Smart Card Authentication

On the VPN server side, RADIUS must also be enabled. Smart card authentication is not set by default. VPN servers have to support EAP to support smart cards or certificates (soft tokens). The authentication provider for the VPN server has changed to RADIUS. For configuration information, such as the RADIUS Server name, a shared secret and the RADIUS authentication port is required.

EAP configuration can be set with RAS policies. In EAP Methods, smart card or certificate user authentication is selected. Click EAP Methods to configure authentication types for EAP.

VPN Client Configuration for VPN and Smart Card Logon

The following section covers the authentication method for smart cards or certificates, and the VPN tunnel type (PPTP or L2TP/IPSec) for VPN client configuration. For large deployments, Connection Manager Administration Kit is recommended.

1. Open the Network Connection Wizard.

2. Select a VPN connection, and then type the name of the VPN server. A new client connection, Virtual Private Connection, is created on the machine.

   

   

3. To set the VPN types, click to select the VPN connection, and then click Properties.

4. Click the Networking tab, and then under Type of VPN server I am calling, select PPTP or L2TP/IPSec from the menu.

   

   

5. To configure EAP for the client computer, click the Security tab. HBT requires a server validation certificate from the trusted HBT Certificate Authority. In addition, VPN clients will only connect to VPN servers from the USWest domain.

   

   

Requesting a Computer Certificate

When you select L2TP/IPSec, additional authentication processes are triggered. Before any user authentication will start, the machines will authenticate with certificates to each other (mutual authentication). For this reason, machine certificates must be installed for L2TP/IPSec. For large deployments, automatic enrollment of computer certificates by way of GPOs is recommended. This example illustrates the manual certificate request process. Be sure to start MMC with the certificate snap-in for computers, not for users. In the following procedure only user-related certificate templates are offered.Note: Rights to enroll Computer Certificate templates is managed within AD Sites and Services.

1. From the personal folder, start the Certificate Request Wizard, and click Next.

   

2. Select the Computer certificate template, and then click Next.

   

   The Computer Certificate is now installed on the local computer, as indicated by the following illustration.

   

VPN Client Logon with Certificates or Smart Cards

Established RADIUS Authentication and VPN Connection

The following section illustrates client-side and server-side impressions of established VPN connections with smart card logon.

VPN connection parameters.

Different VPN tunnel types. On the left, a PPTP connection with MPPE 128-bit (Microsoft Point to Point Encryption similar to RC symmetric encryption family). On the right, an IPSec connection in Encapsulated Security Payload with 3DES symmetric encryption.

A successful RADIUS authentication of the administrator, granting access to the VPN Server.

Unsuccessful RADIUS authentication of the administrator, denying access to the VPN Server. This is a result of a revoked certificate on the smart card.

VPN users that are currently logged on.

RADIUS, PPTP, and IPSec Network Traces

RADIUS authentication network trace between the VPN server and IAS server.

Establishing a PPTP connection between VPN client and VPN server. Smart card user logon is provided with EAP.

Establishing an L2TP/IPSec connection between VPN client and VPN server. Smart card user logon is provided with EAP.

The Code Signing Configuration

Code signing is a popular way to establish additional security. Office 2000 prevents viruses from infesting the system by only letting macros run when they are digitally signed.

Because macro viruses are common, HBT decided to configure the Microsoft Office 2000 suite to run only macros that were digitally signed.

The following section provides an overview on how to complete the following steps:

• Configure Word 2000 to run only signed macros.

• Sign Visual Basic for Applications code.

• Determine what happens when a Word document is opened.

1. From the Tools menu in Microsoft Word 2000, point to Macro, and then click Security.

   

2. In the Security dialog box, click the security level you want for running macros. By default, the security level for signed macros is set to High, and click OK.

   

In the following section, HBT enforces signing the Visual Basic for Application Macros.

1. From the open macro, on theTools menu, click Digital Signature.

   

2. In the Digital Signature dialog box, click Choose to select the certificate for macro signing.

   

3. In the Select Certificate dialog box, choose the macro signing certificates or code signing that you want, and then click OK.

   

The current VBA project is signed with the corresponding private key belonging to the code signing certificate, as indicated in the following illustration.

The code signing certificate is used to verify the digital signature of the macro, and the macro signature is generated when the VBA project is saved. The corresponding private key to the code-signing certificate is located on a smart card. Therefore a smart card must be inserted and a PIN must be typed in to access the private key of the smart card.

Opening an Office 2000 document that contains a macro

Before a signed macro will run automatically in Word, the user has to trust the administrator code-signing certificate. If the user does not trust the certificate, the macro cannot be enabled.

The Administrator certificate is now trusted explicitly, so the macro can be enabled. In all other cases, the macro will not run.

The following illustration shows the macro running in Word.

The following illustration shows the administrator code-signing certificate is trusted. A list of all trusted certificates can be found in Word: on the Tools menu, point to Macro, and then click Security. Click the Trusted Source tab.

The example companies, organizations, products, people, and events depicted herein are fictitious. No association with any real company, organization, product, person or event is intended or should be inferred.