Secure E-Commerce with Smart Cards - 14 Sep 1999

Reduce the risks

Your company might still consider smart cards to be a futuristic technology. To help make them a present reality, Windows 2000 (Win2K) will offer highly integrated support for smart cards. In this article, I introduce you to smart cards, show you why they're important, and explain how they work and how to start using them in Win2K. Specifically, I show you how to set up smart-card-based logon using Gemplus' GemSAFE smart card and GCR410 smart card reader. But smart cards aren't perfect, so I also show you some of their inherent risks.

Smart cards enable public key infrastructure (PKI), which in turn facilitates e-commerce. PKI lets you achieve a level of trust for electronic transactions that equals or surpasses that of the paper- and signature-based world. PKI can provide message integrity, privacy, and nonrepudiation. You can't deny you sent a message if you've signed it with your digital certificate because your public key verifies your signature. If a public key successfully verifies a signature, the only person who could have sent the message is the person with the private key. (For more information about PKI and public and private keys, see "Related Articles in Windows NT Magazine," page 87.) The cornerstone of PKI security is that the private key associated with a digital certificate must remain private. An intruder can use a private key to easily forge transactions.

How Smart Cards Work
Smart cards protect private keys, which are so crucial to PKI. Without smart cards, private keys reside on the local workstation, where they're vulnerable to intruder and physical-access attacks. When you store your certificate on a smart card, the processor inside the smart card generates the corresponding private key directly and permanently inside the smart card. The smart card processes any information that you need to encrypt by using your private key.

This procedure might sound impractical if you need to encrypt and email a file of several megabytes—how can a smart card's relatively slow resources accomplish that encryption? Because, in keeping with PKI's strategy, you don't encrypt actual data with private and public keys. Instead, the system generates a much faster symmetric session key to encrypt the file. The system sends the session key and the file, which the smart card first encrypts with the private key. The recipient decrypts the session key with your certificate's public key, then decrypts the data. This way, you're pushing a fairly small amount of data through the smart card.

Smart cards also let you take your private key with you. If you move from one workstation to another without a smart card, you might not have access to your certificate, depending on the PKI software you're using. With a smart card, however, you can go to any system that has a smart-card reader and log on, initiate transactions, sign and encrypt email, and so on. Eventually, when truly public PKI exists, you might perform the same actions at Internet kiosks in an airport. By sequestering the private key within the smart card, you sidestep many risks. In "Protect Your Passwords," October 1998, I described the many ways to steal Windows NT passwords that are stored on the local system. As intruders turn their attention to PKI, I anticipate similar incidents of intruders stealing locally stored private keys.

Smart cards also reduce password risks. Users often neglect to create quality passwords; therefore, intruders can easily guess those passwords. Passwords are also vulnerable to network eavesdropping and intruder programs. Smart cards provide much stronger two-factor authentication: The user must physically have the smart card and must know the card's personal identification number (PIN). Even when a user misplaces the smart card, an intruder has only a few chances to guess the correct PIN before the smart card permanently locks itself. As soon as the user reports the lost card, the PKI software can revoke the certificate and render it invalid even if the intruder discovers the PIN.

Smart cards are tamper-resistant—you can't cut them open and physically extract the private key, and you can't copy them like their magnetic-strip forebears. Additionally, smart cards are human-friendly: We're conditioned to trust and carefully handle credit cards and automated teller machine (ATM) cards, and we're accustomed to using a PIN. User acceptance of smart cards is crucial to making universal PKI a reality. (For more information about the advantages—and disadvantages—of smart cards, see the sidebar "Smart Cards or Dumb Cards?")

NT doesn't offer built-in smart card support, but you can add the support with products such as GemSAFE. After you install the product, you can use the smart card for secure emailing and Web browsing. Also, applications that support PKI standards can then use smart cards for encryption or digital signatures. For example, Microsoft Office 2000 lets you digitally sign Microsoft Word macros, and Adobe Acrobat 4.0 supports digital signatures. Win2K embraces PKI and smart cards at the OS and directory levels, thus facilitating universal usage throughout the system. With Win2K, you can use smart cards for logon, email encryption, on-disk file encryption, Web access, and more.

Setting Up Smart Cards
Before you can use smart cards, you need a PKI, which Win2K provides with Certificate Server and Active Directory (AD). You have a bewildering array of options for how you set up PKI, depending on whether you'll host your own Certificate Authority (CA), outsource it to a provider such as VeriSign, or use a combination of the two.

In this article, I describe the simplest scenario you can implement—one computer serving as the AD domain controller, Certificate Server installed on an enterprise root CA, and one smart card reader. A root CA is the highest in the trust hierarchy. An enterprise CA means that the certificate server will use AD as its data store and thus offer you a host of certificate management features. A standalone CA, which uses a local database instead of AD, is what public Web servers typically use to issue certificates to Internet users.

After you install Win2K as a domain controller running DNS and Microsoft Internet Information Server (IIS), you must install Certificate Server. Go to the Add/Remove Windows Components applet in Control Panel, and select Certificate Services. Install Certificate Server as a root enterprise CA. Other than specifying the name, you can use the defaults on the subsequent dialog boxes. Next, you need to define which types of certificates your new CA can issue. You can use certificates for many purposes, including validating Web servers, encrypting files with Encrypting File System (EFS), and securing email. A certificate template—a management feature of enterprise CAs—defines valid uses for a particular certificate.

