Passkeys wallet on the EVM
A feedback from the field.
Writen in collaboration with Quentin Nivelais.
Why do we need Passkeys in the first place ?
The web3 onboarding problem
We all agree that current non-custodial wallets pose challenges for new users, from setup and managing the seed phrase to the on-ramp required for transactions…
The emergence of account abstraction allows us to address many of these issues with features like gasless transactions, batching, and social recovery. However, it does not fully resolve the user experience issue for mainstream adoption.
MPC models, utilized by companies like Web3Auth or Magic Link, offer an excellent user experience but do not preserve privacy or maintain complete non-custodianship, creating a dependency on a centralized service.
One might wonder: Is it possible to achieve a good UX without compromising privacy and security?
Since the beginning of 2023, Passkeys have been gaining traction in the blockchain space, promising improved UX and security through key features.
Now… What are Passkeys exactly ?
Passkeys are a digital credential built on the webAuthn standard, aiming to provide a more convenient and safer alternative to passwords.
Using passwords puts a lot of responsibility on users. Choosing strong passwords and remembering them across various accounts can be hard. In addition, even the most savvy users are often misled into giving them up during phishing attempts. 2SV (2FA/MFA) helps, but again puts strain on the user with additional, unwanted friction and still doesn’t fully protect against phishing attacks and targeted attacks like “SIM swaps” for SMS verification. WebAuthn helps address all these issues.
With Passkeys, the private key behind the passkey lives on your devices and in some cases, it stays only on the device it was created on. In other cases, your operating system or an app similar to a password manager may sync it to other devices you own. Passkey sync providers like the Google Password Manager and iCloud Keychain use end-to-end encryption to keep your passkeys private.
Now… What is WebAuthn ?
The Web Authentication API, developed by the W3C and the FIDO Alliance, is compatible with all major platforms and browsers. It enables users to sign in by unlocking their computer or mobile device using fingerprint, facial recognition, or a local PIN.
This API allows servers to register and authenticate users through public key cryptography, rather than passwords.
For each website, a private-public key pair based on ECDSA (referred to as a credential) is generated. The private key is securely stored on the user’s device, while the public key and a randomly generated credential ID are transmitted to the server for storage. The server then utilizes this public key to confirm the user’s identity through a process that involves the signing and verification of a challenge, effectively proving the user’s identity without requiring a password.
Given that the key distinction between Passkeys and WebAuthn lies in their synchronization capabilities, I will use the term ‘Passkeys’ throughout the remainder of this article.
Sounds interesting… But what’s your point ?
With Passkeys, the credentials are created with best platform security rules:
Stored at the hardware level: Credentials are stored within the device’s Hardware Security Module (HSM), in specialized chips such as the iOS Secure Enclave or Android StrongBox.
Signature in the enclave: All signatures are executed directly within the enclave, rather than in the client software or the browser.
Biometric gatekeepers: Biometric locks are enforced directly within the device’s enclave. Private keys are shielded from external API access; they are exclusively activated for digital signing through the device’s lock screen protocols.
Domain bound credentials: Credentials are scoped to specific domains, significantly reducing the risk of phishing, man-in-the-middle, and replay attacks. This is because the authenticator responds only to legitimate requests from the originating domain that created the credential and signs a unique challenge for each authentication session.
Another interesting feature is that the challenge signed during the authentication is a 32 bytes message that can contain ANYTHING. A random message, a hash… You see where I’m going with this ?
Why not use it in the blockchain and sign a tx hash ?
But…That’s it ? How is that possible? What wizardry is this ?
2 keys innovations allow us to make that happen:
Onchain P256 signature verifier: We eliminate the server component of the Passkeys signing ceremony, replacing it with a smart contract capable of verifying the signature on-chain. Opclave introduced the first implementation of such a verifier, followed by an optimized version developed by the Ledger team.
Account abstraction (AA): Smart wallets enable us to use a different curve than Ethereum’s (secp256k1 in this case) for signing messages and verification.
AA x Passkeys — Yoan’s experience
A little background
My name is Yoan, I work as a software/blockchain developer at Cometh, a leading company in web3 gaming that provides middleware and tools for web3 projects. I am the lead developer of Cometh Connect, an account abstraction SDK built on Passkeys and the Gnosis Safe smart wallet.
Connect is currently live and serving multiple clients worldwide, with daily activity providing us with valuable feedback from end-users.
Cometh Connect passkeys implementation
At the start of 2023, Cometh worked with Renaud Dubois and the Ledger cryptographic team on one of the first implementations of his FCL library. This collaboration aimed to optimize the on-chain verification of the secp256r1 elliptic curve (shoutout kelvyne). The first implementation involved a small dApp that demonstrated the practical feasibility of this technology in a real-world scenario
https://x.com/Cometh/status/1641728767864320001?s=20
What began as a proof of concept has evolved into a product we now offer to other projects and applications known as Cometh Connect. The concept was to introduce a smart wallet equipped with a signer capable of signing and verifying messages through EIP1271 and Passkeys, utilizing the FCL library. This integration aims to merge the safety and modularity of smart accounts with the enhanced security and user experience offered by Passkeys, including biometric authentication and Touch ID.
Now, with that in mind, we started to think about what our product should offer as features:
P256 signer implementation on Safe: We developed the first p256 signer for a safe ,optimizing it for minimal fees for deployment and signing, and adapted the passkey signature to fit the safe format. We decided against using the precomputed version of the FCL library due to our use of lazy deployment, as predicting the wallet address proves more challenging with precomputation. However, we remain open to revisiting this decision based on our ongoing analysis of wallet activity and client needs.
SDK for Client interactions: We developed a suite of SDK (ethers, viem and unity) designed to facilitates passkeys/wallet interactions, managing the logic on the client side. This suite supports the various implementations of passkeys across different operating systems (iOS, Android, Windows, etc.) and types of authenticator attachments (platform-specific, cross-platform, etc.).
Privacy preserving by design: Cometh Connect does not require users to share personal details with us, including email, phone numbers, or even usernames. Authentication relies solely on the public address of the smart wallet and the passkey, enhancing both security and user anonymity.
Passkeys synchronization feature: As mentioned earlier, passkeys enable secure access to credentials/private keys across multiple devices, assuming they are synchronized. We leverage this feature to facilitate the retrieval and connection of a wallet on different devices without requiring any backend, provided the devices are synced.
Onchain Social recovery: Depending on the scenario, your key might be stored on a unique device that you can lose. To mitigate that we needed an on-chain recovery system. We are using the safe recovery hub.
Lazy deployment: We aim to predict the smart wallet address and deploy it only when necessary. To do that we generate a public key credential during the generation of the first instance of the account. This key can then be passed to the safe contract factory and p256 signer factory enabling us to predict both contract addresses with the CREATE2 opcode.
Offline compatibility: Signing can work offline as long as the webAuthn api is supported by the browser.
Combining all those features gave us a pretty solid foundation for a product that we think will help a lot of projects. We are already working on other features and improvements that we think are going to enhance the experience of end users and projects.
Building our solution, we ran into some challenges that I wanted to share in this article:
FCL cryptographic optimization: As previously mentioned, Cometh collaborated with Renaud Dubois on implementing the P256 verifier, facing significant cryptographic challenges along the way. For those interested in diving deeper into this topic, here is a video that provides more insight.
Domain bound credentials: As credentials are bound to devices and domains (urls), we had to develop secured ways of handling multiple devices using the same wallet when the credentials are not synced.
Signature malleability interrogation: Given that the secp256r1 curve is based on ECDSA, it is also susceptible to signature malleability. In our case, as we use it with a gnosis safe implementation, we are already protected by the nonce preventing any replay attacks. The question remains relevant for other cases, according to the p256 specification this restriction is not present.
Browser/OS passkeys implementations: Passkeys integration is very different depending on the browser and OS running. For example, Windows only supports ECC passkeys since Windows 11, Mac and IOS support is flawless (thanks Apple), same for Android… Overall, it’s evident that major technology companies are moving towards adopting Passkeys as a standard
AA x Passkeys — Quentin’s experience
A little background
Let me introduce myself, I’m Quentin, the CTO of Frak-labs. Our mission is to revolutionize content distribution and consumption, but that’s a conversation for another day.
As of now, we have over 17,000 users for our initial MVP. Notably, about 20% of them use EOA, while the rest utilize smart wallets, specifically the Kernel Smart Wallet. This type of wallet adheres to the ERC-4337 and ERC-6900 conventions, offering comprehensive modularity around the smart account signer.
Frak passkeys implementation
Wanting to contribute to ERC4337 and account abstraction at the end of 2023, we formed partnerships with Pimlico for the infrastructure layer (bundler and paymaster), and ZeroDev for the smart account aspect. We contributed significantly to both projects, enhancing the developer experience when interacting with their SDKs and projects.
We particularly contributed to the Kernel Smart Account, introducing a new type of Validator. This is a module around a smart account that validates user operations and signatures.
At the moment, we’re working on a proof of concept (stay tuned for updates) that offers an alternate solution to the traditional subscription paywall, which can often be a source of friction for users. To tackle this, we’re introducing a pay-as-you-go paywall that utilizes WebAuthn and Kernel Smart Wallet.
Using passkeys features, this new approach presents fresh opportunities for businesses. They can sponsor transactions which users can validate with a simple tap, allowing almost instant access to articles.
To achieve this, inspired by Cometh’s work, we suggested a new validator using passkeys to ZeroDev.
Despite Cometh already having an implementation, we had to start from the ground up to ensure compatibility with the Kernel smart wallet. We constructed a compact client SDK (which is not yet available, but we hope to incorporate it into the kernel SDK soon), and a new validator to validate the passkey signature in a gas-efficient manner (minimizing the number of elements needing deployment, and leveraging new strategies to reduce overall gas usage). You can find this work here: ZeroDev Kernel Pull Request.
Our POC yielded numerous insightful learnings, many of which resonated with Yoan’s experiences. Here are some of the key takeaways:
Passkeys are getting more accessible: Despite passkeys not being widely adopted yet and potentially appearing complex to implement, it’s actually well-documented and there’s already a significant amount of work done to facilitate its integration (thanks Cometh !).
FCL cryptographic optimization: Renaud’s work with the ledger team on the optimized version of the p256 curve verification is truly outstanding.
ERC4337 compatibility: We ran into some hurdles with one of the prerequisites of ERC-4337 for sponsoring the transaction. The paymaster requires a dummy signature to calculate the transaction validation cost, but asking our users to perform two signatures for one transaction is far from ideal. Crafting this dummy signature for each transaction, while finding the right data schema, posed a challenge.
Passkeys are the future: Passkeys, especially when used with biometrics for transaction validation, are a breath of fresh air compared to traditional methods like password verification or 2FA. This experience really highlighted how web2 is falling behind and convinced me that the combination of this standard with blockchain will be the key to mass adoption of web3.
Our shared vision of Web3 onboarding
To better understand the different approaches and decisions made by each company, let’s first identify the commonalities. Both Cometh and Frak are committed to the widespread adoption of web3, not just for financial transactions. Cometh, true to its pioneer roots, offers one of the first passkey based blockchain SDK to onboard users. Frak, on the other hand, aims to revolutionize how users interact with content, such as newspaper articles, online videos, music streaming, and more.
Smart Wallet for the win
Due to their product model and the experimental phase, Frak required an innovative solution capable of processing potentially millions of micro-transactions daily with high efficiency. This demanded a highly optimized technical stack, particularly to minimize gas fees — a critical factor since, in microtransactions, gas fees could surpass the transaction value itself. They opted for the Kernel smart wallet, distinguished by its modularity and efficiency. However, wallets like Kernel are subject to frequent updates, including occasional breaking changes, which occur every three to six months.
For Cometh, selecting Safe offered them access to a fully audited suite of contracts and modules, featuring functionalities such as session keys, social recovery, and recent support for ERC4337. Considering their smart wallet currently manages assets worth 70 billion, opting for Safe was a clear decision for them. The Safe mobile app also enables end-users to directly utilize the Safe created via Cometh, incorporate a regular signer, and engage with the entire web3 ecosystem. However, this approach currently necessitates deploying new signers (p256) for each user.
If you want to go into more details about gas differences, here is a benchmark that we are working on using foundry.
Passkeys for the UX
In our opinion, although Passkeys are an ideal “kickstart” mechanism to onboard a user, it might not always be the right solution as the only signer setup within a smart account. In some cases we envisioned a smart wallet that can be initially provisioned by a Passkey, yet can add other signers and even remove itself if needed. This would erase any friction for onboarding users, letting them learn and experience crypto instead of throwing them into the web3 jungle right away.
ERC4337 for decentralization
ERC4337, a new standard for account abstraction, was still in its draft phase and undergoing frequent updates in early 2023, prompting Cometh to wait for it to stabilize and gain broader adoption.
With their wallet migration at the end of 2023, Frak adopted it immediately. This decision enabled them to leverage different bundlers and paymasters based on transaction speed, offering significant versatility and ensuring optimal performance.
As ERC4337 matures and sees increased adoption, Cometh is preparing to launch an ERC4337-compatible version of their SDK in the near future.
All in one SDK
Cometh chose to develop their own SDK to simplify the management of passkeys and all features related to account abstraction for their clients. They produced TypeScript versions, including adapters for ethers and viem/wagmi, as well as a Unity version tailored for gaming applications. Through Connect, Cometh provides a comprehensive SDK suite that enables startups and enterprises to seamlessly transition from web2 to web3, ensuring a smooth and secure user experience.
Frak, conversely, offers a custom wallet with an available SDK for content corporations to integrate and add to their existing paywalls. They chose Pimlico permisionless.js, which was one of the first ERC-4337 SDKs that worked with Viem and Wagmi. Given that a significant number of our end-users are mobile users, some with older devices, it was critical to select a lightweight and fast SDK.
End user — Performance
From the perspective of the end-users, the differences between both solutions may not be immediately noticeable, save for a tiny slight speed advantage that Frak might possess, while Cometh allows for more flexibility and interoperability with all the available modules.
The impact on the end user is relatively minor, with the main changes affecting the developer experience, potential for future improvements, and overall system reliability and security.
A look into the future
With the emergence of these new solutions, we are witnessing a future where achieving mainstream UX standards without compromising the fundamental principles of blockchain is becoming a reality. The combination of Passkeys and account abstraction enables projects to provide their users with the best of both worlds. Our prediction is that we will see many applications where wallets become invisible, allowing the user experience to take center stage while the blockchain technology operates seamlessly in the background.
However, challenges remain, and here are some potential developments we see that could push forward the adoption of these technologies:
Native P256 curve verification: A native EVM implementation of the P256 curve could significantly lower gas fees for signature verification, currently ranging from 180 to 300k gas, down to approximately 3,45k gas with EIP-7212. The Opclave team is pushing in that regard with EIP7212, and a RIP is being adopted as we speak.
Full Passkey client/hardware adoption: Passkeys are already widely adopted, yet some browsers lag in support, and certain operating systems are only beginning to transition (Windows hello only added ECC algorithms since windows 11).
Clear-signing for Passkey signature: Another issue is that, with current implementations, the default mode is blind signing. This might not be a big deal for most applications, but it can be needed for use cases where clear signing is required (Defi for example).
Web wallet centered around Passkeys: Another interesting idea would be to have a web wallet that could handle passkey signatures. That way you could bypass domain restrictions and get compatibility across multiple urls. However, this approach introduces security concerns, as reliance on a specific URL could become a single point of failure. Cometh is actively exploring solutions to address this.
Native account abstraction: If we broaden the spectrum of EVM chains, a few ZK rollups (Starknet and zkSync to my knowledge) are incorporating native account abstraction in their architecture. Coupled with potential passkeys implementations, this could lead to great innovations and a relative low cost for signature verification. Some projects are already working on this like Cartridge.
Dapps support for smart wallet signatures: A lot of Dapps are not supporting EIP1271 signatures as of now. Major applications like Opensea or Uniswap are pushing forward but there is still a lot of work to do. Cometh built a library to facilitate signature verification for other projects.
La Fin.
Thank you for reading.
