There are two main takeaways from all of these vulnerabilities discussed above – peer review and node security. You cannot underestimate the importance of using the reference implementation (Bitcoin Core), and you ultimately need to trust the computer that your full node is on. Hardware wallets will never, by design, fulfill these requirements. It is inherent in their architecture.
Most, if not all, of the remote vulnerabilities discussed were strictly due to poor code review. These simple yet devastating types of vulnerabilities (remote private key extraction, attacker controlled addresses, ransom attacks, etc), never have occurred in Bitcoin Core, and for as long as it remains the reference implementation, likely never will. Bitcoin Core has a decentralized development process that is very conservative, prioritizes security, is supported by hundreds of developers, and has wide community and business review all over the world, with no single point of failure. On the other hand, these hardware wallet projects have a handful of developers at most, with one single project lead who can merge commits with essentially no community review. These projects can push poorly written code, or even malicious code, without it going noticed for months or even years at a time. With Bitcoin Core, there is no individual developer a government or attacker can target.
What you have to understand about HWWs is that even when used with Core through something like HWI (Hardware Wallet Interface [56]), hardware wallets remove private key generation and transaction signing from all the peer review that Core gets. And as going through all the examples previously shows, this is very dangerous.
Even the physical attacks discussed are made more difficult when used with Core, as Core has written libsecp256k1 [57], an optimized cryptographic library that is constant-time and constant-memory (therefore making side channel attacks much more expensive and complex), and is so well audited that the Core developers have actually discovered bugs in other libraries used by thousands of projects, like OpenSSL [58] and the GCC compiler [59]. Also, because Core is a software application that can run on any generic hardware, you don’t need to give away any personally identifiable information to set up a secure wallet. For example, you can walk into a store, buy a laptop with cash, and download Core over Tor. Unlike hardware wallets, which are bitcoin specific and purchased online, the risk of supply chain attacks with generic hardware are much less significant.
The single selling point of hardware wallets – that they enable you to securely sign transactions from a malicious computer – is a lie. Anyone who knows anything about Bitcoin or cybersecurity in general can tell you this. This is because Bitcoin’s security model fails without a full node, and you cannot trust a software application (the node) if you cannot trust the computing levels beneath it – that is, the operating system (OS), kernel, bootloader, BIOS, CPU, and hardware. Just like Bitcoin, these need to be open source, well audited, and built with a security first mindset. If one level is vulnerable or malicious, it corrupts all levels above it.
The vulnerability that best demonstrates why a secure full node/computer is needed, is the segwit vulnerability that was disclosed by Saleem in March of 2020 [60]. Think of this type of attack as a MITM attack, with the software wallet/computer acting as a malicious proxy between the hardware wallet and the bitcoin network. In this hypothetical, a user has two UTXOs of 15btc and 20btc. The user wants to create a transaction spending 20btc. Since the (malicious) software wallet/computer creates the transaction and broadcasts it to the network, while the hardware wallet merely confirms/signs it, this attack is easy to carry out. The malware on the computer will create a transaction consuming the 15btc UTXO completely, and fake 5btc from the 20btc. This will look like a 20btc spend from the user’s point of view. After the HWW signs the transaction, the computer will then return an error like “Woops, Broadcast Error, Please Try Again”. (This does sometimes happen for various reasons – so it wouldn’t be too suspicious). Now, when asking the user to sign again, the malware will this time have the user sign the 20btc UTXO. It will look like, from the user’s POV, the same transaction (since it is the same amount). The malware now combines the signed 15btc from the first transaction and the signed 20btc from the second transaction, and sends the entire 35btc from the user’s account. The 20btc will go to the user’s intended recipient, and the 15btc can be ransomed from the user, or profit shared with a miner. The fix for this was very controversial, as some wallets did not have the data necessary to stop this one specific vulnerability, which locked up users’ funds, and led to incompatibilities across wallets.
However, one needs to think broader. This is actually an issue with using a full node on an insecure machine. There ultimately is no fix for this. (Except not using a hardware wallet, and using a full node in a sane manner). Here is an example of another attack that demonstrates this: A simple, what I call ‘twice-spend’ attack (since double-spends mean something entirely else in Bitcoin) [61]. If an attacker controlling your node sends you a transaction to sign, and you sign and broadcast it, they can simply tell you it has failed, and even show that to you in your UI. They can then send you another (different) transaction for the same amount for you to sign, essentially stealing bitcoin from you. This is a very simplified version of Saleem’s attack, yet with absolutely no fix for people who can’t trust their computer (which, remember, is the only selling point of HWWs). If you can’t trust your computer, you ultimately cannot know when a broadcast fails, when a transaction sends, or if bitcoin you have received are real or not.
Ultimately, supporters and makers of hardware wallets do admit to this point when pressed on the matter. NVK from Coldcard stated, "We can't prevent you from signing something that you want to sign...if you are of that level of concern, you can have a separate laptop that isn't connected to the internet..you can have Core...you could have a segregated laptop, which you should by the way." [62].
You should be suspicious of companies that continue to lie to their consumers – refuse to accept vulnerabilities, reward researchers, or be honest with the public. Besides the numerous hacks that have occurred, another area in which false security occurs is with HWWs' ‘airgaps’. Trezor and Ledger use a USB cable, the BitBox plugs directly into your computer using the USB connector, and the Coldcard uses an SD card. These are not airgaps, but rather direct lines for transferring unlimited, unverifiable data. This is incredibly dangerous, especially when the HWW advertises as being able to connect to a malicious machine. Both USBs and SD cards contain proprietary firmware, many attack vectors, and complicated protocols [63], [64]. The device has to parse the provided information by loading drivers, parsing partition tables, and mounting/parsing filesystems – all of which is performing a ton of untrusted input processing. There are two requirements to an airgap – you need the information to be verifiable, and you need the method of transfer to be as constrained as possible in regards to bandwidth. You want as little data as possible to be able to transfer between the computers, because you want an attacker to have an incredibly difficult time getting effective malware across the gap. With bitcoin and QR codes, we only need to, and only are able to, transfer a few hundred bytes at a time. This means that an attacker can only squeeze in a couple bytes of malicious code on top of the data being transferred. In addition to this, QR codes are open source, and their contents are verifiable by the end user (they can be scanned on another device first, before scanning on the airgapped machine, while confirming visually that they have not changed). With USB and SD cards, gigabytes of data can be transferred. To keep this in perspective, malicious code is usually measured in kilobytes. (1 GB = 1,000,000 kb = 1,000,000,000 bytes). So for hardware wallets, attackers have plenty of space, and there is absolutely no way for an end user to verify the transfer of data, as there is all sorts of ways for malicious data to hide. With QR codes, there is just a few bytes of space.
Note: For Yeti, we have had to change from QR codes to CD-r (read only CD’s). These are just a dumb/blank medium with no filesystem or firmware. Because Bitcoin Core does not support reading QR codes yet [65], it would require us writing much of the code, which would introduce an attack vector for our users. Our analysis was that CD’s, while larger in size than QR codes and not verifiable, are still far superior to USB/SD cards due to the lack of complex firmware and filesystem. It remains our goal to get a QR code standard accepted and merged into Bitcoin Core. There is research into a possible standard ongoing [66]. I am currently funding a PR.
Let's pretend for a moment that HWWs actually were properly airgapped. And let’s disregard the numerous vulnerabilities discussed. Even if this were the case, there is still a significant hack that can occur and could leak private keys. This is called a chosen or biased nonce attack. Without getting too in depth into the math/cryptography, when signing bitcoin transactions, besides using your random private key, a pseudorandom nonce is required, which is generated from the message that is being signed and the private key. It is pseudorandom in the sense that while deterministic, the output looks random from any observer’s point of view. However, if the nonce is ever reused, it's implementation is biased in any way, an attacker is able to gain information about the data, or if an attacker is able to choose the nonce, the signatures that are broadcast on the blockchain would leak information about the user's private keys, which could then be reconstructed by the attacker. This would lead to complete fund loss. [67].
The problem with HWWs is that there is no way to know that the nonce is not biased. You have to trust the developers, vendors, manufacturers, and shippers. There have been some proposed solutions, none implemented, that could fix this (such as sign to contract commitments) [68].
Let’s continue to make assumptions for the benefit of hardware wallet vendors. All of the vulnerabilities, remote and physical, have been fixed. No more will occur. You are able to purchase and receive the device (somehow) without giving away personal information. Somehow they gain about a hundred developers, a decentralized development process, a strong community (that took Bitcoin 10 years to build), and better cryptographic libraries (that can run on restricted MCUs). They switch to QR codes. They instruct users to only use the device with a segregated, Bitcoin-only computer as a full node. (At this point, I’m not sure what benefits the HWW has for the user). Even if this all were true, as bitcoin-specific hardware, hardware wallets would still represent serious risks of supply chain attacks, which ultimately are impossible to fix.
As an example of the risks of purchasing application specific hardware, let’s look to Bitmain, the largest producer of Bitcoin mining hardware. They were able to ship a backdoor in their firmware, which was discovered in April of 2017 [69]. If activated, it would have allowed Bitmain to link specific machines to customers, and remotely shut down up to half of Bitcoin's hash power at the time.
Also in April of 2017, Greg Maxwell reverse engineered Bitmain ASICs and revealed that it's chip contained an undocumented and undisclosed circuit design that enabled the covert ASICBOOST attack against Bitcoin's proof of work. This interfered with the protocol, blocking the segregated witness update, and gave Bitmain an estimated $100 million per year profit gain, as well as a centralizing effect [70], [71]. Both of these went unnoticed for significant periods of time, even though they produced a massive percentage of the bitcoin hashing power hardware. You don't think your favorite bitcoin hardware vendors could do the same?
Vendors currently try to solve this with (laughable) attempts like tamper evident seals. These, however, don't remove the trust in the vendors themselves, and are removable using everyday items like hair dryers. In addition, there are already counterfeit seals and devices online, and different versions of seals on vendor websites, which makes verifying confusing (and impossible IMO) for users [47]. Another attempt at supply chain security is to use secure elements. However, as discussed extensively in the vulnerabilities section, secure elements can be bypassed by malicious firmware. Furthermore, SE’s come with quite the downside, which is that they are closed source. Verifying the operations of the device is usually illegal (without signing an NDA and paying a lot of money) and quite difficult. Even without malicious firmware or Secure Elements, software and firmware is ultimately dependent on the hardware it is built on. As Saleem warns, “I cannot repeat this enough: if you do not verify the physical hardware, it is game over.” [43]. It is incredibly easy for an attacker or the vendors themselves to add a malicious chip which would compromise the security of the entire device. As hardware wallets are bitcoin-specific devices, they are the perfect target for attackers.
Besides, the firmware comes pre-installed on all of the devices. That means that even if you are one of the few individuals auditing the HWWs' codebases, you have to trust that the code you have audited is the code that is actually on the device. In order to prove this without any trust involved, there must be a process called ‘deterministic builds’ [72]. This allows the users to compile the code, hash it, and check that the output matches the one that the developers built. However, Trezor and BitBox are the only vendors that allow for this process, and it is only secure if other community members participate. Trezor continues to have issues with their build process [73], and BitBox has essentially no participants [74]. In addition, none of the HWW vendors offer bootstrappable builds, which protect against malicious compilers/toolchains (Bitcoin Core does) [75].
In conclusion, hardware wallets should be treated as a serious attack on the Bitcoin ecosystem as a whole. There is no way to know whether or not there is currently a system wide attack on Bitcoin users occurring, just waiting to execute until a certain threshold of users and funds are vulnerable. This is not paranoia, and I am not the only person talking about this. Gregory Maxwell is one of the most knowledgeable Bitcoin developers around, and he recently wrote a scathing review of the industry [76]:
"I don't think very highly of hardware wallets. They're opaque, largely unauditable. Most are crapped up with sketchy altcoin support that forces them into objectively less secure cryptographic code and makes them harder to review. They're an extremely attractive target for supply chain attacks….The badness of the supply chain vulnerability is so severe that I just cannot recommend a hardware wallet except for casual low/moderate value use where it doesn't really matter what security properties you use...
For the moment the situation isn't quite dire because the thieves are busy with low hanging fruit, and haven't started e.g. flooding ebay/amazon with nearly indistinguishable backdoored clones. Yet. (or maybe they have, and Jan 1st, everyone with one is going to have their funds taken all at the same time. :( )...
There is no perfect solution but "just use a hardware wallet" has an astronomical vulnerability to counterfeit goods/supply-chain interception-- one that is potentially large enough to be a systemic risk to the [whole] ecosystem...
What happens when someone sinks a million dollars into setting up clone manufacturing lines for several popular hardware wallets, and saturates distributors, amazon comingling/etc. with nearly indistinguishable fakes? I believe the only reason that we're not yet seeing that at scale is because for the moment you can compromise hardware wallets by adding a slip of paper to the box "We've selected a random 12 word see for you, keep it safe"
Peter Todd is another security expert and long time, leading contributor to Bitcoin Core. When Peter was asked how he would steal from Trezor or Ledger users if he were a developer working for them, his response was “I hate to say this, but this would be a very easy thing. All I would be worried about is getting caught. If my goal is purely to go steal the Bitcoins, you’d just go push your software update that backdoors the random number generator for instance, or backdoors the signing algorithms so it creates broken signatures...I think it’s easy to do and probably easy to get away with it too” [77].
3.0 Arguments Made in Defense of Hardware Wallets:
In this section, I will discuss why common arguments made in defense of hardware wallets are invalid. One of the most common comments I hear, is that using a multisig setup with varying hardware vendor devices would solve all of the vulnerabilities discussed, as you would not be dependent on any single firmware, hardware, or developer. This is just factually incorrect – using multiple insecure devices does not magically create a secure scheme. If you built your house out of cheap windows, cheap insulation, and a cheap foundation, it is by definition still a poorly made home. While a HWW multisig setup would be more secure than a single sig HWW, it still does not represent a sane or secure private key management policy. (Scoring a 30% on an exam may be better than scoring a 20%, but both are F’s). There are so many long term and inherent issues/vulnerabilities with hardware wallets, that finding overlapping vulnerabilities or attack vectors across devices is an incredibly easy task.
Even if this weren’t the case, hardware wallets have such poor code review, that they can’t even properly implement multisignature wallets. Benma, a hardware wallet developer with BitBox, recently wrote a post titled “How nearly all personal hardware wallet multisig setups are insecure”, claiming that “if you use hardware wallets in a Bitcoin multisig setup...you are likely to be exposed to remote theft or ransom attacks...Multisig using multiple hardware wallets is often used as a security upgrade for personal funds previously held in a single-signature wallet. In reality, it often achieves the opposite when it comes to remote attacks. ” [78].
Hardware wallets also implement their own ‘standards’ that have no actual acceptance in the wider community [79], and sometimes don’t even have any documentation [80]. This is incredibly dangerous, as this circumvents the consensus process that standards should go through. In fact, this situation has gotten so bad, that websites have appeared that have had to document which HWW’s implement which ‘standards’, in what ways, with what documentation [81]. Having just your seed phrase is not enough for recovery of your funds.
Another common defense of hardware wallets I hear is that the (numerous) physical attacks aren’t worth considering, because the device’s passphrase, or ‘25th word’, prevents the attacks.
There are a number of issues with the so called ‘25th word’. One, is that for Trezor devices, the passphrase is entered on the computer and not confirmed on the device, which would allow an attacker to MITM this data and send a separate password to the device, which would then receive coins on a separate wallet that the attacker could then ransom [82]. Humans are also notoriously bad at creating strong passwords, especially if it has to be entered on a small device with only two buttons, rather than typed on an actual keyboard. This also creates a scenario where multiple sensitive pieces of information now have to be saved (the seed, PIN, and passphrase), increasing complexity greatly. Memorizing passwords is also absolutely not recommended. It is for these very reasons that Bitcoin Core has always defaulted to not encrypting the user’s private keys. David Harding, the co-author of the Bitcoin Optech newsletters, writes “there's an open question between experts about whether or not the use of wallet encryption in typical user wallets saves more money than it loses...Some experts believe the number of occasions where a wallet file has fallen into a attacker's hands without that attacker getting direct access to the user's computer is small compared to the large number of occasions where a user has forgotten their passphrase, so it's on average safer not to use encryption.” Wladimir J. van der Laan, the maintainer of Bitcoin Core, supported the same message by writing, “I've received way more sob stories about people losing their wallet passphrase than about stolen funds”, and declared that he is “partial to not encrypting by default”, since encryption only really protects funds when “people have physical access to my PC but won't use it to install a keylogger/backdoor" [83].
The final defense of hardware wallets that I often hear is that they have a reduced attack surface. While it is true that HWWs are not a fully fledged computer, running the nearly 30 million lines of code that is the Linux Kernel, with a complete GRUB bootloader, coreboot BIOS, and all peripherals (including firmware) – this is a very elementary way of viewing attack vectors. Threat analysis is so much more than just counting lines of code. The in depth analysis I just performed in the previous sections clearly demonstrates this. It does us no good if the smaller code base is littered with numerous critical vulnerabilities and inherent architectural issues. However, this does bring up some good points, like the fact that the Linux Kernel is monolithic and doesn’t have great hardening [84]. Yeti (the solution I propose in the next section) solves this not by reverting to poorly designed hardware wallets, but by recommending a combination of secure operating systems with certain special attributes, and by running them in a multisignature offline setup.
4.0 Solutions
We have talked about all the issues, so now what is the solution? I have demonstrated here that without a doubt, hardware wallets are not it. Our requirements are running the reference implementation (Bitcoin Core) in an offline, multisignature setup, with a true airgap and minimal software dependencies. The hardware used needs to be wiped clean, running an open source operating system, and be single-purpose (used only for storing/sending/receiving your Bitcoin). So how do we achieve this? We achieve this through Yeti [2], which is a protocol that enables users to secure generic hardware, install Linux, Bitcoin Core, and set up airgapped multisignature wallets – all using the reference implementation.
As discussed above, in scenarios where the greatest security is needed, we advise users to install certain different operating systems. These are Qubes [85] (using the AppVM’s Whonix Workstation and Whonix Gateway), GNU Guix [86], and Debian [87]. Qubes minimizes the trusted computing base, helps with the bloated kernel issues, and isolates peripherals, while Whonix [88] enables the best hardening of any distro and makes DNS leaks impossible (even malware with root privileges can’t discover the true IP address – as long as there’s no exploit against Xen or Tor). GNU Guix is an OS that is working on reducing the ‘trusting trust’ attack [89] by minimizing the size of the binary seed bootstrap, and working towards a universal, full source bootstrap [90]. Finally, Debian is a major linux distribution that can run on the PowerISA, the only open source instruction set architecture with an open source firmware/schematics implementation available on the market. I am also working on a project to port Qubes to the Power ISA.
You should visit YetiCold.com if you would like to view this protocol and it's documentation (how to secure the coordinating/broadcasting device, set up a secure signing location, in depth guides and tutorials for downloading, verifying and installing software, etc). A nice way to visualize the setup, is that it in regards to protocol, it is essentially the same system as a multisignature hardware wallet private key management scheme, except replace the hardware wallets with offline laptops running Bitcoin Core. Is this even possible? Yes. You can run Bitcoin Core on a computer/laptop that has network access disabled. You then use PSBTs (BIP174) to pass partially signed transactions around over the air gap (QR codes), until passing back to the online device (full node; Bitcoin Core on a networked device) to broadcast. This isn't possible in Core yet (especially in the GUI), so Yeti is used as a thin layer on top, with the goal that Core is one day all that is needed. As Core gets updated, the amount of code Yeti has is decreased. I am currently funding the work necessary to standardize and implement this in Bitcoin Core.
This may sound like overkill for some scenarios, and I both understand and agree with that. What I have described here is our most secure level of account. This is for one of our most extreme of scenarios, with the largest of funds. Just like with traditional fiat money, you most likely have a wallet that you keep small amounts of cash in, a spending account, a savings account, and a safety deposit box. With Bitcoin, you are going to want to have the same partitioning with different levels of security. You are not going to want to have all of your funds in the most secure setup because of usability concerns. It is also a security risk, because physically accessing your signing devices so frequently will be more likely to give away the locations if you are under surveillance. So you want to limit that process as well.
At Yeti, we have different Levels of sovereign custody schemes that balance security and usability in order to recreate those types of accounts that our users are used to. In my upcoming posts, I will be describing more in depth those options, the differences between them, as well as the theory behind them.
5.0 Advantages and Disadvantages of the Solution
The strength of this solution is obviously security. However, there are weaknesses which should be discussed. The two major ones are space and time. Laptops take up much more physical space than hardware wallets do. Typically in multisignature protocols, it is suggested for the cosigners to be spread geographically. This traditionally involves giving the cosigners the hardware wallet. It is more difficult to give a cosigner an entire laptop than a small hardware wallet. This could be solved by giving the cosigners only a backup of the cosigner keys (Yeti uses descriptors and Core’s WIF format, written in the NATO alphabet with a checksum). However, you then would be required to perform a full re-download/installation of the software and restore the wallet anytime you wanted to send bitcoin. (This is not necessarily recommended, but supported – especially if you don’t want the cosigners to know what you are giving them. This is made less-worse by the fact that such a secure setup should only be spent from once or twice a year.).
The other downside is time. Hardware wallets are easy. The UI is nice, and set up is fast. But as proven, they’re not secure. Yeti will take longer to setup. But time does not have to mean confusion. We work really hard on user experience, and that is because we believe user experience is not only abstractly important, but important as a component of security. Good usability means there is less of a chance that users will make a fatal error. In addition to us, there is already an entire new Bitcoin Design community [91] that is creating a Bitcoin Design Guide and receiving new grants to help develop Core’s user experience.
However, we recognize that we cannot turn people into security experts overnight, and we do not want to drive users to custodian options as a side effect of exposing the security theater of hardware wallets (as custodians also represent an existential threat to the Bitcoin ecosystem). This is why we have worked hard on the user experience. During installation, Yeti will explain every step of the way what is going on, and what you are to do. As mentioned, I will be releasing more in depth posts like this one. And the Yeti team will be releasing videos explaining the process. As Grubles from Blockstream said, “That hardware wallets are easier for noobs just means that we need to make the old laptop UX easier.” [92].
While a common complaint about this solution is expense, as there is a belief that purchasing laptops as offline signing devices has to be expensive – this is not true. You can find laptops at Best Buy for $150-200. This is not drastically different than most hardware wallets, for a drastically more secure system (it should be noted that hardware wallets cost about the same – the BitBox and Coldcard both cost around $120).
6.0 Conclusion
Bitcoin Core is the spec of Bitcoin. Bitcoin Core currently is Bitcoin. If you want to follow Bitcoin, and you want to run well reviewed code, you run Bitcoin Core. Bitcoin Core has more developers, more peer review, more fuzzing, and more research than any other wallet. It is not even close. That security gain is far undervalued. In comparison, all Hardware Wallets have been vulnerable to remote attacks, all as a result of lack of peer review. All are vulnerable to supply chain attacks. All have inherent architectural vulnerabilities.
Besides Yeti, there currently is no other secure, offline, airgapped, HD multisig wallet built on top of Bitcoin Core with minimal software dependencies. Every dependency is a potential attack surface. Outside of Core, you should only use battle-tested software. It is just inappropriate to recommend hardware wallets when you cannot confirm if the device is genuine, they run essentially non-peer reviewed code, falsely advertise the ability to work with malicious nodes, have no ability to properly setup multisignature wallets, and have a long history of life-ending bitcoin-stealing vulnerabilities that are often hand-waived away as insignificant.
Copyright © 2022 Robert Spigler - All Rights Reserved.
I do not host this website. Default cookies for the purpose of analytics and performance tracking are loaded. I do not have control over how these cookies are stored. If this is a concern of yours, I suggest installing something like 'Privacy Badger' in addition to selecting "Decline". View 'Privacy Policy' for details.