It’s been almost 11 months since we showed that the Bitfi Knox MD40 wallet was vulnerable to two quite serious attacks:

• The keys persisted in memory for days, allowing them to be recovered over USB in a few minutes – the cold boot attack.
• The device could be easily rooted and backdoored over USB in a few minutes, allowing an attacker to receive your keys when you used them – the evil maid attack.

In those 11 months, Bitfi have not informed users of their device that they were vulnerable, or if they continue to be vulnerable:

• Is the USB bootloader still open on some or all Bitfi devices?
• Can some or all devices still be rooted trivially?
• Have reasonable precautions been made to wipe the RAM?
• How does a user determine if their device is vulnerable?

Without knowledge of the vulnerabilities on their devices, users cannot take appropriate actions to mitigate risk.

If you take their threat model as truth – that it is safe from nation states – you have no idea if your funds are at risk or not.

This is completely unacceptable, especially when one of their co-founders claims that not informing users of security issues puts lives at risk.

Further to this, Daniel Khesin has stated they believe the attacks take at least 10 minutes and have a 25-30% success rate. In reality, it was 2 minutes, and we didn’t see them fail. This suggests a massive disconnect on Bitfi’s side – they don’t actually understand the issue.

2/ and took anywhere from 10 – 30 minutes just to attempt. This means that you would have to leave a device unattended & within the physical reach of a highly skilled & sufficiently equipped attacker in order to be “at risk”. While it is a “feasible attack” it is not a “likely”

— Daniel Khesin (@KhesinDaniel) July 14, 2019

Without acknowledging the ease with which the attacks were carried out, there is no way they can actually fix them properly.

I have some very simple – and reasonable – requests for Bitfi:

1. Document the attacks clearly and concisely on your own site, bitfi.com, including which versions of hardware and software are still vulnerable.
2. Inform your customers, by way of both email and the dashboard, of these issues.

A company unwilling to take these actions is, by their own words, putting people at risk.

Without these basic courtesies in place, I’m not even going to entertain looking at the devices at Defcon.

Daniel Khesin – Bitfi’s not-CEO – has recently started differentiating Bitfi as the only one that can protect against state actors.

But why would he be recovering it? He is not the threat. The threat are state actors. Nobody expects Cybergibbons to crawl through their window and do something. No one gives a shit about you. Government seizure or someone else with those resources and it will all be taken.

— Daniel Khesin (@KhesinDaniel) July 13, 2019

This doesn’t hold up to scrutiny.

Daniel keeps on talking about “forensic labs” that can recover keys from Trezor’s STM32 MCU. This is a feasible task.

Yes you are promoting it. I don’t care what elaborate methods you have for storing your 0.0001 BTC. I do know that Bitfi stores nothing. And your Trezor will not hold up to forensic methods. Just be honest and say Trezor is only good for online attacks. Even then it has issues…

— Daniel Khesin (@KhesinDaniel) July 14, 2019

He also claims a “secure element” does very little to stop extraction. Recovering data from most secure elements is beyond the means of nearly every lab in the world. Those that could carry it out will be charging very large sums of money.

1/ First, a secure element does very little to stop extraction. Second, the whole argument against SE and why companies use off the shelf microcontrollers (usually from STM) is because firmware is open source. Benefit of that is you can audit the source, unlike with a secure

— Daniel Khesin (@KhesinDaniel) July 14, 2019

Finally, he claims that anything typed into a computing device can be recovered. As of 2019, there are no labs on this earth who can recover data from the RAM inside a powered down MCU.

And as we have learned, being solely focused on this, anything you type into some kind of computing device is retrievable with forensic methods unless complex memory management is handled properly which is not easy..

— Daniel Khesin (@KhesinDaniel) July 13, 2019

But, let’s assume these labs exist.

There are three serious logical errors here.

Firstly, how does the state actor have such advanced capabilities in recovering data from a secure element, but are unable to backdoor a Bitfi?

If a state actor wants to access your funds on Bitfi, all they need to do is backdoor the device. We showed how easy this was last year. It’s a much easier attack than cold boot.

