@final
stacking since: #193385
0 sats \ 0 replies \ @final OP 19 May \ parent \ on: GrapheneOS discusses leaked Cellebrite phone exploit documentation security
No. The documentation is saying GrapheneOS is the only OS sufficient to protect you from this in the long-term because they can't exploit the device, only extract data if the owner of the device gives the password away.
If you have a higher threat model, then use a stronger passphrase that cannot be brute forced (which prevents you trusting the secure element) and reduce the auto reboot time.
I don't post other topics on social media much but this is unintentionally one of the funniest articles I've ever read. The macro zoom pic of the McDouble seals it. Hilarious.
Had no idea a bitcoin-themed football club existed in England. Congratulations to them on the promotion!
It appears you can watch them live when they play too: https://www.realbedford.com/live-stream
Pixel 8 is far above the 7 because it has Hardware Memory Tagging exclusive to it. GrapheneOS is the only OS using it in production right now, but it's an extremely large hardware-based security feature that provides memory safety for memory-unsafe code.
While it sounds boring to things the user sees like the Vanadium browser or what not, it's our biggest security feature of the OS. Almost all major vulnerabilities on the Android platform are to do with memory corruption.
Outside of GrapheneOS, the Pixel 8 also has 7 years of update support. If you aren't the type to buy a phone every couple of years then it's a good choice.
You can do WiFi calling/texting but you're still trusting the mobile network when doing this. If you lack public WiFi then there isn't a lot you can do about this though. You're better off hoping to move people away from these insecure services over time.
Made a reply of this on Nostr already but this is a Google Play feature that won't work on GrapheneOS. It's just a Android equivalent of Apple's Find My. It uses Bluetooth and it needs to be configured to work like this and also enabled by the OS.
If it's based on hardware, would changing the OS make a difference?
It would make a difference. The Pixels supporting this were released before the feature. It needs to be enabled by the OS. You use software to interact with your hardware all the time and this is no different, if you don't allow it, then it can't do it. A device finder is something a lot of GrapheneOS users seem to request but if that's going to happen it must be an opt-in.
(For some reason I didn't get the @ for this in my notifications... would have replied to this thread faster if I saw this earlier)
cc: @teemupleb
Why did eSIM previously rely on google services, but now it doesn't?
There are now additional shims to make it work without the sandboxed Google services. This is an example of a commit for it: https://github.com/GrapheneOS/platform_frameworks_base/commit/813cd8f45d0a49bb6775453ef0744441f133f6ef
Activating an eSIM would perform data sharing with Google services. The EuiccGoogle package alone doesn't send data directly to Google, so isolating it from the Google services and making it work standalone helps. We also have a toggle to completely disable that binary which is enabled by default.
So the stock OS eSIM package is open source so there is also no reason to use anything else?
It's part of a closed source package. At the time it was the only package allowing eSIM activation and today it is still the only package allowing all the relevant features. One of the Google eSIM apps handle the updates for the eSIM secure element's firmware, which is needed for security updates.
Any idea how the CalyxOS eSIM support works compared to Graphene? CalyxOS doesn't seem to indicate much about what they are doing with eSIM.
They use the same Google packages but without the toggle to deactivate or isolating it.
Generally I'm wondering if any eSIM tools in android can help with https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/485 .
If someone put their time into it, maybe? Wouldn't really know, not looked at this.
We've also made reports on Bluetooth LE memory corruption bugs. We have no reason to believe they are exploited as the bugs were uncovered from our security features breaking it when the recent Android 14 QPR2 upgrade happened.
They're patched in GrapheneOS, they also were marked as a high-quality, high-severity report. Judging by how long it took Google to discuss them then it may take a couple months or less.
Missing features and implementation issues. It doesn't support all carriers nor implement all the required baseline functionality including wiping of eSIMs, which the future duress password feature plans to erase.
We allow eSIM activation without any Google services, it uses the stock OS package but totally isolated and isn't dependent on any Google Play services. There is little to no privacy improvement either as you need to make connections to the provider to activate eSIM regardless. There isn't much value in working on one for GrapheneOS for that reason either.
A lot of the failures come down to people just not reading and understanding what GrapheneOS does and doesn't do before they choose to install it. Giving the docs a read should give everyone the best foresight.
A couple people I know have tried out Graphene but decided that the extra work/hassle wasn't worth it, mostly because they're "doxed" in other ways anyway, so why take a bunch of trouble with Graphene. But I'd still like to try it.
The merits of using GrapheneOS aren't worthless if you are a public person or not. You'd still have a more secure device using GrapheneOS and security is very important for everyone. Many of the security enhancements for GrapheneOS are seamless and aren't seen or touched by most users.
A completely average person could (and many do) use GrapheneOS as a normal phone. They'll use all the Google services and apps and mainstream social media but with better security and privacy than on the stock OS. Many people completely miss the mark and refuse to use GrapheneOS thinking it isn't okay to use it like this, you have the option to at your discretion. The Sandboxed Google Play compatibility layer is there for that.
Is there an article or something with a list of of functionality that the Graphene doesn't give you? For instance, if you definitely must have X feature, then don't bother with Graphene?
Some reasons you may not use GrapheneOS are:
- You must have contactless credit/debit card payments with Google Pay.
- You must use an app that blocks running on anything but a Google-certified OS (Google Pay contactless requires this), A small run of bank apps do this, installing Sandboxed Google Play would fix apps that don't do this.
- You require an oddly specific Stock OS feature no matter what.
Most of these are fixed by having a second phone, but, may be a deal breaker to some.
Check the posts on SN about GrapheneOS, I also made a lot of posts about GrapheneOS on here in the past and I have used it for several years, I strongly recommend giving it a try. Since those posts I've now made a close relationship with GrapheneOS so I am not neutral in my answers.
We definitely don't have people for this and a hardware OEM would need to work on that, plus it seems may seem a bit out of what GrapheneOS is focused on as a mobile/security privacy non-profit. Although it could be a nice thing.
In the past there had been ideas of a phone that could essentially have a Trezor or equivalent built into it with a whole separate display on the back and completely isolated, but it already works as separate hardware anyway.
A serious OEM could make a phone with this in mind and make an ecosystem with it. Android keystore API could have support for secp256k1/Schnorr added and then apps could use additional secure element support for it. In practice someone could add that as an extension implementation, but it would need to be part of the stock Android standard apps APIs for app devs to consider using it. It wouldn't really be much of a hardware wallet alone since there's no secure display.
The open hardware would be more of a ethical choice than a security or privacy one. If it did use an open hardware design, there would still be just as much trust in the manufacturing for each component you buy like an SoC or secure element. The manufacturing process itself isn't open, and makes up a lot of their complexity.
Trezor do quite a similar job to what you describe, people build their own, they also do GPLv3: https://www.instructables.com/Making-My-Own-Trezor-Crypto-Hardware-Wallet/
https://github.com/trezor/trezor-hardware/tree/master/electronics
The issue is the Trezor's before Safe 3 don't have a secure element so strong PIN/passphrase and other remediations needed to protect physical attacks.
side note: Electronics is not my strong spot at all.
After First Unlock. When a device is powered on, encryption keys to decrypt data are not in use until you use the device credential for the first time. With BFU (Before First Unlock) these are at rest in the Pixel's secure element. There is a huge difference between a device not unlocked once after boot and a device that is when it comes to exploitable attack surface.
We do provide extended support releases for these devices but they have many missing features and are meant to help users transition to a newer device. The newer Pixels aren't just faster, they're more secure, especially the Pixel 8 and later thanks to hardware memory tagging.
The unsupported/extended support devices do not get firmware or driver fixes, any vulnerability incorporating them remains unpatched. Using a heavily insecure unsupported device with many missing patches as a wallet may not be the best choice, especially if you're relying on it for other sensitive manners. You could thrift it and buy a signing device in some cases. Likewise, if a phone is seized that actor can sit and wait how long he wants until an exploit in the secure element is uncovered which allows him to brute-force.
Having a dedicated user with a stronger passphrase just for managing cryptocurrencies could help especially if you have a larger (but not cold storage worthy) amount. All of it's data would be encrypted and at-rest when not in use and it won't be active if you have another profile in use providing you set up the options. I do this to handle other currencies or PayNym payments. An additional user also makes it harder for the threat actor in the scenario above, as the profile would be at rest and could not be unlocked via a RAM dump brute-force unless the dump occurred while the profile session was active. Would need to have an exploit for the secure element like the device was in BFU otherwise.