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

211–220 of 284 posts

Re: GrapheneOS protections against data extraction from locked devices

#211

Post by cromka »

gruez wrote: post #92
cromka wrote: post #43

Earlier quoted context omitted.

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

>I believe LUKS is capable of that Booting into a 30 GB partition on a 128GB phone is going to be mega suspicious, even if the remaining data is random.

There are ways around it AFAIK.

Re: GrapheneOS protections against data extraction from locked devices

#212

Post by cromka »

prmoustache wrote: post #109
cromka wrote: post #43

Earlier quoted context omitted.

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

Having different data partition forces you to hide stuff, which can be unlawful in some juridictions. Not having the data in the first place in some specific contexts (like crossing borders) is easier.

Fair.

Re: GrapheneOS protections against data extraction from locked devices

#213

Post by cromka »

Cider9986 wrote: post #124
cromka wrote: post #43

Earlier quoted context omitted.

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

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?

Re: GrapheneOS protections against data extraction from locked devices

#214

Post by rustyhancock »

usern20260720 wrote: post #57

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

Agreed and it's not even conceptually hard.

Perhaps the solution is that some apps and data is in a locked area that would require a further pin once the device is unlocked.

So the duress pin unlocks the device but wipes that region.

It then appears that the secure or locked part was never setup.

I think many OSs offer Locked data options, Google Photos, Samsung etc.

Re: GrapheneOS protections against data extraction from locked devices

#215

Post by gruez »

cromka wrote: post #211
gruez wrote: post #92

Earlier quoted context omitted.

>I believe LUKS is capable of that Booting into a 30 GB partition on a 128GB phone is going to be mega suspicious, even if the remaining data is random.

There are ways around it AFAIK.

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.

Re: GrapheneOS protections against data extraction from locked devices

#216

Post by mystifyingpoi »

prmoustache wrote: post #207
mystifyingpoi wrote: post #117

Earlier quoted context omitted.

> "selfhosting a cellphone at home with some kind of remote access system You can use TeamViewer for that. Or maybe scrcpy could be coerced into working in a similar way.

Good luck making it work again remotely after a long power outage.

Not sure what do you mean? If that is a concern, there are solutions for this. Like UPSes and backup cellular connections.

Re: GrapheneOS protections against data extraction from locked devices

#217

Post by dredmorbius »

rzk wrote: post #4

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

The Guardian story discussed on HN: https://news.ycombinator.com/item?id=49024436>.

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

Re: GrapheneOS protections against data extraction from locked devices

#218

Post by iamnothere »

xnickb wrote: post #210
iamnothere wrote: post #188

Earlier quoted context omitted.

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

No you just chose to ignore other cases that OP mentioned and focused on this one

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.

Re: GrapheneOS protections against data extraction from locked devices

#219

Post by dredmorbius »

gruez wrote: post #215
cromka wrote: post #211

Earlier quoted context omitted.

There are ways around it AFAIK.

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.

Re: GrapheneOS protections against data extraction from locked devices

#220

Post by dredmorbius »

gruez wrote: post #92
cromka wrote: post #43

Earlier quoted context omitted.

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

>I believe LUKS is capable of that Booting into a 30 GB partition on a 128GB phone is going to be mega suspicious, even if the remaining data is random.

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.

Post reply on HN