Aptos Passkey 介绍

Passkey 是一种用于取代密码的认证形式，在Aptos 区块链上通过 WebAuthn 验证器实现。它的设计目的是提供更安全、更快速的用户认证方式，以及防范钓鱼攻击。用户可以在其设备上创建一个新的网站特定的公钥凭证，并通过授权手势（如 Face ID 或 Touch ID）访问它们。在交易时，用户可以使用 Passkey 代替密码生成数字签名，以验证其身份。

本 AIP 将通过为开发者和用户提供一种简单的方法来创建不可钓鱼、可恢复的私钥，从而惠及他们。影响如下：

用户友好性：

1、WebAuthn 凭证注册（私钥创建）和交易签名可以通过用户认证（如设备生物识别）简单完成

2、使用户能够通过他们的通行密钥账户与 DApp 交互，而无需安装移动或扩展钱包：即，无头钱包体验

3、通过将私钥安全地存储在 WebAuthn 认证器中，而不是浏览器存储（例如，本地存储），通行密钥消除了传统上为加密浏览器中的私钥而设置钱包密码的需要

4、在某些操作系统上，通行密钥会被备份并与多个设备无缝同步（参见备份资格）

安全性：

1、在通行密钥中，私钥不会被保存在浏览器的存储空间（例如：localStorage）中，恶意方可能通过物理访问设备或通过恶意依赖的供应链攻击来访问它

2、默认情况下，通行密钥提供一种基于同意的签名体验，并在每次签名时提示用户进行身份验证，类似于 Apple Pay 或 Google Pay

3、通行密钥绑定到一个依赖方（例如，一个像基于 Web 钱包这样的网站），并且不易受到钓鱼攻击

规范详情通行证使用了由 FIDO联盟 和 万维网联盟（W3C） 共同创建的 WebAuthn 规范 进行通行证注册和认证。在下文中，本 AIP 讨论了WebAuthn 规范在 Aptos 上用于交易认证的方式。

（一）术语

1. **无密钥账户: **无密钥账户的安全性和活跃性由 OIDC 账户支持（例如，Google 账户），而不是由密钥支持。
2. 依赖方: ** 用户试图访问的网站、应用程序或服务，负责验证用户通行密钥的签名，以确保用户是他们声称的那个人。为了简化，我们可以说“依赖方”在这个上下文中与钱包同义，因为两者都负责管理用户对私钥的访问。
3. WebAuthn 验证器: 存在于硬件或软件中的加密实体，可以为给定的依赖方注册用户，并在稍后断言拥有注册的公钥凭证，并可选地向依赖方验证用户。
4. 账户验证器: 通过交易中账户的发送者或批准者的集合授权在 Aptos 上执行交易。

（二）使用通行证创建 Aptos 账户

注册新的 WebAuthn 凭证期间，通过该设备上的 WebAuthn 认证器安全地生成了一对非对称密钥（即私钥及其关联的公钥）。与 WebAuthn 凭证关联的公钥可以用来推导链上关联的账户。控制账户的私钥将由设备上的 WebAuthn 认证器进行保护。

注册过程特别重要，原因有几个：

1. 与凭证关联的公钥仅在注册期间被公开。断言响应（使用通行密钥签名）不会返回公钥。因此，必须解析注册响应，并且与凭证相关的相关信息应该被适当地存储并由钱包在后端持久化。
2. 注册响应包括描述凭证备份特性的flags。如果通行密钥备份是一个重要的考虑因素，那么在创建链上账户之前，应该评估这些标志。

2.1 PublicKeyCredentialCreationOptions 

每个 WebAuthn 凭证都由钱包使用一组选项创建，称为PublicKeyCredentialCreationOptions。这些选项有助于配置 WebAuthn 凭证的许多方面，包括但不限于：

1. 凭证的非对称密钥类型（Ed25519、ECDSA、RSA等）
2. 在断言期间的用户验证要求
3. WebAuthn凭证是否应绑定到一个设备或可在多个平台上使用。

仔细考虑选择哪些选项非常重要，因为它们对通行证用户体验有重大影响，并且在凭证创建后无法重新配置。

下面突出显示了 PublicKeyCredentialCreationOptions 中的一些字段。

每个 WebAuthn 凭证都是由钱包使用一组选项创建的，这些选项被称为 PublicKeyCredentialCreationOptions。这些选项有助于配置 WebAuthn 凭证的许多方面，包括但不限于：

1. 凭证的非对称密钥类型（Ed25519、ECDSA、RSA等）
2. 断言期间的用户验证要求
3. WebAuthn 凭证是否应该绑定到一个设备或跨平台可用。

仔细考虑选择哪些选项非常重要，因为它们对通行密钥用户体验有重大影响，并且不能在凭证创建后重新配置。

