Smart Cards

Article
03/24/2009

By Jan De Clercq

Introduction

The need for security and enhanced privacy is increasing as electronic forms of identification replace face-to-face and paper-based ones. The emergence of the global Internet and the expansion of the corporate network to include access by customers and suppliers from outside the firewall have accelerated the demand for solutions based on public key cryptography technology.

A few examples of the kinds of services that public key cryptography technology enables are secure channel communications over a public network, digital signatures to ensure image integrity and confidentiality, authentication of a client to a server (and vice versa), and the use of smart cards for strong authentication.

The Microsoft Windows operating system platform is smart card–enabled and is the best and most cost-effective computing platform for developing and deploying smart card solutions.

What Is a Smart Card?

A smart card is a small, tamperproof computer. The smart card itself contains a CPU and some non-volatile storage. In most cards, some of the storage is tamperproof while the rest is accessible to any application that can talk to the card. This capability makes it possible for the card to keep some secrets, such as the private keys associated with any certificates it holds. The card itself actually performs its own cryptographic operations.

Although smart cards are often compared to hard drives, they’re “secured drives with a brain”—they store and process information. Smart cards are storage devices with the core mechanics to facilitate communication with a reader or coupler. They have file-system configurations and the ability to be partitioned into public and private spaces that can be made available or locked. They also have segregated areas for protected information, such as certificates, e-purses, and entire operating systems. In addition to traditional data storage states, such as read-only and read/write, some vendors are working with sub states best described as “add only” and “update only.”

Smart cards currently come in two forms, contact and contactless.

Contact cards require a reader to facilitate the bidirectional connection. The card must be inserted into a device that touches the contact points on the card, which facilitate communication with the card’s chip. Contact cards come in 3-volt and 5-volt models, as do current desktop CPUs. Contact card readers are commonly built into company or vendor-owned buildings and assets, cellular phones, handheld devices, stand-alone devices that connect to a computer desktop’s serial or Universal Serial Bus (USB) port, laptop card slots, and keyboards.
Contactless cards use proximity couplers to get information to and from the card’s chip. An antenna is wound around the circumference of the card and activated when the card is radiated in a specific distance from the coupler. The configuration of the card’s antenna and the coupler facilitate connected states from a couple of centimeters to a couple of feet. The bidirectional transmission is encoded and can be encrypted by using a combination of a card vendor’s hard-coded chip algorithms; randomly generated session numbers; and the card holder’s certificate, secret key, or personal identification number (PIN). The sophistication of the connection can facilitate separate and discrete connections with multiple cards should they be within range of the coupler. Because contactless cards don’t require physical contact with a reader, the usability range is expanded tremendously.

International standards govern the physical characteristics of smart cards. For example, the size of a card is covered by International Organization for Standardization (ISO) 7810. ISO 7816 and subsequent standards cover manufacturing parameters, physical and electrical characteristics, location of the contact points, communication protocols, data storage, and more. Data layout and format, however, can vary from vendor to vendor.

In addition to physical and manufacturing standards, an increasing number of standards exist for specific vendor applications. Credit card vendors, cellular phone vendors, Unites States and European banks, credit agencies, and debit agencies are examples of organizations that are tailoring smart card applications and procedures geared exclusively to the services they offer and the companies with which they do business.

The two largest vendors of operating systems for smart cards are MAOSCO (an industry consortium) and Microsoft. More information about the MAOSCO consortium and the MULTOS operating system for smart cards is available from https://www.multos.com.

The Microsoft Windows for Smart Cards operating system is a component-based architecture that supports multiple card chips and platforms. It’s extensible and supported by a growing number of card manufacturers and vendors. Developers can integrate the application programming interfaces (APIs) and the associated toolkit into environments that are already familiar to them. You can obtain cards that are compliant with Windows for Smart Cards from a variety of sources. You can develop smart card applications by using systems such as Microsoft Visual Basic and Microsoft Visual C++. Internally, Microsoft is working with Windows for Smart Cards–compliant third-party vendors to provide enterprise management tools that are compatible with Microsoft Windows 2000 and later operating systems. These will provide additional administrative features, such as the ability to remotely reset PINs.

A number of vendors are providing support and other standards for Windows for Smart Cards. Sun Microsystems has published and currently maintains specifications for both Windows for Smart Cards and a “Java Card.” Gemplus and Schlumberger also support Windows for Smart Cards, in addition to their own card operating system, the “Java Card” specification.

Why a Smart Card?

Smart cards are a key component of the public key infrastructure (PKI) that Microsoft is integrating into the Windows platform because smart cards enhance software-only solutions, such as client authentication, logon, and secure email. Smart cards are a point of convergence for public key certificates and associated keys because they:

Provide tamper-resistant storage for protecting private keys and other forms of personal information
Isolate security-critical computations, involving authentication, digital signatures, and key exchange from other parts of the system that don’t have a need to know
Enable portability of credentials and other private information between computers at work, at home, or on the road

The smart card has become an integral part of the Windows platform because smart cards provide new and desirable features as revolutionary to the computer industry as the introduction of the mouse or CD-ROM

Introducing Windows for Smart Cards

One of the newest members of the Windows operating system family, Windows for Smart Cards extends the benefits of the Windows environment to the smart card industry.

A Windows Powered Smart Card is a microcomputer without a graphical user interface (GUI). According to Gemplus, a leading smart card manufacturer, companies have reduced their technical support calls by 40 percent by implementing smart cards that perform automatic authentication, which previously was an error-prone manual process. Microsoft is working closely with smart card industry leaders such as Gemplus to develop its smart card technology to the highest performance and security standards in the enterprise. At the same time, Microsoft is integrating smart card technology with Windows-based architectures to facilitate ease of application development.

