Passkeys are a secure and user-friendly approach to authentication that can also be used to create and securely store crypto wallets, thanks to their use of elliptic curve cryptography.
In this post, we’ll cover how passkeys work, explore the risks of using passkeys for crypto wallets, and dive into how account abstraction enables passkeys to be used when combined with smart contracts.
Passkeys are a simple and secure way for users to sign into an application without requiring them to store sensitive passwords or remember any login details. Instead, users create and access accounts using familiar methods like biometrics such as Face ID or Touch ID.
This enables users to easily log in and interact with applications in an authorized manner without ever storing sensitive credentials; providing a seamless experience and additional security against data breaches and common attack vectors such as phishing.
On most devices, such as the iPhone, passkeys are stored inside specialized hardware called the Secure Enclave; a dedicated, isolated environment designed to protect sensitive data even if the main processor is compromised.
Passkeys utilize public key cryptography to generate a public-private key pair on the user’s device, consisting of two keys:
Like blockchain wallets, the private key of a passkey can be used to sign messages and transactions that can be sent to make state changes on a blockchain.
To sign a transaction with a passkey’s private key, the transaction is sent to the secure hardware, where it is signed, and the resulting signature is then output. Throughout this process, neither the owner nor the app developer ever has access to the private key; they only receive the generated signatures.
This provides enhanced security for the user, as the private key is typically not loaded into the application’s memory, reducing the risk of exposure to potential attacks. For example, on the iPhone, the user cannot even access the value of the passkey within their settings, as the key is generated and stored in specialized hardware that is not accessible to the interface.
Passkeys and crypto wallets share the same underlying technology of elliptic curve cryptography to generate public-private key pairs. Blockchain application developers can make use of passkeys to create secure in-app wallets for users with a powerful UX.
However, there is one important difference that introduces complexity when using passkeys for blockchain accounts; passkeys use a different elliptic curve than blockchain accounts.
While Apple, Android, and WebAuthn all use the secp256r1 (AKA P-256) curve for passkeys, blockchain accounts use the secp256k1 elliptic curve.
This means transactions signed by the private key of a passkey are not understood (and therefore rejected) by blockchains such as Ethereum or Abstract. The default expectation of blockchains is that the transaction is signed by a key pair generated on the secp256k1 curve.
Since regular (EOA) wallets are generated on the k1 curve, smart contract wallets are therefore required, as they can include custom logic that verifies transactions signed by private keys generated by passkeys before authorizing transaction execution.
Bitcoin was the first to adopt the secp256k1 curve for cryptographic operations, which set the standard for Ethereum and other EVM-based chains to use the k1 variation of the curve for accounts.
The k1 variation of the curve also lacks certain features like additional coefficients that make secp256r1 slightly more complex, meaning secp256k1 is more computationally efficient for key generation, signature creation, and verification.
Although no direct vulnerabilities have been found, there are also conspiracy theories that exist that Bitcoin chose to use the k1 over the more well-adopted r1 curve to avoid any potential for a backdoor that might have been secretly introduced by government agencies like the NSA, given their involvement in the development of NIST-endorsed cryptographic standards.
Smart contract wallets (such as those supported by Abstract’s native account abstraction) can contain arbitrary logic for the EVM to execute; including signature verification for messages it receives signed by a private key created on the r1 curve.
Open-source libraries like Daimo’s open-source P256 verifier have been built to verify signatures on the secp256r1 curve inside of smart contracts written in Solidity.
On Ethereum, this means you can use smart contracts built with the ERC-4337 account abstraction standard to verify the r1 signature of the User Operation inside the validateUserOp
function of the smart contract wallet.
On Abstract, native account abstraction enables smart contract wallets to submit transactions with the signature field set as the message signed by the private key of the passkey. If the account that sent the transaction is a smart contract that includes logic to verify r1 signatures (in the validateTransaction
function), the transaction is accepted.
Smart contract wallets use code (in the form of a smart contract) to manage and control their functionality, meaning they can have any custom features; including recovery modules, multiple approved signers, spending limits, session keys, and more.
Smart contract wallets offer more flexibility than traditional EOA (Externally Owned Accounts) wallets and since they can include arbitrary EVM code, have the power to verify signatures (i.e. authorize transactions) from key pairs created on the r1 elliptic curve.
As verifying signatures on the r1 curve is not native to blockchains like Ethereum or Abstract, it is computationally expensive to perform this verification; leading to drastically increased gas costs to verify r1 signatures as opposed to k1 signatures (roughly 100x more expensive).
RIP-7212 (Rollup Improvement Proposal) proposes the addition of a precompiled smart contract to Ethereum L2s for more gas-efficient signature verification on the r1 curve. While this is not yet included on Ethereum, EVM-compatible scaling solutions such as Abstract have already implemented this and provide a 100x gas reduction for r1 signature verifications.
The downside to passkey wallets is the fact that they are tied to a single domain. For example, if you create a wallet on some-domain.com, your passkey (and therefore your wallet) is only able to connect to that specific domain.
This is an intentional design choice to avoid phishing attacks, however, poses a major flaw for users valuing self-custody, as your wallet is tied directly to one application; meaning:
For these reasons, passkey wallets are most suitable for small sums of money or to onboard beginner users to their first crypto experiences until they become more knowledgeable about self-custody wallets.
This depends on how you choose to back up your passkey. There are several options to back up your passkey into the Cloud (such as Apple Keychain) to be accessible across other devices even if you lose your original one.
The private key cannot be read on the device at any point since it is in the Secure Enclave. However, if they have access to your biometric data they can perform operations as if they had control of your passkey/wallet.
No. Your biometrics are not sent anywhere; they stay on your device. Your biometric data is simply used to “unlock” the passkey.
Passkeys are a secure and user-friendly approach to authentication that can also be used to create and securely store crypto wallets, thanks to their use of elliptic curve cryptography.
In this post, we’ll cover how passkeys work, explore the risks of using passkeys for crypto wallets, and dive into how account abstraction enables passkeys to be used when combined with smart contracts.
Passkeys are a simple and secure way for users to sign into an application without requiring them to store sensitive passwords or remember any login details. Instead, users create and access accounts using familiar methods like biometrics such as Face ID or Touch ID.
This enables users to easily log in and interact with applications in an authorized manner without ever storing sensitive credentials; providing a seamless experience and additional security against data breaches and common attack vectors such as phishing.
On most devices, such as the iPhone, passkeys are stored inside specialized hardware called the Secure Enclave; a dedicated, isolated environment designed to protect sensitive data even if the main processor is compromised.
Passkeys utilize public key cryptography to generate a public-private key pair on the user’s device, consisting of two keys:
Like blockchain wallets, the private key of a passkey can be used to sign messages and transactions that can be sent to make state changes on a blockchain.
To sign a transaction with a passkey’s private key, the transaction is sent to the secure hardware, where it is signed, and the resulting signature is then output. Throughout this process, neither the owner nor the app developer ever has access to the private key; they only receive the generated signatures.
This provides enhanced security for the user, as the private key is typically not loaded into the application’s memory, reducing the risk of exposure to potential attacks. For example, on the iPhone, the user cannot even access the value of the passkey within their settings, as the key is generated and stored in specialized hardware that is not accessible to the interface.
Passkeys and crypto wallets share the same underlying technology of elliptic curve cryptography to generate public-private key pairs. Blockchain application developers can make use of passkeys to create secure in-app wallets for users with a powerful UX.
However, there is one important difference that introduces complexity when using passkeys for blockchain accounts; passkeys use a different elliptic curve than blockchain accounts.
While Apple, Android, and WebAuthn all use the secp256r1 (AKA P-256) curve for passkeys, blockchain accounts use the secp256k1 elliptic curve.
This means transactions signed by the private key of a passkey are not understood (and therefore rejected) by blockchains such as Ethereum or Abstract. The default expectation of blockchains is that the transaction is signed by a key pair generated on the secp256k1 curve.
Since regular (EOA) wallets are generated on the k1 curve, smart contract wallets are therefore required, as they can include custom logic that verifies transactions signed by private keys generated by passkeys before authorizing transaction execution.
Bitcoin was the first to adopt the secp256k1 curve for cryptographic operations, which set the standard for Ethereum and other EVM-based chains to use the k1 variation of the curve for accounts.
The k1 variation of the curve also lacks certain features like additional coefficients that make secp256r1 slightly more complex, meaning secp256k1 is more computationally efficient for key generation, signature creation, and verification.
Although no direct vulnerabilities have been found, there are also conspiracy theories that exist that Bitcoin chose to use the k1 over the more well-adopted r1 curve to avoid any potential for a backdoor that might have been secretly introduced by government agencies like the NSA, given their involvement in the development of NIST-endorsed cryptographic standards.
Smart contract wallets (such as those supported by Abstract’s native account abstraction) can contain arbitrary logic for the EVM to execute; including signature verification for messages it receives signed by a private key created on the r1 curve.
Open-source libraries like Daimo’s open-source P256 verifier have been built to verify signatures on the secp256r1 curve inside of smart contracts written in Solidity.
On Ethereum, this means you can use smart contracts built with the ERC-4337 account abstraction standard to verify the r1 signature of the User Operation inside the validateUserOp
function of the smart contract wallet.
On Abstract, native account abstraction enables smart contract wallets to submit transactions with the signature field set as the message signed by the private key of the passkey. If the account that sent the transaction is a smart contract that includes logic to verify r1 signatures (in the validateTransaction
function), the transaction is accepted.
Smart contract wallets use code (in the form of a smart contract) to manage and control their functionality, meaning they can have any custom features; including recovery modules, multiple approved signers, spending limits, session keys, and more.
Smart contract wallets offer more flexibility than traditional EOA (Externally Owned Accounts) wallets and since they can include arbitrary EVM code, have the power to verify signatures (i.e. authorize transactions) from key pairs created on the r1 elliptic curve.
As verifying signatures on the r1 curve is not native to blockchains like Ethereum or Abstract, it is computationally expensive to perform this verification; leading to drastically increased gas costs to verify r1 signatures as opposed to k1 signatures (roughly 100x more expensive).
RIP-7212 (Rollup Improvement Proposal) proposes the addition of a precompiled smart contract to Ethereum L2s for more gas-efficient signature verification on the r1 curve. While this is not yet included on Ethereum, EVM-compatible scaling solutions such as Abstract have already implemented this and provide a 100x gas reduction for r1 signature verifications.
The downside to passkey wallets is the fact that they are tied to a single domain. For example, if you create a wallet on some-domain.com, your passkey (and therefore your wallet) is only able to connect to that specific domain.
This is an intentional design choice to avoid phishing attacks, however, poses a major flaw for users valuing self-custody, as your wallet is tied directly to one application; meaning:
For these reasons, passkey wallets are most suitable for small sums of money or to onboard beginner users to their first crypto experiences until they become more knowledgeable about self-custody wallets.
This depends on how you choose to back up your passkey. There are several options to back up your passkey into the Cloud (such as Apple Keychain) to be accessible across other devices even if you lose your original one.
The private key cannot be read on the device at any point since it is in the Secure Enclave. However, if they have access to your biometric data they can perform operations as if they had control of your passkey/wallet.
No. Your biometrics are not sent anywhere; they stay on your device. Your biometric data is simply used to “unlock” the passkey.