9 ms·

GrapheneOS protections against data extraction from locked devices

448 points by Cider9986 3mo ago

robotswantdata 3mo ago
Relevant xkcd https://xkcd.com/538/ https://xkcd.com/538/
- bigyabai 3mo ago
  Relevant news story: https://www.androidauthority.com/grapheneos-duress-pin-us-prosecution-3691271/ https://www.androidauthority.com/grapheneos-duress-pin-us-pr... According to The Guardian, the US Department of Justice is prosecuting Atlanta resident Samuel Tunick after he allegedly gave a GrapheneOS duress PIN while border agents were trying to search his Google Pixel phone. 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.
  - imkac 3mo ago
    Backup is useless without security chip.
  - prmoustache 3mo ago
    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.
    - evan_a_a 3mo ago
      Border searches are special case in US law where the 4th amednment protections aren't as strong. See the EFF page about it for more: https://www.eff.org/issues/border-searches https://www.eff.org/issues/border-searches
    - polipputter 3mo ago
      >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 Oh you sweet innocent child. US Customs and Boarder agents, every federal agency, and most local law enforcement agencies all have Cellebrite, Oxygen, or an equivalent tool which can perform a full device extraction on basically any phone expect for a pixel running Graphene OS with the current updates and a new model iPhone also running it's current updates. Every other phone on the market in the US can be cracked and extracted by cellebrite simply by plugging in a usb-c cable. Even a stock pixel, Samsung, iPhone, etc. Typically they would absolutely need a warrant to perform a device extraction but the supreme court has ruled that at boarder crossings, a person is not actually in the US until allowed entry by an agent and by not being in the US, US law and constitutional rights dont apply. If you are a US citizen, they can not deny you entry but that can keep your phone and attempt to extract it at a later time when exploits may be uncovered to break the encryption or bypass it completely
  - cryo32 3mo ago
    My trick there is not travelling to the US. 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.
  - microtonal 3mo ago
    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).
    - Dylan16807 3mo ago
      Oh please. That's not a real distinction. The phone as a unit, flash plus enabling chips, is wiped in an unrecoverable way. And the primary copy is not a backup.
      - inigyou 3mo ago
        It might be a real legal distinction, but probably not.
      - microtonal 3mo ago
        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.
        Dylan16807 3mo ago
        Going into detail about how it works: great. Saying it's "italics-not wiped": bad.
  - riedel 3mo ago
    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.
    - Terr_ 3mo ago
      > 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.
  - jcul 3mo ago
    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.
  - ludicrousdispla 3mo ago
    So, technically, the border agents wiped the phone. I wonder how specific their request was of Tunick when they asked for the password.
    - dqv 3mo ago
      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 https://blogs.illinois.edu/view/25/574827
  - inigyou 3mo ago
    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.
  - grapheneos 3mo ago
    > 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).
- ris 3mo ago
  I hate this meme. The point is to at least make them resort to hitting you with the $5 wrench, at which point they're probably committing a more serious offence than what you're up for (dependent on country).
  - moffkalast 3mo ago
    You end up getting hit by a wrench though, that doesn't sound like it ends well for you.
    - XorNot 3mo ago
      Liberty is given up in inches, not miles. 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.
    - iamnothere 3mo ago
      Sounds like something a coward would say, honestly.
      - moffkalast 3mo ago
        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.
    - tarpitt 3mo ago
      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.
rzk 3mo ago
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. [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-protester-phone 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-Medhurst-had-his-mobile-phone-seized-Did-using-a-secure-phone-protect-his-data https://www.computerweekly.com/feature/Journalist-Richard-Me...
- microtonal 3mo ago
  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).
  - msh 3mo ago
    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.
    - choo-t 3mo ago
      Because you may need the data in the data during/after your travel and lack clean way to access safely, securely and anonymously remotely.
deleted 3mo ago
[deleted]
- deleted 3mo ago
  [deleted]
