Feature request: Optionally unmount secret basis on an idle timer

[markhuge]

This is analogous to a few GrapheneOS features that attempt to put lost, stolen, or seized devices into their most secure state automatically.

The closest feature in terms of impact is the GrapheneOS "auto reboot" option will automatically reboot the device if it has not been successfully unlocked after N hours. The closest in function is probably auto disabling Bluetooth after N minutes of no devices being connected.

In xous, I imagine an option to unmount a secret basis after N hours without of one/any/all of the following:

• successful pin unlock
• root password entered
• read or write to the secret basis

[bunnie]

I have a few questions about this feature and its intent.

Based on this statement:

lost, stolen, or seized devices

This feature sounds like...it would prefer to err on the side of paranoia. There is a "self destruct" feature in Precursor. Would the idea be to activate this in the case that the timeout is hit?

On a device keyed with BBRAM keys, it would make the device totally inert (unbootable, bricked, dead). On a device with eFused keys or no backup key set, it would ... make the device unbootable until someone disassembled it and reset the kill switch, or they allowed the battery to run down to zero. After which point, it would boot and return to the unlock PIN state with no secret bases mounted.

In terms of "when" to trigger such an event, I'm a little divided.

I feel like...if the device is plugged in to my PC, I kind of don't want it self-destructing, but I do like the idea that if it's unplugged and mobile in my pocket, it'll wake up in "N days" and present a PIN challenge, and if it's unsuccessful more than say 5 times, it'll destroy itself. That's probably a feature I would actually set.

However, a device just...destroying itself even if it's plugged in at my desk because I forgot to type the root password in once every day seems like a recipe for disaster for everyday users, but maybe it's the sort of thing a very paranoid user would want.

I'm trying to calibrate myself to the expectations of a user who would set this sort of thing. I...don't want to make the logic that sets this extremely complicated, with lots of options and buttons. First it's going to be hard to test that logic, second, it lends to fat-fingering and misconfiguration.

So I guess I'm trying to understand what's the type of user and use case for this. Lacking any response, I'd probably implement the version that suits my own envisioned use case, but I figure it's worth asking for feedback before just doing that.

[markhuge]

This feature sounds like...it would prefer to err on the side of paranoia. There is a "self destruct" feature in Precursor. Would the idea be to activate this in the case that the timeout is hit?

However, a device just...destroying itself even if it's plugged in at my desk because I forgot to type the root password in once every day seems like a recipe for disaster for everyday users, but maybe it's the sort of thing a very paranoid user would want.

I'm proposing an optional, non destructive operation that happens often.

It's possible I'm misunderstanding how the PDDB works and what's actually happening when bases are mounted vs unmounted. I opened this with the impression that mounted bases are in a less secure/plausibly deniable state than unmounted bases. The intent would be to optionally, automatically unmount bases after some interval to put them in a "better" state without the need for user intervention.

it'll wake up in "N days" and present a PIN challenge, and if it's unsuccessful more than say 5 times, it'll destroy itself. That's probably a feature I would actually set.

FWIW the keyboard is still really easy to fat finger. The prospect of trashing the hardware with a pocket dial is also pretty scary.

So I guess I'm trying to understand what's the type of user and use case for this.

Without knowing what user personas you guys have already, I think it depends on persona/threat model:

Non-destructive

• Traveler who routinely has to go through customs were devices may be turned over for inspection/dumping
• Keeps backups
• Probably can't afford to re-buy $500+ bricked hardware on the regular

Destructive

• High value target
• Targeted by state/corporate sponsored attackers
• Has resources for inventory of replacement devices
• Leverages some kind of SCIF or mentant instead of digital backups

[bunnie]

Got it. I think in the case for the "non-destructive" use case, the easiest and cleanest way to handle this is to actually have the system just force a reboot after some period of time. A system straight out of boot is in its most deniable, secure state, because the entire RAM is also zeroized by the bootloader (whereas simply unmounting a Basis without a reboot may leave some traces of plaintext in the heap, that can then be extracted by an adversary who has planned ahead).

One other fine point I'm trying to understand. I think you are also asking in this feature spec that the system will wake itself up if asleep to force the reboot to a locked state if it has not been interacted with for some period of time, is that correct?

[bunnie]

d3dfe9fdde78a1bf26fe43dac7e1d7b7900bd793 partially addresses this issue. One can set the option to autosleep and lock on autosleep, which will generally cause the right thing to be done.

The thing that is missing is if the user desires the system to wake itself up even if it is asleep to force itself into a clean reboot.

Wake even if asleep to lock is a bit more of a complicated feature to implement (involves configuring the RTC to self-wake) so I'd like to be clear on the use case and parameters before trying to implement that.