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

de0u It's not directly possible due to authenticated encryption. They'd need to extract the key for that from the main SoC which is not accessible to the OS, etc. and at that point they would be using expensive equipment in a lab. It's more realistic to have fancy equipment for tampering with memory which is extremely complex and growing in complexity. Trying to MITM the encrypted connection between the SoC secure core and secure element doesn't really make sense. It's not worth the trouble and doesn't really accomplish anything for an attacker able to exploit the OS, which should be far easier than that.

Duress PIN/password is an OS feature so it can be bypassed by exploiting the OS. If it was supported by the secure element, then it would require a secure element exploit or the secure element could perform an erase when an authentication token derived from the duress PIN/password is passed. Each Weaver slot would need both the valid authentication token and a duress authentication token, where the valid ones gets back the Weaver token, and invalid one triggers throttling and the duress one triggers an erase. This cannot be implemented by GrapheneOS since we do not make the secure element firmware. It's a theoretical feature which is unlikely to be implemented by any OEM even if we make a good proposal for it. We'd need to have our own device with our own secure element where we build and sign the firmware for it to make those kinds of features.

mmmm It would have happened already if we were willing to compromise on meeting our baseline security requirements, but we aren't. It's easy to make yet another device with poor security, especially if it's just using a MediaTek CPU and largely using a standard OEM design with minor deviations. It's not easy to make a highly secure device. We don't have any interest in a white labelled variant of an insecure phone, so it makes it very hard to get it done for real. If a company is interested but unable to deliver what we need, it doesn't go anywhere.

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.

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?

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.