Claims made by forensics companies, their capabilities, and how GrapheneOS fares

GrapheneOS Do you think it's a better choice to wait for titan m2 to be open source and write secure element firmware based on that?

popsicleman You're fantastic. Where did you find it? I found the Yotube video URL but as you said it wasn't in Wayback and Google didn't cache the video. My infinite thanks it was so gratifying to see that self-own.

robertnovak

Just a small remark. Titan M2 has passed the highest hardware vulnerability assessment by an independent and accredited evaluation lab. A leading international security lab SGS Brightsight certified Titan M2 hardware and cryptography library against CC PP0084 with AVA_VAN.5, which is the most rigorous standard for vulnerability assessment. This means that Titan M2 has passed the most advanced methodical vulnerability analysis and resistance against a high attack potential.

Hathaway_Noa The link is dead.

I wonder if GrapheneOS will implement features similar to Sentry and Wasted App: wiping data after a specified period of inactivity, and wiping data after receiving a specified message

Another question is whether Sentry and Wasted App currently use a normal reset system or a secure wipe method when performing wipes on GrapheneOS

robertnovak
Well, GrapheneOS has autoreboot feature, which is better than auto wipe I guess? ;)

Also, there is an interesting app Find My Device (https://discuss.grapheneos.org/d/439-find-my-device-on-grapheneos/27) and there is a ticket open to implement reboot feature (they also have wipe implemented).

Matthai

If there is a timed destruction function, when you are being interrogated by a centralized government, you can know that the data has been destroyed as long as you wait until the specified time.

If there is no such function, they may use torture to force you to reveal the password (the interrogator can easily know that GrapheneOS can set a duress password)

Matthai Titan M2 has passed the highest hardware vulnerability assessment by an independent and accredited evaluation lab. A leading international security lab SGS Brightsight certified Titan M2 hardware and cryptography library against CC PP0084 with AVA_VAN.5, which is the most rigorous standard for vulnerability assessment.

Great information! Is it possible to provide a link?

de0u

https://security.googleblog.com/2022/10/google-pixel-7-and-pixel-7-pro-next.html

robertnovak How is it going to wipe the data if it's not turned on? Will the timer be based on the clock for the main SoC based on real time so it doesn't get reset on reboot?

GrapheneOS

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.

GrapheneOS

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 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?

That is an interesting question. I wonder what protection is afforded to Google's signing keys for their OS updates?

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