Duress PIN/Password to wipe specific secondary profiles or Private Spaces

[Ganwtrs]

Relates to #3598, but this wouldn't be deniable

[Evaexe117]

Selective profile wipe is more deniable than a full wipe, not less

Re: the note that a per-profile duress wipe "wouldn't be deniable". For the coercion / border-search threat model this seems backwards, because a fully wiped device is itself the red flag.

Threat model. A user keeps a normal everyday profile (messaging, photos, social apps, a real lived-in history) and a second profile with sensitive material (source and fixer contacts, an editor). Under coercion they are forced to unlock. Handing over a factory-blank phone screams "I wiped something", since nobody travels with an empty device. Handing over a normal, used phone where only the hidden profile has silently vanished is far less suspicious.

There are two distinct notions of deniability here:

1. Situational (at the moment of coerced unlock): a lived-in device is strictly more plausible than a blank one. Selective wipe wins clearly.
2. Forensic (post-seizure lab): can an examiner prove a second profile existed and was destroyed?

The forensic objection only holds for a naive implementation. Destroying the profile's keys handles content confidentiality, but the evidence of existence lives at the system level (userlist.xml, /data/system/users/N, package-manager per-user records), which is encrypted under the owner/system key, not the wiped profile's key, so it survives a key-only wipe. That, and only that, is what would let a lab upgrade "he wiped something" to "he had a hidden compartment".

Proposed mechanism.

• Reuse the existing duress detection path unchanged. Today DuressPasswordHelper.isDuressCredential() calls DuressWipe.run(), which calls RecoverySystemService.deleteSecrets() / AndroidKeyStoreMaintenance.deleteAllKeys() (global). The detection already fires anywhere a device credential is requested, which is exactly the reach that is wanted, and it needs no change.
• Add a per-profile duress credential, stored in the owner duress config so it is checked at the same "anywhere" point. On match, instead of the global wipe, destroy the target user's key material and remove its system-level user record (userlist.xml, /data/system/users/N, package-manager entries, relevant logs).

Open question on the scoped key destruction. The global path relies on deleteAllKeys(), which is atomic and wipes everything. Is there a per-user equivalent that can run from the credential-verification context, destroying a single secondary user's storage keys (its KeyMint keys / Weaver slot / synthetic-password blob) as irreversibly as the global call? This is the crux of feasibility, and I would rather raise it directly than assume a clean primitive exists.

Result.

• Content confidentiality: identical to the current duress. Keys destroyed, data cryptographically unrecoverable.
• Situational deniability: strictly better than a full wipe. The device looks normal, with a natural long-lived history instead of a fresh-setup timestamp.
• Forensic deniability: comparable to a full wipe provided the user record is scrubbed. The only residue is high-entropy blocks in unallocated space; on a fully-encrypted device (freed blocks are never zeroed) this is indistinguishable from normal free space. No "user-shaped hole" remains.

On the "fast and uninterruptible" property. It splits into two parts. Confidentiality is instant and uninterruptible: the key is destroyed in one step, exactly like the current design, so there is no slow shredding window. The metadata scrub that provides deniability is multi-step and therefore best-effort: if it is interrupted, confidentiality still holds and only deniability degrades. That trade-off seems acceptable, but it is worth flagging rather than claiming full atomicity.

Typical usage is just owner plus one secondary profile, so this can be scoped to "duress wipes the secondary profile / Private Space and returns to owner", without arbitrary per-user targeting.

Would a design along these lines, per-user key destruction plus user-record removal, triggered from the existing duress detection path, be acceptable in principle?

[thestinger]

No AI slop.