In this post, we'll explain how the Ambire Wallet security model works and how we achieve a web2-style login with an email/passphrase while still providing self-custody.
Normally, you'd keep your funds on a normal cryptographic keypair, which consists of two parts: private key and public key. The public key, in a hashed form, is your address, and the private key is the part that allows you to access your funds that you need to keep secure.
For the purposes of this article, we'll call this a "key" or a "keypair", but you'll also see it called an "EOA", or an externally owned address (an address that is not a smart contract).
The Ambire Wallet is a smart wallet, which means that you, as a user, will be represented by a small smart contract on-chain.
In technical terms, this contract is a standard (EIP 1167) non-upgradable proxy that points to another contract (Identity.sol) which implements transaction batching, meta transactions and other conveniences.
This setup enables two important features:
- Transaction batching: being able to do multiple actions in one Ethereum transaction, which abstracts away ERC20 approvals, among other things, and makes depositing into DeFi protocols like Yearn a single-click breeze
- Authorities management: you can add/remove different "authorities" or keys which can control this account, which means that you can start with software-level authentication (eg email/passphrase login) and upgrade to a hardware wallet later on without having to move funds; adding multiple authorities will protect you from events like losing one of your private keys
Now you know how smart wallets work and the value they provide. But did you also know that they can be further secured through multisigs and timelocks?
This is how the email/passphrase login feature works: when you sign up, two keys get generated: one gets generated on the client side, using your email/passphrase and an extra seed as entropy, and another key is generated on the Ambire backend.
If you want, you can request to download/backup the second key.
For a transaction to be sent immediately, both keys need to sign it. The Ambire backend will automatically co-sign the transactions with you, but before doing this it can also perform further security checks: for example, check if the transaction is to a known contract/address, check if it's over a configurable daily limit, or even enforce 2FA through OTP or email.
If a transaction is only signed by key only, a 3 day timelock gets triggered. When it elapses, the given transaction can be executed. But in the meantime, any one of the two keys can cancel it. This has two use cases:
- Allowing account recovery in case you forget the passphrase
- Allowing account recovery in case the Ambire backend goes down
In this model, only the user can access the funds immediately by having both keys, but in case one of the keys gets compromised, we allow enough time for fradulent transactions to be detected and cancelled.
Your security model is entirely configurable with the Ambire Wallet, to best suit your skill level and profile. For example, some people are more confident and will want to use a hardware wallet for everything, while others might prefer to also have a recovery option.
Here's some examples of what you can do, and of course, keep in mind you can change it on the fly:
- Use email/passphrase login together with a harwdare wallet: both can access your funds but the former can be limited to a certain daily spending limit
- Use MetaMask together with a hardware wallet: both can access your funds but MetaMask can only do so in the business hours
- Only use a hardware wallet
- Connect two hardware wallets, one of them can access funds immediately, the other is timelocked - if you want, for example, to let someone close to you recover your funds (social recovery)
- Use a hardware wallet together with a Gnosis Safe instance: good for social recovery or for corporate use cases
Obviously, the possibilities are endless and this can be tailored perfectly to the security preferences of every individual and corporation.
In the normal scenario, the user signs transactions with their own key, and Ambire confirms by signing them with the second key. Ambire will additionally verify 2Fa if enabled, and will require email confirmation in certain scenarios.
We recommend that users backup the second key (normally held by Ambire), to ensure full custody all the time. In this case, the user will keep the backup in cold storage, to reduce the likelihood of it being compromised.
Here's an example of how this system works around some common adverse scenarios:
- User key gets lost (forgotten passphrase or browser storage cleared): Ambire can use its key to trigger a timelocked account recovery request
- User key gets compromised: the attacker will only be able to send timelocked transactions, and in the meantime the user can change their key; 2/2 transaction can be sent cause the user already has their key, and Ambire will co-sign as long as there's email confirmation and/or 2FA
- Ambire is down/Ambire key gets lost: the user can send transactions but has to wait for the timelock period, unless they have the backup, in which case they can send a 2/2 transaction
- Ambire key gets compromised: the user can access their wallet through the backup (by sending a 2/2 transaction)
- One of the keys gets lost AND compromised: the user can access their wallet through the backup (by sending a 2/2 transaction)