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).