--- url: 'https://www.corbado.com/zh/blog/device-bound-synced-passkeys' title: '设备绑定型与同步型通行密钥对比 (SCA 与通行密钥一)' description: '探索同步型与设备绑定型通行密钥的区别，并了解硬件安全模块（安全飞地、TEE、TPM）的作用。' lang: 'zh' author: 'Vincent Delitz' date: '2026-05-24T16:30:41.072Z' lastModified: '2026-05-24T16:35:30.697Z' keywords: '设备绑定型通行密钥, 同步型通行密钥, 通行密钥设备, 可同步通行密钥' category: 'Passkeys Strategy' --- # 设备绑定型与同步型通行密钥对比 (SCA 与通行密钥一) ## 概述：使用通行密钥进行强客户身份验证 - PSD2 与 SCA 要求分析 - SCA 要求对通行密钥意味着什么 - PSD3 / PSR 对通行密钥的影响 ## 1. 简介：设备绑定型与同步型通行密钥 在我们之前的通行密钥 PSD2 博客文章中，我们讨论了 Revolut 和 Finom 等金融科技公司如何使用通行密钥，以及它们如何提高[银行业](https://www.corbado.com/passkeys-for-banking)的数字安全性。 通行密钥主要有两种形式：**同步型通行密钥（synced passkeys）**和**设备绑定型通行密钥（device-bound passkeys）**。虽然同步型通行密钥允许用户在多台设备上无缝进行身份验证，但**设备绑定型通行密钥**严格链接到特定的通行密钥设备，如硬件安全密钥或本地身份验证器。 通过这由四部分组成的系列博客文章，我们将深入分析不同类型的通行密钥（设备绑定型与同步型）如何符合 SCA 和 PSD2 要求。 本系列的第一部分主要是了解**设备绑定型与同步型通行密钥之间的区别**。 第二部分以通俗易懂的方式解释了 PSD2 和强客户身份验证（SCA）的含义，并阐述了其历史发展。 第三部分介绍了不同类型的通行密钥如何符合 SCA 要求，以及这对考虑采用通行密钥的银行、金融科技公司和金融机构意味着什么。 系列的第四部分也是最后一部分总结了 PSD3 / PSR 未来对 SCA 和通行密钥的意义。 ## 2. 强客户身份验证、PSD2 与通行密钥 在上一篇博客文章发布后，我们收到了许多关于我们在通行密钥立场上的后续问题，特别是与 PSD2 框架下的 SCA 相关的问题。大家不仅对通行密钥的应用感兴趣，还非常想了解它们如何符合**监管技术标准（RTS）**。此外，利益相关者也很好奇监管机构（包括**欧洲银行管理局，EBA**）关于使用通行密钥的潜在解释和指导。 认识到这一点，我们旨在深入探讨通行密钥如何集成到 PSD2 指令、关于 SCA 的 RTS 中，并阐明我们对使用该技术的立场。我们还将探讨现有的 EBA 问答，以说明监管机构和 EBA 可能会如何看待通行密钥。此次探讨不仅将解决同步型和设备绑定型通行密钥之间的区别，还将探讨它们在增强安全性和用户体验方面的实际应用。 通过了解这些细微差别，利益相关者可以做出明智的决策，这不仅符合 PSD2 的严格要求，而且还能利用最新的身份验证技术来保障数字交易的安全。我们的讨论旨在进一步阐明将通行密钥集成到身份验证流程中的途径，确保安全措施跟上不断发展的数字格局。 当然，受 PSD2 监管的每个实体都需要自行决定如何实现监管目标，因为每种实施方案都有其自身的复杂性。这种个性化方法承认，虽然监管框架提供了统一的标准，但由于各组织在运营环境、技术能力和用户群方面的独特性，这些标准的实际应用将在不同的组织中存在显著差异。 因此，虽然我们的见解旨在提供指导和信息，但并非规定性的。每个实体在将通行密钥集成到其安全和身份验证协议中时，必须考虑其具体情况和挑战。 [Watch on YouTube](https://www.youtube.com/watch?v=V1Pc4Gl0xKc) ## 3. 从设备绑定型通行密钥到同步型通行密钥 为了理解设备绑定型和同步型通行密钥之间的区别，我们将简要探讨生态系统的发展。 ### 3.1 什么是设备绑定型通行密钥（单设备通行密钥）？ 在深入研究设备绑定型通行密钥的技术细节之前，我们先来看看它的历史和发展。 ![设备绑定型通行密钥](https://www.corbado.com/website-assets/device_bound_passkey_effe25ab99.png) #### 3.1.1 设备绑定型通行密钥的历史 从历史上看，WebAuthn（通行密钥底层的标准）中的身份验证机制与物理设备紧密耦合：安全密钥（例如 YubiKeys）。在通行密钥被广泛采用之前，[绑定到单个身份验证器的 FIDO2 凭据代表了安全性的黄金标准](https://github.com/w3c/webauthn/wiki/Explainer:-broadening-the-user-base-of-WebAuthn)。这些凭据链接到它们所在的设备。这种绑定的影响是显而易见的：凭据无法在其原始硬件之外转移或使用。 这种方法虽然通过将身份验证过程本地化到单个设备来增强安全性，但不可避免地遇到了阻碍其广泛采用的实际限制，尤其是在普通非技术消费者中。用户在每次登录尝试时都必须提供其身份验证设备，这不仅限制了用户的移动性，还在设备丢失、损坏或无法立即访问的情况下引发了担忧。 此外，消费者也不愿投资额外的硬件。从历史上看，专用安全密钥的拥有和使用率在普通消费者中非常低。购买专门用于身份验证目的的硬件，尽管其安全性有所提高，但并没有得到大多数 B2C 用户的认可，而这些用户通常是广泛网络钓鱼攻击或凭据填充攻击的目标。 #### 3.1.2 设备绑定型通行密钥的技术细节 **设备绑定型通行密钥**的特点是它们被具体分类为可发现（discoverable）和不可发现（non-discoverable）凭据，这种区别主要定义了它们的可发现性。但区分**设备绑定型密钥**的关键因素封装在 WebAuthn 凭据属性中，特别是通过 `isBackupEligible` 和 `isBackupSynchronized` 标志。对于**设备绑定型通行密钥**，这两个字段都设置为零，表明这些凭据不具备跨设备备份或同步的条件。这些特征突出了它们与创建这些凭据的物理设备之间的内在联系，确保凭据始终绑定并在该特定硬件上唯一可用。 在实践中，设备绑定凭据的一个显著例子出现在 Windows 生态系统中。Windows 10 和 Windows 11 上的 Windows Hello 凭据仍然是设备绑定的——Windows Hello 本身尚无法跨设备同步通行密钥。然而，微软已经迈出了重要的第一步，[在 Microsoft Edge 中引入了通行密钥保存和同步功能](https://blogs.windows.com/msedgedev/2025/11/03/microsoft-edge-introduces-passkey-saving-and-syncing-with-microsoft-password-manager/)（从 Edge 142 开始）。这种通过 Microsoft Password Manager 进行的浏览器级同步，使得在使用 Edge 时可以在 Windows 设备上同步通行密钥，这类似于 Google Password Manager 在 Windows 上的 Chrome 浏览器中实现通行密钥同步的方式。这代表了 Windows 通行密钥功能的重要进步，不过它特定于 Edge 浏览器，而不是 Windows Hello 平台身份验证器。Windows Hello 通行密钥仍然是设备绑定的，但这种 Edge 集成为 Windows 上的同步型通行密钥提供了一条实用途径，而平台身份验证器本身将来也可能会演进以支持同步。 另一方面，Google 表达了对不可发现通行密钥的明确立场，表明现有的不可发现通行密钥可以在未来的实现中保持不同步。这一决定符合更广泛的原则，即不可发现凭据在某些安全上下文中发挥着至关重要的作用，它们严格绑定于设备并且不可发现，因此不能用作通行密钥。 相比之下，Apple 在 macOS 和 iOS 上采用的方法存在显著差异。与 Windows 和 Google 观察到的固定的设备绑定策略不同，[Apple 生态系统更加强烈地倾向于仅允许同步型通行密钥，尤其是在 iOS 上](https://fy.blackhats.net.au/blog/2023-02-02-how-hype-will-turn-your-security-key-into-junk/)，因此几乎不可能通过 WebAuthn 创建设备绑定型通行密钥。 各大平台策略的分化说明了管理 WebAuthn 凭据的多种方法，特别是在考虑安全性、便利性和用户可访问性之间的平衡时。虽然设备绑定型通行密钥通过确保凭据无法移出或在其预期设备之外被滥用来提供高水平的安全性，但行业仍在不断发展，寻求在不牺牲用户体验和移动性的情况下维持安全标准的解决方案。 ### 3.2 什么是同步型通行密钥（多设备通行密钥）？ 在这里，我们在分析技术细节之前先看看同步型通行密钥的历史发展。有时，同步型通行密钥也称为**可同步通行密钥（syncable passkeys）**。 ![同步型通行密钥](https://www.corbado.com/website-assets/synced_passkey_042125aca6.png) #### 3.2.1 同步型通行密钥的历史 在 2021 年中后期发布 WebAuthn Level 2 和 CTAP 2.1 规范之后，WebAuthn 工作组发起了一项重大的行业倡议，旨在克服阻碍 WebAuthn 标准替代密码并提高采用率的主要障碍。该倡议主要集中在两个关键领域：消除对额外硬件安全设备的需求，并在保持与现有标准完全向后兼容的同时，降低与丢失身份验证器相关的风险。 ##### 3.2.1.1 利用平台身份验证器作为安全硬件模块 第一个挑战——消除对新硬件的需求——通过利用现代消费者设备中内置的平台身份验证器（例如 Touch ID、Face ID、Windows Hello）得到了解决。 ![硬件安全模块 HSM TPM TEE 安全飞地](https://www.corbado.com/website-assets/hardware_security_modules_hsm_tpm_tee_secure_enclave_11118d359e.png) 现代设备越来越多地配备专用安全模块，例如 Android 上的可信执行环境（TEE）、iOS 和 macOS 上的安全飞地（Secure Enclave），以及 Windows 设备上的可信平台模块（TPM）。这些完整的安全密钥库为通行密钥提供了坚实的基础，有效地充当了内置的“安全密钥”。这种方法使得公钥密码学能够被广泛采用，而这种安全级别以前只能通过外部硬件安全密钥（例如 YubiKeys）来实现，并且主要局限于懂技术的个人或高度受监管行业的组织。 通过利用 TEE、安全飞地或 TPM 的功能，WebAuthn 协议有能力提供强大的基于密码学的用户身份验证机制。现在，复杂的身份验证方法变得对公众友好且易于访问，而不需要额外的专业硬件。 这种演进是对数字安全方法的一项非常强有力的改进，强调了以用户为中心的安全解决方案在推动广泛采用中所起的关键作用。结合同步型通行密钥以及优化的通行密钥创建和通行密钥登录流程的组织，看到了最高的采用率。通过使用当代设备的安全特性，行业努力成功解决了消除外部硬件必要性的最初障碍。 这一发展是数字身份验证生态系统新时代的关键一步，在这个新时代，公钥密码学的广泛应用直接适用于各种用例，同时也简化了用户的身份验证。 ##### 3.2.1.2 通行密钥同步到云端 为了解决与丢失手机以及由此导致丢失手机上存储的通行密钥相关的风险，行业倡议侧重于支持将可发现凭据同步到云端。这种方法有效地将凭据从严格的设备绑定转变为多设备使用，或者更准确地说，绑定到用户与其云提供商（例如 Apple 设备的 iCloud 或 Android 设备的 Google）的账户上。 这种实用的解决方案意味着，即使用户的手机丢失或被更换，以前建立的凭据也不会永久丢失。相反，可以从用户的云账户检索这些凭据并同步到新设备。这种转变显著减少了以前与丢失物理身份验证器相关的不便和安全风险。 通过利用云同步，通行密钥现在可以在用户的设备之间无缝过渡，无论使用何种特定设备，都能保持其完整性和安全性。例如，当用户从新设备登录网站时，可以自动建议使用云账户中可用的凭据进行身份验证。如果需要，可以将这些凭据传输到新设备，从而跨不同平台和设备保持一致且安全的身份验证体验。 这种向云同步、基于账户绑定的凭据过渡代表了对数字安全的务实方法。它承认了现代设备使用的现实以及设备交换的普遍现象（无论是由于丢失、损坏还是升级）。通过将凭据绑定到用户的云账户——无论是 Apple 的 iCloud 还是 Google 的云服务——该解决方案不仅降低了与丢失设备相关的风险，而且还增强了用户跨多台设备管理和恢复其数字身份的能力。 这一发展有效地拓宽了 WebAuthn 强大的基于密码学的身份验证机制的适用性，使其更适应现实世界中的用户场景。它还确保了强身份验证易于访问和管理，不仅针对那些具有技术背景或在高度受监管的行业中的人，也针对带着多台设备探索数字世界的普通用户。 #### 3.2.2 同步型通行密钥的技术细节 同步型通行密钥也被称为可发现凭据（discoverable credentials）或常驻密钥（resident keys）。它们通过两个关键属性与设备绑定型密钥区分开来：`isBackupEligible` 和 `isBackedUp` 具有不同的值。对于同步型通行密钥，`isBackupEligible` 标志设置为 1，表明这些凭据符合备份条件。在成功同步到云端后，`isBackedUp` 标志也设置为 1，确认凭据已正确同步。需要注意的是，同步状态可能会随时间变化，反映设备使用和管理的动态特性。 当平台通过将 `requireResidentKey` 参数设置为 **required** 或 **preferred** 来请求常驻密钥时，支持云服务的平台会自动创建同步型通行密钥。这个过程确保用户能够依赖他们的凭据，从而能在各台不同设备上访问。在 Windows 上，同步型通行密钥现在可以通过 Microsoft Edge/Microsoft Password Manager（浏览器级同步）获得，而 Windows Hello 平台身份验证器凭据仍为设备绑定。具备通行密钥管理功能的第三方密码管理器（如 Dashlane、KeePassXC、1Password）也提供跨平台同步。在使用同步型通行密钥的场景中，`isBackupEligible` 和 `isBackedUp` 标志设置为 1，指示符合备份条件且已成功同步。 此外，虽然目前仍然可以识别出存储了通行密钥的特定身份验证器，但大多数这些凭据缺乏证明（attestation），这意味着无法通过密码学验证它们的来源。这一方面突出了一个潜在的限制，即在完全通过 WebAuthn 的标准机制来保证同步型通行密钥的安全谱系方面存在不足。 同步型通行密钥的发展从本质上拓宽了可发现凭据的范围，将它们集成到基于云的同步框架中。通过使这些密钥符合备份条件并确保它们在用户的设备间同步，WebAuthn 解决了数字身份验证中的两大挑战：由于设备丢失导致失去访问权限的风险，以及管理多个设备绑定凭据的不便。 ### 3.3 为实现更大目标而牺牲 WebAuthn 凭据的单设备绑定 从设备绑定型通行密钥向同步型通行密钥的转变引发了 WebAuthn 工作组内部的重要对话，主要围绕对高级安全措施的必要性、涉及的法律问题以及既对消费者友好又安全的妥协方案展开。 采用同步型通行密钥受到了欢迎，因为它有望通过云同步和无缝多设备功能等特性提高用户便利性和安全性。然而，它在一些依赖方（RPs）中引起了一些不安，特别是在具有较高安全要求的环境中对安全性和合规性的影响方面。争论的核心是需要一种机制来确保即使是同步型通行密钥也能保持与特定设备的连接，这个概念对于处理敏感交易或在严格监管标准下运营的依赖方至关重要。 对于无法或不愿采用通行密钥的 RP，在关键应用程序中缺乏将这些凭据绑定到特定设备的可靠方法，构成了重大挑战。一些 RP 认为此类机制非常重要。这种设备绑定功能的缺失（这一期望或许未被明确说明，但肯定是意料之中的），从他们的角度来看是一个严重的意外，并破坏了信任。 讨论得出的结论是，应该协调各方利益，但首先，推广通行密钥的更大目标应优先考虑。在讨论中，[devicePubKey 扩展](https://github.com/w3c/webauthn/issues/1658) 被视为解决这些担忧的一种方法，但后来被 **supplementalPubKeys** 所取代，后者在当前的 WebAuthn Level 3 草案中采取了更广泛的方法。不幸的是，这一方法也在 2024 年 8 月被中止了。 ### 3.4 两全其美：通行密钥与 supplementalPubKeys 扩展 \[截至 2024 年 8 月已弃用] 让我们分析一下 supplementalPubKeys 扩展的折中方案是如何形成的，以及这在技术上意味着什么。 #### 3.4.1 从 devicePubKey 到 supplementalPubKeys 扩展 围绕从 **devicePubKey** 扩展向 **supplementalPubKeys** 扩展过渡的讨论突显了 WebAuthn 规范的动态本质。最初，**devicePubKey** 旨在通过设备绑定的公钥增强安全性，但后来它被在 [WebAuthn Level 3 编辑工作草案](https://w3c.github.io/webauthn/#sctn-supplemental-public-keys-extension)中提出的 **supplementalPubKeys** 所取代。这个较新的扩展通过允许多个密钥来增强身份验证流程，提供了一个更全面的解决方案。 辩论的核心集中在平衡增强的安全措施与跨不同设备和平台更广泛的采用和通行密钥的实际效用之间。**supplementalPubKeys** 扩展代表了这些优先事项的结合，能够实现更严格的身份验证。例如，它通过允许带有证明声明的附加“子密钥”，以适应要求某些身份验证标准的法规。这些密钥可以作为合规性信号以满足身份验证要求，有可能在某些条件下减少额外登录质询的需要（即使使用通行密钥）。 [直接来自 WebAuthn 草案的示例](https://w3c.github.io/webauthn/#sctn-supplemental-public-keys-extension)： “_假设在网站上出现一个登录请求，同时伴随一个以前从未在用户的该账户上见过的地理位置信号，并且不在该账户观察到的典型使用时间内。此时可认为风险足够高从而拒绝该请求，即使仅有多设备凭据提供断言也是如此。但如果还能出示由与该用户高度建立关联的且受设备绑定的补充密钥提供的签名，那可能就会打破这种平衡并允许通过。_” 在讨论期间，强调这些扩展仅适用于对安全性要求极高（例如在[政府](https://www.corbado.com/passkeys-for-public-sector)背景下）的 RP。 通过吸收反馈并解决特定的用例——也包括受监管的金融交易以及在多设备凭据环境中对设备绑定信号的需求——WebAuthn 社区旨在解决安全和互操作性两个方面的问题。因此，**supplementalPubKeys** 扩展是一种致力于提供稳健安全特性的方法，同时支持无缝的用户体验和广泛的兼容性，这对于通行密钥的广泛采用至关重要。这是一个完全可选的扩展，不会干扰过去 2 年中已经见到的通行密钥实现。 向更具包容性和灵活性的框架发展，突显了 WebAuthn 社区致力于改善 Web 身份验证方法，甚至适用于更严格的使用案例。 #### 3.4.2 supplementalPubKeys 的技术细节 WebAuthn 中引入的 **supplementalPubKeys** 扩展允许在主凭据旁边使用额外的密钥对。 ![补充公钥图表](https://www.corbado.com/website-assets/supplemental_pub_key_chart_b976bf5115.png)_取自原始的 [GitHub issue](https://github.com/w3c/webauthn/pull/1957)_ 该图显示了取自原始 [GitHub issue](https://github.com/w3c/webauthn/pull/1957) 的 **supplementalPubKey** 概念（pk = passkey（通行密钥），pspk = provider supplemental key（提供商补充密钥），dspk = device supplemental key（设备补充密钥））。 以下是它的工作原理及其预期用途的细分： **supplementalPubKey 的目的和功能** - **仅保留一个中央通行密钥凭据：**请记住，只有一把中央通行密钥仍是用户身份验证的主要方法，而附加密钥提供额外的安全性与保障层，这一点非常重要。这种结构保持了使用单个核心通行密钥进行跨多设备身份验证的简单性和效率，确保了无缝的用户体验。同时，补充密钥旨在增强身份验证上下文，向依赖方 (RP) 提供有关安全环境或合规特定身份验证标准的附加信号。这些补充密钥并非独立的身份验证方法，而是补充主通行密钥，通过设备完整性的证据强化其可信度。 - **设备绑定密钥（Device-Bound Keys）**：这些专门绑定于某一台设备。它们可以保证身份验证请求来自于先前已经过身份验证的受信任设备。它们在任何情况下都不会被同步。 - **提供商绑定密钥（Provider-Bound Keys）**：这些密钥具有“提供商”作用域，这意味着它们可以根据身份验证提供商的策略或提供商的特定证明来提供额外的保证。例如，提供商可能仅在用户完成更高水平的身份验证（例如 2FA）之后才发布此类密钥。 - **多个公钥**：与仅允许一个设备绑定公钥的前身 **devicePubKey** 扩展不同，**supplementalPubKeys** 允许包含一种或两种补充密钥类型。这些密钥可用于不同目的和作用域——即设备绑定和提供商绑定作用域。 **supplementalPubKey 的用例和示例** 1. **增强安全性**：在网站（依赖方）必须遵守某些增强的安全身份验证标准的情况下，补充密钥可用于满足这些要求。如果网站以前见过并验证过此补充密钥，它可以允许用户绕过额外的登录质询，因为可以通过先前的信号确认设备连续性。 2. **风险管理**：对于看似有风险的登录请求（例如，来自新的地理位置或异常时间），具有用户帐户使用历史的设备绑定补充密钥的存在，可以降低感知的风险并允许请求继续进行，而在其他情况下该请求可能已被阻止。 **supplementalPubKey 的技术层面** - **无单独的凭据 ID：** 补充密钥不是用户凭据，它们没有自己的凭据 ID。 - **证明声明（Attestation Statements）**：补充密钥可以选择性地具有证明。这些对于理解补充密钥的作用域和安全级别至关重要。证明可以指示受硬件绑定密钥保护的级别，或用于其他类型补充密钥的策略。 - **对依赖方的实现**：依赖方可以在身份验证过程中请求这些补充密钥。然而，处理多个密钥和证明声明的复杂性意味着，此扩展最适合具有特定安全需求的实体，例如在严格监管要求下运营的银行或服务。 至关重要的是要指出，截至 2024 年 4 月，**supplementalPubKeys** 扩展尚未被任何主流浏览器采用，且 WebAuthn Level 3 规范仍在制定中并可能发生更改。此功能是否包含在规范的最终版本中及其潜在的未来实现和采用仍然不确定，因为目前它仅处于编辑草案阶段。 #### 3.4.3 2024 年 8 月 supplementalPubKeys 弃用 截至 2024 年 8 月，**supplementalPubKeys** 扩展已被正式停用。WebAuthn 工作组决定移除此功能，原因是支持不足。该扩展的弃用也凸显了一个新方向。目前，**FIDO 联盟**正在致力于开发不同的方法来支持具有高安全要求的**依赖方**。这一即将推出的解决方案预计将弥补因停止使用 **supplementalPubKeys** 而留下的空白，并提供新的方法来加强在严苛安全标准至关重要的场景下的身份验证流程。 有关弃用的更多详细信息，请参阅官方的 [WebAuthn GitHub pull request](https://github.com/w3c/webauthn/pull/2109)。 ## 4. Corbado 在实践中如何处理设备绑定与同步型通行密钥之间的差异 理解设备绑定和同步型通行密钥之间的区别是必要的，但银行还需要工具在规模化运作时将这些差异付诸实施。Corbado 的平台提供设备信任情报，可自动对通行密钥类型进行分类，并对每种类型应用正确的 SCA 处理方式。 ### 跨通行密钥类型的设备信任可见性 Corbado 的设备信任仪表板显示了设备绑定型和同步型通行密钥在生产环境中的不同表现。设备绑定型通行密钥实现了更高的成功率（99.1%），同时需要进行升阶认证（step-up）的要求为零，而带有设备信任信号的同步型通行密钥达到 98.4%，新设备上有少量的升阶认证率。 ![Corbado 设备信任仪表板](https://www.corbado.com/website-assets/corbado_device_trust_dashboard_42ce934484.png) 该仪表板还能追踪设备分类——识别哪些设备为单个用户专用（在典型的[银行业](https://www.corbado.com/passkeys-for-banking)部署中占 92%），哪些是两个用户共享（7%），以及哪些是共享/自助终端设备（0.8%）。这种分类可直接反馈到 SCA 合规性决策中。 ### 针对不同通行密钥场景的基于策略的控制 无需将所有通行密钥一视同仁，Corbado 的信任策略允许银行基于通行密钥类型、设备状态以及信任级别实施不同的规则。已知设备上的设备绑定型通行密钥可获得无摩擦身份验证，而新设备上的同步型通行密钥会触发升阶验证——这正是 PSD2 的 SCA 框架所要求的细致入微的方法。 ![Corbado 信任策略配置](https://www.corbado.com/website-assets/corbado_trust_policy_80ad56409f.png) 这意味着银行可以自信地部署同步型通行密钥以提供更好的用户体验，同时利用设备绑定型通行密钥来保持其为高安全场景所提供的严格设备控制——所有这些通过策略配置管理，无需分离的身份验证流。 > **Corbado 对 PSD2/SCA 与通行密钥的立场：** 通行密钥（无论是设备绑定型还是同步型）都可以是符合 SCA 要求的。每家机构都必须主导自身的 SCA 风险评估，但证据是显而易见的：通行密钥固有地提供了两种 SCA 因素——拥有（在硬件安全模块或云钥匙串中的私钥）+ 固有特征（生物识别）或知识（PIN）。关于“拥有”因素的争论虽然很细微但可以解决——该行业主要倾向于三种方式：(1) **通行密钥直接原样使用**（如 Revolut, Finom） - 固有特征 + 通过持有私钥设备的拥有因素；(2) **通行密钥 + Cookie/会话绑定**（如 PayPal, Comdirect） - 为保守解释而引入的额外拥有信号；(3) **密码学绑定 (DBSC/DPoP)** - 受硬件绑定的拥有证明，具有最强保证。目前尚不存在单一“正确”的解释。对于 SCA 需要一种注重结果的方法——侧重于可证明的抗网络钓鱼能力，而不是僵化的因素分类。动态链接对于使用通行密钥的[支付](https://www.corbado.com/passkeys-for-payment)而言仍然是一项单独的要求。 ## 常见问题 ### 设备绑定型通行密钥如何增强安全性？ 设备绑定型通行密钥是严格与创建它们时的设备绑定的 WebAuthn 凭据。与同步型通行密钥不同，它们保留在单一设备上，这使得它们在某些用例中本身就更加安全： - **防止凭据窃取**：私钥绝不会离开设备，因此攻击者无法拦截凭据。 - **防止未授权访问**：身份验证只能在创建通行密钥的特定设备上进行。 - **无云端依赖**：消除与云端数据泄露或账户劫持相关的风险。 - **高安全合规性**：满足[金融服务](https://www.corbado.com/passkeys-for-banking)（AAL3）等受监管行业对于严格的设备绑定身份验证要求。 主要缺点是便携性有限。如果设备丢失，通行密钥无法被恢复，除非用户在其他设备上注册一个新的通行密钥。 ### 为什么要引入同步型通行密钥？它们有什么优势？ 引入同步型通行密钥（多设备通行密钥）是为了解决设备绑定型通行密钥在可用性方面的挑战，特别是在缺乏便携性以及设备丢失可能导致的账户锁定问题。主要好处包括： - **多设备身份验证**：从多台设备访问帐户，而无需为每台设备手动注册新的通行密钥。 - **无丢失访问权限风险**：凭据将备份至云端（如 iCloud Keychain, Google Password Manager），以确保如果设备丢失也能恢复。 - **更好的用户体验（UX）**：省去了手动传输或重新创建凭据的需要，消除了使用阻力。 - **不需要额外硬件**：不同于硬件安全密钥，同步型通行密钥使用内置设备安全模块。 - **将强大安全性与云端便利性相结合**：端到端加密确保私钥永远不会以未加密的格式离开设备。 ## 5. 结论 在由四部分组成的系列第一部分中，我们分析了设备绑定型通行密钥和同步型通行密钥的历史和技术差异。了解这些差异将有助于我们相应地应用 PSD2 和 SCA 的要求。同时，我们通过研究不断发展的 Webauthn Level 3 标准中的最新变化，展望了未来可能发生的事情。 以下是我们系列其他部分的链接： - 第二部分“PSD2 与 SCA 要求分析（SCA 与通行密钥二）” - 第三部分“SCA 要求对通行密钥意味着什么（SCA 与通行密钥三）” - 第四部分“PSD3 / PSR 对通行密钥的影响（SCA 与通行密钥四）”