The discussion below assumes some familiarity with how keyless works.

ZK circuit

Keyless accounts leverage a ZKP to prove the satisfiability of a complex relation, dubbed “the keyless relation” (see AIP-61). However, state-of-the-art ZKPs with efficient verifiers and practical proving times require the relation to be described as a so-called rank-1 constraint system (R1CS). This requires implementing the keyless relation in a domain-specific language (DSL) that compiles down to R1CS (e.g., circom).

Pepper service

Keyless blockchain addresses are cryptographic commitments to the user’s OIDC identity (e.g., their email address) and the application’s identity (e.g., the OAuth client_id). To ensure these commitments are hiding, they are blinded using a random blinding factor, called a pepper.

Since the goal of keyless accounts is for users to not have to remember anything, a pepper service (AIP-81) helps users remember their pepper. Specifically, users can authenticate to this service (also) using a valid JWT and the service can (re)compute their pepper for them.

Prover service

The Aptos Keyless deployment includes a prover service (AIP-75) that helps users quickly compute their ZKPs, which are necessary to transact.

The prover service helps users maintain privacy from the blockchain, since the ZKP leaks nothing about the user-and-application identifiers, nor the pepper.

Currently, the user does not maintain their privacy from the prover service, which does learn the user-and-application identifiers and the pepper.

Training wheels (TW)

Training wheels (TW) mode (AIP-61, AIP-75) is a security extension which is currently enabled on the ZK prover service to mitigate against bugs in the ZK circuit implementation.

When enabled, all keyless transactions are required to have a training wheels signature over their ZKPs from the prover service. This ensures that the prover service always verifies the keyless relation manually before computing a ZKP, thereby vouching for the existence of a valid witness and thus preventing attackers from exploiting ZK circuit bugs by constructing a malicious witness.

If the prover service is offline with the training wheels feature enabled, then users with expired ZKPs could temporarily lose access to their keyless accounts.

Definitions

Integrity: Guarantees that only the owner of the OIDC account behind a keyless account can transact on behalf of that keyless account.

Privacy: Privacy guarantees are two-fold.

On one hand, when keyless users sign into their OIDC accounts, a passive OIDC provider (e.g., Google) must not learn the user's keyless blockchain address nor their transaction activity.

On the other hand, a user’s keyless transaction should not leak the user's OIDC identifier (e.g., the JWT’s sub or email) nor the application's identifier. Naturally, this presumes that the application cannot be implicitly-identified from the transaction payload (e.g., the Move contracts being called).

Availability: Availability guarantees that the owning user of a keyless account can always transact and access their account, of course under the assumptions that (1) the OIDC provider is online, (2) the blockchain is live and, if training wheels are on, (3) the prover service is online.

Attacks

Assuming that (1) the keyless validation logic on the blockchain is sound and (2) the MPC ceremony for the ZKP has been done securely, our discussion focuses on what can go wrong in any of the following:

• the ZK circuit
• the pepper service
• the prover service
• the training wheels mode

To compromise a keyless account, an attacker must do all of the following:

• identify a soundness bug in the ZK circuit such that an attacker can create a proof for a statement without possessing a valid witness for the keyless relation (see AIP-61)
• depending on the circuit soundness bug, the attacker may also need to exfiltrate the victim user’s pepper
  • e.g., the ZK bug may be such that the witness still needs to contain the correct pepper
• identify a bug in the training wheels (TW) protection implemented on the prover service
  • e.g., exfiltrate the TW SK, or trick the prover service into providing a training wheels signature over a forged ZKP

To break privacy, an attacker must do any of the following:

• obtain the victim user's peppers
  • e.g., exfiltrate the SK of the pepper service
• identify a bug in the prover service such that the ZKP ends up leaking information about the secret witness
  • e.g., force the service to always use the same randomness when computing proofs
  • e.g., gain read-only access to the prover service’s memory and dump all proving requests and their secret witnesses

Notes on the pepper service

The pepper service is trusted to secure its secret key. Otherwise, an attacker in possession of this key can unblind keyless addresses by brute forcing their otherwise low-entropy user identifier and application identifier.

The pepper service is NOT trusted for security of the keyless account. In other words, a malicious pepper service on its own cannot take over a user's keyless account (i.e., not without exploiting a circuit bug and breaking the training wheels). For example, while the pepper service receives a user's JWT in order to authenticate the user before giving them their pepper, it does NOT receive the user's ephemeral secret key (ESK) and therefore cannot steal the user's keyless account.

However, currently, the pepper service is trusted with privacy. For example, the pepper service could perform the brute-forcing attack described above and unblind keyless addresses. But, it is (for now) trusted not to.

As is, the pepper service incidentally happens to serve as an additional layer of security against a large class of soundness bugs in the ZK circuit implementation. For example, even if an attacker can forge a ZKP without having a valid JWT for a keyless address, the attacker would still need the victim user's pepper, which it can only get from the pepper service in exchange for a valid JWT, which it does not have.

