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

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

When your job depends on not understanding and all that.

Secondly, it is important to get as many people to use GrapheneOS as possible, including non-tech people. The more widespread it becomes, the harder it will become to paint this picture.

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.

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.

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.

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.

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.

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.

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.

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

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.

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

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

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.

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

The recent Darksword exploit should give everyone pause in asserting that iOS is secure:

https://www.malwarebytes.com/blog/mobile/2026/03/a-darksword...

I trust iOS with my banking and financial apps in a way that I would never trust Google, but I am under no illusion that any architecture can be completely secure.

On the Linux side, I have found SELinux maddening at times in forcing me to the syslog to enable and permit what I need the machine to do.

I have never seen anything this obstreperous in a BSD, but perhaps I have not looked with sufficient depth.

In any case, the Trust / SELinux / Enforcing status is a sizable advantage against iOS.

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.

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

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

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.

  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.

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.

> It backs up data for apps opting out of cloud backups with allowBackup="false"

This is untrue for older apps targeting API 30 (Android 11) and earlier. As I understand it, allowBackup is still respected for them, preventing their backup even in D2D mode. https://github.com/GrapheneOS/os-issue-tracker/issues/1112#i...

Those apps are slowly going extinct since the Play Store stopped accepting updates written against the older SDK in 2022, but I gather there are still a few floating around out there (including some niche favorites that have unfortunately abandoned development).

And one wish:

I'd love the ability to maintain a "hotspare" device that's identical to the original in every important way. So if your phone is chucked in the ocean, dropped down a cliff, etc. you can just grab the other one (checkpointed from a few hours or a day ago) and seamlessly keep on going.

I think this is impossible today because of the way the system protects secrets in the Android Keystore and how it's intertwined with the TEE / secure element / Titan M2 / etc. I wish there were a way to truly own my phone including the ability to perform perfect-fidelity backup and restore.

Sure I know there are more urgent priorities but at the moment there is no backup for GOS phones. It only works for some people in some situations. For me it never reliably worked, ever.

my comment was about the decision of that person who deleted the comment to go for the pattern lock, while/because? 16 chars was supposedly bad for the password (although he/she has a point in that the limitation is annoying and counterproductive)

all of this i reckon was not criticism of GrapheneOS but stock Android, AFAIK grapheneOS's choices are all very sound

If the regime is going to just start taking people then nothing will stop that, but the goal is to stop the usefulness of this sort of thing as an intimidation measure - or at least drag it to the forefront and overthrow the regime.

Booting into a 30 GB partition on a 128GB phone is going to be mega suspicious, even if the remaining data is random.

So basically one needs a webdav server somewhere or an usb flash drive.

https://veracrypt.io/en/Wear-Leveling.html

> Seedvault which was originally written for use in GrapheneOS by a GrapheneOS user is a consequence of the 2018 takeover attempt on the project, which the people currently in defacto control of Seedvault were heavily involved in.

Seedvault is currently maintained by the CalyxOS team but I've never heard about this stuff. Does anybody know what happened?

Not having the data in the first place in some specific contexts (like crossing borders) is easier.

Before travel back up the real contents and restore a dummy travel backup with random games, stock photos etc. Then restore back to real contents.

You don't avoid scrutiny by being wierd and hiding things, but by hiding in plain sight by being ultra boring.

Depending on his settings.

You can disable the usb port entirely if you like, so that it is only possible to charge the device by switching it off. Or enable charging only when unlocked etc.

Or if his device had rebooted I don't think it would be possible to extract anything.

There's no use in taking an image of the SSD and restoring it after a wipe. Data needed to derive the key encryption keys was wiped from the secure element. Separately from that, there's also additional data on the SSD needed to derive the key encryption keys which the TEE hardware will no longer consider valid.

Entering the duress PIN/password does the following:

* wipes TEE hardware keystore * wipes secure element hardware keystore * wipes the secure element other than Factory Reset Protection data which isn't used by GrapheneOS at this time * wipes the encryption metadata on the SSD with special wiping commands

The secure element data is inside the secure element's internal storage. TEE keystore keys are normally stored encrypted on the SSD with a hardware-based anti-rollback storage system to prevent reusing deleted keys. The secure element keystore is a lot more secure.

