How to protect hardware wallets against tampering

So you just received a package with your brand new hardware wallet. Genuine sender? Check. Intact anti-tampering seal? Check. Think you’re safe to use your wallet now? Think again.

If an organisation had enough know-how to intercept your package, replace the firmware of your hardware wallet by some rogue software which would allow them to empty your wallet, don’t you think it would be trivial for them to duplicate and replace a piece of colored tape, giving you a false impression of security?

Is there a way to fully guarantee that your package has not been opened and tampered with, other than fetching it directly from the hands of the developpers ?

An approach, available for open source projects, would be for the end-user to compile herself the wallet firmware from a verified repository. You may know how to check out a docker environment on Linux and launch the building process, but there is no way this approach could scale to mass adoption.

The solution: attestation

A better approach for proving authenticity of hardware wallets is to use attestation. This is basically a cryptographic challenge presented to the device each time it is connected to the computer (or smartphone).
Let’s take an example: the Ledger Nano is using attestation as a way of proving to its owner that the product is genuine.

How does it work?

The Ledger Wallet Chrome application sends a random value to the Nano as a challenge. The Nano then signs this random value + the firmware version, using an embedded private key shared by some batches.
The Chrome app knows the public key and can verify the signature.
If an attacker switched the Nano with a replica running a rogue firmware, it wouldn’t pass the attestation test and would immediatly be rejected as non genuine.
There is absolutely no way that an attacker could replace the firmware and make it pass attestation, without knowing the Ledger private key.
Also, as a side note, all API calls are protected by an attestation token generated during the initial check. Without a valid token, it is impossible to query our servers (protecting ourselves against unfair use of our blockchain explorer).
Attestation doesn’t have any impact on privacy. Ledger uses a set of keys which are distributed by batches (for instance, we would change the key every 10,000 units). It is shared enough to completely avoid tracking, but is not unique to be able to contain damage in case of a key being compromised (which would affect only a part of the user base).

What about the Ledger private key security?

Attestation-based security is as good as the security of the attestation private key. If it is embedded in all Nanos, isn’t it a major risk?
This is where you can see the true power of using secure elements (or smartcards): the chip is designed to be a stronghold with extreme measures against physical attacks. The private key extraction attack can be theoretically executed, but at great expense and time, and only an organization such as the NSA could do it.
Hardware wallets based on regular micro controllers would never be able to use attestation. As these chips are not designed with security in mind, the master private key would be extracted in days at little or no cost.

Executing a massive interdiction on a non smartcard based hardware wallet could be an extremely lucrative opportunity

Just flash a rogue firmware (with basic modifications from the open sourced one), replace the package/stickers by your own, and you are done! No need to hack anyone or anything.
Ledger users, not affected.

If you own a Nano S, you can refer to the following guide to extensively check the device’s integrity.