Add information about key types in Windows Hello for Business

This commit is contained in:
Paolo Matarazzo
2024-01-09 17:29:10 -05:00
parent 901eb80269
commit 7683f6130d
2 changed files with 8 additions and 17 deletions

View File

@ -21,22 +21,6 @@ sections:
answer: |
When using Windows Hello for Business, the PIN isn't a symmetric key, whereas the password is a symmetric key. With passwords, there's a server that has some representation of the password. With Windows Hello for Business, the PIN is user-provided entropy used to load the private key in the Trusted Platform Module (TPM). The server doesn't have a copy of the PIN. For that matter, the Windows client doesn't have a copy of the current PIN either. The user must provide the entropy, the TPM-protected key, and the TPM that generated that key in order to successfully access the private key.
The statement *PIN is stronger than Password* is not directed at the strength of the entropy used by the PIN. It's about the difference between providing entropy versus continuing the use of a symmetric key (the password). The TPM has anti-hammering features that thwart brute-force PIN attacks (an attacker's continuous attempt to try all combination of PINs). Some organizations may worry about shoulder surfing. For those organizations, rather than increase the complexity of the PIN, implement the [Multifactor Unlock](multifactor-unlock.md) feature.
- question: What's a container?
answer: |
In the context of Windows Hello for Business, a container is a logical grouping of *key material* or data. Windows Hello uses a single container that holds user key material for personal accounts (including key material associated with the user's Microsoft account or with other consumer identity providers), and credentials associated with an organization's account.
The container holds organization's credentials only on devices that are *registered* with the organization.
> [!NOTE]
> There are no physical containers on disk, in the registry, or elsewhere. Containers are logical units used to group related items. The keys, certificates, and credentials that Windows Hello stores, are protected without the creation of actual containers or folders.
The container contains a set of keys, some of which are used to protect other keys. The following image illustrates an example: the *protector key* is used to encrypt the *authentication key*, and the authentication key is used to encrypt the individual keys stored in the container. Each logical container holds one or more sets of keys.\
:::image type="content" source="images/howitworks/hello-container.png" alt-text="logical container with set of keys" border="false":::
Containers can contain several types of key material:
- An authentication key, which is always an asymmetric public-private key pair. This key pair is generated during registration. It must be unlocked each time it's accessed, by using either the user's PIN or a biometric gesture. The authentication key exists until the user resets the PIN, at which time a new key will be generated. When the new key is generated, all the key material that the old key previously protected must be decrypted and re-encrypted using the new key.
- The IdP key. These keys can be either symmetric or asymmetric, depending on which IdP you use. A single container may contain zero or more IdP keys, with some restrictions (for example, the enterprise container can contain zero or one IdP key). IdP keys are stored in the container. For certificate-based Windows Hello for Work, when the container is unlocked, applications that require access to the IdP key or key pair can request access. IdP keys are used to sign or encrypt authentication requests or tokens sent from this device to the IDP. IdP keys are typically long-lived but could have a shorter lifetime than the authentication key. Microsoft accounts, Active Directory accounts, and Microsoft Entra accounts all require the use of asymmetric key pairs. The device generates public and private keys, registers the public key with the IdP (which stores it for later verification), and securely stores the private key. For enterprises, the IdP keys can be generated in two ways:
- The IdP key pair can be associated with an enterprise Certificate Authority (CA) through the Windows Network Device Enrollment Service (NDES). In this case, Windows Hello requests a new certificate with the same key as the certificate from the existing PKI. This option lets organizations that have an existing PKI continue to use it where appropriate. Given that many applications, such as VPN solutions, require the use of certificates, when you deploy Windows Hello in this mode, it allows a faster transition away from user passwords while still preserving certificate-based functionality. This option also allows the enterprise to store additional certificates in the protected container.
- The IdP can generate the IdP key pair directly, which allows quick, lower-overhead deployment of Windows Hello in environments that don't have or need a PKI.
- question: How are keys protected?
answer: |
Anytime key material is generated, it must be protected against attack. The most robust way to do this is through specialized hardware. There's a long history of using hardware security modules (HSMs) to generate, store, and process keys for security-critical applications. Smart cards are a special type of HSM, as are devices that are compliant with the Trusted Computing Group TPM standard. Wherever possible, the Windows Hello for Business implementation takes advantage of onboard TPM hardware to generate and protect keys. Administrators can choose to allow key operations in software, but it's recommended the use of TPM hardware. The TPM protects against a variety of known and potential attacks, including PIN brute-force attacks. The TPM provides an additional layer of protection after an account lockout, too. When the TPM has locked the key material, the user will have to reset the PIN (which means the user will have to use MFA to reauthenticate to the IdP before the IdP allows re-registration). Resetting the PIN means that all keys and certificates encrypted with the old key material will be removed.

View File

@ -154,6 +154,13 @@ Windows Hello also generates an *administrative key*. The administrative key can
Access to the key material stored in the container, and obtaining a signature to validate user possession of the private key, is enabled only by the PIN or biometric gesture. The two-step verification that takes place during provisioning creates a trusted relationship between the IdP and the user. This happens when the public portion of the public/private key pair is sent to an identity provider and associated with the user account. When a user enters the gesture on the device, the identity provider knows that it's a verified identity, because of the combination of Windows Hello keys and gestures. It then provides an authentication token that allows Windows to access resources and services.
A container can contain several types of key material:
- An *authentication key*, which is always an asymmetric public-private key pair. This key pair is generated during registration. It must be unlocked each time it's accessed, by using either the user's PIN or a biometric gesture. The authentication key exists until the user resets the PIN, at which time a new key will be generated. When the new key is generated, all the key material that the old key previously protected must be decrypted and re-encrypted using the new key
- The *IdP key*. These keys can be either symmetric or asymmetric, depending on which IdP you use. A single container may contain zero or more IdP keys, with some restrictions (for example, the enterprise container can contain zero or one IdP key). IdP keys are stored in the container. For certificate-based Windows Hello for Work, when the container is unlocked, applications that require access to the IdP key or key pair can request access. IdP keys are used to sign or encrypt authentication requests or tokens sent from this device to the IDP. IdP keys are typically long-lived but could have a shorter lifetime than the authentication key. Microsoft accounts, Active Directory accounts, and Microsoft Entra accounts all require the use of asymmetric key pairs. The device generates public and private keys, registers the public key with the IdP (which stores it for later verification), and securely stores the private key. For enterprises, the IdP keys can be generated in two ways:
- The IdP key pair can be associated with an enterprise Certificate Authority (CA) through the Windows Network Device Enrollment Service (NDES). In this case, Windows Hello requests a new certificate with the same key as the certificate from the existing PKI. This option lets organizations that have an existing PKI continue to use it where appropriate. Given that many applications, such as VPN solutions, require the use of certificates, when you deploy Windows Hello in this mode, it allows a faster transition away from user passwords while still preserving certificate-based functionality. This option also allows the enterprise to store additional certificates in the protected container. For example, an enterprise might want to store a certificate that allows the user to authenticate via RDP.
- The IdP can generate the IdP key pair directly, which allows quick, lower-overhead deployment of Windows Hello in environments that don't have or need a PKI.
To learn more how Windows uses the TPM in support of Windows Hello for Business, see [How Windows uses the Trusted Platform Module](../../hardware-security/tpm/how-windows-uses-the-tpm.md).
### Windows Hello data storage
@ -218,7 +225,7 @@ Changing a user account password doesn't affect sign-in or unlock, since Windows
## Next steps
> [!div class="nextstepaction"]
> To accommodate the multitude of organization needs and requirements, Windows Hello for Business offers different deployment options. To learn how to plan a Windows Hello for Business deployment, see:
> To accommodate the multitude of organizations needs and requirements, Windows Hello for Business offers different deployment options. To learn how to plan a Windows Hello for Business deployment, see:
>
> [Plan a Windows Hello for Business Deployment](deploy/index.md)