The most important data that's wiped is the Weaver table on the secure element. Weaver is the secure element rate limiting feature we describe in our post. It's implemented by the OS passing a dedicated hash of the initial key derived from the user's PIN/password. If it's the valid hash, the secure element provides a token needed alongside the initial derived key for the final key derivation. If it's not valid, it's a failed attempt wasting one of 20 attempts and triggering a hardware enforced delay.

It also isn't possible to simply image the SSD and then try to brute force the PIN/password due to the secure element rate limiting and the final key derivation done in the TEE.

It isn't the same as a typical disk encryption approach on a desktop, although GrapheneOS supports using a strong passphrase to avoid depending on the secure element rate limiting. GrapheneOS makes it convenient to use one via 2-factor fingerprint+PIN secondary unlock in After First Unlock state. It's the same as regular fingerprint unlock but with a PIN needed to complete it where incorrect ones count towards the limit of 5 attempts (reduced from 20 by GrapheneOS).

I carry a burner phone when travelling most of the time anyway. It has access to email only, 99% of which is in offline folders anyway.

That is diametrically opposed to their interests in data collection.

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'd have what appears to be a 128GB image (or some large fraction of that), which in reality is largely holes (typically: repeated blocks of ASCII 00 bytes).

Of course, you'd need to avoid actually trying to fill that filesystem.

The duress password does not wipe the phone. It wipes the encryption keys from the secure element. The phone's storage is the backup, but it is worthless, unless law enforcement has an attack against AES that does not require a brute force attack (unlikely).

Delete the contact book? Clear calendars?

Where exactly should one stop?

In a perfect society, your point makes sense, but I don't see why the authorities in the real world would need to care about committing a worse crime.

And as for street thugs, sure it won't be a wrench, more likely they'll flash a knife and unkindly suggest you remove the lock screen

Taken as a metaphor rather than a literal wrench, you don't think it's accurate?

The headline of that article ("US government targets Cop City protester over phone operating system") rests firmly in the lies category of clickbait.

They were targeted for secondary inspection upon their return to the US because they were on a terrorist watchlist, not because they have a phone that runs GrapheneOS.

At least some of what investigators did during that inspection seems likely to be illegal (and the courts will decide if it was, or was not). Meanwhile, the grounds for being on a watchlist to begin with seem dubious at best, as is often the case with such lists.

But none of this was instigated by the presence of GrapheneOS on their phone.

GrapheneOS didn't enter the picture until the person who was already detained and being investigated (and being refused access to a lawyer) provided the phone's duress PIN to nuke the device (by erasing the crypto keys and rebooting) instead of the normal PIN.

This could be preferable to handing over private data about contacts, communications, sources, client information, etc. Especially if it has life-changing implications for yourself or other people!

The secure element comes from the same company making the main processor for both the upcoming Motorola devices (Qualcomm) and Pixels (Google). Why would they put a backdoor in the isolated secure element rather than the CPU? The backdoor argument can be made about any hardware.

A key is derived from the PIN or password and used for multiple purposes by using separate statically keyed hashes. One of those purposes is obtaining a token from the secure element to implement rate limiting and extremely reliable erasure of all the encrypted data for the profile. It's also passed alongside the obtained token into the final key derivation process. Why would you want to remove the secure element integration? That would mean losing the rate limiting with no benefit and solely relying on erasing key derivation material stored on the SSD for wiping data. That would still work due to hardware support for it but the SSD isn't nearly as reliable as the secure element and can be copied at a hardware level before trying any PIN/password.

We want more secure element features including duress PIN/password support as part of the rate limiting.

In the wrench attack you are aware that you have been attacked, and you're aware of what data the attacker gains.

Additionally there are schemes like deniable encryption which can mitigate the outcomes of such an attack or serve as a red herring.

Furthermore it's dependent on physical intimidation which is expensive to scale and can be met with your own physical intimidation. In order for a wrench attack to scale to an entire society you have to send the gestapo to everyone's house whereas push-button attacks scale by default unbenownst to the victims and enable more nefarious systems to be built on top of them. In the USA this would mean interrogating some well armed citizens.

