Smart Card Enhancements

Updated: February 18, 2010

Applies To: Windows 7, Windows Server 2008 R2

Smart cards are supported in versions of Windows beginning with Windows 2000. However, significant enhancements to smart card support were introduced in Windows Vista, and additional important enhancements were added in Windows 7.

The following smart card limitations exist in versions of Windows earlier than Windows Vista:

• A smart card can support only one certificate for logon.

• Users must log on with a user name and password before they can change the PIN or unblock a smart card.

Windows Vista enhancements

Winlogon was redesigned in Windows Vista.

Credential providers

In versions of Windows prior to Windows Vista, a custom Microsoft Graphical Identification and Authentication (GINA) dynamic link library (DLL) was used to support customizable user identification and authentication. Beginning in Windows Vista, the functionality formerly in GINA DLLs is distributed among three components:

• Winlogon

• Logon user interface (UI)

• Credential providers

MSGINA.DLL is removed, and custom GINAs are not loaded. The password credential provider and the smart card credential provider are provided by default, and a custom credential provider can be created to support custom authentication mechanisms. After Winlogon launches the logon UI, it loads registered credential providers. The smart card credential provider uses interfaces that are exposed through the credential provider framework to gather the required credentials, package them, and return them to the logon UI. The logon UI then passes the credentials to Winlogon for Kerberos authentication.

Multiple logon certificates

Winlogon supports multiple logon certificates and containers on the same smart card. The number of certificates that can be stored and containers that can be created depends on how much space is available on the smart card.

Smart card resource manager

The WinSCard API is extended to provide caching (storage of non-sensitive data on a per-user-basis) at the smart card resource manager level. The smart card resource manager was formerly called the smart card service.

Smart card Base cryptographic service provider

Each smart card must have a cryptographic service provider (CSP). A CSP uses the CryptoAPI interfaces to enable cryptographic operations and the WinSCard APIs to enable communication with smart card hardware. For more information, see Smart Card Subsystem Architecture in the Smart Card Architecture section.

