My idea is to detect whether the time is exceeded when booting, and clear the data if it is exceeded.
As for the second question, I am not a professional developer, but it seems that the clock system in the shutdown state is unreliable? If the clock data in the shutdown state can be rewritten at will, then this function cannot be implemented safely. It is even worse if the communication with the clock system in the startup process is plain text and not verified.
Yes, I know that many of these apps are not reliable and can be easily bypassed. But I think they are still useful for dealing with less professional attacks.
I don't know if enabling these apps will reduce the overall security of the system. After all, they are just apps. Although they have obtained some sensitive permissions, they should not affect the overall security of the system.
matchboxbananasynergy Kudos for the great summary. ☕
I have to ask, what protection is afforded to the signing keys for OS updates, against, for instance, coercion by a developer's government into handing them over?
Harald The secure element only accepts signed firmware updates after the Owner user authenticates, which is documented as one of our hardware requirements:
https://grapheneos.org/faq#future-devices
Insider attack resistance for updates to the secure element (Owner user authentication required before updates are accepted)
This means it's not possible to bypass the time-based brute force protection via a malicious firmware update. We aren't capable of creating a malicious firmware update anyway, since it's not our hardware.
For the most part, what you're asking isn't very relevant to this thread and is based on the incorrect assumption that preventing handing over signing keys with an HSM would protect against coercion. An HSM can protect against the keys being obtained through a compromise of the build/signing machines, but a compromise of those machines would allow tampering with what gets built so obtaining the keys wouldn't be required. An HSM has limited usefulness for this. Dedicated build/signing machines offer better protection. A supply chain attack against software we depend on is a lot more likely and is our main concern.
GrapheneOS Thank you for providing this clarification!
I’m curious what other information can be gleaned from the private celebrite chats. I know it’s about iOS but am curious from what event recovering the passcode is time sensitive? Time since the passcode was last entered? Time since it first entered afu?
Does anybody know the resilience against brute force attack by current forensics analysis of a grapheneos pixel 6a and 8a? I'm pretty sure the devices are in BFU state after auto reboot
Rcif419 There's no indication that any of these companies can currently bypass the Titan M2 brute force protection provided through the Weaver feature. That means it quickly ramps up to 1 attempt per 24 hours after 140 failed attempts which makes a random 6 digit PIN secure. If you have a truly strong passphrase, then no future exploits can obtain the data. They could of course develop an exploit for the Titan M2 in the future. That's why we want to make strong passphrases much more convenient by adding support for 2-factor fingerprint unlock along with support for automatically generating a random passphrase.
What if it is a 4 digit passcode?
Rcif419 Assuming random digits, a four-digit PIN is 99% less secure than six digits, because there are 100 times as many six-digit numbers as four-digit numbers.
Security people often make recommendations based on what should be good enough for a given use case, plus some margin. Four digits might be good enough? But not good enough plus some margin.
Edit: note that the "140 attempts" figure above is 1% of the way through the space of a four-digit PIN, so the attacker could get lucky. You might choose to take that bet, but I doubt you will find somebody willing to recommend it as a good bet to take.
Hey all. I have a Pixel 8 pro and followed all the recommendations with Diceware password, auto boot every hour, turned off what I need etc. I understand this is a Graphene OS forum, But I just don't know where I can go to ask this question.
Does the same apply with an Iphone? Latest Iphone with the latest ios, alphanumerical passphrase of 20+, lock down mode on and iCloud all turned off. Is that strong enough?
uppa9 iphines are pretty secure. Renowned in the field in fact. The problem with iphones are; not open source, and tied strongly to apple. Who knows what they know of you, even not logged in to icloud. Its kind of mandatory anyway if you want to use it properly. They're not as private as apple would have you believe. Damn secure though.
But a strong password makes those things pretty unbreakable too. They're not GraoheneOS though!
Interesting.
Since the major point of failure here is a powered-on device, maybe it will be considered
to add a feature to the new USB-C HAL exploit protection, such as - if a charger is plugged,
require the passphrase? Since I assume most tricky part for forensics companies will be keeping
the device charged before it's rebooted. If this can't be achieved, they will have to somehow
wirelessly charge the battery without passphrase (if it's possible) or they will be left with the power
level currently left on the device. Since I know that most investigations are not "hot", it will be safe
to assume that the device will be BFU if this feature is implemented.
404 media report https://archive.is/qgBWB
Leaked Docs Show What Phones Cellebrite Can (and Can’t) Unlock
de0u Strong enough for what?
uppa9 More so keeping my data safe for a very long time
It's hard to say.
For example, if the question is "What if I put ultra-private data on an iPhone, turn it off, and lock it up a safe, will the data remain private in 50 years?" I would not want to predict that. Fifty years is a long time for somebody to find bugs in an obsolete iPhone.
If the iPhone is getting regular software updates, that's different (and presumably the ultra-private data will need to migrate to a new device every five years or so).
It also matters who wants the data. If it's a large state actor with powerful supercomputers, that's different than if it's a rural police detective. And if the state actor can torture you until you divulge your passphrase, that's entirely different.
It's hard to answer the question at all, and pretty impossible without a detailed threat model.
de0u If there's a 10 diceware word passphrase, as in 128 bits of entropy, then there would need to be truly massive breaks in AES, scrypt or the other cryptography used as part of key derivation to recover any of the data in that profile. Cryptography is considered broken when an algorithm meant to have 128 bit security has an attack reducing the security to 127 bits even only in a certain edge case. It's using AES256 rather than AES128 so even a massive break 30 years from now reducing AES256 to 100-bit security doesn't mean any data can be recovered. The disk encryption is already protected against theoretical powerful quantum computers, unlike TLS connections with ed25519 key exchange or using AES128 instead of AES256.
