Smart Wallets and Passkeys

Smart wallets with passkeys are the latest innovation in the crypto wallet space. The widely known conflict between UX and security that is at the center of all authentication services whether to use multi-factor authentication or not has its counterpart in the crypto space. Onboarding and creation of non-custodian wallets is extremely complicated and unfriendly for inexperienced users. Passkeys can be a way out. In this article we will address:

• What wallet types do exist and how do they differ?
• How can passkeys help in smart wallets and what examples exist?
• Which recommendations do we have for smart wallet providers?

We will address these questions by focusing on the Ethereum Network, the largest blockchain after Bitcoin. Unlike Bitcoin, which primarily serves as a store of value with limited smart contract capabilities, Ethereum offers a more versatile platform.

In the cryptocurrency space, wallets play a crucial role in managing digital assets. Understanding the various types of wallets is essential for both security and usability. Wallets can be broadly categorized into two main types: custodial and non-custodial. Each of these categories has different implementations and features, ranging from base addresses to smart contracts.

Subscribe to our Passkeys Substack for the latest news, insights and strategies.

Subscribe

Custodial wallets are managed by third-party services, typically exchanges or other financial institutions (e.g. Coinbase, Kraken or Binance). In these wallets, the service provider holds the private keys on behalf of the user, meaning the user trusts the custodian to secure their assets.

Advantages:

• User-Friendly: Custodial wallets are typically easier to use, as the service provider handles the security and management of private keys.
• Recovery Options: Since the custodian controls the private keys, users can often recover their accounts through customer support if they lose access.

Disadvantages:

• Trust Issues: Users must trust the service provider with their assets. If the custodian is hacked or becomes insolvent, users may lose their funds.
• Control: Users do not have full control over their assets, as the custodian has the ultimate authority over the wallet.

Custodial wallets are helpful for users and institutions that do not have the expertise to manage private keys. To shield the user from the complexity most of the work to protect the funds is invested into multiple forms of authentication with multi factor authentication and recovery options.

Non-custodial wallets give users full control over their private keys and, consequently, their digital assets. These wallets do not rely on a third party to manage or secure the funds.

Advantages:

• Control: Users have complete control over their assets and private keys, ensuring that they are the only ones who can authorize transactions.
• Security: Since private keys are not stored by a third party, the risk of centralized hacks or failures is eliminated.

Disadvantages:

• Complexity: Non-custodial wallets can be more complex to use, especially for beginners. Users must understand how to secure their private keys and backups.
• No Recovery Options: If users lose their private keys or recovery phrases, they may permanently lose access to their funds.

Traditionally, non-custodial wallets were preferably for more advanced users as they require custom software and knowledge on how to protect the private key from loss or recover it. In this article, we focus on non-custodial wallets and how passkeys are used to improve security, UX and adoption of the cryptosystem.

Become part of our Passkeys Community for updates and support.

Join

There are different types of non-custodial wallets. They differ by their characteristics on chain and where / how they are stored, but they are all built on the same foundation: a public-private keypair that can sign transactions and provide cryptographic proof of ownership.

Ethereum's cryptographic foundation relies heavily on the principles of elliptic curve cryptography (ECC), specifically using the secp256k1 curve. This type of cryptography is used to generate key pairs, which consist of a private key and a corresponding public key. Here’s a more detailed explanation of how Ethereum addresses are created and how they function within the network.

1. Private Key Generation: The process starts with the generation of a private key, which is a randomly selected 256-bit number. This number is kept secret and is the basis of a user’s security in the Ethereum network.

2. Public Key Derivation: Using the Elliptic Curve Digital Signature Algorithm (ECDSA) on the secp256k1 curve, the private key is used to derive a public key. The secp256k1 curve is specifically chosen for its security properties and efficiency in cryptographic operations.

3. Address Creation: The Ethereum address is obtained by taking the last 20 bytes of the Keccak-256 hash of the public key. This address is a 40-character hexadecimal string that serves as the identifier for the user's account on the Ethereum network.

• Unlimited Key Pairs: The cryptographic process allows for the generation of an unlimited number of unique key pairs. Each key pair is independent, and its security relies on the secrecy of the private key.

• Address Existence and Verification: An Ethereum address only becomes verifiable and active once a transaction is made involving that address. Before any transaction occurs, the address exists only as a potential within the vast space of possible addresses. When a transaction is initiated, the holder of the private key signs the transaction. This signature can be verified by anyone using the corresponding public key, which is sent alongside with the transaction, proving that the holder of the private key has authorized the transaction without revealing the private key itself.