At a price of approximately $20 per card reader and a maximum of $5 per card, Windows Powered Smart Cards are an inexpensive way to strengthen your corporate security. Even when you implement the cards only for security reasons, your business still benefits from the multitude of other functions that Smart Cards facilitate. These services include payment functionality and storage of loyalty information, medical and citizen information, and personal contacts.

The Windows Powered Smart Card can enhance your existing corporate network; there’s no need to replace the existing system infrastructure. Windows for Smart Cards works with all Windows releases since Windows 95.

You can customize Windows Powered Smart Cards for each user, and program the cards with multiple keys. The cards can be used to log on to a PC or to one or more networks and to perform remote logons. By storing all of a user’s authentication information, one Windows Powered Smart Card can provide a user with admittance to all of their accounts—on the corporate network, within Internet chat rooms, or within financial institutions.

Therefore, Windows for Smart Cards used with one or more of the Microsoft Windows operating systems can enhance protection, improve productivity, increase profit, and facilitate promotion.

Enhanced Protection

Corporate computers generally are configured to require a form of authentication for logon purposes. Password authentication, the most widely used logon security mechanism, is only as infallible as its users. Users often share their personal passwords with friends and spouses. Even the most reliable user might write a password on a slip of paper where another user could discover it later. If a user doesn’t safeguard a password, the network might be subject to concurrent usage of a user account or worse, be unprotected against malicious break-ins.

Only one person at a time can use a Windows Powered Smart Card, which makes concurrent account usage impossible. Because the card is required to access the network, users are inclined to carry the card with them wherever they go, thus preventing malicious break-ins. Windows for Smart Cards supports multiple authentication mechanisms, such as PIN, fingerprint, or retina recognition. Your company can determine the method or methods that work best for you.

If the card is lost, no one else can use it to access the network because only the owner knows the PIN or has the fingerprint or retina to match the authentication account. Information and account balances aren’t lost if the card is lost because a user’s information is replicated on each card partner’s server. When a replacement card is activated and inserted into the card partner’s network, the information is transferred to the new card.

Like a bank or credit card, if a Windows Powered Smart Card is lost or stolen, an 800 number can be used to turn off the card and activate the issuance of a new card. Unlike a bank or credit card, however, a Windows Powered Smart Card can be produced at a branch office for quicker turnaround.

By using the most secure crypto-algorithms, such as RSA, DES, 3DES, AES, and SHA, and by being built on the most reliable chips, Windows Powered Smart Cards are virtually inviolable.

Improved Productivity

Windows for Smart Cards ensures a consistent experience for application developers and end users. Application developers can use development and debugging tools with which they’re already proficient, such as Microsoft Visual Studio, to create applications for Windows Powered Smart Cards. Additionally, developers save time by using the Microsoft Windows Smart Card Toolkit to write applications. Unlike tools that differ from vendor to vendor, Windows for Smart Cards is a logical extension of the Windows operating systems and provides a consistent development and runtime environment. By using the Windows Smart Cards Toolkit with the Windows operating systems, developers can write and debug many diverse applications in the same amount of time it would have taken to port one application to many diverse operating environments.

You can use Windows Powered Smart Cards with the Windows operating systems to store personal contact information. By using the cards as a companion to the Microsoft Outlook messaging and collaboration client, you can transfer the names, email addresses, and phone numbers of business associates from a PC or network to the card. You can slip the card into your pocket or wallet; then, miles and time zones away, you can insert it into another computer running a Windows operating system. Instantly, your Outlook information is accessible.

With the appropriate hardware, you can use Windows Powered Smart Cards to call a contact at the touch of a button, obtain a street address while driving, or exchange contact information with another user of Outlook. And unlike email attachments or floppy disks, the smart cards are tamper-resistant, making them resistant to viruses, physical modification, or any other type of unauthorized access.

In fact, physical defenses are built into the hardware of a Windows Powered Smart Card. It uses the software protection strategy of the access control list (ACL), enabling information to be retrieved from the card only if certain known principles (requester’s identification, computer identification, time of day) match information stored in the ACL. In addition, these smart cards use an MS-DOS–type file system so that applications from different vendors are stored separately. Vendors, therefore, can’t obtain information that doesn’t pertain directly to their application from a card. ACL and file partitioning, together with security libraries and mathematical algorithms, work in tandem to protect these smart cards from unauthorized users and the most invasive tampering. If anyone tampers with the card in any way (e.g., consecutive incorrect PIN entries, electron microscope, sawing open), it implodes, rendering it useless.

Windows Powered Smart Cards can be used to store medical information and citizen accounts. Pharmacies can check a patient’s card to verify that the patient isn’t taking medication that might interact negatively with a new prescription. By using Windows Powered Smart Cards, a doctor’s office can bill insurance companies at the time of treatment, eliminating copious paperwork and speeding the payment of charges. Furthermore, Windows Powered Smart Cards also can be used to help distribute food stamps, store traffic violations, and verify a consumer’s age for tobacco and alcohol purchases.

Vendors of Windows Powered Smart Cards can use standard Windows-based APIs to customize the amount and type of information stored on a card. For those loath to store their personal information on a card that could be lost, the card can be configured as an identification mechanism only. In this case, medical and citizen information resides on an agency’s server, and the user’s Windows Powered Smart Card acts as the identity key.

Increased Profit

