Join the discussion
Write your take first — we'll ask for email only when you're ready to publish.
- Hacker News
- Relevant xkcd https://xkcd.com/538/
- 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).
by ris - Relevant news story: https://www.androidauthority.com/grapheneos-duress-pin-us-pr...
It sounds like he did give them the password, but it was the password to wiping his phone and not unlocking it. I'm surprised they didn't back up the device first.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.by bigyabai - I always leave my phone and laptop off when going through TSA or Passport Control. I don't think in the US you an be compelled into giving up your password. They are free to confiscate the device but with it powered down good luck trying to break the password.by t1234s
- I was just told if I don’t give my pin they take my green card. You cannot call a lawyer so do you want to gamble or give your pin? WhatsApp just needs Face ID with unique pin not the main app one.by siilats
- 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.
by Cider9986 - Does it protect it in After First Unlock mode? I often use my device and if I lock it before LE or another bad actor catches it then it's kind of useless if it doesn't protect my data in after first unlock (locked) mode. Especially with LE agencies having tools like Cellebrite at their station for same day analysis. Most people probably won't have time to reboot their device.
Similar to how I use Veracrypt, but I leave my PC running, because I hate spending time booting up again. So LE could decrypt my stuff using RAM extraction stuff.
by b8 - 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.
by grapheneos - Here's an idea: soft duress PIN that wipes a list of apps of your choice however doesn't make it obvious it's done so.
Or restores app data to a restore point of your choosing making it seem like everything is fine.
Make it untraceable you had it setup and it'll help deal with any potential legal issues.
- 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.by Cider9986
- 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.
by grapheneos - Does anyone know if the Motorola partnership is still on with GrapheneOS or how long until a phone is made available from them?by ddtaylor
- >within ~12 months, in 2027
https://news.ycombinator.com/item?id=49038982
Not from someone employed by the project but a frequent contributor.
by Cider9986 - It's really comical when you want to have same security guarantees as you get on apple devices you are a criminal. Search more: "apple devices automatically restart", "apple device full encryption", "apple lockdown mode".
edit: this was a response to another comment opps.
by himata4113 - 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.
by kmeisthax - although it is wonderful to know that there exists a piece of hardware in the world that is not conspiring against its users, the outcome of entering a duress password should be indistinguishable to the user that grabs hold of the mobile phone. The duress password should wipe off the real user account information but present the kidnappers with a full-fledged operating system populated with real-looking content to entertain the police officers with polite meaningless e-mails saying things like
> > On Apr 11, 2015, at 5:45 PM, Jim Steyer Hey John, > > > > We know you're a true master of cuisine and we have appreciated that for > years ... > > > > But walnut sauce for the pasta? Mary, plz tell us the straight story, > was the sauce actually very tasty? > > > > > Jim
- That email chain sounds exactly like the TV show Severanceby DeluluDon
- That's called a decoy password rather than a duress password, btwby inigyou
- 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.
by imkac - 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.
by rustyhancock - There was some comment here somewhere arguing that 16 characters for a password is too little, but that he used the pattern lock. Looks like it was deleted.
Anyway. The pattern lock in Android provides Log2(389112) =~ 18.57 bits of entropy. This is less than 3 random characters, or 4 lowercase letters, or a decimal PIN digit password of 6 characters.
Granted, you could use mnemonics for long passwords, but how convenient is to input those long passwords?
I wonder why don't they just allow for longer passwords and just use a hash digest when it's too long, rather than just disallowing people from using strong passwords that they will remember. This pushes people to reuse passwords, send them to themselves, and other bad practices.
by muyuu - 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.by brendyn
- 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.
by jeroenhd - >>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.
by Cider9986 - 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.
by grapheneos - What GrapheneOS is missing is a complete backup and restore solution so that people can preventively wipe their smartphone before crossing the border. It would be nice to have the possibility to backup/restore every app and their data from an ssh/sftp server the way google/apple users do with google cloud / icloud. I'd rather wipe my smartphone, only add a couple of direct contacts, a copy of my passport and the pdf of my plane tickets, take the plane and cross the border with a smartphone with very little but real personal data they already know and be able to provide my PIN/password to law enforcement if they ask for it, abiding with law if such a law exist (which is the case in my home country), than using a duress and risk prosecution.
Sure that doesn't protect your data from any other attack vector but it allows you to travel with less risk of getting detained by law enforcement of a country you are visiting. You get asked your password, you can give it, and they see a phone that is used like a dumbphone. If you get questioned for that a simple "my phone died yesterday, a friend just gave me his old pixel". If you need more stuff/information during your travel you would basically only need to remember the passphrase to access a password manager or a remote ssh server but you can restore only the stuff you need when travelling and and wipe again at any moment.
Having said that maybe it is better to set this up some way but not have it builtin so that law enforcement doesn't expect that any grapheneos user would have his data on an sftp server somewhere by default. Otherwise we are back to point 0 where they would ask to connect to it and restore to a phone they own. Oh and have a dummy google account you only used to purchase a couple of silly stuff on amazon, aliexpress and shein and random subscription of various "non risky subjects" on youtube. The gmail address would quickly be filled with enough spam to look genuine.
I am travelling abroad in 3 weeks for a month and I am seriously considering wiping up my grapheneOS phone before flying. I am wary that I could be targeted at a border just for having a google pixel with grapheneOS. Or maybe I should just leave my main phone at home and only travel with a new empty 150€ phone with only my main family emergency contacts. I don't remember ever being asked to show my smartphone at a border but you never know when it will happen. Thanksfully until you reboot it there is nothing that shows from the lockscreen that it is not running the regular google pixel android.
by prmoustache - Honestly, I feel like I'd be more suspicious of someone who had little to nothing installed on their phone.by hahn-kev
- "my phone died yesterday, a friend just gave me his old pixel" - please don't do this. That's lying to law enforcement and they can prosecute. Just say it's your travel phone.by ryoshu
- Remind us what happened when you do cross.by DeluluDon
- > 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?
by drnick1