Smart Cards and the Windows 2000 PKI

Article
03/24/2009

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

Introduction

This paper covers security related issues with respect to deploying smart cards in a Windows 2000 environment.

After reading this chapter, you should have a clear understanding of the following topics:

Hardware and software requirements for smart card deployment
Enrollment processes for smart card users
Client authentication and logon with smart cards
E-mail signing and encryption

Enhanced Security with Smart Cards

In a secure network environment, data cannot be accessed or modified by people who do not have rights to the information. Unfortunately, options for securing an enterprise network until now have been limited. Typically, organizations have relied on a password authentication system to protect their digital assets. The weaknesses of such a system are numerous: users choose simple passwords that are easy to hack; administrators engage in password fraud; passwords are shared and then stolen, and so on.

Now, in a Windows 2000 environment, you can use smart card technology to protect your network, instead of relying on password protection. Smart cards provide tamper-proof storage for a user's key pair and an associated public key certificate. These symmetric and asymmetric keys are protected through a PIN (Personal Identification Number) that the user has to type in when a key or a certificate on the smart card is required.

Furthermore, when you deploy smart cards in a Windows 2000 environment, you can leverage operating system features such as Kerberos and S/MIME to increase security in relation to authentication, e-mail encryption, and key exchanges.

Smart Card Logon Requirements

Before implementing a smart card logon in your enterprise, make sure your network meets the following system requirements.

Required Hardware

The PC/SC Workgroup has developed specifications for interoperability between readers and smart cards. Microsoft Windows 2000 supports any smart card reader that is PC/SC compatible. For a complete list of supported smart card readers, see the hardware compatibility list at https://www.microsoft.com/hcl.

Note: Every smart card reader and/or coupler is usually a smart card writer. With this functionality, you can use a generic smart card reader to write certificates to a smart card.

Required Software

In a Windows 2000 environment, you must have a Windows 2000 Server product with the following software components installed:

The Certificate Authentication Service. With this service, Windows 2000 can create certificates that can be installed on the smart card. A Windows 2000 server running this service is called a Certificate Authority (CA).
Microsoft Active Directory™. This is the Windows 2000 LDAP V3 compliant directory service where the certificates are stored.
A Cryptography Service Provider (CSP). This facilitates communication between the device and the smart card. The CSP must be signed by Microsoft, or it will not work on Windows 2000. Typically, a CSP is provided by the manufacturer of the Smart Card Reader—for example, a GemPlus reader would use a GemPlus CSP, a Schlumberger CSP would use the Schlumberger CSP, and so on.

You also must have Windows 2000 installed on the client because only Windows 2000 uses a PC/SC-compliant smart card reader with Kerberos as the authentication protocol.

Required Enrollment Processes

In the enrollment process, a certificate is issued on a smart card. In Windows 2000, Smart Card Enrollment Control enables administrators to obtain certificates for smart card users, rather than each user enrolling for smart card certificate. Enrollment is independent from the PKI design.

During a typical enrollment process, the enrollment agent writes the certificate on a user's smart card. The enrollment agent then becomes a member of the Certificate Requester Group in Windows. The following conditions must be met for successful enrollment:

The enrollment agent must have an enrollment agent certificate.
The CA has to be online while the user is enrolled.
The CA needs to be trusted in the CA hierarchy.
The appropriate CA needs to be configured to issue certificates for smart card logon and for the smart card user if the user will be encrypting and signing e-mail.

Smart Card Logon and Authentication

This section describes the recommended authentication protocol for smart card logon and the logon process.

Kerberos Authentication Protocol

The Kerberos protocol is the primary authentication mechanism in the Microsoft Windows 2000 operating system. At the heart of the protocol is a trusted server called a Key Distribution Center (KDC). When the user logs on to the network, the KDC verifies the user's identity and provides credentials called "tickets", one for each network service that the user wants to use. Each ticket introduces the user to the appropriate service, and optionally carries information that indicates the user's privileges for the service.

