The web3 ecosystem has grown exponentially, with new use cases, products, and features popping up every day. Unfortunately, one of the main pain points that still exists today is managing seeds and private keys.
Seed phrases are the current industry standard, however they have their own set of weaknesses. For example, we find that people will take screenshots of their seed phrase which, for obvious reasons, is extremely insecure. On the opposite side of the spectrum, we also find cases where users will write down their seed phrase on a piece of paper and misplace it. There are countless stories of people leaking or losing their seed phrases, and thus, losing their funds.
In the last couple of years, the advent of embedded wallets has introduced novel ways of users accessing, backing up and recovering their seeds. These new key management tools focus on providing smoother UX using more familiar Web2 flows. While these circumvent the responsibility of managing a seed phrase and feels “smoother” to users, there tend to be drawbacks with regards to how they manage to do so. For example, we’ve seen designs that attempt to split a secret into independent shares. While in theory this ensures self-custodianship, if a single party (i.e. the service provider’s backend) holds a threshold of these shares, in reality the protocol is entirely custodial and the party with the threshold of shares can trivially reconstruct the seed and drain the wallet. Another pattern we’ve seen is companies using hardware security modules (HSMs), where a user’s private key is stored on the HSM (or some derivative of this concept). The claim is that these HSMs will only sign transactions according to some policy agent that ensures it is indeed the user asking for a signature. While this seems sound in theory, the reality is that if the policy enforcement happens outside of the HSM, it could easily be manipulated to have the HSM sign even in malicious cases.
Using Google or Apple to login to Phantom provides the ideal balance between usability and true self-custody. Users simply need to sign in with their Google or Apple account and set a 4-digit PIN to access their Phantom wallet. Under the hood, our distributed key management protocol ensures that even if Phantom (or any part of the protocol) gets hacked or goes malicious, your seed phrase can never be exfiltrated and your wallet cannot get drained.
Phantom's solution
The ability to login to Phantom with Google or Apple is built upon a secure, self-custodial, distributed key management protocol. This protocol ensures users no longer need to remember (or safely store) a complex sixteen word seed phrase, instead opting for a simple 4-digit PIN that is easily memorable.
The protocol has two factors of authentication: An email and a 4-digit PIN. This ensures that even if a user gets their email hacked, their funds are still safe behind their PIN (and vice-versa).
The protocol is self-custodial by design. The only point where a seed exists in full is on the user’s device after they have successfully authenticated with their email and PIN. When a seed is backed up, the seed itself exists on Phantom’s backend in ciphertext (encrypted) form, while the encryption key is split into shares across the Juicebox network. No single party, outside of the user, is ever able to reconstruct the seed in plaintext.
Technical overview
In this section we’ll actually explain what happens when you create a new Phantom wallet with a Google or Apple and how backup and recovery actually work under the hood.
Backing up a wallet
When onboarding, users are now presented with two new options:
- The ability to create a wallet with Google or Apple
- The ability to recover a previously created wallet
A couple things to consider: Existing users with seed phrases or private keys have no overlap with wallets created with Google or Apple accounts. Everything is entirely separate and parallel to already existing wallets. In the future, we may allow already existing users to create new wallets with Google or Apple accounts, but that is not supported at this time.
Let’s walk through what happens when a user creates a wallet with Google or Apple.
On the user’s device, a new seed is generated that is used as entropy for the user’s wallets.
Phantom then generates a symmetric key, the seed is encrypted using the key resulting in a seed ciphertext. All of this happens on the device with neither the seed nor symmetric key being sent off device.
The seed ciphertext is then sent to Phantom’s backend for secure storage. The ciphertext is non-sensitive, especially in terms of custody. Even with this ciphertext, Phantom (nor any malicious actor) can’t sign on behalf of users, without also having access to the symmetric key.
Next, back on the user’s device, the symmetric key is split into two shares (in a 2-of-2 Shamir Sharing threshold). Phantom holds onto one of these shares (called the Backend key share) while the other share will be stored in the distributed storage protocol Juicebox.
Note, even in this state, Phantom is unable to sign even with access to the ciphertext and a single share given the 2-of-2 threshold to reconstruct the symmetric key.
The final step for backing up is to write the Juicebox share to the Juicebox network. The user selects a PIN and uses it to register the Juicebox key share. Registration involves splitting the Juicebox key share and distributing the “sub”-shares to each Juicebox node, where access to each sub-share is gated by PIN entry. See more information on the Juicebox protocol here.
The above diagram shows a 2-of-2 example, however Juicebox is configurable. i.e. We plan on launching with a 2-of-2 Juicebox configuration, but will be moving towards a 2-of-3, with the option of increasing the network size further down the line.
At time of launch, the Juicebox network will consist of one realm ran by a third party node provider and the second node ran by Phantom.
Recovering a wallet
When a user goes to recover their wallet created with Google or Apple, the process is analogous to backing up but in the reverse direction. Essentially, the user’s device will authenticate to Phantom’s backend and acquire the seed ciphertext and the backend key share. The user’s device then recovers the Juicebox key share by entering the PIN. Finally, the two key shares are used to reconstruct the original encryption key which is then used to decrypt the seed ciphertext to obtain the original seed entropy. The original seed entropy is then stored and used as normal within the user’s Phantom app.
Putting it all together
This results in the following end state:
- The user holds access to their email and remembers their PIN
- Their Phantom app on their device has the entire seed in a usable, exportable state
- Phantom’s backend has:
- The seed ciphertext
- One share of the symmetric key
- Each Juicebox realm has a sub-share of the second share of the symmetric key
- Such that if a threshold of realms are asked to recover, they can reconstruct the second share of the symmetric key
Which gives the following properties:
- If Phantom’s database gets hacked, the attacker can’t do anything with the data stored
- If a number of Juicebox realms lower than the threshold are malicious, the seed is still safe given they cannot reconstruct the Juicebox share
- Even if the entire Juicebox protocol is malicious, the key is still safe as the Juicebox network has no access to the other share of the symmetric key (nor the seed ciphertext)
- If a user’s email is hacked, the seed is still safe because the only way to access Juicebox’s key share is to provide the PIN.
Security
At Phantom, our goal is to provide the best user experience possible without taking any compromises on security. Given the sensitive nature of wallet recovery, we carefully architected the protocol to provide the best balance of usability and security.
Our goals with the security of this feature are as follows:
- No 3rd party (including Phantom) that is involved in wallet recovery should be able to reconstruct nor use the user’s private key.
- The only way a user can reconstruct their private key is if they can successfully authenticate access to their email while also proving knowledge of a 4-digit PIN.
For point 1, we note that to reconstruct the private key, one must have access to the seed ciphertext and both encryption key shares.
- If a number of Juicebox realms lower than the threshold is malicious, they will be unable to reconstruct the Juicebox key share.
- If the entire Juicebox protocol itself is broken, the attacker would still need to break Phantom’s backend infrastructure to gain access to the Phantom backend key share.
- If Phantom’s backend were to be attacked, attackers would still not have access to the Juicebox share
For point 2, Phantom’s backend uses the battle tested OAuth2 specification to authenticate and authorize users using their Google or Apple accounts. Juicebox uses a distributed oblivious pseudorandom function (OPRF) protocol to ensure a user’s PIN before a user can access the Juicebox share in plaintext.
Under the hood, Phantom uses the ChaCha20-Poly1305 authenticated encryption algorithm for encrypting and decrypting the seed entropies. We also use an audited Shamir Secret Sharing library for splitting and reconstructing the encryption key. Lastly, on our backend, all shares are KMS encrypted using a KEK-DEK pattern per share with AES-GCM.
Reliability
A key point to understand with our decentralized seed management protocol is that a user must have access to their email and knowledge of their PIN to recover. Unlike traditional web2 protocols, Phantom support cannot help you recover your PIN nor your private key. This is a key feature; if Phantom could discover either of these, the essential property of self-custody would be broken.
For a truly zero trust solution, some amount of responsibility must fall on the user.
On the other hand, because private keys are also stored on the user’s device, if a user forgets their PIN, as long as one of their devices has the Phantom app installed with their wallet, they can easily reset the PIN.
Additionally, the app periodically asks users to verify their PIN to help users not forget it. When verifying, if a user does indeed realize they forgot their PIN, they can easily reset the PIN and create a new backup.
At the end of the day, this means that as long as the user either has access to their device or their email and PIN, they can access their wallet.
Given that recovering an account is as easy as logging into an email and entering a four digit PIN, we encourage users after onboarding to recover onto another device. This provides three points of access, one on each device as well as the wallet backup.
Wrapping up
Seed phrases are too clunky and unintuitive for the next wave of users that will push crypto into mass adoption. There is too much friction having to type in a seed phrase on a new device or an app, and too much confusion on how to properly store a seed phrase securely.
Having decentralized seed management protocol that uses intuitive, familiar web2 flows that are truly self-custodial and secure provides the right balance for the next generation of Web3 users.