Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

GrapheneOS protections against data extraction from locked devices

discuss.grapheneos.org

Post reply on HN
Print view View original

221–230 of 284 posts

Re: GrapheneOS protections against data extraction from locked devices

#221

Post by gruez »

dredmorbius wrote: post #219
gruez wrote: post #215

Earlier quoted context omitted.

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 activ…

Who carriers around a phone that doesn't have any activity for months/years? An activity-generator might help address that.

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.

Re: GrapheneOS protections against data extraction from locked devices

#222

Post by grapheneos »

gruez wrote: post #180
grapheneos wrote: post #172

Earlier quoted context omitted.

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

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.

Re: GrapheneOS protections against data extraction from locked devices

#223

Post by Cider9986 »

cromka wrote: post #213
Cider9986 wrote: post #124

Earlier quoted context omitted.

Not possible to have a robust implementation with the current tech unfortunately. https://veracrypt.io/en/Wear-Leveling.html

Interesting, did not know that! They do say some hardware, though, is phone's solid state storage definitely affected?

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.

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

Re: GrapheneOS protections against data extraction from locked devices

#224

Post by grapheneos »

b8 wrote: post #190

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 lea…

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.

Re: GrapheneOS protections against data extraction from locked devices

#225

Post by praguegolem »

libroot wrote: post #76
londons_explore wrote: post #49

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.

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.

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.

Re: GrapheneOS protections against data extraction from locked devices

#226

Post by dredmorbius »

gruez wrote: post #221
dredmorbius wrote: post #219

Earlier quoted context omitted.

Who carriers around a phone that doesn't have any activity for months/years? An activity-generator might help address that.

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.

Those are ... relatively minor concerns.

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

Re: GrapheneOS protections against data extraction from locked devices

#227

Post by rkagerer »

grapheneos wrote: post #174
prmoustache wrote: post #9

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…

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 bac…

One clarification:

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

Re: GrapheneOS protections against data extraction from locked devices

#228

Post by gruez »

dredmorbius wrote: post #226
gruez wrote: post #221

Earlier quoted context omitted.

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.

Those are ... relatively minor concerns. 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).

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

Re: GrapheneOS protections against data extraction from locked devices

#229

Post by prmoustache »

grapheneos wrote: post #174
prmoustache wrote: post #9

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…

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 bac…

thanks for chiming in.

Re: GrapheneOS protections against data extraction from locked devices

#230

Post by Marsymars »

inigyou wrote: post #133
microtonal wrote: post #56

Earlier quoted context omitted.

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…

"I'm here for business and my employer requires it" is an acceptable excuse. "I don't like government surveillance" is not.

"I'm self-employed and my SOC 2 compliance consultant requires it."
Post reply on HN