diff --git a/windows/security/identity-protection/smart-cards/smart-card-architecture.md b/windows/security/identity-protection/smart-cards/smart-card-architecture.md index bd8330d478..5e28ca6340 100644 --- a/windows/security/identity-protection/smart-cards/smart-card-architecture.md +++ b/windows/security/identity-protection/smart-cards/smart-card-architecture.md @@ -9,7 +9,7 @@ ms.date: 11/06/2023 This topic for the IT professional describes the system architecture that supports smart cards in the Windows operating system, including credential provider architecture and the smart card subsystem architecture. -Authentication is a process for verifying the identity of an object or person. When you authenticate an object, such as a smart card, the goal is to verify that the object is genuine. When you authenticate a person, the goal is to verify that you are not dealing with an imposter. +Authentication is a process for verifying the identity of an object or person. When you authenticate an object, such as a smart card, the goal is to verify that the object is genuine. When you authenticate a person, the goal is to verify that you aren't dealing with an imposter. In a networking context, authentication is the act of proving identity to a network application or resource. Typically, identity is proven by a cryptographic operation that uses a key only the user knows (such as with public key cryptography), or a shared key. The server side of the authentication exchange compares the signed data with a known cryptographic key to validate the authentication attempt. Storing the cryptographic keys in a secure central location makes the authentication process scalable and maintainable. @@ -51,7 +51,7 @@ Credential providers can be designed to support single sign-in (SSO). In this pr Multiple credential providers can coexist on a computer. -Credential providers must be registered on a computer running Windows, and they are responsible for: +Credential providers must be registered on a computer running Windows, and they're responsible for: - Describing the credential information that is required for authentication - Handling communication and logic with external authentication authorities @@ -74,7 +74,7 @@ The following graphic shows the relationship between the CryptoAPI, CSPs, the Sm ### Caching with Base CSP and smart card KSP -Smart card architecture uses caching mechanisms to assist in streamlining operations and to improve a user's access to a PIN. +Smart card architecture uses caching mechanisms to help streamlining operations and to improve a user's access to a PIN. - [Data caching](#data-caching): The data cache provides for a single process to minimize smart card I/O operations - [PIN caching](#pin-caching): The PIN cache helps the user from having to reenter a PIN each time the smart card is unauthenticated @@ -87,8 +87,8 @@ The existing global cache works as follows: 1. The application requests a cryptographic operation. For example, a user certificate is to be read from the smart card 1. The CSP checks its cache for the item -1. If the item is not found in the cache, or if the item is cached but is not up-to-date, the item is read from the smart card -1. After any item has been read from the smart card, it is added to the cache. Any existing out-of-date copy of that item is replaced +1. If the item isn't found in the cache, or if the item is cached but isn't up-to-date, the item is read from the smart card +1. After any item has been read from the smart card, it's added to the cache. Any existing out-of-date copy of that item is replaced Three types of objects or data are cached by the CSP: pins (for more information, see [PIN caching](#pin-caching)), certificates, and files. If any of the cached data changes, the corresponding object is read from the smart card in successive operations. For example, if a file is written to the smart card, the CSP cache becomes out-of-date for the files, and other processes read the smart card at least once to refresh their CSP cache. @@ -98,7 +98,7 @@ The global data cache is hosted in the Smart Cards for Windows service. Windows The PIN cache protects the user from entering a PIN every time the smart card is unauthenticated. After a smart card is authenticated, it will not differentiate among host-side applications—any application can access private data on the smart card. -To mitigate this, the smart card enters an exclusive state when an application authenticates to the smart card. However, this means that other applications cannot communicate with the smart card and will be blocked. Therefore, such exclusive connections are minimized. The issue is that a protocol (such as the Kerberos protocol) requires multiple signing operations. Therefore, the protocol requires exclusive access to the smart card over an extended period, or it requires multiple authentication operations. This is where the PIN cache is used to minimize exclusive use of the smart card without forcing the user to enter a PIN multiple times. +To mitigate this, the smart card enters an exclusive state when an application authenticates to the smart card. However, this means that other applications can't communicate with the smart card and will be blocked. Therefore, such exclusive connections are minimized. The issue is that a protocol (such as the Kerberos protocol) requires multiple signing operations. Therefore, the protocol requires exclusive access to the smart card over an extended period, or it requires multiple authentication operations. This is where the PIN cache is used to minimize exclusive use of the smart card without forcing the user to enter a PIN multiple times. The following example illustrates how this works. In this scenario, there are two applications: Outlook and Internet Explorer. The applications use smart cards for different purposes. @@ -108,13 +108,13 @@ The following example illustrates how this works. In this scenario, there are tw 1. The user opens Internet Explorer and tries to access a protected site that requires Transport Layer Security (TLS) authentication for the client 1. Internet Explorer prompts the user for the smart card PIN. The user enters the correct PIN 1. The TLS-related private key operation occurs on the smart card, and the user is authenticated and signed in -1. The user returns to Outlook to send another signed e-mail. This time, the user is not prompted for a PIN because the PIN is cached from the previous operation. Similarly, if the user uses Internet Explorer again for another operation, Internet Explorer will not prompt the user for a PIN +1. The user returns to Outlook to send another signed e-mail. This time, the user isn't prompted for a PIN because the PIN is cached from the previous operation. Similarly, if the user uses Internet Explorer again for another operation, Internet Explorer won't prompt the user for a PIN The Base CSP internally maintains a per-process cache of the PIN. The PIN is encrypted and stored in memory. The functions that are used to secure the PIN are RtlEncryptMemory, RtlDecryptMemory, and RtlSecureZeroMemory, which will empty buffers that contained the PIN. ### Smart card selection -The following sections in this topic describe how Windows leverages the smart card architecture to select the correct smart card reader software, provider, and credentials for a successful smart card sign-in: +The following sections in this article describe how Windows uses the smart card architecture to select the correct smart card reader software, provider, and credentials for a successful smart card sign-in: - [Container specification levels](#container-specification-levels) - [Container operations](#container-operations) @@ -202,10 +202,10 @@ Each call to `SCardUI *` may result in additional information read from a candid For type I and type II container specification levels, the smart card selection process is less complex because only the smart card in the named reader can be considered a match. The process for matching a smart card with a smart card reader is: -1. Find the requested smart card reader. If it cannot be found, the process fails (this requires a cache search by reader name) -1. If no smart card is in the reader, the user is prompted to insert a smart card. (this is only in non-silent mode; if the call is made in silent mode, it will fail) +1. Find the requested smart card reader. If it can't be found, the process fails (this requires a cache search by reader name) +1. If no smart card is in the reader, the user is prompted to insert a smart card. (this is only in nonsilent mode; if the call is made in silent mode, it fails) 1. For container specification level II only, the name of the default container on the chosen smart card is determined -1. To open an existing container or delete an existing container, find the specified container. If the specified container cannot be found on this smart card, the user is prompted to insert a smart card +1. To open an existing container or delete an existing container, find the specified container. If the specified container can't be found on this smart card, the user is prompted to insert a smart card 1. If the system attempts to create a new container, if the specified container already exists on this smart card, the process fails #### Make a smart card match @@ -217,23 +217,23 @@ For container specification levels III and IV, a broader method is used to match > [!NOTE] > This operation requires that you use the smart card with the Base CSP. -1. For each smart card that has been accessed by the Base CSP and the handle and container information are cached, the Base CSP looks for a valid default container. An operation is attempted on the cached SCARDHANDLE to verify its validity. If the smart card handle is not valid, the Base CSP continues to search for a new smart card -1. If a matching smart card is not found in the Base CSP cache, the Base CSP calls to the smart card subsystem. SCardUIDlgSelectCard() is used with an appropriate callback filter to find a matching smart card with a valid default container +1. For each smart card that has been accessed by the Base CSP and the handle and container information are cached, the Base CSP looks for a valid default container. An operation is attempted on the cached SCARDHANDLE to verify its validity. If the smart card handle isn't valid, the Base CSP continues to search for a new smart card +1. If a matching smart card isn't found in the Base CSP cache, the Base CSP calls to the smart card subsystem. SCardUIDlgSelectCard() is used with an appropriate callback filter to find a matching smart card with a valid default container #### Open an existing GUID-named container (no reader specified) > [!NOTE] > This operation requires that you use the smart card with the Base CSP. -1. For each smart card that is already registered with the Base CSP, search for the requested container. Attempt an operation on the cached SCARDHANDLE to verify its validity. If the smart card handle is not valid, the smart card's serial number is passed to the `SCardUI *` API to continue searching for this specific smart card (rather than only a general match for the container name) -1. If a matching smart card is not found in the Base CSP cache, a call is made to the smart card subsystem. `SCardUIDlgSelectCard()` is used with an appropriate callback filter to find a matching smart card with the requested container. Or, if a smart card serial number resulted from the search in Step 1, the callback filter attempts to match the serial number, not the container name +1. For each smart card that is already registered with the Base CSP, search for the requested container. Attempt an operation on the cached SCARDHANDLE to verify its validity. If the smart card handle isn't valid, the smart card's serial number is passed to the `SCardUI *` API to continue searching for this specific smart card (rather than only a general match for the container name) +1. If a matching smart card isn't found in the Base CSP cache, a call is made to the smart card subsystem. `SCardUIDlgSelectCard()` is used with an appropriate callback filter to find a matching smart card with the requested container. Or, if a smart card serial number resulted from the search in Step 1, the callback filter attempts to match the serial number, not the container name #### Create a new container (no reader specified) > [!NOTE] > This operation requires that you use the smart card with the Base CSP. -If the PIN is not cached, no CRYPT_SILENT is allowed for the container creation because the user must be prompted for a PIN, at a minimum. +If the PIN isn't cached, no CRYPT_SILENT is allowed for the container creation because the user must be prompted for a PIN, at a minimum. For other operations, the caller may be able to acquire a *verify* context against the default container `CRYPT_DEFAULT_CONTAINER_OPTIONAL` and then make a call with CryptSetProvParam to cache the user PIN for subsequent operations. @@ -242,15 +242,15 @@ For other operations, the caller may be able to acquire a *verify* context again 1. If the smart card is present, but it already has the named container, continue the search 1. If the smart card is available, but a call to CardQueryFreeSpace indicates that the smart card has insufficient storage for an additional key container, continue the search 1. Otherwise, use the first available smart card that meets the above criteria for the container creation -1. If a matching smart card is not found in the CSP cache, make a call to the smart card subsystem. The callback that is used to filter enumerated smart cards verifies that a candidate smart card does not already have the named container, and that CardQueryFreeSpace indicates the smart card has sufficient space for an additional container. If no suitable smart card is found, the user is prompted to insert a smart card +1. If a matching smart card isn't found in the CSP cache, make a call to the smart card subsystem. The callback that is used to filter enumerated smart cards verifies that a candidate smart card doesn't already have the named container, and that CardQueryFreeSpace indicates the smart card has sufficient space for an additional container. If no suitable smart card is found, the user is prompted to insert a smart card #### Delete a container -1. If the specified container name is NULL, the default container is deleted. Deleting the default container causes a new default container to be selected arbitrarily. For this reason, this operation is not recommended +1. If the specified container name is NULL, the default container is deleted. Deleting the default container causes a new default container to be selected arbitrarily. For this reason, this operation isn't recommended 1. For each smart card already known by the CSP, refresh the stored SCARDHANDLE and make the following checks: - 1. If the smart card does not have the named container, continue the search + 1. If the smart card doesn't have the named container, continue the search 1. If the smart card has the named container, but the smart card handle is no longer valid, store the serial number of the matching smart card and pass it to SCardUI -1. If a matching smart card is not found in the CSP cache, make a call to the smart card subsystem. The callback that is used to filter enumerated smart cards should verify that a candidate smart card has the named container. If a serial number was povided as a result of the previous cache search, the callback should filter enumerated smart cards on serial number rather than on container matches. If the context is non-silent and no suitable smart card is found, display UI that prompts the user to insert a smart card +1. If a matching smart card isn't found in the CSP cache, make a call to the smart card subsystem. The callback that is used to filter enumerated smart cards should verify that a candidate smart card has the named container. If a serial number was povided as a result of the previous cache search, the callback should filter enumerated smart cards on serial number rather than on container matches. If the context is non-silent and no suitable smart card is found, display UI that prompts the user to insert a smart card ### Base CSP and KSP-based architecture in Windows @@ -269,16 +269,16 @@ The following diagram shows the Cryptography architecture that is used by the Wi | `PP_ROOT_CERTSTORE` | - Read and Write (used by `CryptGetProvParam` and `CryptSetProvParam`)
- Used to write a collection of root certificates to the smart card or return `HCERTSTORE`, which contains root certificates from the smart card
- Used primarily for joining a domain by using a smart card
- Caller responsible for closing the certificate store | | `PP_SMARTCARD_READER` | - Read-only (used only by `CryptGetProvParam`)
- Returns the smart card reader name as an ANSI string that is used to construct a fully qualified container name (that is, a smart card reader plus a container) | | `PP_SMARTCARD_GUID` | - Return smart card GUID (also known as a serial number), which should be unique for each smart card
- Used by the certificate propagation service to track the source of a root certificate | -| `PP_UI_PROMPT` | - Used to set the search string for the `SCardUIDlgSelectCard` card insertion dialog box
- Persistent for the entire process when it is set
- Write-only (used only by `CryptSetProvParam`) | +| `PP_UI_PROMPT` | - Used to set the search string for the `SCardUIDlgSelectCard` card insertion dialog box
- Persistent for the entire process when it's set
- Write-only (used only by `CryptSetProvParam`) | ### Implications for CSPs in Windows -Cryptographic Service Providers (CSPs), including custom smart card CSPs, continue to be supported but this approach is not recommended. Using the existing Base CSP and smart card KSP with the smart card minidriver model for smart cards provides significant benefits in terms of performance, and PIN and data caching. One minidriver can be configured to work under CryptoAPI and CNG layers. This provides benefits from enhanced cryptographic support, including elliptic curve cryptography and AES. +Cryptographic Service Providers (CSPs), including custom smart card CSPs, continue to be supported but this approach isn't recommended. Using the existing Base CSP and smart card KSP with the smart card minidriver model for smart cards provides significant benefits in terms of performance, and PIN and data caching. One minidriver can be configured to work under CryptoAPI and CNG layers. This provides benefits from enhanced cryptographic support, including elliptic curve cryptography and AES. If a smart card is registered by a CSP and a smart card minidriver, the one that was installed most recently will be used to communicate with the smart card. ### Write a smart card minidriver, CSP, or KSP -CSPs and KSPs are meant to be written only if specific functionality is not available in the current smart card minidriver architecture. For example, the smart card minidriver architecture supports hardware security modules, so a minidriver could be written for a hardware security module, and a CSP or KSP may not be required unless it is needed to support algorithms that are not implemented in the Base CSP or smart card KSP. +CSPs and KSPs are meant to be written only if specific functionality isn't available in the current smart card minidriver architecture. For example, the smart card minidriver architecture supports hardware security modules, so a minidriver could be written for a hardware security module, and a CSP or KSP may not be required unless it's needed to support algorithms that aren't implemented in the Base CSP or smart card KSP. For more information about how to write a smart card minidriver, CSP, or KSP, see [Smart Card Minidrivers](/windows-hardware/drivers/smartcard/smart-card-minidrivers). diff --git a/windows/security/identity-protection/smart-cards/smart-card-certificate-propagation-service.md b/windows/security/identity-protection/smart-cards/smart-card-certificate-propagation-service.md index 8cfae399fd..851e89b13a 100644 --- a/windows/security/identity-protection/smart-cards/smart-card-certificate-propagation-service.md +++ b/windows/security/identity-protection/smart-cards/smart-card-certificate-propagation-service.md @@ -33,23 +33,23 @@ The following figure shows the flow of the certificate propagation service. The Properties of the certificate propagation service include: - `CERT_STORE_ADD_REPLACE_EXISTING_INHERIT_PROPERTIES` adds certificates to a user's Personal store -- If the certificate has the `CERT_ENROLLMENT_PROP_ID` property (as defined by `wincrypt.h`), it filters empty requests and places them in the current user's request store, but it does not propagate them to the user's Personal store -- The service does not propagate any computer certificates to a user's Personal store or propagate user certificates to a computer store -- The service propagates certificates according to Group Policy options that are set, which may include: +- If the certificate has the `CERT_ENROLLMENT_PROP_ID` property (as defined by `wincrypt.h`), it filters empty requests and places them in the current user's request store, but it doesn't propagate them to the user's Personal store +- The service doesn't propagate any computer certificates to a user's Personal store or propagate user certificates to a computer store +- The service propagates certificates according to Group Policy options that are set, which might include: - **Turn on certificate propagation from the smart card** specifies whether a user's certificate should be propagated - **Turn on root certificate propagation from smart card** specifies whether root certificates should be propagated - **Configure root certificate cleanup** specifies how root certificates are removed ## Root certificate propagation service -Root certificate propagation is responsible for the following smart card deployment scenarios when public key infrastructure (PKI) trust has not yet been established: +Root certificate propagation is responsible for the following smart card deployment scenarios when public key infrastructure (PKI) trust hasn't yet been established: - Joining the domain - Accessing a network remotely -In both cases, the computer is not joined to a domain, and therefore, trust is not being managed by Group Policy. However, the objective is to authenticate to a remote server, such as the domain controller. Root certificate propagation provides the ability to use the smart card to include the missing trust chain. +In both cases, the computer isn't joined to a domain, and therefore, trust isn't being managed by Group Policy. However, the objective is to authenticate to a remote server, such as the domain controller. Root certificate propagation provides the ability to use the smart card to include the missing trust chain. -When the smart card is inserted, the certificate propagation service propagates any root certificates on the card to the trusted smart card root computer certificate stores. This process establishes a trust relationship with the enterprise resources. You may also use a subsequent cleanup action when the user's smart card is removed from the reader, or when the user signs out. This is configurable with Group Policy. For more information, see [Smart Card Group Policy and Registry Settings](smart-card-group-policy-and-registry-settings.md). +When the smart card is inserted, the certificate propagation service propagates any root certificates on the card to the trusted smart card root computer certificate stores. This process establishes a trust relationship with the enterprise resources. You might also use a subsequent cleanup action when the user's smart card is removed from the reader, or when the user signs out. This is configurable with Group Policy. For more information, see [Smart Card Group Policy and Registry Settings](smart-card-group-policy-and-registry-settings.md). For more information about root certificate requirements, see [Smart card root certificate requirements for use with domain sign-in](smart-card-certificate-requirements-and-enumeration.md#smart-card-root-certificate-requirements-for-use-with-domain-sign-in). diff --git a/windows/security/identity-protection/smart-cards/smart-card-certificate-requirements-and-enumeration.md b/windows/security/identity-protection/smart-cards/smart-card-certificate-requirements-and-enumeration.md index 1ac825dde6..79cf20942a 100644 --- a/windows/security/identity-protection/smart-cards/smart-card-certificate-requirements-and-enumeration.md +++ b/windows/security/identity-protection/smart-cards/smart-card-certificate-requirements-and-enumeration.md @@ -15,8 +15,8 @@ When a smart card is inserted, the following steps are performed. > Unless otherwise mentioned, all operations are performed silently (CRYPT_SILENT is passed to CryptAcquireContext). 1. The smart card resource manager database searches for the smart card's cryptographic service provider (CSP). -1. A qualified container name is constructed by using the smart card reader name, and it is passed to the CSP. The format is `\\.\` -1. CryptAcquireContext is called to retrieve a context to the default container. If a failure occurs, the smart card will be unusable for smart card sign-in. +1. A qualified container name is constructed by using the smart card reader name, and it's passed to the CSP. The format is `\\.\` +1. CryptAcquireContext is called to retrieve a context to the default container. If a failure occurs, the smart card is unusable for smart card sign-in. 1. The name of the container is retrieved by using the PP_CONTAINER parameter with CryptGetProvParam. 1. Using the context acquired in Step 3, the CSP is queried for the PP_USER_CERTSTORE parameter (added in Windows Vista). For more information, see [Smart Card Architecture](smart-card-architecture.md). If the operation is successful, the name of a certificate store is returned, and the program flow skips to Step 8. 1. If the operation in Step 5 fails, the default container context from Step 3 is queried for the AT_KEYEXCHANGE key. @@ -40,13 +40,13 @@ When a smart card is inserted, the following steps are performed. ## Smart card sign-in flow in Windows -Most issues during authentication occur because of session behavior changes. When changes occur, the Local Security Authority (LSA) does not reacquire the session context; it relies instead on the Cryptographic Service Provider to handle the session change. +Most issues during authentication occur because of session behavior changes. When changes occur, the Local Security Authority (LSA) doesn't reacquire the session context; it relies instead on the Cryptographic Service Provider to handle the session change. -Client certificates that do not contain a UPN in the `subjectAltName`` (SAN) field of the certificate can be enabled for sign-in, which supports a wider variety of certificates and supports multiple sign-in certificates on the same card. +Client certificates that don't contain a UPN in the `subjectAltName`` (SAN) field of the certificate can be enabled for sign-in, which supports a wider variety of certificates and supports multiple sign-in certificates on the same card. Support for multiple certificates on the same card is enabled by default. New certificate types must be enabled through Group Policy. -If you enable the **Allow signature keys valid for Logon** credential provider policy, any certificates that are available on the smart card with a signature-only key are listed on the sign-in screen. This allows users to select their sign-in experience. If the policy is disabled or not configured, smart card signature-key-based certificates are not listed on the sign-in screen. +If you enable the **Allow signature keys valid for Logon** credential provider policy, any certificates that are available on the smart card with a signature-only key are listed on the sign-in screen. This allows users to select their sign-in experience. If the policy is disabled or not configured, smart card signature-key-based certificates aren't listed on the sign-in screen. The following diagram illustrates how smart card sign-in works in the supported versions of Windows. @@ -69,7 +69,7 @@ Following are the steps that are performed during a smart card sign-in: 1. The sign-in UI requests the new credentials from the smart card credential provider. As a response, the smart card credential provider provides each sign-in certificate to the sign-in UI, and corresponding sign-in tiles are displayed. The user selects a smart card-based sign-in certificate tile, and Windows displays a PIN dialog box. 1. The user enters the PIN, and then presses ENTER. The smart card credential provider encrypts the PIN. -1. The credential provider that resides in the LogonUI system collects the PIN. As part of packaging credentials in the smart card credential provider, the data is packaged in a KERB_CERTIFICATE_LOGON structure. The main contents of the KERB_CERTIFICATE_LOGON structure are the smart card PIN, CSP data (such as reader name and container name), user name, and domain name. User name is required if the sign-in domain is not in the same forest because it enables a certificate to be mapped to multiple user accounts. +1. The credential provider that resides in the LogonUI system collects the PIN. As part of packaging credentials in the smart card credential provider, the data is packaged in a KERB_CERTIFICATE_LOGON structure. The main contents of the KERB_CERTIFICATE_LOGON structure are the smart card PIN, CSP data (such as reader name and container name), user name, and domain name. User name is required if the sign-in domain isn't in the same forest because it enables a certificate to be mapped to multiple user accounts. 1. The credential provider wraps the data (such as the encrypted PIN, container name, reader name, and card key specification) and sends it back to LogonUI. 1. Winlogon presents the data from LogonUI to the LSA with the user information in LSALogonUser. 1. LSA calls the Kerberos authentication package (Kerberos SSP) to create a Kerberos authentication service request (KRB_AS_REQ), which containing a preauthenticator (as specified in RFC 4556: [Public Key Cryptography for Initial Authentication in Kerberos (PKINIT)](http://www.ietf.org/rfc/rfc4556.txt)). @@ -107,7 +107,7 @@ Following are the steps that are performed during a smart card sign-in: For more information about the Kerberos protocol, see [Microsoft Kerberos](/windows/win32/secauthn/microsoft-kerberos). -By default, the KDC verifies that the client's certificate contains the smart card client authentication EKU szOID_KP_SMARTCARD_LOGON. However, if enabled, the **Allow certificates with no extended key usage certificate attribute** Group Policy setting allows the KDC to not require the SC-LOGON EKU. SC-LOGON EKU is not required for account mappings that are based on the public key. +By default, the KDC verifies that the client's certificate contains the smart card client authentication EKU szOID_KP_SMARTCARD_LOGON. However, if enabled, the **Allow certificates with no extended key usage certificate attribute** Group Policy setting allows the KDC to not require the SC-LOGON EKU. SC-LOGON EKU isn't required for account mappings that are based on the public key. ## KDC certificate @@ -125,26 +125,26 @@ Certificate requirements are listed by versions of the Windows operating system. ### Certificate requirements -The smart card certificate has specific format requirements when it is used with Windows XP and earlier operating systems. You can enable any certificate to be visible for the smart card credential provider. +The smart card certificate has specific format requirements when it's used with Windows XP and earlier operating systems. You can enable any certificate to be visible for the smart card credential provider. | Component | Requirements | |--|--| | CRL distribution point location | Not required | | Key usage | Digital signature | | Basic constraints | Not required | -| extended key usage (EKU) | The smart card sign-in object identifier is not required.

