Cold brute force attack

Alan_the_coder

I would like to understand how we are protected against brute force attack in 'cold' mode.
I don't know much how Android and GOS work compared to Desktop OS.
For example, when I start Linux (LUKS encryped), I will be asked for my (long) password before being able to load the OS.
If someone is able to steal my HD or SSD then he will be able to try all possible passwords until he will find mine (which will take a very long time!).
How are we protected with GOS and Android? If my phone is stolen, will the person be able to get a copy of the memory and try all possible passwords? As most of us are using a 6-to-8 digits PIN, it wouldn't take long to crack our passwords.
I assume there is another defense mechanism, but I don't know how it works.

Watermelon

Alan_the_coder You seem to conflate two different attacks here with some overlapping similarities, since you mention both brute force and memory dumping. If an attacker manages to dump the memory containing secrets or personal data, they have no need to brute force anything!

Protection against brute force: If you use a long, secure passphrase, there is strong encryption protecting from brute force because of the high passphrase entropy. Regardless, encryption on GrapheneOS is also strictly tied with the secure element — a dedicated hardware component containing a separate, extremely limited CPU, OS, memory, and storage of its own. The secure element stores certain data that's necessary for decryption. A PIN doesn't have enough entropy on its own to be strong so then you're left relying entirely on the secure element's resistance against attacks rather than also your passphrase being strong enough. Google's Titan M2 secure elements which exist in all Pixel 6, 7, 8, and 9 devices are considered to be the strongest secure elements. You can see the pinned thread at the top of the forum regarding Cellebrite — they haven't found any way to successfully attack Titan M2 (Pixel 6 and later as I said, with a mid-2022 security patch level).
Protection against memory (RAM) dumping: GrapheneOS erases all memory when it becomes unused, including during shutdown/reboot but also when apps are closed/apps release some memory/etc. This is zero-on-free that you can see mentioned in the features page (maybe called slightly different there) at the homepage of GrapheneOS. They also added another feature, zero-on-boot (I believe this is my name for it, the GrapheneOS project uses the term reset attack mitigation), which erases the entire RAM when GrapheneOS boots up, and they also requested Google to implement zero-on-boot when booting into Fastboot mode, which Google did over a year ago; both of these protect against an attacker cutting off power to the powered-on device without GrapheneOS having time to use its zero-on-free feature — the RAM is erased as early as possible, for example before the USB port becomes functional, so companies like Cellebrite exploiting the device in Fastboot mode through the USB port and successfully taking over the device would see empty RAM containing no leftover traces from powered-on use. And needless to say, an attacker managing to dump the RAM of a process or the entire system while powered-on would get much less secrets/personal data thanks to the zero-on-free feature. And regarding dumping the memory of the secure element, as I said it's a separate hardware component that's much more limited and focused on specific tasks and is specifically meant to resist such attacks. GrapheneOS also adds the auto-reboot feature, which coupled with the RAM zeroing features, cause a device that hasn't been unlocked for a while (user-configurable, can also be disabled if you wish) to reboot and become totally encrypted with no secrets left in memory, thus nothing to dump.

KleinesSinchen

Please read the encryption part in FAQ
https://grapheneos.org/faq#encryption
This explains everything way better than I ever could.

In short: The security chip/secure element/Titan M2 heavily throttles password attempts making bruteforcing even a 6-digit pin infeasible. The actual password protected encryption key is not easily available to an attacker like on a PC where one can extract the LUKS header and use a whole server farm for cracking.

However, if somebody was able to circumvent the throttling (as it happened with other secure elements) a short pin is obviously cracked on device very quickly.

You don't have to rely on the throttling. If you feel this doesn't suit your needs you can switch to a long passphrase and use fingerprint+short PIN as secondary unlock method.

grayway2

KleinesSinchen what would you use as a windows/Linux laptop to throttles passwords attempts ?

From what I know, only M Mac series are as good as Pixels for this task.

Also how about external storage such as solid state drive or flash drives from Apricorn ? How good is their Brute Force Hack Defense Mechanism ?

Alan_the_coder

KleinesSinchen thanks mate, it makes things clearer for me.
So if I understand, the password is protected by the Titan M2 chip, which is like an embedded computer and prevent brute force attack.
Is it possible for someone to tamper the M2 program/OS or dump its memory to be able to crack the passwords stored in it? I assume only Google or a big firm or state can do it?

Sigismund

grayway2 what would you use as a windows/Linux laptop to throttles passwords attempts ?

Fido key for preboot auth with a very long "recovery key". I am not worthy enough for NSA to start cracking, so I don't care for "quantum".

raccoondad

grayway2 what would you use as a windows/Linux laptop to throttles passwords attempts ?

The only method realistically is high parameter argon2 or similar password hashing methods

raccoondad

Alan_the_coder I assume only Google or a big firm or state can do it?

It has not been done by either, so no. The OS has no way of changing behavior of the secure element, its not an aspect of the OS.

Watermelon

Watermelon I should also add, GrapheneOS adds another feature called duress PIN/password, which immediately wipes the cryptographic material necessary to decrypt your data and shuts down. Several months ago I asked here on the forum what happens to the RAM, and the GrapheneOS project account replied that the shutdown that appears as "instant" in the duress feature is actually a clean shutdown procedure, meaning that the usual zero-on-free feature kicks in and cleans up all personal data and secrets from RAM before it's powered off. All of this happens extremely quickly in a few seconds.

https://discuss.grapheneos.org/d/18523-why-duress-works-this-way/27

Watermelon

Watermelon Watermelon Oh and GrapheneOS also adds the USB-C port control feature that lets you block all kind of communication through the USB port while GrapheneOS is powered on (this is also user-configurable and can be disabled if you wish). So even if your device is stolen while powered on and it's not rebooted yet, they can't exploit it through the USB port to dump its memory or do any other bad things through it.

Is there anything else I forgot?? (All features improve overall security, but some features are especially relevant to this topic.) Seriously, there's so many good features in GrapheneOS. Huge thanks to this project.

I guess there's all other attack surface reduction features, like turning Wi-Fi and Bluetooth off when they're not used (such as when your device doesn't see familiar access points/Bluetooth devices nearby, for example if it's stolen from you) and the LTE-Only mode which block an attacker from trying to exploit your powered-on device through Wi-Fi, Bluetooth, and 2G/3G/5G cellular protocols. Oh and the NFC one that they recently removed for the time being because of discovered issues with it, but they plan to add it back sometime.