Agility8200 You're likely to find it if you search for "MSAB Monday wasted" or something similar on Yandex. MSAB realized they messed up and tried to scrub it, but they couldn't do it completely. The video is archived regardless, but that's where someone can find it on the Internet at the moment.
Claims made by forensics companies, their capabilities, and how GrapheneOS fares
matchboxbananasynergy Thank you I will have a look.
Suppose I have a Pixel 8 Pro (latest GrapheneOS) seized by law enforcement in an authoritarian country.
Suppose I told them the password for the owner profile but not the password for the second profile (for confidential use).
I have two questions here.
1 Can they run an FFS extraction on the Cellebrite or Grayshift device to access the second profile?
2 After the device is returned, do I need to put the device in Airplane mode before hitting the password to counteract GrayKey's Hide UI, and on top of that, once I revert to stock OS and install GrapheneOS again?
TitanMPro 2, I doubt this is necessary but I would revert that to stock, chuck it away and get another phone. If I was in a situation where that scenario happened, and I was worried that the oppressive regime would add some kind of spyware, there is no way I would feel comfortable using the phone again. No doubt thats overkill and a factory wipe would solve any issues but I would still feel watched.
TitanMPro 2 After the device is returned, do I need to put the device in Airplane mode before hitting the password to counteract GrayKey's Hide UI, and on top of that, once I revert to stock OS and install GrapheneOS again?
When they handed it to me, I would restart it instantly. After that I would factory reset it and sell it.
Realistically you are probably safe if you just restart it. I doubt GrayKey can survive Verified Boot.
One question is whether it is possible to confirm whether the password given is a duress password.
My understanding is that after the system is running, the system program detects the duress password and executes an operation to destroy the data in the security chip.
If the system is not running, remove the security chip and simulate the system to input the password to the security chip. If it is a duress password, the security chip will return a password error, and the duress password will be exposed.
If the attacker knows that the mobile phone system is GrapheneOS, he will know that the password handed over may be a duress password, and thus perform such a test.
I am not sure whether the security chip has a function like environmental detection. Only when the system is detected to be intact will subsequent operations be performed. If there is such a function, then add a middleman in the communication link between the system and the security chip, normal operations are allowed to pass, and operations such as destruction are directly discarded, which can also prevent the key in the chip from being destroyed.
robertnovak If the system is not running, remove the security chip and simulate the system to input the password to the security chip. If it is a duress password, the security chip will return a password error, and the duress password will be exposed.
If the attacker knows that the mobile phone system is GrapheneOS, he will know that the password handed over may be a duress password, and thus perform such a test.
That assumes the attacker is very well resourced. An attacker that powerful likely has other options available.
- Edited
robertnovak No, that's not possible since there's authenticated encryption between the SoC and secure element. An attacker has to exploit the main SoC or the OS to do that. The duress PIN/password feature would ideally be supported as part of the Weaver feature of the secure element to prevent bypassing it via an OS exploit, but you cannot do the kind of tampering that you're proposing. Physical anti-tampering as a whole would be incredibly weak if there wasn't authenticated encryption between the SoC and secure element. It would make the dedicated secure element chip into a liability rather than a strength for physical attacks, and that's not the case because there is authenticated encryption so there isn't a disadvantage to it being a separate chip beyond higher latency than if it was right next to the CPU. The SoC has a secure core and also a Trusted Execution Environment implemented via TrustZone (a CPU mode, rather than a separate core) both running Trusty OS in addition to the secure element. The secure core talks to the secure element via authenticated encryption.
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.
- Edited
GrapheneOS We'd need to have our own device with our own secure element where we build and sign the firmware
What type of conditions need to be met in order for this to become a reality? A while a go the official account mentioned something may be on the cards, but I believe this fell through. Is something like this going to be able to happen or is it more an ideal pipe dream? It would be so cool for you to be able to control the hardware.
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
- Edited
matchboxbananasynergy Appears I found the video in question
Title: How to disable the Wasted app with XRY Pro
Original upload URL (does not appear to have been archived by Wayback machine): https://www.youtube.com/watch?v=FUqYzA3l_Qg
I have obtained a copy of the suspect video and uploaded it elsewhere.
https://drive.proton.me/urls/AEFPPMD614#epG2p3euLleb
SHA256: 0838c6bdc96ec3634900efde9743d0cc265921bde9539f4920a5250c7e654226
[deleted]
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.
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).