Windows Hello

本文介绍作为 Windows 的一部分随附的 Windows Hello 技术，并讨论了开发人员如何实现这项技术来保护其 Windows 应用和后端服务。 它重点介绍了这些技术的特定功能，这些技术有助于缓解使用传统凭据产生的威胁，并提供有关在 Windows 客户端推出过程中设计和部署这些技术的指导。

注意

本文重点介绍应用开发。 有关 Windows Hello 的体系结构和实现详细信息，请参阅规划Windows Hello 企业版部署。

有关使用 Windows Hello 和后盾身份验证服务创建 WinUI 应用的分步演练，请参阅 Windows Hello 登录应用 和 Windows Hello 登录服务 文章。

介绍

有关信息安全的基本假设是，系统可以识别正在使用它的人员。 标识用户允许系统确定用户是否被适当地标识（称为身份验证的进程），然后确定经过适当身份验证的用户应能够执行哪些操作（授权）。 全世界部署的绝大多数计算机系统都依赖于用户凭据做出身份验证和授权决策，这意味着这些系统依赖于可重用的用户创建的密码作为其安全性的基础。 被引用的最大值，身份验证可以涉及“你知道的东西，你拥有的东西，或你的东西”巧妙地强调了问题：可重用的密码是一个身份验证因素本身，所以任何知道密码的人都可以模拟拥有它的用户。

旧凭据问题

自20世纪60年代中期以来，当费尔南多·科尔巴托和他的团队在马萨诸塞理工学院支持引入密码以来，用户和管理员必须处理密码的使用，以便进行用户身份验证和授权。 随着时间的推移，密码存储和使用的最先进的状态有所提升（例如，安全哈希和加盐），但我们仍然面临着两个问题。 密码易于克隆，易于窃取。 此外，实现错误可能会使他们不安全，并且用户很难平衡便利和安全性。

凭据盗窃

密码的最大风险在于太过简单：攻击者可以轻松窃取密码。 输入、处理或存储密码的每个位置都容易受到攻击。 例如，攻击者可以通过窃听网络流量到应用程序服务器、在应用程序或设备上植入恶意软件、在设备上记录用户击键或监视查看用户类型的字符，从身份验证服务器窃取密码或哈希集合。 这些只是最常见的攻击方法。

另一个相关的风险是凭据重播，攻击者通过窃听不安全的网络来捕获有效的凭据，然后在以后重播该凭据以模拟有效用户。 大多数身份验证协议（包括 Kerberos 和 OAuth）通过在凭据交换过程中包括时间戳来防止重播攻击，但该策略仅保护身份验证系统发布的令牌，而不是用户提供的密码，以便首先获取票证。

凭据重用

使用电子邮件地址作为用户名的常见方法使问题变得更糟。 成功从受攻击的系统恢复用户名-密码对的攻击者可以在其他系统上尝试同一对。 这种策略通常很出人意料地工作，使攻击者能够从被入侵的系统跳入其他系统。 使用电子邮件地址作为用户名会导致本指南稍后将探讨的其他问题。

解决凭据问题

解决密码构成的问题很棘手。 单独收紧密码策略不会这样做;用户只能回收、共享或记下密码。 尽管用户教育对于身份验证安全性至关重要，但单独教育并不能消除该问题。

Windows Hello 通过验证现有凭据以及创建生物识别或基于 PIN 的用户手势保护的设备特定凭据，将密码替换为强双因素身份验证（2FA）。

什么是 Windows Hello？

Windows Hello 是内置于 Windows 中的新生物识别登录系统的名称Microsoft。 由于它直接内置于操作系统中，因此 Windows Hello 允许人脸或指纹识别解锁用户的设备。 当用户提供其唯一生物识别标识符来访问特定于设备的凭据时，会进行身份验证，这意味着窃取设备的攻击者无法登录该设备，除非攻击者具有 PIN。 Windows 安全凭据存储保护设备上的生物特征数据。 通过使用 Windows Hello 解锁设备，授权用户可以访问其所有 Windows 体验、应用、数据、网站和服务。