deleted 3mo ago
[deleted]
prmoustache 3mo ago
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.
- ButlerianJihad 3mo ago
  [flagged]
muyuu 3mo ago
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.
- brendyn 3mo ago
  Maybe because it was mistaken. I just set my grapheneos to a 35 character password to test it and it didnt seem to have any issue.
  - b112 3mo ago
    Did ypu test using random characters after 30 chars?
  - muyuu 3mo ago
    nope it was arguing that this is a difference with stock android and that it is 16 chars there, idk about that though
- Cider9986 3mo ago
  >>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.
londons_explore 3mo ago
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.
- libroot 3mo ago
  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.
  - praguegolem 3mo ago
    Im skeptical of what the average lab can do on modern day hardware, but it's not something I would ever want to test my luck on.
    - one33seven 3mo ago
      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.
- Aachen 3mo ago
  If it was that easy, we'd just do that to get access to our own data on these devices. The OEM unlock toggle is a much-desired feature for a reason
- KJs6ZxELzQM37O 3mo ago
  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.
usern20260720 3mo ago
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
- DeluluDon 3mo ago
  That email chain sounds exactly like the TV show Severance
- imkac 3mo ago
  From GrapheneOS official account: Our duress PIN/password feature doesn't pretend that it can stealthily wipe the device. It properly implements what people expect it to do and does it safely. It isn't our role to choose how to use the feature including how to use it in a situation where there are potential consequences to it. We haven't implemented any features which are in any way specific to situations involving law enforcement. We aren't going to give people any legal advice on how to handle situations involving law enforcement. It isn't our role and does not make sense particularly since laws vary so much based on jurisdiction, context and how they're interpreted on a case-by-case basis. If people want legal advice, they should ask a lawyer for it. It's not possible to provide anything close to plausible deniability for wiping profiles. A deleted profile leaves behind metadata proving it existed in the device encrypted and Owner profile encrypted storage. There are a whole bunch of different ways it can be shown that it existed. ADB can be easily used to identify a wipe occurred and when it occurred. The standard approach used by forensic tools is connecting via ADB and they can easily add support for detecting this. It would be easy for non-experts to figure out how to do it especially with the guidance of a decent LLM. It would put users at risk who believe they can perform a stealthy wipe despite it not being possible. We do not want to provide a feature which cannot come close to working properly. Android's Private Space has a half-baked feature for hiding that the Private Space is enabled in the user interface for someone without access to the relevant unlock methods or ADB. There are multiple publicly known ways to identify a Private Space is enabled. These aren't treated as significant security vulnerabilities and fixes for it aren't backported to older releases. It isn't practical to cover all possible ways of detecting it even with the limited scope of only attempting to hide it in the user interface and not ADB. We don't plan to remove the feature but don't think it should have been implemented and wouldn't have done it ourselves. If we implemented a half-baked deniable wiping feature then the flaws would be discussed in this forum, our issue tracker and elsewhere on the internet. It would quickly become known to LLM models, which would be able to assist with detecting it. It would be incorporated into standard forensic tools and guides. This is not an approach we want to take with GrapheneOS. Our features need to work against adversaries aware those features exist. An adversary aware of the duress PIN/password existing doesn't have a way to tell it apart from a real PIN/password. They'll have to consider if a PIN/password provided to them could be a duress PIN/password even for users who don't use the feature. The feature is now going to be widely known about due to the news coverage and it's still going to work. On future devices, we want to add duress PIN/password support to the secure element as part of the Weaver rate limiting so it can't even be bypassed with an OS exploit.
ddtaylor 3mo ago
Does anyone know if the Motorola partnership is still on with GrapheneOS or how long until a phone is made available from them?
- Cider9986 3mo ago
  >within ~12 months, in 2027 https://news.ycombinator.com/item?id=49038982 https://news.ycombinator.com/item?id=49038982 Not from someone employed by the project but a frequent contributor.