Every transaction in the Ethereum network must be signed with the sender's private key. The signature ensures the integrity and authenticity of the transaction, allowing the network to verify that the transaction has indeed been authorized by the rightful owner of the address.

The signed transaction is broadcast to the Ethereum network, where nodes use the public key to verify the signature. This process confirms that the transaction is valid and can be recorded on the blockchain.

Within the Ethereum network, only key pairs generated using the secp256k1 curve are valid. This specificity ensures a standardized approach to cryptographic security, allowing the network to efficiently verify transactions and maintain a high level of security. Each address only becomes an active participant in the network upon the initiation of a transaction, ensuring that only valid, authorized activities occur within the Ethereum ecosystem.

There are different non-custodial wallets available. For better comparison, we have added also custodial wallets to this table. An overview of possible wallets for the Ethereum network can be found here.

Let’s have more detailed look at some of the non-custodial wallets:

• Software wallets: Can be desktop (e.g. Electrum, Exodus) or mobile (e.g. Metamask). They basically are a protection wrapper around the private key with a connection to the underlying network to be able to participate by sending and receiving transaction. Those wallets very often also have a browser extension or integration in order to be able to use the wallets for web3 logins or transaction authorizations in web (e.g. such as buying NFTs from OpenSea).

• Paper wallets: Not listed above are paper wallets – as they are mostly exported from software wallets. Paper wallets refer to private keys written down on paper. The actual format depends on the blockchain or the software wallet used to export. Ethereum private keys are typically represented as a long string of hexadecimal characters, but e.g. Metamask Wallet uses the BIP39 to provide a 12-word mnemonic phrase to protect a wallet that might contain Ethereum. This is one of the ways keys could be recovered.

An example how a BIP39 12-word mnemonic phrase looks like.

Taken from: https://ethereum.org

• Hardware wallets: These are physical devices designed to securely store private keys offline, significantly reducing the risk of hacking or malware attacks. Examples include Ledger and Trezor. They connect to computers or mobile devices via USB or Bluetooth when transactions need to be signed, keeping the private key isolated from potentially compromised devices.

Taken from: https://shop.ledger.com/de/products/ledger-nano-s-plus/matte-black

• Smart wallets (also known as: smart contract wallets): These are advanced non-custodial wallets that leverage smart contracts to offer enhanced features such as multi-signature security, social recovery options, and programmable smart contract interactions, automatic transaction approvals, spending limits or secure backups. This is achieved by utilizing the Ethereum blockchain's ability to execute code (smart contracts) automatically when predefined conditions are met. These smart contracts are deployed on the Ethereum network and can enforce rules (e.g. Gnosis Safe).

As we can see in the comparison, smart wallets use the possibility to elevate functionality by using smart contracts. In the following section, we’ll look at how this has been connected with passkeys.

Let's see how Ethereum has made smart wallets possible and what the steps are for using passkeys.

The Ethereum network continuously evolves through the introduction of Ethereum Improvement Proposals (EIPs) and Ethereum Request for Comments (ERCs). These are standards and proposals that enhance the network's functionality, security, and scalability. ERCs focus on defining application-level standards and conventions, such as token standards (ERC-20), non-fungible tokens (ERC-721), and advanced account management features (ERC-4337). By implementing these standards, the base functionality of the Ethereum network expands, allowing developers to embed more complex and versatile functionalities directly into smart contracts. This iterative process of community-driven proposals and implementations ensures that the Ethereum ecosystem remains innovative, adaptable, and capable of supporting a wide array of decentralized applications and services.

ERC-4337, also known as Account Abstraction, is a proposal that allows for the creation of smart contract-based accounts on the Ethereum network, enhancing the flexibility and functionality of wallet addresses. Traditional Ethereum accounts are based solely on a single key pair, but ERC-4337 introduces a layer of abstraction that enables the use of smart contracts to manage accounts. Account Abstraction has made significant progress in realizing the Ethereum developer community's long-standing goal of utilizing Ethereum Virtual Machine (EVM) code (underlying code of smart contracts) not just for application logic, but also for implementing the verification logic of individual user wallets. This opened possibilities for innovative wallet designs with more features like the mentioned multi-signature.

How ERC-4337 Works

Users send UserOperation objects, which encapsulate the user’s intent along with signatures and verification data. These objects can be bundled by miners or services like Flashbots into a single "bundle transaction" that is then included in an Ethereum block. The bundler pays the transaction fee in ETH and is reimbursed through fees collected from the individual UserOperations.

A smart contract wallet under ERC-4337 must implement two functions:

1. validateUserOp: Verifies the signature and nonce on the UserOperation, pays the fee, and increments the nonce if verification succeeds.

2. Execution function: Executes the calldata instructions for the wallet. This function is flexible and can be customized to perform multiple operations atomically.

The complexity of ensuring transaction safety and fee management is handled by a global contract called the "entry point," which ensures that only validated operations are executed, thus protecting wallets from potential attacks.

To incorporate passkeys into Ethereum applications using the ERC-4337 standard, two primary steps are required: client-side signing with passkeys and establishing smart accounts capable of verifying passkey signatures.

1. Generate and Sign Passkeys: Use the WebAuthn API to create and sign passkeys on the user's device. This involves generating a public-private key pair where the private key is securely stored, and the public key is used for verification.

2. Passkey Generation: Take a look into our tutorial on how to implement passkeys to get a basic understanding. Keep in mind that the passkeys can be used to login can be the same to use for a wallet but do not necessarily have to be.

1. Modify Smart Contracts: Implement smart contracts that can verify P256 signatures used in most recent passkeys. This requires modifying the validateUserOp function to include the P256 signature verification algorithm. This leads to the fact that wallets cannot be created on Windows 10, as they only support RS256 and not elliptic curves. See here to find out where P256 is supported.

2. Use Existing Frameworks: Streamline development by utilizing established frameworks such as Daimo's p256-verifier, which provide ready-to-use implementations for P256 signature verification.

3. Optimize Gas Costs: Consider the ongoing proposal EIP-7212, which suggests precompiling the P256 signature verification contract to reduce gas costs. This proposal is currently live on the Polygon network and expected to be integrated into Ethereum.

1. Deploy Smart Accounts: Include an initCode in the first user operation to deploy the smart account. This initCode is typically a hex concatenation of a smart account factory and an encoded call to create a new account owned by the passkey.

2. Sign User Operations: Use the WebAuthn API to obtain a signature from the passkey to sign the hash of the user operation. In ERC-4337, this process ensures secure transaction authorization using the passkey.

3. Implement Signature Verification: Ensure the validateUserOp function in the smart contract can verify the P256 signature, thus only executing valid, authorized transactions.

Since the inception of ERC-4337, there have been different production Implementations examples:

• ERC-4437 Smart Wallet controlled with Passkeys:

  • https://github.com/passkeys-4337/smart-wallet
  • https://passkeys-4337.vercel.app/

• Daimo.com Accounts

  • https://github.com/daimo-eth/daimo/blob/master/packages/contract/src/DaimoAccount.sol
  • https://daimo.com/blog/p256verifier (contribution of the first audited P256 verifier)

• https://safe.global/

  • https://docs.safe.global/home/passkeys-safe
  • https://github.com/safe-global/safe-modules/tree/main/modules/passkey/contracts/4337
  • https://github.com/safe-global/safe-modules/tree/main/examples/4337-passkeys

The most recent addition of passkeys to smart wallets is for the Coinbase Wallet SDK, that was inspired by DaimoAccount, launching their smart wallet service https://wallet.coinbase.com/smart-wallet at which we will take a closer look.

On 5th of June 2024, Coinbase launched its browser-based 'Smart Wallet' infrastructure claiming it “will allow wallet developers to provide users with passkey-based logins, easy access to Coinbase balances and the potential for gasless transactions”. We will look into the implementation from a passkey perspective (updated: 2024-06-16).

We start by registering a wallet on https://wallet.coinbase.com using deliberately a Windows 11 computer. Once you click on “Create a smart wallet”, the Windows passkeys creation process starts and completes successfully.

Open Coinbase smart wallet website Create a smart wallet Create a passkey Windows Hello success message Success message smart wallet creation

Let’s take a look into the WebAuthn ceremony in the background captured using chrome://device-log.

{
    "attestation":"direct",
    "authenticatorSelection":{
        "residentKey":"required",
        "userVerification":"preferred"
    },
    "challenge":"GUV0aGVyZXVtIFNpZ25lZCBNZXNzYWdlOgo5OUNvaW5iYXNlIFdhbGxldCBSZWdpc3RyYXRpb24KCk5vbmNlOiAyNTNkZjllNTg4NzM4ZTZhNTFjMTdlOTliNTBmZjI5ZQpIb3N0OiBhcGkud2FsbGV0LmNvaW5iYXNlLmNvbQ",
    "excludeCredentials":[
        
    ],
    "extensions":{
        "credProps":true
    },
    "pubKeyCredParams":[
        {
            "alg":-7,
            "type":"public-key"
        }
    ],
    "rp":{
        "id":"keys.coinbase.com",
        "name":"Coinbase Onchain Account"
    },
    "user":{
        "displayName":"Smart Wallet 6/16/2024",
        "id":"MGRjYTUwMTYtNTI5ZS00ZTRlLWE3ZDgtMjRmNDExOWM2Y2Nh",
        "name":"Smart Wallet 6/16/2024"
    }
}