Windows Hello 验证器称为 Hello。 Hello 对单个设备和特定用户的组合是唯一的。 它不会在设备之间漫游，不会与服务器或调用应用共享，并且无法从设备轻松提取。 如果多个用户共享设备，则每个用户都需要设置自己的帐户。 每个帐户都会获得该设备的唯一 Hello。 可以将 Hello 视为可用于解锁存储凭据（或释放）的令牌。 Hello 本身不会向应用或服务进行身份验证，但它会释放可以的凭据。 换句话说，Hello 不是用户凭据，但它是身份验证过程的第二个因素。

Windows Hello 身份验证

Windows Hello 为设备识别单个用户提供了一种强大的方法，它解决了用户与请求的服务或数据项之间的第一部分路径。 在设备识别出用户之后，在确定是否授予对所请求资源的访问权限之前，它仍然必须对用户进行身份验证。 Windows Hello 提供完全集成到 Windows 中的强 2FA，并将可重用的密码替换为特定设备的组合以及生物识别手势或 PIN。

不过，Windows Hello 不仅仅是传统 2FA 系统的替代。 从概念上讲，它类似于智能卡：身份验证是使用加密基元而不是字符串比较执行的，并且用户的密钥材料在防篡改硬件内是安全的。 Windows Hello 不需要智能卡部署所需的额外基础结构组件。 特别是，如果当前没有公钥基础结构（PKI），则不需要公钥基础结构（PKI）来管理证书。 Windows Hello 结合了智能卡的主要优势（虚拟智能卡的部署灵活性和物理智能卡的可靠安全性），没有任何缺点。

Windows Hello 的工作原理

当用户在其计算机上设置 Windows Hello 时，它会在设备上生成新的公钥-私钥对。 受信任的平台模块 （TPM） 生成并保护此私钥。 如果设备没有 TPM 芯片，则私钥会加密并受软件保护。 此外，已启用 TPM 的设备还会生成一个数据块，这些数据块可用于证明密钥绑定到 TPM。 此证明信息可用于解决方案，以确定用户是否被授予其他授权级别，例如。

若要在设备上启用 Windows Hello，用户必须具有其Microsoft Entra ID 帐户或在 Windows 设置中连接的Microsoft帐户。

如何保护密钥

每当生成密钥材料时，都必须保护它免受攻击。 执行此操作的最可靠方法是通过专用硬件。 使用硬件安全模块（HSM）为安全关键型应用程序生成、存储和处理密钥有着悠久的历史。 智能卡是特殊类型的 HSM，符合受信任的计算组 TPM 标准的设备也是如此。 无论可能，Windows Hello 实现都利用载入 TPM 硬件来生成、存储和处理密钥。 但是，Windows Hello 和 Windows Hello for Work 不需要载入 TPM。

只要可行，Microsoft建议使用 TPM 硬件。 TPM 可防范各种已知和潜在攻击，包括 PIN 暴力攻击。 TPM 在帐户锁定后还提供额外的保护层。 当 TPM 锁定密钥材料时，用户必须重置 PIN。 重置 PIN 意味着将删除使用旧密钥材料加密的所有密钥和证书。

身份验证

当用户想要访问受保护的密钥材料时，身份验证过程从用户输入 PIN 或生物识别手势解锁设备开始，此过程有时称为“释放密钥”。

应用程序永远不能使用来自另一个应用程序的密钥，也不能有人使用其他用户的密钥。 这些密钥用于对发送到标识提供者或 IDP 的请求进行签名，以寻求对指定资源的访问权限。 应用程序可以使用特定 API 请求需要特定操作密钥材料的操作。 通过这些 API 进行访问确实需要通过用户手势进行显式验证，并且密钥材料不会向请求应用程序公开。 相反，应用程序会要求执行特定操作，例如对一段数据进行签名，而 Windows Hello 层会处理实际工作并返回结果。

准备实现 Windows Hello

现在，我们已经基本了解了 Windows Hello 的工作原理，让我们看看如何在自己的应用程序中实现它们。

