Mnemonic storage on a (dedicated) microSD card

[ghost]

If you were to use a microSD card exclusively for storing a mnemonic, in theory there's no obvious difference between storing a plaintext file of your mnemonic on an SD card vs. as a QR code on paper, assuming:

• Krux writes the mnemonic to the microSD card itself (i.e., you don't do this on a computer)
• You never plug the card into anything other than an airgapped Krux thereafter

However, in Krux we already use a microSD card for storing firmware updates, saving settings, and (if enabled) writing log files that we expect could be opened up on a computer. Therefore, given that we already set the precedent that microSD cards are for "safe" data to plug into a computer, I think we need to go a few steps further if we want to enable this functionality:

1. Dedicated microSD card for mnemonics Require that a dedicated microSD card be used exclusively for mnemonic storage. Hence, if a mnemonic is on the card, Krux will not save settings, log to it, etc. until a card with no mnemonic is inserted. Vice versa, Krux will not write a mnemonic to a card that has any other file on it. It's worth noting that previously such a thing was not possible due to the inability to hot-swap a card at runtime, but thanks to recent work by @tadeubas Krux could now use multiple SD cards throughout its runtime.
2. Encrypted mnemonics Allow the user to enter an encryption key so that the mnemonic can be first encrypted before being stored to the card. Analog methods of plaintext storage like QRs on paper, metal punch plates, etc. are insecure to external threats like prying eyes or (hacked?) cameras that can read them, but with a storage device like an SD card likely the biggest threat is the user themselves who might accidentally plug the card into their computer not realizing it stores their mnemonic. Therefore, an encrypted file will provide some defense in this situation.
3. Secure wipe Add an option under the Mnemonic menu to "Wipe microSD Card" which will delete the mnemonic file and perform a secure wipe (overwriting bits) of the card.

[tadeubas]

2. is awesome... Sparrow, BlueWallet, Electrum and others already have this concept of a Wallet password (or PIN) to encrypt the mnemonics (and other wallet data), and it is important to make sure the user don't misunderstand this concept and the extra word (passphrase) of BIP-39 because some users don't backup their passphrase thinking that it is just a protections/lock in the software and not something necessary to restore your mnemonic seed bkp. So I think that reusing the BIP-39 passphrase automatically as a password for encryption too is somewhat confusing even for advanced users, because other software's don't have this behavior.

3. the way you described it seems to me that this will make the process unsafe. Most of the losses are related to the users own fault rather than an attack vector by a third party. Maybe we can add this feature in a way that if the user type a certain "wipe password", the mnemonic is not loaded and the encrypted file is deleted. We can also think about a "plausible deniability" way to access the mnemonic with the correct password but a different BIP-39 passphrase, allowing the user to verify addresses and sign transactions of a wallet with less funds than his "real wallet".

1. I don't see any problem to use the same SD card as settings, logging, PSBT, etc (as these information's are not sensitive). So only 2 SD cards would be needed.

[ghost]

2. Good point. Better to keep them separate.

3. Yeah, wipe after load may be too aggressive to do by default, but the option to wipe the file from a card would be necessary if you wanted to retire an old card or something along those lines.

1. I probably wasn't clear. I'm envisioning the card holding a mnemonic to be only briefly used. Something like:

Load Mnemonic -> Via microSD -> Insert your mnemonic card -> [Enter your decryption key ->] BIP39 word list (Continue) -> Remove your mnemonic card -> Home screen

The "Remove your mnemonic card" could prevent continuing as long as /sd/mnemonic.dat existed. The reason I think that should be done is that the user could inadvertently leave it in and save a signed PSBT to it or similar if they aren't required to eject the card before continuing.

So, yes, you would end up having one card if you only used microSD for your mnemonic, or two if you wanted to save settings, PSBTs, etc.

[ghost]

Found a discussion of this same idea in the seedsigner-os repo: SeedSigner/seedsigner-os#31

They mention that ColdCard generates a 12-word mnemonic encryption key. Using a mnemonic for this is a good idea because:

1. it forces the user to use a sufficiently secure key,
2. we already have ways for a user to securely generate mnemonics (Add option to generate mnemonic from camera feed #38 will be particularly useful for this), and
3. you could then use all the existing mnemonic exporting functionality we already have to print it, punch it, etc. If we assume that the main threat model for having a QR on paper or steel is that someone else could see it or take a picture of it, then at best now all they get is your encryption key. They have to then physically steal your microSD card too to get access to your real mnemonic.

All that said, the more I think about it I don't see why Krux should require a mnemonic to be encrypted when exporting to a dedicated microSD card. It being optional does make it easier to shoot yourself in the foot, but the same could be said for the existing export methods.

A compromise between the two would be to use the SIGNER_PUBKEY to encrypt the mnemonic if the user chooses not to provide an encryption key of their own. Since Krux already knows this (public) key and uses it to verify firmware builds, it would be available on the device to both decrypt and encrypt mnemonics. Users who build Krux from source and change the signer pubkey to their own would be even safer.

[tadeubas]

"A compromise between the two would be to use the SIGNER_PUBKEY" to encrypt the mnemonic if the user chooses not to provide an encryption key of their own
If that is the public key, how it is possible to decrypt without the private key? You said "it would be available on the device to both decrypt and encrypt", so are we exposing the private key to Krux somehow?

There are two schemes on Coldcard to secure your seed bkp. One is the Seed XOR, the ability to combine 2 seeds to create a third using the bitwise operator XOR (this third seed will only exist temporary on the device) https://seedxor.com/ . The other one is encrypted seed bkp https://coldcard.com/docs/backups . I think it is important to understand the differences and tradeoffs of both methods, that can be applied simultaneously too!

I also agree that if Krux exports unencrypted bkps there is no need to require an encrypted bkp just because it's on an SD and the user can make a mess... IMHO Krux is just a tool to help the user interact with Bitcoin , it's always good to tell the user what Krux does (and maybe what the user should do), but I don't think Krux needs to "protect" the user from itself, or hide/disable features for the user "for its own safety"