In regards to your first link, the quote "'It’s concerning – and sends the message that [GrapheneOS] is criminal by default,' said Christophe Boutry, a cybersecurity and surveillance expert." really is leading language. It's stating that protection is criminal and that vulnerability is law-abiding.

citing the 18-hour auto-reboot feature that returns the device to Before First Unlock (BFU) mode, where keys cannot be extracted.

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).

A replacement for SeedVault is planned:

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

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

A complete backup is solution that can be stored on my own encrypted servers and restored with a click of a button is really needed.

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.

I think more useful would be to be able to boot into another data partition with a different password, which, in turn, would hide the other "daily" partition. I believe LUKS is capable of that. The storage dump looks like a random set of data and only a valid password can find and decrypt a matching hidden partition.

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.

Remind us what happened when you do cross.

Honestly, I feel like I'd be more suspicious of someone who had little to nothing installed on their phone.

Modern Pixel phones have a TPM-like device that protects against brute-force attacks. Assuming the pattern is non-obvious, an attacker has 20 attempts before the supplementary key material is wiped and the encryption key is lost.

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.

>>To make a strong passphrase convenient to use without ruining it with biometric unlock, GrapheneOS adds an optional 2nd factor fingerprint PIN. We reduce the allowed fingerprint attempts from 20 to 5 and failure to enter the correct 2nd factor PIN counts towards it. This enables using 6-8 random diceware words as the main unlock method required in Before First Unlock and fingerprint+PIN using a short PIN for convenience. Using a valid fingerprint prompts to enter the 2nd factor PIN which is needed to complete unlocking the screen and hardware keystore.

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.

Maybe because it was mistaken. I just set my grapheneos to a 35 character password to test it and it didnt seem to have any issue.

That email chain sounds exactly like the TV show Severance

From GrapheneOS official account:

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.

>within ~12 months, in 2027

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

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

He was put on a watchlist for protesting. I don't think the OS is what caused the unconstitutional detainment.

>it was already pretty much impossible to get an encrypted device past US Customs more than 15 years ago

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.

I hate this meme.

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).

Relevant news story: https://www.androidauthority.com/grapheneos-duress-pin-us-pr...

  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.

You don’t seem to know much about modern electronics or forensics. “Probing” the “circuitry” isn’t going to get you anything. The devices supported by GrapheneOS keep their encryption secrets in tiny, sealed chips that are strongly tamper-resistant and will erase themselves if you attempt to get to the actual memory cells without specialty equipment. The only labs that can extract information from chips like this are very rare, expensive, and slow, and success still isn’t guaranteed. Plus these labs are going to have a backlog of espionage and military cases; they aren’t going to be working on some random dude’s phone unless he’s a cartel boss.

This is also relevant if you get the phone back. There could be some nasty hw modifications that could leak data out of the phone in AFU state. Hopefully people in these kinds of situations take this into account. IMO all phones and computers should be treated as unsafe to unlock after they've been seized.

I would not think it is fairly easy. The only real physical attack I can think of is to somehow to remove the delay throttles and brute force unlocking the device. This would be feasible for digits PIN, but not if you include characters. I am curious if you had something else in mind.

If it was that easy, we'd just do that to get access to our own data on these devices. The OEM unlock toggle is a much-desired feature for a reason

Not possible to be forensically safe. They aren't gonna implement a plausible deniability solution that isn't robust because it will give people a false sense of security and put them in danger.

Powering down or restarting is ideal because BFU is much more secure.

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.