可以使用 Windows Hello 实现不同的方案。 例如，只需登录到设备上的应用。 另一种常见方案是针对服务进行身份验证。 你将使用 Windows Hello，而不是使用登录名和密码。 在以下部分中，我们将讨论如何实现几种不同的方案，包括如何使用 Windows Hello 对服务进行身份验证，以及如何从现有用户名/密码系统转换为 Windows Hello 系统。

实现 Windows Hello

在本部分中，我们将从没有现有身份验证系统的绿地方案开始，并介绍如何实现 Windows Hello。

下一部分介绍如何从现有用户名/密码系统迁移。 但是，即使该部分更符合你的兴趣，你可能希望了解此部分，以便基本了解过程和所需的代码。

注册新用户

我们从一项全新的服务开始，该服务将使用 Windows Hello，以及一个准备好在新设备上注册的假设新用户。

第一步是验证用户是否能够使用 Windows Hello。 应用会验证用户设置和计算机功能，以确保它可以创建用户 ID 密钥。 如果应用确定用户尚未启用 Windows Hello，它会提示用户在使用该应用之前进行此设置。

若要启用 Windows Hello，用户只需在 Windows 设置中设置 PIN，除非用户在开箱即用体验（OOBE）期间对其进行设置。

以下代码行显示了一种检查用户是否已为 Windows Hello 设置的简单方法。

var keyCredentialAvailable = await KeyCredentialManager.IsSupportedAsync();
if (!keyCredentialAvailable)
{
    // User didn't set up PIN yet
    return;
}

下一步是要求用户提供注册服务的信息。 可以选择请求用户输入名字、姓氏、电子邮件地址和唯一用户名。 可以使用电子邮件地址作为唯一标识符;它由你决定。

在此方案中，我们使用电子邮件地址作为用户的唯一标识符。 用户注册后，应考虑发送验证电子邮件以确保地址有效。 这为你提供了一种机制来重置帐户（如有必要）。

如果用户设置了其 PIN，应用将创建用户的 KeyCredential。 该应用还获取可选的密钥证明信息，以获取 TPM 上生成的密钥的加密证明。 生成的公钥（可选）将发送到后端服务器以注册正在使用的设备。 每个设备上生成的每个密钥对都是唯一的。

创建 KeyCredential 的代码如下所示：

var keyCreationResult = await KeyCredentialManager.RequestCreateAsync(
    AccountId, KeyCredentialCreationOption.ReplaceExisting);

RequestCreateAsync 是创建公钥和私钥的调用。 如果设备具有正确的 TPM 芯片，API 将请求 TPM 芯片创建私钥和公钥并存储结果：如果没有可用的 TPM 芯片，OS 将在代码中创建密钥对。 应用无法直接访问创建的私钥。 创建密钥对的一部分也是生成的证明信息。 （有关证明的详细信息，请参阅下一部分。

在设备上创建密钥对和证明信息后，公钥、可选证明信息以及唯一标识符（如电子邮件地址）需要发送到后端注册服务并存储在后端中。

若要允许用户访问多个设备上的应用，后端服务需要能够存储同一用户的多个密钥。 由于每个设备的每个密钥都是唯一的，因此我们将存储所有连接到同一用户的密钥。 设备标识符用于在对用户进行身份验证时帮助优化服务器部件。 我们将在下一部分中更详细地讨论这一点。

在后端存储此信息的示例数据库架构可能如下所示：

注册逻辑可能如下所示：

当然，你收集的注册信息可能包括比我们在此简单方案中包含的更多识别信息。 例如，如果应用访问安全服务（例如银行服务），则需要在注册过程中请求标识证明和其他事项。 满足所有条件后，此用户的公钥将存储在后端中，用于验证用户下次使用该服务的时间。

using System;
using System.Runtime;
using System.Threading.Tasks;
using Windows.Storage.Streams;
using Windows.Security.Credentials;