What is interesting is that userVerification is only set to preferred . We would expect this to be set to required in order to be sure that the underlying authentication is indeed a two factor authentication. At the same time, we were surprised that creation of device-bound passkeys is allowed. Coinbase does not verify if the passkeys were actually backed up using the BE / BS flags that are part of the authenticator response. For Windows, currently, the BE / BS flags are consequently false. As user.id , a UUID is chosen as Base64 MGRjYTUwMTYtNTI5ZS00ZTRlLWE3ZDgtMjRmNDExOWM2Y2Nh (decoded: 0dca5016-529e-4e4e-a7d8-24f4119c6cca). The algorithm is set correctly to only allow P256 with alg being set to -7.

The challenge is also interesting. It’s also Base64 encoded and decoded returns the value below:

• Base64: GUV0aGVyZXVtIFNpZ25lZCBNZXNzYWdlOgo5OUNvaW5iYXNlIFdhbGxldCBSZWdpc3RyYXRpb24KCk5vbmNlOiAyNTNkZjllNTg4NzM4ZTZhNTFjMTdlOTliNTBmZjI5ZQpIb3N0OiBhcGkud2FsbGV0LmNvaW5iYXNlLmNvbQ
• Decoded:
• Ethereum Signed Message: 99Coinbase Wallet Registration
• Nonce: 253df9e588738e6a51c17e99b50ff29e
• Host: api.wallet.coinbase.com

Let’s see how the login is performed.

In order to be able to start from zero and actually add wallets, we needed to delete our browser information (cookies & LocalStorage) from the past hour because a lot of meta data is stored to remember existing wallets. This is not a security issue as performing an actual transaction required use of the passkey.

Select your wallet type Choose the way to access the smart wallet Perform passkey authentication Provide your local authentication, here: Windows Hello PIN Approve connection request to Coinbase wallet

Once we tried to connect the wallet, we had to choose the passkeys belonging to the wallet. For the name of the wallet, it would be better to let the user choose a more relatable name to distinguish potentially different wallets. Let's look at the WebAuthn authentication ceremony:

{
    "allowCredentials":[
        
    ],
    "challenge":"GUV0aGVyZXVtIFNpZ25lZCBNZXNzYWdlOgo5NENvaW5iYXNlIFdhbGxldCBTaWduIEluCgpOb25jZTogYTc1MDZjOTNiYzY4YjYyY2M4N2E1ZjU4MGM2YmRmMzMKSG9zdDogYXBpLndhbGxldC5jb2luYmFzZS5jb20",
    "rpId":"keys.coinbase.com",
    "userVerification":"preferred"
}

Again, we noted that userVerification is set to preferred which should not be the case for an application like a wallet. This has some severe security drawbacks, that we will cover in our review in the next chapter. The challenge is in the same format containing another nonce.

Coinbase has greatly simplified the onboarding of crypto wallets with their smart wallets that support passkeys. We could receive ETH within seconds on our newly created address, but this is not part of the article. There are some severe security considerations that we need to flag.

• ⚠️⚠️⚠️ Support of device-bound passkeys on Windows: In our opinion, this is a significant failure in the smart wallet design. There is no possibility to export or backup such a key as it is not synced or backed up in any cloud. Anyone using Coinbase Smart Wallets with Windows 11 without a password manager will inevitably lose access to the wallet at some time when the computer is defect, reinstalled or changed. A lot of consumers do not know that. Coinbase has pointed out that it will provide recovery features and multiple holders in the future, but it seems the functionality has only been tested and designed with Macs and mobile phones in mind.
• ⚠️⚠️ User verification is not required: In the ceremony, userVerification is not set to required to utilize self-contained MFA security of passkeys. This should be the case as the wallet here is directly accessed without any other authentication method, while MFA is the standard for protecting custodian wallets.
• ⚠️ User verification flag is not checked: On Windows computers, userVerification is done for every WebAuthn operation, but this is not true on Macs. Best practice after userVerification is required on every authentication is to check the flag for being true. This is not done here as verification is only requested preferred.

