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

GrapheneOS thats frustrating for the project. I'm glad to hear there will be no comprises, but I'm not surprised! I'm sure one day it will be a reality, and I'm eager for that one day to arrive. Keep up the good work.

GrapheneOS Thanks for your reply, glad GrapheneOS is so secure

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)

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?

robertnovak Many of the features provided by these apps are insecure and can be easily bypassed, regardless of the fact that we made the device admin API wipe securely via a wipe-without-reboot implementation.

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.