Secondly, if a state actor wants your funds, they are either going to get them or make your life unpleasant. In other words, YOU’RE STILL GONNA GET MOSSAD’ED UPON.

Thirdly, if these labs are capable of recovering anything typed into a computing device, this means that these same labs can recover the seed and phrase from a Bitfi.

Bitfi have created a threat model to which their own device is incredibly vulnerable to.

Well, here we are again.

The topic of Bitfi has reared it’s ugly head. I’ve written about Bitfi several times before, but they are still banging on about how their device doesn’t “store” your keys. If it doesn’t store your keys, there is nothing to steal.

This is bullshit.

There are two options here:

• It does not store the keys
• It does store the keys

Let’s threat model these two.

Situation: Bitfi does not store the keys

Imagine there is a means by which the device, genuinely, does not store keys in any form, for any length of time.

This would stop all attacks that aim to steal they keys, because they do not exist on the device. This would include:

• Cold boot attacks that recover the key after the device has been used.
• Evil maid attacks where the firmware is modified to recover the key before it is used.
• Side channel attacks where the device leaks information about the key.

As these attacks would be impossible, there would be no need to use mitigations to make them more difficult to carry out.

Situation: Bitfi does store the keys

Now back to reality. Bitfi does store keys for a finite length of time in RAM.

This means that:

• Cold boot attacks are now possible as the keys did exist in RAM and may remain in some form.
• Evil maid attacks are now possible, as modified firmware can read the key and send it elsewhere.
• Side-channel attacks are now possible, as the device has to store the key

This, in turn, means that mitigations must be put in place to make these attacks harder (but not impossible) to carry out.

The efficacy of these mitigations is therefore key to the security of the device.

Bitfi has (some) of these mitigations in place. As far as I know they:

• Attempted to reduce the amount of time the keys exist in memory.
• Attempted to obfuscate the contents of memory.
• Have prevented USB data access to the device.

Conclusion

If Bitfi didn’t store keys, there would be no need to mitigate against attacks that steal the keys. They do have these mitigations in place.

It’s dishonest to keep on claiming that it doesn’t store keys when it does.

How effective are these mitigations? Well, we have no idea. I doubt Bitfi do either though.

Bitfi’s core concept is that the wallet itself does not “store” your private keys – it calculates them on the fly.

It is acting as a simple key-derivation function. A salt (8 characters) and a phrase (30 characters or more) are passed through a simple algorithm to generate longer private keys.

The Bitfi takes a short key and “stretches” it into a longer key.

There is no secret sauce in a Bitfi – you don’t need that user’s Bitfi (or any Bitfi, for that matter), the user’s email address, password, access to the Bitfi dashboard or anything else. All you need is the salt and phrase. With those, funds can be accessed.

The Competition

We need to see how others have tried to implement hardware wallets. Most of them don’t work like the Bitfi.

• A private key is generated using a random number generator in the wallet.
• The private key is displayed on the wallet itself. The user writes it down and stores it safely as a backup.
• This is the only time the key is output from the wallet.
• From this point onward, the wallet acts as black box, signing any transactions that are sent to it. There is no need to enter the private key, and the private key is never output from the device.

This is probably the most important security feature of a hardware wallet: the private key is locked away in a black box with a limited attack surface and on a device that has a single use. The private key never needs to exist on your malware-infected, general-purpose laptop, and is therefore much less likely to be compromised.

There are still some obvious security issues that need to be handled.

1. If the wallet is stolen, it could be used to sign transactions. To prevent this, the wallet uses a PIN to guard access to the black box. Without this PIN, the device will not function. Brute-force protection makes it infeasible to try all combinations, preventing the private key from being accessed.
2. If the wallet is stolen, the private key could be read out from the memory inside the device. To mitigate this, the keys are stored on internal flash on microcontrollers. There is no easy way to read the keys out without advanced hardware attacks.
3. The wallet simply signs transactions that are sent to it. A user may be expecting to sign “send 2BTC to Bob”. This could be modified to be “send 200BTC to Eve”. To prevent this, the wallet displays the transaction details and asks the user to confirm using buttons on the wallet.
4. The wallet will run firmware, which can be updated. A malicious firmware could be loaded, allowing the private key to be read, or hide modified transactions from the user. Signed firmware and secure boot are used to protect against this. Only the vendor can generate firmware that the wallet will accept.

