What backup / key management schemes should we support?

[danielnordh]

Given the Daily Wallet use case, what backup / key management schemes should we support?

The assumption here is that it's a mobile-only product, amounts held are likely to be on the lower end (less than one months salary), so focus should be on providing a secure, but not cumbersome scheme. It may make sense to put more weight on protecting the user against self inflicted 'loss of wallet', but also 'remote theft'. (see bitcoin backups)

Main ways to 'loss of wallet'

• Phone lost or stolen
• Phone destroyed
• Phone reset / wiped
• Upgrade / bought new phone
• User forgets where backup is stored
• User forgets access details to backup location (PIN, password etc)

Main ways to 'remote theft'

• 3rd party theft from cloud provider
• Inside job / theft at cloud provider
• Remote access to user device
• Interception of traffic from device to network

Cloud backup (and maybe manual paper) seems to be the logical scheme here, but there are many nuances within that category. For now, this project is iOS only so will focus on the technical options we have available on that platform and what they protect against:

• Device Keychain (encrypted by Apple)
• iCloud Keychain (cloud backup enabled, encrypted by Apple, works if user has iCloud Keychain turned on)
• iCloud Keychain + extra encryption
  • Per app encryption key (downside: developer will know)
  • Per user encryption key (downside: CKContainer.fetchUserRecordID only works if user has iCloud enabled, fileManager.ubiquityIdentityToken doesn't seem 100% stable if user restore's device, changes account values)
  • Photon library (per-user key which is encrypted and stored on separate backup server, downsides: developer needs to run server, user needs to remember PIN)
• Manual backup

Current preference, with some thoughts

iCloud Keychain + extra encryption with per-user key This gives excellent protection to loss of wallet, and good protection against remote theft. A bad actor would need to have access not just to the iCloud data but also the encryption key, which they can only get by being logged in on the user's device with the application running with the correct app identifier. Edgecase where user starts with iCloud off (where this scheme is not enabled), then enables it later. Can detect and 'upgrade' to the user token when available.

When writing the code, I can/could enable the developer to define their own choice where it provides material differences:

• Automatic - no user action required
  • iCloud Keychain + per user key
  • iCloud Keychain + per app key
  • iCloud Keychain, built in encryption only
• Hybrid - some user action required
  • Photon - user has to remember PIN, developer run key server
• Manual - user action required
  • Device Keychain - user has to manually save recovery-phrase (may be less relevant when adding lightning backup requirements)

Thoughts and critique welcome, what is right for the Daily Wallet use case?

[sbddesign]

iCloud Keychain + extra encryption with per-user key This gives excellent protection to loss of wallet, and good protection against remote theft. A bad actor would need to have access not just to the iCloud data but also the encryption key, which they can only get by being logged in on the user's device with the application running with the correct app identifier.

This sounds very nice. Would this make it difficult to migrate to a new device if the user loses this device?

I'm a fan of this mobile key backup scheme. (Read from "Secure cloud backup" all the way through "The Security model" section).

The basic gist is like so:

1. Seed phrase generated on user device
2. Encryption key generated on user device
3. Seedphrase is encrypted and sent to iCloud
4. Encryption key is sent to developer's server. Developer server encrypts it again and takes good security precautions.
5. User has an email/password login with the developer's company.
6. In the event the private key needs to be recovered, user logs in to the app again (with the email password). Seedphrase is pulled from their iCloud account and decrypted with the encryption key pulled down from the developer's server.

I think that's nice because an attacker has to gain access to your iCloud account and your account with the developer.

Ok, so what if they compromise the email tied to your iCloud account and then initiate a password reset with the developer? Sure, that's an issue, but could be mitigated by having some sort of waiting period on the developer's end...like, we won't provide the encryption key for 7 days after a password reset.

With many lightning wallets needing to operate as some sort of LSP for their business, doesn't seem unreasonable to also provide a key server.

[moneyball]

A resource in case you weren't aware: https://github.com/photon-sdk/photon-lib/blob/master/threat-model.md

