17.3 Leveraging smart cards and USB tokens for PKI-enabled applications | Windows Server 2003 Security Infrastructures: Core Security Features (HP Technologies)

Windows 2000, Windows XP, and Windows Server 2003 can support both smart cards and USB tokens. Although these two device types have a different form factor and typically use a different computer connection interface, they both offer the same service: secure hardware-based PKI credential (private keys and certificates) storage.

Unfortunately, not every Windows PKI-enabled application supports smart card or USB token credential storage. As of this writing, the following Windows PKI-enabled applications are natively capable of dealing with smart card–enabled or USB token–based credentials:

Secure mail using S/MIME from the Outlook mail client
Smart card logon to a Windows Server 2003 domain (interactive logon)
Smart card logon to Windows Server 2003 from the Windows Server 2003 Terminal Services client
Smart card logon to a Windows Server 2003 domain using remote access
Client authentication from Internet Explorer in SSL/TLS-based secure Web scenarios

Windows Server 2003 includes important enhancements to the way Windows administrators can use smart cards and USB tokens. Administrators can now access their credentials stored on a smart card or a USB token when running the dcpromo.exe command (to install AD), the net.exe commands, and the runas.exe command (to switch between different security identities), and when using terminal services.

Next we focus on the built-in Windows 2003 and Windows XP smart card and USB token support, Windows Server 2003 smart card logon, and third-party software that you can use to extend the Windows smart card or USB token management capabilities on the Windows Server 2003 platform. Unless mentioned otherwise, in the following sections “smart card” refers to both smart cards and USB tokens.

For a broader introduction to smart cards and USB tokens, refer to the following books:

Smart Card Security and Applications by Mike Hendry, Artech House, 2001.
Authentication: From Passwords to Public Keys by Richard E. Smith, Addison-Wesley, 2002.
Smart Cards: The Developer’s Toolkit by Tim Jurgensen and Scott Guthery, Prentice Hall, 2002.

17.3.1 Windows Server 2003 and Windows XP smart card support

For a complete list of all the smart card readers and USB tokens that are compatible with Windows 2003 and Windows XP, refer to the Windows Hardware Compatibility List (HCL), available from http://www.microsoft.com/windows/catalog/ for Windows XP and http://www.microsoft.com/windows/catalog/server/ for Windows Server 2003. All Windows Server 2003 and Windows XP compatible smart card readers support the PC/SC smart card interface. More information on the PC/SC smart card interface standard is available from http://www.pcscworkgroup.com/.

Out-of-the-box Windows Server 2003 supports smart cards from Gem- plus, Infineon, and Schlumberger. The support for smart cards depends on the availability of a driver and a smart card Cryptographic Service Provider (CSP).^[4] Both software components enable the operating system to communicate with the card for credential storage, cryptographic, and configuration operations. Smart cards and USB tokens from other vendors (ActivCard, Datakey, eAlladin, and Spyrus) are supported if you add the appropriate drivers and CSPs.

Most smart cards and tokens come with special management software allowing you to configure different card or token properties such as the PIN code. When you associate a PIN code with a smart card, you bind the card to the entities knowing the PIN code—a process that is known as smart card personalization. Most management software also allows you to set the number of bad PIN entry attempts after which the card is locked.

Figure 17.18 shows the token management utility eToken Format, which is made available by eAlladin together with its eToken USB tokens.

click to expand
Figure 17.18: eAlladin eToken Format utility.

17.3.2 Enrolling for smart card–based credentials

In a Windows Server 2003 environment, a user can enroll for smart card credentials (certificates and private keys), provided he or she has the appropriate permissions on the smart card certificate templates and provided the templates are available on the CA. To enroll for smart card credentials, a user can use any of the enrollment methods mentioned in Chapter 15.

Windows Server 2003 comes with two default smart card-related certificate templates: smart card user and smart card logon. Besides SSL/TLS client authentication and smart card logon, the smart card user template offers support for secure e-mail. Smart card certificates are visible in a user’s certificate store. When a smart card is plugged in, CryptoAPI will automatically copy the smart card certificates to the user’s certificate store. CryptoAPI will only propagate the first certificate on the smart card to the user MY certificate store container. It’s up to the Cryptographic Service Providers (CSPs) to propagate other certificates stored on the smart card.

An alternative is to let the user certificates and private keys be loaded centrally by an administrator with a special enrollment agent certificate. This is what Microsoft calls enrollment using a smart card enrollment station. Given the importance of smart card enrollment from a security point of view and given the difficulty of the user certificate enrollment procedure in general, the use of a smart card enrollment station is the preferred way to enroll users for smart card–based credentials in a corporate environment.

The smart card enrollment station interface is Web-based (it is illustrated in Figure 17.19). It is accessible from the default certificate server Web interface (provided that you are using an enterprise CA) by selecting the “Request a certificate for a smart card on behalf of another user by using the smart card certificate enrollment” option (which is available from the advanced certificate request menu option). Only administrators who have an enrollment agent certificate in their personal certificate store can request smart card certificates on behalf of another user. Smart card certificate requests are signed using the enrollment agent’s private key. The CA validates the requests using the enrollment agent’s corresponding public key. If you check the access control settings on the enrollment agent certificate template, you will notice that by default only domain and enterprise administrators can enroll for an enrollment agent certificate.

