CONTINUED
We've currently reported these issues for Pixels and will be filing similar issues with Samsung. We don't have as much leaked information about how they're doing it for Galaxy phones, but we can propose the same generic mitigations eliminating the main classes of vulnerabilities.
Secure element throttling is crucial to secure typical lock methods like a random 6 digit PIN or even a typical passphrase. Non-Pixel/non-iPhone devices are mostly missing it so data isn't safe even at rest for typical lock methods (much less than 7-8 random diceware words).
Pixels have used a secure element for this since the Pixel 2, but the NXP and ARM secure core Titan M1 had a fair number of vulnerabilities. Pixel 6 substantially improved this, so there's more focus on ever at exploiting the OS / firmware while the device isn't at rest.
For nearly any current generation secure element, there will likely eventually be a firmware vulnerability discovered. If you want to completely rule out a brute force, use a strong random passphrase. Can take good advantage of each user profile having separate encryption keys.
GrapheneOS has been heavily focused on securing against remote attacks and also providing privacy/security from apps. Those features make physical exploits harder, but we plan to add more features focused on it alongside auto-reboot and blocking new USB peripherals while locked.
Many apps and operating systems implement insecure duress features which can be bypassed. They do a standard wipe via reboot to recovery, which can be easily interrupted. Our implementation avoids this and will be shipped soon. However, we also proposed it to Android for the API.
Android 12 device admin API for disabling USB data is disappointing, since it's similar to what we already did and doesn't disable data lines.
Our default auto-reboot timer will be reduced from 72 hours. We also plan to add more attack surface reductions and other mitigations.
MetropleX [GrapheneOS] ⚡🟣
npub1gd…7cn8c
2024-01-11 19:30:00
in reply to nevent1q…gpl4
Author Public Key
npub1gd3h5vg6zhcuy5a46crh32m4gjkx8xugu95wwgj2jqx55sfgxxpst7cn8cPublished at
2024-01-11 19:30:00Event JSON
{
"id": "1191a3cf3f3b8414a1272f84eae70ced7cd3ef1f4e8c45aadad882065cba5941",
"pubkey": "43637a311a15f1c253b5d60778ab7544ac639b88e168e7224a900d4a41283183",
"created_at": 1705001400,
"kind": 1,
"tags": [
[
"e",
"a62c13060bc638aab1e4f3b5ac58ff2408e3965466255ee3b2f463848371128e",
"",
"root"
],
[
"p",
"43637a311a15f1c253b5d60778ab7544ac639b88e168e7224a900d4a41283183"
]
],
"content": "CONTINUED\n\nWe've currently reported these issues for Pixels and will be filing similar issues with Samsung. We don't have as much leaked information about how they're doing it for Galaxy phones, but we can propose the same generic mitigations eliminating the main classes of vulnerabilities.\n\nSecure element throttling is crucial to secure typical lock methods like a random 6 digit PIN or even a typical passphrase. Non-Pixel/non-iPhone devices are mostly missing it so data isn't safe even at rest for typical lock methods (much less than 7-8 random diceware words).\n\nPixels have used a secure element for this since the Pixel 2, but the NXP and ARM secure core Titan M1 had a fair number of vulnerabilities. Pixel 6 substantially improved this, so there's more focus on ever at exploiting the OS / firmware while the device isn't at rest.\n\nFor nearly any current generation secure element, there will likely eventually be a firmware vulnerability discovered. If you want to completely rule out a brute force, use a strong random passphrase. Can take good advantage of each user profile having separate encryption keys.\n\nGrapheneOS has been heavily focused on securing against remote attacks and also providing privacy/security from apps. Those features make physical exploits harder, but we plan to add more features focused on it alongside auto-reboot and blocking new USB peripherals while locked.\n\nMany apps and operating systems implement insecure duress features which can be bypassed. They do a standard wipe via reboot to recovery, which can be easily interrupted. Our implementation avoids this and will be shipped soon. However, we also proposed it to Android for the API.\n\nAndroid 12 device admin API for disabling USB data is disappointing, since it's similar to what we already did and doesn't disable data lines.\n\nOur default auto-reboot timer will be reduced from 72 hours. We also plan to add more attack surface reductions and other mitigations.",
"sig": "9c0e486b42e3e5d480a5312f9f9e71998a01df8876d0086c947d86b60294a4aba8e6117e8e976a0b31526bd12978723b9d36cf2207cf54763f1bee1ff6379db2"
}