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

71–80 of 284 posts

Re: GrapheneOS protections against data extraction from locked devices

#71

Post by hamper653 »

microtonal wrote: post #56
inigyou wrote: post #54

Earlier quoted context omitted.

It's one that will get you denied entry, or detained indefinitely.

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…

> Probably different for the US though.

After cornering themselves into being labeled an unsafe destination (long overdue imho), the US are gonna have to learn being treated as such.

Re: GrapheneOS protections against data extraction from locked devices

#72

Post by muyuu »

brendyn wrote: post #62
muyuu wrote: post #48

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

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.

nope it was arguing that this is a difference with stock android and that it is 16 chars there, idk about that though

Re: GrapheneOS protections against data extraction from locked devices

#73

Post by flexagoon »

prmoustache wrote: post #40
microtonal wrote: post #12

Earlier quoted context omitted.

A replacement for SeedVault is planned: https://grapheneos.org/features#encrypted-backups https://github.com/GrapheneOS/os-issue-tracker/issues/4687#i...

Neat, I didn't realize it was still included. I thought it had been abandonned. So basically one needs a webdav server somewhere or an usb flash drive.

I use Seedvault to create a backup locally on my phone, and then sync it to my backup server with Syncthing

Re: GrapheneOS protections against data extraction from locked devices

#74

Post by bornfreddy »

flexagoon wrote: post #31
Voklen wrote: post #18

Earlier quoted context omitted.

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

There has been a lot of conflict between Calyx and GrapheneOS a while ago.

[flagged]

Re: GrapheneOS protections against data extraction from locked devices

#75

Post by dqv »

ludicrousdispla wrote: post #61
bigyabai wrote: post #3

Earlier quoted context omitted.

Relevant news story: 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 sur…

So, technically, the border agents wiped the phone. I wonder how specific their request was of Tunick when they asked for the password.

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

Re: GrapheneOS protections against data extraction from locked devices

#76

Post by libroot »

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.

Re: GrapheneOS protections against data extraction from locked devices

#77

Post by kotaKat »

choo-t wrote: post #45
msh wrote: post #34

Earlier quoted context omitted.

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.

Because you may need the data in the data during/after your travel and lack clean way to access safely, securely and anonymously remotely.

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

Re: GrapheneOS protections against data extraction from locked devices

#78

Post by [deleted] »

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…

[deleted]

Re: GrapheneOS protections against data extraction from locked devices

#79

Post by SuperShibe »

microtonal wrote: post #12
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…

A replacement for SeedVault is planned: https://grapheneos.org/features#encrypted-backups https://github.com/GrapheneOS/os-issue-tracker/issues/4687#i...

It's been planned for years...

Re: GrapheneOS protections against data extraction from locked devices

#80

Post by kungito »

microtonal wrote: post #29
Tanoc wrote: post #21

Earlier quoted context omitted.

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.

sounds to me like iphone isnt actually that safe otherwise it wouldnt make sense. maybe we are missing some critical information
Post reply on HN