**Note** If an EKU is present, it must contain the smart card sign-in EKU. Certificates with no EKU can be used for sign-in. | -| Subject alternative name | E-mail ID is not required for smart card sign-in. | +| extended key usage (EKU) | The smart card sign-in object identifier isn't required.

**Note** If an EKU is present, it must contain the smart card sign-in EKU. Certificates with no EKU can be used for sign-in. | +| Subject alternative name | E-mail ID isn't required for smart card sign-in. | | Subject | Not required | -| Key exchange (AT_KEYEXCHANGE field) | Not required for smart card sign-in certificates if a Group Policy setting is enabled. (By default, Group Policy settings are not enabled.) | +| Key exchange (AT_KEYEXCHANGE field) | Not required for smart card sign-in certificates if a Group Policy setting is enabled. (By default, Group Policy settings aren't enabled.) | | CRL | Not required | | UPN | Not required | | Notes | You can enable any certificate to be visible for the smart card credential provider. | ### Client certificate mappings -Certificate mapping is based on the UPN that is contained in the subjectAltName (SAN) field of the certificate. Client certificates that do not contain information in the SAN field are also supported. +Certificate mapping is based on the UPN that is contained in the subjectAltName (SAN) field of the certificate. Client certificates that don't contain information in the SAN field are also supported. -SSL/TLS can map certificates that do not have SAN, and the mapping is done by using the AltSecID attributes on client accounts. The X509 AltSecID, which is used by SSL/TLS client authentication is of the form "X509: `` `` and `` are taken from the client certificate, with '\r' and '\n' replaced with ','. +SSL/TLS can map certificates that don't have SAN, and the mapping is done by using the AltSecID attributes on client accounts. The X509 AltSecID, which is used by SSL/TLS client authentication is of the form "X509: `` `` and `` are taken from the client certificate, with '\r' and '\n' replaced with ','. #### Certificate revocation list distribution points @@ -167,10 +167,10 @@ This account mapping is supported by the KDC in addition to six other mapping me The certificate object is parsed to look for content to perform user account mapping. - When a user name is provided with the certificate, the user name is used to locate the account object. This operation is the fastest, because string matching occurs -- When only the certificate object is provided, a series of operations are performed to locate the user name to map the user name to an account object +- When only the certificate object is provided, multiple operations are performed to locate the user name to map the user name to an account object - When no domain information is available for authentication, the local domain is used by default. If any other domain is to be used for lookup, a domain name hint should be provided to perform the mapping and binding -Mapping based on generic attributes is not possible because there is no generic API to retrieve attributes from a certificate. Currently, the first method that locates an account successfully stops the search. But a configuration error occurs if two methods map the same certificate to different user accounts when the client does not supply the client name through the mapping hints. +Mapping based on generic attributes isn't possible because there's no generic API to retrieve attributes from a certificate. Currently, the first method that locates an account successfully stops the search. But a configuration error occurs if two methods map the same certificate to different user accounts when the client doesn't supply the client name through the mapping hints. The following figure illustrates the process of mapping user accounts for sign-in in the directory by viewing various entries in the certificate. @@ -190,23 +190,23 @@ A single user certificate can be mapped to multiple accounts. For example, a use Based on the information that is available in the certificate, the sign-in conditions are: 1. If no UPN is present in the certificate: - 1. Sign-in can occur in the local forest or in another forest if a single user with one certificate needs to sign in to different accounts - 1. A hint must be supplied if mapping is not unique (for example, if multiple users are mapped to the same certificate) + 1. Sign-in can occur in the local forest or in another forest if a single user with one certificate needs to sign in to different accounts + 1. A hint must be supplied if mapping isn't unique (for example, if multiple users are mapped to the same certificate) 1. If a UPN is present in the certificate: - 1. The certificate cannot be mapped to multiple users in the same forest - 1. The certificate can be mapped to multiple users in different forests. For a user to sign in to other forests, an X509 hint must be supplied to the user + 1. The certificate can't be mapped to multiple users in the same forest + 1. The certificate can be mapped to multiple users in different forests. For a user to sign in to other forests, an X509 hint must be supplied to the user ## Smart card sign-in for multiple users into a single account -A group of users might sign in to a single account (for example, an administrator account). For that account, user certificates are mapped so that they are enabled for sign-in. +A group of users might sign in to a single account (for example, an administrator account). For that account, user certificates are mapped so that they're enabled for sign-in. -Several distinct certificates can be mapped to a single account. For this to work properly, the certificate cannot have UPNs. +Several distinct certificates can be mapped to a single account. For this to work properly, the certificate can't have UPNs. For example, if Certificate1 has CN=CNName1, Certificate2 has CN=User1, and Certificate3 has CN=User2, the AltSecID of these certificates can be mapped to a single account by using the Active Directory Users and Computers name mapping. ## Smart card sign-in across forests -For account mapping to work across forests, particularly in cases where there is not enough information available on the certificate, the user might enter a hint in the form of a user name, such as *domain\user*, or a fully qualified UPN such as `user@contoso.com`. +For account mapping to work across forests, particularly in cases where there isn't enough information available on the certificate, the user might enter a hint in the form of a user name, such as *domain\user*, or a fully qualified UPN such as `user@contoso.com`. > [!NOTE] > For the hint field to appear during smart card sign-in, the **Allow user name hint** Group Policy setting (**X509HintsNeeded** registry key) must be enabled on the client. @@ -215,9 +215,9 @@ For account mapping to work across forests, particularly in cases where there is Online Certificate Status Protocol (OCSP), which is defined in RFC 2560, enables applications to obtain timely information about the revocation status of a certificate. Because OCSP responses are small and well bound, constrained clients might want to use OCSP to check the validity of the certificates for Kerberos on the KDC, to avoid transmission of large CRLs, and to save bandwidth on constrained networks. For information about CRL registry keys, see [Smart Card Group Policy and Registry Settings](smart-card-group-policy-and-registry-settings.md). -The KDCs in Windows attempt to get OCSP responses and use them when available. This behavior cannot be disabled. CryptoAPI for OCSP caches OCSP responses and the status of the responses. The KDC supports only OCSP responses for the signer certificate. +The KDCs in Windows attempt to get OCSP responses and use them when available. This behavior can't be disabled. CryptoAPI for OCSP caches OCSP responses and the status of the responses. The KDC supports only OCSP responses for the signer certificate. -Windows client computers attempt to request the OCSP responses and use them in the reply when they are available. This behavior cannot be disabled. +Windows client computers attempt to request the OCSP responses and use them in the reply when they're available. This behavior can't be disabled. ## Smart card root certificate requirements for use with domain sign-in @@ -227,10 +227,10 @@ For sign-in to work in a smart card-based domain, the smart card certificate mus - The smart card sign-in certificate must have the HTTP CRL distribution point listed in its certificate - The CRL distribution point must have a valid CRL published and a delta CRL, if applicable, even if the CRL distribution point is empty - The smart card certificate must contain one of the following: - - A subject field that contains the DNS domain name in the distinguished name. If it does not, resolution to an appropriate domain fails, so Remote Desktop Services and the domain sign-in with the smart card fail - - A UPN where the domain name resolves to the actual domain. For example, if the domain name is `Engineering.Corp.Contoso`, the UPN is `username@engineering.corp.contoso.com`. If any part of the domain name is omitted, the Kerberos client cannot find the appropriate domain + - A subject field that contains the DNS domain name in the distinguished name. If it doesn't, resolution to an appropriate domain fails, so Remote Desktop Services and the domain sign-in with the smart card fail + - A UPN where the domain name resolves to the actual domain. For example, if the domain name is `Engineering.Corp.Contoso`, the UPN is `username@engineering.corp.contoso.com`. If any part of the domain name is omitted, the Kerberos client can't find the appropriate domain -Although the HTTP CRL distribution points are on by default in Windows Server 2008, subsequent versions of the Windows Server operating system do not include HTTP CRL distribution points. To allow smart card sign-in to a domain in these versions, do the following: +Although the HTTP CRL distribution points are on by default in Windows Server 2008, subsequent versions of the Windows Server operating system don't include HTTP CRL distribution points. To allow smart card sign-in to a domain in these versions, do the following: 1. Enable HTTP CRL distribution points on the CA 1. Restart the CA @@ -240,7 +240,7 @@ Although the HTTP CRL distribution points are on by default in Windows Server 20 The workaround is to enable the **Allow user name hint** Group Policy setting (**X509HintsNeeded** registry key), which allows the user to supply a hint in the credentials user interface for domain sign-in. -If the client computer is not joined to the domain or if it is joined to a different domain, the client computer can resolve the server domain only by looking at the distinguished name on the certificate, not the UPN. For this scenario to work, the certificate requires a full subject, including `DC=`, for domain name resolution. +If the client computer isn't joined to the domain or if it's joined to a different domain, the client computer can resolve the server domain only by looking at the distinguished name on the certificate, not the UPN. For this scenario to work, the certificate requires a full subject, including `DC=`, for domain name resolution. To deploy root certificates on a smart card for the currently joined domain, you can use the following command: diff --git a/windows/security/identity-protection/smart-cards/smart-card-removal-policy-service.md b/windows/security/identity-protection/smart-cards/smart-card-removal-policy-service.md index 970bee548f..616ea96b49 100644 --- a/windows/security/identity-protection/smart-cards/smart-card-removal-policy-service.md +++ b/windows/security/identity-protection/smart-cards/smart-card-removal-policy-service.md @@ -15,7 +15,7 @@ The smart card removal policy service is applicable when a user has signed in wi The numbers in the previous figure represent the following actions: -1. Winlogon is not directly involved in monitoring for smart card removal events. The sequence of steps that are involved when a smart card is removed begins with the smart card credential provider in the sign-in UI process. When a user successfully signs in with a smart card, the smart card credential provider captures the reader name. This information is then stored in the registry with the session identifier where the sign-in was initiated. +1. Winlogon isn't directly involved in monitoring for smart card removal events. The sequence of steps that are involved when a smart card is removed begins with the smart card credential provider in the sign-in UI process. When a user successfully signs in with a smart card, the smart card credential provider captures the reader name. This information is then stored in the registry with the session identifier where the sign-in was initiated. 1. The smart card resource manager service notifies the smart card removal policy service that a sign-in has occurred. 1. ScPolicySvc retrieves the smart card information that the smart card credential provider stored in the registry. This call is redirected if the user is in a remote session. If the smart card is removed, ScPolicySvc is notified. 1. ScPolicySvc calls Remote Desktop Services to take the appropriate action if the request is to sign out the user or to disconnect the user's session, which might result in data loss. If the setting is configured to lock the computer when the smart card is removed, ScPolicySvc sends a message to Winlogon to lock the computer. diff --git a/windows/security/identity-protection/virtual-smart-cards/virtual-smart-card-get-started.md b/windows/security/identity-protection/virtual-smart-cards/virtual-smart-card-get-started.md index fd30cb8172..9993a82970 100644 --- a/windows/security/identity-protection/virtual-smart-cards/virtual-smart-card-get-started.md +++ b/windows/security/identity-protection/virtual-smart-cards/virtual-smart-card-get-started.md @@ -11,9 +11,9 @@ ms.date: 11/06/2023 This topic for the IT professional describes how to set up a basic test environment for using TPM virtual smart cards. -Virtual smart cards are a technology from Microsoft that offer comparable security benefits in two-factor authentication to physical smart cards. They also offer more convenience for users and lower cost for organizations to deploy. By utilizing Trusted Platform Module (TPM) devices that provide the same cryptographic capabilities as physical smart cards, virtual smart cards accomplish the three key properties that are desired by smart cards: non-exportability, isolated cryptography, and anti-hammering. +Virtual smart cards are a technology from Microsoft that offers comparable security benefits in two-factor authentication to physical smart cards. They also offer more convenience for users and lower cost for organizations to deploy. By utilizing Trusted Platform Module (TPM) devices that provide the same cryptographic capabilities as physical smart cards, virtual smart cards accomplish the three key properties that are desired by smart cards: nonexportability, isolated cryptography, and anti-hammering. -This step-by-step walkthrough shows you how to set up a basic test environment for using TPM virtual smart cards. After you complete this walkthrough, you will have a functional virtual smart card installed on the Windows computer. +This step-by-step walkthrough shows you how to set up a basic test environment for using TPM virtual smart cards. After you complete this walkthrough, you'll have a functional virtual smart card installed on the Windows computer. You should be able to complete this walkthrough in less than one hour, excluding installing software and setting up the test domain. @@ -29,7 +29,7 @@ You should be able to complete this walkthrough in less than one hour, excluding ## Prerequisites -You will need: +You'll need: - A computer running Windows 10 with an installed and fully functional TPM (version 1.2 or version 2.0) - A test domain to which the computer listed above can be joined @@ -37,17 +37,17 @@ You will need: ## Step 1: Create the certificate template -On your domain server, you need to create a template for the certificate that you will request for the virtual smart card. +On your domain server, you need to create a template for the certificate that you request for the virtual smart card. ### To create the certificate template -1. On your server, open the Microsoft Management Console (MMC). One way to do this is to type **mmc.exe** from the **Start** menu, right-click **mmc.exe**, and click **Run as administrator** +1. On your server, open the Microsoft Management Console (MMC). One way to do this is to type **mmc.exe** from the **Start** menu, right-click **mmc.exe**, and select **Run as administrator** 1. Select **File** > **Add/Remove Snap-in** ![Add or remove snap-in.](images/vsc-02-mmc-add-snap-in.png) -1. In the available snap-ins list, click **Certificate Templates**, and then click **Add** +1. In the available snap-ins list, select **Certificate Templates**, and then select **Add** ![Add Certificate Templates snap-in.](images/vsc-03-add-certificate-templates-snap-in.png) 1. Certificate Templates is now located under **Console Root** in the MMC. Double-click it to view all the available certificate templates. -1. Right-click the **Smartcard Logon** template, and click **Duplicate Template**. +1. Right-click the **Smartcard Logon** template, and select **Duplicate Template**. ![Duplicating the Smartcard Logon template.](images/vsc-04-right-click-smartcard-logon-template.png) 1. On the **Compatibility** tab, under **Certification Authority**, review the selection, and change it if needed. ![Compatibility tab, certification authority setting.](images/vsc-05-certificate-template-compatibility.png) @@ -56,31 +56,31 @@ On your domain server, you need to create a template for the certificate that yo 1. Set the validity period to the desired value. 1. On the **Request Handling** tab: 1. Set the **Purpose** to **Signature and smartcard logon**. - 1. Click **Prompt the user during enrollment**. + 1. Select **Prompt the user during enrollment**. 1. On the **Cryptography** tab: 1. Set the minimum key size to 2048. - 1. Click **Requests must use one of the following providers**, and then select **Microsoft Base Smart Card Crypto Provider**. + 1. Select **Requests must use one of the following providers**, and then select **Microsoft Base Smart Card Crypto Provider**. 1. On the **Security** tab, add the security group that you want to give **Enroll** access to. For example, if you want to give access to all users, select the **Authenticated users** group, and then select **Enroll** permissions for them. -1. Click **OK** to finalize your changes and create the new template. Your new template should now appear in the list of Certificate Templates. -1. Select **File**, then click **Add/Remove Snap-in** to add the Certification Authority snap-in to your MMC console. When asked which computer you want to manage, select the computer on which the CA is located, probably **Local Computer**. +1. Select **OK** to finalize your changes and create the new template. Your new template should now appear in the list of Certificate Templates. +1. Select **File**, then select **Add/Remove Snap-in** to add the Certification Authority snap-in to your MMC console. When asked which computer you want to manage, select the computer on which the CA is located, probably **Local Computer**. ![Add Certification Authority snap-in.](images/vsc-06-add-certification-authority-snap-in.png) 1. In the left pane of the MMC, expand **Certification Authority (Local)**, and then expand your CA within the Certification Authority list. -1. Right-click **Certificate Templates**, click **New**, and then click **Certificate Template to Issue**. +1. Right-click **Certificate Templates**, select **New**, and then select **Certificate Template to Issue**. ![Right-click menu for Certificate Templates.](images/vsc-07-right-click-certificate-templates.png) -1. From the list, select the new template that you just created (**TPM Virtual Smart Card Logon**), and then click **OK**. +1. From the list, select the new template that you created (**TPM Virtual Smart Card Logon**), and then select **OK**. > [!NOTE] > It can take some time for your template to replicate to all servers and become available in this list. ![Selecting a certificate template.](images/vsc-08-enable-certificate-template.png) -1. After the template replicates, in the MMC, right-click in the Certification Authority list, click **All Tasks**, and then click **Stop Service**. Then, right-click the name of the CA again, click **All Tasks**, and then click **Start Service**. +1. After the template replicates, in the MMC, right-click in the Certification Authority list, select **All Tasks**, and then select **Stop Service**. Then, right-click the name of the CA again, select **All Tasks**, and then select **Start Service**. ![Stopping and starting the service.](images/vsc-09-stop-service-start-service.png) ## Step 2: Create the TPM virtual smart card -In this step, you will create the virtual smart card on the client computer by using the command-line tool, [Tpmvscmgr.exe](virtual-smart-card-tpmvscmgr.md). +In this step, you create the virtual smart card on the client computer by using the command-line tool, [Tpmvscmgr.exe](virtual-smart-card-tpmvscmgr.md). ### To create the TPM virtual smart card @@ -90,10 +90,10 @@ In this step, you will create the virtual smart card on the client computer by u `tpmvscmgr.exe create /name TestVSC /pin default /adminkey random /generate` - This will create a virtual smart card with the name **TestVSC**, omit the unlock key, and generate the file system on the card. The PIN will be set to the default, 12345678. To be prompted for a PIN, instead of **/pin default** you can type **/pin prompt**.\ + This creates a virtual smart card with the name **TestVSC**, omit the unlock key, and generate the file system on the card. The PIN is set to the default, 12345678. To be prompted for a PIN, instead of **/pin default** you can type **/pin prompt**.\ For more information about the Tpmvscmgr command-line tool, see [Use Virtual Smart Cards](virtual-smart-card-use-virtual-smart-cards.md) and [Tpmvscmgr](virtual-smart-card-tpmvscmgr.md). -1. Wait several seconds for the process to finish. Upon completion, Tpmvscmgr.exe will provide you with the device instance ID for the TPM Virtual Smart Card. Store this ID for later reference because you will need it to manage or remove the virtual smart card. +1. Wait several seconds for the process to finish. Upon completion, Tpmvscmgr.exe provides you with the device instance ID for the TPM Virtual Smart Card. Store this ID for later reference because you need it to manage or remove the virtual smart card. ## Step 3: Enroll for the certificate on the TPM Virtual Smart Card @@ -102,15 +102,15 @@ The virtual smart card must be provisioned with a sign-in certificate for it to ### To enroll the certificate 1. Open the Certificates console by typing **certmgr.msc** on the **Start** menu -1. Right-click **Personal**, click **All Tasks**, and then click **Request New Certificate** +1. Right-click **Personal**, select **All Tasks**, and then select **Request New Certificate** ![Request New Certificate.](images/vsc-11-certificates-request-new-certificate.png) 1. Follow the prompts and when offered a list of templates, select the **TPM Virtual Smart Card Logon** check box (or whatever you named the template in Step 1) ![Certificate enrollment, select certificate.](images/vsc-12-certificate-enrollment-select-certificate.png) 1. If prompted for a device, select the Microsoft virtual smart card that corresponds to the one you created in the previous section. It displays as **Identity Device (Microsoft Profile)** -1. Enter the PIN that was established when you created the TPM virtual smart card, and then click **OK** -1. Wait for the enrollment to finish, and then click **Finish** +1. Enter the PIN that was established when you created the TPM virtual smart card, and then select **OK** +1. Wait for the enrollment to finish, and then select **Finish** -The virtual smart card can now be used as an alternative credential to sign in to your domain. To verify that your virtual smart card configuration and certificate enrollment were successful, sign out of your current session, and then sign in. When you sign in, you will see the icon for the new TPM virtual smart card on the Secure Desktop (sign in) screen or you will be automatically directed to the TPM smart card sign-in dialog box. Click the icon, enter your PIN (if necessary), and then click **OK**. You should be signed in to your domain account. +The virtual smart card can now be used as an alternative credential to sign in to your domain. To verify that your virtual smart card configuration and certificate enrollment were successful, sign out of your current session, and then sign in. When you sign in, you'll see the icon for the new TPM virtual smart card on the Secure Desktop (sign in) screen or you are automatically directed to the TPM smart card sign-in dialog box. Select the icon, enter your PIN (if necessary), and then select **OK**. You should be signed in to your domain account. ## See also diff --git a/windows/security/identity-protection/virtual-smart-cards/virtual-smart-card-understanding-and-evaluating.md b/windows/security/identity-protection/virtual-smart-cards/virtual-smart-card-understanding-and-evaluating.md index 2ab0167682..c5ac24e838 100644 --- a/windows/security/identity-protection/virtual-smart-cards/virtual-smart-card-understanding-and-evaluating.md +++ b/windows/security/identity-protection/virtual-smart-cards/virtual-smart-card-understanding-and-evaluating.md @@ -11,17 +11,14 @@ ms.date: 11/06/2023 This article describes the virtual smart card technology and how it can fit into your authentication design. -Virtual smart card technology uses cryptographic keys that are stored on computers that have the Trusted Platform Module (TPM) installed. Virtual smart cards offer comparable security benefits to conventional smart cards by using two-factor authentication. The technology also offers more convenience for users and has a lower cost to deploy. By utilizing TPM devices that provide the same cryptographic capabilities as conventional smart cards, virtual smart cards accomplish the three key properties that are desired for smart cards: non-exportability, isolated cryptography, and anti-hammering. +Virtual smart card technology uses cryptographic keys that are stored on computers that have the Trusted Platform Module (TPM) installed. Virtual smart cards offer comparable security benefits to conventional smart cards by using two-factor authentication. The technology also offers more convenience for users and has a lower cost to deploy. By utilizing TPM devices that provide the same cryptographic capabilities as conventional smart cards, virtual smart cards accomplish the three key properties that are desired for smart cards: nonexportability, isolated cryptography, and anti-hammering. -Virtual smart cards are functionally similar to physical smart cards. They appear as always-inserted smart cards, and they can be used for authentication to external resources, protection of data by secure encryption, and integrity through reliable signing. Because TPM-enabled hardware is readily available and virtual smart cards can be easily deployed by using existing certificate enrollment methods, virtual smart cards can become a full replacement for other methods of strong authentication in a corporate setting of any scale. +Virtual smart cards are functionally similar to physical smart cards. They appear as always-inserted smart cards, and they can be used for authentication to external resources, protection of data by secure encryption, and integrity through reliable signing. Since TPM-enabled hardware is readily available and virtual smart cards can be deployed using existing certificate enrollment methods, virtual smart cards can become a replacement for other methods of strong authentication in a corporate setting of any scale. This topic contains the following sections: -- [Comparing virtual smart cards with physical smart cards](#comparing-virtual-smart-cards-with-physical-smart-cards): - Compares properties, functional aspects, security, and cost. - -- [Authentication design options](#authentication-design-options): - Describes how passwords, smart cards, and virtual smart cards can be used to reach authentication goals in your organization. +- [Comparing virtual smart cards with physical smart cards](#comparing-virtual-smart-cards-with-physical-smart-cards): compares properties, functional aspects, security, and cost. +- [Authentication design options](#authentication-design-options): describes how passwords, smart cards, and virtual smart cards can be used to reach authentication goals in your organization. ## Comparing virtual smart cards with physical smart cards @@ -33,13 +30,11 @@ All cryptographic operations occur in the secure, isolated environment of the TP Virtual smart cards maintain the three key properties of physical smart cards: -- **Non-exportability**: Because all private information on the virtual smart card is encrypted by using the TPM on the host computer, it can't be used on a different computer with a different TPM. Additionally, TPMs are designed to be tamper-resistant and non-exportable, so a malicious user can't reverse engineer an identical TPM or install the same TPM on a different computer. - For more information, see [Evaluate Virtual Smart Card Security](virtual-smart-card-evaluate-security.md). +- **Non-exportability**: Because all private information on the virtual smart card is encrypted by using the TPM on the host computer, it can't be used on a different computer with a different TPM. Additionally, TPMs are designed to be tamper-resistant and nonexportable, so a malicious user can't reverse engineer an identical TPM or install the same TPM on a different computer. For more information, see [Evaluate Virtual Smart Card Security](virtual-smart-card-evaluate-security.md). - **Isolated cryptography**: TPMs provide the same properties of isolated cryptography that are offered by physical smart cards, and this is utilized by virtual smart cards. Unencrypted copies of private keys are loaded only within the TPM and never into memory that is accessible by the operating system. All cryptographic operations with these private keys occur inside the TPM. -- **Anti-hammering**: If a user enters a PIN incorrectly, the virtual smart card responds by using the anti-hammering logic of the TPM, which rejects further attempts for a period of time instead of blocking the card. This is also known as lockout. - For more information, see [Evaluate Virtual Smart Card Security](virtual-smart-card-evaluate-security.md). +- **Anti-hammering**: If a user enters a PIN incorrectly, the virtual smart card responds by using the anti-hammering logic of the TPM, which rejects further attempts for a period of time instead of blocking the card. This is also known as lockout. For more information, see [Evaluate Virtual Smart Card Security](virtual-smart-card-evaluate-security.md). The following subsections compare the functionality, security, and cost of virtual smart cards and physical smart cards. @@ -47,41 +42,41 @@ The following subsections compare the functionality, security, and cost of virtu The virtual smart card system that was designed by Microsoft closely mimics the functionality of conventional smart cards. The most striking difference to the end user is that the virtual smart card is essentially a smart card that is always inserted into the computer. There's no method to export the user's virtual smart card for use on other computers, which adds to the security of virtual smart cards. If a user requires access to network resources on multiple computers, multiple virtual smart cards can be issued for that user. Additionally, a computer that is shared among multiple users can host multiple virtual smart cards for different users. -The basic user experience for a virtual smart card is as simple as using a password to access a network. Because the smart card is loaded by default, the user must simply enter the PIN that is tied to the card to gain access. Users are no longer required to carry cards and readers or to take physical action to use the card. +The basic user experience for a virtual smart card is as simple as using a password to access a network. Because the smart card is loaded by default, the user must enter the PIN that is tied to the card to gain access. Users are no longer required to carry cards and readers or to take physical action to use the card. -Additionally, although the anti-hammering functionality of the virtual smart card is equally secure to that of a physical smart card, virtual smart card users are never required to contact an administrator to unblock the card. Instead, they simply wait a period of time (depending on the TPM specifications) before they reattempt to enter the PIN. Alternatively, the administrator can reset the lockout by providing owner authentication data to the TPM on the host computer. +Additionally, although the anti-hammering functionality of the virtual smart card is equally secure to that of a physical smart card, virtual smart card users are never required to contact an administrator to unblock the card. Instead, they wait a period of time (depending on the TPM specifications) before they reattempt to enter the PIN. Alternatively, the administrator can reset the lockout by providing owner authentication data to the TPM on the host computer. ### Security Physical smart cards and virtual smart cards offer comparable levels of security. They both implement two-factor authentication for using network resources. However, they differ in certain aspects, including physical security and the practicality of an attack. Due to their compact and portable design, conventional smart cards are most frequently kept close to their intended user. They offer little opportunity for acquisition by a potential adversary, so any sort of interaction with the card is difficult without committing some variety of theft. -TPM virtual smart cards, however, reside on a user's computer that may frequently be left unattended, which provides an opportunity for a malicious user to hammer the TPM. Although virtual smart cards are fully protected from hammering (as are physical smart cards), this accessibility makes the logistics of an attack somewhat simpler. Additionally, the anti-hammering behavior of a TPM smart card differs in that it only presents a time delay in response to repeated PIN failures, as opposed to fully blocking the user. +TPM virtual smart cards, however, reside on a user's computer that may frequently be left unattended, which provides an opportunity for a malicious user to hammer the TPM. Although virtual smart cards are fully protected from hammering (as are physical smart cards), this accessibility makes the logistics of an attack simpler. Additionally, the anti-hammering behavior of a TPM smart card differs in that it only presents a time delay in response to repeated PIN failures, as opposed to fully blocking the user. -However, there are several advantages provided by virtual smart cards to mitigate these slight security deficits. Most importantly, a virtual smart card is much less likely to be lost. Virtual smart cards are integrated into computers and devices that the user already owns for other purposes and has incentive to keep safe. If the computer or device that hosts the virtual smart card is lost or stolen, a user will more immediately notice its loss than the loss of a physical smart card. When a computer or device is identified as lost, the user can notify the administrator of the system, who can revoke the certificate that is associated with the virtual smart card on that device. This precludes any future unauthorized access on that computer or device if the PIN for the virtual smart card is compromised. +However, there are several advantages provided by virtual smart cards to mitigate these slight security deficits. Most importantly, a virtual smart card is much less likely to be lost. Virtual smart cards are integrated into computers and devices that the user already owns for other purposes and has incentive to keep safe. If the computer or device that hosts the virtual smart card is lost or stolen, a user notices its loss quicker than the loss of a physical smart card. When a computer or device is identified as lost, the user can notify the administrator of the system, who can revoke the certificate that is associated with the virtual smart card on that device. This precludes any future unauthorized access on that computer or device if the PIN for the virtual smart card is compromised. ### Cost -If a company wants to deploy physical smart cards, they need to purchase smart cards and smart card readers for all employees. Although relatively inexpensive options can be found, options that ensure the three key properties of smart card security (most notably, non-exportability) are more expensive. If employees have computers with a built-in TPM, virtual smart cards can be deployed with no additional material costs. These computers and devices are relatively common in the market. +If a company wants to deploy physical smart cards, they need to purchase smart cards and smart card readers for all employees. Although relatively inexpensive options can be found, options that ensure the three key properties of smart card security (most notably, nonexportability) are more expensive. If employees have computers with a built-in TPM, virtual smart cards can be deployed with no additional material costs. These computers and devices are relatively common in the market. The maintenance cost of virtual smart cards is less than that for physical smart cards, which are easily lost, stolen, or broken from normal wear. TPM virtual smart cards are only lost or broken if the host computer or device is lost or broken, which in most cases is much less frequently. ### Comparison summary -| Physical Smart Cards | TPM virtual smart cards | -|---------------------|-------------------| -| Protects private keys by using the built-in cryptographic functionality of the card. | Protects private keys by using the cryptographic functionality of the TPM. | -| Stores private keys in isolated non-volatile memory on the card, which means that access to private keys is only from the card, and access is never allowed to the operating system. | Stores encrypted private keys on the hard drive. The encryption ensures that these keys can only be decrypted and used in the TPM, not in the accessible memory of the operating system. | -| Guarantees non-exportability through the card manufacturer, which includes isolating private information from operating system access. | Guarantees non-exportability through the TPM manufacturer, which includes the inability of an adversary to replicate or remove the TPM. | -| Performs and isolates cryptographic operations within the built-in capabilities of the card. | Performs and isolates cryptographic operations in the TPM of the user's computer or device. | -| Provides anti-hammering through the card. After a certain number of failed PIN entry attempts, the card blocks further access until administrative action is taken. | Provides anti-hammering through the TPM. Successive failed attempts increase the device lockout time (the time the user has to wait before trying again). This can be reset by an administrator. | -| Requires that users carry their smart card and smart card reader with them to access network resources. | Allows users to access their TPM-enabled computers or devices, and potentially access the network, without other equipment. | -| Enables credential portability by inserting the smart card into smart card readers that are attached to other computers. | Prevents exporting credentials from a given computer or device. However, virtual smart cards can be issued for the same user on multiple computers or devices by using additional certificates. | -| Enables multiple users to access network resources through the same computer by inserting their personal smart cards. | Enables multiple users to access network resources through the same computer or device by issuing a virtual smart card for each user on that computer or device. | -| Requires the user to carry the card, making it more difficult for an attacker to access the device and launch a hammering attempt. | Stores virtual smart card on the user's computer, which may be left unattended and allow a greater risk window for hammering attempts. | -| Provides a generally single-purpose device that is carried explicitly for the purpose of authentication. The smart card can be easily misplaced or forgotten. | Installs the virtual smart card on a device that has other purposes for the user, so the user has greater incentive to be responsible for the computer or device. | -| Alerts users that their card is lost or stolen only when they need to sign in and notice it's missing. | Installs the virtual smart card on a device that the user likely needs for other purposes, so users will notice its loss much more quickly. This reduces the associated risk window. | -| Requires companies to invest in smart cards and smart card readers for all employees. | Requires that companies ensure all employees have TPM-enabled computers, which are relatively common. | -| Enables using a smart card removal policy to affect system behavior when the smart card is removed. For example, the policy can dictate if the user's sign-in session is locked or terminated when the user removes the card. | Eliminates the necessity for a smart card removal policy because a TPM virtual smart card is always present and can't be removed from the computer. | +| Physical Smart Cards | TPM virtual smart cards | +|--|--| +| Protects private keys by using the built-in cryptographic functionality of the card. | Protects private keys by using the cryptographic functionality of the TPM. | +| Stores private keys in isolated non-volatile memory on the card, which means that access to private keys is only from the card, and access is never allowed to the operating system. | Stores encrypted private keys on the hard drive. The encryption ensures that these keys can only be decrypted and used in the TPM, not in the accessible memory of the operating system. | +| Guarantees nonexportability through the card manufacturer, which includes isolating private information from operating system access. | Guarantees nonexportability through the TPM manufacturer, which includes the inability of an adversary to replicate or remove the TPM. | +| Performs and isolates cryptographic operations within the built-in capabilities of the card. | Performs and isolates cryptographic operations in the TPM of the user's computer or device. | +| Provides anti-hammering through the card. After some failed PIN entry attempts, the card blocks further access until administrative action is taken. | Provides anti-hammering through the TPM. Successive failed attempts increase the device lockout time (the time the user has to wait before trying again). This can be reset by an administrator. | +| Requires that users carry their smart card and smart card reader with them to access network resources. | Allows users to access their TPM-enabled computers or devices, and potentially access the network, without other equipment. | +| Enables credential portability by inserting the smart card into smart card readers that are attached to other computers. | Prevents exporting credentials from a given computer or device. However, virtual smart cards can be issued for the same user on multiple computers or devices by using additional certificates. | +| Enables multiple users to access network resources through the same computer by inserting their personal smart cards. | Enables multiple users to access network resources through the same computer or device by issuing a virtual smart card for each user on that computer or device. | +| Requires the user to carry the card, making it more difficult for an attacker to access the device and launch a hammering attempt. | Stores virtual smart card on the user's computer, which might be left unattended and allow a greater risk window for hammering attempts. | +| Provides a generally single-purpose device that is carried explicitly for the purpose of authentication. The smart card can be easily misplaced or forgotten. | Installs the virtual smart card on a device that has other purposes for the user, so the user has greater incentive to be responsible for the computer or device. | +| Alerts users that their card is lost or stolen only when they need to sign in and notice it's missing. | Installs the virtual smart card on a device that the user likely needs for other purposes, so users will notice its loss much more quickly. This reduces the associated risk window. | +| Requires companies to invest in smart cards and smart card readers for all employees. | Requires that companies ensure all employees have TPM-enabled computers, which are relatively common. | +| Enables using a smart card removal policy to affect system behavior when the smart card is removed. For example, the policy can dictate if the user's sign-in session is locked or terminated when the user removes the card. | Eliminates the necessity for a smart card removal policy because a TPM virtual smart card is always present and can't be removed from the computer. | ## Authentication design options @@ -113,6 +108,6 @@ The additional security comes with added material and support costs. Traditional ### Virtual smart cards -Virtual smart cards emulate the functionality of traditional smart cards. Instead of requiring the purchase of additional hardware, virtual smart cards utilize technology that users already own and are more likely to always have with them. Theoretically, any device that can provide the three key properties of smart cards (non-exportability, isolated cryptography, and anti-hammering) can be commissioned as a virtual smart card. The virtual smart card platform is limited to the use of the Trusted Platform Module (TPM) chip, which is on most modern devices. +Virtual smart cards emulate the functionality of traditional smart cards. Instead of requiring the purchase of additional hardware, virtual smart cards utilize technology that users already own and are more likely to always have with them. Theoretically, any device that can provide the three key properties of smart cards (nonexportability, isolated cryptography, and anti-hammering) can be commissioned as a virtual smart card. The virtual smart card platform is limited to the use of the Trusted Platform Module (TPM) chip, which is on most modern devices. -Virtual smart cards that utilize a TPM provide the three main security principles of traditional smart cards: non-exportability, isolated cryptography, and anti-hammering. Virtual smart cards are less expensive to implement and more convenient for users. Since many corporate computers already have a built-in TPM, there's no cost associated with purchasing new hardware. The user's possession of a computer or device is equivalent to the possession of a smart card, and a user's identity can't be assumed from any other computer or device without administrative provisioning of further credentials. Thus, two-factor authentication is achieved because the user must have a computer that is set up with a virtual smart card and know the PIN to use the virtual smart card. +Virtual smart cards that utilize a TPM provide the three main security principles of traditional smart cards: nonexportability, isolated cryptography, and anti-hammering. Virtual smart cards are less expensive to implement and more convenient for users. Since many corporate computers already have a built-in TPM, there's no cost associated with purchasing new hardware. The user's possession of a computer or device is equivalent to the possession of a smart card, and a user's identity can't be assumed from any other computer or device without administrative provisioning of further credentials. Thus, two-factor authentication is achieved because the user must have a computer that is set up with a virtual smart card and know the PIN to use the virtual smart card.