Quick tour on Ethereum private keys attacks
Disclaimer: this paper is just an introduction to possible attacks against cryptography algorithms used in blockchains. Its only purpose is to arouse your curiosity, and should absolutely not be taken as a cryptography course. Even if some researches have been done, there could remain some incorrect statements. Every paper used to write this article is mentioned, so please read them if you want to deepen your knowledge in this field.
Introduction
Your entire Ethereum (and almost every other blockchains) wallet is accessible by your private key, which is basically a random 256 bits long number. In fact, you could enter any 32 hex characters long key, and import an account to your Metamask for example. If you want to try this out, there are two ways: some websites like https://keys.lol/ allow you to see random private keys, and even compute their balance. However, I’d be tempted to think that if you use such websites to compute a private key, you’ll probably won’t be able to withdraw from one whose balance is not zero, as there’s a high chance the website installed a bot that filters the latter and instantly transfers the funds to another address, such as the website owner’s.
The second way you can try is by opening your Python (3.6+) shell and just type:
import secrets
print(secrets.token_hex(32))Then enter the obtained private key to Metamask. Unless you are extremely lucky, you will see a 0 ETH balance. As well as you may find Vitalik’s private key. Concretely, what are the odds to get a non zero balance? According to Etherscan, there are currently less than 200M active addresses. Active means that is has been used to sign a transaction on the blockchain, not that it has a positive balance. Since there are 2²⁵⁶ possible private keys, which is a little more than 10⁷⁷, and if we optimistically consider 10⁹ positive addresses (which is still far from reality…), you would have less than one chance out of 10⁶⁸ to find one. If you still wonder if it is possible to bruteforce the private key of an address, it is impossible today. However, if we follow Moore’s law, it could happen in the next decades, but algorithms will certainly evolve to prevent these types of cracking.
However, some weaknesses regarding the signing algorithm behind Ethereum and Bitcoin have already been exploited. First, we have to understand what is the link between your private key and your transactions on Blockchain.
Transaction signing on Ethereum
The global principle is pretty clear. On Ethereum (or Bitcoin) When you have a wallet, you have a private key, a public key, and an address. Let’s forget about the address in this example, since the address is composed of a part of the hashed public key. When you sign a message, or a transaction, everyone will be able to check if it is your private key that signed this, thanks to your public key. It is made possible by Cryptography algorithms. For Bitcoin, Ethereum, and many other blockchains, this algorithm is the Elliptic Curve Digital Signature Algorithm (ECDSA), as you can note here:
In fact, ECDSA is popular because Bitcoin used it first, so other blockchains followed, even if Bitcoin recently (November 2021) changed ECDSA for Schnorr in Taproot Update .
If you want to learn more about ECDSA algorithm, and how it is used in Ethereum, I recommend you to read this Wikipedia page, and this Medium article.
If we agree on the fact that ECDSA cannot be bruteforced, there still remains some weaknesses in this cryptography.
Potential Attacks against Ethereum private keys
First, if naively guessing a private key of a public address is impossible, some hackers have apparently been clever. For instance, in 2019, an hacker stole around 45.000 ETH, by trying extremely simple private keys. His process is detailed here, but in short, the hacker tried private keys as simple as ‘1’, then went on with other simple keys.
However, there are weaknesses due to the ECDSA signing algorithm itself, which may be exploited. Its main frailness is located in step 3 here.
The number k, often called the nonce, could have serious consequences if it is found or if it is not truly random.
First, let’s suppose that two ECDSA signatures, from the same private key, used the same nonce. We would be first able to identify the nonce part of the signature. Then, thanks to a not so complex calculus, we would be able to recover the private key of the signer, without knowing the nonce.
To have more technical details, and a quick Python implementation, I invite you to take a look at this Medium article.
The fact is that the nonce is chosen by your signing software, namely your wallet. These types of security flaws seem to have been patched, a study in 2018: Biased Nonce Sense: Lattice Attacks against Weak ECDSA Signatures in Cryptocurrencies successfully recovered private keys that gave the researchers the access to few bucks in BTC, ETH and XRP.
The second potential hack is when k is partially known. Since the nonce is generated locally by your wallet software, it is up to the wallet to correctly generate it. For instance, a breach has been found in 2013, affecting Android Bitcoin Wallet, due to a Java method that presented flaws in random number generation. However, don’t worry as a Ethereum user: Vitalik Buterin himself covered this breach in a paper, published in Bitcoin Magazine.
Without going into detail, some papers showed that, with a sufficient number of ECDSA signatures by the same private key, we would be able to recover a private key with only knowing few bits of the nonce. For instance, an attack called the Lattice Attack can find a private key just by knowing 4 bits of the nonces used in 87 (or more) signatures. This attack is easily demonstrated by Antoine Duffont in this Python code.
One may wonder if it could be profitable to brute force a private key that signed many messages by naively trying to guess some bits of the nonce used for each signature. The response seems to be no, since if we wanted to brute force a private key that signed 87 signatures, we would have to try (2⁴)⁸⁷ = 2³⁴⁸ possibilities to try to guess 4 bits of the nonce, which is far greater than 2²⁵⁶.
Nevertheless, there are physical hacks against hardware, called Side Channel Attacks that make it possible to obtain few bits of the nonce when signing. These attacks are only against hardware encryption, on a chip for example. The principle is to measure physical magnitudes around your hardware when signing, such as the power consumption, the magnetic field, the current, in order to obtain information about data transmitted.
The data collected is called the trace, from which we will try to extract useful information. There has even been Deep Learning methods developed to enhance Side Channels Attack, as described in this article from elie.net.
You may be wondering how could it affect your Ethereum hardware wallet. Remember: when you’re signing something with your Ethereum key using ECDSA, the weakness is the nonce. In a very imaginary scenario, if someone were to be able to Side Channel Attack your wallet, and to guess few bits of the nonce for each transaction, he could recover your private key. Therefore, the question that comes to mind is wether your Ledger safe. No worries, it seems your hard wallet is safe from these attacks according to the Ledger website.
Conclusion
We are still far from having enough computing power to brute force a private key, and even though we could manage to get there pretty fast thanks to Moore’s law or maybe even faster with quantum computing, the danger is probably not here. As Bitcoin recently did by switching from ECDSA to Shnorr, blockchains can upgrade their cryptography algorithms to enforce security. Nevertheless, there are still possible attacks, that do not depend on the ECDSA’s robustness, but rather on how the algorithm is implemented. By leaking as little information as only one nonce bit, some hackers could start obtaining information about your private key. Nevertheless, software wallet such as Metamask rely on strong cryptography librairies, and Ledger claims to be bullet proof against Side Channel Attacks, so it seems that most of us are safe for the moment! 🥳
References used to write this article:
