Understanding Blue Wallet Encryption

[i5hi]

Hey I just wanted to open this issue to get an understanding of how Blue wallet does encryption at rest.

I have commented on this old issue: #201

[Overtorment]

can you ask more specific question?

[i5hi]

so as I understand mobile wallet security, apps get access to a limited secure storage space. Wallets can either store the actually private key here OR store a really strong encryption key, and use that to encrypt app data at rest.

usually a really strong cryptographically secure key can be generated when the app is first installed and this key will be used to encrypt all app data. This key is retained on the device as long as the app is not reinstalled. so if an malicious app (for example file manager with extended permissions) take a snapshot of the file system, they will need to access secure storage and get the strong key from there too - which is not easy but I suppose also not impossible if one has root access - in case a phone gets lost.

I read briefly through

BlueWallet/class/app-storage.js

Line 93 in 8636919

async storageIsEncrypted() {

FWIU Blue wallet makes a user set a key from a (weak) password/pin and stores this in secure storage to use for app data encryption. So if a malicious apps dumps app data, they could brute force relatively easily.

So the threat model I am seeing is that, the password as the only encryption key - not being on the device is good BUT since its weak it can be brute forced easily.
By using a local key stored in SS as the encryption key, although its on the device, it is hard to access by other malicious programs and the only possible attack is root access and even that takes a lot of expertise to extract. In case an attacker is successful, the added password encryption will at best buy a little more time.

[Overtorment]

youre more or less correct. encryption password is supplied by user, and if its weak - encrypted data blob is bruteforceable. plus there is no enforcement on complexity of that password. so if user wants to shoot himself in the foot he totally can.

[i5hi]

This example is in flutter. encryptionKey is only null when the app is first installed. Once it is set, it will not change as long as the user goes not reinstall/uninstall the app. In such case, they will have to reimport their seed.

  const secureStorage = FlutterSecureStorage();
  final encryprionKey = await secureStorage.read(key: 'key');
  if (encryprionKey == null) {
    final key = Hive.generateSecureKey(); // this has to be a strong key generator
    await secureStorage.write(
      key: 'key',
      value: base64UrlEncode(key),
    );
  }
  final key = await secureStorage.read(key: 'key');
  final encryptionKey = base64Url.decode(key!);

  await Hive.openBox<Wallet>(
    StoreKeys.Wallet.name,
    encryptionCipher: HiveAesCipher(encryptionKey),
  );

Does Blue Wallet already do something to this effect?

Is there any case where a user generated encrypted key is more preferable to something like this?

If so, can they be combined? Concat strong key + user chosen key and hash to get the final encryption key?

[Overtorment]

BW was designed for ios where apps have pretty good sandboxing, so threat model only included rooted devices that can leak both encrypted blob and secure keystore. in that scenarion, user's password will always be bruteforceable (unless there is enforcement on password complexity)

[i5hi]

Is there ever a case where BW app data is NOT encrypted?

If I don't choose a password, is a random secure key generated for me by default?

[Overtorment]

1. if unencrypted by user password its still stored in keychain/keystore, which apple/google claims is secure
2. data backup is saved to realm database encrypted, encryption password is stored in keychain/keystore, and is genegated by secure randombytes

PS. realm backup is only used for weird rare cases of keystore losing data. this needs refactoring, either number 1 or number 2 must go

[i5hi]

awesome, thanks for clarifying!