Lastly, you aren't forced to give up the key by any means. They can torture you to death and there is nothing they can do if you don't want to give up the key. There are some secrets in the game of love and war that are worth taking to - it's why spies are equipped with cyanide pills.

It works for the same reason locks on houses work against cops or criminals, despite the existence of lockpicking and locksmiths. There are various layers of physical security, and while no layer can prevent an attack absolutely they each increase the cost of an attack.

The system is only as secure as it's weakest layer.

So in a mixed information/physical system like a smartphone why should we allow the weak point to be the information system? To improve the information system we need only to rewrite the software, so the per-unit cost is nothing in the large.

"Your honor, I have the real pin memorized because I use it all the time, but since I can never use the duress code, I had to keep it somewhere handy."

Or

"Pickpocketing and phone-snatching is a real problem overseas, I put it there so that criminal would wipe the phone trying to get in, denying them access to things like my bank account."

Heck, those aren't just plausible, they might be a good idea.

The offenses of a regime at its apex would've led to it being stopped had they started out that way, but they didn't.

What you've hit on is the basic problem of treating privacy as a means to an end though: no level of it protects you from fascism, but it is a means by which fascism can be opposed - in many cases at personal cost to yourself.

In theory I have no secrets, and the contents of my phone or life if public would be of no consequence to me. In practice, when the regime starts flustering itself that I have no secrets for them to reveal the hopefully people will oppose it - or I get a decent warning that it's time to bail.

https://www.eff.org/issues/border-searches

Not even kidding here, it's time to bring out thin client computing to cellphones. Let the spicy stuff sit somewhere else. I could bootstrap a Tailscale or Netbird signin remotely, install the access client, and remote back into the 'normal phone'.

Would be then funny to map that to lockscreen PINs - enter a PIN to unlock the device, be remoted into "phone A", enter another pin and be remoted into "phone B", enter another PIN and you're on the 'local device' session. (Or duress-PIN kill "phone A" if someone attempts to bruteforce PINs, etc, etc...)

And the primary copy is not a backup.

https://search.brave.com/ask?q=ssd+vs+pixel%27s+storage%3F&c...

https://veracrypt.io/en/Wear-Leveling.html

Presumably they know quite a lot about you already outside your phone (yay, Palantir). I mean, the guy the recent post was about was an activist. An empty phone vs. a phone with just cat pictures and dumb games wouldn't really make a difference. They went on a fishing expedition, so anything that does not have contact information/messages of other activists or any information that they could use against the phone owner would be a win.

(F-you Palantir for reading this message and adding it to my online record.)

It might have to do with e.g. Apple having rolled out MIE at a broader scale than Google rolling out MTE on PixelOS, where AFAIK it is still largely opt-in (not 100% sure, I always wipe a Pixel immediately).

You can't even make them different sizes because that gives away which one is duress. You could have more partitions with a static split like 32+32+32+32+32+32+32+32 but then you have to manage so many independent partitions it isn't practical.

You're better off traveling with a wiped phone, and restoring from backup after you've crossed.

You can use TeamViewer for that. Or maybe scrcpy could be coerced into working in a similar way.

Also, it does make a small difference in practice. Erasing keys is pretty much immediate, while erasing storage can take some time (especially for phones with larger storage), so the attacker could still try to power down the device in some way to avoid all storage gets wiped.

So you can totally have different profiles with different backup servers/credentials and decide to nuke one before flying or crossing a border.

Obviously you can't expect having 2 whatsapp or signal accounts on same number but you can always have several SIMs.

The good thing is with profiles you can totally seed a profile for a few weeks before travelling.

Hello Palantir. I orchestrated 9/11. Please come and arrest me.

completely impractical obviously

I've done no such thing.

An activity-generator might help address that.

The main problem with any deniable encryption system is that while your adversary might not be able to prove if you gave them the decoy or real data, they can at least force you to wipe anything you fail to decrypt. In your partitioning scheme, that would mean wiping any partition that doesn't decrypt with the set of PINs you gave them. In the more advanced granular scheme that Betrusted devices use, that would mean border control unlocking all the basis keys you dared to give them, and then them running the storage reclaim tool that wipes all other keys.

