Currently, the only way to secure your Aptos account is to keep theprivate key(secret key, SK). However, this task is much less simple than it sounds. The reality is that it is very easy for users to lose their private keys (e.g., forgetting to record a mnemonic when setting up their Aptos wallet for the first time) or for their private keys to be misappropriated (e.g., being tricked by a scammer into divulging their private key). This makes it incredibly difficult for users to get started and can lead to user churn when their account is lost or stolen.
In this AIP, we describe a more user-friendly approach to account management that relies on:
1.bare**OpenID Connect (OIDC)** standard.
2. its blockchain applications.
3.Zero Knowledge Proof of Knowledge (ZKPoKs)exist OIDC SignatureThe latest developments.
More specifically, on Aptos, we provide the ability to use a private key without the traditional private keykeyless accountThese accounts are managed through the user's pre-existing OIDC account(i.e., they're on Google, GitHub, Apple, etc.) OIDC providerowned Web2 account) to secure it, rather than securing your account with an unmanageable private key. In a nutshell, it's "Your blockchain account = your OIDC account".
Warning
An important feature of keyless accounts is that they are not only related to the user's OIDC accountbind(e.g., alice@gmail.com) and also with an OIDC provider registered with theManaging Applicationsbindings (e.g., a dapp's dapp.xyz website, or a phone's wallet app). In other words, they areapplication-specificaccount. Therefore, if an account's management application disappears or loses its OIDC provider's enrollment credentials, the user account tied to this application will be inaccessible unless a replacement is provided.Recovery path(discussed below).
1. Objectives
1. User-friendliness::
i.Blockchain accounts should be supported by user-friendly OIDC accounts, which makes them easy to access (and therefore less likely to lose their access)
ii. allow users to interact with dapps through their OIDC accounts without having to install a wallet: i.e., theWalletless Experience
iii.Allow users to easily access their blockchain accounts from any device
2. Security:
i.Keyless accounts should be as secure as their underlying OIDC accounts (see discussion here)
ii.Keyless accounts should be set up with a method for account recovery, even if the application responsible for their management is no longer available (see the discussion of alternative recovery methods in the subsequent section for more details).
3. Privacy:
i. Keyless accounts and their associated transactionsshould not Leak any information about a user's OIDC account (e.g., a Google user's email address or their OAuth sub identifier).
4. Efficiency: Transactions for keyless accounts should be efficiently created by wallets or DApps ($ < 1$ seconds) and can be efficiently verified by Aptos authenticators ($ < 2$ milliseconds).
5. Censorship resistance: Aptos Authentication Nodes should not prioritize OpenID transactions based on which application or user the transaction came from.
6. Decentralization: Keyless account design shouldn't rely on intermediary parties that are inherently incapable of decentralization.
2. Background
2.1 OAuth and OpenID Connect (OIDC)
We assume that the reader is familiar with the OAuth authorization framework and the OIDC protocol:
Է OAuth implicit authorization flowand OAuth authorization code authorization flowThe safety of the
Է OAuth client registration (e.g., client_id of the management application)
ꔷ JSON Web Tokens (JWTs)It includes:
JWT header segment (header)
JWT payload (payload), we usually referred to as "JWT".
JWT signatures, which sign the header segment and payload, are often referred to as OIDC signatures.
We usually refer to the combination of the header segment, the payload and its signature as a signed JWT.
See sample JWT heads and payloads.
Է The associated JWT header field (e.g., kid)
Է Related JWT payload fields (e.g., aud, sub, iss, email_verified, nonce, iat, exp)
ԷJSON Web Keys (JWKs)The JWK endpoints are published by each OIDC provider at the JWK endpoint URL specified in the URL of its OpenID configuration.
2.2 Terminology
ԷOIDC Account:Web2 accounts provided by OIDC providers (e.g., Google) (e.g., alice@gmail.com)
ԷNo key account:A blockchain account whose security and validity is supported by an OIDC account (e.g., a Google account) rather than by a key. The core of this AIP is to explain how to securely implement such a keyless account.
ԷApplication-specific keyless accounts:No key account at the same timebindThe identity of the user (e.g., alice@gmail.com) and the identity of the application responsible for management (e.g., dapp.xyz). This means that in order to access the account, a signed JWT Token must be provided that contains the identity of the user and the identity of the managed application. This token can only be obtained by authenticating the management application by logging in with the user's OIDC provider (e.g., Google). This approach is important for account recovery path selection in the event that the application management becomes inaccessible.
2.3 Overview of OIDC
For the purposes of this AIP, the most important element of understanding OIDC is that it enables theManagement Applications(e.g., dapp.xyz, some-wallet.org, or a mobile app) through an OIDC provider (e.g., Google) without obtaining the user's OIDC login credentials, i.e., the management app does not need to know the user's Google account password. In particular, if and only if the user has successfully logged in, only the management application can receive the Signed JWT, which is a publicly available user login credential.
This AIP is intended to demonstrate how this signed JWT can be used to authorize the execution of transactions for this user, as well as the keyless account it is associated with, and also to serve the management application.
2.4 Zero-knowledge proofs
This section assumes that you have some understanding of zero-knowledge proof (ZKP) systems: in short, a zero-knowledge proof system for a certainLogical relations 𝑅makeswitnessable to do so without disclosing any information about theirpersonal message 𝑤 to a premise with apublic information 𝑥𝑥validatorProve that you do hold 𝑤 to meet the 𝑅(𝑥;𝑤)=1(i.e., proving that a relationship was established).
Other ZKP terms:
ԷProving key respond in singing Verification key
ԷRelation-specific trusted setup
We assume a SNARK-friendly hash function 𝐻zk , which is easily proved inside our Zero Knowledge Proof (ZKP).
2.5 Aptos Account and Transaction Verification
Recall that in Aptos, an account is identified by its address, and the account'sauthentication keyStored under this address.
An authentication key is a confidentiality promise that is linked to the account'sPublic Key (PK)(e.g., a hash of the public key) are cryptographically linked. The account'sholderResponsible for managing the correspondingprivate keyThe
coerceauthorizationsAccess the Aptos account, which includes the following transactions:
1. For the (a) accountaddressand (b)Transaction payload(e.g., Move entry function calls) of thedigital signature
2. In the account address lower authentication key Submitted in public key
To verify that the transaction obtains authorized access to the account, the validator performs the following actions:
1. Extraction from transactionspublic keyand, based on the type of public key, derive the correspondingAuthentication Key.
2. Verify that this derivedauthentication keyWhether it is the same as the one already stored under the addressauthentication keymatch
3. Verificationsign (one's name with a pen etc)Whether or not it can be taken out of the transactionpublic keySuccessful calibration.
3. Scope
This AIP is concerned:
1. Explain the detailed process of keyless account operation.
2. describe an overview of our earliest keyless transaction authentication system created using the Rust language.
4. Elements outside the scope of the discussion
1. Security of DNS and X.509 certificate ecosystems
Keyless accounts rely on OAuth and OIDC, whose security in turn relies on the security of the DNS and X.509 certificate ecosystem.
Since all Internet software is not separated from the above system, this part is not included in this scope.
2. Malicious wallet apps posing as real wallet apps
Let's assume that an attacker is unable to publish a mobile app posing as a wallet-registered OAuth client_id in (say) Apple's App Store
We assume that an attacker cannot trick a user into installing a malicious desktop application that impersonates another application's OAuth client_id. Therefore, we do not recommend managing keyless accounts for desktop applications because they are very easy to impersonate.
3. an in-depth discussion of the auxiliary back-end components required for keyless accounts:
Pepper Services: This is a topic discussed in AIP-8113 and an overview of what is involved can be found in Pepper Services.
ZK Attestation Services: this is the subject of discussion in AIP-7514, and an overview of the relevant content can be found in [Appendix] (# (Unexpected) Zero Knowledge Attestation Services).
Consensus Protocol for JSON Web Keys (JWK): This is a topic discussed in AIP-6715, and an overview of what is involved can be found in the JWK Consensus.
Trusted setup MPC rituals for our Groth16 ZKP (see Groth16 discussion)
4. Pepper and ZK Proof of Service Decentralization Plan
locomotive
As explained in the summary, this change accomplishes two things:
1. Make the process easier for the user by simply signing into the wallet or dapp with (say) their Google account.
2. Since there are no keys involved, users are less likely to lose their accounts.
If this proposal is rejected, we will maintain our current key-dependent and user-unfriendly approach to account management. This may hinder acceptance of the Aptos network because many users do not understand the details of public-key cryptography, such as how users can protect their mnemonics, what a private key is, and what the difference is between a public key and a private key.
affect (usually adversely)
1. Dapp Developer
Familiarity with SDKs for keyless accounts
If desired, dapps can be enabledWalletless ExperienceUsers can log in to the dapp directly through their OpenID account (e.g., their Google account) without having to connect to a wallet.
This will allow users to access their dapp-specific blockchain account. This way, since the account is limited to that particular dapp, the dapp can authorize transactions on the user's behalf "no-brainer" without the need for complex TXN prompts.
2. Wallet developers
Familiarity with SDKs for keyless accounts
Consider switching their default user bootstrapping process to use a keyless account bootstrapping process
3. Users
Familiarity with security models for keyless accounts
Recognize that their account's are secure, just like their OpenID account (e.g. Google account).
Know how to restore your account if the Admin app is no longer available.
alternative
1. Passkey
An alternative that avoids the need for users to manage their own keys is Passkeys and the WebAuthn standard.A Passkey is a key associated with an application or website that is backed up in the user's cloud (e.g., Apple's iCloud, Google's Password Manager, etc.).
Originally designed to replace traditional website passwords, Passkeys work because instead of storing a user's password, websites store a Passkey public key that uniquely corresponds to the user. When a user needs to log in to a website, he or she can securely prove his or her identity by signing a random authentication message provided by the website with his or her Passkey, which is securely stored in a cloud backup.
The natural inclination is to utilize Passkey private keys to manipulate blockchain accounts by setting the account's private key to a Passkey private key. Unfortunately, there are currently two problems with Passkey private keys, but these will likely be solved in the future. Specifically.On some platforms, such as Microsoft Windows, Passkey private keys are not always automatically backed up to cloud storage.In addition, the Passkey private key brings aCross-device issues:For example, if a user creates a blockchain account on their Apple phone, their Passkey private key is backed up to iCloud, but this backup is not available on any of the user's other Android, Linux, or Windows devices because there is currently no functionality for backing up Passkey private keys across multiple platforms.
In the future, one possible way to enhance the passkeys application would be to encrypt the user's mnemonic via passkey, which would provide an additional backup option. Unfortunately, however, it is not yet clear that the WebAuthn PRF extension 16 How broad is the range of support.
2. Multi-party computing (MPC)
An alternative to avoiding the need for users to manage their private keys is to rely on a Multiparty Computing (MPC) service to compute signatures for users who have been authenticated in some way.
Often, users need to authenticate to a multi-party computing (MPC) system in a convenient way (i.e., without having to manage private keys). If this were not the case, the MPC system would not solve the user experience problem and would therefore become worthless. It is for this reason that the vast majority of MPC systems employ OIDC or Passkey keys to authenticate users before signing them instead.
There are two problems with this. First, the MPC system will learn who transacts when: i.e., the OIDC account and its corresponding on-chain account address.
Second, since the user can authenticate directly to the authenticator via OIDC (as discussed in this AIP) or via Passkey (as discussed above), the MPC is inherently redundant.
In other words.Keyless accounts avoid the need for complex Multi-Party Computing (MPC) signature services.（They authenticate users directly through the OIDC (which can be challenging to set up securely and consistently).
In fact, the security of keyless accountsgreaterThe reason for this is that in the event of a security breach in the MPC system, the account is at risk of being stolen. While keyless accounts arewill not (act, happen etc)Stolen, unless such a situation arises:
(1) a security problem with the user's OIDC account.
(2) The OIDC service provider itself is under attack.
Nevertheless, keyless accounts still rely on a distributed Pepper service and a ZK proof service (see Appendix). However:
ԷIn order to improve performance on a browser or cell phone, a proof service is only required when performing a Zero Knowledge Proof (ZKP) computation. With future optimizations of the ZKP system, this service is not expected to be needed.
ԷThe Pepper service, unlike the MPC service, is not sensitive to security: even if an attacker completely takes over the Pepper service, they will not be able to steal the user's account; unless they also compromise the user's OIDC account.
ԷAlthough the Pepper service requires a high degree of responsiveness, i.e., users cannot complete transactions without access to their own Peppers, this problem can be solved by distributing them using a simple design scheme based on VRF.
ԷOne of the MPC system'svantagelies in the fact that the MPC node can execute the transaction (TXN) signature before theFraud Detection(fraud detection). Whether it is better to perform fraud detection in the MPC system or in the wallet or through account abstraction requires more in-depth research.
3. HSM or trusted hardware
Fundamentally, this approach suffers from the same problem as Multi-Party Computing (MPC): in order to authenticate a user, its necessary to use a convenient OIDC or Passkey-based authentication method so that the user can be signed by an external (hardware-based) system instead.
As a result, that external system (i.e., the Hardware Security Module, HSM) may become an unnecessary point of risk - one that could be compromised.
As mentioned earlier, our strategy allows users to authenticate directly to the blockchain authenticator, avoiding the risks associated with introducing additional infrastructure.
One advantage of Hardware Security Modules (HSMs) or other trusted hardware is their relatively simple implementation process. More importantly, unlike the Multiparty Computing (MPC) approach, the use of trusted hardware is more helpful in ensuring privacy security.
standardize
Below, we explain the key concepts behind implementing keyless accounts:
1. Without a key account public key（What is the public key?
2. How to derive from this public key the authentication key(authentication key) ?
3. OIDC account transactions of digital signature（What does a digital signature look like?
1. Public Key
keyless account public key Included:
1. issval: the identity of the OIDC provider, i.e., what is displayed in the iss field of the JWT (e.g., https://accounts.google.com), which we label as issval
2. addridc:An identity commitment (IDC), which is a hidden promise, the promise includes:
The identifier issued by the OIDC provider to the owning user (e.g., alice@gmail.com), represented by uidval.
The name of the field in the JWT that stores the user's unique identifier is specified as uidkey; the Typescript SDK currently only supports the sub or email fields to prevent beginners from choosing the wrong JWT field17. Nonetheless, the validator is able to accept arbitrary fields, and this is done so as not to limit experienced users who wish to innovate on top of existing functionality.
When a management application registers with an OIDC (OpenID Connect) provider, it is granted an identifier, the client_id in OAuth, which is stored in the aud field of the JWT and denoted by audval.
More strictly (and omitting those complex implementation details here), the IDC is derived by hashing the preceding fields using a hash function 𝐻′ appropriate for SNARK techniques:
$$ \mathsf{addr_{idc}} = H'(\mathsf{uid_{key}},\mathsf{uid_{val}},\mathsf{aud_{val}}; r),\ \text{where}\ r\stackrel{$}{\gets } {0,1}^{256} $$2. Pepper
In the above, we used a blinding factor with high entropy 𝑟 to generate the IDC, which ensures that the IDC truly hides the identity of the user and the management application. In this AIP report, this blinding factor is referred to as a privacy-preserving Pepper.
Pepper has two important attributes:
1. when signing a transaction to authorize access to an account, one needs to know that pepper 𝑟
2. Even if Pepper goes public, the attacker should not Gaining access to an account. In other words, unlike a key, Pepper does not need to be encrypted to secure an account; it is only concerned with protecting the privacy of the account.
More simply put:
ԷIf Pepper lossSo, what's the point?Access to the account is lost.The
Էin the event thatpIf the epper is leaky (e.g., stolen), then only the privacy of the account will be lost.(i.e., the user and application identities in $\mathsf{addr_idc}$ could be brute-force broken and eventually exposed).
relies on users remembering their pepper 𝑟, which will maintain the status quo of easily-lost key-based accounts, thereby defeats the purpose of OpenID-based blockchain accounts.
Therefore, we introduce a Pepper Service designed to help users generate and memorize their Peppers (for a brief description of the features of this service, we have a brief description in the Appendix and an in-depth discussion in the AIP-81 document).
3. Authentication key
Next, the **authentication key** of a keyless account is a hash of its public key as described above. More formally, assuming the cryptographic hash function is 𝐻 , the authentication key is: authkey=𝐻(issval,addridc)
take note of: In practice, the above hash also includes a domain separator, but for the sake of simplifying the exposition, we ignore these details.
4、Private key
Having defined the above "public key", a natural question arises:
What is the private key associated with this public key?
The answer is that the user has no additional private key to memorize. Instead, their "private key" is actually their ability to log into their OIDC account, which is accomplished by the user through the management application submitted in the authkey above.
In other words, the "private key" is actually the password that the user uses to log into the account, which the user already knows, or it can be a pre-installed HTTP cookie that eliminates the need for the user to re-enter the password. However, this alonePasswords are not enough.: The management application must be available, it must allow users to log into their OIDC account and obtain an OIDC signature. (We'll go into more detail on how to deal with application unavailability later in this section on recovery services when the management application is unavailable)
More formally, if a user can successfully use an application identified by audval (via OAuth) to log in to an OIDC account given to them by an OIDC provider identified by (uidkey,uidval) and identified by issval, then this ability to successfully use it serves as the user's "secret key". secret key" of that user.
5. Signature
We start with a "warm-up" on our leaky mode keyless signature scheme, which does not guarantee user privacy. Next, we will introduce zero-knowledge signature schemes, which are effective in protecting user privacy.
6. Warming up: leaky user identity and application identity signatures
Before describing our fully privacy-preserving TXN signatures, let's warm up by describing leaky signatures, which expose the user's identity and the application's identity: i.e., they expose the uidkey,uidval, and audval.
A leaky address transaction txn sign (one's name with a pen etc)For 𝜎txn, the authentication key (authentication key) for this address is $\mathsf{auth\_key}$, which is defined as follows:
𝜎txn=(uidkey,jwt,header,epk,𝜎eph,𝜎oidc,expdate,𝜌,𝑟,idcaudval)
Of which.
1. uidkey is the name of the JWT field used to store the user's identity and its value is submitted in the address IDC
2. jwt is the payload of JWT (e.g., see example)
3. header is the JWT header; it represents the OIDC signature scheme and the key ID of the JWK, which are necessary to verify the OIDC signature under the correct PK.
4. epk, a temporary public key (EPK) generated by the management application, whose associated $\mathsf{esk}$ is kept secret on the management application side
5. 𝜎eph is a temporary signature for transaction $\mathsf{txn}$
6, 𝜎oidc is a test of the full JWT (i.e., a test of the $\mathsf{header}$ and the
OIDC signature for $\mathsf{jwt}$ payload)
7. expdate is a timestamp after which $\mathsf{epk}$ is considered expired and cannot be used to sign TXN.
8, 𝜌 is a key high entropy degree variable used to generate the EPK promise associated with epk and exp_date. For data security, this promise is stored in the jwt["nonce"] field.
9, 𝑟 is a Pepper for the IDC of the address, but in the so-called "leaky mode" this value is usually set to zero.
10. idcaudval is an optional field used primarily for account recovery operations. If set, it will contain an aud value identical to that in the IDC. This is important information to include in the TXN signature at the time of recovery, because in that case the load of $\mathsf{jwt}$ will contain the aud value of the recovery service, not the aud value originally committed in the IDC.
The next thing to be addressed is theWarning about pattern leaky:
Է Pepper 𝑟 can leaky from transactions, exposing the address IDC to the risk of brute-force cracking.
Է Similarly, the blinding factor 𝜌 of the EPK is revealed by the TXN, and thus fails to fulfill its privacy-preserving purpose at this time.
ԷThe JWT payload exists in plaintext and leaks information about the identity of the management application and the user.
ԷEven if the JWT payload is hidden, OIDC signatures may likewise leaky this identity information, since signed JWTs may have low entropy. As a result, an attacker can perform a targeted brute-force attack on a set of potentially signed JWTs to verify the signature.
7. Zero knowledge signature
This brings us to the core of this AIP: we are now ready to explain how privacy-preserving signatures work in our keyless accounts. These signatures do not disclose any information about the user's OIDC account or the management application associated with the keyless account.
specific transaction txn , which is directed to an address that has the authentication key $\mathsf{auth\key}$, whichZero Knowledge Signature $\sigma\mathsf{txn}$ Definitions are shown below:
Double subscripts: use braces to clarify
$$\sigma_\mathsf{txn} = (\mathsf{header}, \mathsf{epk}, \sigma_\mathsf{eph}, \mathsf{exp_date}, \mathsf{exp_horizon}, \mathsf{extra_field}, \mathsf{override_aud_val}, \sigma_\mathsf{tw}, \pi). extra_field}, \mathsf{override_aud_val}, \sigma_\mathsf{tw}, \pi)$$Among them:
Further, signature verification against a public key (issval,addridc) consists of the following steps.
zero knowledge relevance (ZK relation) 𝑅 is primarily responsible for performing the core verification process involving privacy from the previously mentioned ** leaky mode (leaky mode)**:
1. verify - by hashing the input in wpub with 𝐻zk (as described in the previous section) - that the resulting public input hash pih - is correct.
2. Check the OIDC provider ID in the JWT:
Verify that issval is equal to jwt["iss"], i.e., $\mathsf{iss_{val}}\stackrel{?} {=}\mathsf{jwt}[\texttt{"iss"}]$
3. If you are using an email-based ID, make sure that your email has been verified:
i. If the uidkey is equal to "email", then verify that the
'_' allowed only in math mode
$\mathsf{jwt}[\texttt{"email_verified"}]$
The value is 'true', i.e.: $\mathsf{jwt}[\texttt{"email_verified"}] \stackrel{?} {=} \texttt{"true"}$
4. Verify the user ID in the JWT:
i. Verify that uidval is equal to jwt[uidkey], i.e.: $\mathsf{uid_{val}}\stackrel{?} {=}\mathsf{jwt}[\mathsf{uid_{key}}]$
5. Check that the value used for the address IDC is correct:
i. Check if audval matches jwt["aud"], i.e.: $\mathsf{addr_{idc}}
\stackrel{?} {=}
H'(\mathsf{uid_{key}}, \stackrel{?} {=}
\mathsf{uid_{val}}, \mathsf{aud_{val}}; r)$.
6, Are we in recovery mode? (i.e., $\mathsf{override_{aud_{val}}} \stackrel{?} {=} \bot$
7. verify that the EPK has been submitted in the nonce field of the JWT: confirm i.jwtIs ["nonce"] equal to 𝐻′(epk,expdate;𝜌), ie:
$\mathsf{jwt}[\texttt{"nonce"}]\stackrel{?} {=}H'(\mathsf{epk},\mathsf{exp_{date}};\rho)$8. Check if the expiration date of the EPK is too far away:
9. Parse the extrafield into extrafieldkey and extrafieldval and verify that extrafieldval=?jwt[extrafieldkey].
10. verify OIDC signature 𝜎oidc based on jwk to JWT header and load jwt
which we will discuss later.Considerations for a zero-knowledge modelIncluded:
1. the user/wallet gets pepper 𝑟 through the pepper service, which we will briefly describe in the appendix.
2.Computing Zero Knowledge Proof (ZKP) Processes Slowly. This requires a specialized proof generation service, which is briefly described in the appendix.
3. ForBugs with zero knowledge relationship realizationThis can be effectively circumvented by adopting the "training-wheels" model.
reference implementation
This section, while optional, is highly recommended and is where you can include examples of what you want to demonstrate in this proposal. Either code, diagrams or plain text is fine. Ideally, a link should be provided to an active code base that demonstrates this criterion; for simpler cases, it could be inline code.
1. Select ZKP system: Groth16
Our initial deployment will use the Groth16 zero-knowledge proof system18In the case of BN25419 performed on elliptic curves. Groth16 was chosen based on the following considerations:
1. Minimized proof size (smallest of all ZKP systems)
2. Verify that the time is constant
3. Proof generation is fast (up to 3.5 seconds on a Macbook Pro M2 using multi-threading technology).
4. It is relatively simple to implement the relationships we need in circom20
5、circom has mature ecological tools support
6. It is possible to create forgery-proof certificates, which are essential for the authenticity of our transaction signatures.
Unfortunately, Groth16 belongs to the type of pre-SNARK with trusted settings for targeted presets. This means that for our ZK relation 𝑅, we need to organize aMulti-Party Computing (MPC) Based Trusted Setup CeremonyThis is beyond the scope of the current AIP document.
The resulting problem is that we cannot upgrade or fix our zero-knowledge proof-of-relationship implementation without a reset. So, in the future, we may migrate to a transparent SNARK, or adopt a relationship-specific-independent and disposableGeneric Trusted Settings.
2. keyless_account.move module
Keyless accounts require the following configuration on the chain:
1. Groth16 authentication key under which Zero Knowledge Proof (ZKP) needs to be completed;
2. The constant value of a specific Circuit;
3. the public key of the training wheels (if provided);
4. aud's rewrite list list;
5. the maximum number of keyless signatures allowed in a single transaction (TXN) as a way to reduce the risk of denial-of-service (DoS) attacks.
The configuration is stored in two resources within aptos_framework::keyless_account:
/// 288-byte Groth16 Validation Key (VK) used to implement a zero-knowledge relationship for keyless accounts
struct Groth16VerificationKey has key, store {
/// 32-byte serialization of `alpha * G`, where `G` is the generator of `G1`.
alpha_g1: vector.
/// A 64-byte serialization of `alpha * H`, where `H` is the generator of `G2`.
beta_g2: vector, ///
/// A 64-byte serialization of `gamma * H`, where `H` is the generator of `G2`.
gamma_g2: vector.
/// A 64-byte serialization of `delta * H`, where `H` is the generator of `G2`.
delta_g2: vector.
/// `\forall i \in {0, ... , \ell}, 64-byte serialization of gamma^{-1} * (beta * a_i + alpha * b_i + c_i) * H`, where `H` is the generator of `G1` and `\ell` is 1 for the zero-knowledge relation.
gamma_abc_g1: vector, the
}
struct Configuration has key, store {
/// Rewrite `aud` for the identity recovery service, which will help users recover keyless accounts associated with dapps or wallets that have disappeared
/// IMPORTANT: This recovery service **cannot** take over a user account on its own; the user must first log in to the recovery service via OAuth!
/// before allowing it to rotate any of the user's keyless accounts.
override_aud_vals: vector,
/// No transaction can have more than this number of keyless signatures.
max_signatures_per_txn: u16, /// No transaction can have more than this number of keyless signatures.
/// The maximum length of time (in seconds) that the EPK expiration time can be set from the time the JWT was issued.
max_exp_horizon_secs: u64, /// Maximum time in seconds that the EPK expiration time can be set from the JWT issuance time.
/// The training wheels public key if training wheels is enabled.
training_wheels_pubkey: Option, /// If training wheels is enabled, it is the training wheels public key.
/// Maximum length of a temporary public key supported by our Circuit (93 bytes)
max_commited_epk_bytes: u16, /// The maximum length of the temporary public key supported by our Circuit (93 bytes).
/// Maximum length of JWT `iss` fields supported by our Circuit (e.g. `"https://accounts.google.com"`)
max_iss_val_bytes: u16,
/// Maximum length of JWT field names and values supported by our Circuit (e.g. `"max_age": "18"`)
max_extra_field_bytes: u16, /// Maximum length of JWT field names and values supported by our Circuit (e.g. `"max_age": "18"`)
/// Maximum byte length of base64url-encoded JWT headers supported by our Circuit
max_jwt_header_b64_bytes: u32, /// The maximum length in bytes of our Circuit-supported base64url-encoded JWT header.
}
The Move module also provides governance functions to update the Groth16VerificationKey and Configuration configuration items in the chain:
/// Queues changes to the Groth16 VerificationKey. Changes take effect only after reconfiguration.
/// Can only be invoked via the governance proposal.
///
/// WARNING: To mitigate the risk of a DoS attack, VK changes should be made in conjunction with training round public key changes, the
/// so that the old ZKP of the old VK cannot be replayed as a potentially valid ZKP.
///
/// WARNING: This will lead to theft of funds if a malicious key is set.
public fun set_groth16_verification_key_for_next_epoch(fx: &signer, vk: Groth16VerificationKey) { /* ... */ }
/// Queues changes to the keyless configuration. Changes take effect only after reconfiguration. Only
/// Called via a governance proposal.
///
/// WARNING: Malicious `Configuration` can lead to DoS attacks, cause active issues, or enable malicious
/// Recovery Service Providers to be able to phish users' accounts.
public fun set_configuration_for_next_epoch(fx: &signer, config: Configuration) { /* ... */ }
/// Convenience method for queuing changes to the training round public key. Changes take effect only after reconfiguration.
/// Can only be invoked via the governance proposal.
///
/// WARNING: This *could* lead to theft of funds if a malicious key is set.
public fun update_training_wheels_for_next_epoch(fx: &signer, pk: Option) acquires Configuration { /* ... */ }
/// Convenience method for queuing changes to the maximum expiration time range. Changes take effect only after reconfiguration.
/// Can only be called via the governance proposal.
public fun update_max_exp_horizon_for_next_epoch(fx: &signer, max_exp_horizon_secs: u64) acquires Configuration { /* ... */ }
/// Convenience method for queuing up a collection of clears overriding `aud`. Changes take effect only after reconfiguration.
/// Can only be called via the governance proposal.
///
/// WARNING: Recovery of keyless accounts associated with vanished apps when no override `aud` is set up
/// will no longer be possible.
public fun remove_all_override_auds_for_next_epoch(fx: &signer) acquires Configuration { /* ... */ }
/// Convenience method for queuing up appends to collections that override `aud`. Changes take effect only after reconfiguration.
/// Can only be called via the governance proposal.
///
/// WARNING: If a malicious override `aud` is set, this *may* lead to theft of funds.
public fun add_override_aud_for_next_epoch(fx: &signer, aud: String) acquires Configuration { /* ... */ }3. aud rewrite list
Note that the Move module maintains an alternative list of auds in the Configuration, in line with the recovery service discussed later (see the section "Recovery Service"). As explained in the "Signatures" and "Recovery Services" sections, the OIDC signatures corresponding to these auds allow the user to recover a keyless account associated with any client_id when the application (dapp) disappears. The
4. Rust structures
The keyless public key is defined as:
pub struct KeylessPublicKey {
/// The value of the `iss` field in the JWT, indicating the OIDC provider.
/// For example: https://accounts.google.com
pub iss_val: String,
/// SNARK-friendly commitment to the following:
/// 1. the ID of the application; i.e., the `aud` field in the Signature OIDC JWT, representing the OAuth client ID.
/// 2. the OIDC provider's internal identifier for the user; i.e., the signed `sub` field in the JWT, the
/// 它是Google对bob@gmail.com的用户内部标识符, or the `email` field.
///
/// For example, H(aud || uid_key || uid_val || pepper), where `pepper` is used to hide the
/// the promised randomness of `aud` and `sub`.
pub idc: IdCommitment, `pepper` is used to hide /// `aud` and `sub` commitment randomization.
}
pub struct IdCommitment(#[serde(with = "serde_bytes")] pub(crate) Vec);Keyless signatures are defined as:
pub struct KeylessSignature {
pub cert: EphemeralCertificate,
// The decoded plaintext JWT header (i.e., not base64url-encoded), containing the two relevant fields:
// 1. `kid`, indicating which JWK from the OIDC provider should be used for authentication
// The [zero-knowledge-proof] OpenID signature.
// 2. `alg`, specifying which type of signature scheme was used to sign the JWT
pub jwt_header_json: String,
// The expiration time of `ephemeral_pubkey`, expressed as a UNIX epoch timestamp in seconds.
pub exp_date_secs: u64, // The expiration time of `ephemeral_pubkey` in UNIX epoch timestamps.
// The short-term public key used to verify `ephemeral_signature`.
pub ephemeral_pubkey: EphemeralPublicKey, // The short-term public key used to verify the `ephemeral_signature`.
// Signature of the transaction under `ephemeral_pubkey` and the ZKP if it exists.
// Include the ZKP in this signature to prevent mutable attacks.
pub ephemeral_signature: EphemeralSignature, // the signature of the transaction and the ZKP (if it exists) under `ephemeral_pubkey`.
}
pub enum EphemeralCertificate {
ZeroKnowledgeSig(ZeroKnowledgeSig), the
OpenIdSig(OpenIdSig),
}
pub struct ZeroKnowledgeSig {
pub proof: ZKP,
// The expiration range that Circuit should enforce on the expiration date promised in nonce.
// This must <= `Configuration::max_expiration_horizon_secs`.
pub exp_horizon_secs: u64,
// An optional extra field (e.g., `"":""`) that will be publicly matched in the JWT
pub extra_field: option, // an optional extra field (e.g., `"":""`) that will be publicly matched in JWT
// will be set to override the `aud` value, which Circuit should match instead of `aud` in IDC.
// This will allow users to recover keyless accounts tied to applications that are no longer online.
pub override_aud_val: Option,
// Sign proofs and declarations with training round SK to mitigate the shortcomings in our Circuit.
pub training_wheels_signature: Option, // Signature of proofs and declarations by training round SKs to mitigate shortcomings in our Circuit.
}
pub struct OpenIdSig {
// Decoded bytes for JWS signatures in JWT (https://datatracker.ietf.org/doc/html/rfc7515#section-3)
#[serde(with = "serde_bytes")]
pub jwt_sig: Vec.
// JWT's decoded/plaintext JSON payload (https://datatracker.ietf.org/doc/html/rfc7519#section-3)
pub jwt_payload_json: String, // JWT's decoded/plaintext JSON payload ().
// The name of the key in the declaration mapped to the user's identity; e.g., "sub" or "email".
pub uid_key: String, // The name of the key mapped to the declaration of the user identification; for example, "sub" or "email".
// Random value used to obfuscate the EPK from the OIDC provider in the nonce field
#[serde(with = "serde_bytes")]
pub epk_blinder: vec.
// The privacy-preserving value used to compute the identity promise. It is usually uniquely derived from `(iss, client_id, uid_key, uid_val)`.
pub pepper: Pepper, // Used to compute the privacy-preserving value of an identity commitment.
// When overriding aud_val is used, the signature needs to contain the aud_val promised in the IDC, the
// because JWT will contain the override.
pub idc_aud_val: Option,
}
pub enum EphemeralPublicKey {
Ed25519 {
public_key: Ed25519PublicKey,
}
Secp256r1Ecdsa {
public_key: secp256r1_ecdsa::PublicKey,
},
}
pub enum EphemeralSignature {
Ed25519 {
signature: Ed25519Signature,
}
WebAuthn {
signature: PartialAuthenticatorAssertionResponse,
},
}4. PR
We'll add more links to our Circuit code and Rust transaction authenticator below:
Է Rust authenticator code for leaky mode #11681
Է Rust Authenticator Code for Groth16-based ZKP Schema #11772
Է Get it from the chain Groth16 VK #11895
Է Correctly handle exp_horizon, VK, and configuration initialization in Rust #11966
Է Optional training wheels signature #11986
Է Repair smoke test (smoke test) #11994
Է Use base 10 strings as nonce #12001
Է Remove uid_key restriction #12007
Է Optimize iss storage and reconfigure #12017
Է Renamed AIP-61 Term #12123
Է Rename to keyless #12285
Է Fix base64, fix training wheels signature #12287
Է Custom hexadecimal serialization for certain keyless structures #12295
Է End-to-End Test Characterization Gating #12296
ԷSupport for password-based EPK and fixing non-malleability signatures #12333
Է Update validation key and test proof #12413
Է Fix public input hash generation, fix serde deserialization, add Google as default OIDC provider in devnet #12476
Է Fix feature gating and match alg field #12521
Testing (optional)
1. Correctness and completeness tests for signature verification
ԷUnexpired [ ZKPoKs ] OIDC signatures from supported providers
ԷExpired [ ZKPoKs' ] OIDC signatures from supported providers do not pass validation.
Էcome from (a place)unsupportedof the provider's signature does not pass validation.
ԷOIDC signature validation failed for [ ZKPoKs ] without a temporary signature.
ԷZero-knowledge proofs (ZKPs) are immutable.
2. Other test elements
Է Ability to quickly validate transactions containing a large number of OIDC accounts
We will be expanding the testing program in the future. (TBD)
Risks and drawbacks
Է List here the potential negative consequences that could result from the proposal. What are the risks?
Է What backward compatibility issues should we be concerned about?
Է If we encounter problems, how will we mitigate or resolve them?
All related risks and deficiencies are addressed in the Security, Activity and Privacy Considerations section.
Future development potential
Thoughtful consideration of the future development of the proposal. How do you foresee its future outcomes? What will be the impact of the proposal one year from now? What about five years from now?
Overall, this approach helps attract the next billion user base to the market by removing barriers related to mnemonics and key management.
In a year's time, the proposal could lead to a whole new ecosystem of decentralized apps (dapps), where apps allow users to easily access them through their (for example) Google account without having to manually connect to a wallet.
The wallet ecosystem may likewise grow by supporting users to access it without having to write down a mnemonic.
It may also make wallets on the Aptos network more secure, as such wallets will no longer need to hold long-term keys for the user (or rely on complex multi-party computation MPCs or Hardware Security Module HSM systems to perform this task on the user's behalf).
timeline
1. Recommended implementation timeline
The amount of time it is expected to take to complete the implementation can be described in several phases or milestones.
Given that the interaction of multiple components complicates step-by-step development, the following is a breakdown of potential milestones:
1. Implementing zero-knowledge proof relations in circom20.
2. Development of the RUST transaction validator.
3. centralized pepper service deployment.
4. Centralized deployment of proof services, including "training-wheels".
5. JWK consensus mechanism based on Aptos authentication nodes.
6. Organization of the Trusted Multiparty Computing (MPC) Setting Ceremony.
2. Recommended developer platform support timeline
We are currently working on SDK development and support. The remaining tools will be added in the future.(to be determined)
3. Recommended deployment timeline
Deployment on the devnet network is planned for February.
Deployment on the mainnet network is planned for March.
The plan is to deploy it on the testnet network in the next few days.(exact time to be determined)
Security, Activity and Privacy Considerations
ԷDoes this change our basic assumptions about security or threat models?
ԷIs there a potential for fraud? What are the corresponding mitigation measures?
ԷAre there other safety hazards to consider?
ԷIs there a relevant security design document or audit report available?
1. Training wheels
During our initial deployment, we intended to add an additional zero-knowledge proof (ZKP) after verifying that the relationship is accurate before proving that the service computes a proof of theAuxiliary Wheel SignatureStep. In this way, we avoid the risk of a single point of failure (i.e., the realization of a zero-knowledge proof relation) without giving the proof service additional power to the extent of interfering with account security.
Specifically, even in the training wheels, an error in the implementation of our zero-knowledge proof (ZK) relation does not result in a significant loss of user funds. At the same time, an attacked proof service cannot steal funds on its own: it must also obtain the victim's OIDC account and a valid OIDC signature.
One of the importantSurvivability issuesYes, users may not be able to access their accounts for a while if the proofing service is down. However, we expect such downtime to be very brief and an acceptable tradeoff against our goal of ensuring security during initial deployment.
The public key for the Training wheels schema will be saved as a parameter in the chain, available in the aptos_framework::keyless_account::Configuration resource (see here for details) and can be modified through governance.
The training wheels model also plays aThe Role of DoS Attack Prevention, because invalid Zero Knowledge Proofs (ZKPs) are not signed by the proof service. Therefore, since our Rust verification code first checks the signature of Training wheels, it can easily identify and exclude invalid ZKPs without expending resources for verification. A key implementation detail is that if the Groth16 validation key (VK) is changed, the Training wheels schema public key (twPK) must also be updated at the same time, since the Training wheels signature does not cover the VK. forgetting to update the twPK may allow an attacker to utilize the old VK by replaying the old If you forget to update the twPK, it may allow an attacker to use the old VK to replay the old ZK proof to launch a DoS attack.
2. Restoration of services
Again, keyless accounts are tied not only to the user, but also to the management application (e.g. dapp or wallet).
Unfortunately, there is a risk that the admin app will disappear, for example:
1. The OAuth client_id of the application may be blocked by the OIDC provider (for various reasons).
2. An inadvertent administrator may have lost the application's OAuth client_secret or completely logged out of the application at the OIDC provider.
3. An unsuspecting administrator may simply shut down the app (e.g., remove the mobile app from the app store, or stop the dapp website from functioning) without realizing that this will result in the user no longer being able to use the keyless account within the app.
In other words.If the management application does not exist, users can no longer access their keyless accounts, because they can't get the signed JWTs they need in case the application is missing.
However, withRecovery ServicesThis loss of account can be avoided by regaining access to the account through helper users. Specifically.
1. Users will log in to the recovery service using their OIDC account.
2. The recovery service then obtains an OIDC signature based on its client_id and the user's personal identification number sub.
3. The client_id of the restored service will be included in the aud replacement list, as determined by the previous successful governance proposal.
4. The blockchain verifier recognizes this [zero-knowledge proof] OIDC signature as a valid keyless signature for any managed application.
5. Users can therefore utilize this [zero-knowledge proof] OIDC signature to perform key updates for their inaccessible accounts.
The recovery path can only be used after the client_id of the recovery service has been added to the list of chained aud replacements through governance.
of this approachvantageIncluded:
1. It reduces the risk of centralization because the client_id of the recovery service can be set based on the governance proposal.
2. Users can choose recovery services from multiple providers and use the one they trust the most.
3. The recovery service itself does not retain state or store signed JWTs from previous user logins.
4. The non-compliant recovery service cannot change the user's account alone, and the user must log in to the recovery service first.
But this method also has amalpractice: If a user logs into anuclear facilitiesrecovery service, then the service may steal all the keyless accounts of the user. Therefore, users must be careful in choosing the recovery service they want to use.
To mitigate this risk, we may deploy the recovery service in a distributed manner through Multiparty Computing (MPC) technology. This will ensure that signed JWTs are not stolen by a few colluding individuals within the server. This aspect of the work remains to be further explored in the future.
3. Other recovery modalities
While there are other recovery methods that work, they can be problematic: poor user experience, vulnerability to phishing attacks, not supporting all platforms, or requiring centralized management:
Է For **Mailbox-based **OIDC service providers, we can replace the OIDC-signed ZKPoK with the ZKPoK21 of a DKIM-signed email (and the message must be formatted correctly).
While this may not be a good user experience, it provides a way to recover in an emergency and also protects privacy.
Ensuring that this process is difficult to spoof is key, as users may be lured into sending so-called "account reset" emails by attackers.
For example, enable this process only if the account has been inactive for a long time.
Alternatively, this process may require the user to communicate with another decentralized verifier who will appropriately guide the user through the account reset process.
Է with regards toNon-Email Basedof the OIDC provider, the alternate recovery path may vary from provider to provider:
For Twitter, users can prove they have a Twitter account by posting a message in a specific format.
Similarly, for GitHub, users can accomplish the same validation by publishing a gist.
If there is an HTTPS Oracle, the authenticator can verify the above tweet or gist and allow the user to perform an account key change. Since at least the authenticator can learn the user's identity via the HTTPS URL, such an operationIt won't protect privacy.The
This process also has the potential to be exploited by phishing attacks.
Է Another option is to configure all keyless accounts in 1-out-of-2 mode22 with a **Passkey** subaccount for recovery. This can be utilized to restore account access in situations where Passkey is automatically backed up (e.g., on Apple platforms).
The use of traditional key (SK) subaccounts could also be considered, but this would require the management application to prompt the user to record the key, which goes against the user-friendliness principle mentioned in the original goal.
Է Alternatively, for popular applications, we can consider performing amanual patch: e.g., add exceptions to our zero-knowledge proof relation directly for some specific client_id. But this introduces the risk of centralization.
For users who are not comfortable with this approach, they have the option of (1) not using this feature at all, or (2) choosing to use the t-out-of-n method22 depending on their preference, where one of the n factors is a keyless account.
The service also uses the OIDC account for request authentication, so it cannot effectively be used as a second authentication factor; at least not without defeating the original purpose of a keyless account that doesn't require memorizing any information.
4. Breach of OIDC account
The core idea of keyless accounts is to ensure that a user's blockchain accountSame security as their OIDC accountIt stands to reason that if an OIDC account, such as Google's, is hacked, all keyless accounts associated with the user are also at risk. It stands to reason that if an OIDC account (such as Google) is hacked, all keyless accounts associated with the user's OIDC account are also at risk.
In fact, even if the OIDC accounttransitorycompromised, keyless accounts may also beroyalty-freecompromised. This is because an attacker can gain access to an OIDC account in a short period of time and easily change the account key.
Nonetheless, that's exactly what we designed it to anticipate: "Your blockchain account is equivalent to your Google account!"
Users who do not like this design have the option of (1) not using this feature, or (2) using a t-out-of-n multi-factor authentication method22 of their personal choice, one of which can be a keyless account.
**Note:** The Pepper service also uses OIDC authentication requests, so it cannot be used as a valid factor for secondary authentication; except to undermine the original intent of keyless accounts, which was to eliminate the need for the user to memorize any information.
5. Sabotage of OIDC providers
Again, "Your blockchain account is your OIDC account." In other words:
ԷIf your OIDC account is compromised, your keyless account is also affected.
ԷIf your OIDC provider, such as Google, is compromised, all keyless accounts associated with that provider are also at risk.
We emphasize that this is acharacterizationspeciousflaws: We expect Aptos users to leverage the security and convenience of their OIDC accounts for seamless transactions. However, for those users who do not want to rely solely on the security of their OIDC account, they can upgrade to the $t$ out of 𝑛 authentication method, using a combination of a different OIDC account and/or traditional SKs22.
We can mitigate the associated risk through an emergency governance proposal to revoke the JWK of a compromised OIDC provider.
6. OIDC provider changes algorithm to unsupported signature algorithm
The zero-knowledge proof relation we currently implement only supports RSA signature verification, based on its widespread use among OIDC providers. However, if the provider suddenly switches to another algorithm (e.g., Ed25519), this will result in users not being able to generate ZKPs and thus not being able to access their accounts.
In response to this unlikely scenario, we may need to take the following steps:
1. First, you can enable aDisclosure modelof the feature flag. This would restore access to user accounts at the expense of privacy, which, while not ideal, would at least keep most user assets safe.
2. Second, we upgrade the Zero Knowledge Proof (ZK) protocol to adapt it to the new scheme, perform a short-term trust setting, and finally deploy it to the actual product environment.
7. Web-based wallets and wallet-less Dapps
The emergence of keyless accounts will enable (1) web-based wallets, where users can log in through services such as Google, and (2) allow users to log in without a traditional wallet directly through services such as Google'sNo Wallet Dapps.
There are a number of security challenges in the Web environment:
ԷEnsure that JavaScript dependencies have not been tampered with, as this could lead to theft of ESKs, signed JWTs, or both.
ԷThere is a risk that ESKs for managing user accounts in the browser may be leaky due to caching or incorrect storage of these keys in JavaScript.
Thankfully, using the Web Encryption API and/or Passkey instead of ESK can be effective in preventing such issues.
ԷProtection against cross-site scripting attacks (XSS) and cross-site request forgery attacks (CSRF)
Managing JWTs in web browsers is extremely risky, especially when using an implicit process with OAuth authorization, as JWTs may appear in URL and HTTP Referer fields, which are prone to information leaky. For this reason, application developers must exercise extreme caution.
8. SNARK-friendly hash functions
To ensure that the time to generate proofs is within reason, we use Poseidon, a friendly hash function designed specifically for SNARK.23 Unfortunately, Poseidon has not yet undergone much cryptographically detailed analysis compared to longer-established hash functions such as SHA2-256.
If a collision vulnerability exists in the Poseidon hash function, an attacker could alter the submitted value of a user or application ID and misappropriate funds without breaching the zero-knowledge proof of system or OIDC provider.
In the long term, we plan to phase out SNARK-friendly hash functions and migrate to choices where our zkSNARK proof system maintains high efficiency even when used with SNARK-unfriendly hash functions such as SHA2-256.
Open-ended questions (optional reading)
This section contains a series of questions and answers, some of which may already have been answered, while others are still being explored and should be clarified.
1. Collection of OIDC providers with secure alternate recovery paths
What are the key issues when deploying? What OIDC providers recognize safe alternate recovery paths (e.g., processes that are difficult to counterfeit)?
2. Where should web developers store ESK and signed JWTs by default?
For mobile applications, storing ESK is not a problem: all data is stored in the application's own storage.
But for the web application side, i.e. dapps or web wallets, two options exist:
1. Use OAuth Implicit Authorization process and stores the Encryption Signing Key (ESK) and the signed JWT in the browser (e.g., local storage, IndexedDB).
The advantage of this approach is that even if the back-end service of the decentralized application (dapp) or web wallet that the user is using is compromised, the user's assets will not be stolen unless the user opens and operates a compromised website that triggers malicious JavaScript code,.
2. Use OAuth Authorization Code process, storing the cryptographic signing key (ESK) in the browser and keeping the signed JWT in the server backend.
Unfortunately, some OIDC providers allow signed JWTs to be refreshed on the backend with a new nonce field without user consent. This means that in the event of an attack on the backend, even if the OAuth session has not expired, an attacker may be able to refresh the JWT without requiring the user to visit the site and steal the keyless account.
3. What is the maximum expiration time threshold max_exp_horizon that should be set?
Recall that the value of $\mathsf{exp\date}$ should not exceed $\mathsf{jwt}[\texttt{"iat"}]+ \mathsf{max{exp_horizon}}$ .
Limitations:
ԷThe time limit should not be set too short: this will result in users needing to frequently refresh the signed JWTs, which in turn will frequently regenerate the ZKPs, causing inconvenience.
ԷThe timeframe should also not be too long: otherwise there is a large risk window during which the signed JWTs and corresponding submitted ESKs may be illegally stolen.
4. Zero-knowledge transactions still expose OIDC provider identity information
In current zero-knowledge transactions (TXNs), revealing the issval field (e.g., Google, GitHub) tells which OIDC provider is involved in the transaction.
However, we are able to modify our zero-knowledge proof relation to hide the identity of the OIDC provider. More specifically, instead of treating the jwk as a public input, we can treat it as a private input and confirm whether this JWK is in the table of authorized JWKs on the chain. This is necessary because, if not, a user could enter any JWK at will and forge a transaction signature.
appendice
1. OpenID Connectivity (OIDC)
The OIDC Code has the following provisions:
ԷThe iat field must be specified in UNIX cosmic seconds (see details).
ԷThe protocols for refreshing tokens do not allow setting new nonce values (see details). However, based on our experience with it, providers such as Google do in fact allow refreshing of OIDC signatures on a new nonce.
2. Examples of JWT headers and payloads
Here is a sample JWT from Google OAuth Playground 24.
JWT Header Segment:
{
"alg": "rs256".
"kid": "822838c1c8bf9edcf1f5050662e54bcb1adb5b5f",
"typ": "JWT"
}JWT Payload.
{
"iss": "https://accounts.google.com",.
"azp": "407408718192.apps.googleusercontent.com",
"azp": "407408718192.apps.googleusercontent.com", "aud": "407408718192.apps.googleusercontent.com",
"sub": "103456789123450987654",
"email": "alice@gmail.com",
"email_verified": true,
"at_hash": "a5z9bu-5jokhN3pmxj2kMg",
"iat": 1684349149,
"exp": 1684352749
}3. Pepper services
The Pepper service is used to recover users if they lose their account's pepper, and if they do, the account cannot be recovered.
The Pepper Service is designed to help users retrieve Peppers from their accounts, and if a Pepper is lost, the account cannot be retrieved.
The specific design details of the service are beyond the scope of this AIP manuscript, but we highlight a few of its key features here:
ԷThe service needs to disclose the user pepper beforeauthenticate a useridentity, which is very similar to the process operated by blockchain verifiers.
The verification process will be done utilizing the same OIDC signature as was used to create the transaction signature.
ԷThe service uses a **Verifiable Random Function (VRF)** to generate peppers.
ԷIt is designed to support easydecentralization, whether it exists as a standalone system or as an upper tier service for the Aptos Validator.
ԷThe Pepper service isPrivacy: it will not know either the identity of the user requesting the pepper, or the specific pepper value generated for that user.
ԷThe Pepper service is primarily "stateless", meaning that it stores only those VRF keys used to derive user peppers.
4. (Unanticipated) zero-knowledge proofing services
When the cost of computing zero-knowledge proofs (ZKPs) on browsers and mobile devices is still highZero Knowledge Proofing Servicewill assist users in quickly calculating their ZKPs.
The design details of this service are detailed in the AIP-8113 document. Below, we highlight a few of its key features:
ԷIt cannot steal a user's keyless account; unless the OIDC (OpenID Connect) account associated with it is compromised first.
ԷEven if the service stops, users can still access their accounts in a slow way because they can always calculate the ZKPs themselves.
Unless it is proved that the service is performing the "novice protection mode" (see below).
ԷThe service should bedecentralized, either in an authorized environment or without authorization.
ԷIt should have the ability to withstanddenial of service (computing)(DoS) attack resilience.
ԷIt should beunknowable(used form a nominal expression)maybeprivacy: i.e., it will not understand any private input data in a zero-knowledge proof (e.g., identity-anonymized requesters, or their peers, etc.).
ԷProof of service is primarily "stateless", storing only those public proof keys that compute our zero-knowledge proof relation 𝑅.
5. JWK Consensus
Accounts that do not use keys involve verifying OIDC signatures when performing transaction signing. This requires that the verifierAgree to updated JWKs for OIDC providers(i.e., public keys), which will be available in the specific provider'sOpenID Configuration URL The above is regularly updated.
For details on the design and implementation of the JWK (JSON Web Key) consensus mechanism, see the AIP-6715 document. For now, let's focus on a few of the core features:
ԷValidators are required to periodically run a validation check on each supported provider'sOpenID Configuration URL Check for changes to JWKs on
ԷWhen a verifier detects changes, they propose them through a one-time consensus mechanism.
ԷOnce a consensus has been reached between validators, the new JWKs will be reflected in the public Move module of aptos_framework::jwks.
Update Log
Է2024-02-29: Earlier versions of this AIP referred to the keyless account as theOpenID-based Blockchain (OIDB) Account.
Է2024-03-14: Added Rust data structure support for signing and giving public keys without keys.
Է2024-03-14: Enhanced transaction signing without keys, added account recovery service and new public field functionality.
Է2024-05-08: Several updates were made
As a primary solution to the problem of disappearing dapps / wallets, a recovery service was introduced.
The ZK relation 𝑅 has been updated with the latest details (rewrite of the aud field, new extra_field field, public input hash).
Updated comparative analysis of passkey, MPC (Multi-Party Computing) and HSM (Hardware Security Module).
A "training wheels" signature mechanism has been introduced.
Code samples are provided for both Rust and Move languages.
Added links to relevant AIP documentation (e.g., Account Recovery Service, Proof Service, JWK Consensus Mechanism, etc.).
quote
Footnotes not defined by the original author
1. There are alternatives to single SK accounts, such as multi-signature based accounts (e.g., via MultiEd25519 or via AIP-55), but they still boil down to one or more users protecting their secret keys from loss or theft.
2. OpenPubkey: enhancing OpenID Connect with user-held signing keys, by Ethan Heilman, Lucie Mugnier, Athanasios Filippidis, Sharon Goldberg, Sebastien Lipman, Yuval Marcus , Mike Milano, Sidhartha Premkumar, and Chad Unrein, in Cryptography Preprints, Paper 2023/296, 2023, [URL].
3. Use Google to sign in to your identity contract (for fun and profit), by Santiago Palladino, link
(https://forum.openzeppelin.com/t/sign-in-with-google-to-your-identity-contract-for-fun-and-profit/1631)
4.EIP-7522: OIDC ZK Validator for AA Accounts, author: dongshu2013, link
(https://eips.ethereum.org/EIPS/eip-7522)
5. Extension of blockchain addresses: zero-knowledge address abstraction; Authors: Sanghyeon Park, Jeong Hyuk Lee, Seunghwa Lee, Jung Hyun Chun, Hyeonmyeong Cho, MinGi Kim, Hyun Ki Cho, Soo-Mook Moon; Published in. Cryptology ePrint Archive, paper 2023/191, 2023; link
(https://eprint.iacr.org/2023/191)
6.SNARK-JWT Authentication
7. nozee
8. bonsay-pay
9. zk-blind
10.zklogin
11. OAuth 2.1 Authorization Framework, by Dick Hardt, Aaron Parecki, and Torsten Lodderstedt, 2023, [URL].
12. Undefined (translator's note)
13.https://github.com/aptos-foundation/AIPs/blob/main/aips/aip-81.md
14.https://github.com/aptos-foundation/AIPs/blob/main/aips/aip-75.md
15.https://github.com/aptos-foundation/AIPs/blob/main/aips/aip-67.md
16.PRF Expansion Details
17. Only allow OIDC providers to use the email field and the value of that field is never changed (e.g., email services like Google), as this ensures that users don't accidentally lock themselves out of their blockchain accounts by changing the email address of their Web2 account.
18. on the size of pairing-based non-interactive arguments, by Jens Groth, in Advances in Cryptography - EUROCRYPT 2016, 2016
19.bn254
20. circom
21.https://github.com/zkemail
22. See AIP-55: Universal Transaction Authentication and Support for Arbitrary K-of-N Multi-Key Accounts
23. Poseidon: New Hash Functions for Zero-Knowledge Proof Systems, by Lorenzo Grassi, Dmitry Khovratovich, Christian Rechberger, Arnab Roy, and Markus Schofnegger, in USENIX Security '21, 2021, [URL].
24. OAuth Playground
All of the above content is reproduced from the Internet, does not represent the position of AptosNews, is not investment advice, investment risk, the market need to be cautious, such as infringement, please contact the administrator to delete.
WeChat Sweep 
Alipay Sweep 
