Everyone is talking about Account Abstraction (AA) and its potential to revolutionize the user experience in the blockchain space. However, the main misunderstanding about AA is that it goes beyond merely abstracting gas fees or enabling batch transactions. How? Through programmable key management systems.

These systems can provide hardware-level security for everyday devices and integrate Web2 authentication methods into Web3 environments, allowing us to move beyond the traditional 12-word seed phrases. Today, I’ll explain different key management systems that developers can utilize and the specific use cases where they are most useful.

Moving beyond 12 words

Our industry loves buzzwords, and “seedless” is one of the latest to capture attention. While we all agree that expecting users to store their private keys securely is impractical and has resulted in the loss of millions of dollars, the question remains: if we don’t show users the seed phrases, where do we store the keys?

Without Account Abstraction (AA), most existing solutions rely on Multi-Party Computation (MPC) to distribute keys into multiple parts and create a threshold for making transactions. These solutions often claim to be self-custodial. However, this is not entirely accurate. For example, Binance stores one share of the key, acting as a custodian in case users lose their devices. This setup means that, despite the claims, users are not truly in control of their keys, and there is still a reliance on a centralized entity for key recovery.

Furthermore, if any key share gets leaked, there’s no way to revoke the key from the main account. Revocation is impossible because Externally Owned Accounts (EOAs) do not support key rotation, meaning leaked keys will always be a part of the account. This presents a significant security risk, as compromised keys cannot be replaced or removed, leaving the account vulnerable indefinitely.

If you want to learn more about how AA opens the way for programmable accounts and key rotation, you can check my article.

1. Fully programmable accounts: account Abstraction

Account Abstraction allows developers to build different key management systems. An account can be controlled with multiple keys and different authentication methods, all supporting key rotation. Even better, the power of keys can be differentiated. This means users can use different keys for the same account, each tailored for different use cases. I’ll explain these use cases in more detail later.

With AA, funds are stored in smart contracts, and account ownership is defined by these smart contracts. Accounts compatible with EIP-4337 have two parts in their transactions.

1. The first part is verification, where account ownership is verified on-chain.
2. The second part is execution, which executes the message.

The two parts are fully programmable; for example, you can define two keys (i, ii), and the first key (i) can execute immediate transactions, whereas the second key (ii) can only execute transactions after a time lock. This means that we can define the power of the keys, add time lock, or enable other conditions to execute a transaction.

So, when we talk about traditional accounts (EOAs) authentication is equal to authorization. With AA, authorization is programmable, so developers can define a role-based access control scheme and enforce the principle of least privilege.

There are many authentication methods (i.e., key management systems) in the crypto space that can enable role-based access control schemes, and using only one key cannot solve all the problems associated with key management. The most important aspects of key management systems are: where the key is stored and who authenticates it.

Pros and cons of different key management systems

I’ll quickly summarize the Passkeys (Consumer Secure Enclaves), MPC Based Solutions, Cloud-Based TEE solutions, Custodial Solutions, Traditional 12 words and Session Keys. After that, will explain the best combinations.

1. Traditional 12 words - (secp256k1) -

Bitcoin and Ethereum support the secp256k1 ECC (elliptic curve cryptography) algorithm to create private keys and store them on users’ devices. This method is widely used in EOAs and can also be applied to smart accounts. To use it, the wallet application generates a private key using a random key generation algorithm and then stores the private key in shared storage.

Using secp256k1 has several advantages: it incurs no extra gas costs, is inexpensive, and easy to verify onchain via the ecrecover precompile. It is also self-custodial because only the user can access the key.

However, there are some drawbacks:

1. It is challenging to educate users on securely storing their keys in case they lose their devices.
2. A trojan or malware could steal the private key from users’ devices since it is stored in shared storage.

NIST does not support the secp256k1 curve, which means it’s not commonly supported by popular frameworks and most hardware.

2. Passkeys (Consumer Secure Enclaves)

Almost all modern devices have two primary components: an operating system (with associated shared storage) and a Secure Enclave. The operating system handles most operations except for sensitive tasks like protecting biometric data, cryptographic keys, encryption, and device unlocking.

Developers created a dedicated microchip called the Secure Enclave to manage these sensitive operations separately. The Secure Enclave functions similarly to a hardware wallet; it operates independently, securely handling sensitive data, and even the device owner cannot access its contents. Fortunately, the Secure Enclave supports cryptographic operations, such as creating private keys and signing messages with them. Unfortunately, Secure Enclave does not support the curve Ethereum supports (secp256k1), instead it supports p256 curve. To enable native P256 verification, we (@getclave"">@getclave team) proposed the RIP-7212 and almost all big rollups now support it.