Notes on the prover service with training wheels enabled

The prover service is trusted to secure its training wheels secret key (TW SK). Otherwise, an attacker who is in possession of this key and identified a circuit soundness bug may be able to steal user funds (depending on whether the soundness bug affects the keyless address derivation from the pepper).

The prover service is trusted with privacy. The prover service receives the user's secret witness (e.g., the JWT, the pepper), learning who the user is and which keyless dapp they are using. For now, the prover service is trusted to not reveal this information.

Rewards are calculated based on the severity of the impact that the identified vulnerability would have on Aptos Keyless users. The following severity classifications include sample impacts per criticality, and potential Reward ranges. Aptos Foundation retains sole discretion to determine the severity classification of reported vulnerabilities and the amount of any Reward.

Critical

• Account compromise / loss of funds: up to $1,000,000

High

• Bypassing Training Wheels, enabling fraudulent zero-knowledge proofs (ZKPs) to be accepted without proper validation: up to $100,000
• Exploiting a ZK circuit vulnerability, allowing incorrect proof generation: up to $50,000
• Compromising the pepper service’s secret key, allowing attackers to deanonymize keyless users or link them to blockchain addresses: up to $50,000

Medium

• Leak of peppers for registered user(s) on-chain: up to $10,000
• Denial-of-service (DoS) attack on the prover service, preventing keyless users from generating valid ZKPs for transactions: up to $5,000

If you identify a security vulnerability impacting Aptos Keyless that does not fall under any of the above categories, we encourage you to report it for further analysis and we will consider a Reward as appropriate and within our sole discretion. Security issues impacting the Aptos Keyless having a root cause in external code dependencies are also in-scope for the program.

To be eligible for a Reward, you are required to:

• Play by the rules, including following these Rules and any other relevant agreements. If there is any inconsistency or conflict between these Rules and any other applicable terms, the applicable terms of these Rules will prevail;
• Submit an in-scope vulnerability as detailed above;
• Include detailed information and clear steps to reproduce the issue. Vulnerabilities must be reproducible using the code currently in scope for the Program, based on the current mainnet configuration, and must affect features that are either enabled or are set to be enabled via a governance proposal;
• Avoid any testing on live systems serving mainnet, testnet or devnet; all testing must be done locally;
• Report any vulnerability within 24 hours from discovery;
• Avoid disrupting our systems, destroying data, and/or harming users;
• Only use this platform to report and discuss vulnerability information with us;
• Provide us a reasonable amount of time to resolve the issue;
• Limit the data you access to the minimum required to effectively demonstrate a Proof of Concept in circumstances where a vulnerability provides unintended access to private data or secrets;
• Vulnerabilities based on social engineering or network Denial of Service (DoS) attacks are considered out of scope and are not eligible for Rewards under this program;
• Not engage in extortion.

Duplicate Reports

Rewards for duplicate reports will be split among reporters with first to report taking priority using the following equation:

R: total reports
ri: report priority
bi: bounty share

bi = 2 ^ (R - ri) / ((2 ^ R) - 1)

Where report priority derives from the set of integers beginning at 1, where the first reporter has ri = 1, the second reporter ri = 2, and so forth.

Note, reports that come in after the issue has been fully triaged and resolved will not be eligible for a Reward..

Do not discuss or disclose any vulnerabilities, even resolved ones, outside of this Program without the Aptos Foundation’s written consent.

You ARE NOT eligible to participate in the Program if you are:

• A "Restricted Person" as defined in the Aptos Foundation Terms of Use. To receive a Bounty, you will be required to complete an identity verification process to confirm that you are not a Restricted Person.
• Under the age of 16. If you are at least 16 years old but are considered a minor in your place of residence, you must obtain your parent's or legal guardian's permission prior to participating in this Program.
• Currently an employee or provide services to the Aptos Foundation or are a former employee or provided services to the Aptos Foundation within the last 12 months of your submitted security report.
• Employed by an entity that does not allow you to participate in the Program.

To receive a Reward, you will have to enter into an Agreement with Aptos Foundation and provide required information, which may include identity verification information and tax information or forms, such as a W-9 or W-8 for U.S. residents or citizens.

Rewards are managed by Aptos Foundation and are denominated in United States Dollars (USD). Rewards may be paid partially or fully in digital assets at the sole discretion of Aptos Foundation. If you receive digital assets as part of your Reward, the value of the digital assets in USD will be determined at the time you execute your Agreement with Aptos Foundation and after you have satisfied all eligibility criteria. Token-based rewards may be subject to a lock-up period.

Getting Started

• The Aptos Blockchain Whitepaper
• Aptos Blockchain Deep Dive
• Move - A Web3 Language and Runtime
• Engage with the Aptos community