mirror of
https://github.com/MicrosoftDocs/windows-itpro-docs.git
synced 2025-05-14 06:17:22 +00:00
acrolinx
This commit is contained in:
parent
1704aedea2
commit
045dfde0ad
@ -78,7 +78,7 @@ sections:
|
||||
Windows Hello biometrics template database file is created on the device only when a user is enrolled into Windows Hello biometrics-based authentication. Your workplace or IT administrator may have turned certain authentication functionality, however, it is always your choice if you want to use Windows Hello or an alternative method, like a PIN. Users can check their current enrollment into Windows Hello biometrics by going to sign-in options on their device. Go to **Start > Settings > Accounts > Sign-in** options. If you don't see Windows Hello in Sign-in options, then it may not be available for your device or blocked by admin via policy. Admins can request users to enroll into Windows Hello during Autopilot or during the initial setup of the device. Admins can disallow users to enroll into biometrics via Windows Hello for Business policy configurations. However, when allowed via policy configurations, enrollment into Windows Hello biometrics is always optional for users.
|
||||
- question: When is Windows Hello biometrics database file deleted? How can a user be unenrolled from Windows Hello face or fingerprint authentication?
|
||||
answer: |
|
||||
To remove Windows Hello and any associated biometric identification data from the device, user can go to **Start > Settings > Accounts > Sign-in options**. Select the Windows Hello biometrics authentication method you want to remove, and then select **Remove**. This will u-enroll the user from Windows Hello biometrics authentication and will also delete the associated biometrics template database file. For more details, see [Windows sign-in options and account protection (microsoft.com)](https://support.microsoft.com/en-us/windows/windows-sign-in-options-and-account-protection-7b34d4cf-794f-f6bd-ddcc-e73cdf1a6fbf#bkmk_helloandprivacy).
|
||||
To remove Windows Hello and any associated biometric identification data from the device, user can go to **Start > Settings > Accounts > Sign-in options**. Select the Windows Hello biometrics authentication method you want to remove, and then select **Remove**. This will u-enroll the user from Windows Hello biometrics authentication and will also delete the associated biometrics template database file. For more details, see [Windows sign-in options and account protection (microsoft.com)](https://support.microsoft.com/windows/windows-sign-in-options-and-account-protection-7b34d4cf-794f-f6bd-ddcc-e73cdf1a6fbf#bkmk_helloandprivacy).
|
||||
|
||||
- name: Management and operations
|
||||
questions:
|
||||
@ -117,7 +117,7 @@ sections:
|
||||
- Data about whether people sign in with their face, iris, fingerprint, or PIN
|
||||
- The number of times they use it
|
||||
- Whether it works or not
|
||||
All this is valuable information that helps Microsoft building a better product. The data is pseudonymized, does not include biometric information, and is encrypted before it is transmitted to Microsoft. You can choose to stop sending diagnostic data to Microsoft at any time. [Learn more about diagnostic data in Windows](https://support.microsoft.com/en-us/windows/diagnostics-feedback-and-privacy-in-windows-28808a2b-a31b-dd73-dcd3-4559a5199319).
|
||||
All this is valuable information that helps Microsoft building a better product. The data is pseudonymized, does not include biometric information, and is encrypted before it is transmitted to Microsoft. You can choose to stop sending diagnostic data to Microsoft at any time. [Learn more about diagnostic data in Windows](https://support.microsoft.com/windows/diagnostics-feedback-and-privacy-in-windows-28808a2b-a31b-dd73-dcd3-4559a5199319).
|
||||
- question: Can I disable the PIN while using Windows Hello for Business?
|
||||
answer: |
|
||||
No. The movement away from passwords is accomplished by gradually reducing the use of the password. In situations where you can't authenticate by using biometrics, you need a fallback mechanism that isn't a password. The PIN is the fallback mechanism. Disabling or hiding the PIN credential provider will disable the use of biometrics.
|
||||
|
@ -1,7 +1,7 @@
|
||||
---
|
||||
title: Deploy Virtual Smart Cards (Windows 10)
|
||||
description: This topic for the IT professional discusses the factors to consider when you deploy a virtual smart card authentication solution.
|
||||
ms.topic: article
|
||||
title: Deploy Virtual Smart Cards
|
||||
description: Learn about what to consider when deploying a virtual smart card authentication solution
|
||||
ms.topic: conceptual
|
||||
ms.date: 02/22/2023
|
||||
appliesto:
|
||||
- ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 10 and later</a>
|
||||
@ -12,13 +12,13 @@ appliesto:
|
||||
|
||||
[!INCLUDE [virtual-smart-card-deprecation-notice](../../includes/virtual-smart-card-deprecation-notice.md)]
|
||||
|
||||
This topic for the IT professional discusses the factors to consider when you deploy a virtual smart card authentication solution.
|
||||
This article discusses the factors to consider when you deploy a virtual smart card authentication solution.
|
||||
|
||||
Traditional identity devices, such as physical smart cards, follow a predictable lifecycle in any deployment, as shown in the following diagram.
|
||||
|
||||

|
||||
|
||||
Physical devices are created by a dedicated manufacturer and then purchased by the corporation that will ultimately deploy it. The device passes through the personalization stage, where its unique properties are set. In smart cards, these properties are the administrator key, Personal Identification Number (PIN), PIN Unlock Key (PUK), and its physical appearance. To provision the device, it is loaded with the required certificates, such as a sign-in certificate. After you provision the device, it is ready for use. The device must simply be maintained. For example, you must replace cards when they're lost or stolen and reset PINs when users forget them. Finally, you'll retire devices when they exceed their intended lifetime or when employees leave the company.
|
||||
A device manufacturer creates physical devices, and then an organization purchase and deploy them. The device passes through the personalization stage, where its unique properties are set. In smart cards, these properties are the *administrator key*, *Personal Identification Number (PIN)*, *PIN Unlock Key (PUK)*, and its physical appearance. During the device provisioning phase, the required certificates are installed, such as a sign-in certificate. After you provision the device, it's ready for use. You'll maintain the device, for example you may replace cards when they're lost or stolen, or reset PINs when users forget them. Finally, you'll retire devices when they exceed their intended lifetime or when employees leave the company.
|
||||
|
||||
This topic contains information about the following phases in a virtual smart card lifecycle:
|
||||
|
||||
@ -39,27 +39,28 @@ The TPM Provisioning Wizard, which is launched from the **TPM Management Console
|
||||
When you create virtual smart cards, consider the following actions in the TPM:
|
||||
|
||||
- **Enable and Activate**: TPMs are built into many devices. In some cases, the TPM must be enabled and activated through the BIOS
|
||||
- **Take ownership**: When you provision the TPM, you set an owner password for managing the TPM in the future, and you establish the *storage root key*. To provide anti-hammering protection for virtual smart cards, the user or a domain administrator must be able to reset the TPM owner password. For corporate use of TPM virtual smart cards, it's recommended that the domain administrator restricts access to the TPM owner password by storing it in Active Directory, and not in the local registry. When TPM ownership is set, the TPM must be cleared and reinitialized
|
||||
- **Take ownership**: When you provision the TPM, you set an owner password for managing the TPM in the future, and you establish the *storage root key*. To provide anti-hammering protection for virtual smart cards, the user or a domain administrator must be able to reset the TPM owner password. For corporate use of TPM virtual smart cards, the domain administrator should restrict access to the TPM owner password by storing it in Active Directory, and not in the local registry. When TPM ownership is set, you must clear and reinitialize the TPM
|
||||
- **Manage**: You can manage ownership of a virtual smart card by changing the owner password, and you can manage anti-hammering logic by resetting the lockout time
|
||||
|
||||
A TPM might operate in reduced functionality mode. This could occur, for example, if the operating system cannot determine if the owner password is available to the user. In those cases, the TPM can be used to create a virtual smart card, but it is strongly recommended to bring the TPM to a fully ready state so that any unexpected circumstances will not leave the user blocked from using the computer.
|
||||
A TPM might operate in reduced functionality mode, which may occur if the operating system can't determine if the owner password is available to the user. During reduce functionality mode, you can use the TPM to create a virtual smart card, but it's preferable to bring the TPM to a fully ready state so that any unexpected circumstances won't leave the user blocked from using the device.
|
||||
|
||||
Those smart card deployment management tools that require a status check of a TPM before attempting to create a TPM virtual smart card can do so using the TPM WMI interface.
|
||||
|
||||
Depending on the setup of the computer that is designated for installing TPM virtual smart cards, it might be necessary to provision the TPM before continuing with the virtual smart card deployment. For more information about provisioning, see [Use Virtual Smart Cards](virtual-smart-card-use-virtual-smart-cards.md).
|
||||
Depending on the setup of the device designated for installing TPM virtual smart cards, it may be necessary to provision the TPM before continuing with the virtual smart card deployment. For more information about provisioning, see [Use Virtual Smart Cards](virtual-smart-card-use-virtual-smart-cards.md).
|
||||
|
||||
For more information about managing TPMs by using built-in tools, see Trusted Platform Module Services Group Policy Settings.
|
||||
|
||||
### Creation
|
||||
|
||||
A TPM virtual smart card simulates a physical smart card, and it uses the TPM to provide the same functionality as physical smart card hardware. A virtual smart card appears within the operating system as a physical smart card that is always inserted. Supported versions of the Windows operating system present a virtual smart card reader and virtual smart card to applications with the same interface as physical smart cards, but messages to and from the virtual smart card are translated to TPM commands. This process ensures the integrity of the virtual smart card through the three properties of smart card security:
|
||||
A TPM virtual smart card simulates a physical smart card, using the TPM to provide the same functionality as physical smart card hardware.\
|
||||
A virtual smart card appears within the operating system as a physical smart card that is always inserted. Windows presents a *virtual smart card reader* and a *virtual smart card* to applications using the same interface as physical smart cards. The messages to and from the virtual smart card are translated to TPM commands, ensuring the integrity of the virtual smart card through the three properties of smart card security:
|
||||
|
||||
- **Non-exportability**: Because all private information on the virtual smart card is encrypted by using the TPM on the host computer, it cannot 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 cannot reverse engineer an identical TPM or install the same TPM on a different computer.
|
||||
- **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).
|
||||
|
||||
- **Isolated cryptography**: TPMs provide the same properties of isolated cryptography that is 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.
|
||||
- **Isolated cryptography**: TPMs provide the same properties of isolated cryptography that is offered by physical smart cards, which 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.
|
||||
- **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 some time instead of blocking the card. This is also known as lockout.
|
||||
For more information, see [Blocked virtual smart card](#blocked-virtual-smart-card) and [Evaluate Virtual Smart Card Security](virtual-smart-card-evaluate-security.md).
|
||||
|
||||
There are several options for creating virtual smart cards, depending on the size of the deployment and budget of the organization. The lowest cost option is using `tpmvscmgr.exe` to create cards individually on users' computers. Alternatively, a virtual smart card management solution can be purchased to more easily accomplish virtual smart card creation on a larger scale and aid in further phases of deployment. Virtual smart cards can be created on computers that are to be provisioned for an employee or on those that are already in an employee's possession. In either approach, there should be some central control over personalization and provisioning. If a computer is intended for use by multiple employees, multiple virtual smart cards can be created on a computer.
|
||||
@ -68,23 +69,23 @@ For information about the TPM Virtual Smart Card command-line tool, see [Tpmvscm
|
||||
|
||||
### Personalization
|
||||
|
||||
During virtual smart card personalization, the values for the administrator key, PIN, and PUK are assigned. As with a physical card, knowing the administrator key is important for resetting the PIN or for deleting the card in the future. (If a PUK is set, the administrator key can no longer be used to reset the PIN.)
|
||||
During virtual smart card personalization, the values for the administrator key, PIN, and PUK are assigned. As with a physical card, knowing the administrator key is important for resetting the PIN or for deleting the card in the future. (If you set a PUK, you can't use the administrator key to reset the PIN.)
|
||||
|
||||
Because the administrator key is critical to the security of the card, it is important to consider the deployment environment and decide on the proper administrator key setting strategy. Options for these strategies include:
|
||||
Because the administrator key is critical to the security of the card, it's important to consider the deployment environment and decide on the proper administrator key setting strategy. Options for these strategies include:
|
||||
|
||||
- **Uniform**: Administrator keys for all the virtual smart cards that are deployed in the organization are the same. Although this makes the maintenance infrastructure easy (only one key needs to be stored), it is highly insecure. This strategy might be sufficient for very small organizations, but if the administrator key is compromised, all virtual smart cards that use this key must be reissued.
|
||||
- **Uniform**: Administrator keys for all the virtual smart cards deployed in the organization are the same. Although using the same key makes the maintenance infrastructure easy (only one key needs to be stored), it's highly insecure. This strategy might be sufficient for small organizations, but if the administrator key is compromised, all virtual smart cards that use the key must be reissued.
|
||||
|
||||
- **Random, not stored**: Administrator keys are assigned randomly for all virtual smart cards, and they are not recorded. This is a valid option if the deployment administrators do not require the ability to reset PINs, and instead prefer to delete and reissue virtual smart cards. This could also be a viable strategy if the administrator prefers to set PUK values for the virtual smart cards and then use this value to reset PINs, if necessary.
|
||||
- **Random, not stored**: Administrator keys are assigned randomly for all virtual smart cards, and they aren't recorded. This is a valid option if the deployment administrators don't require the ability to reset PINs, and instead prefer to delete and reissue virtual smart cards. This is a viable strategy if the administrator prefers to set PUK values for the virtual smart cards and then use this value to reset PINs, if necessary.
|
||||
|
||||
- **Random, stored**: Administrator keys are assigned randomly and stored in a central location. Each card's security is independent of the others. This is secure on a large scale unless the administrator key database is compromised.
|
||||
- **Random, stored**: you assign the administrator keys randomly, storing them in a central location. Each card's security is independent of the others. This is a secure strategy on a large scale, unless the administrator key database is compromised.
|
||||
|
||||
- **Deterministic**: Administrator keys are the result of some function or known information. For example, the user ID could be used to randomly generate data that can be further processed through a symmetric encryption algorithm by using a secret. This administrator key can be similarly regenerated when needed, and it does not need to be stored. The security of this method relies on the security of the secret used.
|
||||
- **Deterministic**: Administrator keys are the result of some function or known information. For example, the user ID could be used to randomly generate data that can be further processed through a symmetric encryption algorithm by using a secret. This administrator key can be similarly regenerated when needed, and it doesn't need to be stored. The security of this method relies on the security of the secret used.
|
||||
|
||||
Although the PUK and the administrator key methodologies provide unlocking and resetting functionality, they do so in different ways. The PUK is a PIN that is simply entered on the computer to enable a user PIN reset.
|
||||
Although the PUK and the administrator key methodologies provide unlocking and resetting functionality, they do so in different ways. The PUK is a PIN that is entered on the computer to enable a user PIN reset.
|
||||
|
||||
The administrator key methodology takes a challenge-response approach. The card provides a set of random data after users verify their identity to the deployment administrator. The administrator then encrypts the data with the administrator key and gives the encrypted data back to the user. If the encrypted data matches that produced by the card during verification, the card will allow PIN reset. Because the administrator key is never accessible by anyone other than the deployment administrator, it cannot be intercepted or recorded by any other party (including employees). This provides significant security benefits beyond using a PUK, an important consideration during the personalization process.
|
||||
The administrator key methodology takes a challenge-response approach. The card provides a set of random data after users verify their identity to the deployment administrator. The administrator then encrypts the data with the administrator key and gives the encrypted data back to the user. If the encrypted data matches that produced by the card during verification, the card will allow PIN reset. Because the administrator key is never accessible by anyone other than the deployment administrator, it can't be intercepted or recorded by any other party (including employees). This provides significant security benefits beyond using a PUK, an important consideration during the personalization process.
|
||||
|
||||
TPM virtual smart cards can be personalized on an individual basis when they are created with the Tpmvscmgr command-line tool. Or organizations can purchase a management solution that can incorporate personalization into an automated routine. An additional advantage of such a solution is the automated creation of administrator keys. Tpmvscmgr.exe allows users to create their own administrator keys, which can be detrimental to the security of the virtual smart cards.
|
||||
TPM virtual smart cards can be personalized on an individual basis when they're created with the Tpmvscmgr command-line tool. Or organizations can purchase a management solution that can incorporate personalization into an automated routine. An another advantage of such a solution is the automated creation of administrator keys. Tpmvscmgr.exe allows users to create their own administrator keys, which can be detrimental to the security of the virtual smart cards.
|
||||
|
||||
## Provision virtual smart cards
|
||||
|
||||
@ -92,37 +93,35 @@ Provisioning is the process of loading specific credentials onto a TPM virtual s
|
||||
|
||||
A high-assurance level of secure provisioning requires absolute certainty about the identity of the individual who is receiving the certificate. Therefore, one method of high-assurance provisioning is utilizing previously provisioned strong credentials, such as a physical smart card, to validate identity during provisioning. In-person proofing at enrollment stations is another option, because an individual can easily and securely prove his or her identity with a passport or driver's license, although this can become infeasible on a larger scale. To achieve a similar level of assurance, a large organization can implement an "enroll-on-behalf-of" strategy, in which employees are enrolled with their credentials by a superior who can personally verify their identities. This creates a chain of trust that ensures individuals are checked in person against their proposed identities, but without the administrative strain of provisioning all virtual smart cards from a single central enrollment station.
|
||||
|
||||
For deployments in which a high-assurance level is not a primary concern, you can use self-service solutions. These can include using an online portal to obtain credentials or simply enrolling for certificates by using Certificate Manager, depending on the deployment. Consider that virtual smart card authentication is only as strong as the method of provisioning. For example, if weak domain credentials (such as a password alone) are used to request the authentication certificate, virtual smart card authentication will be equivalent to using only the password, and the benefits of two-factor authentication are lost.
|
||||
For deployments in which a high-assurance level isn't a primary concern, you can use self-service solutions. These can include using an online portal to obtain credentials or simply enrolling for certificates by using Certificate Manager, depending on the deployment. Consider that virtual smart card authentication is only as strong as the method of provisioning. For example, if weak domain credentials (such as a password alone) are used to request the authentication certificate, virtual smart card authentication will be equivalent to using only the password, and the benefits of two-factor authentication are lost.
|
||||
|
||||
For information about using Certificate Manager to configure virtual smart cards, see [Get Started with Virtual Smart Cards: Walkthrough Guide](virtual-smart-card-get-started.md).
|
||||
|
||||
High-assurance and self-service solutions approach virtual smart card provisioning by assuming that the user's computer has been issued prior to the virtual smart card deployment, but this is not always the case. If virtual smart cards are being deployed with new computers, they can be created, personalized, and provisioned on the computer before the user has contact with that computer.
|
||||
High-assurance and self-service solutions approach virtual smart card provisioning by assuming that the user's computer has been issued prior to the virtual smart card deployment, but this isn't always the case. If virtual smart cards are being deployed with new computers, they can be created, personalized, and provisioned on the computer before the user has contact with that computer.
|
||||
|
||||
In this situation, provisioning becomes relatively simple, but identity checks must be put in place to ensure that the recipient of the computer is the individual who was expected during provisioning. This can be accomplished by requiring the employee to set the initial PIN under the supervision of the deployment administrator or manager.
|
||||
|
||||
When you are provisioning your computers, you should also consider the longevity of credentials that are supplied for virtual smart cards. This choice must be based on the risk threshold of the organization. Although longer lived credentials are more convenient, they are also more likely to become compromised during their lifetime. To decide on the appropriate lifetime for credentials, the deployment strategy must take into account the vulnerability of their cryptography (how long it could take to crack the credentials), and the likelihood of attack.
|
||||
When you're provisioning your computers, you should also consider the longevity of credentials that are supplied for virtual smart cards. This choice must be based on the risk threshold of the organization. Although longer lived credentials are more convenient, they're also more likely to become compromised during their lifetime. To decide on the appropriate lifetime for credentials, the deployment strategy must take into account the vulnerability of their cryptography (how long it could take to crack the credentials), and the likelihood of attack.
|
||||
|
||||
If a virtual smart card is compromised, administrators should be able to revoke the associated credentials, like they would with a lost or stolen laptop. This requires a record of which credentials match which user and computer, which is functionality that does not exist natively in Windows. Deployment administrators might want to consider add-on solutions to maintain such a record.
|
||||
For compromised virtual smart cards, administrators should be able to revoke the associated credentials, like they would with a lost or stolen laptop. Revoking credentials requires a record of which credentials match which user and device, but the functionality doesn't natively exist in Windows. Deployment administrators might want to consider add-on solutions to maintain a record.
|
||||
|
||||
### Virtual smart cards on consumer devices used for corporate access
|
||||
|
||||
There are techniques that allow employees to provision virtual smart cards and enroll for certificates that can be used to authenticate the users. This is useful when employees attempt to access corporate resources from devices that are not joined to the corporate domain. Those devices can be further defined to not allow users to download and run applications from sources other than the Windows Store (for example, devices running Windows RT).
|
||||
There are techniques that allow employees to provision virtual smart cards and enroll for certificates that can be used to authenticate the users. This is useful when employees attempt to access corporate resources from devices that aren't joined to the corporate domain. Those devices can be further defined to not allow users to download and run applications from sources other than the Microsoft Store.
|
||||
|
||||
You can use APIs that were introduced in Windows Server 2012 R2 and Windows 8.1 to build Windows Store apps that you can use to manage the full lifecycle of virtual smart cards. For more information, see [Create and delete virtual smart cards programmatically](virtual-smart-card-use-virtual-smart-cards.md#create-and-delete-virtual-smart-cards-programmatically).
|
||||
You can use APIs to build Microsoft Store apps that you can use to manage the full lifecycle of virtual smart cards. For more information, see [Create and delete virtual smart cards programmatically](virtual-smart-card-use-virtual-smart-cards.md#create-and-delete-virtual-smart-cards-programmatically).
|
||||
|
||||
#### TPM ownerAuth in the registry
|
||||
|
||||
When a device or computer is not joined to a domain, the TPM ownerAuth is stored in the registry under HKEY\_LOCAL\_MACHINE. This exposes some threats. Most of the threat vectors are protected by BitLocker, but threats that are not protected include:
|
||||
When a device or computer isn't joined to a domain, the TPM ownerAuth is stored in the registry under HKEY\_LOCAL\_MACHINE. This exposes some threats. Most of the threat vectors are protected by BitLocker, but threats that aren't protected include:
|
||||
|
||||
- A malicious user possesses a device that has an active local sign-in session before the device locks. The malicious user could attempt a brute-force attack on the virtual smart card PIN, and then access the corporate secrets.
|
||||
|
||||
- A malicious user possesses a device that has an active virtual private network (VPN) session. The device is then compromised.
|
||||
|
||||
The proposed mitigation for the previous scenarios is to use Exchange ActiveSync (EAS) policies to reduce the automatic lockout time from five minutes to 30 seconds of inactivity. Policies for automatic lockout can be set while provisioning virtual smart cards. If an organization wants more security, they can also configure a setting to remove the ownerAuth from the local device.
|
||||
The proposed mitigation for the previous scenarios is to use Exchange ActiveSync (EAS) policies to reduce the automatic lockout time from five minutes to 30 seconds of inactivity. You can set policies for automatic lockout while provisioning virtual smart cards. If an organization wants more security, they can also configure a setting to remove the ownerAuth from the local device.
|
||||
|
||||
For configuration information about the TPM ownerAuth registry key, see the Group Policy setting Configure the level of TPM owner authorization information available to the operating system.
|
||||
|
||||
<!-- Replace following link if a newer one becomes available for similar content. -->
|
||||
For configuration information about the TPM ownerAuth registry key, see the Group Policy setting **Configure the level of TPM owner authorization information** available to the operating system.
|
||||
|
||||
For information about EAS policies, see [Exchange ActiveSync Policy Engine Overview](/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/dn282287(v=ws.11)).
|
||||
|
||||
@ -130,12 +129,10 @@ For information about EAS policies, see [Exchange ActiveSync Policy Engine Overv
|
||||
|
||||
The following table describes the important differences between managed and unmanaged virtual smart cards that exist on consumer devices:
|
||||
|
||||
<!-- Check on whether the middle column header is correct - it probably should be [Managed cards](#managed-cards) -->
|
||||
|
||||
| Operation | [Managed and unmanaged cards](virtual-smart-card-deploy-virtual-smart-cards.md#managed-and-unmanaged-cards) | [Unmanaged cards](virtual-smart-card-deploy-virtual-smart-cards.md#unmanaged-cards) |
|
||||
|-----------------------------------------|--------------|----|
|
||||
| Reset PIN when the user forgets the PIN | Yes | No, the card has to be deleted and created again. |
|
||||
| Allow user to change the PIN | Yes | No, the card has to be deleted and created again. |
|
||||
| Operation | [Managed and unmanaged cards](virtual-smart-card-deploy-virtual-smart-cards.md#managed-and-unmanaged-cards) | [Unmanaged cards](virtual-smart-card-deploy-virtual-smart-cards.md#unmanaged-cards) |
|
||||
|---|---|---|
|
||||
| Reset PIN when the user forgets the PIN | Yes | No. Delete and recreate the card. |
|
||||
| Allow user to change the PIN | Yes | No. Delete and recreate the card. |
|
||||
|
||||
## Managed cards
|
||||
|
||||
@ -143,7 +140,7 @@ A managed virtual smart card can be serviced by the IT administrator or another
|
||||
|
||||
### Managed card creation
|
||||
|
||||
A user can create blank virtual smart card by using the Tpmvscmgr command-line tool, which is a built-in tool that is run with administrative credentials through an elevated command prompt. This virtual smart card needs to be created with well-known parameters (such as default values), and it should be left unformatted (specifically, the **/generate** option should not be specified).
|
||||
A user can create blank virtual smart card by using the *Tpmvscmgr* command-line tool, which is a built-in tool executed with administrative credentials through an elevated command prompt. The virtual smart card must be created with well-known parameters (such as default values), and it should be left unformatted (specifically, the **/generate** option shouldn't be specified).
|
||||
|
||||
The following command creates a virtual smart card that can later be managed by a smart card management tool launched from another computer (as explained in the next section):
|
||||
|
||||
@ -153,7 +150,7 @@ Alternatively, instead of using a default administrator key, a user can enter an
|
||||
|
||||
`tpmvscmgr.exe create /name "VirtualSmartCardForCorpAccess" /AdminKey PROMPT /PIN PROMPT`
|
||||
|
||||
In either case, the card management system needs to be aware of the initial administrator key that is used so that it can take ownership of the virtual smart card and change the administrator key to a value that is only accessible through the card management tool operated by the IT administrator. For example, when the default value is used, the administrator key is set to:
|
||||
In either case, the card management system needs to be aware of the initial administrator key. The requirement is so that the card management system can take ownership of the virtual smart card and change the administrator key to a value that is only accessible through the card management tool operated by the IT administrator. For example, when you use the default, the administrator key is set to:
|
||||
|
||||
`10203040506070801020304050607080102030405060708`
|
||||
|
||||
@ -171,7 +168,7 @@ Similar to physical smart cards, virtual smart cards require certificate enrollm
|
||||
|
||||
#### Certificate issuance
|
||||
|
||||
Users can enroll for certificates from within a remote desktop session that is established to provision the card. This process can also be managed by the smart card management tool that the user runs through the remote desktop connection. This model works for deployments that require the user to sign a request for enrollment by using a physical smart card. The driver for the physical smart card does not need to be installed on the client computer if it is installed on the remote computer. This is made possible by smart card redirection functionality that was introduced in Windows Server 2003, which ensures that smart cards that are connected to the client computer are available for use during a remote session.
|
||||
Users can enroll for certificates from within a remote desktop session that is established to provision the card. This process can also be managed by the smart card management tool that the user runs through the remote desktop connection. This model works for deployments that require the user to sign a request for enrollment by using a physical smart card. The driver for the physical smart card doesn't need to be installed on the client computer if it's installed on the remote computer. This is made possible by smart card redirection functionality that was introduced in Windows Server 2003, which ensures that smart cards that are connected to the client computer are available for use during a remote session.
|
||||
|
||||
Alternatively, without establishing a remote desktop connection, users can enroll for certificates from the Certificate Management console (certmgr.msc) on a client computer. Users can also create a request and submit it to a server from within a custom certificate enrollment application (for example, a registration authority) that has controlled access to the certification authority (CA). This requires specific enterprise configuration and deployments for Certificate Enrollment Policies (CEP) and Certificate Enrollment Services (CES).
|
||||
|
||||
@ -179,11 +176,11 @@ Alternatively, without establishing a remote desktop connection, users can enrol
|
||||
|
||||
You can renew certificates through remote desktop connections, certificate enrollment policies, or certificate enrollment services. Renewal requirements could be different from the initial issuance requirements, based on the renewal policy.
|
||||
|
||||
Certificate revocation requires careful planning. When information about the certificate to be revoked is reliably available, the specific certificate can be easily revoked. When information about the certificate to be revoked is not easy to determine, all certificates that are issued to the user under the policy that was used to issue the certificate might need to be revoked. For example, this could occur if an employee reports a lost or compromised device, and information that associates the device with a certificate is not available.
|
||||
Certificate revocation requires careful planning. When information about the certificate to be revoked is reliably available, the specific certificate can be easily revoked. When information about the certificate to be revoked isn't easy to determine, all certificates that are issued to the user under the policy that was used to issue the certificate might need to be revoked. For example, this could occur if an employee reports a lost or compromised device, and information that associates the device with a certificate isn't available.
|
||||
|
||||
## Unmanaged cards
|
||||
|
||||
Unmanaged virtual smart cards are not serviceable by an IT administrator. Unmanaged cards might be suitable if an organzation does not have an elaborate smart card deployment management tool and using remote desktop connections to manage the card is not desirable. Because unmanaged cards are not serviceable by the IT administrator, when a user needs help with a virtual smart card (for example, resetting or unlocking a PIN), the only option available to the user is to delete the card and create it again. This results in loss of the user's credentials and he or she must re-enroll.
|
||||
Unmanaged virtual smart cards aren't serviceable by an IT administrator. Unmanaged cards might be suitable if an organization doesn't have an elaborate smart card deployment management tool and using remote desktop connections to manage the card isn't desirable. Because unmanaged cards aren't serviceable by the IT administrator, when a user needs help with a virtual smart card (for example, resetting or unlocking a PIN), the only option available to the user is to delete the card and create it again. This results in loss of the user's credentials and he or she must re-enroll.
|
||||
|
||||
### Unmanaged card creation
|
||||
|
||||
@ -211,7 +208,7 @@ Another option is to have the user access an enrollment portal that is available
|
||||
|
||||
#### Signing the request with another certificate
|
||||
|
||||
You can provide users with a short-term certificate through a Personal Information Exchange (.pfx) file. You can generate the .pfx file by initiating a request from a domain-joined computer. Additional policy constraints can be enforced on the .pfx file to assert the identity of the user.
|
||||
You can provide users with a short-term certificate through a Personal Information Exchange (.pfx) file. You can generate the .pfx file by initiating a request from a domain-joined computer. You can enforce other policy constraints on the .pfx file to assert the identity of the user.
|
||||
|
||||
The user can import the certificate into the **MY** store (which is the user's certificate store). And your organization can present the user with a script that can be used to sign the request for the short-term certificate and to request a virtual smart card.
|
||||
|
||||
@ -225,13 +222,13 @@ For deployments that require users to use a physical smart card to sign the cert
|
||||
|
||||
#### Using one-time password for enrollment
|
||||
|
||||
Another option to ensure that users are strongly authenticated before virtual smart card certificates are issued is to send a user a one-time password through SMS, email, or phone. The user then types the one-time password during the certificate enrollment from an application or a script on a desktop that invokes built-in command-line tools.
|
||||
Another option to ensure that users is strongly authenticated before virtual smart card certificates are issued, is to send a user a one-time password through SMS, email, or phone. The user then types the one-time password during the certificate enrollment from an application or a script on a desktop that invokes built-in command-line tools.
|
||||
|
||||
#### Certificate lifecycle management
|
||||
|
||||
Certificate renewal can be done from the same tools that are used for the initial certificate enrollment. Certificate enrollment policies and certificate enrollment services can also be used to perform automatic renewal.
|
||||
|
||||
Certificate revocation requires careful planning. When information about the certificate to be revoked is reliably available, the specific certificate can be easily revoked. When information about the certificate to be revoked is not easy to determine, all certificates that are issued to the user under the policy that was used to issue the certificate might need to be revoked. For example, this could occur if an employee reports a lost or compromised device, and information that associates the device with a certificate is not available.
|
||||
Certificate revocation requires careful planning. When information about the certificate to be revoked is reliably available, the specific certificate can be easily revoked. When information about the certificate to be revoked isn't easy to determine, all certificates issued to the user under the policy that was used to issue the certificate might need to be revoked. For example, if an employee reports a lost or compromised device, and information that associates the device with a certificate isn't available.
|
||||
|
||||
## Maintain virtual smart cards
|
||||
|
||||
@ -245,9 +242,9 @@ When renewing with a previously used key, no extra steps are required because a
|
||||
|
||||
**Lockout reset**: A frequent precursor to resetting a PIN is the necessity of resetting the TPM lockout time because the TPM anti-hammering logic will be engaged with multiple PIN entry failures for a virtual smart card. This is currently device specific.
|
||||
|
||||
**Retiring cards**: The final aspect of virtual smart card management is retiring cards when they are no longer needed. When an employee leaves the company, it is desirable to revoke domain access. Revoking sign-in credentials from the certification authority (CA) accomplishes this goal.
|
||||
**Retiring cards**: The final aspect of virtual smart card management is retiring cards when they're no longer needed. When an employee leaves the company, it's desirable to revoke domain access. Revoking sign-in credentials from the certification authority (CA) accomplishes this goal.
|
||||
|
||||
The card should be reissued if the same computer is used by other employees without reinstalling the operating system. Reusing the former card can allow the former employee to change the PIN after leaving the organization, and then hijack certificates that belong to the new user to obtain unauthorized domain access. However, if the employee takes the virtual smart card-enabled computer, it is only necessary to revoke the certificates that are stored on the virtual smart card.
|
||||
The card should be reissued if the same computer is used by other employees without reinstalling the operating system. Reusing the former card can allow the former employee to change the PIN after leaving the organization, and then hijack certificates that belong to the new user to obtain unauthorized domain access. However, if the employee takes the virtual smart card-enabled computer, it's only necessary to revoke the certificates that are stored on the virtual smart card.
|
||||
|
||||
### Emergency preparedness
|
||||
|
||||
@ -257,18 +254,6 @@ The most common scenario in an organization is reissuing virtual smart cards, wh
|
||||
|
||||
#### Blocked virtual smart card
|
||||
|
||||
The anti-hammering behavior of a TPM virtual smart card is different from that of a physical smart card. A physical smart card blocks itself after the user enters the wrong PIN a few times. A TPM virtual smart card enters a timed delay after the user enters the wrong PIN a few times. If the TPM is in the timed-delay mode, when the user attempts to use the TPM virtual smart card, the user is notified that the card is blocked. Furthermore, if you enable the integrated unlock functionality, the user can see the user interface to unlock the virtual smart card and change the PIN. Unlocking the virtual smart card does not reset the TPM lockout. The user needs to perform an extra step to reset the TPM lockout or wait for the timed delay to expire.
|
||||
The anti-hammering behavior of a TPM virtual smart card is different from that of a physical smart card. A physical smart card blocks itself after the user enters the wrong PIN a few times. A TPM virtual smart card enters a timed delay after the user enters the wrong PIN a few times. If the TPM is in the timed-delay mode, when the user attempts to use the TPM virtual smart card, the user is notified that the card is blocked. Furthermore, if you enable the integrated unlock functionality, the user can see the user interface to unlock the virtual smart card and change the PIN. Unlocking the virtual smart card doesn't reset the TPM lockout. The user needs to perform an extra step to reset the TPM lockout or wait for the timed delay to expire.
|
||||
|
||||
For more information about setting the Allow Integrated Unblock policy, see [Allow Integrated Unblock screen to be displayed at the time of logon](../smart-cards/smart-card-group-policy-and-registry-settings.md#allow-integrated-unblock-screen-to-be-displayed-at-the-time-of-logon).
|
||||
|
||||
## See also
|
||||
|
||||
[Understanding and Evaluating Virtual Smart Cards](virtual-smart-card-understanding-and-evaluating.md)
|
||||
|
||||
[Get Started with Virtual Smart Cards: Walkthrough Guide](virtual-smart-card-get-started.md)
|
||||
|
||||
[Use Virtual Smart Cards](virtual-smart-card-use-virtual-smart-cards.md)
|
||||
|
||||
[Evaluate Virtual Smart Card Security](virtual-smart-card-evaluate-security.md)
|
||||
|
||||
[Tpmvscmgr](virtual-smart-card-tpmvscmgr.md)
|
@ -1,6 +1,6 @@
|
||||
---
|
||||
title: Evaluate Virtual Smart Card Security (Windows 10)
|
||||
description: This topic for the IT professional describes security characteristics and considerations when deploying TPM virtual smart cards.
|
||||
title: Evaluate Virtual Smart Card Security
|
||||
description: Learn about the security characteristics and considerations when deploying TPM virtual smart cards.
|
||||
ms.topic: conceptual
|
||||
ms.date: 02/22/2023
|
||||
appliesto:
|
||||
@ -12,11 +12,12 @@ appliesto:
|
||||
|
||||
[!INCLUDE [virtual-smart-card-deprecation-notice](../../includes/virtual-smart-card-deprecation-notice.md)]
|
||||
|
||||
This topic for the IT professional describes security characteristics and considerations when deploying TPM virtual smart cards.
|
||||
In this article, you'll learn about security characteristics and considerations when deploying TPM virtual smart cards.
|
||||
|
||||
## Virtual smart card non-exportability details
|
||||
|
||||
A crucial aspect of TPM virtual smart cards is their ability to securely store and use secret data, specifically that the secured data is non-exportable. Data can be accessed and used within the virtual smart card system, but it is meaningless outside of its intended environment. In TPM virtual smart cards, security is ensured with a secure key hierarchy, which includes several chains of encryption. This originates with the TPM storage root key, which is generated and stored within the TPM and never exposed outside the chip. The TPM key hierarchy is designed to allow encryption of user data with the storage root key, but it authorizes decryption with the user PIN in such a way that changing the PIN doesn't require re-encryption of the data.
|
||||
A crucial aspect of TPM virtual smart cards is their ability to securely store and use secret data. Specifically, that the secured data is non-exportable.\
|
||||
Data can be accessed and used within the virtual smart card system, but it's meaningless outside of its intended environment. In TPM virtual smart cards, security is ensured with a secure key hierarchy, which includes several chains of encryption. The chain originates with the TPM storage root key, which is generated and stored within the TPM and never exposed outside the chip. The TPM key hierarchy is designed to allow encryption of user data with the storage root key, but it authorizes decryption with the user PIN so that changing the PIN doesn't require re-encryption of the data.
|
||||
|
||||
The following diagram illustrates the secure key hierarchy and the process of accessing the user key.
|
||||
|
||||
@ -24,38 +25,30 @@ The following diagram illustrates the secure key hierarchy and the process of ac
|
||||
|
||||
The following keys are stored on the hard disk:
|
||||
|
||||
- User key
|
||||
|
||||
- Smart card key, which is encrypted by the storage root key
|
||||
|
||||
- Authorization key for the user key decryption, which is encrypted by the public portion of the smart card key
|
||||
- User key
|
||||
- Smart card key, which is encrypted by the storage root key
|
||||
- Authorization key for the user key decryption, which is encrypted by the public portion of the smart card key
|
||||
|
||||
When the user enters a PIN, the use of the decrypted smart card key is authorized with this PIN. If this authorization succeeds, the decrypted smart card key is used to decrypt the auth key. The auth key is then provided to the TPM to authorize the decryption and use of the user's key that is stored on the virtual smart card.
|
||||
|
||||
The auth key is the only sensitive data that is used as plaintext outside the TPM, but its presence in memory is protected by Microsoft Data Protection API (DPAPI), such that before being stored in any way, it is encrypted. All data other than the auth key is processed only as plaintext within the TPM, which is completely isolated from external access.
|
||||
The auth key is the only sensitive data used as plaintext outside the TPM, but its presence in memory is protected by Microsoft Data Protection API (DPAPI), such that before being stored in any way, it's encrypted. All data other than the auth key is processed only as plaintext within the TPM, which is isolated from external access.
|
||||
|
||||
## Virtual smart card anti-hammering details
|
||||
|
||||
The anti-hammering functionality of virtual smart cards relies on the anti-hammering functionality of the TPM that is enabling the virtual smart card. However, the TPM version 1.2 and subsequent specifications (as designed by the Trusted Computing Group) provide very flexible guidelines for responding to hammering. The spec requires only that the TPM implement protection against trial-and-error attacks on the user PIN, PUK, and challenge/response mechanism.
|
||||
The anti-hammering functionality of virtual smart cards relies on the anti-hammering functionality of the TPM that is enabling the virtual smart card. However, the TPM version 1.2 and subsequent specifications (as designed by the Trusted Computing Group) provide flexible guidelines for responding to hammering. The spec requires only that the TPM implement protection against trial-and-error attacks on the user PIN, PUK, and challenge/response mechanism.
|
||||
|
||||
The Trusted Computing Group also specifies that if the response to attacks involves suspending proper function of the TPM for some period of time or until administrative action is taken, the TPM must prevent running the authorized TPM commands. The TPM can prevent running any TPM commands until the termination of the attack response. Beyond using a time delay or requiring administrative action, a TPM could also force a reboot when an attack is detected. The Trusted Computing Group allows manufacturers a level of creativity in their choice of implementation. Whatever methodology is chosen by TPM manufacturers determines the anti-hammering response of TPM virtual smart cards. Some typical aspects of protection from attacks include:
|
||||
The Trusted Computing Group specifies that if the response to attacks involves suspending proper function of the TPM for some period of time, or until administrative action is taken, the TPM must prevent running the authorized TPM commands. The TPM can prevent running any TPM commands until the termination of the attack response. Beyond using a time delay or requiring administrative action, a TPM could also force a reboot when an attack is detected. The Trusted Computing Group allows manufacturers a level of creativity in their choice of implementation. The methodology used by TPM manufacturers determines the anti-hammering response of TPM virtual smart cards. Some typical aspects of protection from attacks include:
|
||||
|
||||
1. Allow only a limited number of wrong PIN attempts before enabling a lockout that enforces a time delay before any further commands are accepted by the TPM.
|
||||
1. Allow only a limited number of wrong PIN attempts before enabling a lockout that enforces a time delay before any further commands are accepted by the TPM.
|
||||
|
||||
> **Note** Introduced in Windows Server 2012 R2 and Windows 8.1, if the user enters the wrong PIN five consecutive times for a virtual smart card (which works in conjunction with the TPM), the card is blocked. When the card is blocked, it has to be unblocked by using the administrative key or the PUK.
|
||||
> **Note**
|
||||
> If the user enters the wrong PIN five consecutive times for a virtual smart card (which works in conjunction with the TPM), the card is blocked. When the card is blocked, it must be unblocked by using the administrative key or the PUK.
|
||||
|
||||
1. Increase the time delay exponentially as the user enters the wrong PIN so that an excessive number of wrong PIN attempts quickly trigger long delays in accepting commands.
|
||||
1. Increase the time delay exponentially as the user enters the wrong PIN so that an excessive number of wrong PIN attempts quickly trigger long delays in accepting commands.
|
||||
1. Have a failure leakage mechanism to allow the TPM to reset the timed delays over a period of time. This is useful in cases where a valid user has entered the wrong PIN occasionally, for example, due to complexity of the PIN.
|
||||
|
||||
2. Have a failure leakage mechanism to allow the TPM to reset the timed delays over a period of time. This is useful in cases where a valid user has entered the wrong PIN occasionally, for example, due to complexity of the PIN.
|
||||
For example, it will take 14 years to guess an eight character PIN for a TPM that implements the following protection:
|
||||
|
||||
As an example, it will take 14 years to guess an 8-character PIN for a TPM that implements the following protection:
|
||||
|
||||
1. Number of wrong PINs allowed before entering lockout (threshold): 9
|
||||
|
||||
2. Time the TPM is in lockout after the threshold is reached: 10 seconds
|
||||
|
||||
3. Timed delay doubles for each wrong PIN after the threshold is reached
|
||||
|
||||
## See also
|
||||
|
||||
[Understanding and Evaluating Virtual Smart Cards](virtual-smart-card-understanding-and-evaluating.md)
|
||||
1. Number of wrong PINs allowed before entering lockout (threshold): 9
|
||||
1. Time the TPM is in lockout after the threshold is reached: 10 seconds
|
||||
1. Timed delay doubles for each wrong PIN after the threshold is reached
|
@ -12,37 +12,33 @@ appliesto:
|
||||
|
||||
[!INCLUDE [virtual-smart-card-deprecation-notice](../../includes/virtual-smart-card-deprecation-notice.md)]
|
||||
|
||||
This topic for IT professional provides an overview of the virtual smart card technology.
|
||||
This article provides an overview of the virtual smart card technology.
|
||||
|
||||
## Feature description
|
||||
|
||||
Virtual smart card technology offers comparable security benefits to physical smart cards by using two-factor authentication. Virtual smart cards emulate the functionality of physical smart cards, but they use the Trusted Platform Module (TPM) chip that is available on devices, rather than requiring the use of a separate physical smart card and reader. Virtual smart cards are created in the TPM, where the keys that are used for authentication are stored in cryptographically-secured hardware.
|
||||
Virtual smart card technology offers comparable security benefits to physical smart cards by using two-factor authentication. Virtual smart cards emulate the functionality of physical smart cards, but they use the Trusted Platform Module (TPM) chip that is available on devices, rather than requiring the use of a separate physical smart card and reader. Virtual smart cards are created in the TPM, where the keys used for authentication are stored in cryptographically-secured hardware.
|
||||
|
||||
By utilizing TPM devices that provide the same cryptographic capabilities as physical smart cards, virtual smart cards accomplish the three key properties that are desired for smart cards: non-exportability, isolated cryptography, and anti-hammering.
|
||||
|
||||
## Practical applications
|
||||
|
||||
Virtual smart cards are functionally similar to physical smart cards and appear in Windows as smart cards that are always-inserted. Virtual smart cards can be used for authentication to external resources, protection of data by secure encryption, and integrity through reliable signing. They are easily deployed by using in-house methods or a purchased solution, and they 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 and appear in Windows as smart cards that are always-inserted. Virtual smart cards can be used for authentication to external resources, protection of data by secure encryption, and integrity through reliable signing. They're easily deployed by using in-house methods or a purchased solution, and they can become a full replacement for other methods of strong authentication in a corporate setting of any scale.
|
||||
|
||||
### Authentication use cases
|
||||
|
||||
**Two-factor authentication‒based remote access**
|
||||
|
||||
After a user has a fully functional TPM virtual smart card, provisioned with a sign-in certificate, the certificate is used to gain strongly authenticated access to corporate resources. When the proper certificate is provisioned to the virtual card, the user need only provide the PIN for the virtual smart card, as if it was a physical smart card, to sign in to the domain.
|
||||
After a user has a fully functional TPM virtual smart card, provisioned with a sign-in certificate, the certificate is used to gain authenticated access to corporate resources. When the proper certificate is provisioned to the virtual card, the user need only provide the PIN for the virtual smart card, as if it was a physical smart card, to sign in to the domain.
|
||||
|
||||
In practice, this is as easy as entering a password to access the system. Technically, it is far more secure. Using the virtual smart card to access the system proves to the domain that the user who is requesting authentication has possession of the personal computer upon which the card has been provisioned and knows the virtual smart card PIN. Because this request could not have possibly originated from a system other than the system certified by the domain for this user's access, and the user could not have initiated the request without knowing the PIN, a strong two-factor authentication is established.
|
||||
In practice, this is as easy as entering a password to access the system. Technically, it's far more secure. Using the virtual smart card to access the system proves to the domain that the user who is requesting authentication has possession of the personal computer upon which the card has been provisioned and knows the virtual smart card PIN. Because this request couldn't have possibly originated from a system other than the system certified by the domain for this user's access, and the user couldn't have initiated the request without knowing the PIN, a strong two-factor authentication is established.
|
||||
|
||||
**Client authentication**
|
||||
|
||||
Virtual smart cards can also be used for client authentication by using Secure Socket Layer (SSL) or a similar technology. Similar to domain access with a virtual smart card, an authentication certificate can be provisioned for the virtual smart card, provided to a remote service, as requested in the client authentication process. This adheres to the principles of two-factor authentication because the certificate is only accessible from the computer that hosts the virtual smart card, and the user is required to enter the PIN for initial access to the card.
|
||||
Virtual smart cards can also be used for client authentication by using TLS/SSL or a similar technology. Similar to domain access with a virtual smart card, an authentication certificate can be provisioned for the virtual smart card, provided to a remote service, as requested in the client authentication process. This adheres to the principles of two-factor authentication because the certificate is only accessible from the computer that hosts the virtual smart card, and the user is required to enter the PIN for initial access to the card.
|
||||
|
||||
**Virtual smart card redirection for remote desktop connections**
|
||||
|
||||
The concept of two-factor authentication associated with virtual smart cards relies on the proximity of users to the computers that they access domain resources through. Therefore, when a user remotely connects to a computer that is hosting virtual smart cards, the virtual smart cards that are located on the remote computer cannot be used during the remote session. However, the virtual smart cards that are stored on the connecting computer (which is under physical control of the user) are loaded onto the remote computer, and they can be used as if they were installed by using the remote computer's TPM. This extends a user's privileges to the remote computer, while maintaining the principles of two-factor authentication.
|
||||
|
||||
**Windows To Go and virtual smart cards**
|
||||
|
||||
Virtual smart cards work well with Windows To Go, where a user can boot into a supported version of Windows from a compatible removable storage device. A virtual smart card can be created for the user, and it is tied to the TPM on the physical host computer to which the removable storage device is connected. When the user boots the operating system from a different physical computer, the virtual smart card will not be available. This can be used for scenarios when a single physical computer is shared by many users. Each user can be given a removable storage device for Windows To Go, which has a virtual smart card provisioned for the user. This way, users are only able to access their personal virtual smart card.
|
||||
The concept of two-factor authentication associated with virtual smart cards relies on the proximity of users to the computers that they access domain resources through. Therefore, when a user remotely connects to a computer that is hosting virtual smart cards, the virtual smart cards that are located on the remote computer can't be used during the remote session. However, the virtual smart cards that are stored on the connecting computer (which is under physical control of the user) are loaded onto the remote computer, and they can be used as if they were installed by using the remote computer's TPM. This extends a user's privileges to the remote computer, while maintaining the principles of two-factor authentication.
|
||||
|
||||
### Confidentiality use cases
|
||||
|
||||
@ -52,41 +48,15 @@ Physical smart cards are designed to hold private keys that can be used for emai
|
||||
|
||||
**BitLocker for data volumes**
|
||||
|
||||
sBitLocker Drive Encryption technology makes use of symmetric-key encryption to protect the content of a user's hard drive. This ensures that if the physical ownership of a hard drive is compromised, an adversary will not be able to read data off the drive. The key used to encrypt the drive can be stored in a virtual smart card, which necessitates knowledge of the virtual smart card PIN to access the drive and possession of the computer that is hosting the TPM virtual smart card. If the drive is obtained without access to the TPM that hosts the virtual smart card, any brute force attack will be very difficult.
|
||||
BitLocker Drive Encryption technology makes use of symmetric-key encryption to protect the content of a user's hard drive. This ensures that if the physical ownership of a hard drive is compromised, an adversary won't be able to read data off the drive. The key used to encrypt the drive can be stored in a virtual smart card, which necessitates knowledge of the virtual smart card PIN to access the drive and possession of the computer that is hosting the TPM virtual smart card. If the drive is obtained without access to the TPM that hosts the virtual smart card, any brute force attack will be difficult.
|
||||
|
||||
BitLocker can also be used to encrypt portable drives, which involves storing keys in virtual smart cards. In this scenario (unlike using BitLocker with a physical smart card), the encrypted drive can be used only when it is connected to the host for the virtual smart card that is used to encrypt the drive, because the BitLocker key is only accessible from this computer. However, this method can be useful to ensure the security of backup drives and personal storage uses outside the main hard drive.
|
||||
BitLocker can also be used to encrypt portable drives, storing keys in virtual smart cards. In this scenario (unlike using BitLocker with a physical smart card), the encrypted drive can be used only when it's connected to device for the virtual smart card that is used to encrypt the drive, because the BitLocker key is only accessible from this device. This method can be useful to ensure the security of backup drives and personal storage uses outside the main hard drive, too.
|
||||
|
||||
### Data integrity use case
|
||||
|
||||
**Signing data**
|
||||
|
||||
To verify authorship of data, a user can sign it by using a private key that is stored in the virtual smart card. Digital signatures confirm the integrity and origin of the data. If the key is stored in an operating system that is accessible, a malicious user could access it and use it to modify already signed data or to spoof the key owner's identity. However, if this key is stored in a virtual smart card, it can be used only to sign data on the host computer. It cannot be exported to other systems (intentionally or unintentionally, such as with malware theft). This makes digital signatures far more secure than other methods for private key storage.
|
||||
|
||||
## New and changed functionality as of Windows 8.1
|
||||
|
||||
Enhancements in Windows 8.1 enabled developers to build Microsoft Store apps to create and manage virtual smart cards.
|
||||
|
||||
The DCOM Interfaces for Trusted Platform Module (TPM) Virtual Smart Card device management protocol provides a Distributed Component Object Model (DCOM) Remote Protocol interface used for creating and destroying virtual smart cards. A virtual smart card is a device that presents a device interface complying with the PC/SC specification for PC-connected interface devices to its host operating system (OS) platform. This protocol does not assume anything about the underlying implementation of virtual smart card devices. In particular, while it is primarily intended for the management of virtual smart cards based on TPMs, it can also be used to manage other types of virtual smart cards.
|
||||
|
||||
**What value does this change add?**
|
||||
|
||||
Starting with Windows 8.1, application developers can build into their apps the following virtual smart card maintenance capabilities to relieve some of your administrative burdens.
|
||||
|
||||
- Create a new virtual smart card or select a virtual smart card from the list of available virtual smart cards on the system. Identify the one that the application is supposed to work with
|
||||
- Personalize the virtual smart card
|
||||
- Change the admin key
|
||||
- Diversify the admin key which allows the user to unblock the PIN in a PIN-blocked scenario
|
||||
- Change the PIN
|
||||
- Reset or Unblock the PIN
|
||||
- Destroy the virtual smart card
|
||||
|
||||
**What works differently?**
|
||||
|
||||
Starting with Windows 8.1, Microsoft Store app developers are able to build apps that have the capability to prompt the user to reset or unblock and change a virtual smart card PIN. This places more responsibility on the user to maintain their virtual smart card but it can also provide a more consistent user experience and administration experience in your organization.
|
||||
|
||||
For more information about developing Microsoft Store apps with these capabilities, see [Trusted Platform Module Virtual Smart Card Management Protocol](/openspecs/windows_protocols/ms-tpmvsc/10bd67d7-4580-4e38-a6e9-ec3be00033b6).
|
||||
|
||||
For more information about managing these capabilities in virtual smart cards, see [Understanding and Evaluating Virtual Smart Cards](virtual-smart-card-understanding-and-evaluating.md).
|
||||
To verify authorship of data, a user can sign it by using a private key stored in the virtual smart card. Digital signatures confirm the integrity and origin of the data. If the key is stored in an operating system that is accessible, a malicious user could access it and use it to modify already signed data or to spoof the key owner's identity. However, if the key is stored in a virtual smart card, it can be used only to sign data on the host device. The key can't be exported to other systems (intentionally or unintentionally, such as with malware theft), making digital signatures more secure than other methods for private key storage.
|
||||
|
||||
## Hardware requirements
|
||||
|
||||
|
Loading…
x
Reference in New Issue
Block a user