在 PublicKeyCredentialCreationOptions 中，以下是一些被突出显示的字段。

PublicKeyCredentialParameters

为使 WebAuthn 凭证与 Aptos 兼容，pubKeyCredParams 数组应仅包含受支持的签名方案。目前只支持 secp256r1，因此数组必须有一个元素，其 alg: -7，以表示 secp256r1 是凭证类型的选择。

PublicKeyCredentialUserEntity

每个认证器存储一个凭证映射，从（rpId、userHandle）到公钥凭证源的映射。为了提供上下文，用户句柄是凭证的唯一标识，类似于 credentialId，但由钱包而不是 WebAuthn 验证器选择。如果用户在同一验证器上（在同一用户的设备/平台上）使用与现有凭证相同的 userHandle 创建另一个凭证，它将覆盖现有凭证，从而覆盖与通行证账户关联的私钥。为了避免这种情况发生，钱包必须维护一个已注册的凭证及其对应的用户句柄列表。

2.2 注册响应

成功注册凭证后，验证器将返回一个 PublicKeyCredential。在 PublicKeyCredential 中将包含一个 AuthenticatorAttestationResponse 类型的 response 字段，其中将包含大部分用于验证注册响应的信息。

对 PublicKeyCredential 中的 response 字段进行完全解码将得到一个 AuthenticatorAttestationResponse。下面是其 Rust 表示形式的示例：

code reference

pub struct AuthenticatorAttestationResponse {
    /// 这个属性包含了客户端传递给认证器的`CollectedClientData`的JSON序列化，用于生成这个凭证。确切的 JSON 序列化必须被保留，因为已经对序列化的客户端数据进行了哈希计算。
    #[serde(rename = "clientDataJSON")]
    pub client_data_json: Bytes,

    /// 这是包含在认证对象中的验证器数据。
    pub authenticator_data: Bytes,

    /// 这是新凭证的 DER [SubjectPublicKeyInfo]。如果不可用，则为 None。
    ///
    /// [SubjectPublicKeyInfo]: https://datatracker.ietf.org/doc/html/rfc5280#section-4.1.2.7
    #[serde(skip_serializing_if = "Option::is_none")]
    pub public_key: Option<Bytes>,

    /// 这是新凭证的 [CoseAlgorithmIdentifier]
    ///
    /// [CoseAlgorithmIdentifier]: https://w3c.github.io/webauthn/#typedefdef-cosealgorithmidentifier
    #[typeshare(serialized_as = "I54")] // because i64 fails for js
    pub public_key_algorithm: i64,

    /// 这个属性包含一个认证对象，对于客户端来说是不透明的，并且被加密保护，以防止客户端篡改。认证对象包含了  [`AuthenticatorData`] 和一个认证声明。前者包含了 [`Aaguid`]、唯一凭证 ID 和凭证公钥的 [`AttestedCredentialData`]。认证声明的内容由验证器使用的认证声明格式确定。它还包含了依赖方服务器验证认证声明所需的任何附加信息，以及解码和验证 [`AuthenticatorData`] 以及客户端数据的 JSON 兼容序列化。
    pub attestation_object: Bytes,

 /// 此字段包含零个或多个唯一的 [`AuthenticatorTransport`] 值的序列，按字典顺序排列。这些值是认证器（被认为）支持的传输方式，或者如果信息不可用，则为空序列。这些值应该是 [`AuthenticatorTransport`] 的成员，但依赖方应该接受并存储未知值。
    #[serde(default, skip_serializing_if = "Option::is_none")]
    pub transports: Option<Vec<AuthenticatorTransport>>,
}

2.3 Authenticator Data

在认证响应（AuthenticatorAttestationResponse）中的 authenticatorData 包含 flags，提供了 WebAuthn 凭证的备份资格和备份状态信息。如果钱包认为 WebAuthn 凭证应该需要备份，钱包应该检查认证响应中的 Backup Eligibility（BE）和 Backup State（BS）标志，以确保凭证已备份。如果 BE 和 BS 都设置为 true，意味着 凭证是多设备凭证，并且当前已备份。

对于那些希望使用 passkeys 作为 Aptos 账户的可恢复私钥替代品的用户，强烈建议在创建链上账户之前，将BE和BS标志都设置为true，以确保在设备丢失的情况下账户可恢复。

AttestedCredentialData 包含了 key，这是与 WebAuthn 凭证关联的公钥。

code reference

pub struct AttestedCredentialData {
    /// 验证器的 AAGUID。
    pub aaguid: Aaguid,

    /// 凭证 ID，其长度被前置到字节数组中。这不是公开的，因为它不应该被修改为超过 u16 的长度。
    credential_id: Vec<u8>,

