Smart Card Enhancements
Applies To: Windows Vista, Windows Server 2008, Windows 7, Windows 8.1, Windows Server 2008 R2, Windows Server 2012 R2, Windows RT, Windows Server 2012, Windows 8
This topic for the IT professional explains changes in functionality for smart card authentication with the Windows operating system.
Smart cards with personal identification numbers (PINs) are a popular, reliable, and cost-effective form of two-factor authentication. With the right controls in place, a user must have the smart card and know the PIN to gain access to network resources. The two-factor requirement significantly reduces the likelihood of unauthorized access to an organization’s network. Smart cards provide particularly effective security control for:
Authentication for scenarios such as remote access
Data integrity for scenarios such as document signing
Data confidentiality for scenarios that require encryption
Their use in additional scenarios, such as secure access to high-value applications, is likely to grow as organizations deploy a new generation of secure applications.
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 subsequent versions.
This topic applies to versions of the Windows operating systems designated in the Applies to list at the beginning of this topic.
This topic discusses the smart card enhancements in the following operating systems:
Enhancements in Windows 8.1
Application programming interfaces (APIs) allow you to use features in Windows Store apps to create virtual smart cards and to manage physical and virtual smart cards.
For more information, see Windows.Devices.SmartCards namespace (Windows) in the MSDN Library.
Enhancements in Windows 8
This section contains information about the smart card enhancements in Windows 8, including:
Virtual smart cards
Virtual smart cards emulate the functionality of traditional smart cards, but they use the Trusted Platform Module (TPM) chip that is available on many organizations’ computers rather than requiring the use of a separate physical smart card and reader. When compared with conventional smart cards, virtual smart cards have the following technical and functional differences:
To the end user, the virtual smart card is a smart card that is always available on the computer.
If a user needs to use more than one computer, a virtual smart card must be issued to the user for each computer.
A computer that is shared among multiple users can host multiple virtual smart cards—one for each user.
Conventional smart cards and TPM-based virtual smart cards offer comparable levels of security. Virtual smart cards can be deployed with no additional material costs if employees have computers with built-in TPMs. For more information, see Understanding and Evaluating Virtual Smart Cards.
Smart card sign-in experience
When an end user signs in on a computer running Windows Server 2012 or Windows 8, the software can detect whether a smart card reader was installed and whether a smart card or a password was used to sign in or unlock the computer at the last use. If a smart card was not installed previously, and the user selects the smart card sign-in icon, a message appears that tells the user to connect a smart card. After a card is connected, the smart card PIN dialog box appears. If the user does not want to use the sign-in option that automatically appears (for example, if the smart card is not readily available), a second message allows the user to select from other sign-in options.
Smart Card Service start and stop behavior
Smart card reader detection logic was added so that the Smart Card Service runs only when appropriate. In Windows Server 2012 and Windows 8, the Smart Card Service (scardsvr) automatically starts when the user connects a smart card reader, and it automatically stops when a user removes a smart card reader and no other smart card reader is connected to the computer.
On startup, the Smart Card Service automatically starts if a reader was previously connected to the computer but a reader is not currently connected to the system. If no smart card readers are connected to the computer, the service will automatically shut down one minute after the last API call into the Smart Card Service. If a reader was never previously connected to the computer, the service will not start automatically.
Smart card transactions
In Windows Server 2012, Windows 8, and Windows RT, if a transaction is held on the card for more than five seconds with no operations happening on the card, the card is reset. This is a change from the behavior in previous releases.
For more information, see SCardBeginTransaction function.
Smart card support in Windows RT
Smart card support in Windows RT includes the following:
Smart card readers
Only smart card readers that connect over USB and support the USB Chip/Smart Card Interface Devices (CCID) specification are allowed by Windows RT. Such smart card readers must use the USB CCID specification smart card reader class driver that comes with Windows RT.
Smart cards
Only smart cards that support the Generic Identity Device Specification (GIDS) or the Personal Identity Verification (PIV) standard are supported by Windows RT. The class drivers for cards that are based on these specifications are included in the Windows Run Time.
Smart card support in Windows 8 applications
Windows 8 supports a number of new types of desktop applications. Developers who create applications that need the security benefits of smart cards must address the following requirements; otherwise, these applications cannot automatically use smart cards to support their functionality:
To use a smart card, applications that are running in AppContainer must have the sharedUserCertificates capability in their application manifest. Without this capability, the application will not be permitted to use a smart card for authentication, signing, or encryption. For information about this capability and how to include it in the manifest, see Setting certificate store capabilities.
For Windows RT applications, smart card support is limited to the Secure Sockets Layer (SSL) protocol for client authentication. For a sample application that demonstrates the use of smart cards for SSL client authentication, see Windows Store app for banking: code walkthrough.
Enhancements in Windows 7
This section contains information about the smart card enhancements in Windows 7, including:
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, which enables the associated smart card minidriver to automatically download and install.
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. The Windows operating system 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 Smart Card Minidriver Specification.
The PnP ID for the smart card is transferred to the Plug and Play service, which 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.
Note
Smart card Plug and Play does not require administrative privileges.
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 to integrate with Windows. These solutions do not use the Windows Smart Card Framework, and they must be installed on the computer before the smart card is used the first time.
The following solutions are not compatible with smart card Plug and Play:
Custom cryptographic service provider (CSP)-based solutions
Custom key storage provider (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 into 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.
Important
For commercial deployments that target end users (such as online banking) and environments that include both Plug and Play and non-Plug and Play smart cards, using Group Policy to disable Plug and Play for smart cards is strongly discouraged because it affects all the smart cards in your environment.
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. 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, see About Personal Identity Verification (PIV) of Federal Employees and Contractors.
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, Windows calls CardAuthenticateEx 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 Sign-in 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:
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).
Encrypt the data on the server that is to be sent to the smart card. Such data can be one of the following:
Authentication data, such as a PIN or administrator key.
An asymmetric key pair, such as RSA/ECC.
Decrypt data on the smart card that is attached to the client.
Version 7 of the minidriver specification has more information about the APIs that are available to application developers and a few use case scenarios. For more information, see Smart Card Minidriver Specification.
Enhancements in Windows Vista with SP1
This section contains information about the smart card enhancements in Windows Vista with SP1, including:
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 that are used in some European countries. A smart card that is Read-only must advertise it through the CardGetProperty function. Read-only smart cards must support only a subset of the Version 6 card minidriver interface, and they 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.
Secure PIN channel
Secure PIN channel is a feature in Windows Vista with SP1 that enables a secure PIN prompt, which is followed by establishing 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 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 a PIN being stolen.
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 by using 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 instead of a PIN to access a smart card.
In external PIN mode, whenever PIN authentication to a smart card is required, Windows does not prompt the user for a PIN. Instead, it calls the minidriver's authentication API immediately without any user notification. The authentication and PIN collection occur without involvement from the operating system.
Optionally, and subject to specific restrictions, the minidriver can display its user interface (UI) to instruct the user to perform specific actions related to PIN collection. Such a UI is not used to 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 the UI when the context is silent mode. Minidrivers that display the UI must use a specific window handle, which is provided to the minidriver by Windows to create UI elements.
Note
Minidrivers must always return a session PIN when processing an external PIN.
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. This means that the supported versions of Windows can securely gather and present the unencrypted PIN to smart cards that support session PINs, and then get a security token from the smart card for accessing PIN-protected features. Session PINs are used by the external PIN feature, and they can be used by the secure PIN channel.
Session PINs are temporary, and they 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 this case, Windows presents the session PIN for smart card authentication until the smart card invalidates the session PIN. For more information, see the sections that describe the CardAuthenticateEx and CardSetProperty functions in Windows Smart Card Minidriver Specification.
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, which allows for up to eight roles and PINs. The PIN identifiers are used to extract PIN information from the smart card, and 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, and each bit corresponds to a role. For example, assume that the user authenticates with role 3, which corresponds 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 and multiple authenticated identities has PIN #1 authenticated, and then subsequently PIN #2 is authenticated, operations that either of these PINs control are allowed.
Enhancements in Windows Vista
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.
This section contains information about the smart card enhancements in Windows Vista, including:
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 the Smart Card Architecture section in Smart Card Architecture.
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 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.
The Base CSP is included in the Windows operating system as designated in the Applies to list at the beginning of this topic. 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 packages, see Description of the software update for Base Smart Card Cryptographic Service Provider.
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. The versions of Windows designated in the Applies to list at the beginning of this topic 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.
See also
The following table lists additional resources for smart card technologies.
Content type |
Resource |
|---|---|
Evaluation |
|
Reference |
|
Troubleshooting |
|
Community |
Using Smart Cards in Windows Virtual PC - Windows Virtual PC |
Developer |
|
Support |