static async void RegisterUser(string AccountId)
{
    var keyCredentialAvailable = await KeyCredentialManager.IsSupportedAsync();
    if (!keyCredentialAvailable)
    {
        // The user didn't set up a PIN yet
        return;
    }

    var keyCreationResult = await KeyCredentialManager.RequestCreateAsync(AccountId, KeyCredentialCreationOption.ReplaceExisting);
    if (keyCreationResult.Status == KeyCredentialStatus.Success)
    {
        var userKey = keyCreationResult.Credential;
        var publicKey = userKey.RetrievePublicKey();
        var keyAttestationResult = await userKey.GetAttestationAsync();
        IBuffer keyAttestation = null;
        IBuffer certificateChain = null;
        bool keyAttestationIncluded = false;
        bool keyAttestationCanBeRetrievedLater = false;

        keyAttestationResult = await userKey.GetAttestationAsync();
        KeyCredentialAttestationStatus keyAttestationRetryType = 0;

        switch (keyAttestationResult.Status)
        {
            case KeyCredentialAttestationStatus.Success:
                keyAttestationIncluded = true;
                keyAttestation = keyAttestationResult.AttestationBuffer;
                certificateChain = keyAttestationResult.CertificateChainBuffer;
                break;
            case KeyCredentialAttestationStatus.TemporaryFailure:
                keyAttestationRetryType = KeyCredentialAttestationStatus.TemporaryFailure;
                keyAttestationCanBeRetrievedLater = true;
                break;
            case KeyCredentialAttestationStatus.NotSupported:
                keyAttestationRetryType = KeyCredentialAttestationStatus.NotSupported;
                keyAttestationCanBeRetrievedLater = true;
                break;
        }
    }
    else if (keyCreationResult.Status == KeyCredentialStatus.UserCanceled ||
        keyCreationResult.Status == KeyCredentialStatus.UserPrefersPassword)
    {
        // Show error message to the user to get confirmation that user
        // does not want to enroll.
    }
}

证明

创建密钥对时，还可以选择请求 TPM 芯片生成的证明信息。 此可选信息可以作为注册过程的一部分发送到服务器。 TPM 密钥证明是一种协议，以加密方式证明密钥是 TPM 绑定的。 这种类型的证明可用于保证特定计算机的 TPM 中发生了特定加密操作。

当它收到生成的 RSA 密钥、证明语句和 AIK 证书时，服务器将验证以下条件：

• AIK 证书签名有效。
• AIK 证书将链接到受信任的根目录。
• AIK 证书及其链已启用 EKU OID“2.23.133.8.3”（友好名称为“证明标识密钥证书”）。
• AIK 证书是有效的时间。
• 链中的所有颁发 CA 证书都有效且未吊销。
• 证明语句的格式正确。
• KeyAttestation Blob 上的签名使用 AIK 公钥。
• KeyAttestation Blob 中包含的公钥与客户端与证明语句一起发送的公共 RSA 密钥匹配。

你的应用可能会根据这些条件向用户分配不同的授权级别。 例如，如果其中一项检查失败，它可能不会注册用户，或者可能会限制用户可以执行的操作。

使用 Windows Hello 登录

在系统中注册用户后，他或她可以使用该应用。 根据方案，可以要求用户进行身份验证，然后才能开始使用应用，或者只是要求用户在开始使用后端服务后进行身份验证。

强制用户再次登录

在某些情况下，你可能希望用户证明他或她是当前登录的人员，然后访问应用，有时是在应用内执行特定操作之前。 例如，在银行应用将转移资金命令发送到服务器之前，你需要确保它是用户，而不是找到登录设备的人，试图执行交易。 可以使用 UserConsentVerifier 类强制用户再次在应用中登录。 以下代码行将强制用户输入其凭据。

以下代码行将强制用户输入其凭据。

UserConsentVerificationResult consentResult = await UserConsentVerifier.RequestVerificationAsync("userMessage");
if (consentResult.Equals(UserConsentVerificationResult.Verified))
{
    // continue
}

还可以使用来自服务器的质询响应机制，这要求用户输入其 PIN 代码或生物识别凭据。 这取决于你作为开发人员需要实现的方案。 以下部分介绍了此机制。