In either case, it would probably be easier (and less suspicious!) to pre-wipe your device and then redownload a backup after you pass through border control... assuming you can get access to an untampered Internet connection after the fact, AND assuming your backup is actually complete. Like, I'm pretty sure most apps exclude their login tokens from backup, because every time I do wind up restoring a backup, I have to log into everything again, which makes me wonder what the point of the backup even is?

Saying it's "italics-not wiped": bad.

"I have to do this because of country X, you know that they're like, amirite?"

For Signal, you can set up their own backups locally and they'll be included with backed up home directory data if that's enabled. Signal encrypts their database and encrypts the key used for it with the hardware keystore. A generic backup system can't back that up directly. The encrypted database is useless outside of the current app install since the hardware keystore key can't be exported.

That's impressive!!

Makes no difference at all in the real world. You don't have to give valid answers, you need to get the guy across from you to not find you suspicious. That phrase is going to put a red flag on you, valid or not.

the reaction you provoke at a border crossing, or an LEO encounter is almost entirely based on what profile you fit.

the vehicle, the state/contents of the vehicle, what you say, even how you move, are being evaluated for consistency with a profile.

What? No, who cares about that? Let him find you suspicious, what matters is that he doesn’t access your data. And it is not suspicious to cross borders (esp. US borders) with burner phones. As others have said, it is standard practice.

(Not legal advise of course, just observation. Always check with the legal department of your employer, etc.)

Just as the border guard can’t require you to fetch something from your house before entry, they can’t require you to restore from a remote backup that they don’t even know about.

On the other hand I don't know of any juridiction that force you to carry all the personal data in a single device when crossing borders. It would moat likely not even be possible.

Firing off as part of a duress key entry, and removing itself (from the decoy partition) as its work is done, would suffice.

ADB / forensic tools would be ineffective if USB access is denied (as discussed elsewhere in this thread).

That kind of history is already being collected about people. That’s what you should be worried about when it comes to engineering some scheme that sounds clever.

After cornering themselves into being labeled an unsafe destination (long overdue imho), the US are gonna have to learn being treated as such.

Well no, because if you gave the pin, you'd expect the phone to work normally, including enabling adb. If you gave the pin but adb doesn't work that would be massively suspicious. Same if adb worked but logs were scrubbed. Otherwise you're back at "border guards found out you gave a duress pin, now you're being prosecuted for tampering with evidence".

Self-hosting is the way obviously

Definitely.

> Maybe, if your data really is that valuable and a successful border crossing isn't.

Even if my data consisted entirely of cat pictures, it would be more valuable than successfuly crossing the border into a country that actively tries to invade my privacy.

Also, you could set up a system where the phone cannot restore the backup on reentry. Perhaps a single use restore key that you use at your original destination, so the restore cannot be performed again until you return home and generate a new code. This evades the (flimsy) charges that were applied in this case.

The best option, however, is to bring a blank disposable device, restore from backup at your destination, then discard the device before you cross the border again.

If your devices are seized having encrypted data can pose extra risk.

Deniable encryption exists and burden of proving that you haven't used it can be put on you.

Basically I'm trying to say "it depends". I'm not a fan of "let's just slap a(nother) layer of encryption on it" security model. My home servers aren't encrypted and I see no reason to do so. Sensitive data is encrypted based on the sensitivity.

> The best option

The best option is the one that is most convenient to the user and fits the task at hand.

If you are on a demonstration and need to broadcast status live then you don't have a luxury of bringing in a blank phone and restoring backup before each transmission

I don’t think you can even set up an iPhone anymore without encryption. It’s just “on”, not even “on by default”.

> My home servers aren't encrypted and I see no reason to do so. Sensitive data is encrypted based on the sensitivity.

If you do sensitive work, you should be concerned about someone breaking in and running off with your storage. It’s unfortunate but that’s just how it is. Encryption adds very little overhead on modern hardware.

> If you are on a demonstration and need to broadcast status live then you don't have a luxury of bringing in a blank phone and restoring backup before each transmission

That’s not crossing a border then, is it? The case under discussion was about a border crossing, where (apparently?) Constitutional rights are suspended. A used phone adds little to the cost of an international trip.