A new CSP in Windows called the Base CSP allows smart card vendors to write smart card–specific modules called smart card minidrivers instead of writing CSPs. Writing a smart card minidriver for a smart card is analogous to writing a printer driver for a printer. A smart card minidriver acts as the hardware interface between the smart card and the Base CSP. Beginning with Windows Vista, the Base CSP is included in the Windows operating system. A Base CSP package can also be downloaded for Windows XP with Service Pack 2 (SP2), Windows 2000 with Service Pack 4 (SP4), and Windows Server 2003 with Service Pack 1 (SP1). For more information and links to the downloadable Base CSP package, see Description of the software update for Base Smart Card Cryptographic Service Provider (https://go.microsoft.com/fwlink/?LinkId=161161).

Smart Card key storage provider

To support additional cryptographic algorithms and to provide an extensible architecture, Cryptography API: Next Generation (CNG) was introduced in Windows Vista. Architecturally, CNG is parallel to CryptoAPI. A key storage provider (KSP) in CNG is analogous to a CSP in CryptoAPI. Windows Vista, Windows Server 2008, Windows 7, and Windows Server 2008 R2 provide a smart card KSP, which uses the same smart card minidriver interface that is available for the Base CSP. Smart card minidriver support for RSA and elliptic curve cryptography (ECC) is available through the smart card KSP.

Windows Vista with SP1 enhancements

Windows Vista with SP1 added support for the Windows Smart Card Minidriver Specification Version 6, which supports multiple PINs, read-only smart cards, a secure PIN channel, and external PIN collection.

Read-only smart cards

Windows Vista with SP1 introduced support for smart cards that are customized outside the Base CSP/Smart Card KSP environment and are inherently read-only. Examples of such smart cards include the electronic ID cards used in some European countries. If a smart card is read-only, it must advertise this through the CardGetProperty function. Read-only smart cards must support only a subset of the Version 6 card minidriver interface and are not required to support an administrator PIN. For the complete list of functions that must be supported by a read-only smart card, see the Smart Card Minidriver Specification (https://go.microsoft.com/fwlink/?LinkId=93343).

Secure PIN channel

Secure PIN channel is a feature in Windows Vista with SP1 that enables a secure PIN prompt followed by establishment of a secure channel between Windows and the smart card for PIN authentication. Secure PIN channel protects the smart card PIN against eavesdropping while the PIN is transmitted through components of the operating system and to a smart card.

With a secure PIN prompt, the user must press CTRL+ALT+DEL and is then prompted for the PIN within a user experience that is identical to Windows logon. Using a secure PIN prompt reduces the risk of stolen PINs.

Secure PIN channel can be enabled by using the Common Criteria Group Policy setting, or by using the PIN_INFO_REQUIRE_SECURE_ENTRY attribute on the PIN object.

External PIN

An external PIN is one that was not collected via the computer's keyboard; for example, by using a PIN Entry Device (PED). An external PIN mechanism could also be used to link a smart card with a fingerprint reader so that a fingerprint can be used to access a smart card instead of a PIN.

In external PIN mode, whenever PIN authentication to a smart card is required, Windows does not prompt the user for a PIN but rather calls the minidriver's authentication API immediately without any user notification. It is expected that the actual authentication and PIN collection occur without operating system involvement.

Optionally, and subject to specific restrictions, the minidriver can display its own UI to instruct the user to perform specific actions related to PIN collection. It is not expected that such a UI will be used to actually collect a PIN from the user; instead, the UI informs the user that Windows is waiting for a PIN to be collected externally. A minidriver is not allowed to display UI when the context is silent mode. Minidrivers that display UI must use a specific window handle provided to the minidriver by Windows to create UI elements.

Session PINs

To avoid having the smart card PIN exposed and cached in plaintext in user processes, Windows Vista with SP1 introduced the session PIN. Smart cards that support Windows Smart Card Minidriver Specification version 6 or higher can declare the ability to work with session PINs through the CP_CARD_PIN_STRENGTH_VERIFY property. Windows Vista with SP1, Windows Server 2008, Windows 7, and Windows Server 2008 R2 can securely gather and present the unencrypted PIN to smart cards that support session PINs and get a security token from the smart card for accessing PIN-protected features. Session PINs are used by the external PIN feature and can be used by the secure PIN channel.

Session PINs are temporary and can be transferred between processes. For smart card minidriver developers, we recommend that a session PIN remain valid (for example, by using the CARD_AUTHENTICATE_ SESSION_PIN flag) until the session is complete, even if CardAuthenticateEx is called with the GENERATE_SESSION_PIN flag set.

Smart cards that can return a temporary session PIN may return a temporary session PIN to Windows for subsequent caching. In such a case, Windows presents the session PIN for smart card authentication until the smart card invalidates the session PIN. More information can be found in the Windows Smart Card Minidriver Specification for the sections describing the CardAuthenticateEx and CardSetProperty functions.

Multiple PINs

Windows Vista with SP1 provided a more flexible architecture for PIN support and introduced a new concept of roles, for multiple PIN support, in which each role corresponds to a PIN identifier. The identifier consists of a number 0 through 7, allowing for up to eight roles and PINs. The PIN identifiers are used to extract PIN information from the smart card, as well as to associate a PIN with a key container.

Windows Vista with SP1 also introduced the PIN_SET, which is a bitmask that can be generated from the PIN identifier. The lower 8 bits are used for the PIN set, each bit corresponding to a role. For example, assume that the user authenticates with role 3, corresponding to PIN #3. This translates to a bit mask of 0000 0100 (the third bit of the mask is 1). Thus, version 6 minidriver smart cards allow for multiple authenticated identities on the smart card simultaneously. As an example, if a smart card that supports roles 1 and 2 as well as multiple authenticated identities has PIN #1 authenticated and then subsequently PIN #2 authenticated, operations that either of these PINs control are allowed on computers running Windows Vista with SP1, Windows Server 2008, Windows 7, and Windows Server 2008 R2.

Windows 7 enhancements

Smart card Plug and Play

When a Windows Logo Certified smart card is inserted into a smart card reader on a computer running Windows 7, a Plug and Play (PnP) event is triggered that enables the automatic download and installation of the associated smart card minidriver.

How it works

A smart card filter driver (scfilter) precedes the smart card reader driver and detects smart card insertion events. When a smart card insertion event is detected, the Certificate Propagation service creates a device node for the smart card that is visible from Device Manager. Windows then performs heuristics to generate a PnP ID for the smart card. For information about how Windows generates a PnP ID for a smart card, see the Smart Card Minidriver Specification (https://go.microsoft.com/fwlink/?LinkID=93343). The PnP ID for the smart card is transferred to the Plug and Play service that attempts to locate a minidriver from Windows Update or through Windows Server Update Services (WSUS). When a driver is located, it is downloaded and installed automatically without user intervention.

Smart card solutions that are not compatible with Plug and Play

Smart card Plug and Play only supports smart cards that require drivers to function. Not all smart card solutions require drivers for integrating with Windows. These solutions do not use the Windows Smart Card Framework and must be installed on the computer before using the smart card for the first time.

The following solutions are not compatible with smart card Plug and Play:

• Custom CSP-based solutions.

• Custom KSP-based solutions.

• Public Key Cryptography Standard #11 (PKCS #11)-based solutions.

• Smart card driver packages without complete INF files or with incorrect device identifications.

• Multislot smart card readers that create only one device node for all available slots in the smart card reader.

Each time a smart card is inserted in the computer, Windows attempts to download and install the smart card driver if it is not already available on the computer. You may see a Plug and Play error when you insert a non-Plug and Play smart card on the computer. This does not necessarily mean that there is a problem with the smart card.

If your deployment uses only non-Plug and Play smart card solutions, smart card Plug and Play can be disabled by a local administrator on a client computer. Disabling smart card Plug and Play prevents the download of smart card minidrivers and prevents smart card Plug and Play prompts.

For enterprise deployments, smart card Plug and Play can be disabled by deploying a Group Policy setting. For information about administrative templates, see Administrative templates overview for GPMC (https://go.microsoft.com/fwlink/?LinkId=152390).

Enhanced support for the Personal Identity Verification standard

Windows 7 features enhanced support for the Personal Identity Verification (PIV) standard from the National Institute of Standards and Technology (NIST). When a PIV-compliant smart card is inserted into a smart card reader, Windows attempts to download the driver from Windows Update. If an appropriate driver is not available from Windows Update, a PIV-compliant minidriver that is included with Windows Server 2008 R2 and Windows 7 is used for the smart card.

For more information about PIV, see About Personal Identity Verification (PIV) of Federal Employees and Contractors (https://go.microsoft.com/fwlink/?LinkId=164579).

External PIN support for logon

In Windows 7, the smart card credential provider can suppress the default PIN collection controls. If the PIN properties indicate that it is an external PIN, CardAuthenticateEx is called to request that the minidriver invoke its own PIN-handling user interface.

Smart card logon with ECC certificates

Windows 7 supports smart card logon with elliptic curve cryptography (ECC) certificates. For information about the algorithms, curves, and special considerations for Elliptic Curve Digital Signature Algorithm (ECDSA) logon certificates, see How Smart Card Logon Works in Windows.

Secure Key Injection API

Version 7 of the smart card minidriver interface introduces an API for Secure Key Injection. Secure Key Injection enables an encrypted transfer of sensitive material from a server application to a smart card through an untrusted client.

For Secure Key Injection to work, the following steps need to occur:

1. Securely establish encryption keys for the channel; for example:

   • Use shared symmetric keys between the server and the smart card on the client.

   • Generate a temporary symmetric session key on the server and import it onto the smart card encrypted by a public key that originates on the smart card.

   • Derive a session key from a shared symmetric key.

   • Use a key agreement protocol such as Diffie-Hellman (DH).

2. Encrypt the data on the server that is to be sent to the smart card. Such data could be:

   • Authentication data, such as a PIN or administrator key.

   • An asymmetric key pair such as RSA/ECC.

3. Decrypt data on the smart card attached to the client.

Version 7 of the minidriver specification has more information about the APIs available to application developers along with a few use case scenarios. For more information, see the Smart Card Minidriver Specification (https://go.microsoft.com/fwlink/?LinkID=93343).