后端的身份验证

当应用尝试访问受保护的后端服务时，该服务会向应用发送质询。 应用使用用户的私钥对质询进行签名，并将其发送回服务器。 由于服务器存储了该用户的公钥，因此它使用标准加密 API 来确保消息确实使用正确的私钥进行签名。 在客户端上，签名由 Windows Hello API 完成;开发人员将永远无法访问任何用户的私钥。

除了检查密钥之外，服务还可以检查密钥证明，并判断在设备上存储密钥的方式是否有任何限制。 例如，当设备使用 TPM 保护密钥时，它比在没有 TPM 的情况下存储密钥的设备更安全。 例如，后端逻辑可以决定，仅当不使用 TPM 来降低风险时，才允许用户转移一定金额。

证明仅适用于具有版本 2.0 或更高版本的 TPM 芯片的设备。 因此，需要考虑到此信息在每台设备上可能不可用。

客户端工作流可能如下图所示：

当应用在后端调用服务时，服务器会发送质询。 质询使用以下代码进行签名：

var openKeyResult = await KeyCredentialManager.OpenAsync(AccountId);

if (openKeyResult.Status == KeyCredentialStatus.Success)
{
    var userKey = openKeyResult.Credential;
    var publicKey = userKey.RetrievePublicKey();
    var signResult = await userKey.RequestSignAsync(message);

    if (signResult.Status == KeyCredentialStatus.Success)
    {
        return signResult.Result;
    }
    else if (signResult.Status == KeyCredentialStatus.UserPrefersPassword)
    {

    }
}

第一行 KeyCredentialManager.OpenAsync 将要求 Windows 打开密钥句柄。 如果成功，可以使用 KeyCredential.RequestSignAsync 方法对质询消息进行签名，从而导致 Windows 通过 Windows Hello 请求用户的 PIN 或生物识别。 开发人员绝不有权访问用户的私钥。 这一切都通过 API 保持安全。

API 请求 Windows 使用私钥对质询进行签名。 然后，系统会要求用户输入 PIN 代码或配置的生物识别登录。 输入正确的信息后，系统可以要求 TPM 芯片执行加密功能并签署质询。 （或使用回退软件解决方案（如果没有 TPM 可用）。 客户端必须将签名质询发送回服务器。

此序列图中显示了基本质询-响应流：

接下来，服务器必须验证签名。 当请求公钥并将其发送到服务器以用于将来验证时，该公钥位于 ASN.1 编码的 publicKeyInfo Blob 中。 如果在 GitHub 上检查 Windows Hello 代码示例，你将看到有帮助程序类来包装 Crypt32 函数，以便将 ASN.1 编码的 Blob 转换为 CNG Blob，这更常用。 Blob 包含公钥算法，即 RSA 和 RSA 公钥。

在示例中，我们将 ASN.1 编码的 Blob 转换为 CNG blob 的原因是，它可用于 CNG 和 BCrypt API。 如果查找 CNG Blob，它会将你指向相关的 BCRYPT_KEY_BLOB 结构。 此 API 图面可用于 Windows 应用程序中的身份验证和加密。 ASN.1 是一种记录的标准，用于传达可序列化的数据结构，通常用于公钥加密和证书。 这就是以这种方式返回公钥信息的原因。 该公钥是 RSA 密钥，这是 Windows Hello 在对数据签名时使用的算法。

获得 CNG Blob 后，需要针对用户的公钥验证已签名的质询。 由于每个人都使用自己的系统或后端技术，因此无法实现此逻辑。 我们将 SHA256 用作 SignaturePadding 的哈希算法和 Pkcs1，因此请确保在验证来自客户端的签名响应时使用。 同样，请参考示例，了解在 .NET 4.6 中的服务器上执行此操作的方法，但一般情况下，示例将如下所示：

using (RSACng pubKey = new RSACng(publicKey))
{
    retval = pubKey.VerifyData(originalChallenge, responseSignature, HashAlgorithmName.SHA256, RSASignaturePadding.Pkcs1);
}