t1234s 3mo ago
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.
- Cider9986 3mo ago
  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.
  - t1234s 3mo ago
    they need a shortcut where you triple tap the power button and it just does a fast hard power off similar to removing the battery.
- siilats 3mo ago
  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.
saidnooneever 3mo ago
[flagged]
- Cider9986 3mo ago
  He was put on a watchlist for protesting. I don't think the OS is what caused the unconstitutional detainment.
- ksbd-pls-finish 3mo ago
  >it was already pretty much impossible to get an encrypted device past US Customs more than 15 years ago B-but I did it many times? Or do you mean that it's impossible to refuse providing the decryption key and still pass? That's pretty obvious.
CommanderData 3mo ago
Here's an idea: soft duress PIN that wipes a list of apps of your choice however doesn't make it obvious it's done so. Or restores app data to a restore point of your choosing making it seem like everything is fine. Make it untraceable you had it setup and it'll help deal with any potential legal issues.
- Cider9986 3mo ago
  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.
- grapheneos 3mo ago
  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.
jdsfijfdsifs 3mo ago
[dead]
arkhiver 3mo ago
[dead]
b8 3mo ago
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.
- grapheneos 3mo ago
  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.
himata4113 3mo ago
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.
- kmeisthax 3mo ago
  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.
reindeer2 3mo ago
[flagged]
LWIRVoltage 3mo ago
( roughly copying my post from another thread) A few things: #1. The download and restore backup method would work for people in general- except it doesn't capture what people would need. Exmaple: I have some thermal cameras that rely on old 32 bit apps that do not run on anything android 12 onwards- If i wipe those old phones, and restore- the apps often wanted to reach out to a server for initial activation- they would fail upon reinstall and i'd be out of the apps that are required to control my cameras and related equipment,which is worth thousands and thousands and thousands. And it'd be all dead weight and rendered useless. (and competitors today do not compete- for example try finding a 640*480 30 hz or better form factor thermal camera that attaches to phones - they dont exist anymore) \The solution is full imaging- but there isnt a way to fully image phones and restore backups today. There used to be it seems- but not really with the latest stuff at the time of this post . On another note:Veracrypt- The weakness of truecrypt and veracrypt, the hidden OS option only worked if you converted your computer to MBR, which means you can't have a hard drive too large. Making a UEFI hidden OS has not been done yet. And the Hidden Volume option- isn't 'as' useful, and of course, your OS might make a copy and put it somewhere, you have to be careful. As a example: Any time I open a file, using the software tool Everything to search and confirm this- you can easily see Windows makes copies and temp files and whatnot in randomly named locations- that's the sort of behavior that would screw people over We need fully image-backup capable Phones. I mean fully. Not just backing up some apps- as this refuses to backup apps you have that are no longer on app stores, or that Play Protect doesn't like, etc. Next- Plausible deniability is a way forward- but you need multiple profiles, that are cryptographically indistinguishable, along with the phone being hardened so GreyKey /Cellebrite won't be able to exploit a way in. This needs to be built this way from the ground up ideally, eventually. There has been research about making devices that treat all block space the same way so you can't tell if someone has 1, or 50 profiles or partitions, etc- and even stuff that overlaps. Often it needs to be fixed size partitions, but it is apparently NOT impossible to create. I am aware of Shufflecake attempting to make a solution for Linux, and yes, a Hidden OS option that is forensic- invisible. But nothing has come out - and especially, for phones. I hope Graphene OS or another group, eventually works on this for phones. I do wonder if it would require a Linux phone, or something built from the ground up rather than current phone architecture. It would be nice to see the day where, if you travel to a hostile country, you can tell them you have just one profile, and if they ask, you could theoretically mention a 2nd, and then show it- but you might have 3 more - and they'd all be immune to forensic inspection if the system is built right.(Yes, there's often issues you have to be careful of ,like setting this up so you dont destroy data when in other profiles,) This is how you solve this problem in the long run-make computing devices impossible to analyze, but standard.