Microsoft's implementation of the protocol uses extensions to enable smart card logon. This provides the twin advantages of strengthening the authentication process and providing seamless entry into the public key infrastructure. Smart card logon only works with Kerberos; you cannot use NTLM, the authentication method of Windows NT 4.0 and earlier versions of Windows NT, for smart card logon.

Typically, Kerberos uses Symmetric Key encryption. The certificate on the smart card, however, is based on asymmetric public key encryption.

For more information about using Kerberos in the Windows 2000 environment, see: https://www.microsoft.com/windows2000/

Smart Card Logon

Windows 2000 uses a layered approach for local and domain logon as illustrated in the following diagram.

The smart card logon process includes the following steps:

After the user inserts his or her smart card, Windows Logon Service (WINLOGON) dispatches this event to MSGINA. The window below displays.
The user is prompted to enter a PIN (rather than a user name and password).
MSGINA sends the PIN to Local Security Authority (LSA).

Note: There is no logon domain information required, because the user is logged on with a Unified Principal Name (UPN).
The LSA uses the PIN to access the smart card and extract the certificate with the user's public key.
The Kerberos security service provider sends the signed user's certificate with the user's private key to the Key Distribution Center (KDC).
The KDC compares the UPN (user principal name) in the certificate with the UPN on the user object in the directory. The KDC also verifies the signature on the certificate to ensure that it was issued by a Certificate Authority that is trusted in the Active Directory forest such as an Enterprise CA.
The KDC encrypts the logon session key and the Ticket Granting (TGT) for the Ticket Granting Service with the Public Key from the client certificate. This ensures that only the client with the appropriate private key can decrypt the logon session key.
The client decrypts the logon session key and presents the TGT to the ticket granting service. After this process is complete, all other communication in Kerberos uses symmetric encryption.

E-mail Signing and Encryption

This section describes message encryption using secured multipurpose Internet mail extension (S/MIME) and explains how Smart Card Enrollment Station utilizes S/MIME to encrypt messages.

Message Encryption

S/MIME is a popular protocol used for message encryption and signing. Microsoft e-mail clients (Microsoft Outlook 98, Outlook 2000, and Outlook Express) and Microsoft Exchange support S/MIME. This security option provides for a completely opaque message body and signature. It generates a one-time symmetric key and encrypts it in the recipient's public key, so that only that specific key owner can decrypt it, and then sends the message. On the recipient end, the private key is used to decrypt the symmetric key, which is then used to decrypt the message. This process is transparent to the user. It is performed with no interaction between client and additional network services except for a directory query to obtain the recipient's public key. The following diagram shows the encryption and decryption process.

Digital signatures

When a digital signature is added to a message, the message contents are used to compute a hash value that identifies the sender and serves as a "digital fingerprint" that verifies the message has not been altered in transit. A message digest algorithm, the message contents, and the sender's private key are used to generate the hash value. The recipient decrypts the original hash value with the sender public key, which is readily obtainable from a trusted directory, such as the Active Directory, or may optionally be sent with the signed message. The message is decrypted, and then a new hash value is computed from the received text and compared to original hash value. If they match, the contents and the sender's identity are verified. The following diagram illustrates this process.

Smart Card Enrollment Station

The Smart Card Enrollment Station is a Web-based application that provides smart card enrollment for S/MIME. The station is part of the Web client that will be installed during setup of the Window 2000 Certificate Service. By default, the Web client is installed on every CA. (A separate Web client exists for the Enterprise and standalone CAs.) Alternatively, the Web client can be installed on a separate Windows 2000 server with Internet Information Services (IIS)..

Smart card enrollment is more complex than the Key Management Service enrollment in Exchange 5.5. The client initiates the enrollment process. All key pairs are generated by the smart card, in contrast to the Exchange 2000 KMS enrollment process, where encryption key pairs are generated within Key Management server and signing key pairs are generated in the mail client site. Therefore, key recovery is not provided with smart cards—private keys are never revealed in smart cards.

