6 ms·

> ...but never once mention what sort of threat model they are private/secure against. You know, they're Secure(TM)! Against Threats(TM)! Buy me if you're sc

by Syonyk 2y ago

> ...but never once mention what sort of threat model they are private/secure against. You know, they're Secure(TM)! Against Threats(TM)! Buy me if you're scared of Threats(TM)! Threat modeling ("Secure from who? Under what conditions?") sort of stuff just doesn't seem to be a thing that's taught these days outside certain weird circles. And certainly something this project hasn't touched on in the slightest. But, yes, I was having to keep my eyeballs constrained too. As much as it pains me, I think the most "generally secure phone" out there, for at least the sort of threat models this phone handwaves at (journalists, human rights activists) is a recent (last generation or two) iPhone with Lockdown enabled - and then shut down nightly, and carried shut down through any sort of sensitive environments. I would be inclined to go with an iPhone SE3, moreso than one of the mainline devices, simply for fingerprint scanning versus the FaceID stuff. You can't "point a phone at me" and unlock it with my fingerprint, but you can with FaceID in a wide enough range of situations to be concerning. Set a longer than usual PIN/passphrase, and be careful where you enter it. As far as I understand the boot process, Apple has largely fixed a lot of the "before first unlock" type attacks with their secure enclave. They fixed that rather well after the battle with the FBI, and seem to have continued hardening and improving that process (hence my recommendation for the latest generation or two of device - there are changes in the boot security flows every now and then, and I assume they matter, at some point). Then Lockdown, as near as I can tell, does a very fine job of simply closing the common attack points used. Most of the "good" attacks on iPhone users (at least the ones I know of...) are through the various "texting-esque" endpoints with weird image formats, or a browser based Javascript/JIT exploit, and Lockdown does a fine job of simply refusing most of the paths these use. Weird image formats simply aren't rendered. URLs in text messages aren't accessed and previewed. The Javascript engine removes all JIT capabilities, WebRTC, WebGL, and other "suitably complex that it's probably exploitable" sort of features. It's not perfect, but were I an individual who believed I was under actual threat for this sort of stuff, I'd 100% use a secured iPhone (possibly with some of the Mobile Device Management features configured by a trusted person to disable the USB port and such things) over a random device like this. Sorry, open JTAG ports means it's "comically insecure" against anyone with local access and the time to bother doing anything with it. And of course, don't keep location services on, don't install a ton of apps, etc. The usual if you're concerned about any of this. I don't like that this is the state of the world of secure computing, but it certainly seems to be it, to me.

nonrandomstring 2y ago
> You know, they're Secure(TM)! Against Threats(TM)! This is thought provoking because I get your sentiment against half-baked ideas of "secure" and "threat", but then you start talking about cameras, fingerprint readers and boot processes... These have nothing to do with phones as I see them. For me a secure phone is the minimum viable device to make a voice communication (and perhaps short text messages at a stretch). So what's going on here is woolly ideas about function. If we define a "phone" as a multi-purpose personal computer, address book, secure storage device, video player, film camera etc, then it's going to have very different security parameters than a simple "telephone". So we can't talk about threats and security until we have talked about function. As we define (or rather fail to define) a 'phone' today it has almost no functional boundaries, and so there's no model around which to define security. The minimal RISC-V device outlined in the article looks like the kind of thing that could be customised to constrain functionality in such a way as to add security. It obtains that possibility by giving control to the end user around what not to include.
gruez 2y ago
>As far as I understand the boot process, Apple has largely fixed a lot of the "before first unlock" type attacks with their secure enclave. They fixed that rather well after the battle with the FBI, and seem to have continued hardening and improving that process (hence my recommendation for the latest generation or two of device - there are changes in the boot security flows every now and then, and I assume they matter, at some point). It's worth pointing out that even the latest iPhones are vulnerable after first unlock (AFU), which means if your phone gets seized and you don't have time to turn it off, they can get a full dump of your phone. https://discuss.grapheneos.org/d/14344-cellebrite-premium-july-2024-documentation https://discuss.grapheneos.org/d/14344-cellebrite-premium-ju...
- Syonyk 2y ago
  And this is a good reason to keep your smartphone turned off regularly. I really don't have a great answer. I'm aware Graphene offers some substantial benefits too, but it's also somewhat harder for a non-technical user to use. Unfortunately, when the attacker has unlimited physical access, a device can and will fall, given time and resources.

by Syonyk 2y ago

nonrandomstring 2y ago

> You know, they're Secure(TM)! Against Threats(TM)! This is thought provoking because I get your sentiment against half-baked ideas of "secure" and "threat", but then you start talking about cameras, fingerprint readers and boot processes... These have nothing to do with phones as I see them. For me a secure phone is the minimum viable device to make a voice communication (and perhaps short text messages at a stretch). So what's going on here is woolly ideas about function. If we define a "phone" as a multi-purpose personal computer, address book, secure storage device, video player, film camera etc, then it's going to have very different security parameters than a simple "telephone". So we can't talk about threats and security until we have talked about function. As we define (or rather fail to define) a 'phone' today it has almost no functional boundaries, and so there's no model around which to define security. The minimal RISC-V device outlined in the article looks like the kind of thing that could be customised to constrain functionality in such a way as to add security. It obtains that possibility by giving control to the end user around what not to include.

gruez 2y ago

>As far as I understand the boot process, Apple has largely fixed a lot of the "before first unlock" type attacks with their secure enclave. They fixed that rather well after the battle with the FBI, and seem to have continued hardening and improving that process (hence my recommendation for the latest generation or two of device - there are changes in the boot security flows every now and then, and I assume they matter, at some point). It's worth pointing out that even the latest iPhones are vulnerable after first unlock (AFU), which means if your phone gets seized and you don't have time to turn it off, they can get a full dump of your phone. https://discuss.grapheneos.org/d/14344-cellebrite-premium-july-2024-documentation https://discuss.grapheneos.org/d/14344-cellebrite-premium-ju...

Syonyk 2y ago
And this is a good reason to keep your smartphone turned off regularly. I really don't have a great answer. I'm aware Graphene offers some substantial benefits too, but it's also somewhat harder for a non-technical user to use. Unfortunately, when the attacker has unlimited physical access, a device can and will fall, given time and resources.