With the adoption of e-commerce by the masses, fraud activity has increased dramatically. Stolen credit card numbers are used to purchase goods and services on the Internet, where signatures aren’t required to prove identity. Underage users can access information and entertainment that are intended for more mature audiences. With Windows for Smart Cards, a Web site administrator can ascertain the identity of a user signing in to a chat room to ensure the safety of patrons. In addition, administrators of Web sites that contain adult content can ensure that only the intended audience views the material.

Internet merchants can implement Windows Powered Smart Cards to obtain a digital signature when a customer purchases goods and services. Such a digital signature would protect financial institutions as well, ensuring that only a card’s owner can make purchases with the card. Windows Powered Smart Cards can be used in lieu of a bank or credit card in traditional purchasing scenarios as well. By writing a financial application and storing it on the card, a vendor can determine the payment method. Financial institutions can write applications for Windows Powered Smart Cards that store a prepaid value, deducting from it as purchases are made. Alternatively, developers can write applications for Windows Powered Smart Cards with the same Windows-based APIs they already use to interact with a server-side automatic billing program.

Richer Advertising

You can use Windows Powered Smart Cards much like a credit card to advertise your business and your corporate partners. You can also store loyalty information, such as airline miles and past purchase amounts, directly on the card. Or you can issue Windows Powered Smart Cards to your customers and sell advertising space on them.

Unlike a credit card, however, Windows Powered Smart Cards are read/writable. When your company’s strategic alliances change, you don’t need to manufacture more cards; instead, you can change the advertisements and loyalty information on the cards you’ve already issued.

Smart Card Enhanced Solutions

By enhancing software-only solutions, such as client authentication and secure messaging, smart cards enable a new breed of applications positioned to take advantage of future opportunities in the emerging global digital economy. Smart cards offer application developers a secure mechanism for enhancing solutions aimed at both the enterprise and the consumer.

Client Authentication

Client authentication involves identification and validation of a client to a server to establish a secure communications channel. A secure protocol, such as Secure Sockets Layer (SSL) or Transport Layer Security (TLS), is typically used in conjunction with a trusted public key certificate provided by the client that identifies the client to the server. The client could be Internet Explorer running on a Windows platform, and the server could be Internet Information Services (IIS) or some other Web server that supports SSL/TLS.

The secure session is established by using public key authentication with key exchange to derive a unique session key that can then be used to ensure data integrity and confidentiality throughout the session. You can achieve additional authentication by mapping the certificate to a user or group account with previously established access-control privileges. The smart card enhances the public key authentication process by serving as a secure store for the private-key material and as a cryptographic engine for performing a digital signature or key-exchange operation.

Smart Card Logon

In the past, interactive logon meant the ability to authenticate a user to a network by using a form of shared credential, such as a hashed password. Windows 2000 supports public key interactive logon and uses an X.509 version 3 certificate stored on a smart card along with the private key. Instead of a password, the user inputs a PIN to the Graphical Identification and Authentication (GINA) module; the PIN is used to authenticate the user to the card.

Logging on to a network with a smart card provides a strong form of authentication because it uses cryptography-based identification and proof of possession when authenticating a user to a domain.

For example, if a malicious person obtains a user’s password, that person can assume the user’s identity on the network simply through use of the password. Many people choose passwords they can remember easily, which makes passwords inherently weak and open to attack.

In the case of smart cards, that same malicious person would have to obtain both the user’s smart card and the PIN to impersonate the user. This combination makes an attack less likely because an additional layer of information is needed to impersonate a user. An additional benefit is that a smart card is locked after the PIN is entered incorrectly several times in a row, making a dictionary attack against a smart card extremely difficult. (Note that a PIN doesn’t have to be a series of numbers; it can also use other alphanumeric characters.) Attacks against a smart card don’t go undetected, because the malicious person must have the smart card in his or her possession and the rightful owner of the smart card would notice that it was missing.

During a smart card logon, the user’s public key certificate is retrieved from the card through a secure process and verified to be valid and from a trusted issuer. During the authentication process, a challenge, based on the public key contained in the certificate, is issued to the card to verify that the card is indeed in possession of and can successfully use the corresponding private key. After successful verification of the public-private key pair, the user’s identity contained in the certificate is used to reference the user object stored in Active Directory to build a token and return a Ticket-Granting Ticket (TGT) to the client. Public key logon has been integrated with the Microsoft implementation of Kerberos version 5 that’s compatible with the public key extension specified in the Internet Engineering Task Force (IETF) draft RFC 1510.

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 Personal Computer/Smart Card (PC/SC) Workgroup has developed specifications for interoperability between readers and smart cards. Microsoft Windows 2000 and later operating systems support any smart card reader that’s PC/SC compatible. For a complete list of supported smart card readers, see the hardware compatibility list at https://www.microsoft.com/whdc/hcl/default.mspx.

Every smart card reader 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 or later environment, you must have a Windows 2000 Server or later product with the following software components installed:

The Certificate Authentication Service. With this service, Windows can create certificates that can be installed on the smart card. A Windows server running this service is called a Certificate Authority (CA).
Microsoft Active Directory. This is the Windows 2000 and Windows Server 2003 Lightweight Directory Access Protocol version 3 (LDAPv3)-compliant directory service where the certificates are stored.
A Cryptographic Service Provider (CSP). The CSP facilitates communication between the device and the smart card. The CSP must be signed by Microsoft, or it won’t work on Windows. Typically, the manufacturer of the smart card reader provides a CSP—for example, a Gemplus reader would use a Gemplus CSP, a Schlumberger reader would use the Schlumberger CSP, and so on.