While Coinbase has put significant effort into the cryptographic security of its blockchain & smart contract source code with two security audits by Certora and Cantina, their passkey implementation should also be challenged from a security perspective.

We will not provide recommendations for the implementation of smart contracts, as other experts can offer better advice. Since smart contracts also use cryptography, it is generally advised not to implement them yourself when there are open source audited versions. Instead, use a major open-source implementation or library to ensure that no mistakes are made.

Therefore, here are our recommendations from a passkey perspective:

1. Define a Clear Objective and Target Market: Define your target audience clearly. If aiming for a wide consumer market, prioritize minimizing risks and enhancing user experience. For example, only allow platform authenticators (e.g. Windows Hello, Face ID, Touch ID) that backup passkeys. To access services on desktops, leverage QR codes to use passkeys which are stored on synced mobile devices.

2. Enforce Cloud-Synced Passkeys: Only accept passkeys that are synchronized to the cloud (where the BE & BS flag is true). This ensures that users have a backup and can recover their wallets if they change devices or if a device is lost.
   
   Verify the BS flag on every login. Alert the customer if their passkey is not backed up to mitigate the risk of losing access to their wallet.

3. Support for Windows 11: CDA Creation via QR Codes: For supporting Windows 11 devices, use Cross-Device-Authentication (CDA) creation via QR codes. This allows users to create the passkey directly on a mobile device and authenticate using CDA, ensuring better security and recovery options. We recommend to use CDA here, as passkeys on Windows 11 are by default only device-bound (they use Windows Hello if no third-party password manager is managing the passkeys).
   
   Windows 10 with Chrome & Edge version > 69 can also be supported using a CDA-approach.

4. Enforce User Verification: All authentication processes should require user verification "userVerification=required". This enhances the security of the smart wallet.
   
   Ensure the UV (User Verification) flag is set to true/1 during the WebAuthn ceremony. Verify the user verification requirement on every login. If any change is detected, prompt the user to re-authenticate with proper user verification. This prevents the possibility of forged authentications. Deny the ceremony if the UV flag is not correctly set, thereby enforcing strong authentication.

5. Optional: Support Hardware Security Keys: If you plan to support hardware security keys (like YubiKeys), allow for BS = 0 only with hardware security keys. Ensure to verify that indeed a hardware security key is used by checking the AAGUID and verifying their attestation.
   
   Educate users on the differences and risks associated with using hardware security keys compared to cloud-synced passkeys.

6. Define Logical Names for Relying Party ID and Wallet: Passkeys are bound to a Relying Party ID (rpID) that defines for which domain a passkey can be used. Find a suitable Relying Party ID value in case you want to use the same passkey for authentication in your wallet service and simultaneously use the passkey to create a wallet on the blockchain. The following options exist, let’s assume the service runs under example.com.

If not defined clearly, the users might be confused which passkeys to use. For more information look here.

Furthermore, it is helpful for users to be able to give a name to the passkey, which then is used to display it in the browser in case there are multiple wallets involved. Set the WebAuthn user.displayName and user.name accordingly. This could be for example the purpose or a name “My private smart wallet”. Keep in mind that currently that information cannot be updated in a convenient way.

By implementing these recommendations, smart wallet providers can enhance the security, usability, and overall trustworthiness of their products, ensuring a safer and more user-friendly experience for their customers.

In this article, we addressed several key questions regarding smart wallets and passkeys, focusing on the Ethereum Network. Here’s a summary of our findings:

• What wallet types exist and how do they differ?
  We explored custodial and non-custodial wallets, highlighting their respective advantages and disadvantages. Custodial wallets offer ease of use and recovery options but require trust in third parties. Non-custodial wallets provide complete control over assets but come with increased complexity and the risk of permanent loss if keys are lost.
• How can passkeys help in smart wallets and what examples exist?
  Passkeys can enhance security and user experience in smart wallets by offering a seamless and secure method of authentication. Examples of implementations include Coinbase's new smart wallet service which is based on ERC-4337 Smart Wallets.
• Which recommendations do we have for smart wallet providers?
  Our recommendations include enforcing cloud-synced passkeys, requiring user verification and ensuring proper naming conventions for wallets. These measures aim to improve security and user experience, minimizing risks associated with wallet access and management.

Finally, our recommendations for passkey usage are designed to ensure a high level of security and usability. Implementing passkeys requires the same rigorous attention to detail as developing secure blockchain smart contracts. By following these guidelines, smart wallet providers can create more robust and user-friendly products, ultimately contributing to a safer and more accessible crypto & passkey ecosystem. We are happy to help with any questions.