Crypto for crypto: how safe is you data?
As a Web3 user, you are certainly using a wallet to manage your assets. Even if you are not that familiar with the ecosystem, you may have already heard about some of them, such as MetaMask, Coinbase Wallet, Trust Wallet, or cede.store.
The purpose of wallets is to offer an interface to track and manage transactions, but also serve the important goal of storing the keys, at the core of the whole Web3 technology. This data is of utmost secrecy because anyone that has access to your keys can withdraw your assets, make transactions, or even worse, steal your identity on all the networks/dApps connected to your account.
All wallets, therefore, have a very strong incentive to ensure that your data is safe and that no breach exists that would allow an attacker to get ownership of your keys. We will take a look at one of a recent case of such an attack, using the example of the Atomic Wallet hack, which has resulted in around 100M$ of losses for its users. As a user, it is reassuring to know how secure are the tools that you use, and maybe avoid some of them, but it is also very important for developers to know the state-of-the-art practices in order to deliver the safest product possible.
As it is one of the oldest and most popular wallets, let’s start our journey with MetaMask.
Metamask
MetaMask is mostly known for its eponymous browser extension, launched in 2016. It is an open-source project, which has made it the foundation for the codebase of many other extensions.
Open-source
This is one of the most important factors of trust in the safety of MetaMask: because it is open-source, everyone can see the source code, and contribute to it. Because many talented developers have tried their hands on and independently audited it, you can be pretty sure that the most obvious weaknesses have been fixed a long time ago. This does not mean that it is unbreakable, of course, but this is a good indication that it is constantly pushed towards the best of what is achievable in terms of security.
Keyring
The keyring is at the base of every sensitive data stored in MetaMask. The visual analogy is self-evident: a seed phrase is used to generate different keys that can be used on the Ethereum network. The keyring is literally the set of the ring (seed phrase), and the keys (accounts on the network), held together by the former. Because this generation process is deterministic, it is possible to retrieve your account from that seed phrase alone.
This means that we reduce the amount of sensitive data down to the seed phrase, and some personal data associated with your accounts, which is always better. The private key is never stored anywhere, and that’s one less point of failure to consider. MetaMask can therefore regenerate the sensitive data when the content is loaded, and cherry-pick the information that is needed (there’s no need to store all the keys if we can retrieve the one that we want to use for a specific purpose).
There is a special class in the code, called the KeyringController, that has the responsibility to store/load & encrypt/decrypt the data. The first thing to notice is that everything that is stored on the disk is encrypted (using some variant of AES, a cryptographically unbreakable cipher method). The data is only decrypted at runtime when the password is given by the user. Every sensitive information is therefore only present in the memory, which can only be accessed by the MetaMask process. If a change is requested and needs to be stored, the password will be used to encrypt everything that needs to be, and then the data will be put in the browser's local storage.
LavaMoat
This is another big part of the security ensured by Metamask, that solves a point of failure that 99% of the web-related projects are subjected to. Because nobody wants to reinvent the wheel every time they start a new project, developers (especially in the JS/TS ecosystem) will use external libraries. This is a huge issue because nobody really audits everything that is inside those packages, so, malicious code can get into them and may compromise the privacy of the data. Think about a simple module, that would run some code in the background to access your data and send it to an attacker. It is even worse when you can update packages because it can be perfectly safe at some point, and the next version can be unsafe. Nobody has the time and resources to audit all the packages, on every version used throughout a project (plus, some packages also have dependencies, that have dependencies, and so on…), so Metamask developers have found a solution to this issue.
To prevent these kinds of attacks (called supplychain attacks), LavaMoat will ensure that the native data structures are immutable. Because of… the way JS is, one can replace the prototype of every object at runtime, and change its behavior. Imagine having an array of accounts somewhere in the memory, but you would only want the user to see his own. Using Array.filter is unsafe in this context because one can replace the prototype method filter with a function that would return everything in the array. By disallowing such a “feature”, we ensure that our structures will behave the way they should. LavaMoat goes even further than that, a can attribute a limited scope to parts of the code. For instance, it can restrict access to the API (i.e. window, document, and so on) for the modules that only use it. Also, it disables install scripts, that are run when a package is installed. This was the door to many attacks, as they allowed the blind execution of pretty much anything on your machine.
This makes Metamask very robust, as its codebase is basically a fortress with very few gates, and a strict policy for entrance.
Taho
Taho is an extension that positions itself as a direct concurrent to Metamask. As they state:
Today’s Web3 landscape is dominated by a single wallet and a single infrastructure provider, both owned by a single conglomerate. These facts undermine the censorship resistance of Ethereum today… and they’re also against Web3’s spirit of community ownership. We can do better.
But in terms of security, do they really do better?
Architecture and encryption
Very similar to Metamask’s architecture, Taho will offer us a way to also discuss good practices when developing a Web3 project.
Their internal wallet API communicates with a limited amount of services: an external API (responsible for dealing with on-chain actions), an internal storage manager (for common data), and an “Indexed DB” (for critical data). This is very important because once the data has been properly routed, the developers can then focus on a single entry point and protect it to the maximum. As an example, we can check their encryption module, which is contained in a single file and can easily be maintained and improved.
It is also a good way to explain the common encryption mechanism. In a nutshell, the password is not used alone in the process; it is accompanied by a salt. This is a randomly generated set of bytes, that ensures that the combination password + salt is unique, even for two users having the same password. This makes it impossible for attackers to guess the password, even if they just successfully managed to decrypt someone’s data using the exact same one. In practice, the two are “hashed” together, to form the real key, that will be used in the encryption/decryption algorithm. For Taho, it is AES-GSM (Advanced Encryption Standard with Galois Counter Mode), which requires a whole lot of complicated math, but has been rigorously proven to be cryptographically secure, and used in protocols such as SSH, TLS, or the NSA standards. Because the key is symmetric, the same password can be used to decrypt the data, of course.
What about supplychain attacks?
As of 2023, Taho does not use LavaMoat (because it is supported by Metamask, and the team does not want to build upon the same tools as everyone else) and does not use a similar library. They seem to be limiting their module usage to the minimum, but I have not been able to confirm if it’s written somewhere in their policy, or if they plan to do something about it. The absence of proof is not proof of absence, but in the domain of security, it is. Therefore, Taho may well be vulnerable to supply attacks.
The others
You may have noticed that the previous paragraph on Taho was much shorter than the one on Metamask. That is because of the monopoly that Metamask has over the wallet ecosystem. Basically, every new project will be inspired by Metamask, either consciously because the code is open-source and available, but also because it is the golden standard as of now. Metamask has, so far, been extremely secure, so it’s easier to rely on the number one to claim such levels of security.
To name a few, Rabby, Argent-X, or even OneKey implement the same architecture, use the same encryption protocols, and there is no killer feature that would be a step forward in the wallet ecosystem in terms of security. We must also include cede.store, with the addition that its API service is not directed towards the blockchain, but to centralized exchanges.
There may be some novelty coming from closed-source wallets (Phantom for instance), but it is hard to tell as their codebase is not disclosed, and we cannot really see any sign that it provides additional features to protect our data.
A case study of an attack: Atomic Wallet
Atomic Wallet is a non-custodial wallet, so the keys are stored locally, and the wallet serves as an interface to use and store them. Although relatively small in the ecosystem, it has seen a rise in interest in early June 2023, after an attack supposedly performed by the North-Korean infamous hacker group Lazarus. It has resulted in a loss of 100M$, but the exact source of the attack has not been disclosed yet.
This wallet presented already some red flags, as opposed to the good practices we described in this article:
- Firstly, it was not open-source. For a wallet of this size, it is uncommon to stay closed-source, and that means that as a user, we have to trust audits made by private companies, which can be biased or hard to believe. Such an audit was made by LeastAuthority in 2022, which stated that some vulnerabilities were existing, but the team behind Atomic did not act fast enough to solve these issues before the breach.
- Secondly, it did not take care of its dependencies. It is believed (backed by Elliptic, an independent crypto-auditing firm) that the hack could have come from malware introduced in a security release (how ironic), coming from outdated dependencies and unchecked code.
This highlights the importance of the key elements of security that we identified. Developers should be incentivized to focus on applying those standards as soon as their project is released to the public, and never let their guard down when a new breach is found, because it does not always apply to others only.
Atomic is unfortunately not the only wallet to fall victim to such a hack, as the Solana Slope Wallet caused a loss of 4.5M$ in 2022 when a hacker gained control of its remote services, or Parity Multisig, that had missed a security issue allowing anyone to gained control of any wallet after its initialization. It is estimated to have cost 30M$ in 2017, and a distrust among developers for the design pattern that allowed this exploit, the Proxy Library Pattern, as it is not used much anymore in major open-source projects.
Conclusion
In the end, wallets are ensuring the safety of the data through a robust architecture, and solid cryptographic algorithms, shared by almost every actor in the ecosystem. They are all more or less equal in terms of security, and that level is very high compared to the rest of traditional browser extensions. It is unlikely to see a major breach of data in the near future, judging by the audits and available sources.
Metamask is above the melee nonetheless, as it is the reference. It not only ensures safety against attacks from hackers but also against rival developers, with LavaMoat.
Interested in developing with cede.store? Check out our docs here!
