| ▲ | cherryteastain a day ago | ||||||||||||||||||||||||||||||||||
Easier solution: phone wipes itself if passcode is not entered every X hours | |||||||||||||||||||||||||||||||||||
| ▲ | Andromxda 13 hours ago | parent | next [-] | ||||||||||||||||||||||||||||||||||
GrapheneOS already has an auto-reboot feature that can be set to time intervals ranging from 10 minutes to 72 hours. Rebooting puts the device back in before first unlock (BFU) state. This wipes all memory contents, including the encryption keys. Any unlock attempt will have to go through the secure element, which is basically impossible to tamper with (no successful attacks on the Titan M2 so far, or the Apple SEP for that matter), and includes substantial security mechanisms, such as throttling key derivations (through the Weaver API), or insider attack resistance (requiring user authentication before new firmware can be flashed to the secure element). Leaked documents from mobile forensics companies, such as Cellebrite or XRY confirm this. It's impossible to crack a Pixel with GrapheneOS in BFU state. See https://grapheneos.social/@GrapheneOS/112462758257739953 and https://grapheneos.social/@GrapheneOS/112826067364945164 | |||||||||||||||||||||||||||||||||||
| ▲ | ragall 5 hours ago | parent | prev | next [-] | ||||||||||||||||||||||||||||||||||
There's a problem with that too: it would often force the owner of the phone to input the code when outside a secure environment, so a simple video surveillance could obtain the code. | |||||||||||||||||||||||||||||||||||
| |||||||||||||||||||||||||||||||||||
| ▲ | atoav a day ago | parent | prev [-] | ||||||||||||||||||||||||||||||||||
Deadmans-switch, nice. I always had a weird fascination for that kind of mechanism, because it inverts the whole situation. Where before you have to actively wipe a phone, now them taking your phone may be the mechanism that triggers the wipe. | |||||||||||||||||||||||||||||||||||
| |||||||||||||||||||||||||||||||||||