Smart cards, or secure elements, are a very specific kind of microcontrollers architectured with security and secret protection in mind. Evolving from simple memory fuses in the early 1980s, it quickly became a standard for holding and processing secrets in the European banking industry and in the worldwide telecom market through SIM cards.
When you own bitcoins, what you really own are private keys. These private keys allow you to sign a transaction and transfer property of your bitcoins to any other party. Anyone who would get hold of these keys would then able to take ownership (and transfer them to their own benefit) without any possible recourse.
Protection of these keys is paramount, but not an easy task. Computers are not known for their ability to secure secrets, and malware targeting bitcoins will be more and more popular.
This is where hardware wallets bring a neat solution: an external device securing the private keys, never exposing them to the host computer, checking what is being signed and signing all transactions inside its walled garden.
These hardware wallets are potentially exposed to five types of attacks:
- logical attacks, such as trying to exploit programming errors in the input parameters validation to execute malicious code and reveal the secrets
- physical or side channels attacks, such as glitching the chip or listening to its RF activity to extract secrets
- trivial man in the middle attack: malware substitutes the payment address before sending the signing instructions to the hardware wallets
- advanced man in the middle attack: the merchant website is attacked by the malware, changing the payment address directly on it so the user can’t know it is being attacked
- “NSA attack”: your hardware wallet is switched by a third party at some time, embedding a special firmware which would reveal your private keys at some time
What value bring smart cards in different attack scenarios?
Secure elements are not magic. They are just tools fit to secure secrets. Bad programming and mistakes would be as devastating as on a regular microcontroller. However they usually provide signature methods to check code execution directly embedded on the secure microcontroller, enabling to validate code paths. So if you made a programming mistake and an attacker took advantage of that, smartcards can avoid leaking a critical asset.
Physical and side channel attacks
The most intrusive basic physical attack you can do on a microcontroller is glitching. It basically means injecting faults, e. g. by creating a clock or current variation to modify the fetched program instructions or flash memory access operations in a controlled way.
Let’s take a trivial example: you have a hardware wallet checking your PIN code and pausing exponentially after each wrong attempts. The pseudo code would be the following:
Depending how the comparison is done, it could be glitched to end before the full PIN is compared, reducing the strength of the PIN.
Also since the invalid PIN attempts are incremented after the PIN is actually compared, it is possible to detect the power consumption surge created by this operation and prevent the write access, allowing a bruteforce attack on the PIN.
A smart card is specifically built to avoid voltage or clock tampering. It doesn’t mean glitching is impossible but it would require access to an expensive laboratory for a few weeks and an intimate knowledge of the chip against a $50 circuit, a cheap digital oscilloscope and a few hours of work for a generic microcontroller.
Of course, glitching can be made harder in most cases for regular microcontrollers by implementing security aware programming principles for critical operations. The following implementation of PIN verification would be more immune to glitching:
Side channels attacks are more subtle and rely on power analysis of the chip while operating to extract secrets. These attacks are more complicated than glitching, but require some careful implementation of the cryptographic primitives to be avoided or specific cryptographic hardware designed to be less noisy.
Smartcards feature cryptographic coprocessors that do just that, and come with vendor cryptographic APIs that have been audited for many years against side channel attacks.
Trivial MITM attack
If the hardware wallet signs anything without second factor verification, then it acts as an oracle. A clever malware can then replace the payment address by its own and defeat all security purposes by sitting between the computer and the hardware wallet.
The solution is to have the hardware wallet show to the user the payment address and the amount for visual verification. If all is fine, user confirms and payment is validated.
In the case of TREZOR, a screen/button is connected to the microcontroller, and in the case of Ledger a cryptographic challenge based on a security card is used (either for direct validation — the challenge being built on the payment address — or to pair a mobile phone which will act as a screen/button).
A smartcard doesn’t bring any upside in this attack scenario, as the solution is based the global architecture of the hardware wallet.
Advanced MITM attack
If the payment address is changed before the user has the opportunity to check it, then security is compromised. User will confirm payment as the address seems legit, but bitcoins will be sent to the attacker.
For instance, you want to buy something in bitcoins at a merchant using BitPay. The payment page is shown, and the malware just change the address on our browser. There is no way you can easily verify the address is really from BitPay.
This attack can be prevented by using the Payment Protocol (BIP 70) to provide a cryptographic validation of the address by the sender. However, this is more suitable for merchants, as it requires being able to issue certificates in a secure way. Smartcards can help making it easier for regular users to create certificates by acting as a trust root protecting issuer keys.
In the most of paranoids attack, you could target a specific user by switching at delivery time the hardware wallet by a clone running a malicious firmware.
Unless you would wipe your hardware wallet, compile everything from scratch and flash again your firmware, there is no way a regular micro controller could do against that.
Smartcards bring an elegant solution: attestation. By embedding a master private key from the manufacturer (for instance, Ledger), the software wallet can challenge the hardware and verify it holds the correct key.
An attacker wouldn’t be able to attest his firmware as it wouldn’t have the master private key (secured in the vaults of Ledger before it’s securely transferred to each Ledger Wallet).
But why a regular microcontroller couldn’t do that? As it is not designed to hold secrets, it would be just a matter of time before one device would be torn down and the master secret key shared by multiple devices is exposed. Tearing down a microcontroller is a more costly operation (around 10k$ done by specialized companies) but quick enough and worth it if the secret is valuable.
Smartcards protect against that by encrypting everything in place and ensuring that secrets are destroyed if the chip is tampered with, considerably raising the effort needed to extract them.
Smartcards are not only great because of their security features, but they are usually designed with multiple Input/Ouput interfaces in mind. They can feature USB, NFC and multiple General Purpose I/O pins for a fraction of the cost of the generic microcontroller.
This result in cheaper and smaller designs.
When dealing with financial assets, security is not a feature, it is the cornerstone of everything. For decades, banks have been used secure elements for their credit cards and critical designs. They have never used regular microcontrollers, and they will never be.
For the same reasons, we believe hardware wallets should be inspired from this successful experience and use banking tools and know how to enhance the users security and privacy.