448 points by Cider9986 3mo ago

robotswantdata 3mo ago

Relevant xkcd https://xkcd.com/538/ https://xkcd.com/538/

bigyabai 3mo ago
Relevant news story: https://www.androidauthority.com/grapheneos-duress-pin-us-prosecution-3691271/ https://www.androidauthority.com/grapheneos-duress-pin-us-pr... According to The Guardian, the US Department of Justice is prosecuting Atlanta resident Samuel Tunick after he allegedly gave a GrapheneOS duress PIN while border agents were trying to search his Google Pixel phone. 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.
- imkac 3mo ago
  Backup is useless without security chip.
- prmoustache 3mo ago
  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.
  - evan_a_a 3mo ago
    Border searches are special case in US law where the 4th amednment protections aren't as strong. See the EFF page about it for more: https://www.eff.org/issues/border-searches https://www.eff.org/issues/border-searches
  - polipputter 3mo ago
    >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 Oh you sweet innocent child. US Customs and Boarder agents, every federal agency, and most local law enforcement agencies all have Cellebrite, Oxygen, or an equivalent tool which can perform a full device extraction on basically any phone expect for a pixel running Graphene OS with the current updates and a new model iPhone also running it's current updates. Every other phone on the market in the US can be cracked and extracted by cellebrite simply by plugging in a usb-c cable. Even a stock pixel, Samsung, iPhone, etc. Typically they would absolutely need a warrant to perform a device extraction but the supreme court has ruled that at boarder crossings, a person is not actually in the US until allowed entry by an agent and by not being in the US, US law and constitutional rights dont apply. If you are a US citizen, they can not deny you entry but that can keep your phone and attempt to extract it at a later time when exploits may be uncovered to break the encryption or bypass it completely
- cryo32 3mo ago
  My trick there is not travelling to the US. 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.
- microtonal 3mo ago
  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).
  - Dylan16807 3mo ago
    Oh please. That's not a real distinction. The phone as a unit, flash plus enabling chips, is wiped in an unrecoverable way. And the primary copy is not a backup.
    - inigyou 3mo ago
      It might be a real legal distinction, but probably not.
    - microtonal 3mo ago
      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.
      - Dylan16807 3mo ago
        Going into detail about how it works: great. Saying it's "italics-not wiped": bad.
- riedel 3mo ago
  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.
  - Terr_ 3mo ago
    > 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.
- jcul 3mo ago
  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.
- ludicrousdispla 3mo ago
  So, technically, the border agents wiped the phone. I wonder how specific their request was of Tunick when they asked for the password.
  - dqv 3mo ago
    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 https://blogs.illinois.edu/view/25/574827
- inigyou 3mo ago
  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.
- grapheneos 3mo ago
  > 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).
ris 3mo ago
I hate this meme. The point is to at least make them resort to hitting you with the $5 wrench, at which point they're probably committing a more serious offence than what you're up for (dependent on country).
- moffkalast 3mo ago
  You end up getting hit by a wrench though, that doesn't sound like it ends well for you.
  - XorNot 3mo ago
    Liberty is given up in inches, not miles. 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.
  - iamnothere 3mo ago
    Sounds like something a coward would say, honestly.
    - moffkalast 3mo ago
      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.
  - tarpitt 3mo ago
    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.

rzk 3mo ago

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. [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-protester-phone 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-Medhurst-had-his-mobile-phone-seized-Did-using-a-secure-phone-protect-his-data https://www.computerweekly.com/feature/Journalist-Richard-Me...

microtonal 3mo ago
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).
- msh 3mo ago
  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.
  - choo-t 3mo ago
    Because you may need the data in the data during/after your travel and lack clean way to access safely, securely and anonymously remotely.

deleted 3mo ago

[deleted]

deleted 3mo ago
[deleted]

