编辑
Amazon Web Services 的 Dean H. Saxe，FIDO 企业部署工作组联合主席
1. 引言
去年 FIDO Alliance、Apple、Google 和 Microsoft 宣布他们打算支持密钥，即 FIDO 凭证，这些凭证可以备份并在注册到同一密钥提供商的设备上可用。 从那时起，我们已经看到多个平台和密码管理器对密钥和测试版实施的支持。 企业对通行密钥表示了兴趣，但不知道从哪里开始，什么类型的通行密钥在其环境中起作用，或者通行密钥如何适应他们的身份验证策略。
请务必注意， FIDO Alliance 已使用术语“密钥”来描述任何无密码 FIDO 凭证。 这包括 synced passkeys（与原始公告和意图一致）以及 device-bound passkeys – 这些密钥是 FIDO 身份验证凭证，无法离开已发布的设备（例如，在 FIDO 安全密钥上）。
在以下系列论文中，FIDO 企业部署工作组 （EDWG） 将为领导者和从业者提供从中小型企业扩展到大型企业的 FIDO 解决方案的部署指导。 鉴于 FIDO 凭证有多种不同的使用案例，从synced passkeys密钥到device-bound passkeys，本系列将确定关键决策点，以确定哪些解决方案适合不同的企业使用案例。 企业可能会发现需要多种基于 FIDO 的解决方案来满足其不同的用例。
当组织评估如何在其环境中使用通行密钥时，他们需要确定其组织的法律、法规和安全要求，并评估 synced passkeys 和设备 device-bound passkeys 如何满足这些要求。
我们假设读者对 FIDO 协议有很高的理解，如果没有，请咨询 https://passkeys.dev/。
2. 为什么选择 通行密钥？
密码是超过 80% 的数据泄露的根本原因，高达 51% 的密码被重复使用，使其受到撞库攻击。 由于其设计，FIDO 凭证本质上比密码更安全。 这些凭证是范围限定为特定源（例如 https://fidoalliance.org/）的唯一加密密钥对，以防止被不相关的服务发现。 与密码不同，FIDO 凭证具有高度的防网络钓鱼能力，并且凭证（私钥）不能从信赖方 （RP） 服务器中窃取。
FIDO 凭证可用于各种使用案例（从低保证到高保证），从而平衡用户体验、便利性和安全性。 身份验证器（从硬件安全密钥到手机、平板电脑和笔记本电脑中的生物识别硬件，再到密码管理器）使企业能够为其独特的环境选择合适的工具。
虽然所有 FIDO 凭证都基于加密密钥对，但它们并不表现出相同的安全特征，也不都适用于所有使用案例。 例如，硬件安全密钥可能是经过 FIPS 认证的设备，具有 device-bound passkeys。 RP 可以根据注册时提供的认证声明来识别这些凭证。 另一方面，同步密钥实施通过基于云的服务同步密钥材料。 在第三方服务中导出和管理凭据会引入其他注意事项，可能无法满足每个组织的安全要求。 第 4 页的表格总结了设备绑定 synced passkeys的使用案例和属性。
在阅读本系列时，您可能会遇到 FIDO 生态系统独有的术语。 有关这些术语的定义，请参阅 FIDO 技术术语表 。
我们预计大多数企业将拥有跨越多个这些论文的使用案例。 无论组织身处何处，他们都可以立即开始使用 FIDO 凭证来减少凭证重用、网络钓鱼和撞库攻击。
在第一篇文章中，我们研究了组织如何将密钥部署到使用密码作为唯一身份验证因素的用户。 通过部署密钥，公司可以立即降低员工在使用公司或个人设备进行身份验证时遭受网络钓鱼或撞库攻击的风险。 https://fidoalliance.org/fido-in-the-enterprise/。
许多组织已经部署了经典的第二因素身份验证解决方案，例如 SMS OTP、TOTP 和 HOTP。 在许多情况下，这些部署是战术性响应，旨在降低网络钓鱼攻击的成功率。 但是，这些机制都不能免受网络钓鱼的影响。 在本系列的第二篇论文中，我们研究了密钥如何在改善身份验证用户体验的同时取代较少的网络钓鱼防御机制。 https://fidoalliance.org/fido-in-the-enterprise/。
受监管行业的企业可能有义务为其部分或全部员工使用更高级别的保证认证。 这些公司（或具有严格安全要求的其他公司）可能能够部署 synced passkeys和/或 device-bound passkeys，以满足其身份验证要求。 本系列的第三篇论文提供了关于确定哪些基于 FIDO 的解决方案可以满足这些要求的指导。 https://fidoalliance.org/fido-in-the-enterprise/。
最后一篇论文介绍了在功能或法规要求需要高度保证的情况下使用device-bound passkeys
认证。
这些方案使用证明数据来安全地验证用于生成和管理密钥的硬件设备。
此证明数据可用于确保符合受监管企业和使用案例的法规和安全要求。 https://fidoalliance.org/fido-in-the-enterprise/。
| 设备绑定 通行密钥 | 已同步 通行密钥 | |
|---|---|---|
| 低保证 | 足够 | 足够 |
| 中等保证 | 足够 | 可能就足够了 |
| 高保证 | 可能就足够了 取决于验证器和 法规/合规性要求（例如 FIPS 140) | 不足 |
| 可移植性 | 可以在设备和生态系统之间移植，例如硬件安全密钥） 受可用连接选项（USB、 NFC、BLE） | 在 通行密钥 Provider 生态系统中可移植 |
| 可共享/可复制 | 否 – 无法导出设备绑定的凭据 | 可能支持。
取决于密钥 供应商 |
| 账户恢复 | 通过注册来最大限度地减少凭据丢失情况 多个 device-bound passkeys 通过定义的企业 RP 进行帐户恢复 机制 | 通过 通行密钥 Provider 定义的机制进行凭证恢复，以引导新设备 通过定义的企业 RP 进行帐户恢复 机制 |
| 费用 | 获取和预置的潜在额外成本 硬件安全密钥（如果设备绑定密钥为 在 Platform 生态系统中不可用 | 内置于现有平台 第三方/非平台密钥提供商可能产生的额外费用 |
3. 鸣谢
- Vittorio Bertocci， Okta
- 格雷格·布朗，Axiad
- 杰罗姆·贝夸特，Axiad
- 蒂姆·卡帕利，Microsoft
- Matthew Estes，Amazon Web Services
- John Fontana，Yubico，FIDO 企业部署工作组联合主席
- Rew Islam，Dashlane
- Sue Koomen，美国运通
- 杰夫·克雷默 （Jeff Kraemer），Axiad
- 凯伦·拉森 （Karen Larson），Axiad
- 肖恩·米勒，RSA
- Tom Sheffield，Target Corporation
- Johannes Stockmann，Okta
- Shane Weeden，IBM 公司
- 蒙蒂·怀斯曼，超越身份
- 来自 Amazon Web Services 的 Khaled Zaky
- FIDO 企业部署工作组成员