[danielnordh]

iCloud Keychain + extra encryption with per-user key This gives excellent protection to loss of wallet, and good protection against remote theft. A bad actor would need to have access not just to the iCloud data but also the encryption key, which they can only get by being logged in on the user's device with the application running with the correct app identifier.

This sounds very nice. Would this make it difficult to migrate to a new device if the user loses this device?

No it should make that much EASIER. As long as they are logged in to the same Apple account, they will be able to recover automatically. I have good experiences with this when using a 'per-app' encryption key. One condition with this approach is that the user needs to be using iCloud with their account (if not no iCloud interactions are possible for any apps of course). The part I don't have experience with is the unique per-user token. But from my research it seems that the CKContainer.fetchUserRecordID is 100% stable as long as they are signed in to the same account.

I'm a fan of this mobile key backup scheme. (Read from "Secure cloud backup" all the way through "The Security model" section).

It seems good, and something I might add as an option down the line. I am trying to reduce dependencies and any user actions to achieve the automatic recovery. In this case: Developer needs to run servers and store user data, user needs yet another account/password. But yes, having the encryption key stored somewhere else does add protection against bad-actors. For a daily wallet I wonder if it's not overkill though.

[danielnordh]

A resource in case you weren't aware: https://github.com/photon-sdk/photon-lib/blob/master/threat-model.md

Thank you. I think I had seen it last year but forgotten. It's a good overview and summary.

The scheme I have outlined above provides all the same protections as Photon, EXCEPT: If a bad actor has access to the user's phone UNLOCKED.

In this case Photon protects by requiring the PIN. The PIN can be reset, and since the bad actor has full access to the phone they can access email and text messages. Photon can protect against this with a 30 day time lock for PIN resets.

This is very comprehensive with Photon, and I think makes sense for higher amounts, savings account or similar. My thinking for passing on it for the Daily Wallet, for now:

• User has to set a PIN, and remember it every time they use the app, if they forget it, they can't use the app for 30 days (or however long you want the time lock)
• If a bad actor has the phone AND ability to unlock it, they either have the owner under duress and can unlock with biometric, or the user has not enabled biometrics for phone access (but the app developer can require it, preventing an unprotected user from starting to use it in the first place)

So the only case where my suggestion does not provide the same protection as Photon is when the user is UNDER DURESS. So it comes down to: will the user have the nerve to not disclose their PIN to the bad actor?

For a Daily Wallet I think it's a reasonable tradeoff compared with the avoided friction for all other cases of potential wallet loss.

[danielnordh]

Since automatic cloud backup depends on the user being signed in to an iCloud enabled account, what should we do in case they are not?:

• Do not allow them to create a wallet at all (safest)
• Create a wallet that is locally stored only, with a per-app encryption key. If user enables iCloud later, migrate key to per-user encryption key (less obnoxious, but inherently unsafe)

Leaning towards the first option for now, and maybe work out the second later.

Downside with using CloudKit to get the unique ID is that it requires a paid developer account (as it creates an app-specific CloudKit Container). Note to self: Checking for entitlements is not available out of the box. Found this library but for some reason I'm not able to access UIApplication.

[sbddesign]

Leaning towards the first option for now, and maybe work out the second later.

Seems reasonable

[moneyball]

Someone just told me that when they upgraded phones they completely lost their iCloud backup due to some bizarre Apple issue. I wonder how frequently this occurs and whether or not cloud backups from Photon or otherwise need to address this to be more resilient.

[danielnordh]

It's somewhat opaque, and a developer can not check if the user has iCloud Keychain available either. Need to do more research on the edge cases.

[danielnordh]

New thought:

The old NSUbiquitousKeyValueStore seems to be available to all users regardless if they have iCloud Drive enabled or not.

One could

• Generate unique per user encryption key on user device
• Use that to encrypt what gets stored and backed up in iCloud Keychain
• Store the encryption key in NSUbiquitousKeyValueStore

This would be better than a per app encryption key as it would reduce risk for each user, although it does add another dependency.