Feature Request: Export/Load seed via encrypted file on microSD card

[KyleOfTheCorn]

A common criticism against SeedSigner is the requirement for the seed phrase to be in plaintext form, either as words typed manually or as a SeedQR code. This limits the storage options of the seed's physical backup for users that spend frequently. The response to this has been to use strong passphrases to protect the wallet and/or use multisig, but this does not solve the issue of being able to improve the physical backup's security.

Additionally, traveling with a SeedSigner requires bringing the plaintext seed phrase (as words or in QR form) with you, or to memorize them. When a traditional hardware wallet user can bring the device only, and leave their backup at home (or in a safe place). This still creates a risk to those users, though, because hardware wallets are becoming more popular and can be easily identified. Storing an encrypted seed on a microSD card raises almost zero alarms on the traveler, since they are general purpose and extremely common. The user would have to be specifically targeted in order for any authorities to even know that there is encrypted data on the card.

This proposal/feature request provides the user with an additional option for seed storage, but is likely to break the "single location of a key" property, which is popular in the community. This option also allows the project to avoid secure elements entirely, which have been discussed in the community on several occasions, by storing the keys in an encrypted state on a microSD card. It should also be stressed that this is not a replacement for BIP39 passphrases, and as will be shown in the user workflows, passphrases can (and should) still be used.

Foundation Devices recently made a blog post on encrypted microSD backups which provides more information on the benefits and tradeoffs. Their format for storing the seed is available in their docs. There exists an opportunity to work with the Foundation Devices team to develop a standard for both encrypting/decrypting backups, and the format in which the data is stored (currently a simple text file).

High-Level Points

• The microSD card should never need to be plugged into a computer (it should be able to remain airgapped).
• The SeedSigner remains a stateless device.
• The BIP39 passphrase is never exported/stored to the microSD card.
• Using an encrypted backup does not replace the need for BIP39 passphrases.
• Exporting/Loading a seed with a microSD card is optional, not a requirement.
• An encryption password should be different than a wallet's passphrase for best practices.

A final point that needs more detail: this is not a replacement for multisig or passphrases, is not specific to singlesig setups, and should still fully support multisig setups. Loading a seed from an encrypted backup is simply another option for loading a seed, and can be used in combination with multiple encrypted seeds stored on multiple microSD cards, written/memorized mnemonics, and SeedQRs.

Downsides

• Breaks the single-backup property by introducing a copy of the seed if the user already has a physical backup.
• It's up to the user to never plug the microSD card containing the encrypted backup into a computer to retain it's airgapped property.
• Requires the user to type an encryption/decryption password for use, which is difficult to do on the SeedSigner.
• Requires the user to memorize or otherwise securely store yet another password.
• Introduces a third party encryption protocol to SeedSigner, which could have its own vulnerabilities.

User Workflows

Exporting Workflow

• With a seed phrase already loaded in the SeedSigner, the user selects Seeds, the fingerprint of the desired seed, Backup Seed, and a new "Export to microSD" option is available.
• A Caution page is displayed, stating "Exporting to a microSD card is not a replacement for a strong physical backup or a passphrase" (or similar wording).
• User selects I Understand and is brought to a page notifying the user to remove the existing microSD card and insert a new one.
• When a new card is detected (or the user selects "Okay"), the user may either set a password or have one generated for them to encrypt the backup.
  • If a password is generated for them, an additional prompt is displayed with the password.
• A confirmation page is displayed informing the user with the filename.
• Upon confirmation, the encrypted file should be saved to the microSD card.
• A success dialog is displayed to the user and prompts if they would like to store the encrypted backup on another card.
  • If the user selects Yes, they are asked to remove the current microSD card and insert a new one.
  • When a new card is detected (or the user selects "Okay"), the same backup is written to the card.
  • (Repeat) A success dialog is displayed to the user and prompts if they would like to store the encrypted backup on another card.

Loading Workflow

• User selects Seeds, Load a seed, and a new "Insert microSD" option is available.
• Upon selection, a page is displayed instructing the user to remove the existing microSD card and insert their card containing the encrypted backup.
• When a new card is detected (or the user selects "Okay"), the user is able to choose an encrypted file from the card (filter by the relevant file type).
  • If not detected, display a prompt to the user that no backup was detected.
• Upon selection, prompt the user for the encryption password.
  • If the wrong password is supplied, prompt an error to the user.
• With a successful password supplied, display the seed's fingerprint and prompt the user to enter a passphrase or load the seed as-is (continues the current process of loading a seed).

[kiz8]

Yes I would definitely use this to move between devices and create multiple encrypted backups. Great idea!

[inpharmaticist]

I like this. Additionally, adding the option to export the seed into two or three seeds generated using Coldcard's XOR feature. Its similar in that you need multiple pieces to reveal the seed but with XOR you can use the individual seeds as decoy wallets. Downsides being that its obvious its a seed phrase.

[openoms]