我们读取存储的公钥，这是 RSA 密钥。 我们使用公钥验证已签名的质询消息，如果签出，我们将授权用户。 如果用户已经过身份验证，应用可以正常调用后端服务。

完整的代码可能如下所示：

using System;
using System.Runtime;
using System.Threading.Tasks;
using Windows.Storage.Streams;
using Windows.Security.Cryptography;
using Windows.Security.Cryptography.Core;
using Windows.Security.Credentials;

static async Task<IBuffer> GetAuthenticationMessageAsync(IBuffer message, String AccountId)
{
    var openKeyResult = await KeyCredentialManager.OpenAsync(AccountId);

    if (openKeyResult.Status == KeyCredentialStatus.Success)
    {
        var userKey = openKeyResult.Credential;
        var publicKey = userKey.RetrievePublicKey();
        var signResult = await userKey.RequestSignAsync(message);
        if (signResult.Status == KeyCredentialStatus.Success)
        {
            return signResult.Result;
        }
        else if (signResult.Status == KeyCredentialStatus.UserCanceled)
        {
            // Launch app-specific flow to handle the scenario 
            return null;
        }
    }
    else if (openKeyResult.Status == KeyCredentialStatus.NotFound)
    {
        // PIN reset has occurred somewhere else and key is lost.
        // Repeat key registration
        return null;
    }
    else
    {
        // Show custom UI because unknown error has happened.
        return null;
    }
}

实施正确的质询响应机制超出了本文档的范围，但本主题需要注意才能成功创建安全机制，以防止重播攻击或中间人攻击等事项。

注册其他设备

用户通常现在安装了相同应用的多个设备。 将 Windows Hello 与多个设备配合使用时，这如何工作？

使用 Windows Hello 时，每个设备都将创建唯一的私钥和公钥集。 这意味着，如果希望用户能够使用多个设备，后端必须能够存储此用户的多个公钥。 有关表结构示例，请参阅“注册新用户”部分中的数据库关系图。

注册另一台设备与首次注册用户几乎相同。 你仍然需要确保注册此新设备的用户确实是他们声称的用户。 可以使用今天使用的任何双因素身份验证机制来实现此目的。 可通过多种方式安全地实现此目的。 这一切都取决于你的方案。

例如，如果仍然使用登录名和密码，则可以使用该登录名对用户进行身份验证，并要求他们使用其验证方法之一，如短信或电子邮件。 如果没有登录名和密码，还可以使用其中一个已注册的设备并将通知发送到该设备上的应用。 MSA 验证器应用就是一个示例。 简言之，应使用通用的 2FA 机制为用户注册额外的设备。

注册新设备的代码与首次注册用户（从应用内部）完全相同。

var keyCreationResult = await KeyCredentialManager.RequestCreateAsync(
    AccountId, KeyCredentialCreationOption.ReplaceExisting);

为了方便用户识别已注册的设备，可以选择将设备名称或其他标识符作为注册的一部分发送。 例如，如果要在后端实现服务，用户可以在设备丢失时注销设备，则这也很有用。

在应用中使用多个帐户

除了支持单个帐户的多个设备外，在单个应用中也经常支持多个帐户。 例如，你可能从应用内连接到多个 Twitter 帐户。 使用 Windows Hello，可以创建多个密钥对并支持应用中的多个帐户。

执行此操作的一种方法是保留隔离存储上一部分中所述的用户名或唯一标识符。 因此，每次创建新帐户时，都会将帐户 ID 存储在独立存储中。

在应用 UI 中，允许用户选择以前创建的帐户之一或注册新帐户。 创建新帐户的流程与前面所述相同。 选择帐户是在屏幕上列出已存储帐户的问题。 用户选择帐户后，使用帐户 ID 在应用中登录用户：

var openKeyResult = await KeyCredentialManager.OpenAsync(AccountId);

流的其余部分与前面所述相同。 为了清楚起见，所有这些帐户都受同一 PIN 或生物识别手势的保护，因为在此方案中，它们正在使用同一 Windows 帐户的单个设备上。

