Hypothetical: Phone is stolen while being used - Remote wipe useful?

aquila-enu

I've been wondering, since GrapheneOS doesn't have a native remote wipe feature (or not that I know of), what if your phone is stolen right off your hand while you're using it?

Assuming you have an auto lock every 15s of inactivity and that you have a 10-digit PIN to unlock your screen, your phone is in an AFU state. Say, you're chasing the thief down the road for more than 15s, at the very least, you can be assured that your phone is in a locked mode.

But, how secure/difficult is it for the thief to access your data in an AFU state with the 10-digit PIN?

Another scenario is, what if, for convenience purposes, you have auto lock once every 30 mins (the max option in the settings), and you're done chasing the thief before 30 mins pass. Your phone will be unlocked then and without a remote wipe, they will be able to access your phone.

In this scenario, is having a 30 min auto lock not a good security practice? And if so, why is the option there? Tyvm.

matchboxbananasynergy

aquila-enu But, how secure/difficult is it for the thief to access your data in an AFU state with the 10-digit PIN? If it's safe enough, I see why remote wipe isn't that useful.

They would need an exploit of the OS, and note that they have a limited window of opportunity (18 hours by default, but can be as little as 10 minutes) via the auto-reboot feature, which gets the device back to BFU. With a 10 digit PIN, you're relying on the secure element's throttling for security. In order to bruteforce it and get in, they'd need a secure element exploit, which isn't an easy ask.

A "remote wipe" is tricky. How is it triggered, and how trivial is it to stop? If it requires sending an SMS, for example, all the thief has to do is put the phone in a faraday bag, and you can no longer do anything.

matchboxbananasynergy

aquila-enu Another scenario is, what if, for convenience purposes, you have auto lock once every 30 mins (the max option in the settings), and you're done chasing the thief before 30 mins pass. Your phone will be unlocked then and without a remote wipe, they will be able to access your phone.

In this scenario, is having a 30 min auto lock not a good security practice? And if so, why is the option there? Tyvm.

This scenario is trickier, that's for sure. Google is tackling that via a Play Services update that will come with Android 15. It is unlikely to work on GrapheneOS as I imagine it'll require high privileges which GrapheneOS doesn't grant Play Services, but it goes a little bit like this:

Assume you have your phone unlocked and holding and using it in your hands. A mugger runs up, snatches the phone and runs away. The phone detects the sudden movement and automatically locks itself.

GrapheneOS could implement something similar using the device's sensors. It's unlikely to be as fancy and sophisticated as Google's implementation with all of its machine learning and whatnot, but it might just be effective enough.

de0u

aquila-enu What if, for convenience purposes, you have auto lock once every 30 mins (the max option in the settings), and you're done chasing the thief before 30 mins pass. Your phone will be unlocked then and without a remote wipe, they will be able to access your phone.

If a thief grabbed your phone and outran you in a chase, now you have no phone with which to remotely wipe your stolen phone -- especially not if the thief turned your stolen phone off and/or yanked the SIM card.

I think I've seen apps that lock a phone if the accelerometers detect a drop. In that case, dropping the phone while initially wrestling with the thief would be helpful.

I think people have also suggested it would be nice to have an app that would lock a phone if it fell out of contact with some BLE beacon, but I am not aware of such an app.

aquila-enu

matchboxbananasynergy You responded much faster than I edited my post ^^" Thanks for your response. I added a second scenario btw.

How remote wipe is implemented, I'm not sure. I'm not a techy person and I only know of an SMS or Internet connection. You're right in saying that a faraday bag would disable all these methods, but what are the odds of a petty thief carrying a faraday bag with them? If the thief is non-techy like me, they would probably just carry a normal bag. Would you then see a value in having a remote wipe there?

matchboxbananasynergy

aquila-enu A petty thief is also very unlikely to be aware of any OS exploits to unlock the phone with. Even more unlikely, they won't have a secure element exploit to bruteforce the PIN once auto-reboot kicks in to put the device back to BFU.

They're much more likely to try and pawn the phone off after wiping it in recovery.

If you want to be mischievous about it, you could set a duress PIN/Password, and put either in a paper slip between the case and the phone. Maybe you can trick them into thinking you wrote it down in case you forget it, they try to input it, and wipe the phone themselves.

aquila-enu

matchboxbananasynergy Funny you mentioned duress PIN. I literally just checked my security setting after your reply to see what is the duration I have set for auto restart, and there, I noticed Graphene has a new Duress PIN/Password feature! Off topic, I wonder if there is a newsletter or news I can subscribe to for when GrapheneOS released new features?

aquila-enu

matchboxbananasynergy Oh, that's actually clever. Yeah, if motion-based lockdown or even better, restart can be triggered based on this, that'd be awesome. I fail to see how machine learning plays a big role in this kind of feature, but any "simpler" implementation of this would be sweet. Thanks a lot for your time to have me feel rest easy.

matchboxbananasynergy

aquila-enu https://grapheneos.org/releases.atom in an RSS/Atom feed reader, and you'll be notified of new OS releases. :)

aquila-enu

de0u If I couldn't outrun the thief, I'd probably take out my laptop to do a remote wipe quickly - assuming no faraday bag involved. Granted, you will probably need to find a public place for internet access, which is another layer of challenge.

matchboxbananasynergy

aquila-enu fail to see how machine learning plays a big role in this kind of feature,

The phone "learning" how you usually use it/handle it could reduce false positives, whereas a "simple" approach that uses device sensors and locks when a certain threshold using the accelerometer is exceeded could result in false positives where the phone locks on you while you're using it if you make a sudden move for whatever reason. Likely not the end of the world, admittedly, but something to think about when considering a potential implementation.

aquila-enu

matchboxbananasynergy Got it, tyvm. Also thanks for the RSS link :D