Before enrolling users, appropriate rights must be set for the smart card enrollment operator to IIS/Certificate Services and also to the Certificate Templates in Windows 2000. The smart card user needs logon, client authentication and secure mail access, and the SC enrollment operator needs access to the Enrolment Agent Template.

Smart Card S/MIME Enrollment Process

Following is a description of the smart card enrollment process:

The smart card operator accesses the Web enrollment page https://hostname/certsrv/ and opens the Smart Card Enrollment Station.
The smart card operator requests a smart card user certificate for a specific user.
A key-generating request for a key pair is sent to the hardware CSP (Smart Card CSP) and the smart card is accessed with a PIN.
The smart card generates the key pair (multiple key pairs, if the signing and encryption process is separated with different key pairs).
After the key pair is generated, the public key is retrieved from the smart card.
The smart card enrollment station sends the public key along with the certificate request message format (PKCS #10) to certificate service. IIS passes this request to the certificate service.
Certificate Service (CS) generates the requested certificates.
If certificate service is configured as an Enterprise CA, the generated certificates will be published to Active Directory. If CS is configured as a stand-alone CA, then certificates are published in the file system by default.
CS sends the certificates to IIS. IIS will pass the certificates to the smart card enrollment station.
The certificate is stored in EEPROM of the inserted smart card. The smart card is now ready for distribution to the specific user.
The user registers the smart card on his or her local workstation with the smart card registration tool (provided by smart card vendors). If the smart card is used for logon, the smart card is automatically registered at first logon. In registration a copy of the smart card user certificate is stored in the local certificate store of the user's machine.
Finally, Outlook or Outlook Express is configured for S/MIME by retrieving the smart card user certificate from the local certificate store.

Sending Encrypted E-Mail with Smart Cards

S/MIME client deployment with smart cards and the common S/MIME deployment based on soft tokens (certificates and keys) are very similar. Both use S/MIME certificates and keys for mail encryption and signing. The main difference is where private keys are stored.

In a smart card deployment, private keys are stored on the smart card and can only be accessed through the smart card PIN. In S/MIME deployments based on soft tokens, private keys are stored in the protected store of the local machine and can be accessed through the user logon password or an administrator password.

The following diagram illustrates e-mail encryption and decryption using smart cards. A detailed description of the process follows the diagram.

Encrypting and Signing E-mail with a smart card

Alice wants to send Bob a signed and encrypted message.

In the mail encryption process, Bob's certificate is retrieved from the corporate directory. A session key is generated and used for the message (bulk) encryption. Bob's public key, located in Bob's S/MIME certificate, encrypts the session key.
To generate a digital signature, Alice inserts her smart card into the reader. A hash function produces a message digest of the original mail. Alice enters her smart card PIN to gain access to her private key. The signing operation is now processed inside the smart card by encrypting the message digest with Alice' private key.

Decrypting and Verifying the Signature of the E-mail

Bob receives the encrypted and signed e-mail from Alice.

To decrypt the e-mail, Bob inserts his smart card into the reader and enters his PIN. The encrypted session key is decrypted with Bob's private key, which is stored in his smart card. Then, the session key is used to decrypt the e-mail.
To decrypt the digital signature, Alice's public key is retrieved from the corporate directory where her certificate is published. (Alice's public key may also be sent with the e-mail message, depending on the security configuration of the S/MIME client.) The same hash algorithm generated when Alice inserted her smart card into the reader is used to produce a message digest locally. If the received message digest and the locally generated message digest match, the mail has not been altered during transport and Alice is authenticated as the author of the e-mail message.

Microsoft Enterprise Services

Roland Zeitler: MCS Germany

Jung-Uh Yang: MCS Germany

March 2001

For information about Enterprise Services, see
https://www.microsoft.com/services/microsoftservices/default.mspx.

Companies, organizations, products, people, and events depicted in examples in this paper are fictitious. No association with any real company, organization, product, person, or event is intended or should be inferred.