Screen 1 shows that I've added templates to my example CA and that I'm about to add the Smartcard Logon template. (You access these templates through the Certificate Authority Microsoft Management Console (MMC) snapin, which is available after you configure Certificate Server.) As their name suggests, Smartcard Logon certificates are limited to logon; Smartcard User certificates let you use one smart card for logging on and signing email. You must also add the Enrollment Agent template, which you need if you want to create new certificates. You now have a PKI that can authenticate users via smart cards.

Your next step is to install the GCR410 smart card reader, which is a simple step thanks to Plug and Play (PnP). Shut down the system, then connect the reader's two cables to the computer. The PS/2 cable is a wedge connector that inserts between the PS/2 port and the keyboard or mouse cable. The reader draws power from the PS/2 port. The serial cable, which plugs into a spare serial port, establishes communication between the system and the reader. When you start up your system, Win2K automatically detects the new reader—a welcome banner now prompts you to log on with a smart card or password, as Screen 2, page 87 shows.

Because smart card enrollment is a sensitive administrative function such as assigning user IDs and passwords, you need to limit this capability to specific users and workstations. Consequently, your next step is to enable one system as a smart card certificate enrollment workstation. First, request an Enrollment Agent certificate for the administrator who will enroll users with smart cards (i.e., assign smart cards to users). When the administrator requests smart card certificates for new users, Win2K signs the request with this Enrollment Agent certificate. Next, open the MMC snap-in Certificates. This MMC snap-in lets you manage certificates associated with your user account and request new ones. Request a new Enrollment Agent certificate, provide a friendly name, and click Install.

The preceding steps are necessary only for initial setup. You'll repeat the remaining steps for each user who needs a smart card. (In this article's example of only one computer, the user will need the right to log on locally to this server, by being a member of the Server Operators group, for example.)

You can now request smart card certificates on behalf of other users. Select an existing user account or create a new one. Open Microsoft Internet Explorer (IE), and enter your CA's server name (e.g., b1) followed by /CertSrv, as the URL in Screen 3 shows. Request a certificate, then specify an advanced request on the next screen. On the following screen, select Request a certificate for a smart card on behalf of another user using the Smart Card Enrollment Station. Screen 4 shows Certificate Server's final user enrollment screen. Select the Certificate Template (i.e., Smartcard User or Smartcard Logon). You can also specify which CA to use, although this field defaults to the CA you've installed. You can specify the Cryptographic Service Provider (CSP) to use with this certificate. A CSP provides basic cryptographic services to the OS and applications. A smart-card-specific CSP uses the smart card to fulfill requests for the services that involve the private key. Screen 4 shows the GemSAFE as the selected CSP. You can also specify the Enrollment Agent certificate that will sign this request. Use the Enrollment Agent certificate you created earlier. Finally, you need to specify the user for whom you're requesting this certificate, then click Enroll. The system will prompt you to insert the smart card into the reader and enter its PIN. Certificate Server will display a page in your browser informing you that the operation was successful. You can then view the certificate on the smart card or enroll another user.

Now you're ready to log on using the smart card. First, log off the system and reinsert the card. The reader notifies the system that you've inserted a card, and the system asks you for the PIN. Enter the PIN, and your portion of the logon is complete. Win2K sends the PIN to the smart card for authentication. Then, the PIN performs cryptographic functions that Win2K requests (e.g., Win2K asks the smart card to sign a logon request).

Microsoft facilitated an Internet Engineering Task Force (IETF) proposal called PKINIT to extend the Kerberos version 5 (V5) authentication protocol to support public-key- and private-key-based authentication in addition to Kerberos' shared secret symmetric key method. Consequently, the workstation sends the logon request to a domain controller via a Kerberos Authentication Services (AS) request. The Kerberos Key Distribution Center (KDC) running on the domain controller verifies the request by using your certificate's public key, which the CA publishes. If everything checks out, Kerberos grants a ticket and you can log on. If a user loses his or her smart card, you simply open the certificate Services MMC snap-in, select the certificate under Issued Certificates, revoke it, publish the updated certificate revocation list (CRL), and issue a new smart card to the user. If someone tries to log on with the now invalid smart card, Win2K will refuse the logon.

Only Time Will Tell
The simplest-case scenario of implementing smart-card-based logon, which this article describes, is fairly easy. Ideally, a company with Win2K Professional (Win2K Pro) workstations, a spare serial port, and a CA hierarchy in place could implement smart card logon by simply plugging a reader into each workstation and issuing a smart card to each user.

However, the real world requires much more planning. Smart card deployment is really PKI deployment, which, according to the media, is fraught with complication and complexity. Win2K, with its PKI support at the desktop and directory levels, promises to provide a platform for the interoperability and integration necessary to make PKI take off.

I hope Microsoft releases a quality, usable OS that catches on quickly. If Win2K beta 3 is any indication, Microsoft might actually pull it off. When I implemented smart cards based on the procedures I outline in this article, everything worked the first time. If application vendors take advantage of Win2K's directory and public-key services, PKI could become a reality much sooner for everyone. And if manufacturers start building smart card readers into the PC, deployment costs will drop even lower and accelerate the move to smart-card-based PKI. Only time will tell.