Hacker News

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

The Guardian story discussed on HN: <https://news.ycombinator.com/item?id=49024436>.

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

GrapheneOS includes an encrypted backup system covering far more data than Google cloud backups. It backs up data for apps opting out of cloud backups with allowBackup="false" since it operates in the device-to-device transfer mode. The backup system supports arbitrary sync services with a compatible API. Backups are per-profile so you can test it by restoring to a secondary user.

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.

A replacement for SeedVault is planned:

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

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

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.

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 am wary that I could be targeted at a border just for having a google pixel with grapheneOS.

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

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.

GrapheneOS supports up to 128 character passwords to support using diceware passphrases. Using a strong passphrase avoids depending on the secure element. A random 6 digit PIN is secure due to the secure element rate limiting. Only a total of 20 attempts are permitted so even a random 4 digit PIN would be fine.

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.

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

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.

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.

Of course, the same authorities angry at GrapheneOS are also angry at Apple. The main problem is that you can't call iPhone users criminals, you'd get laughed out of the room.

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

Agreed and it's not even conceptually hard.

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.

That's called a decoy password rather than a duress password, btw

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.

That email chain sounds exactly like the TV show Severance

Yes, it provides strong protection while profiles are in After First Unlock state. It automatically reboots 18 hours after locking by default so there's a time limit on having a working exploit which is highly unlikely. The timer can be set as low as 10 minutes by users.

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.

>within ~12 months, in 2027

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

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

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.

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.

Reliable deletion of data depends on wiping keys with hardware support. Android has per-profile keys meaning separate keys for each user and Private Space. It can reliably erase all of the data or specific profiles. It's important to reboot the device to wipe the RAM to get rid of leftover traces after wiping a profile or the whole device. Deleting a single profile may seem like a good approach but there's metadata outside the profile for it to function and it will be obvious it existed. It will be obvious it was deleted and when that happened. It isn't a system designed for secretly deleting a profile. A bunch of filesystem and OS data/metadata will be left showing it existed. Reliable deletion of the data within the profile does exist but not hiding that the profile itself existed and was deleted.

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.

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.

Rate limiting is implemented by a high quality secure element hardened against physical tampering. It isn't implemented by the regular SoC, RAM or the OS. It's not simple to bypass the throttling making a random 6 digit PIN secure.

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.

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.

This could be your PhD project or get you a job at the NSA. It's possible in principle but much harder than you assume. For instance, all the relevant circuitry is inside a single chip designed to be tamper-proof.

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