GrapheneOS protections against data extraction from locked devices

Also worth mentioning that you can set auto-reboot to a shorter period (down to 10 minutes). So if you anticipate situations where your phone can be seized (border crossings, demonstrations), it's worth temporarily setting this to a short time period (or rebooting your phone yourself to get to BFU).

(The Computer Weekly item was submitted but saw no significant discussion.)

We plan to entirely overhaul the backup system but it already works fine. It could be a lot simpler and cleaner both in terms of implementation and user experience. We're in the process of overhauling the other apps first but we'll get to it.

https://grapheneos.org/features#encrypted-backups

https://github.com/GrapheneOS/os-issue-tracker/issues/4687#i...

Ideally this should also work on lock screen, e.g. if you type in a non-standard PIN, it would boot from the "dummy" partition in the background, with a slight delay perhaps.

This way you don't have backup anything (I mean you should, but for normal purposes) and have a plausible deniability whenever you get randomly inspected, not just at border crossings that you anticipate.

I always dread the possibility of my GrapheneOS phone being damaged or stolen and having to spend hours reinstalling and reconfiguring everything that Seedvault missed, as well as losing access to accounts that are locked by the secure element keys.

Is that likely to happen at all in a civilized (Western) country?

GrapheneOS adds the option to set a 2nd factor PIN for fingerprint unlock to make using a strong passphrase convenient without the downsides of biometric-only unlock.

Pattern lock strongly encouraging using only a tiny subset of the possibilities so it's much worse than your analysis shows. It was removed from GrapheneOS years ago because it's far worse than simply generating and using a random 6 digit PIN despite appearing to be similar. It gives a false sense of security and we didn't want to add support for a duress pattern or random pattern generating alongside those planned features. Built-in random PIN and passphrase generation is still in progress but has been started and will be shipped.

Pattern lock isn't exposed to the user afaik because it's insecure.

>I wonder why don't they just allow for longer passwords

They allow up to 128 digit passwords which they changed from AOSP.

I use a long passphrase for primary unlock and it's convenient because you only enter it when you restart.

If you rely on the secure element than 6 digits is fine. A long passphrase ensures you're protected even if the secure element is exploited.

It's theorerically possible to use side channel attacks against the security chip to bypass this, of course, but that requires opening the device and some very precise, damaging operations, assuming the attacker has a known-working side channel attack in the first place.

Our duress PIN/password feature doesn't pretend that it can stealthily wipe the device. It properly implements what people expect it to do and does it safely. It isn't our role to choose how to use the feature including how to use it in a situation where there are potential consequences to it. We haven't implemented any features which are in any way specific to situations involving law enforcement. We aren't going to give people any legal advice on how to handle situations involving law enforcement. It isn't our role and does not make sense particularly since laws vary so much based on jurisdiction, context and how they're interpreted on a case-by-case basis. If people want legal advice, they should ask a lawyer for it.

It's not possible to provide anything close to plausible deniability for wiping profiles. A deleted profile leaves behind metadata proving it existed in the device encrypted and Owner profile encrypted storage. There are a whole bunch of different ways it can be shown that it existed. ADB can be easily used to identify a wipe occurred and when it occurred. The standard approach used by forensic tools is connecting via ADB and they can easily add support for detecting this. It would be easy for non-experts to figure out how to do it especially with the guidance of a decent LLM. It would put users at risk who believe they can perform a stealthy wipe despite it not being possible. We do not want to provide a feature which cannot come close to working properly.

Android's Private Space has a half-baked feature for hiding that the Private Space is enabled in the user interface for someone without access to the relevant unlock methods or ADB. There are multiple publicly known ways to identify a Private Space is enabled. These aren't treated as significant security vulnerabilities and fixes for it aren't backported to older releases. It isn't practical to cover all possible ways of detecting it even with the limited scope of only attempting to hide it in the user interface and not ADB. We don't plan to remove the feature but don't think it should have been implemented and wouldn't have done it ourselves.

If we implemented a half-baked deniable wiping feature then the flaws would be discussed in this forum, our issue tracker and elsewhere on the internet. It would quickly become known to LLM models, which would be able to assist with detecting it. It would be incorporated into standard forensic tools and guides. This is not an approach we want to take with GrapheneOS.

Our features need to work against adversaries aware those features exist. An adversary aware of the duress PIN/password existing doesn't have a way to tell it apart from a real PIN/password. They'll have to consider if a PIN/password provided to them could be a duress PIN/password even for users who don't use the feature. The feature is now going to be widely known about due to the news coverage and it's still going to work.

On future devices, we want to add duress PIN/password support to the secure element as part of the Weaver rate limiting so it can't even be bypassed with an OS exploit.

Perhaps the solution is that some apps and data is in a locked area that would require a further pin once the device is unlocked.

So the duress pin unlocks the device but wipes that region.

It then appears that the secure or locked part was never setup.

I think many OSs offer Locked data options, Google Photos, Samsung etc.

But installing a third-party OS? That's weird. Weird enough to exoticize and marginalize.

https://news.ycombinator.com/item?id=49038982

Not from someone employed by the project but a frequent contributor.

18 hours was chosen to avoid ever triggering for people who use their phone a couple times a day. For most people, it only needs to be a bit longer than their maximum sleep time to avoid triggering in practice. It's mostly fine if it reboots during the night anyway but people may miss an urgent non-carrier call, etc.

Cellebrite's documentation on Cellebrite Premium capabilities is repeatedly leaked. As of a couple months ago, it still shows they lack exploits for locked GrapheneOS devices updated past a certain 2022 patch level.

Although, based on the latest Cellubrite leaks, GrapheneOS can't be exploited in AFU either.

There's also the reboot timer which brings the device to a BFU state. GrapheneOS implemented it and then Google and apple implemented their own version with fixed timers. GrapheneOS's is configurable down to 10 minutes, the default is 18 hours. On iPhones and Androids it's fixed at 72 hours.

One thing I wish they had in GrapheneOS was a faster shortcut to shutdown. Afaik currently you need to press physical button and then confirm on screen.

The point is to at least make them resort to hitting you with the $5 wrench, at which point they're probably committing a more serious offence than what you're up for (dependent on country).

  According to The Guardian, the US Department of Justice is prosecuting Atlanta resident Samuel Tunick after he allegedly gave a GrapheneOS duress PIN while border agents were trying to search his Google Pixel phone.

Many files will have been copied around and modified leaving traces of those around on the SSD. It's possible to ask the SSD to securely erase a span of data but it's far too late to do that after using files in regular ways for a long time. The data would often be recoverable. It would also be obvious that it happened based on lots of metadata showing those apps were clearly installed. Lack of metadata and statistics which should be there is evidence too.

It's possible to make a feature with which runs in reserved storage space where every encryption passphrase is valid and produces garbage output if the feature wasn't set up or the passphrase isn't correct. That's definitely possible. It's only realistic to make it work properly with a VM and the space for this would need to be reserved for everyone by default with the option to remove it to free it for other uses to make it properly deniable. It's still likely possible to prove it's being used via low-level analysis of the SSD.

B-but I did it many times? Or do you mean that it's impossible to refuse providing the decryption key and still pass? That's pretty obvious.

GrapheneOS adds support for a strong passphrase to avoid depending on the secure element. It also adds the option to set a 2nd factor PIN for fingerprint unlock to make using a strong passphrase convenient via fingerprint+PIN secondary unlock while in After First Unlock state. Only 5 fingerprint unlock attempts are permitting and an incorrect 2nd factor PIN counts towards it so it's hardly a making the device protection weaker. Our PIN scrambling and the duress PIN features can also both be used with the 2nd factor PIN.