deleted 3mo ago

[deleted]

prmoustache 3mo ago

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.

ButlerianJihad 3mo ago
[flagged]

muyuu 3mo ago

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.

brendyn 3mo ago
Maybe because it was mistaken. I just set my grapheneos to a 35 character password to test it and it didnt seem to have any issue.
- b112 3mo ago
  Did ypu test using random characters after 30 chars?
- muyuu 3mo ago
  nope it was arguing that this is a difference with stock android and that it is 16 chars there, idk about that though
Cider9986 3mo ago
>>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.

londons_explore 3mo ago

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.

libroot 3mo ago
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.
- praguegolem 3mo ago
  Im skeptical of what the average lab can do on modern day hardware, but it's not something I would ever want to test my luck on.
  - one33seven 3mo ago
    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.
Aachen 3mo ago
If it was that easy, we'd just do that to get access to our own data on these devices. The OEM unlock toggle is a much-desired feature for a reason
KJs6ZxELzQM37O 3mo ago
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.

usern20260720 3mo ago

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

DeluluDon 3mo ago
That email chain sounds exactly like the TV show Severance
imkac 3mo ago
From GrapheneOS official account: Our duress PIN/password feature doesn't pretend that it can stealthily wipe the device. It properly implements what people expect it to do and does it safely. It isn't our role to choose how to use the feature including how to use it in a situation where there are potential consequences to it. We haven't implemented any features which are in any way specific to situations involving law enforcement. We aren't going to give people any legal advice on how to handle situations involving law enforcement. It isn't our role and does not make sense particularly since laws vary so much based on jurisdiction, context and how they're interpreted on a case-by-case basis. If people want legal advice, they should ask a lawyer for it. It's not possible to provide anything close to plausible deniability for wiping profiles. A deleted profile leaves behind metadata proving it existed in the device encrypted and Owner profile encrypted storage. There are a whole bunch of different ways it can be shown that it existed. ADB can be easily used to identify a wipe occurred and when it occurred. The standard approach used by forensic tools is connecting via ADB and they can easily add support for detecting this. It would be easy for non-experts to figure out how to do it especially with the guidance of a decent LLM. It would put users at risk who believe they can perform a stealthy wipe despite it not being possible. We do not want to provide a feature which cannot come close to working properly. Android's Private Space has a half-baked feature for hiding that the Private Space is enabled in the user interface for someone without access to the relevant unlock methods or ADB. There are multiple publicly known ways to identify a Private Space is enabled. These aren't treated as significant security vulnerabilities and fixes for it aren't backported to older releases. It isn't practical to cover all possible ways of detecting it even with the limited scope of only attempting to hide it in the user interface and not ADB. We don't plan to remove the feature but don't think it should have been implemented and wouldn't have done it ourselves. If we implemented a half-baked deniable wiping feature then the flaws would be discussed in this forum, our issue tracker and elsewhere on the internet. It would quickly become known to LLM models, which would be able to assist with detecting it. It would be incorporated into standard forensic tools and guides. This is not an approach we want to take with GrapheneOS. Our features need to work against adversaries aware those features exist. An adversary aware of the duress PIN/password existing doesn't have a way to tell it apart from a real PIN/password. They'll have to consider if a PIN/password provided to them could be a duress PIN/password even for users who don't use the feature. The feature is now going to be widely known about due to the news coverage and it's still going to work. On future devices, we want to add duress PIN/password support to the secure element as part of the Weaver rate limiting so it can't even be bypassed with an OS exploit.

ddtaylor 3mo ago

Does anyone know if the Motorola partnership is still on with GrapheneOS or how long until a phone is made available from them?

Cider9986 3mo ago
>within ~12 months, in 2027 https://news.ycombinator.com/item?id=49038982 https://news.ycombinator.com/item?id=49038982 Not from someone employed by the project but a frequent contributor.

t1234s 3mo ago

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.

