Bitcoin Stack Exchange is a question and answer site for Bitcoin users, developers, and enthusiasts. It only takes a minute to sign up.
Sign up to join this community
There are many devices available which purport to allow for the secure storage of Bitcoin in adversarial environments, such as compromised computers or potentially untrusted host devices such as phones.
How secure are these devices for storing Bitcoin, and what is the threat model that they protect against and are vulnerable to? How much do commonly stated practices about using these devices improve the safety of storing Bitcoin using them?
what is the threat model that they protect against and are vulnerable to?
Hardware Wallets are security appliances with varying hardware and features, but the overall concept is largely identical. A trusted device holds cryptographic keys, allows for viewing of information on a dedicated display, and accepts secure input through its own interface (buttons or a touch screen).
In the Hardware Wallet security model, a user interacts with their untrusted host device to construct a transaction paying an amount to an address, the transaction is then send to the hardware wallet for assembly of the transaction including the cryptographic signatures. The user is expected to verify the information shown (namely the amount), and acknowledge the transaction on their device. Each transaction needs explicit acknowledgement on the hardware device, and the host is unable to make transactions without that approval.
This is distinct to the traditional software wallet model where a user interacts with an untrusted host, which on the entering of the encryption key for the wallet, can make any arbitrary transaction of any amount to any destination.
How much do commonly stated practices about using these devices improve the safety of storing Bitcoin using them?
Many of the pieces of safety advice given about the usage of Hardware Wallets provide very little additional security, or provide just the illusion of security in lieu of actually effective measures.
An often repeated security measure is checking that the address on your hardware wallet matches the one you attempted to send to using the companion application on the host computer. This is completely meaningless, as the destination address is provided by the untrusted host. The address not matching would be an indicator of absolutely nothing at all other than severe software failure on the part of the device.
How secure are these devices for storing Bitcoin
The ultimate security of the device comes down to trust in the manufacturer, as it is extremely easy for mistakes in software to allow for complete theft or loss of funds, and for invisible backdoors to be inserted. History has shown that many of the devices available are plagued with severe code quality concerns, have poor choices in the construction of their hardware security, and can otherwise be an unsafe choice to store funds.
Backdoors
Backdoors in Bitcoin transactions, specifically due to some features of EDCSA, are trivial to produce and are extremely difficult to detect especially if sporadically deployed. ECDSA signatures contain a number which is generated from a supposedly random source, however if this number is crafted to contain values of a third party, it can deniably leak the secret private key or other information along with being valid. Modern software implementations of ECDSA use [deterministic generation][5] for the secret nonce value, but this is not verifiable without using the private key for validation.
Code Quality
All devices today have shown severe issues with their open source implementations of ECDSA cryptography, or simply have their implementation completely closed source to evade analysis.
The Bitcoin Trezor originally shipped with a ECDSA implementation that based on a python library transliterated into c. This code was comically slow and exposed a [very large timing sidechannel attack][6]. Being physically close to the device while it was signing a transaction exposed enough information through the execution time to expose private key material. The Trezor has otherwise had a considerable number of bootloader, timing analysis, power analysis, and hardware vulnerabilities.
The Ledger Nano has a amateur hour mistake in its bootloader which allows for complete bypass of the security on at least the main processor which is handling user input and communication. For most microcontrollers the layout of the memory has repeating sections and multiple positions at which pieces of data can be accessed, the bootloader was simply unaware of this and allowed for arbitrary changes to the security sensitive code.
The CoinKite series of hardware uses micro-ecc, an abandoned "ECDSA for arduino" which contains absolutely no tests and is vulnerable to at least one timing attack.
Using a hardware wallet for storing Bitcoin is not a bulletproof choice, it's a considered set of security trade offs that requires thoughtfulness and understanding of the threats and weaknesses of the devices.
