Does hardware memory tagging protect me more when phone gets stolen

AspireMan

Hello everyone,
I read some articles about hardware memory tagging and how awesome it is, but to be honest, I didn't get it really.
What I care about is if my phone gets stolen. Can a thief crack my Pixel 8 and get access to my data with hardware memory tagging more easily than a Pixel 7?

raccoondad

AspireMan btw cybersecurity isn't just about physical access scenarios, if you are only accounting for one type of fairly rare scenario you are setting yourself up to be vulnerable.

GrapheneOS

Data is protected by encryption. Our auto-reboot feature automatically reboots the device to get it back at rest, by default 18 hours after the device is locked and hasn't been successfully unlocked. During that window of time, an attacker who was able to exploit the device could obtain the majority of data in the users that are still logged in since most data doesn't get back at rest from simply locking. Hardware memory tagging is a massive improvement to the defenses against exploitation, making it significantly harder to exploit the device in that window before it's back at rest. The main purpose of hardware memory tagging is defending a remote attacker being able to take over an app or the OS via the most common classes of vulnerabilities for the platform, but it also defends against the scenario of a physical attacker too.

AspireMan

Ah so to summarize with my words.

If I shut down my phone before it gets stolen it is almost impossible to obtain the data of my phone. Still the best protection
If not shut down there is a 18 hour window where a thieve could theoretically obtain my data, before auto-reboot starts or the battery dies
HMT makes it much harder during that time window to obtain data from the device.

->With HMT would it be as hard as a shut down phone for a thieve to obtain data from the phone or "just" harder

GrapheneOS

AspireMan Once it's shut down or rebooted to get data back at rest, the security of the data in profiles doesn't depend on OS security anymore but rather on the security of your lock method. There are hardware-based security features integrated into the key derivation process to make even a random 6 digit PIN highly secure. A sophisticated attacker able to exploit the secure element can bypass the time-based throttling for decryption attempts and break a random 6 digit PIN. A highly secure passphrase such as 8 random diceware words is secure against any attacker no matter their resources. There's scrypt-based key derivation at the start and then hardware-bound key derivation with a key unavailable to the OS or even firmware if properly implemented, which makes a weaker passphrase far stronger than it would be without it. It's up to you how to decide to secure your profiles. Each user has separate encryption keys so you could use a random 6 digit PIN for your main profile and 8 random diceware words for a secondary user. In the near future, we plan to add a feature providing the option to add an extra PIN to fingerprint unlock to enable people to use a strong passphrase combined with fingerprint+PIN secondary unlock rather than only a fingerprint by itself, to address the weaknesses of using a fingerprint alone.

GrapheneOS

We provide a bunch of features relevant to this:

1) Our auto-reboot feature automatically getting data back at rest after locking, with the default of 18 hours after locking (you can make it as low as 10 minutes).
2) Our recently added low-level USB-C port control on Tensor Pixels which even disables the data lines in hardware, with the default of disabling USB data in After First Unlock state when the device is locked (you can disable it in Before First Unlock state too along, set it as charging-only or even completely disable USB including charging while the OS is booted to even eliminate the charging protocol attack surface).
3) Our recently added full compacting garbage collection in system_server/SystemUI on the device locks.
4) Our large amount of generic exploit protection improvements including hardened_malloc, hardware memory tagging integrated into hardened_malloc and enabled by default, BTI/PAC and lots of other assorted kernel/userspace hardening along with a minor amount of additional firmware hardening through attack surface reduction. Attack surface reduction features such as Wi-Fi/Bluetooth auto-turn-off are also relevant.

You can see that the first feature gets the data back at rest after a timer elapses after locking if there isn't a successful unlock first, and everything else combines to secure the device against attacks.

Improvements to OS and firmware security are shipping in the stock OS for the April release based on our upstream vulnerability reports / suggestions to make things even better, including reset attack mitigation protection for the firmware fastboot mode by having it zero all memory before activating USB.

AspireMan

GrapheneOS
Amazing explanation and impressive to read. Thank you for taking the time.

I guess than from a security perspective the Pixel 8 (500€) is worth the 200€ upgrade to a pixel 7a?
Especially for my use case of physical unwanted access by a unauthorized person.

For me this is most important. My phone was just stolen and I want to sleep good that nobody in the future is able to gets access to my data, with the right configurations.

Blastoidea

AspireMan

May we ask how your phone came to be stolen?

AspireMan

Blastoidea Holiday in Brazil. Shouldn't have shown my phone on the streets after sunset.

I'm more worried what's currently going on in europe with the digital service act and Ireland.
You say the wrong thing and suddenly the police confiscates your phone and laptop. I'm preparing for something that hopefully never will happen

https://twitter.com/shellenberger/status/1770438721831415839?t=-sc6a6g6PVsBagssgY7NHA&s=19