Cider9986 3mo ago
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.
- t1234s 3mo ago
  they need a shortcut where you triple tap the power button and it just does a fast hard power off similar to removing the battery.
siilats 3mo ago
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.

saidnooneever 3mo ago

[flagged]

Cider9986 3mo ago
He was put on a watchlist for protesting. I don't think the OS is what caused the unconstitutional detainment.
ksbd-pls-finish 3mo ago
>it was already pretty much impossible to get an encrypted device past US Customs more than 15 years ago B-but I did it many times? Or do you mean that it's impossible to refuse providing the decryption key and still pass? That's pretty obvious.

CommanderData 3mo ago

Here's an idea: soft duress PIN that wipes a list of apps of your choice however doesn't make it obvious it's done so. Or restores app data to a restore point of your choosing making it seem like everything is fine. Make it untraceable you had it setup and it'll help deal with any potential legal issues.

Cider9986 3mo ago
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.
grapheneos 3mo ago
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.

jdsfijfdsifs 3mo ago

[dead]

arkhiver 3mo ago

[dead]

b8 3mo ago

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.

grapheneos 3mo ago
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.

himata4113 3mo ago

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.

kmeisthax 3mo ago
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.

reindeer2 3mo ago

[flagged]

LWIRVoltage 3mo ago

( roughly copying my post from another thread) A few things: #1. The download and restore backup method would work for people in general- except it doesn't capture what people would need. Exmaple: I have some thermal cameras that rely on old 32 bit apps that do not run on anything android 12 onwards- If i wipe those old phones, and restore- the apps often wanted to reach out to a server for initial activation- they would fail upon reinstall and i'd be out of the apps that are required to control my cameras and related equipment,which is worth thousands and thousands and thousands. And it'd be all dead weight and rendered useless. (and competitors today do not compete- for example try finding a 640*480 30 hz or better form factor thermal camera that attaches to phones - they dont exist anymore) \The solution is full imaging- but there isnt a way to fully image phones and restore backups today. There used to be it seems- but not really with the latest stuff at the time of this post . On another note:Veracrypt- The weakness of truecrypt and veracrypt, the hidden OS option only worked if you converted your computer to MBR, which means you can't have a hard drive too large. Making a UEFI hidden OS has not been done yet. And the Hidden Volume option- isn't 'as' useful, and of course, your OS might make a copy and put it somewhere, you have to be careful. As a example: Any time I open a file, using the software tool Everything to search and confirm this- you can easily see Windows makes copies and temp files and whatnot in randomly named locations- that's the sort of behavior that would screw people over We need fully image-backup capable Phones. I mean fully. Not just backing up some apps- as this refuses to backup apps you have that are no longer on app stores, or that Play Protect doesn't like, etc. Next- Plausible deniability is a way forward- but you need multiple profiles, that are cryptographically indistinguishable, along with the phone being hardened so GreyKey /Cellebrite won't be able to exploit a way in. This needs to be built this way from the ground up ideally, eventually. There has been research about making devices that treat all block space the same way so you can't tell if someone has 1, or 50 profiles or partitions, etc- and even stuff that overlaps. Often it needs to be fixed size partitions, but it is apparently NOT impossible to create. I am aware of Shufflecake attempting to make a solution for Linux, and yes, a Hidden OS option that is forensic- invisible. But nothing has come out - and especially, for phones. I hope Graphene OS or another group, eventually works on this for phones. I do wonder if it would require a Linux phone, or something built from the ground up rather than current phone architecture. It would be nice to see the day where, if you travel to a hostile country, you can tell them you have just one profile, and if they ask, you could theoretically mention a 2nd, and then show it- but you might have 3 more - and they'd all be immune to forensic inspection if the system is built right.(Yes, there's often issues you have to be careful of ,like setting this up so you dont destroy data when in other profiles,) This is how you solve this problem in the long run-make computing devices impossible to analyze, but standard.