You also must have Windows 2000 or Windows XP installed on the client because only these operating systems use 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, Windows XP, and Windows Server 2003, the Smart Card Enrollment Control enables administrators to obtain certificates for smart card users rather than each user enrolling for a 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 email.

Smart Card Logon and Authentication

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

The Kerberos protocol is the primary authentication mechanism in the Microsoft Windows 2000, Windows XP, and Windows Server 2003 operating systems. 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, which offers the twin advantages of strengthening the authentication process and providing seamless entry into the PKI. Smart card logon works only with Kerberos; you cannot use NT LAN Manager (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.

As Figure 1 shows, Windows 2000, Windows XP, and Windows Server 2003 use a layered approach for local and domain logon,

Figure 1: Smart Card Logon Architecture

The smart card logon process includes the following steps (see Figure 2):

After the user inserts a smart card, the Windows logon service (WINLOGON) dispatches this event to the GINA.
The user is prompted to enter a PIN (rather than a username and password).
The GINA sends the PIN to the Local Security Authority (LSA).

Note: There is no logon domain information required, because the user is logged on with a User 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 KDC.
The KDC compares the UPN 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 CA that’s trusted in the Active Directory forest, such as an Enterprise CA.
The KDC encrypts the logon session key and the TGT for the ticket granting service with the public key from the client certificate. This step 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.

Figure 2: Smart Card Logon Process

Secure Email

Secure email is one of the more exciting public key–enabled applications because it allows users to share information confidentially and to trust that the integrity of the information was maintained during transit. Using Microsoft Outlook Express or Outlook 98, 2000, or XP, a user can select a public key certificate that a trusted CA issued to use for digitally signing and decrypting secure messages. When you publish the user’s certificate to a public directory in the enterprise or on the Internet, other users within a company or on the Internet can send encrypted email to the user, and vice versa.

A smart card adds a level of integrity to secure email applications because it stores the private key on the card, protected by a PIN. In order to compromise the private key and send signed email as someone else, someone would have to obtain the user’s smart card and the PIN. The PIN could someday be replaced with a biometric template of the user’s fingerprint, thus enhancing the non-repudiation aspects of digitally signed email.

Smart Card Base Components

The Windows 2000, Windows XP, and Windows Server 2003 operating systems integrate the smart card base components into the operating system to support public key services, such as smart card logon. The Smart Card Base Components are outlined below.

Component Overview

The basic components of the smart card subsystem are based on PC/SC standards (see specifications at https://www.pcscworkgroup.com/). These basic components include:

A Resource Manager that uses a Windows API.
A user interface (UI) that works with the Resource Manager.
Several base service providers that provide access to specific services. In contrast to the Resource Manager’s Windows API, service providers use a COM interface model to provide smart card services.

Figure 3 shows the relationships of these components in the overall smart card architecture.

The basic components for a smart card are already installed on Microsoft Windows 2000 and later platforms (including Windows XP and Windows Server 2003). For Microsoft Windows NT, Microsoft Windows 95 (OSR2.1), and Microsoft Windows 98, you can install the components by means of the smart card redistributables contained in the Platform SDK. The installation CDs for Windows 95 (OSR2.1) and Windows 98 also contain the basic components.

Figure 3: Overall Windows Smart Card Architecture and Components

Service Providers

All cards must have at least one service provider for Windows-based applications to access card-based services. There can be multiple service providers, depending on the type of card and the card issuer. In general, there are two categories of service providers: cryptographic and noncryptographic. The distinction is necessary due to import and export restrictions on cryptographic technology imposed by governments.

CSPs can be software-only, like the Microsoft Base Provider CSP that ships standard on Windows platforms today, or they can be part of a hardware-based solution in which the cryptographic engine resides on a smart card (or some other piece of hardware) attached to the computer. A CSP associated with a smart card is called a Smart Card Cryptographic Provider (SCCP) to distinguish it from a more general CSP. Both SCCPs and CSPs expose cryptographic services—such as random number generation, key generation, digital signature, key exchange, and bulk encryption—through CryptoAPI.

Smart Card Service Providers (SCSPs) expose the noncryptographic services of a smart card to an application through interfaces. A smart card interface consists of a predefined set of services, the protocols necessary to invoke the services, and any assumptions regarding the context of the services. This is similar in concept to the ISO 7816-5 Application Identifier, but differs in scope.

A smart card can register support for an interface through association with the interface’s globally unique identifier (GUID). This binding between a card and an interface is done at the time the card is first introduced to the system—typically when the SCSP is installed. Once the card is introduced to the system, applications can search for smart cards, based on a specific interface or GUID. For example, a cash card could make itself available to Windows-based applications by registering interfaces to access its purse scheme.

As part of the Smart Card Base Components 1.0 release, Microsoft shipped several base-level service providers for performing generic operations, such as card location, command and reply Application Protocol Data Unit (APDU) management, and card file system access. The Microsoft-supplied service providers are implemented as COM interface objects to enable software developers and card providers to develop higher-level service providers and applications.

Cards

The term smart card has been used to describe a class of credit card–sized devices with varying capabilities: stored-value cards, contactless cards, and integrated circuit cards (ICCs). All of these cards differ in functionality from one another and from the more familiar magnetic stripe cards that standard credit, debit, and ATM cards use. It’s the ICC that’s of most interest to the computer industry because it’s able to perform more sophisticated operations, including signing and key exchange.

To work under the Windows implementation of the PC/SC 1.0 specifications, a smart card must conform physically and electrically to the ISO 7816-1, 7816-2, and 7816-3 standards.

You must first introduce a smart card to Windows by using a vendor-supplied installation program because there’s no Plug and Play (PnP) model for smart cards. There’s no standard for encoding a unique identifier within the Answer-to-Reset (ATR) string used to uniquely identify cards of the same type. The card installation software typically installs an associated card service provider that registers its interfaces with the Resource Manager. The Resource Manager then binds the card to the registered interfaces, enabling applications to access card-based services, based on their supported interfaces. A card can also bind to previously registered interfaces of an existing service provider.

Resource Manager

The Resource Manager runs as a trusted service in a single process. All requests for smart card access go through the Resource Manager and are routed to the smart card reader containing the requested card. Therefore, the Resource Manager is responsible for managing and controlling all application access to any smart card inserted into any reader attached to a Windows-based computer. The Resource Manager provides a given application with a virtual direct connection to the requested smart card.

The Resource Manager performs three basic tasks in managing access to multiple readers and cards. First, it identifies and tracks resources. Second, it controls the allocation of readers and resources across multiple applications. Finally, it supports transaction primitives for accessing services available on a specific card. This is important because current cards are single-threaded devices that often require execution of multiple commands to complete a single function. Transaction control allows multiple commands to be executed without interruption, ensuring that intermediate state information isn’t corrupted.

Device Drivers

A device driver for a specific reader maps the functionality of that reader to the native services that the Windows platform and the smart card infrastructure provide. The reader device driver communicates card insertion and removal events to the Resource Manager and provides data communications capabilities to and from the card by either the T=0 or the T=1 protocols.

A common driver library is included with the Smart Card Base Components 1.0 release for use by developers to simplify device driver development. This shared library supports ISO 7816 and common system functions required for data communication between a smart card and a reader. This is a significant improvement over how smart card reader device drivers were developed in the past because there are now standard interfaces for developers to rely upon. These common interfaces enable a smart card reader device driver to be developed in a uniform manner and be accessible to all Windows applications, as opposed to only a select few applications that know how to communicate with a specific reader.

The type of device driver (for example, .vxd or .sys) depends on the targeted Windows platform. Using the standard Device Driver Kit (DDK) for the targeted Windows platform, an OEM or independent hardware vendor (IHV) can develop a device driver for its reader much like it does for any other peripheral. There are separate smart card DDKs for each Windows-based platform. You can obtain them from MSDN on CD-ROM, but you can’t download them from the Microsoft Web site.

The device driver model for RS-232, PS/2, and PC Card readers varies according to the targeted Windows platform and bus type. With the release of Windows 2000, the device driver model for USB and IEEE 1394 devices was unified. This device driver model is referred to as the Windows Driver Model (WDM). For more information about WDM, see https://www.microsoft.com/whdc/archive/wdm.mspx.

Readers

Smart card readers attach to standard peripheral interfaces, such as RS-232, PS/2, PCMCIA and USB. Readers are considered standard Windows devices and carry a security descriptor and PnP identifier. They’re controlled through standard Windows device drivers and are introduced to and removed from the system using the Hardware Wizard that’s standard with Windows.

Readers must conform to the PC97 or PC98 hardware design requirements and to the Microsoft implementation of the PC/SC Workgroup 1.0 specifications. There’s a Windows-compatible logo program for smart card readers available from the Windows Hardware Quality Labs (WHQL), as there is for other peripheral devices. You can download the smart card reader test kit from the WHQL Web site at https://www.microsoft.com/whdc/whql/resources/HCTsetup.mspx. The test kit includes several test smart cards (distributed separately) that are used to determine whether a reader meets the requirements to receive the Windows-compatible logo. Smart card readers must also meet Windows platform requirements, including PnP and Power Management requirements, to qualify for the Windows-compatible logo.

Table 1 shows the smart card readers that Windows XP and Windows Server 2003 support. Their drivers are installed only upon detection of the corresponding PnP smart card reader hardware.

Table 1 Smart Card Readers Supported in Windows XP and Windows Server 2003

Brand	Smart Card Reader	Interface	Device Driver
American Express	GCR435	USB	Grclass.sys
Bull	SmarTLP3	Serial	Bulltlp3.sys
Compaq	Serial reader [cap?]	Serial	grserial.sys [cap?]
Gemplus	GCR410P	Serial	Grserial.sys
Gemplus	GPR400	PCMCIA	Gpr400.sys
Gemplus	GemPC430	USB	Grclass.sys
Hewlett-Packard	ProtectTools	Serial	Scr111.sys
Litronic	220P	Serial	Lit220p.sys
Schlumberger	Reflex 20	PCMCIA	Pscr.sys
Schlumberger	Reflex 72	Serial	Scmstcs.sys
Schlumberger	Reflex Lite	Serial	Scr111.sys
SCM Microsystems	SCR111	Serial	Scr111.sys
SCM Microsystems	SCR200	Serial	Scmstcs.sys
SCM Microsystems	SCR120	PCMCIA	Pscr.sys
SCM Microsystems	SCR300	USB	Stcusb.sys
Systemneeds	External	Serial	Scr111.sys
Omnikey AG	2010	Serial	Sccmn50m.sys
Omnikey AG	2020	USB	Sccmusbm.sys
Omnikey AG	4000	PCMCIA	Cmbp0wdm.sys

Smart Card Interoperability

Incompatibility of applications, cards, and readers has been a major reason for the slow adoption of smart cards. Interoperability among different vendors’ products is a necessary requirement to enable broad consumer acceptance of smart cards and for corporations to deploy smart cards for use within the enterprise.

ISO 7816, EMV, and GSM

To promote interoperability among smart cards and readers, the ISO developed the ISO 7816 standards for ICCs with contacts. These specifications focused on interoperability at the physical, electrical, and data-link protocol levels. In 1996, Europay, MasterCard, and VISA (EMV) defined an industry-specific smart card specification that adopted the ISO 7816 standards and defined some additional data types and encoding rules for use by the financial services industry. The European telecommunications industry also embraced the ISO 7816 standards for their Global System for Mobile Communications (GSM) smart card specification to enable identification and authentication of mobile phone users.

While all of these specifications (ISO 7816, EMV, and GSM) were a step in the right direction, each was either too low-level or application-specific to gain broad industry support. None of the specifications addressed application interoperability issues, such as device-independent APIs, developer tools, and resource sharing.

The PC/SC Workgroup

The PC/SC Workgroup was formed in May 1996 in partnership with the following major computer and smart card companies: Groupe Bull, Hewlett-Packard, Microsoft, Schlumberger, and Siemens Nixdorf. The main focus of the workgroup has been to develop specifications that solve these interoperability problems. In December 1997, the workgroup released the first version of the specifications. Links to these specifications are available from https://www.pcscworkgroup.com.

The PC/SC specifications are based on the ISO 7816 standards and are compatible with both the EMV and GSM specifications. There’s broad industry support for the specifications and a strong desire to move them toward becoming independent standards in the future.

Since the founding of the PC/SC Workgroup and initial publication of its specifications, additional members have joined the PC/SC Workgroup. New members include Gemplus, IBM, Sun Microsystems, Toshiba, and VeriFone.

Microsofts Approach

The Microsoft approach is simple and consists of the following:

A standard model for interfacing smart card readers and cards with computers
Device-independent APIs for enabling smart card–aware applications
Familiar tools for software development
Integration with all Windows platforms

Having a standard model for how readers and cards interface with a computer enforces interoperability among cards and readers from different manufacturers. Device-independent APIs insulate application developers from differences between current and future implementations. Device-independence also reduces software development costs by avoiding application obsolescence due to underlying hardware changes.

Smart Card Deployment

This section details the process for deploying smart card technology in a large enterprise setting. Because the adoption of smart card technology is still limited, it’s not possible to offer a detailed “cookbook” for successful deployment. However, this section will offer recommendations and identify risks specific to smart card technology integrated with a process based on the Microsoft Solutions Framework (MSF) principles of infrastructure deployment. MSF specifies best practices and principles for managing software development and deployment distilled from internal practices at Microsoft.

The deployment process is organized into three phases:

Envisioning Stage
Planning Stage
Development Stage

Each stage includes milestones that help your organization track progress and ensure that the deployment addresses your organization’s needs. For more information about MSF infrastructure deployment, see https://www.microsoft.com/technet/itsolutions/msf/default.mspx.

Envisioning Stage

Some of the most common reasons for project failure include a lack of shared project goals and a lack of executive sponsorship. Therefore, before detailed planning starts, it is critical to ensure that a clear vision exists for how smart card technology will be implemented. It is also important to involve executive management. Achieving these steps is the goal of the envisioning phase.

Gather the Requirements

Frequently, organizations make the mistake of moving right into development without performing a thorough business requirements analysis. Anticipating the applications that the card must support in its lifetime is critical to good design. After the chips for the card are manufactured, the number and size of applications that can later be added to the card are set. Some applications might not be ready until months later, after the cards are already deployed in the organization.

For this reason, it’s important to identify and meet with the key stakeholders in the smart card deployment in the early development stage. Stakeholders include groups that intend to build smart card applications and groups that can approve (or block) the smart card deployment.

From these discussions, you can compile the requirements into a requirements document. Most organizations are initially interested in smart cards for security reasons. Other common requirements for smart cards include:

Enhancing the security of user logons to the corporate network from the desktop
Providing selective access to data, resources, and Web sites
Providing employees enhanced security when remotely accessing the corporate network
Enabling legally binding digital signatures
Providing internal payment systems (or e.g. e-purse) within the organization
Migrating toward elimination of passwords
Enhancing asset tracking; who’s doing what, with what, and for how long?
Ensuring access for employees with disabilities

After you compile a list of business requirements, consider the administrative tools that will be necessary to manage large numbers of smart cards, such as tools for:

Resetting a user’s PIN remotely.
Viewing a user’s card profile. What applications are on the card? How much memory is available?
Performing first-time diagnostics on a card as it’s being issued.
Allowing full access for security officers.
Flashing new chips.

Document the Operating Environment

Identify the platform, network/server configuration, and hardware with which the smart card solution must integrate. A functioning PKI must be in production in the enterprise before you can deploy smart card technology.

In addition, be sure to document the user’s physical environment. Will users be swiping cards at doorways, next to cashiers, or at workstations? Will they be using cards with mobile devices? What accommodations must be made for people with disabilities?

Prioritize Requirements and Create a Version Strategy

The initial deployment should focus on a few top-priority features and establish the one-time elements of the system (e.g., cards, card readers, issuance process). If designed properly, you can add additional applications and features later to the same card over the course of its life cycle. It’s recommended that you implement the overall list of features in the requirements document in phases.

Build the Team

Getting the right resources on the project takes a long time, so this must begin early. Complete a skills assessment based on the technologies that will be needed. For example, if your company uses Windows 2000 or Windows Server 2003 for its server architecture, at least one developer on your team must have knowledge of PKI. During this time, you can interview and select a card vendor that will participate on the team.

Prepare a Vision/Scope Document

This document will identify the goals, value proposition, high-level features, and risks of the smart card deployment. Circulate this document to key decision-makers, IT managers, and managers of user groups that will be most affected. The vision/scope document must reduce the ideal list to a manageable list of features that can be implemented in a single project or series of projects.

Conduct a High-Level Vision/Scope Review

Present the vision/scope document to the key decision-makers and stakeholders. The review should include a rough cost estimate (not a fixed budget), approximate project time frame (not exact dates), and a preliminary risk assessment. It should also be clear that there are two choices available to the key decision-makers—they can approve and commit resources to proceed to the next milestone or disapprove and send the document back for revision.

Planning Stage

After the vision/scope–approved milestone has been passed, detailed planning and specifications can begin.

Write Functional Specifications

The functional specifications must describe the architecture, design, and implementation details of the core system and custom applications that will use smart card technology. You should consider several key points when preparing the design and specifications.

Chip Design. Chip design should anticipate adding new applications during the 18- to 24-month life cycle of the card. Assume that interest in taking advantage of the smart cards for new applications will grow after people begin to use them. When planning file allocation tables (FATs) and storage space on the chip, allot space for applications that are still in the early phase of planning. Good communication is critical; for example, if an application requires 4KB of storage space on the chip, the space is reserved and reconciled against the storage needs of other applications.

Graphics. The chip can be screen-printed directly on a card or applied as a sticker, or “skin.” By using a skin, you can leverage existing corporate cardkeys or badges. Enterprises with existing card issuance processes and issuing stations and policies can save money by “piggybacking” these processes, stations and policies. Avoid issuing employees multiple cards and readers because to do so involves considerable cost. As more powerful card operating systems and memory become available, skins can be washed off by using special solvents, and new skins can be applied. Note that there’s a risk of damaging the chips with the solvent. For some organizations, such as the military, skins might be viewed as less secure than screen-printing because skins can also be peeled off and placed on a different card.

Cards and Readers. Some organizations have found that if the card-to-reader interface is too tight or abrasive, the cards deteriorate more rapidly. This situation can occur if the cards are too thick. Discuss this issue with your card and reader vendor or vendors. Include physical thickness of cards in your specifications, which is important when selecting vendors for manufacturing skins because the material thickness for skins varies. Also, some readers use USB ports. Some users might have all USB ports on their workstation occupied, and therefore need special accommodations to use the readers. You might need to obtain a mix of card reader connector types. In some companies, it’s appropriate to give users the option to choose the connector type. Some personal computer vendors provide alternative options that don’t occupy the USB port. Both Siemens and Compaq/HP offer corporate desktop computers with built-in card readers. Compaq/HP and Cherry Systems make a keyboard that includes a smart card contact reader at a reasonable cost.

Prepare Schedule and Budget

After the functional specifications are sufficiently detailed, developers and infrastructure IT personnel can prepare detailed task lists and time/cost estimates. The task lists and estimates can then be added to the project schedule and budget estimates. It’s sometimes helpful to create a master plan document that describes the overall strategy for completing the project.

Prepare Risk Assessment

Brainstorm the risks specific to the smart card deployment and document them in a spreadsheet. For each risk, make a determination regarding its probability and impact and decide what the response will be. Response options include avoiding the risk entirely (by doing something to eliminate its cause), mitigating the consequences of the risk, creating contingency plans should the risk occur, or accepting the consequences of the risk. For more information about MSF risk management, see the white paper “The Risk Management Model,” available at https://www.microsoft.com/technet/itsolutions/msf/default.mspx.

Plan Phase Deliverables

The deliverables of the planning phase are a set of planning documents, primarily consisting of the functional specifications, master schedule, budget estimate, risk assessment, and perhaps others. You can disseminate these deliverables to the key decision-makers for comments and input.

Conduct a Project Plan Review

Like the vision/scope review, the project plan review provides a checkpoint at which key decision-makers have an opportunity to evaluate the smart card deployment before committing further resources. However, this review includes much more specific information about how it will work, the cost, and how long it will take. As before, the review meeting should end with yes or no decisions about committing resources to the deployment. If the plan is approved, the deployment continues on to the development phase.

Development Stage

Most smart card deployments require a phase of solution development as custom features, application integration, and installation scripts are developed. Although the specifics depend entirely on the nature of your smart card solution, the following checklist contains some development best practices to ensure quality.

Proof of Concept

Build a proof of concept to test the smart card solution in a lab simulation setting.

Preproduction Test

Use a version control tool, such as Microsoft Visual SourceSafe, for all custom components being developed.
Set up a test environment that reflects the production environment as much as possible.
Devise test cases and compile them into a test plan.
Use issue-tracking software to track bugs.
Take an iterative approach to testing, and retest bugs that have been fixed before closing them.
Establish acceptance criteria for implementing a pilot with input from key stakeholders, such as IT management, security, and department leads of affected user groups.

Pilot Deployment

The purpose of the pilot deployment is to stress the card technology in addition to the processes for issuance, management, and support of the card.

Decide on the size and the composition of individuals who will participate in the pilot. The number of participants determines how many cards and readers to order from the manufacturers. There should be enough participants to stress the deployment and support processes, in addition to the technology—perhaps 100–200.

In most cases, participants should be volunteers. Consider creating an internal Web page to explain what the pilot is about. This way, you can solicit additional volunteers and provide updates.

Consider using special programs and incentives to encourage the use of the cards during the pilot, because it’s unlikely that they’ll be required to use them at this stage to perform tasks such as logging on to the network.

Prepare for Production Deployment

While the pilot program is in progress, you can prepare and refine training materials for the production deployment process:

Draft policies and procedures.
Prepare the card issuance process.
Train technical support and issuance staff.
Determine the number of cards and readers needed.

To prepare for card issuance, you can map out the issuance process. Be sure to include physical variables, such as locations of issuance stations and the equipment required at each station.

The flow chart in Figure 4 shows an example of a card issuance process.

The employee signs an agreement to accept the roles and responsibilities associated with a company-issued asset and goes to the enrollment center to obtain a new smart card. The employee provides proof of ID, (sometimes two pieces of ID are required, depending on the card options and the appropriate level of security). The enrollment officer uses the enrollment card to create the card to be issued. The card is then flashed, the user’s smart card profile is purged, the tracking logs are updated, and the ID decal is applied, if applicable. Then, a simple card password, such as “12Fish34” is flashed on the card and is good for a short period of time; for example, 12 hours. The new cardholder must change the PIN to a permanent personal PIN within that time. You can supply a private terminal located in the enrollment office for this task.

Figure 4: Theoretical Smart Card Issuance Process

Conduct a Ready-for-Release Milestone Review

During the prerelease milestone review, pilot and test results are presented and assessed. The goal of the review is to evaluate the fitness of the solution before proceeding to full production deployment.

The following key deliverables should be ready at this milestone:

Results of the completed pilot
Training materials
Communications plan (to users, technical support staff, trainers)
Installation procedures and scripts
Checklists and templates
Operational procedures
Deployment documentation
Support and troubleshooting documentation
Updated schedules

Deploy Core Technology

You should first deploy the technology that’s centrally operated and managed. Again, the PKI servers are assumed to be operational. Production manufacturing of cards or skins takes place at this time. Arrange for secure delivery and storage throughout the distribution process for receiving from the vendor and sending cards or skins to the various issuance stations.

Deploy Readers and Begin the Issuance Process

During this phase, users receive their cards and readers, and then install the necessary drivers and components from the internal site. You can anticipate and plan for a heavy load of troubleshooting and escalation calls to your technical support staff.

The issuance process should be organized into phases by organizational or geographic units. Users of a given unit are notified that they can obtain their cards and receive instructions within a designated period of time. The implementation schedule should accommodate travel and setup time for security officers and issuance teams who are traveling from site to site.

Complete the Stabilization Process

The development team must work closely with IT personnel to track and resolve issues that are escalated from technical support staff. The development team and the operations staff must agree on the point at which the smart card deployment is considered stable enough to be completely transitioned to operations.

Smart Card Software Development

The Smart Card SDK has been integrated into the Microsoft Platform SDK as part of the Windows Base Services. The Platform SDK now contains the necessary tools and APIs to develop smart card–enabled and smart card–aware Windows-based applications. You can obtain the Platform SDK from the Microsoft Developer Network (MSDN) at https://msdn2.microsoft.com/en-us/library/ms804625.aspx.

From the application developer’s perspective, there are three mechanisms for accessing the services that a smart card supports: CryptoAPI, the Microsoft Win32 API, and SCARD COM. The mechanism chosen depends on the type of application and the capabilities of a specific smart card.

CryptoAPI

CryptoAPI is the cryptographic API for writing a CSP and requires a separate development kit, available from Microsoft. The CSP development kit is import and export controlled and requires the developer to answer a series of questions to ascertain whether the development kit can be legally obtained from Microsoft.

The benefits of using CryptoAPI are significant because the developer can take advantage of the cryptographic features integrated into the Windows platform without having to know cryptography or how a particular cryptographic algorithm works. For example, a properly programmed smart card CSP would use an existing CSP (such as Microsoft Base Provider) to perform all public- and symmetric-key operations and use the smart card itself to perform all private-key operations.

SCARD COM

SCARD COM is a noncryptographic interface implementation that Microsoft provides for accessing generic smart card–based services from applications written in different languages, such as C, Microsoft Visual C++, Java, and Microsoft Visual Basic. It’s composed of a set of base COM interface objects that developers can use to build a richer set of interfaces for use by Windows-based applications. The software developer can use standard development tools, such as Visual C++ and Visual Basic, to develop applications and service providers that are smart card–enabled and smart card–aware.

In general, the application developer doesn’t need to know the details of how a particular smart card functions in order to access its services through COM. This abstraction speeds up Windows application development, saving both time and development costs, and protects the application from obsolescence caused by subsequent changes to a card’s design.

Win32 API

The Win32 APIs are the base-level APIs for accessing smart cards and require a deeper understanding of the Windows operating system and smart cards in order to be used effectively. They also provide the most flexibility for the application to control readers, cards, and related components. For developers who need maximum control over an application’s use of smart cards, this extension to the base Win32 API provides the necessary interfaces for managing interactions with smart card devices.

Conclusion

Microsoft views smart cards as a key component of its PKI support. Smart cards enhance software-only solutions, such as client authentication, interactive logon, and secure email. Smart cards are a point of convergence for public key certificates and associated keys.

For More Information

For more information about smart cards and PKI in general, see the following Microsoft TechNet articles:

Planning Your Public Key Infrastructure: https://www.microsoft.com/technet/prodtechnol/windows2000serv/reskit/deploy/dgch_pki_odbg.mspx
Microsoft Windows 2000 Public Key Infrastructure Introduction: https://www.microsoft.com/technet/prodtechnol/windows2000serv/evaluate/featfunc/2000pk.mspx
Smart Card Deployment Cookbook: https://www.microsoft.com/technet/security/guidance/identitymanagement/smrtcdcb/default.mspx