Affected firmware: All version below v4.2.2 including btc-only
Fixed in: v5.0.0
I’ve become hooked on the adrenaline rush of finding security vulnerabilities in hardware wallets. Now this might sound super lame, but don’t knock it till you try it #nerd_rush. Bitcoin hardware wallets are a great target because virtually all attacks are significant including physical attacks. And all devices are vulnerable to some level of physical attack it is just a question of how much time and money the attacker wants to spend. Also, even single device attacks that cost thousands of dollars can be significant because it is common for people to store many multiples of this on hardware wallets. The password brute force attack discussed here however is relatively low cost (~$100), but a little slow (~5 sec/guess).
Introduction
The BitBox02 is a new hardware wallet from Shift CryptoSecurity and I found it to be a very professionally designed device with good usability. The BitBox02 uses the ATSAMD51 from Microchip, a general-purpose Cortex M4 MCU, along with an ATECC608A secure element from Microchip (big chip and small chip in the pictures respectively). My initial interest in the BitBox02 was focused on finding an error in their usage of the secure element. So, I started by using a sophisticated tool to remove the epoxy to expose the secure element and the bus.
But after reviewing the code for an hour or two I was disappointed to not find any errors. I started to get worried my needed nerd rush was going to be left unsatisfied. Family life really limits the amount of time I can spend so I needed to find something soon. After a couple more hours I finally noticed something that had some potential, a possible side channel attack on the password entry check.
To many less technical people lots of these attacks sound unintelligible and seem more like magic than engineering, so I’m going to try and simplify my descriptions here to make this document more useful to the masses. Side channel attacks generally refer to any way a system leaks information outside of its normal behavior. To make this more understandable for you normies let me first give you an example of a real-world brain teaser problem that is very analogous.
Problem: There is a room with three light bulbs and a closed door, you are outside. There are no windows and the door seals tight such that no light can exit. Outside the room there are three light switches, one for each bulb. You can freely manipulate the switches, but you can only open the door to the room one time. How can you figure out which switch goes to which bulb?
Take a second and see if you can come up with a solution… Hint, you need to preform a side channel attack.
The normal behavior of information exchange with a light bulb is: Switch on - light bulb emits light, Switch off - light bulb is dark. But like hardware wallets light bulbs are physical devices so there are many other properties. For example, think about how can you tell if an installed light bulb is brand new or “old”? Well there are probably many ways, but you could just look at it and see if it has dust on it. Or maybe you can see a date code printed on it and it is very old. Any normie can figure out these methods because light bulbs are something everyone is familiar with. This is exactly the familiarity researchers have with embedded hardware. Most attacks usually aren’t that “hard” but are more like the previous brain teaser for embedded systems, when you find the solution/attack it seems simple and obvious.
Light bulbs leak information about their previous state in a very strong way. If you are familiar with incandescent bulbs you are very familiar with this property. A light bulb that was previously on, but is now off, will stay very hot for some time. So to determine the state of three bulbs you turn two on and one off and wait some time. Then before you enter the room you turn one of the two on, off. Now when you enter the room one will be on and two will be off, but one of the off bulbs will be hot. Now you can match them to the controlling switch.
In embedded systems power consumption is also an important side channel. We can use real time power consumption measurements to see inside the chip and what it is doing. Everything a chip does turns on different numbers of transistors inside the chip and additionally those route power to other places in the chip at different times. Looking at the power can very accurately tell you in real time what the chip is doing. Now let’s review some security features in the BitBox02 and hopefully the method of attack will make a little more sense when you hear it now that you have some foundation to build from.
BitBox02 Security
The BitBox02 uses a workflow similar to many other hardware wallets. The user sets up the device for the first time and the device generates a “seed” that is a root key to derive all the bitcoin private keys. Next you create a device password to unlock access to the seed for signing bitcoin transactions. This flow is common across many devices. Where the different wallet manufactures differentiate their security is how they protect the seed from extraction and unauthorized usage.
The BitBox02 uses a secure element (SE) to help increase the system’s security level, but it is important to understand exactly how it is using this chip to help. If a secure element is misused it can make your security weaker than just using the MCU by itself. One thing to note about the ATECCx08A (SE) is it doesn’t actually support the bitcoin cryptography (this is not a problem). All the bitcoin related cryptography is done in the MCU in software. The SE is just being used to protect some of the key material used to encrypt the bitcoin seed which is stored in the MCU flash. Shift did a good job with the system architecture in how the key material is divided up. They use the user password + MCU secret + SE secret to create the final secret which authenticates and decrypts the bitcoin seed stored on the MCU. This means a BitBox02 attacker needs to recover all these keys to decrypt the seed directly (well at least the MCU and SE, the user key can typically be brute forced). Not storing everything in the SE is especially important because even though an SE is designed to be strong against physical attacks, no device is immune. Including the MCU to store one of the keys is effectively adding another layer of security that is independent from the SE (defense-in-depth). Having additional layers of protection is important, Shift does this in another area as well which helps mitigate my attack.
Another important security function of wallets is limiting the number of guesses that an attacker can make to discover the user’s password. The BitBox02 uses a limit of 10 guesses enforced by software. If you exceed 10 guesses the wallet wipes out the “keys” on the secure element (SE). This permanently eliminate the attacker’s ability to recover the seed. This limit is important because humans often choose weak passwords. Another thing that compounds this weak human password issue is that the BitBox02 has the user enter their password on the BitBox02 itself. I believe this causes users to use less complex passwords just because the process of entering it is “slow”. I am a fan of the new capacitive touch UI for the BitBox02 and it's better than other competitors, but it isn’t the same as a keyboard. This should cause shorter passwords than normal on average. Using a PC or phone paired with the device is another option for making longer/stronger user passwords, but this introduces more risk an attacker can recover the entire password directly with malware on one of those devices. In my opinion it is best to enter the password directly on the device itself, but the wallet designer needs to be aware users will choose shorter passwords and I don’t believe asking the user to have a “strong” password helps. The human brain limits the amount of true randomness we can easily remember regardless of the entry method. Now we finally get into the details of the attack.
The Attack
The BitBox02 stores a counter in the MCU flash to keep track of how many attempts have failed.
The logic in the code goes roughly like this (leaving out some details):
1. User enters password.
2. Password is encrypted and sent to SE.
3. SE combines password with its secret and sends back to MCU.
4. MCU adds in its secret to get the final secret.
5. The MCU uses part of the final secret to check against the stored authentication code in the MCU.
6. MCU checks if authentication matches
7. If match, run AES decryption to recover the seed
8. Else, increment the failed attempt counter.
9. If failed, loop back to step 1
If you look carefully at this logic you can see there are two different execution paths. One where it runs AES and one where it doesn’t. The BitBox02 runs the AES algorithm in software as do many wallets to allow for better audit-ability. However, this makes the algorithm take much longer which makes its power signature more pronounced. This means that if we measure the power consumption, we will see a difference if step 8 runs or step 7 runs. So, the first step of the attack is to detect that AES decrypt didn’t happen (remember light bulb off and still hot).
The next part of the attack is to notice in the code that the counter increment is the final action after checking the password. This means that until that final step executes the MCU has no memory that any attempt was tried. So the attacker just needs to reset the MCU before it increments the failed attempt counter. I implement this attack by directly connecting to the MCU reset line. This gives the attacker a very accurate and fast way to reset the chip. I also inserted a shunt resistor directly inline on the 3.3V power rail. Additionally, I connected a wire to the I2C line controlling the SE. I used this as a trigger to align my timing so I could accurately find the exact place in the power trace I was interested in.
However, these are small signals we are working with so I needed some additional equipment to make the measurements. So I also used a differential probe (from NewAE) to remove the common mode signal (3.3V). Once this was done I could see some interesting data on the scope. But now the challenge was to find the exact place in time where the AES decryption of the seed happened
I used the writes on the I2C bus to the SE to synchronize my power trace with the code being executed. Next, I knew when the MCU writes to flash it would cause a large power spike as well so I was able to find that quickly. So now I was able to bound where I was looking to try and find the signature of AES. And to my surprise the AES difference just jumped out at me without having to do any computer aided processing of the signals (see below).
No AES With AES
Time window
Now I had the position precisely located and I had precise triggers which allows me to reliably reset the MCU just before the code can update the MCU attempt counter (mem write). This allows the attacker to continue to try passwords without the MCU known, but Shift had a backup.
Defense in Depth
Shift implement another security feature specifically to be additional protection in case of an error like the attack above.
When the SE does its part of the key derivation to get what I called the final secret they use a cryptographic command on the SE called KDF (key derivation function). This is just a fancy name for “hash this data with a secret key on the chip”. They actually do this with both slot 3 and slot 4. But slot 3 (ROLLKEY) has an extra bit checked in its configuration on the SE. It has the “LimitedUse” flag set (SE configuration is listed in the source code). This flag has the effect that every time this slot is used with a crypto command (like KDF) it will increment an internal counter in the SE until it reaches its maximum value. Once the maximum value is reached crypto commands will not execute on that slot.
Shift has the counter set such that this slot can only be used 730500 times.
#define MONOTONIC_COUNTER_MAX_USE (730500)
So this provides an upper limit on usage of the BitBox02 to act as a failsafe against brute-force attacks.
Conclusion
In the above I described how the password attempt counter in the MCU can be bypassed allowing an attacker to attempt up to 730500 guesses using the user interface. The above attack I believe can also be developed further to be implemented by just plugging into the device through USB without any disassembly. This attack would use the less precise method of “cutting the power” to cause the BitBox02 to reset before the attempt counter increment. The device would use the power signatures to synchronize the triggers for the attack. Also a device could be constructed that could automate the password guessing by using sensors placed over the capacitive touch electrodes. This would result in a low cost non-invasive attack. However, it would still be “slow” because guesses require the device user interface. If an attacker steals your device he would still need 1-2 months. If the victim notices the device is missing he can move his funds. But to prevent this, the attacker could also replace the stolen device with a “bricked” device. Then the user may just buy a new device and reinitialize with the same seed because they are unaware of the attacker.
Lucky for Shift this error was able to be fixed with a software update. But the important thing to remember when selecting a hardware wallet is all wallets are going to have security issues and if they don't it means no one is looking. The best way to judge a wallet is to look at what was the nature of the past security errors and what was the company’s response when the error was disclosed to them. No wallet will ever be perfect, and they will all make different compromises, but it’s important to use a well-researched wallet so you can know where you stand from a security perspective.