These protections are not perfect; a determined and dedicated attacker can still circumvent them. This is a key point: all we need to do is raise the bar high enough that most attackers don’t succeed.

Here are some example attacks from wallets:

• Extracting keys from a Trezor using side-channel analysis (fixed) – https://jochen-hoenicke.de/trezor-power-analysis/
• Extracting Trezor secrets from SRAM (fixed) – https://saleemrashid.com/2017/08/17/extracting-trezor-secrets-sram/
• Breaking the Ledger security model (fixed) – https://saleemrashid.com/2018/03/20/breaking-ledger-security-model/
• Unfixable Seed Extraction from a Trezor – https://ledger-donjon.github.io/Unfixable-Key-Extraction-Attack-on-Trezor/

Bitfi

Bitfi is very different to those hardware wallets.

Each and every time you need to sign a transaction, the user enters their entire salt and phrase via the touchscreen display.

The wallet then derives the private key. There is no need for the wallet to store the private key long-term.

Bitfi proudly state that this means there is “nothing to hack” – if there are no keys stored on the device, how can a hacker possibly get the keys?

At first glance, this seems sensible. But if you dig a bit deeper, you quickly realise how broken this concept is. I’m going to describe the attacks we have developed against Bitfi, and how they stack up against competitors.

Cold-boot attack

Description

With USB access to a stolen Bitfi, the salt, phrase and keys can be read from the RAM. This is called a “cold boot attack“.

https://twitter.com/saleemrash1d/status/1035269363903946755

The data persists in RAM for days whilst the device has a battery in it.

This only requires a USB cable and a laptop. The wallet casing does not need to be opened, and no specialist hardware is required. No skill is required as the attack is entirely scripted.

The attack takes less than a couple of minutes, and the device works as normal afterwards. It is feasible for this to be carried out during luggage X-ray at an airport, and returned to the user.

The attack has never bricked the Bitfi and has worked extremely reliably.

There is no requirement to cool the device to perform the attack.

Bitfi recommend the use of “diceware” passwords, which greatly facilitates the recovery of the phrase from memory. The use of a list of dictionary words means there is a lot of redundancy, which in turn means that the memory can degrade significantly and we can still recover the phrase.

Bitfi did not inform their customers of this issue.

Update – Summer 2019 – It has been claimed that the issue has been fixed, but no evidence has been provided, and no independent testing has been carried out.

Mitigations

To protect yourself, the battery must be removed from the wallet after use. To ensure the keys are no longer in memory, the wallet must be left powered down for at least an hour. During this period, you must make sure no one physically accesses the device.

Competition

The RAM on most other hardware wallets is protected from access via USB or debug protocols such as JTAG or SWD. We have observed no such protections on the Bitfi.

Even with this considered, most other wallets take steps to “zeroise” or wipe the memory immediately after it is used. This limits the window over which cold-boot attacks could be carried out. This is either not performed, or is wholly ineffectual on the Bitfi.

There are no published cold-boot attacks against other hardware wallets.

Malicious Firmware

Description

With USB access to a Bitfi, the firmware can be modified so that the salt, phrase and keys are sent to an attacker the next time they are entered by the user. This permits “evil maid attacks” as well as supply chain tampering.

This only requires USB access to the device. The wallet casing does not need to be opened, and no specialist hardware is required. The attack could be carried out if the Bitfi is connected to a compromised charger or laptop. Using this vector, the attacker never requires physical access to the device.

The attack takes less than a minute, and there are no mechanisms for the user to detect the modification. It is feasible for the attack to be carried out by anyone with access to the device for a short period, either before (supply chain tampering) or after (evil maid) the Bitfi enters possession of a user.

