How Smart Card Logon Works in Windows

Updated: February 18, 2010

Applies To: Windows 7, Windows Server 2008 R2

Although versions of Windows earlier than Windows Vista include support for smart cards, the types of certificates that smart cards can contain are limited. The limitations are:

• Each certificate must have a user principal name (UPN) and the smart card logon object identifier (also known as OID) in the enhanced key usage (EKU) attribute field. If the EKU is present, it must have smart card logon object identifier present. There is a Group Policy setting to make EKU optional.

• Each certificate must be stored in the AT_KEYEXCHANGE portion of the default CryptoAPI container.

To improve support for smart card deployments, changes to Windows were made to enable support for a range of certificates that do not have the previous limitations.

Smart card logon in Windows Vista

Smart card logon in Windows Vista changed in several key ways. The primary differences are highlighted below:

• The logon screen is no longer displayed automatically when a smart card is inserted in Windows Vista. Users are normally required to press CTRL+ALT+DEL to start the logon process.

• Valid certificates are enumerated and displayed from all smart cards and presented to the user.

• Keys are no longer restricted to the default container, and certificates in different containers can be chosen.

• As discussed in Smart card logon flow in Windows Vista and Windows 7, the cryptographic service provider (CSP) is accessed in Lsass.exe. The CSP is never loaded into the Winlogon process.

• Multiple Terminal Services sessions are supported in a single process.

• Elliptic curve cryptography (ECC)-based certificates are not supported for smart card logon in Windows Vista.

Smart card logon in Windows 7

In addition to the smart card logon changes in Windows Vista, Windows 7 includes:

• Smart card Plug and Play technology.

• Support for smart card logon with ECC-based certificates. ECC smart card logon is enabled through Group Policy.

The following table lists the ECC algorithms supported for smart card logon.

ECDSA logon requires an associated ECDH key on the smart card

The smart card credential provider will not show ECDSA-based logon certificates on the logon screen if they do not have an associated ECDH key on the smart card. This association is made possible through a new key property for ECDSA keys. If the ECDSA key does not have this property, Windows automatically selects the first ECDH container on the smart card.

Pairing an ECDSA logon certificate with an ECDH key allows Windows to support cached logon with ECDSA certificates. To perform cached smart card logon (to log on when the domain controller is not available), the system accesses symmetrically encrypted information that was stored locally during the last logon with the domain controller. For the RSA signature algorithm, the key that encrypts and decrypts this cached information is derived from a random value signed with the RSA logon key. However, a key derived from an ECDSA signature would likely be different each time it gets computed. Therefore, an ECDH key is associated with the ECDSA logon certificate and used to generate an AES key for storing the cached credentials.

Smart card key storage provider changes

The smart card key storage provider exposes the new NCRYPT_ASSOCIATED_ECDH_KEY key property for ECDSA keys so callers can discover which ECDH key to use with an ECDSA key. This property is defined in the CNG header file so that non-Microsoft key storage provider developers can support this new property to perform ECDSA-based logon.

wszProperty	pbDatatype	Description
NCRYPT_ASSOCIATED_ECDH_KEY	Long Pointer to Wide String (LPWSTR)	Return data contains an LPWSTR indicating the container name of the ECDH key to use during logon given a handle to an ECDSA key. If the information is not available (for example, if there are no ECDH keys on the smart card), the key storage provider will return NTE_NOT_FOUND. Note This property is only valid for ECDSA keys.