Some Other Wallets.fail
Our Take on The wallet.fail Presentation
At the recent security conference, CCC, there was a presentation given about
hardware wallets and their security. As is the style with disclosures these days,
there is a pretty website and a fun name to go with it: wallet.fail
The Coldcard hardware wallet is not mentioned in this presentation, and it focuses on the Tezor and Ledger wallets. However, we wanted to go over the talk, just in case any of our customers are curious about how we’ve solved the same issues in the Coldcard.
We will be linking to a Youtube copy of the presentation, because we can deep-link to specific parts of the talk, which is pretty long. There does not seem to be a written version of the talk, nor any published papers to go with the talk at this point.
But First… A few words about Responsible Disclosure
While we understand the researcher’s need to get maximum media impact for their work, we want to say that it’s just not cool to disclose major vulnerabilities without contacting the affected company first. The fact is the vendor will not be the victim. It will be Bitcoin community members and their friends and family that will be directly affected by uncontrolled disclosures.
We do not pay bug bounties, but are happy to discuss security issues with any researchers, via PGP email or support email.
Section: Supply Chain Attacks
The first speaker discusses supply chain issues. First up is the common ‘Security Stickers’ (see 7:22). where they say smugly, “Stickers are for Laptops”.
We do not rely on stickers. Instead we put our product into a uniquely serialized bag. This is different from a sticker because the serial number of the bag is recorded (forever) into the product itself. Here’s what this looks like:
Our approach does take more effort in our factory (at the start of the supply chain) and also when the customer receives it (at the end of the supply chain), as they need to confirm the bag number… but we like it!
(Aside: At the factory, we have a bin of perfectly-good Coldcard units that are burned with the wrong bag number, or burned with the number of a defective bag, and so on. There are real costs to our approach!)
The custom bag is only one layer of our “security in depth”. Our clear plastic case is also a critical part of the Coldcard’s security which some people overlook.
At one point in the video, 14:10, the researchers show an RF implant which could be used to press “OK” remotely. As you can see, although the board is tiny, an antenna is required and the overall result is pretty big and ugly. It would be hard to sneak that into a Coldcard case and make it invisible. (Our clear plastic case is also welded shut, so opening and re-closing it is not a simple matter.)
Some have called our industrial design “Cypherpunk Ugly” but the clear case is one feature you should expect to see on all future Coinkite crypto products.
Section: Ledger STM32 0xFOODBABE
The next researcher to speak describes a pretty serious bootloader issue with the Ledger Nano S. The problem relates to a hex constant 0xF00DBABE which will now enter every commentator’s lexicon forever. (See around 22:06).
This attack is not applicable to the Coldcard at all. We don’t rely on a single memory location… that would be the opposite of our mantra: “Don’t Trust, Verify!” Anyone who has used a Coldcard knows that we checksum every single flash memory address each time it is powered up. The SHA256 hash observed is verified against a value stored securely, inside the secure element.
When we say verified, we mean that the check is performed inside the secure element (ATECC508A) and the result is shown to the user via a dedicated red/green light that cannot be accessed by any part of the system except the secure element.
When we say stored securely, we mean knowledge of the main PIN code must be demonstrated (using a challenge/response sequence) in order to change that hash inside the secure element.
But you don’t have to take our word for it, as our bootloader is open source, and we have a white paper on this specific subject, available here.
The presenters continue into a fun demonstration of a running a
simple game on the Nano by combining this new 0xF00DBABE attack
with already-published weaknesses around the Nano S’s verification
process.
Section: Ledger Blue RF Leaks
In this part, the researchers demonstrated a weakness using the RF leakage from the Ledger Blue product. In the end, it was the Ledger’s pretty GUI that created the problem.
For security researchers who might try this on a Coldcard, we should warn you that most of our staff are licensed amateur radio operators (hams) and so we all have SDR (software defined radio) setups on our benches. We even have a very expensive dedicated-function 3Ghz spectrum analyzer too… so of course our code has protections against this sort of “tempest” attack.
I’m sure Ledger will update their firmware to remove the visual feedback during PIN entry and this issue will be cleared up quickly. Still, we’ll always have that audience reaction to their use of so many peak-hype buzzwords (32:34).
Section: Glitching the Trezor One
The final and most technically challenging part of the demo occurs when they successfully glitched a Trezor one after 3 months of effort. Due to the design of the Trezor one, where all the secrets are stored in the main flash, it’s very easy to get the funds out after the glitch. We do use a very similar microprocessor in the Coldcard, and so it’s probably possible to glitch it as well. But the Coldcard uses a secure element to keep your secrets, and access to that is dependent on your PIN code. The PIN code is not stored anywhere that the main micro can access… it has to ask the user for the code, and only the secure element knows if that’s the right PIN.
The fact is, all bytes of the main micro’s flash memory are already known to the customer, except for a 32-byte secret called the “pairing secret” that is a pre-shared secret between the main micro and the secure element used to secure and authorize their communication.
A successful glitch attach on our micro would reveal that secret, but it does not relate to your bitcoin keys (it’s assigned at the factory). However, attackers could use the pairing secret to accelerate the testing all possible PIN numbers in a brute-force attack. We support up to 12 digits of PIN code, and we strongly recommend to use at least eight digits. The ATECC508A, due to the serial protocol and chip limitations, will limit the max attempt rate to a level such that a brute force attack is not practical against strong PIN numbers.
To be clear, you cannot brute force PIN codes normally on the Coldcard because we enforce a time limit when attempts are wrong, and we take very-involved measures to make sure you cannot avoid that time delay.
As a further defense against glitching, when the Coldcard bootrom starts, it looks
to see if the system is in a secure state, and if it’s not (ie. RDP!=2)
then it makes it secure and resets immediately. There is
actually no sensitive data in RAM or flash at that point anyway.
You can see that here in dispatch.c at line 117