click to expand
Figure 17.19: Smart card certificate enrollment station interface.

By now it should be clear that enrollment agent certificates and smart card enrollment stations should be handled with extreme caution. An administrator with an enrollment agent certificate can impersonate anyone in the corporate network. He or she is the one generating smart card credentials, so he or she can also use them on behalf of a user to log on. If someone succeeds in logging on to an enrollment station using an administrator’s credentials, he or she can do even more harm. He or she can request smart card certificates on behalf of anyone in the organization and impersonate anyone on machines where a smart card reader is available. That is why it is advisable to install a smart card enrollment station on a dedicated highly secured machine, limit the number of enrollment agent administrators, use a special CA to issue smart card certificates, implement strict access control settings on the enrollment agent certificate templates, and write special security policies regulating the use of enrollment agent certificates and smart card enrollment stations.

17.3.3 Smart card logon

Smart card logon in Windows 2000 and Windows Server 2003 is based on an extension to the Kerberos protocol, called PKINIT, which stands for use of Public Key technology for Initial authentication. The details of PKINIT were explained in Chapter 5 on Kerberos. Remember that in PKINIT all occurrences of the hashed password in the initial Kerberos authentication sequences are replaced by a user’s public and private keys.

The use of smart cards for identification offers the following advantages:

Smart cards offer a user identification alternative that is much stronger than plain password identification. Smart card logon is based on two-factor authentication: It combines knowledge (of an alphanumeric PIN code) and possession (of the smart card).
Smart card logon is more difficult to break. The smart card logon sequence relies on asymmetric keying material instead of symmetric crypto-based hashed passwords.
Smart cards offer secure and tamper-resistant credential storage. The user’s credentials (private keys and certificates) never leave the card.

Theoretically, all critical calculations involving the private key also occur only on the card itself.

Smart cards can provide roaming of credentials. A user can log on and have access to his or her credentials from every system that has a smart card reader installed.

Installing a smart card reader on a Windows 2000, Windows XP, or Windows Server 2003 machine will change the GINA (the screen that pops up when you press <CTRL>-<ALT>-<DEL>), as illustrated in Figure 17.20 for Windows Server 2003.

click to expand
Figure 17.20: Smart card logon interface.

The easiest way to set up smart card logon is to use a Windows enterprise CA. An enterprise CA automates most of the enrollment-related tasks, such as publishing the certificate to AD and linking it to the user’s Windows account. Smart card logon certificates can also be issued by third- party CAs (e.g., an Entrust or Baltimore CA). How to do this is explained in the Microsoft Knowledge Base article Q281245 available from http:// support.microsoft.com/default.aspx?scid=kb;en-us;281245. In order for a smart card logon to work, both the domain controller, validating the smart card authentication request, and the user, logging on using a smart card, must have valid certificates. Valid means that both certificates must chain up to a trusted CA and that none of the certificates in the domain control- ler’s or the user’s certificate chains should be revoked. In order to check for revocation, the CRLs must be available and valid. For more information on certificate validation, please refer to Chapter 15.

A nice feature of smart card logon in Windows 2000, Windows XP, and Windows Server 2003 is that OS behavior for smart card removal can be set. The smart card removal behavior can be configured in the machine Security Options of the Domain, Site, OU, and Local Computer GPO objects at the following location: Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options. The values that can be set are No Action, Lock Workstation, and Force Logoff.

Windows 2000 and Windows Server 2003 also allow an administrator to force the use of a smart card for interactive logon. By default, a user who has a smart card can still log on using his or her password. To do so, check the “Smart card is required for interactive logon” box in the user object account properties or set the “interactive logon: Require smart card” security option in the computer portion of the GPO security settings.

17.3.4 Smart card management systems

For many large enterprises, the built-in Windows 2000 and Windows Server 2003 smart card management features are not enough. They are looking for advanced smart card and token management capabilities, such as:

Assigning smart cards or tokens to users. In a Windows environment this means linking the smart card or token (and not just the PKI credentials) to an AD user account.
Keeping track of the smart card or token content and usage.
Defining which PKI-enabled applications can be used with a user’s smart card or token.
Handling lost smart cards or tokens.
Formatting or reformatting smart cards or tokens.

Table 17.8 provides an overview of software vendors selling smart card management system software.

Table : Table 17.8 Smart Card Management Software
Vendor	Product	URL
ActivCard	ActivCard Identity Management System (AIMS)	http://www.activcard.com
Alacris	idNexus Smart Card Management Module	http://www.alacris.com
BellID	ANDiS	http://www.bellid.com
CardBase	Mascot	http://www.cardbase.com
Datakey	Card Management System (CMS)	http://www.datakey.com
eAlladin	Token Management System (TMS)	http://www.ealladin.com
Intercede	Edefice	http://www.intercede.co.uk

^[4]CSPs and CryptoAPI were explained in Chapter 13 of this book.