What Cellbrite tool are used for a Physical Extraction (with user consent)? Physical Analyzer?
Cellebrite Premium July 2024 documentation
A few months ago, I was given a "behind the scenes" tour of a US forensics lab. Part of this included viewing their Faraday vault and mobile extraction solutions. I didn't pry too much but was told that unless the device was setup improperly (bad screen lock, only fingerprint, etc), "modern pixels running GOS" were not in their scope. I offered to have them test my phone but unfortunately all their units (confirmed cellebrite, unsure on further details) were being used.
- Edited
GrapheneOS Can you point to a fuller explanation of the fingerprint+code unlock?
My fingers are quite calloused (I assume that's the reason) and frequently fail on fingerprint unlock.
I'd hate for this to be the unchangeable default method of accessing my device. I'd be locked out 80% of the time.
rocky-planet It is manually enabled after you've added a fingerprint.
https://discuss.grapheneos.org/d/18585-2-factor-fingerprint-unlock-feature-is-now-fully-implemented
GrapheneOS when you say 'support for the new iOS versions', do you mean AFU only?
I have a few questions. Apologies if this has been stated already... (if it has, pls refer me to the post)..
- What access, if any, does celebrite have to data on an iOS with 8 (or more) digit alpha numeric, 10 login limit, in BFU?
- What iOS versions is data able to be accessed (as per above question).
- When the matrix refers to BFU - Yes, BF - no. What is the BFU exploit that is happening? and is this exploit available for 8 (or more) alphanumeric login in BFU?
- Are there any devices that celebrite can access the data when in BFU mode with 8 (or more) alpha numeric passcode?
- can we access the latest celebrite support data anywhere?
GrapheneOS How is the security of Linux against these exploits as compared to macos?
n2gwtl It depends what you mean by Linux. If you mean traditional desktop Linux distributions, they're much worse than macOS which is much worse than iOS. We'd say that the stock Pixel OS is slightly worse than iOS overall right now but GrapheneOS does much better. Please bear in mind ChromeOS, the stock Pixel OS and GrapheneOS are Linux distributions too.
- Edited
GrapheneOS I should be more specific. I have been on the market for a new computer for some time, and I cannot decide between another macos laptop or the framework desktop. I have looked at this site which covers full disk encryption, TPM 2.0, systemd-boot, and secure boot. I thought if I enabled all of this on Fedora, I would have a reasonably secure system without all of the Apple privacy concerns.
n2gwtl Fedora on a Framework laptop will provide essentially zero physical security with no protection against data extraction after you've entered the encryption passphrase. It will only protect your data while the device is powered off. macOS on a Mac will provide far better physical protection. macOS will also be harder to exploit.
TPM 2.0, systemd-boot, and secure boot
The implementation of secure boot and attestation by both that hardware and the OS (Fedora) is incomplete and insecure. It provides no real world security benefits. It neither provides against attacker persistence after exploitation or physical attackers. It's work towards real security features without getting to the point that it actually works. It's similar to locking your front door on a house where there are no walls, just a wooden frame people can step through. It does not deter an attacker.
- Edited
According to this specialist, iPhones running iOS 18 are not exploited
https://m.youtube.com/watch?v=Wan4CdDAqUs&pp=ygUKZ3JhcGhlbmVvcw%3D%3D
- Edited
Locart According to this specialist
He is not a specialist and his video contains errors, that said, he seems to be acting in good faith, yes a modern iPhone is pretty good when it comes to security (much better than most Android devices) and he cites GrapheneOS as the best solution currently, he says he'd rather make a dedicated video of it, which will probably also contain errors.
The comment section is 99.9% full of nonsense and inaccuracies.
- Edited
n2gwtl I should be more specific. I have been on the market for a new computer for some time, and I cannot decide between another macos laptop or the framework desktop. I have looked at this site which covers full disk encryption, TPM 2.0, systemd-boot, and secure boot. I thought if I enabled all of this on Fedora, I would have a reasonably secure system without all of the Apple privacy concerns.
As it looks, Cellebrite has relied solely on USB exploits when attacking Android. Most traditional Linux desktop distributions, including Fedora, does not implement any security against USB exploits at all. The only desktop operating system I am aware of with strong USB security is QubesOS. QubesOS protects against USB exploits to a similar degree as GrapheneOS, it is a very adequate protection. QubesOS also offers some protection against you unknowingly plugging in a malicious USB device when your screen is unlocked, which GrapheneOS does not. USB security was a primary design goal for QubesOS.
Still, you shouldn't expect that much physical security on a desktop computer while it is running and your encrypted disk is unlocked. Phones have always been far ahead in physical security, since the likelihood is far higher that a phone gets taken while powered on. Computers are usually only located in trusted places while powered on, such as your home or workplace. Phones you always carry with you, while they are powered on. So there have never been much priority to implement strong physical security for computers, as there have never been the same need for it. This means, the hardware and firmware itself often lacks support for implementing proper physical security in the desktop world.
Solution, power off your computer whenever you don't use it, so that the disk encryption key gets unloaded, and all your files become inaccessible without knowing your passphrase.
Locart I pointed out in his video that he's wrong about the automatic restart after 72 hours without user lockout, this isn't a Google feature, GrapheneOS introduced it around 2021 (I'm not sure of the date), the timer was set to 72 hours then reduced to 18 hours, Apple did the same thing then recently. I don't know if current stock Android (or Pixel OS) Pixels support auto-restart.
Don't get me wrong, his video is pretty good I think, he doesn't make any sensational speeches and you can see he's done some serious research, I thought I'd seen another mistake but I left it.
Locart Cellebrite's current documentation shows they can exploit iOS 18 and later versions. Cellebrite is also only one of the organizations developing these kinds of exploits. We have access to later documentation than July 2024, we just don't plan to publish it anymore to avoid the leaks to us being closed.
ryrona QubesOS doesn't protect against USB exploits while locked to the same degree as GrapheneOS because the USB controller and USB guest can be exploited. Containing the attacker to the USB controller and to a virtual machine for handling USB isn't comparable to eliminating most of the attack surface. The attacker getting code execution in the USB controller or a virtual machine is much more than not having something to exploit.
GrapheneOS provides much stronger protections against USB drivers being exploited. QubesOS provides much better containment and access control for USB. We do plan to add USB peripheral access control for users but it needs to avoid destroying usability. It's lower priority than a desktop/laptop due to how they're used.
Laptops / desktops don't have serious physical security so USB exploits are really not needed for exploiting them after the encryption passphrase is entered.
GrapheneOS Cellebrite's current documentation shows they can exploit iOS 18 and later versions
What sense is there to be afraid of Cellebrite if they use these vulnerabilities only to read the encrypted file system image? But the file system remains encrypted. A password longer than 10-15 characters does not even make sense to brute force. They cannot bypass password protection even on the Samsung S20 etc. All attempts to prevent access to the USB port are attempts to prevent reading the file system image, but no one will brute force a password longer than 10 characters. A good password, updating the system and rebooting the phone for a few hours - completely makes the phone invulnerable on any version of the latest OS. Sorry for my bad English
- Edited
Alllus Their give them access to essentially all of the data on the device for devices in the After First Unlock state which is the typical situation.
They cannot bypass password protection even on the Samsung S20
They can bypass passwords with brute force since people usually don't set strong random passphrases. Samsung devices do not successfully block brute force like modern iPhones and Pixels are doing successfully with their secure elements.
All attempts to prevent access to the USB port are attempts to prevent reading the file system image
No, that's not what they're doing. They're exploiting the device to gain control over it and access everything the OS can access, which is essentially everything on the device in After First Unlock state.
A good password, updating the system and rebooting the phone for a few hours - completely makes the phone invulnerable on any version of the latest OS.
Rebooting most Android devices doesn't clear the memory. People also often don't get a chance to reboot or power down in these situations even if they know that's a good idea.
Our locked device auto-reboot feature automatically returns the device to the Before First Unlock state in combination with other features for zeroing memory, etc. Before that, the device still needs to defend itself from being exploited.
Aside from that, a password is hardly immune to brute force unless you use something like 6+ random diceware words or 18+ random letters/digits.