And the best part about Secure Enclaves is we can create a private key inside Secure Enclaves with just biometric authentication which enables one click onboarding experience with the best security available on modern devices - hardware level. But it also have some drawbacks:

• P256 Verification without RIP-7212 is expensive and increases the bug risk.
• Since the key can not be extracted, the recoverability is a missing feature here (Passkeys enables limited recoverability but it is not enough)
• If the web domain of the passkey, or Secure Enclave (SE) application stops working, users cannot access the private key because the Secure Enclave is designed to be isolated and independent. Without the associated application or web domain, there is no way to retrieve or interact with the private key, leaving users unable to perform necessary cryptographic operations. - I’ll explain how to solve this problem.

3. SSS-based key management solutions

SSS (Shamir’s Secret Sharing) solutions create a way to eliminate the single point of failure that traditional key management systems have. They essentially split the keys into different parts and establish a threshold to access the key. By distributing these parts, SSS ensures that no single entity holds the entire key, thus enhancing security.

Let’s examine where they store the keys and how they reach the quorum to access the private key. Most existing protocols use three key shares: one share is stored on the user’s device, one is kept on their server (or within an MPC Network), and one is reserved as a backup. Some applications, such as Google Drive, utilize cloud storage solutions to store these key shares.

So, users delegate their wallet control to other parties with a quorum. MPC (Multi-Party Computation) is powerful for delegating key management responsibilities to different parties, but it also has some drawbacks:

Most MPC solutions require a centralized party, and sometimes, what they call decentralized is not truly decentralized. MPC with AA is powerful because key rotation is possible, but many MPC solutions include some functionality for gatekeeping.Also in many cases, previous keys might still be used even after rotating so one needs to trust that keys are actually disposed of Some MPC solutions can censor users, so relying solely on MPC is not always feasible.

Another major drawback of SSS is that it reconstructs the private key, usually in the browser. It is a massive security risk for a plaintext key to be available client-side. TSS never reconstructs the key and uses the MPC to federate the signing across key shares.

4. Cloud-Based TEE solutions

I don’t think Cloud-Based Trusted Execution Environments (TEEs) and SSS-based solutions are that different, but I still wanted to explain how they work. Trusted Execution Environments function exactly as they are coded; they are immutable (at least they claim to be), and TEEs do not show what’s inside even to the TEE owner. They are designed to work with integrity—doing the right thing even if no one is watching. So, keys never exposes to client as soon as TEE’s are doing their work right.

By utilizing TEEs, we can build key management layers where developers can use different authentication methods, and the TEE can verify them. After verification, the TEE signs a message with the private key associated with the user and verifies it on-chain.

The main private key that controls users’ funds is stored inside the TEE and cannot be extracted. This threatens decentralization because if the service decides to shut down or censor users, there is nothing a dApp builder can do.

Cloud-based TEEs look promising in theory, but in the past, we’ve seen vulnerabilities like sgx.fail in cloud TEEs. However, the advantage of TEEs is that even if there is a backdoor or vulnerability, the attacker would need physical access to the TEE, which is why consumer hardware (Secure Enclave - Passkeys) is so powerful because consumer hardware stores the key inside users’ Secure Enclave and only the owner can access the key, whereas Cloud TEE’s store the keys inside a cloud and this makes it vulnerable to attacks.

Not your secure enclave, not your coins.

As I have mentioned, TEEs have some advantages, such as using almost all authentication methods without any cryptographic blockers. However, they also have some drawbacks:

If service providers shut down the server, users’ funds are frozen and no one can access them. The keys are stored inside the Cloud TEE, which means they can censor users. Relying solely on TEEs for key management creates a single point of failure.

Session Keys: A new way for limited permissions

We have talked about permanent keys. What if we can generate a temporal key that has limited access to assets and disappears after a time that user decides? Session Key allows us to do it:

In the web2 world, session keys are like temporary passwords used during a conversation between two devices (like your computer and a server). They’re created at the start of the conversation, used to keep the information shared secure, and then thrown away after the conversation ends. So, even if a hacker somehow finds out this password, they can’t use it to listen in on future conversations because a new, different password (or session key) is created each time.

As in the Web3 world, we define session keys as a framework that can potentially change how users interact with dApps. The goal of session keys is to allow users to set pre-approvals for a specific time in a variety of scenarios and make transactions without signing. But how does it work?

