Document key management / saving options on mobile

[danielnordh]

Any new developer creating a bitcoin wallet will want to know best practices for storing the private key information for users.

Should include

• all available options (let the dev decide depending on use case)
• technical details where possible (at least clear enough to understand what needs doing)

What should be saved?

To easily handle both daily usage and backup scenarios, save the following:

Onchain

• Mnemonic (will enable restore in another wallet)
• Descriptor (use directly when opening the wallet)
• ? (User readable derivation path details or other 'good to know' things?)

Lightning (additional)

• Channel state
• Key (although better if derived from onchain?)
• ?

Encryption options

As we'll see, adding a layer of encryption (other than default OS encryption) is almost always recommended. Should explain both what algorithm (AES-GCM ?), and what options for picking the key is available.

• Keys requiring users to remember something
  • User chosen password or PIN
• Keys that don't require users to remember
  • Random individual key generated on device on first install, stored in keychain (user needs to import from mnemonic to use on another device)
  • App wide key
  • Individual key derived from stable (publicly unknown) user identifier
  • ? Note that storing the key itself also has security implications as many of the options could also potentially be accessed or broken into. The alternative is the Secure Enclave on iOS, Secure Storage on Android where a key can be generated and used, but not be visible from the outside or shared.

Storage options

1. Save as file in app data directory Not recommended - By storing the data as a text or binary file in the application's data directory you have access to it directly, it is however not very secure from a bad actor.

2. Save as encrypted file in app directory By adding your own additional encryption to the data you can potentially mitigate the risk of a bad actor getting their hands on the private keys. This can include other risks and complexity for the user, see the encryption section.

3. Save in user preferences

4. Save in device keychain

5. Save encrypted in device keychain

6. Save encrypted to user's cloud container (iCloud, Google Drive, will only work if enabled)

7. Use decoupled client / server model, i.e. Photon

Questions to answer for each option

• Where is the data stored locally?
• What happens to this data if the app is deleted?
• Is this data included in device wide backups?
• Will this data be present on a new device if the user installs the app again?

OS Device backups

Android

• Google Drive - All app data is backed up if device backups are enabled, they are encrypted and secured by your Google account password, If device is not used for 57 days, the data is deleted
• Google One - App app data is backed up if enabled (separate from Google Drive) iOS
• If iCloud is enabled by user, complete device including app data is backed up
• User can manually backup to a computer, app data will be backed up

OS Individual app backups

Android

• AutoBackup is enabled by default, app developer can opt out
• Saves app data, saved preferences (up to 25mb) in user's Google Drive
• Is supposed to be downloaded if user re-installs app after deletion (I have not had success with this) iOS
• If iCloud is enabled by the user, app data will be backed up automatically
• If iCloud Drive is enabled, app data will be backed up and synced to other devices the user is logged into
• If iCloud Drive is enabled, CloudKit may be used for storage and syncing

Android specific nuggets

• How to ask user if they want to keep app data when deleting app

iOS

• Previous thoughts on iOS only schemes https://github.com/bdgwallet/dailywallet/issues/2

Protect against

Self inflicted

• User deleted app -> Keychain on iOS, Android ? (in theory it should back up if enabled, but not had success)
• Device got wiped -> cloud backup
• User lost device -> cloud backup
• Lost access to cloud account -> Manual offline backup Bad actor
• Got access to device -> Biometrics, Keychain/EncryptedSharedPreferences
• Got access to cloud account details -> Two factor, PIN encryption on cloud backup

[danielnordh]

Bluewallet encryption strategy

[danielnordh]

Different UX goals / threat levels Self inflicted vs bad actor risk

Scenarios - Self inflicted

• User deleted app (iOS keychain / Android?)
• User lost device (iCloud Keychain or iCloud Drive / Google Drive - if available)
• User lost their device plus access to iCloud / Google account (offline backup of recovery phrase)

Scenarios - Bad actor

• Gained access to locked device (biometrics, per user encryption key)
• Gained access to unlocked device (app biometrics, per user encryption key)
• Gained access to OS account login (additional encryption of key data)
• Gained access to app source code (per user encrypted key)
• Gained access to cloud storage data / device backup (per user encrypted data)
• Gained access to encrypted private key data (per user / user-chosen encrypted data)
• Gained access to recovery phrase (passphrase stored elsewhere)

Different Goals

• Max self inflicted protection - User can lose device, recover on another without remembering anything
• Medium easy - Slightly less convenient, slightly more secure
• Medium hard - Slightly less secure, slightly more convenient
• Max bad actor protection - User-chosen password required on each launch
• etc.

[moneyball]

"ideally the HSM has the ECC firmware, BIP32 knowledge etc. to sign. even a LN state machine to securely sign LN transactions. then the key doesn't need to move to main memory."

[danielnordh]

"ideally the HSM has the ECC firmware, BIP32 knowledge etc. to sign. even a LN state machine to securely sign LN transactions. then the key doesn't need to move to main memory."

Creating and using the key in an HSM would be great, and fall into the 'max bad actor protection' category. I'm not sure BDK (or LDK) currently supports this in any practical way though, plus you are left without the opportunity to save or backup the key outside the device at all. Might be more practical for multisig wallets where keys can be replaced?

How could this be made practical?

• BDK somehow support creating mnemonics/private keys and signing inside the HSM

[moneyball]

@danielnordh phone manufacturers will need to improve their firmware

[danielnordh]

iOS jailbreak status

• No known jailbreaks for iOS 15.5+ on iPhone XR/XS and higher (A12 chips or higher)
• iOS 16.2 and lower can be jailbroken on iPhone X/8 and lower (A11 chips)
• Keychain not known to have been accessed on non-jailbroken devices, nor via iCloud