Windows NT® Server
Server Operating System
White Paper
Smart cards are a key component of the public-key infrastructure Microsoft is integrating into the Microsoft® Windows® 95, Windows 98, Windows NT® 4.0, Windows NT 5.0 platforms. By providing a standard model for interfacing smart card readers and cards with PCs, original equipment manufacturers (OEMs) and independent hardware vendors (IHVs) can offer their products to millions of PC users — spanning both commercial and consumer markets. Independent software vendors (ISVs) can also benefit from the broader PC market opportunity by developing applications and services using device-independent application programming interfaces (APIs), high-level languages, and familiar software development tools that protect the application from obsolescence that has plagued the smart card industry.
© 1997 Microsoft Corporation. All rights reserved.
The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication.
This White Paper is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS DOCUMENT.
Microsoft, the BackOffice logo, Visual Basic, Vicual C++, Win32, Windows, and Windows NT are registered trademarks and Visual J++ is a trademark of Microsoft Corporation.
Java is a trademark of Sun Microsystems, Inc.
Other product or company names mentioned herein may be the trademarks of their respective owners.
Microsoft Corporation · One Microsoft Way · Redmond, WA 98052-6399 · USA
0897
The need for security and enhanced privacy is growing 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 from outside the firewall, have accelerated the demand for solutions based on public-key technology. A few examples of the kinds of services that public key technologies enable are: secure channel communications over a public network, digital signatures to ensure image integrity, and authentication of a Web browser to a Web server. In the next release of the Microsoft® Windows NT® operating system, public-key technology will be integrated with the core security infrastructure and the new Active Directory. This integration will enable a broad range of choices for IT organizations that administer an expanding Enterprise.
Smart cards are a key component of the public-key infrastructure that Microsoft is integrating into the Windows® operating system platform because smart cards enhance software-only solutions such as client authentication, single sign-on, secure storage, and system administration. Smart cards provide tamper-resistant storage for protecting private keys, account numbers, passwords, and other forms of personal information. Smart cards also serve to isolate security-critical computations involving authentication, digital signatures, and key exchange from other parts of the system that do not have a “need to know.” In addition, smart cards provide a level of portability for securely moving private information between systems at work, home, or on the road.
The smart card industry has been plagued by incompatibility among applications, cards and readers, and a poor developer tool chain based on proprietary APIs and protocols. The lack of a standard model for interfacing smart card readers to PCs, device-independent APIs for application development, and resource sharing across multiple applications has limited smart card solution deployment. The lack of a standard model creates high development and maintenance costs and overall system administration complexity.
In order to promote interoperability among smart cards and readers, the International Standards Organization (ISO) developed the ISO 7816 standards for integrated circuit cards 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 inter-industry support. Application interoperability issues such as device-independent APIs, developer tools, and resource sharing were not addressed by any of these specifications.
The PC/SC (Personal Computer/Smart Card) Workgroup was formed in May 1996 in partnership with major PC 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 the previously mentioned interoperability problems. In December 1996, the workgroup published its specifications on http://www.smartcardsys.com for public review and comment.
The PC/SC specifications are based on the ISO 7816 standards and are compatible with both the EMV and GSM industry-specific specifications. By virtue of the companies involved in the PC/SC Workgroup, there is broad industry support for the specifications and a strong desire to move them onto an independent standards tract in the near future.
Since its founding and initial publication of the specifications, additional members have joined the PC/SC Workgroup. New members include Gemplus, IBM, Sun Microsystems, Toshiba, and Verifone.
Microsoft’s approach is simple and consists of the following:
Having a standard model for how readers and cards interface with the PC enforces interoperability among cards and readers from different manufacturers. Device-independent APIs serve to insulate application developers from differences between card and reader implementations and future designs. This preserves software development costs by application becoming obsolescence due to hardware changes. Developers will be able to use the standard Win32® platform software development kit (SDK) and device driver kit (DDK) to develop PC-compatible smart card products. In addition, smart card-aware applications and service providers can be developed using high-level language tools such Visual C++®, Visual J++™ and Visual Basic® development systems.
Smart card support has been incorporated into the NetPC, Windows NT 5.0, and PC98 design specifications. Microsoft has released its implementation of the PC/SC specifications on Windows NT 4.0 and Windows 95 that is publicly available for download from http://www.microsoft.com/smartcard. Inquiries about Microsoft’s support for smart cards should be directed to mailto:smartcrd@microsoft.com.
The architecture described below is based on the PC/SC Workgroup specifications as implemented on the Windows platform.
From the application developer’s perspective, there are three mechanisms for accessing the services supported by a smart card: Win32, Crypto API, and SCard COM. Most developers will choose to develop applications using SCard COM or Crypto API, depending on their target market and the capabilities of a given smart card.
Crypto API is the cryptographic API for writing Cryptographic Service Providers (CSPs), and requires a separate development kit available from Microsoft that is import/export controlled. The developer benefits from using the Crypto API because there is no need to know how a particular cryptographic algorithm works in order to support cryptographic features in an application. Please refer to http://sectest.microsoft.com/capi/cspref1.html for more information about CSP development.
SCard COM is a low-level non-cryptographic interface implementation provided by Microsoft for accessing basic smart card services. It is a set of base COM interface objects that can be used to build higher-level interfaces and/or applications. The software developer can use high-level languages such as C, C++, Java™ and Visual Basic to develop applications and service providers that are smart card aware, yet the developer doesn't have to know the details of how a particular smart card or reader functions. This speeds up application development, saving both time and development costs.
Win32 is the lowest level API for accessing smart cards and requires a deep understanding of the Windows operating system and smart cards to be used effectively. For developers that need maximum control over an application’s use of smart cards, this extension to the core Win32 API provides the necessary interfaces for managing smart card interactions.
Figure 1. Service Providers
As shown in the above diagram, 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 non-cryptographic. The distinction is necessary due to import/export restrictions on cryptographic technology imposed by governments.
Cryptographic Service Providers (CSPs) can be software-only, like the rsabase.dll CSP that ships standard on Windows platforms today, or they can be part of a hardware-based solution where the cryptographic engine resides on a smart card or some other piece of hardware attached to the PC. A CSP associated with a smart card is called a Smart Card Cryptographic Provider (SCCP) to distinguish it from the broader CSP solution. Both SCCPs and CSPs expose cryptographic services through CryptoAPI such as key generation and management, random number generation, digital signing, key exchange, and bulk encryption.
Smart Card Service Providers (SCSPs) expose the non-cryptographic services of a smart card to an application through interfaces. Interfaces supported by a smart card are not assumed to be available from the card. 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. The term "interface" is used in a manner very similar to the way it is used in COM. Note that this is similar in concept to the ISO 7816-5 Application Identifier, but differs in scope.
A smart card can claim to support 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. Service Providers register their interfaces at the time the card is introduced to the system thus enabling applications to search for smart cards based on a specific interface or GUID.
As part of the base smart card components, Microsoft will ship several lower-level Service Providers for performing generic operations such as card location and command/reply APDU (Application Protocol Data Unit) maintenance. 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 using Java, Visual Basic and C++.
The Resource Manager runs as a trusted service in a single process. In subsequent versions, it may migrate into the Windows kernel. All requests for smart card access go through the Resource Manager and are routed to the smart card reader containing the targeted card. Therefore, the Resource Manager is responsible for managing and controlling application access to any smart card inserted into any reader attached to a PC. The Resource Manager provides a given application with a virtual direct connection to the targeted smart card.
The Resource Manager solves three basic problems in managing access to multiple readers and cards. First, it is responsible for identification and tracking of resources. Second, it is responsible for controlling the allocation of readers and resources across multiple applications. Finally, it supports transaction primitives for accessing services available on a given card. This is an important point because current cards are single-threaded devices, which 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 is not corrupted.
A device driver for a specific reader maps the functionality of that reader to the native services provided by Windows and the smart card stack. It is the responsibility of the reader device driver to communicate card insertion and removal events to the Resource Manager, and to provide data exchange capabilities to the card by any or all of the Raw, T=0, or T=1 protocols. A common driver library is included with the base smart card components for use by low-cost hardware devices that do not support all functionality in the hardware itself.
Because the smart card infrastructure runs under Windows NT 4.0, Windows NT 5.0, Windows 95 and Windows 98 several device driver models are supported based on the target platform. Using the standard DDK for the targeted Windows platform, an OEM or IHV can develop a device driver for its reader much like it does for any other PC peripheral. This is a significant benefit over how drivers were developed for readers previously.
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 98 and Windows NT 5.0, the device driver model for USB and IEEE 1394 devices will be unified. This device driver model is referred to as the Win32 Driver Model (WDM). For more information on WDM, please refer to http://www.microsoft.com/hwdev/pcfuture/wdm.htm.
Smart card readers attach to standard PC peripheral interfaces such as RS-232, PS/2, PCMCIA, and (in the future) USB. Readers are considered standard Windows devices, and as such carry a security descriptor. They are controlled through standard device drivers and are introduced to and removed from the system, using plug-and-play and the Device Manager that is standard with Windows 95, Windows 98 and the next release of the Windows NT operating system.
The additional concept of reader groups is supported by the Windows smart card infrastructure, allowing readers to be organized into groups whether they are a system resource or associated with a specific PC. This notion of groups will become important in the future for organizations wanting to support multiple readers and administer them from a central resource.
Readers must conform to the PC/SC Workgroup specifications and to the Windows-based hardware design guidelines. Specifically, smart card readers must support event notification of card insertion and removal events. This is best achieved using a hardware interrupt though could be implemented in the driver through polling. In general, devices that do not support interrupt notification for card insertion and removal will not be considered Windows-compatible devices. For more information on Windows-compatibility for hardware visit http://www.microsoft.com/hwtest/.
The term smart card has been used to generically describe a class of credit-card-sized devices with varying capabilities: stored-value cards, contactless cards, and integrated circuit cards (ICC). All of these cards differ in functionality from each other and from the more familiar magnetic stripe cards used by standard credit, debit and ATM cards. It is the ICC that is of most interest to the PC because it is able to perform more sophisticated operations including authentication, signing, and key exchange.
To work under the Windows implementation, a smart card must conform physically and electrically to the ISO 7816-1, 7816-2, and 7816-3 standards that are referenced within the PC/SC Workgroup specifications.
A smart card must first be introduced to Windows using a setup utility, because there's no plug-and-play model for smart cards. There's no plug-and-play model for smart cards because there's no standard specification for encoding the Answer-To-Reset (ATR) strings used to identify a given card to a system or application. The setup utility would typically install an associated Service Provider that registers its interfaces with the Resource Manager. The Resource Manager would then bind the card services to the registered interfaces enabling applications to access the card based on its supported interfaces. It is also possible for a card to bind to previously registered interfaces of an existing Service Provider.
To write smart card aware applications, software developers need development tools and standard APIs that allow them to write their applications for a variety of markets. Because the Windows smart card infrastructure is based on Win32 and COM, developers are already familiar with the programming model and tools.
The SDK and DDK for smart cards will be integrated with the standard platform SDK and DDK for Win32 and Windows platforms. In addition, high-level language tools such Visual C++, Visual J++ and Visual Basic can be used to develop applications and Service Providers in the same manner they are used to develop standard applications for Windows.
The benefits for developers are:
Smart cards offer application developers a secure mechanism for enhancing solutions aimed at the growing Internet and intranet markets. These markets encompass a variety of applications including games, financial services, remote access, and network administration—to name just a few. By enhancing software-only solutions, smart cards enable a new breed of applications positioned to take advantage of future opportunities in the emerging digital economy.
Client authentication involves identification and validation of a client to a server over a secure protocol such as Secure Sockets Layer (SSL) 3.0. Authentication can be achieved using either passwords or public-key certificates mapped to user accounts or groups that have previously established access control privileges. In the case of public-key certificates, a smart card can be used to enhance the authentication process as a secure store for the private key and/or as a cryptographic engine in association with an SCCP. The following diagram shows how the smart card architecture integrates with the Microsoft Internet Explorer 3.0 and Internet Information Server 3.0 client authentication solution.
Figure 2. Client Authentication
Single sign-on means the ability to log a user onto multiple servers (that is, services) based on the user entering a single set of inputs such as a user name, domain, and password. These inputs can be presented directly to the logon server using Windows NT LAN Manager or Kerberos protocols or they can be accessed from a secure store containing a public-key certificate that is presented to the server and is completely hidden from the user. In the case of Windows NT LAN Manager or Kerberos based single sign-on, access to services is determined by the privileges previously granted to an account. For public-key based single sign-on, domain access is determined by a user’s previously registered public-key certificate that maps to an established user account or group and his/her private-key used to respond to a challenge from the logon server.
By developing a Graphical Identification aNd Authentication (GINA) DLL that is smart card aware, a smart card containing public-key certificates takes on the functionality of a credential cache that can be used to log a user on to multiple domains. Because a smart card is inherently secure, the credential cache is also secure and is present only when the user is present. Given the limited storage capacity of a smart card, it is more likely that the smart card would contain one certificate that maps to a user account administered through a directory service. The user object describing the account would then contain the additional credentials associated with the account thereby obviating the need for the smart card to store all credentials associated with a given user.
One of the most vulnerable aspects of public-key based certification is protection of the private key material. Software-only key management solutions such as a CSP based on Crypto API are enhanced through the use of smart cards to store the private key. Because they are physically portable, smart cards also provide a secure mechanism for moving keys between systems. A smart card that supports cryptographic operations can be used to hide the private key from other parts of the system. This serves to minimize the risk of attack from malicious programs.
Because smart card support will be standard on the next generation of Windows platforms, a new breed of enhanced applications and services can be envisioned to work in tandem with Zero Administration Initiative for Windows, Internet Explorer, Crypto API, and the Microsoft Wallet. For example, with Zero Administration Initiative for Windows features such as system lockdown and user roaming can be enhanced through the use of smart cards by helping to enforce policies and simplifying system administration tasks. Because public-key security can be mapped onto the Windows NT security model, smart cards can be used to help lower the costs of administering PC networks by integrating with future ZAW system administration tools. Users would use smart cards to gain access to the corporate network and their machines. Credentials contained on the cards would map to user profiles with requisite permissions covering application installation, machine configuration, and so on.
Microsoft Crypto API FAQ:
http://www.microsoft.com/security/.
Microsoft Zero Administration Initiative for Windows: http://www.microsoft.com/windows/platform/info/zawmb.htm
NetPC:
http://www.microsoft.com/windows/netpc/default.htm
PC98 Design Guide:
http://www.microsoft.com/hwdev/
Bull Personal Transaction Systems:
http://www.bull.com
Gemplus:
http://www.gemplus.com
Hewlett-Packard:
http://www.hp.com
IBM:
http://www.chipcard.ibm.com
Microsoft:
http://www.microsoft.com
Schlumberger:
http://www.slb.com
Siemens Nixdorf:
http://www.sni.de
Sun Microsystems:
http://www.sun.com
Toshiba:
http://www.toshiba.com
Verifone:
http://www.verifone.com
For the latest information on Windows NT Server, check out our World Wide Web site at http://www.microsoft.com/ntserver the Windows NT Server Forum on the Microsoft Network (GO WORD: MSNTS).