(optionally) Don't write the existence of bip39 passphrase wallets to disk

[rabutial]

Right now the App creates numerous references to bip39 passphrase-protected wallets on disk. This allows an adversary with access to the device to determine that (more) BIP39 passphrase wallets exist, and apply rubber hose/$5 wrench methods to access them.

When using the app to access a bip39 passphrase wallet, it should be possible to do so without leaving any traces on disk that the wallet exists.

This option or behaviour should be designed in such a way that it does not give a forensic adversary information about the existence or non-existence of BIP39 wallets.

[NickeZ]

You have a single use case in mind, using optional passphrase as a "hidden wallet". There are many other valid usecases of passphrase. Like it being a second factor to your backup. Maybe you just want several wallets with the same backup. It is not clear that "do not give away anything" is the best UX for all use cases.

[rabutial]

On Fri, Apr 24, 2026 at 08:20:32PM +0000, Niklas wrote: NickeZ left a comment (BitBoxSwiss/bitbox-wallet-app#4053) You have a single use case in mind, using optional passphrase as a "hidden wallet". There are many other valid usecases of passphrase. Like it being a second factor to your backup. Maybe you just want several wallets with the same backup. It is not clear that "do not give away anything" is the best UX for all use cases.

Then make forensic resistance optional ("Write information about passphrase-protected wallets to disk? y/n").

[NickeZ]

If you really care about not leaving any trace you should probably just run the bbapp from a live usb like tails OS. Ensuring that the bbapp doesn't leave any trace at all for all future updates seems impossible.

[rabutial]

If you really care about not leaving any trace you should probably just run the bbapp from a live usb like tails OS. Ensuring that the bbapp doesn't leave any trace at all for all future updates seems impossible.

TAILS comes with Electrum so I would use that, if I wanted to use TAILS. There are major downsides to the TAILS approach, however -- it requires rebooting the laptop, you can't copy and paste addresses, etc. TAILS is not something we can expect less-technical users to use. At the same time, BIP39 passphrases are a commonly recommended solution for protecting against $5 wrench attacks, and kidnappings/physical attacks on crypto holders are growing at a frightening rate. A French tax official was just arrested for selling crypto investors' information to criminals, leading to [41 kidnappings since January 2026](https://x.com/MarioNawfal/status/2047773069607854512#m). If we are going to have a feature that people may rely on to protect their lives and loved ones, we should make sure that feature can in fact be relied on to do the job. Forensic resistance is an important part of surving such situations. For example: if someone buys a BitBox, uses a BIP39 passphrase as part of their anti-kidnapping strategy, assumes the attacker will not be able to find the "extra" wallet(s), but then the attacker finds the `accounts.json` file... what do you think will happen? That is the kind of situation where attackers start cutting off victims' fingers to make a point. (this is not hypothetical, [it has happened](https://www.huffpost.com/entry/cryptocurrency-kidnapping-finger-cut-off_n_6817b816e4b08041c58c69a9)) And no, bbapp doesn't need to avoid leaving any trace at all for all wallets. My suggestion is to (optionally) load BIP39 passphrase protected wallets into memory only, without writing them to `accounts.json`, without keeping them in cache, and turning off logging to `log.txt`, etc. In terms of ensuring this is done 100% in future updates, it probably means adding an `ephemeral` or `ghost_account` field to AccountConfig and making it clear that this property is to be respected at all costs.

[NickeZ]

We have to weigh the cost of implementation and maintenance against benefit. I'm not arguing that what you are saying is bad, it is just a time/effort tradeoff we as a company need to deal with.

Ensuring that feature "not reveal a specific wallet" is true forever is a social problem not technical. We have to ensure that every commit to this repository does not add something that leaks. That is a tremendous maintenance effort.

If an attacker assumes you have a lot of wealth, they will torture you until they get said wealth. If you assume that they will stop just because they cannot find proof in a json file you are naive.

Wealthy people have always needed to think about security. This is not unique to bitcoin.

What you really want to do is protect the funds from yourself. You will probably fold quickly when they start the torture. So you want things like some sort of built-in delay like assembling the private key from multiple sources or require a call to some custodian.

If you want good opsec you really ought to run the bbapp in an ephemeral VM or container that wipes everything when you are done. See QubesOS for example. You don't need to use a live usb OS if that isn't part of your threat model.

edit: Sorry for writing "naive". I don't mean to offend you, but being from Sweden I have personal experience with people being robbed and held hostage in their home and I can assure you that no json files were opened.

[rabutial]

On Sun, Apr 26, 2026 at 03:56:21AM -0700, Niklas wrote: Ensuring that feature "not reveal a specific wallet" is true forever is a social problem not technical. We have to ensure that every commit to this repository does not add something that leaks. That is a tremendous maintenance effort.

Why does it have to be so hard? You already review every commit, I hope, for many other security issues. This one ought to be something you can check for with automated testing. ("Create an ephemeral wallet, grep the generated files and logs for references")

If an attacker assumes you have a lot of wealth, they will torture you until they get said wealth. If you assume that they will stop just because they cannot find proof in a json file you are naive.

"They only go after people with a lot of wealth" is a common misconception. There have been [kidnappings](https://stats.gart.io/) where 6 men worked for 10 days in order to get $6,000 out of a victim. Anyway, in your example, it's the other way around: it would suck if you do everything else right only for the software to betray you. An attacker would not check a JSON file to see how much wealth you have. They would check to verify that your claims about your wealth not being on your hardware wallet are true.

What you really want to do is protect the funds from yourself. You will probably fold quickly when they start the torture. So you want things like some sort of built-in delay like assembling the private key from multiple sources or require a call to some custodian.

Standard practice is to have some reasonable amount of funds ($5000-$10,000) which you can give up to an attacker, with the warning that "if you want any more, it will take 30 days and I'll have to call my lawyer." This is called "fuck off money" and attackers are often willing to take the smaller but immediate payout to avoid the hassle (and risk of jail time) involved in chasing a much more difficult jackpot. However many people need to be able to access larger sums with much less than 30 days' notice for business reasons (e.g trading), so it is legitimately not practical for many users. Having a wallet where it should not be possible for an attacker to tell that it exists is, for that and many other reasons, highly desirable. And "nobody can tell if the wallet exists" is a core and widely-advertised property of BIP39 passphrase wallets. BitBox should live up to that.

If you want good opsec you really ought to run the bbapp in an ephemeral VM or container that wipes everything when you are done. See QubesOS for example. You don't need to use a live usb OS if that isn't part of your threat model.

QubesOS ephermeral VMs ("DispVMs") are, contrary to popular belief, [NOT a way to protect against local forensics.](https://forum.qubes-os.org/t/anti-forensics-with-dispvm-and-appvms/7052) An attacker can extract the disk and/or swap data of the destroyed VM from the free space of the hard drive. Qubes also logs quite a bit of data about what happens on dispVMs. Also, and in particular where life safety is an issue, it is vitally important to take a "defense in depth" approach. This means having MULTIPLE REDUNDANT security layers, such that **any single layer is sufficient to stop the attacker.** For example, proper procedure would be `bbapp` not logging ephemeral wallets to disk, AND using anti-forensics OS-level tricks to protect you even if that fails. When someone's life is on the line, overkill and redundancy are your two best friends. Bridges, elevators, and airplanes have been built this way for years, [and you certainly wouldn't want the next elevator you ride to be any different](https://xkcd.com/2030/).

[NickeZ]

I'll stop discussing this now because in principle I don't disagree with you.

If you think it is very easy you are free to make a PR. As this is something nobody else has requested it must obviously not impact the UX negatively and/or our ability to give support. When customers forget they used passphrases our support team relies on the log files to be able to remind them.

[benma]

@rabutial a point to note: the app does not know whether a keystore loaded from the device is passphrase-protected or not, it only sees the root fingerprint and xpubs as delivered by the device.

In terms of ensuring this is done 100% in future updates, it probably
means adding an ephemeral or ghost_account field to AccountConfig
and making it clear that this property is to be respected at all costs.

Did you mean as a property of one specific account, or a flag that is valid for all accounts? If per account: as mentioned above, the app can't distinguish between regular and passphrase keystores without API changes of the device, but if it could, then adding such a tag would also be a leak, right?

So probably only a general "do not remember anything" mode would work, where no log and no accounts/caches are written to disk at all, including for regular accounts. This would make it an explicit opt-in setting - would that still be helpful?

As an alternative, what about a way to specify the data folder of the app? Then one could point it to a RAM-mounted directory (something like tmpfs).

[rabutial]

@rabutial a point to note: the app does not know whether a keystore loaded from the device is passphrase-protected or not, it only sees the root fingerprint and xpubs as delivered by the device.

Aha, I see. I assumed it would be clear to the software when the wallet is loaded.

Did you mean as a property of one specific account, or a flag that is valid for all accounts? If per account: as mentioned above, the app can't distinguish between regular and passphrase keystores without API changes of the device, but if it could, then adding such a tag would also be a leak, right?

Correct, if it's not possible for the app to tell if the wallet is passphrase-protected or not, then storing info about a specific wallet would defeat the purpose.

So probably only a general "do not remember anything" mode would work, where no log and no accounts/caches are written to disk at all, including for regular accounts. This would make it an explicit opt-in setting - would that still be helpful?

Sure, an "incognito" or "private browsing" type mode would do the job. Some settings would probably need to persist, like the address of a self-hosted Bitcoin back-end, if any. Also, it should be possible to configure the app to "start in incognito mode by default", because users will forget and compromise themselves if they have to remember to check a box every time they use the wallet.

As an alternative, what about a way to specify the data folder of the app? Then one could point it to a RAM-mounted directory (something like tmpfs).

That might work, but as noted above, it's still necessary to persist some settings (local node, etc). And this needs to be something which less-technical users can realistically do as part of a larger security strategy. Even technical users can't be expected to manually create a tmpfs every time they use their wallets.