keepassium
Harden AppLock Guarantees
Disclaimer: One could definitely argue this is over-engineering and the status quo is just fine. I'm merely trying to kick off a discussion. :)
What can be improved? From what I understand, things currently work as follows:
- When master keys are remembered, they remain in memory for some time (I am not sure for how long). While in memory, they are encrypted by the Secure Enclave and can be read by KeePassium at any time.
- When persisted outside of memory, they are committed to Keychain as part of the database settings. The related Keychain entry can be read by KeePassium at any time.
- AppLock is basically a GUI-level protection that leverages an app-specific passcode and/or biometrics to steer the authentication flow. Neither are actually part of the "cryptographic protocol".
Thus, a bug in the app code could theoretically lead to evading AppLock with the master keys ready at hand - or at least that's my current understanding, I'm happy to stand corrected. Outside of the master key wipe feature, it feels like this is the same as if the app was merely locked behind biometrics using the stock iOS feature. Incorporating AppLock into the cryptographic protocol would make evading AppLock mostly impossible.
Rationale Basically this is my replacement for key files. Currently, I use a memorable database password, as well as a key file (as part of the "owning" factor) to strengthen the master key. Because the key file just sits on disk, at best protected by filesystem sandboxing, this is not a very pleasant setup. Ideally, I can choose a strong database password I do not need to remember (but can securely backup away from my devices, like a recovery key) and it is securely persisted by iOS and macOS outside just residing on the file system. Keychain is an upgrade, as the key is at least encrypted and somewhat protected, but I'd prefer harder guarantees on user authentication for releasing the secrets.
The solution you'd like There are two cases, the app-specific passcode and biometrics. As the former is controlled by KeePassium and the latter by the OS, the implementation would need to branch:
App Passcode I guess a separate encryption layer over both memory and Keychain data with a passcode-derived key is a viable solution. Secure Enclave-based memory protection would still help against an offline RAM dump bruteforce or such if the passcode is significantly weaker than the database master key (because I'd assume if you can leak RAM, you can leak the database file) and layering should be "cheap". Ideally, the passcode is not explicitly stored anywhere, but the derived key guards all volatile and persistent security-critical state of the app.
Biometrics
While this would work slightly differently from how AppLock works now, the Keychain items themselves could be protected via the userPresent flag to enforce Keychain authenticating the user before releasing the secrets. This would happen, in the worst case, for every secret individually. Maybe they can be merged to an extent to prevent spamming biometrics prompts? I'm not sure whether this is handled purely at OS level or whether it involves Secure Enclave each time, but ideally Apple will implement the latter eventually if they didn't already. This is not quite as "cryptographic protocol" as the passcode solution, but there needs to be some trust in Secure Enclave either way.
EDIT: Maybe it could also make sense to consider creating a userPresent private key with Secure Enclave and then encrypt the same way as with app passcode for simplicity.
Sorry, this seems to be a somewhat more general duplicate of https://github.com/keepassium/KeePassium/issues/269