Users create a limited permissions like a session key that can spend assets only as specified by the user, for a limited amount of time, and is revocable at any moment. After that, a backend service allows users to conduct transactions by signing them on their behalf. This setup creates a temporary trust window between the dApp and the users. It is much better than infinite approvals because the approval users give is only for specific assets and for a defined period. Even if the dApp gets hacked, users do not need to worry about a session key created months ago 🙂.

Best authentication & key management combinations for different use cases

I have explained different key management systems and their pros and cons. With the power of AA, we can combine these key management systems and create powerful structures with minimal trade-offs. Lets explain it C.1) Passkey + recovery with timelock - Clave - a fintech application that stores valuable funds.

Secure Enclave (passkeys) based authentication methods provide hardware-level security; however, their recoverability is often insufficient for most users. Fortunately, AA allows developers to combine different signing methods and use them in one account. By adding a recovery signer to a smart account, we can solve the recoverability problem that passkeys have.

There are several recovery options like social recovery, universal recovery (ZK-Email Based Recovery), and MPC-based recovery. However, in my opinion, for a fintech application that is designed to be fully self-custodial, social recovery solves most of the problems. At Clave, we built a social recovery module and are working on Universal Recovery.

This approach maximizes security, which is great for financial applications. But it has an important drawback: the application requires biometric authentication for each transaction the user wants to make. Imagine that you want to share a content in a social-media application and the app pops up a biometric sign screen… Terrible right?

Non-financial applications like social-Fi apps and decentralized games need an easier way to conduct transactions, ideally without requiring users to sign each transaction. How? Here is the answer:

1. Passkey + recovery with timelock + session keys — mobile social app

Session keys enable users to make transactions without a sign screen. NFT-based games or social apps can inherit session keys to have temporary and limited access to users’ assets. If you think this adds an extra trust assumption, let’s explain how today’s front ends work:

Today, most users do not even check what they’re signing when playing a game or interacting with a dApp. This is dangerous because a malicious front-end can cause users to lose all their assets.

Session keys are a better alternative to this. Users can check how long the session will be active and which assets the session can access, reducing the need to trust the dApp. After the session time expires, users do not need to worry about approvals = No more need to revoke.cash like applications :)

2. MPC or cloud TEE based signer + self-custodial signer for escape

The drawback of MPC or Cloud TEE-based third-party key management layers is that most are not self-custodial and have significant centralized components. However, some dApps require embedded wallets without extra gas overhead, necessitating MPC or Cloud TEE-based solutions. Adding an extra signer for “rage quit” can solve the censorship problem these key management systems have and also mitigate potential legal issues these dApps may face. You need a smart wallet to build this because key rotation is not possible with EOAs.

There are already several applications that use this key management architecture.

3. 12 words + Hardware Signer for maximizing security — DeFi browser extension experience

DeFi users love the browser extension experience, and changing user behavior is one of the hardest things in the modern world. So, why not build a better alternative? Combining a hardware signer (Secure Enclave or Passkey Signer) with 12-word seed phrases accessible via an extension could also solve the problem of leaked private keys. This approach improves the security while no need to change users’ behaviors. Several teams in the AA industry are working to enable this. (e.g. @myBraavos)

Smart accounts are not smart enough

Imagine that you’re a user who first generated an EOA with @MetaMask and then discovered an alternative like Zerion. You decide to use @zerion, and all you need to do is import your seed phrase—simple. Now, imagine trying to do the same on Starknet, where all wallets are smart accounts. You can’t, because Braavos and Argent are not compatible. This issue also exists in the EIP-4337 ecosystem and @zkSync’s native AA.

We need standards (not gatekeepers) or at least a better way to fund new wallets. Otherwise, there will never be widespread adoption of smart wallets, and existing players will remain the decision-makers, dictating industry practices even if they are not right.

Additionally, “rage quit” should be a default feature, as central actors in almost all key management systems can be shut down. It should be easier for users to change signers or switch smart contracts, and self-hosting should be the default option for users. There are two modular smart account standards: ERC-6900 and ERC-7579. They are both trying to achieve a similar goal - to make smart accounts smarter.

Special thanks to Derek , Konrad, and Noam for feedback and comments!

Disclaimer:

1. This article is reprinted from [X]. All copyrights belong to the original author [2077Research]. If there are objections to this reprint, please contact the Gate Learn team, and they will handle it promptly.
2. Liability Disclaimer: The views and opinions expressed in this article are solely those of the author and do not constitute investment advice.
3. The Gate Learn team translated the article into other languages. Copying, distributing, or plagiarizing the translated articles is prohibited unless mentioned.