    /// 使用 CTAP2 规范的 CBOR 编码格式编码的 COSE_Key 格式的凭证公钥，如 [RFC9052] 的第 7 节所定义。
    /// COSE_Key 编码的凭证公钥必须包含“alg”参数，且不得包含任何其他可选参数。
    /// “alg”参数必须包含一个 [coset::iana::Algorithm] 值。
    /// 编码的凭证公钥还必须包含相关密钥类型规范中规定的任何其他必需参数，即“kty”和算法“alg”（见 [RFC9053] 的第 2 节）。
    ///
    /// [RFC9052]: https://www.rfc-editor.org/rfc/rfc9052
    /// [RFC9053]: https://www.rfc-editor.org/rfc/rfc9053
    pub key: CoseKey,
}

凭证公钥以 CBOR Object Signing and Encryption format (COSE) 格式存储。CoseKey 包括公钥的 x 和 y 坐标，组合起来形成公钥。

有了原始公钥，就可以推导出 Aptos 账户地址。请注意，根据创建的账户类型（SingleKey 或 MultiKey），默认的身份验证密钥派生方法会有所不同。

（三）签署交易

在传统的客户端-服务器WebAuthn规范实现中，注册新凭证和身份验证断言都使用挑战-响应认证（challenge-response authentication）来避免多种类型的攻击。随机化的挑战对于保护免受重放攻击（§13.4.3）特别重要。

Aptos 正在将 WebAuthn 规范调整为用于链上账户和交易。正如许多人已经知道的那样，链上交易包括一个序列号，以避免在 Aptos 上发生。因此，如果交易被用作 WebAuthn 断言的挑战，即使挑战不是由钱包随机生成，重放攻击的风险也会得到缓解。

在传统的客户端-服务器WebAuthn规范实现中，注册新凭证和认证断言都使用挑战-响应认证来避免多种类型的攻击。随机化的挑战（challenges）对于防止重放攻击特别重要(§13.4.3)。

Aptos 正在将 WebAuthn 规范整合到链上账户和交易验证中。通常，链上交易会包含一个序列号，用以防止对 Aptos 网络进行重放攻击。这样一来，即便挑战并非由钱包随机生成，使用交易作为 WebAuthn 断言的验证挑战也能有效增强安全性，降低重放攻击的可能性。

3.1 challenge code reference

dictionary PublicKeyCredentialRequestOptions {
    required BufferSource                   challenge;
    unsigned long                           timeout;
    USVString                               rpId;
    sequence<PublicKeyCredentialDescriptor> allowCredentials = [];
    DOMString                               userVerification = "preferred";
    sequence<DOMString>                     hints = [];
    DOMString                               attestation = "none";
    sequence<DOMString>                     attestationFormats = [];
    AuthenticationExtensionsClientInputs    extensions;
};

在断言过程中，signing_message(raw_transaction) 的 SHA3-256 摘要被提供为 PublicKeyCredentialRequestOptions 中的 challenge。在计算 raw_transaction 的 SHA3-256 之前，signing_message 函数被应用，以实现域分离，而不会进一步增加挑战的大小。

换句话说，challenge 是：

 challenge = H({signing\_message(raw\_transaction)})

其中 是 SHA3-256 哈希。

3.2 AuthenticatorAssertionResponse 

在通过 navigator.credentials.get() 成功提交 PublicKeyCredentialRequestOptions 后，将向客户端返回 AuthenticatorAssertionResponse，如下所示：

code block

interface AuthenticatorAssertionResponse : AuthenticatorResponse {
    [SameObject] readonly attribute ArrayBuffer      authenticatorData;
    [SameObject] readonly attribute ArrayBuffer      signature;
    [SameObject] readonly attribute ArrayBuffer?     userHandle;
    [SameObject] readonly attribute ArrayBuffer?     attestationObject;
};

3.3 签名 

AuthenticatorAssertionResponse 中的 signature 是在消息 m 上计算的，其中 m 是 authenticatorData 和 clientDataJSON .1的 SHA-256 哈希值的二进制连接。clientDataJSON 是 CollectedClientData 的 JSON 序列化，包括 challenge 和关于请求的其他数据，例如请求的 origin 和 type。

其中 H 是 SHA-256 哈希（注意：不是 SHA3-256）， 是 passkey 私钥，$||$ 是二进制链接。

3.4 AuthenticatorAssertionResponse

interface AuthenticatorAssertionResponse : AuthenticatorResponse {
    [SameObject] readonly attribute ArrayBuffer authenticatorData;
    [SameObject] readonly attribute ArrayBuffer signature;
    [SameObject] readonly attribute ArrayBuffer? userHandle;
};

（四）交易提交

