苹果一年前在 WWDC2022 中引入了 Passkey。这具有突破性意义,因为它允许将 FIDO 凭证中的私钥存储在 iCloud 密钥链中,并方便它在设备之间传播。虽然它使 FIDO 凭证易于使用,并解决了引导问题 (用户从新设备登录网站/应用程序),但它带来了一个安全缺点,即私钥不再存储在硬件 TPM 模块中。由于这个缺点,根据 NIST,Passkey 只能被分类为提供 AAL2 级保证。
下图显示了常见认证因素之间的安全强度权衡。
要达到最高安全级别,我们需要利用硬件设备。不幸的是,苹果和谷歌目前的 Passkey 实现并没有给开发者一个选择 TPM 模块的选项。
如果你真的想要很高的安全性保证怎么办?你显然可以使用物理安全密钥如 Yubikey,但这两者都昂贵且难以使用。这篇文章展示了如何利用 iOS 平台提供的原语来从零开始构建 FIDO 解决方案,利用内置的 TPM(也称为安全令牌)。
FIDO 背后的概念很简单。它利用公钥密码学,用户使用私钥对服务器的 nonce 进行签名,并证明其拥有私钥。在本文中,我们将演示如何使用原生 iOS API 来实现相同的认证流程。这不是 FIDO 协议的完整实现,但由于篇幅限制,它只关注私钥和公钥部分。但是如果你选择的话可以在这个例子的基础上扩展。
我们将使用 iOS 中的 Local Authentication 框架,它将生成一个 LAPublicKey 和 LAPrivateKey 对,存储在 TPM 模块中。然后,我们将演示如何使用 LAPrivateKey 进行签名,以及如何使用 LAPublicKey 验证签名。
注册时的凭证注册
首先,我们演示如何在注册过程中生成密钥对。我们利用 LARightStore,它会在安全区域中存储由独特密钥加密的 LAPersistedRight。我们创建一个 generateClientKeys() 函数来捕获全部逻辑。首先,我们初始化一个 LARight(),它是 “一组控制对资源或操作的访问要求的集合”。当我们调用 LARightStore.shared.saveRight() 时,会生成一个密钥对,并持久化密钥和权限,并返回一个 LAPersistedRight。我们可以通过调用 persistedRight.key.publicKey 获取新生成的密钥的公钥引用。这个公钥会被返回,以便调用者可以在服务器端持久化这个公钥用于未来验证。
// 生成密钥对
func generateClientKeys() async throws -> Data {
let right = LARight()
// 如果之前生成过密钥,在生成新密钥对前清除
try await LARightStore.shared.removeRight(forIdentifier: "fido-key")
// 生成新密钥对
let persistedRight = try await LARightStore.shared.saveRight(right, identifier: keyIdentifier)
return try await persistedRight.key.publicKey.bytes
}
注意,在 saveRight() 之前我们也调用了 LARightStore.shared.removeRight()。这是为了在相同标识符下如果之前保存了旧密钥的话删除它。
认证
在注册之后,当用户再次回到你的应用并需要登录时,我们需要通过认证流程来验证用户。下面的代码是一个简化的 FIDO 流程。首先,按照 FIDO 协议,我们需要调用服务器获取一个 nonce。nonce 用于防止重放攻击。然后,我们调用下面的函数对 nonce 进行签名。
func signServerChallenge(nonce: Data) async throws -> Data {
let persistedRight = try await LARightStore.shared.right(forIdentifier: "fido-key")
try await persistedRight.authorize(localizedReason: "Authenticating...")
// 验证我们可以签名
guard persistedRight.key.canSign(using: .ecdsaSignatureMessageX962SHA256) else {
throw NSError(domain: "SampleErrorDomain", code: -1, userInfo: [:])
}
return try await persistedRight.key.sign(nonce, algorithm: .ecdsaSignatureMessageX962SHA256)
}
这个函数先根据相同的标识符查找 LAPersistedRight。如果找到,它会请求用户授权使用该密钥,然后使用私钥对 nonce 进行签名。nonce 和它的签名应该发送到服务器进行验证。
示例代码和演示
FIDO in TPM 项目是一个演示项目,结合了上述代码片段,演示了注册和认证流程的用户界面。你也可以观看这个视频演示以查看注册和认证的用户体验。
使用该解决方案的时机
为什么你不使用平台提供的原生 WebAuthn API(iOS 上的 Authentication Services API 或 Android 上的 Credential Manager API)?有几个原因使用本文概述的自制解决方案:
强安全性 (高达 AAL3 级)。该解决方案将允许你使用内置的平台认证器 (TouchID 或 FaceID) 提供强大的安全性保证,而无需购买独立的安全密钥 (如 Yubikey)。它既安全又易于使用,因为你不需要携带额外的硬件。
更可定制的 UX 和 UI。如演示视频所示,注册体验已经大大简化,甚至可以无需用户交互就默默完成。认证体验也更简单,有很大的定制空间。特别是,你可以选择对最终用户提及 “生物识别” 或其他更熟悉的术语,因为大多数用户都没有听说过 Passkey。这为你提供了灵活性,如果你不想将功能营销为 Passkey。
不需要绑定到网站。WebAuthn 是一个遵循 FIDO 标准的 Web API。为避免钓鱼攻击,WebAuthn 要求凭证绑定到 web 域。当 iOS 和 Android 引入等效的原生 API 时,它们遵循了这种设计,要求你的应用通过通用链接绑定到 web 域。但你的应用可能没有 web 存在。此解决方案可节省设置网站和配置通用链接的麻烦。
结论
与浏览器内部仅限于 WebAuthn API 不同,在原生应用中你可以利用各种 API。如果你不想使用平台提供的 FIDO API,你实际上可以自己实现 FIDO 协议。希望这篇文章为你奠定了基础,如果你想深入进行更多定制化和更强的安全性保证。
注:本文也发表在 Passkey: AAL3 Strong Security with a Customizable Interface 来自：https://drhuanliu.medium.com/passkey-aal3-strong-security-with-a-customizable-interface-7dfdca6cb557