This attack could happen before you receive the device, when going through airport security, or when it is left unattended at home.

Mitigations

There are no mechanisms for a user to check if the device has been tampered with at a firmware level. This has been confirmed by Bitfi developers.

A user could assume that the device is trusted as received from Bitfi. As long as the device does not enter the hands of an attacker, and is never connected to an untrusted USB power source, it could be considered secure from this specific attack.

Assuming the device is trusted as received is therefore high-risk.

Competition

The use of signed firmware updates and secure boot mean that other wallets cannot have their firmware modified in less than a minute using just a USB connection.

There are still other attacks that hardware wallets are vulnerable to.

The wallet can be stolen and replaced in entirety. The replacement will send the PIN to the attacker, allowing them to unlock the stolen wallet and access funds. The user would detect the issue as their key would not be on the replacement wallet, and they would not be able to access funds.

The wallet can be accessed, modified with a hardware implant, and returned. It could harvest the PIN, modify transactions, or spoof integrity checks. This attack is significantly more challenging that simply plugging the device into USB, and to-date, no feasible attack has been shown against any of the popular wallets.

Shoulder surfing

Description

The entire salt and phrase need to be entered into the Bitfi each time it is used. This is entered using a conventional touchscreen, with a QWERTY keyboard, and displayed on the screen clearly.

It is entirely possible to read the salt and phrase from the screen and then use this to steal funds from the user.

Even without direct view of the screen, the finger position when typing allows characters to be inferred. The use of dictionary words means that even if certain characters cannot be determined, they can be inferred from those that can be seen.

As the salt and phrase contain all the information required to steal funds, a user may be entirely unaware that they have been compromised. The attacker can delay the attack until an opportune moment.

Mitigations

The Bitfi wallet cannot be used when someone can observe the device.

Competition

Whilst the PIN can be shoulder-surfed on other devices, an attacker still requires access to the wallet itself to obtain the key. This provides a significant additional layer of security.

Some other wallets mitigate the risk of shoulder surfing by randomising PIN layout.

Key entropy

Description

The Bitfi device allows users to choose their own salt and pass phrase. Multiple studies have shown users are very bad at choosing and storing passwords, and there is no reason to assume that Bitfi will differ.

It was discovered that one user even used the sample phrase from the Bitfi instructions.

Mitigations

A salt and phrase of good quality must be used.

Competition

Competing wallets encourage the use of keys that are randomly generated using a good source of entropy, removing the human aspect.

Something-you-have and something-you-know

Description

Bitfi only requires the salt and phrase, and nothing else. Wallets can be used interchangeably (at least, at a functional level – this is not recommended for security reasons).

If your salt and phrase leak via any means, an attacker has access to your funds. There are no flags to signal this.

This is termed single-factor authentication.

Mitigations

There are no good means to solve this issue.

Competition

Other wallets support passphrases as part of the BIP39 specification. To use the wallet, you need both the key stored in the wallet itself, and a passphrase that is stored elsewhere. This is something-you-have (the key on the wallet) and something-you-know (the phrase).

Use of a passphrase with BIP39 significantly elevates the security above that of a Bitfi.

Conclusion

The Bitfi wallet is less well protected than competing hardware wallets. If you ever let anyone else have access to it, ever connect it to an untrusted device, or use it in a public place, you are not safe.

Users of Bitfi must take significant and limiting steps to mitigate the risk they are exposed to.

Even ignoring Bitfi’s dishonest behaviour, the product has little to recommend it over any other wallet.

Can these issues be fixed?

We aren’t really sure.

There is no hardware root of trust on the Bitfi. This must be burned into the device before it leaves the vendor’s possession for it to be secure. Without this, secure boot cannot be implemented well.

The use of external RAM on a commodity chipset (without RAM encryption) will always leave the keys exposed, no matter how well you try to wipe them from software.

Android is a poor choice of operating system. It makes wiping memory very challenging – the salt and phrase are in tens of locations. It also makes limiting the attack surface very, very hard.