I think this has been posted in response to this news story [1] to clarify that GrapheneOS has strong protection against data being extracted even without a duress PIN/password.
On a related note, a recent article [2] also describes how GrapheneOS helped a journalist protect his work and his confidential sources citing the 18-hour auto-reboot feature that returns the device to Before First Unlock (BFU) mode, where keys cannot be extracted.
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.
This is why it is important to continue iterating everywhere that device security is important for everyone. iPhone has nearly the same level of protection and we also do not see it as 'criminal by default'.
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.
GrapheneOS is good enough to have an entire column dedicated to it in Cellebrite's support matrix, and if I remember correctly the device could break into iPhones but not phones running GrapheneOS.
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.
GrapheneOS seems to be consistently the hardest to exploit AFU based on various Cellubrite leaks. iPhones have better protection than all other Androids except Pixels.
I might be wrong, but I get the impression that the GrapheneOS folks generally recommend GrapheneOS > iOS > Pixel >> everything else.
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).
There are more recent leaks. The last release of GrapheneOS they've been able to exploit on locked device is still from 2022 as of a couple months ago. They take longer to break into iPhones than stock Pixels but that may largely be due to Google giving much earlier access for public testing. They have a far shorter window to prepare for a new iOS release before it's in production as a regular update for users.
Perhaps the fact that iPhones are run by a multi trillion dollar company while GrapheneOS is an open source project with less employees than an Apple store has something to do with NATO approval. They are not going to approve a device that people have to install the OS themselves. I would base the security of an OS based on expert security researchers, not certain government agencies decisions.
iPhones are probably the most secure off the shelf phones you can buy, but based on leaked documents it's clearly inferior real-world security compared to a Pixel running GrapheneOS. Apple and Google have copied many security features from GrapheneOS like the reboot timer.
GrapheneOS is built from the ground up with a primary priority placed on security. GrapheneOS has much more robust USB port hardening. You can see the full list of features added on their website. Apple bolts on some additional security features in lockdown mode but they are mostly fixes to Apple's services which have large attack surface like iMessage. Additionally they are all built together and not on by default which makes the users willing to use it way lower.
Apple can at any time push a hostile "upgrade" that will remove or disable the claimed security features. You don't control the operating system, and can't trust that it isn't backdoored, especially given Apple's record[0].
Is this because of vulnerabilities baked in the HW (or bootROM or any other unpatchable area)? What’s the situation on older Pixels? Are they generally safer than an iPhone for HW issues? It’s expected that given a few years some vulnerabilities will crop up for most hardware.
So then the best chance for security is to stay up to date with everything, including the latest HW model. At least this gives an attacker a window of only ~1 year to find and exploit a vulnerability.
Perhaps GrapheneOS should just be an ASOP release with implicit security features that makes it hard to notice it is anything different. If people think it is a vanilla Android install, it would give them no reason to imply criminal activity.
They'd also have to update all their phone spec sheets -- not having the sandbox doubled graphene's battery life on my Pixel 6 Pro (in practice and vs. advertised specs).
He’s a “surveillance expert” so the language is not at all surprising. These are the people who always bring up the appeal to emotion, associating a benign act with something unpalatable, criminal, terrorist, think of the children.
When your job depends on not understanding and all that.
I'm fairly certain the person being quoted is saying the opposite of what you've implied - i.e. he thinks it is concerning THAT GrapheneOS is automatically associated with criminality.
You’re right, I misinterpreted but now that you mention it it’s like those ambiguous figure images, irreversibly collapsed on the proper interpretation. In this case I can only assume my interpretation of “surveillance expert” is also completely off. Can’t edit, flag away.
It was the article author's choice to include that language without wider context. People say things that can undermine their own position all the time, and it's those that present those statements that influence whether that happens or not. Think about how I soloed that quote out of the wider article for example.
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).
I dont understand why people like a journalist working on things they dont want seized would carry this kind of data on their device at a situation like this (border crossing), I see it as more useful to remove that kind of data from the device first.
What am I misinterpreting? OP literally said they don't understand why a journalist would carry these data with them. As if the data is a file on your phone. Data can be a contact book on your phone, or a messenger with E2E encrypted messages. What would the alternative to that be? Sending pigeons?
Restoring from remote backup when you reach your destination, then wiping again before you cross borders. Or shipping the (encrypted) data separately and picking it up after safe arrival.
Because you show up with nothing on you, and there’s no way to prove that the backups even exist. Especially given how often people travel with blank/disposable phones.
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.
Wiping under duress is
unlawful and could lead to prosecution in some juridictions.
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.
Not if it’s encrypted and self-hosted. Your doomerism is silly. “The government” is not all-powerful, or they wouldn’t need to pester people for PINs at the border.
Can the border guard go to your house and retrieve something, bring it to the checkpoint, and ask you to do something with it before entry? No. This is out of their legal authority.
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.
That's not my point. Rather that any self-hosted solution would. Encryption is completely optional and can be illegal in some places. As long as you trust the endpoint you only care about encryption in transit.
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
> If your devices are seized having encrypted data can pose extra risk.
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.
A protest is a completely different situation. In that situation I’d recommend a burner phone that you can afford to lose or throw away. Ideally the cheapest one available. And never log in to your primary accounts on it.
No one is stopped from backing up important data. It is, in fact, kind of boneheaded to keep all "valuables" on a single device. I don't understand the scenario of not trusting a device to safely access the Internet or the telephony grid while also insisting that they need a PHONE to keep all their stuff on where they're going, and at the same time somehow trust that both themselves and their possessions are perfectly safe from seizure and extortion in the very same location.
Personally I just got grapheneos to replace my normal phone. It's nice, it works for the user instead of the advertiser, and its security features help block antiuser features in apps
I personally run iOS but have given GrapheneOS an extended run on a development phone I use for work, and I have to say it really is a much tidier, less distracting, smoother and more responsive experience than any other Android setup I've used before.
This is where we need "cloud phones as a service" / "selfhosting a cellphone at home with some kind of remote access system".
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...)
You can already do most of that with GrapheneOS or even an iPhone. My contacts, files, photos, etc. are on my home server, accessed through a VPN. My GrapheneOS phone only runs a handful of open source apps. If I were to lose the phone, I would simply revoke the Wireguard key and there wouldn't be anything valuable left on it.
You would need to hide the existence of the original profile while in the decoy profile for this to work, which GrapheneOS considers too complex to implement
The only really plausibly deniable way to do it is for every graphene phone to come pre-partitioned for this. E.g. 128GB main + 128GB duress, random selection of whether partition 0 or 1 is the duress partition. But that means giving up half your storage.
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.
Deniable encryption has gotten way more advanced than this, though - the state-of-the-art is to have a bunch of independently unlockable data stores along with a mechanism to add chaff data that doesn't decrypt with any key. That's how bunnie's Betrusted project works, and it's the same idea as PhonebookFS from yesterdecade.
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?
That requires a whole new OS from scratch. It won't work to support Android. Even if it did, would you unlock your duress partition every time you used your phone to prevent overwriting?
Also the US CLOUD act: If you do business in the US, you have to give American authorities access to warrantlessly search any device not in the US that you have access to.
(I heard Europe and China passed the same laws. The EU has intelligence sharing agreements with the US, so I guess American authorities can just have the EU pull the data for US citizens in the US and forward it back home. I'm not a lawyer. It'd be nice if I'm wrong.)
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.
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.
It's great to know this exists! It's one of a few reasons I switched back to iOS after trying grapheneos.
Back then, you were still using Google's backup thing, and it was the year when they intentionally broke it to encourage people to move to unencrypted cloud services for important data.
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.
> the project has been taken over by another group of people not sharing our goals or approach
> 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?
Yeah, it's planned for years and years at this point.
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.
Android 12 changed the meaning of allowBackup="false" to opting out of cloud backups. GrapheneOS encrypted backups use the device-to-device transfer mode which includes apps opted out of cloud backups. It's similar to the Google Play data transfer feature, not Google's backup system.
Android 12 changed the meaning of allowBackup="false" to opting out of cloud backups. GrapheneOS encrypted backups use the device-to-device transfer mode which includes apps opted out of cloud backups. It's similar to the Google Play data transfer feature, not Google's backup system.
That still doesn't prevent other means that developers have to thwart backups. Chrome and vanadium has a custom backup agent that only dumps out settings, so browsing history and bookmarks aren't backed up at all. I believe firefox is similar unless they changed something recently. Same goes for other apps like signal. Browsers, messengers, and camera are the top 3 categories of apps I use on my phone, and the built-in backup gets 1/3 of them (camera actually works because it's just regular internal storage). That's not very good coverage.
Vanadium will add more data to the device-to-device backups but we haven't gotten to it yet.
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.
I wish they had a toggle for this. I'd much rather just have one backup system. Per-app backups is a pain to keep track of, and signal data is by far less sensitive than other stuff on my phone.
I use local seedvault backup and then sync via round sync daily trigger to my Nextcloud WebDav Server (native seedvault was not able to use this, for some reason).
It also supports the Android Storage Access Framework, so other forms of network "cloud" storage are also supported as long as the client ("cloud storage app") implements the correct api, so not only webdav
TTS is also in the process of being massively improved. What we've included is only an initial bare minimum implementation. We also plan to add speech-to-text but we may only support using existing models for it since it's harder and a model doesn't need to be bundled with the OS for accessibility.
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 partition based on a sparse disk image might avoid that.
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.
There really isn't. You can try avoid the "30GB volume on 128GB phone" problem by putting the hidden volume inside the free space of another volume, but since the outer volume doesn't know about the hidden, you have to be very careful not to overwrite the inner volume contents. The safest way would just be to not use the outer volume, but that's also suspicious. Who carriers around a phone that doesn't have any activity for months/years? Not to mention trim/discard means that free space will get wiped by default, and disabling it also makes you stick out like a sore thumb.
You're better off traveling with a wiped phone, and restoring from backup after you've crossed.
Well the activity generator is going to have to be very careful to not accidentally overwrite data on the hidden volume, and somehow able to hide itself from adb or forensic tools that it's enabled.
The activity generator may be a tool on your PC which is well aware of the hidden partition's presence. All it has to do is changing partition size before writing anything, then restoring it. It may also generate using your real data, which you explicitly ack. Some safe communication with your grandma and mother, some messages from your employer, banks, other recent 2FA codes. You white flag contact names and it does the job for you.
The problem with pre-generated activity is that it must cut off at (or shortly in the future of) generation time, to be plausible.
Otherwise that activity would be suspicious due to either a lack of recent records, or of presumably implausible future ones.
Generating data in advance and applying or updating timestamps later, on an ongoing basis, or when a duress code is entered is a possible way of mitigating this. There's the question of how convincing such data would have to be. White-flagging and generating (or appropriating from public sources, e.g., business or institutional entities) contacts for this might be a part of it. This is similar to but not entirely the same as data fuzzing, which is generally seen as applying to a primary data trail.
>ADB / forensic tools would be ineffective if USB access is denied (as discussed elsewhere in this thread).
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".
In fairness, an adversarial challenge can be useful in pointing out weaknesses (and possible mitigations) to a particular technical approach.
It's not clear that all of those objections are substantive or insurmountable.
"The USB port may have died" might be one possible response. (Not technically a lie, and hence defensible in court.) Or just silence.
Alternatively, some way of directing such probes to the decoy partition and presenting a sufficiently coherent impression of a valid partition might be another approach.
Much of this comes down to risks presented and costs of mitigation (or of getting mitigations wrong).
>"The USB port may have died" might be one possible response. (Not technically a lie, and hence defensible in court.) Or just silence.
That's about as convincing as "wow this phone just decided to experience catastrophic hardware failure after entering your totally-not-duress pin". Not to mention there's wireless adb.
>Alternatively, some way of directing such probes to the decoy partition and presenting a sufficiently coherent impression of a valid partition might be another approach.
That won't work because they'd notice the adb logs don't correspond to actions taken on the actual phone.
>Much of this comes down to risks presented and costs of mitigation (or of getting mitigations wrong).
Right, which is why grapheneos didn't bother implementing it, because it's a huge effort and it's not worth giving users a false sense of security (eg. thinking that the decoy works when it doesn't), and them getting sent to prison for it.
Based on what I read it seems it's the same whether an SSD or UFS (what Pixels use) because they both use Nand flash as the underlying storage technique which is where the metadata issues occur.
An unmounted, hidden veracrypt volume is pretty much undetectable with the typical forensics, if the OS hasn't leaked anything that would expose it. I don't know what their official account was alluding to with that wildcard statement.
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.
"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.
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.
Yeah but if you're a normal guy strolling through every time with a phone that has nothing- no pictures, no signed in email, no history of messages, 4 contacts. That's abnormal, no way of spinning it as "but I just don't use my phone much" will make that seem normal. The average person has their phone glued to their body 24/7 now. Implying that you don't is abnormal.
"I only ever cross borders with a blank phone because I don’t want you invading my privacy" is a perfectly valid answer. You can also add that it is your employer’s policy and/or your government official recommendation.
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.
> you need to get the guy across from you to not find you suspicious.
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.
He doesn't access your data. He confiscates your phone, then still doesn't access your data, then denies you entry, then still doesn't access your data, then holds you in immigration detention for a week while he tries to access your data, which he can't. Is that a success? Maybe, if your data really is that valuable and a successful border crossing isn't.
> 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.
To cross said border with my burner phone in my pocket and do whatever I need to do on the other side, why else? You do realise that is by far the most likely outcome, yes?
I have worked for employers that required taking a burner phone to certain countries without any accounts logged in, etc. (so mostly for calls, maps, and web browsing) and nobody has ever been detained or denied entry. Some countries know that this is just standard procedure when they are visited for business trips. Probably different for the US though.
(Not legal advise of course, just observation. Always check with the legal department of your employer, etc.)
Lying about what? "I only bring a burner phone to border checks because I don’t want people like you to access my data“ is not a lie, and I fail to see how it could be interpreted as such.
This may feel like a good idea as a “gotcha” justification but it just doesn’t matter. It’s still extremely abnormal and you will stick out. The only way to protect yourself is by blending in, not sticking out.
Well but the point goes beyond “do they let you through.” All of this goes past the here and now. It’s about getting flagged in some system that causes you to get picked out 3 stops down the line when these odd occurrences add up to you not being trustworthy based on your profile history.
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.
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.
The easiest way to avoid suspicion is to have a phone filled with cat and family pictures, dumb apps and games.
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.)
On the other hand, if everything about you is boring, that in itself may begin to seem suspicious. "I borrowed this old phone from my stepson because my own phone got run over by a steamroller at a vintage vehicle show" is the sort of thing an actual spy or criminal would never say.
Multiple decoy accounts, heh. First one: cat pics. Second one: dick pics. Third one: conversations with an imaginary mistress. Fourth one: porn that's illegal in Korea. Fifth one: ....
> So you plan to (1) actively/proactively conceal your data/evidence
I am not concealing data/evidence as it doesn't exists. I don't know of any law in any country that force you to hand out the key of your home to a remote state so that they can enter your country and do a search.
> and then (3) constantly restore from cloud backups?
Why constantly? Only and only if I need to access specific data (that may be available remotely without restore anyway). Full restore only when going back in my own country.
Being prosecuted because your smartphone has been setup yesterday is not the same as being prosecuted because you gave a password that wipe your phone in front of law enforcement.
In the past I have had my smartphone die a couple of days before travelling and quickly buying a smartphone so I could have a mobile line in case of emergency while travelling. This is not a totally uncommon case to have a smartphone with very little data. A lot of people never setup any cloud backup and lose all their data every so many years.
Yeah, the lesson is: do not travel to countries that treat people such in a shitty way. This has always been true. Unfortunately, for many foreigners this also applies to the US nowadays.
I guess that you are out of luck if you are a US citizen and need to return to your own country.
Do the requirement to put your social account public when applying for a US Visa still applies? I guess the USA do not have that many non US visitors these days because I don't know a lot of women who would agree to that. Almost all my female friends have been experiencing stalking from jealous ex, former colleagues/clients/patients so putting their social media account public would be a complete no-go for them.
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.
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.
yep, human bias makes 4-digit pins and patterns a lot worse than the theoretical entropy, but still it's a decent starting point
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
>>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.
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
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 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.
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.
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.
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.
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.
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 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.
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).
Doesn't have to be a literal wrench right? A government can trivially and legally make you miss the itinerary that made your holiday possible that you've saved up for the rest of the year with no restitution that I'm aware of in any jurisdiction. They can confiscate 'evidence' (any computer and (backup) storage media in your house) for years. They can do a heck of a lot that's more annoying than medium amounts of wrench swinging
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?
> A government can trivially and legally make you miss the itinerary that made your holiday possible that you've saved up for the rest of the year with no restitution that I'm aware of in any jurisdiction. They can confiscate 'evidence' (any computer and (backup) storage media in your house) for years.
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 wrench attack is still far weaker than a push-button attack.
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.
The United States has famously shot and killed protesters in the Vietnam war era. They have dedicated torture facilities for people suspected, not even convicted, of terrorism. Police officers use lethal violence for no reason every month and rarely get more than a talking to.
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.
The point of the comic is pretty obviously to make fun of the expectations of cryptography geeks; you know, the sort of people who use 4096 bit RSA keys for the coolness factor. It is a stretch to imply it is suggesting that encryption is somehow futile.
If you're that much of a coward, you won't get hit by a wrench anyways because you will give your keys up immediately. But you will force your enemy to exert additional effort.
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.
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.
Everyone thinks they're brave until they get punched in the face. The fact that a handful of terrorist attacks decades ago were all it took to push society into voting for control freaks who built a worldwide surveillance state to nanny them tells me all I need to know about how brave people really are.
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.
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.
> I'm surprised they didn't back up the device first.
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).
From what I understand he was not formally arrested at the time, just interrogated at the border. I am not familiar with US laws but from what I understand the device was not (yet?) considered evidence in an investigation. I imagine backing up might not be as easy an option without tearing down the device as the memory chip is no the device mainboard, so not something you can necessarily do on the side of the road or at a border without a formal warrant/investigation.
This is really an interesting case. Hope to see a ruling here. The edge cases are really interesting as well, like the fake pin on the back of the phone. I also wonder generally about the 'destruction' of data
Wouldn't the government need to prove that there is no backup, because just making it more difficult (like hiding) would probably not call for the paragraph. Unfortunately for the rest of us the defence is based on more proven grounds. I guess only plausible deniability is helpful: I e.g. would love to see my trusted android space being empty/recreated on false password.
> The edge cases are really interesting as well, like the fake pin on the back of the phone.
"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.
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.
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).
This site is called Hacker News :), people might just want to learn how it works technically, so I think it is worth mentioning technical differences.
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.
I'm not sure it would have been that easy for them to back it up.
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.
The alleged charges seem nonsense - destruction of property to prevent seizure? First no property was destroyed, and second they could still seize it. But US courts are a coin toss so it may still work for the government.
Yes, it would be interesting if the question was formulated like "we're gonna need a password" and this ends up being a lawyerdog situation. https://blogs.illinois.edu/view/25/574827
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.
It's fairly easy to open up a phone and probe inner circuitry.
I suspect that'll be the next step for malicious actors. I doubt very much the phone is fully resistant to having malicious data injected onto various busses.
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.
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.
What if the supplier backdoors the secure element? It would be better to just encourage the user to use a high-entropy key, and not bother with the secure element at all.
The secure element rate limiting is integrated in a way that can only add security. It can't reduce the security of key derivation since it's only used to get an extra input for deriving the key. There are various other inputs in addition to the PIN/password too to add various security properties. The most relevant one is the token obtained from the secure element rate limiting system via successful authentication, but there are others.
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.
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.
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 remember cases of that happening to diplomates or something, but I didnt find it. So not for an average lab maybe, but three letter agencies will easily swap your phone if they can't get in.
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.
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.
On a related note, a recent article [2] also describes how GrapheneOS helped a journalist protect his work and his confidential sources citing the 18-hour auto-reboot feature that returns the device to Before First Unlock (BFU) mode, where keys cannot be extracted.
[1] A US man is being prosecuted after allegedly using a GrapheneOS duress PIN to wipe his Pixel during a border search – https://www.theguardian.com/us-news/2026/jul/23/cop-city-pro...
[2] A Journalist had his mobile phone seized. Did using GrapheneOS protect his data? – https://www.computerweekly.com/feature/Journalist-Richard-Me...
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.
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.
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).
That's impressive!!
iPhones are probably the most secure off the shelf phones you can buy, but based on leaked documents it's clearly inferior real-world security compared to a Pixel running GrapheneOS. Apple and Google have copied many security features from GrapheneOS like the reboot timer.
GrapheneOS is built from the ground up with a primary priority placed on security. GrapheneOS has much more robust USB port hardening. You can see the full list of features added on their website. Apple bolts on some additional security features in lockdown mode but they are mostly fixes to Apple's services which have large attack surface like iMessage. Additionally they are all built together and not on by default which makes the users willing to use it way lower.
[0] https://en.wikipedia.org/wiki/PRISM
Probably the latest models. Cop told me they have problems cracking those. Older models not so much, that's pretty common knowledge.
So then the best chance for security is to stay up to date with everything, including the latest HW model. At least this gives an attacker a window of only ~1 year to find and exploit a vulnerability.
That is diametrically opposed to their interests in data collection.
When your job depends on not understanding and all that.
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).
Delete the contact book? Clear calendars?
Where exactly should one stop?
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.
Self-hosting is the way obviously
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.
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...)
You can use TeamViewer for that. Or maybe scrcpy could be coerced into working in a similar way.
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.
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?
https://veracrypt.io/en/Wear-Leveling.html
(I heard Europe and China passed the same laws. The EU has intelligence sharing agreements with the US, so I guess American authorities can just have the EU pull the data for US citizens in the US and forward it back home. I'm not a lawyer. It'd be nice if I'm wrong.)
(The Computer Weekly item was submitted but saw no significant discussion.)
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.
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.
Back then, you were still using Google's backup thing, and it was the year when they intentionally broke it to encourage people to move to unencrypted cloud services for important data.
> 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.
https://grapheneos.org/features#encrypted-backups
https://github.com/GrapheneOS/os-issue-tracker/issues/4687#i...
> 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?
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.
So basically one needs a webdav server somewhere or an usb flash drive.
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.
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.
Booting into a 30 GB partition on a 128GB phone is going to be mega suspicious, even if the remaining data is random.
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.
You're better off traveling with a wiped phone, and restoring from backup after you've crossed.
An activity-generator might help address that.
Otherwise that activity would be suspicious due to either a lack of recent records, or of presumably implausible future ones.
Generating data in advance and applying or updating timestamps later, on an ongoing basis, or when a duress code is entered is a possible way of mitigating this. There's the question of how convincing such data would have to be. White-flagging and generating (or appropriating from public sources, e.g., business or institutional entities) contacts for this might be a part of it. This is similar to but not entirely the same as data fuzzing, which is generally seen as applying to a primary data trail.
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).
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".
It's not clear that all of those objections are substantive or insurmountable.
"The USB port may have died" might be one possible response. (Not technically a lie, and hence defensible in court.) Or just silence.
Alternatively, some way of directing such probes to the decoy partition and presenting a sufficiently coherent impression of a valid partition might be another approach.
Much of this comes down to risks presented and costs of mitigation (or of getting mitigations wrong).
That's about as convincing as "wow this phone just decided to experience catastrophic hardware failure after entering your totally-not-duress pin". Not to mention there's wireless adb.
>Alternatively, some way of directing such probes to the decoy partition and presenting a sufficiently coherent impression of a valid partition might be another approach.
That won't work because they'd notice the adb logs don't correspond to actions taken on the actual phone.
>Much of this comes down to risks presented and costs of mitigation (or of getting mitigations wrong).
Right, which is why grapheneos didn't bother implementing it, because it's a huge effort and it's not worth giving users a false sense of security (eg. thinking that the decoy works when it doesn't), and them getting sent to prison for it.
https://veracrypt.io/en/Wear-Leveling.html
https://search.brave.com/ask?q=ssd+vs+pixel%27s+storage%3F&c...
Not having the data in the first place in some specific contexts (like crossing borders) is easier.
[1] https://news.ycombinator.com/threads?id=Cider9986#49058421
https://veracrypt.io/en/Trim%20Operation.html
https://veracrypt.io/en/Wear-Leveling.html
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?
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.
I've done no such thing.
"I have to do this because of country X, you know that they're like, amirite?"
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.
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.
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.
(Not legal advise of course, just observation. Always check with the legal department of your employer, etc.)
After cornering themselves into being labeled an unsafe destination (long overdue imho), the US are gonna have to learn being treated as such.
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.
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.
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.
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.
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.
You don't avoid scrutiny by being wierd and hiding things, but by hiding in plain sight by being ultra boring.
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.)
Hello Palantir. I orchestrated 9/11. Please come and arrest me.
completely impractical obviously
I am not concealing data/evidence as it doesn't exists. I don't know of any law in any country that force you to hand out the key of your home to a remote state so that they can enter your country and do a search.
> and then (3) constantly restore from cloud backups?
Why constantly? Only and only if I need to access specific data (that may be available remotely without restore anyway). Full restore only when going back in my own country.
You are also not under any obligation to have it on your phone at all times.
I'd rather have them tell me to turn back and go home than being jailed there only because I don't want them to fap at the picture of my daughters.
In the past I have had my smartphone die a couple of days before travelling and quickly buying a smartphone so I could have a mobile line in case of emergency while travelling. This is not a totally uncommon case to have a smartphone with very little data. A lot of people never setup any cloud backup and lose all their data every so many years.
I guess that you are out of luck if you are a US citizen and need to return to your own country.
How is the tourism industry going?
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.
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.
- After an incorrect key, require two (or more) consecutive valid key entries.
- After an incorrect key, no longer accept that nominal key until a secondary key is supplied.
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
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.
> > 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
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.
edit: this was a response to another comment opps.
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.
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.
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).
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?
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!
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.
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.
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.
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.
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).
https://www.eff.org/issues/border-searches
"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 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).
And the primary copy is not a backup.
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.
Saying it's "italics-not wiped": bad.
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.
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.
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.
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.
I suspect that'll be the next step for malicious actors. I doubt very much the phone is fully resistant to having malicious data injected onto various busses.
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.
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.
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.