Sounds like a good feature and agree that it would work very well together with SeedXOR (see SeedSigner/seedsigner#43)

The encryption password can be problematic as it needs to be long and be verified.
The ColdCard generates 12 words from the BIP39 list, that could be an option - secure and easy to verify.

In any case an encryption password verification step is needed to avoid ending up with the false security of an unusable backup.

Would be great to be able to use this 2of3 like scheme with the SeedSigner also: https://github.com/openoms/bitcoin-tutorials/blob/master/backups/coldcard.md#coldcard-single-seed-multi-location-backup-scheme

edit: a long password should be enforced

[jdlcdl]

Scrappiness is such a desirable trait, imo. I like this thread, and this activity. Thanks folks for letting your voices be heard!

I'll share my thoughts on this after I've chewed on them a while.
Till then, they remind me of concerns I had in the past:

• Prudently Paranoid Settings seedsigner#273
• [Feature] Add SeedXOR implementation seedsigner#43
  ...though I'll admit I've had a change of heart (that single-sig is too scary, leaning multisig as the only answer), understanding that seedsigner is optimizing for ease-of-use, protecting users from themselves, sometimes at the cost of not allowing a power user to do what they want to do.

[Semisol]

recommendation: have a few options to manage the MicroSD. Such as

• (secure) erasing it (secure being the data is overwritten multiple times with garbage)
• creating a filesystem
• deleting seeds (overwrite with random data multiple times too)
• encrypting the SD card

[openoms]

@Semisol great point. A LUKS encrypted partition (with a long password) is the best to not run into information leaks whenever the SDcard gets lost or reused.

In this case I think the long password (eg. the CC style 12 words) should be enforced.

[KyleOfTheCorn]

1. Exporting workflow: After success dialog is displayed, Seedsigner OS could ask if the user would like to make an additional identical backup on another microSD card.  The process would repeat until the user has enough identical backups.

Yes, I can see how this would make it easy for this particular use-case.

2. How to best balance security and simplicity of the password creation and ability for users to recall/secure their encrypted passwords.  Will the user create the password, or will Seedsigner OS generate them?  Will any form of characters/numbers be allowed, or will the password be based on BIP39?  IMO creating a series of new passwords for each backup creates too much complexity for the average user and would be problematic as they would then need to backup a series of new passwords in addition to seeds.  Simpler to have one password per seed for all of its future encrypted backups.

I'm good with giving the user the choice to either have a password generated for them, similar to how the Passport does, or allowing the user to supply their own password (and accept the risk that it may not be as strong). It should ultimately be up to the user if they want to use different passwords for the same or different seeds. The SeedSigner itself, being stateless, cannot even determine if the user is doing this.

[Semisol]

If the user can input their own password OR use a 12 word password we could possibly use the same menu for inputting a seed for the password (and checksumming!)

[KyleOfTheCorn]

ColdCard also uses an encrypted backup file. Similar to the Passport, they both use 7z for file encryption and the contents are similarly formatted.

[ffrediani]

Very well written and described Feature Request. Well done !

And agree that is it needed and eliminate the hassle to have to bring a plaintext seed if necessary to travel or move and use the SeedSigner which is not very practical.

However one thing I would remove from the above requirements is that the seed would not be stored in the same SD Card as the SeedSigner one. I don't see that as a big issue really. It is still very secure as long stored in a encrypted file by a passphrase. And it can encourage people to move from HotWallets stored seeds in their PCs to SeedSigner with this feature to improve security which is a very significant thing.

This still makes SeedSigner usage a lot more secure than a traditional HotWallet by not having it to ever connect to the Internet and completely offline.

[ffrediani]

Optionally as mentioned above one alternative to the encrypted file is to have a small LUKS encrypted partition with passphrase which would use well know technology and open-source software available.

[jdlcdl]

Just a note that supporting and challenging opinions were shared in the telegram community group today.

[ffrediani]

@jdlcdl thanks for the update. Would you mind replicate the main points here as this is probably the most appropriate tool to achieve this improvement so everybody following can be aware and contribute ?

[ffrediani]

@jdlcdl can you share the details please ?

[jdlcdl]

@jdlcdl can you share the details please ?

The reason I don't cut and paste directly from the telegram group is that it's for those users to do themselves. I hint to those members to share it in github if they so choose, so that it's easier to find and work on as a developer. But if they don't decide to do that, then I only leave a pointer for those here who are willing to go find it in telegram... and I usually give a fair time frame.

That there were discussions around this topic on May 22nd in telegram is all that I want to share, and everyone is welcome in telegram to see what that discussion was about. The group link is: https://t.me/joinchat/GHNuc_nhNQjLPWsS

[ffrediani]

Hi @jdlcdl
What a pity, because the proper discussions for product/project improvements should happen here or be brought here for everybodys consideration. Telegram is a more lazy and precarious tool where details are easily lost or forgotten. Thats for informal chat and not for proper development.

If they don't decide to do you could do yourself. What matters the most are that the ideas and possible solutions to be brought for discussion in this appropriate tool and be implemented if they make sense. You can even ask if you can do on their behalf or if they wish credit for it or not, but the most import is to share with community and have an ideal solution for this feature request that is very needed.