这个 AIP 基于 AIP-55 中提出的新的 TransactionAuthenticator 和AccountAuthenticator 构建，使用了 SingleKeyAuthenticator 和 MultiKeyAuthenticator，分别支持单一密钥和 k-of-n 多密钥。在 AnySignature 下新增了一个 WebAuthn 变体，在 AnyPublicKey 下新增了一个 Secp256r1Ecdsa 变体，使用户可以使用 Secp256r1 WebAuthn 凭证从 SingleKey 或 MultiKey 账户提交交易。

AccountAuthenticator::SingleKey { authenticator: SingleKeyAuthenticator }
AccountAuthenticator::MultiKey { authenticator: MultiKeyAuthenticator }

pub struct SingleKeyAuthenticator {
    public_key: AnyPublicKey,
    signature: AnySignature,
}

pub struct MultiKeyAuthenticator {
    public_keys: MultiKey,
    signatures: Vec<AnySignature>,
    signatures_bitmap: aptos_bitvec::BitVec,
}

pub struct MultiKey {
    public_keys: Vec<AnyPublicKey>,
    signatures_required: u8,
}

pub enum AnySignature {
    ...,
    WebAuthn {
        signature: PartialAuthenticatorAssertionResponse,
    },
}

pub enum AnyPublicKey {
    ...,
    Secp256r1Ecdsa {
        public_key: secp256r1_ecdsa::PublicKey,
    },
}

AnySignature 中的每个 signature 变体都结构化为 PartialAuthenticatorAssertionResponse。PartialAuthenticatorAssertionResponse 包含验证 WebAuthn 签名所需的所有信息。

pub enum AssertionSignature {
    Secp256r1Ecdsa {
        signature: secp256r1_ecdsa::Signature,
    },
}

pub struct PartialAuthenticatorAssertionResponse {
    /// 此属性包含从认证器返回的原始签名。
    /// 注意：从 WebAuthn 断言返回的许多签名不是原始签名。
    /// 例如，secp256r1 签名被编码为 [ASN.1 DER Ecdsa-Sig_value](https://www.w3.org/TR/webauthn-3/#sctn-signature-attestation-types)
    /// 如果签名已编码，则预期客户端在将其包含在交易中之前将编码签名转换为原始签名。
    signature: AssertionSignature,
    /// 此属性包含通过客户端传递给认证器的 [`CollectedClientData`](CollectedClientData) 的认证器数据的字节序列化。
    /// 必须保留确切的 JSON 序列化，因为已对序列化的客户端数据计算了哈希。
    authenticator_data: Vec<u8>,
    /// 此属性包含通过客户端传递给认证器的 [`CollectedClientData`](CollectedClientData) 的 JSON 字节序列化。
    /// 必须保留确切的 JSON 序列化，因为已对序列化的客户端数据计算了哈希。
    client_data_json: Vec<u8>,
}

（五）签名验证

一旦交易达到签名验证步骤，WebAuthn 认证器将执行以下步骤来验证签名 ：

1. 验证实际的 RawTransaction 是否与 clientDataJSON 中期望的 challenge 匹配，方法是计算

其中H是 SHA3-256 哈希，并验证它是否等于 clientDataJSON 中的 challenge。

[!tip]

译者注：原公式为H(signing\\_message(raw\\_transaction))

2. 使用 clientDataJSON 和 authenticatorData 重构消息 m，
3. 针对消息 m、公钥 pk 和原始签名 ，应用验证函数以确定V(σ, m, pk)是否评估为 true

假设其他所有内容都是正确的，验证通过，并且其他验证器同意结果，那么这笔交易将会成功，并且会被添加到区块链状态中。

（六）交易提交摘要

总结一下，在 Aptos 区块链对 WebAuthn 规范的实现中，身份验证断言的高级协议如下：

1. 客户端以 signing_message 的 RawTransaction 的 SHA3-256 形式提供一个 challenge。我们使用 RawTransaction 的 SHA3-256 而不是 RawTransaction 本身来限制 challenge 的大小，这是 clientDataJSON 的一部分。
2. 如果用户同意，用户代理（浏览器）将请求 WebAuthn 认证器使用 Passkey 凭证在包含挑战的消息 m 上生成断言签名，并将响应返回给客户端。
3. 然后客户端将 SignedTransaction 发送到区块链，其中 SignedTransaction 的签名字段包含 WebAuthn 认证器响应中的相关字段
4. 区块链将验证 SignedTransaction 的签名是否与相同的消息 m（其中包含 RawTransaction）并验证断言签名是否与相应的公钥有效

更多详细信息，请参考 AIP-66 (https://github.com/ALCOVE-LAB/Aptos-Docs/blob/main/AIP/aip-66.md) 

我们已经翻译了中文版的官方英文文档，供大家参考使用