Invalidate local encryption keys on new biometric enrollment (Android / iOS)
Summary:
When a user adds a new fingerprint/biometric credential to their device, Proton Pass currently allows access using the newly added biometric. To protect vault contents from device PIN compromise and rogue biometric enrollment, we propose adding an option that automatically invalidates local unlock keys when the device's biometric set changes, forcing a Master Password re-authentication.
Background & Threat Model:
Currently, if an attacker obtains a user's device PIN/passcode and registers their own fingerprint or face in the OS settings, they can seamlessly unlock the Proton Pass app using that newly added biometric. This leaves stored credentials and Passkeys vulnerable to device PIN compromise followed by rogue biometric enrollment.Technical Analysis & Current Gap:
Both Android and iOS/iPadOS provide OS-level APIs designed to mitigate this exact threat by invalidating cryptographic keys stored in KeyStore / Secure Enclave when the biometric set changes:
Android: setInvalidatedByBiometricEnrollment(true) in KeyGenParameterSpec.Builder. When enabled, adding a new fingerprint throws a KeyPermanentlyInvalidatedException upon use.
iOS / iPadOS: kSecAccessControlBiometricCurrentSet flag in Keychain services. The key becomes invalid if evaluatedPolicyDomainState changes.
Our testing confirmed that Proton Pass currently allows access even after a new fingerprint is enrolled. This indicates that the app either explicitly sets setInvalidatedByBiometricEnrollment(false) (or equivalent) or relies on biometric prompt evaluation without binding decryption directly to an invalidated key.
- Proposed Solution: We request implementing an option to bind local app authentication directly to the current biometric set:
Enforce Key Invalidation: When a new biometric is enrolled, the local key used for app unlock/decryption should be automatically invalidated by the OS.
Fallback to Master Password: When key invalidation is detected (KeyPermanentlyInvalidatedException or domain state change), force the user to re-authenticate with their Master Password to re-generate the local biometric unlock key.
Optional User Toggle (User Control): To balance security and convenience, provide a toggle setting in the app:
Option: "Require Master Password if biometrics change" (Default: ON or Optional for high-security users).
- Secondary Benefits (Security Awareness & Incident Response): Requiring a Master Password upon key invalidation also provides a critical early-warning mechanism for users:
Detection of Rogue Biometrics: If a user is suddenly prompted for their Master Password despite not adding a fingerprint themselves, they are immediately alerted to potential unauthorized access to their device settings.
Prompting Incident Response: This notification allows users to audit their registered biometrics, remove unauthorized fingerprints, and recognize that their device PIN/passcode has likely been compromised—prompting them to change their PIN immediately.
Ponta4649
shared this idea
-
s.c.
commented
Exactly... This is an issue on macOS too. If a new biometric is registered in the macOS system (e.g. new Finger registered for Touch ID), Proton Pass should automatically lock, refuse to accept Touch ID for unlock and require the Proton Pass Account password or extra password before Biometrics can be used again. The macOS Proton Pass app should utilise Keychain Key Invalidation at the Secure Enclave level to cryptographically invalidate the encryption key used to protect the Proton Pass app's local database. This uses the access control flag .biometryCurrentSet. How it should work: This flag pairs the Keychain item strictly to the biometric configuration present at the exact moment the item was saved.The result: If a new fingerprint is registered, the Secure Enclave will completely refuse to release or decrypt that Keychain item. The Proton Pass app will receive an authentication error when trying to fetch the key, naturally forcing the user back to entering their Proton Account Password or Proton Pass Extra Password (not macOS login password).
We should implement hardware and software-level controls to bind the application vault token strictly to the exact biometric compilation present at initialization:
Strict Policy Enforcement:
Force `LAContext` execution parameters to point exclusively to `.deviceOwnerAuthenticationWithBiometrics` rather than allowing general device passcodes to qualify as validation criteria.Hardware Token Invalidation:
Leverage Secure Enclave isolation during `SecAccessControlCreateWithFlags` initialization by assigning `.biometryCurrentSet` flags to stored items. This instructs the hardware to break and invalidate access tokens the moment any alterations to the host fingerprint database are registered.Proactive State Tracking:
Read and persist `context.evaluatedPolicyDomainState` signatures alongside the validation configuration. Compare this state before invoking validation to gracefully intercept altered biometric configurations, dropping authorization flows down to the primary Master Password route while providing clear explanatory UI logs to the user. -
s.c.
commented
This is super important and needs to be fixed ASAP. Also an issue on macOS too.