将现有系统迁移到 Windows Hello

在本简短部分中，我们将解决使用存储用户名和密码的数据库的现有打包应用和后端系统。 这些应用在应用启动时从用户收集凭据，并在后端系统返回身份验证质询时使用这些凭据。

在这里，我们将介绍需要更改或替换哪些部分才能使 Windows Hello 正常工作。

我们已经在前面的部分中介绍了大多数技术。 将 Windows Hello 添加到现有系统涉及在代码的注册和身份验证部分中添加几个不同的流。

一种方法是让用户选择何时升级。 用户登录到应用并检测到该应用和 OS 能够支持 Windows Hello 后，可以询问用户是否希望升级凭据以使用此新式且更安全的系统。 可以使用以下代码来检查用户是否能够使用 Windows Hello。

var keyCredentialAvailable = await KeyCredentialManager.IsSupportedAsync();

UI 可能如下所示：

如果用户选择开始使用 Windows Hello，请创建 前面所述的 KeyCredential 。 后端注册服务器将公钥和可选证明语句添加到数据库。 由于用户已通过用户名和密码进行身份验证，因此服务器可以将新凭据链接到数据库中的当前用户信息。 数据库模型可能与前面所述的示例相同。

如果应用能够创建用户 KeyCredential，它会将用户 ID 存储在独立存储中，以便用户可以在应用再次启动后从列表中选取此帐户。 从这一点开始，流完全遵循前面各节中所述的示例。

迁移到完整 Windows Hello 方案的最后一步是在应用中禁用登录名和密码选项，并从数据库中删除存储的哈希密码。

总结

Windows 引入了更高级别的安全性，也易于实施。 Windows Hello 提供了一种新的生物特征登录系统，可以识别用户，并主动挫败绕过正确身份识别的努力。 然后，它可以提供多层密钥和证书，这些密钥和证书永远不会在受信任的平台模块外部显示或使用。 此外，还可以通过可选地使用证明标识密钥和证书来进一步的安全层。

作为开发人员，可以使用本指南设计和部署这些技术，轻松将安全身份验证添加到打包的 Windows 应用推出，以保护应用和后端服务。 所需的代码最少且易于理解。 Windows 处理繁重的工作。

灵活的实现选项允许 Windows Hello 替换或与现有身份验证系统一起工作。 部署体验是无痛和经济的。 无需其他基础结构即可部署 Windows 安全性。 借助内置于操作系统的 Microsoft Hello，Windows 为新式开发人员面临的身份验证问题提供了最安全的解决方案。

任务完成！ 你刚刚使互联网成为一个更安全的地方！

其他资源

文章和示例代码

• Windows Hello 概述
• 规划Windows Hello 企业版部署
• GitHub 上的 Windows Hello UWP 代码示例

术语

术语	定义
AIK	证明标识密钥用于提供此类加密证明（TPM 密钥证明），方法是对不可迁移密钥的属性进行签名，并向信赖方提供属性和签名进行验证。 生成的签名称为“证明语句”。 由于签名是使用 AIK 私钥创建的（只能在创建它的 TPM 中使用），信赖方可以信任证明的密钥确实不可迁移，并且不能在该 TPM 外部使用。
AIK 证书	AIK 证书用于证明 TPM 中是否存在 AIK。 它还用于证明 AIK 认证的其他密钥源自该特定 TPM。
IDP	IDP 是标识提供者。 例如，Microsoft帐户的 IDP 生成Microsoft。 每当应用程序需要使用 MSA 进行身份验证时，都可以调用 MSA IDP。
PKI	公钥基础结构通常用于指向组织本身托管的环境，并负责创建密钥、撤销密钥等。
TPM	受信任的平台模块可用于创建加密公钥/私钥对，以便私钥永远不能在 TPM 外部显示或使用（即密钥不可迁移）。
TPM 密钥证明	以加密方式证明密钥是 TPM 绑定的协议。 这种类型的证明可用于保证特定计算机的 TPM 中发生特定加密操作

相关主题

• Windows Hello 登录应用
• Windows Hello 登录服务