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

  • [deleted]

Bozo That’s another possibility. My thinking was it must be unlikely cellebrite can attack the device over usb with the data pins disabled by it being in restricted mode. It seems the usb attack surface should be somewhere between non existent and very small. Possibly it’s a different vuln via Bluetooth or something?

I believe it's usb based because it stated to plug all devices to premium as soon as possible to do IPR.

Bozo I didn’t see where they said the timing is a range where was that?

Forensic examiners have been discussing this in the cellebrite private community. It's not a precise time but definitely way longer than one hour.

  • Bozo replied to this.

    [deleted]

    Thanks for the reply. In that case, ouch. It seemed almost too bad to be true :(

    And yes agree it’s on the usb side then.

    final BFU Yes and BF No: Can BFU extraction but not brute force to unlock the device.

    Thank you for explaining it, it makes much more sense now 🌷

    Thank you for the response.

    GrapheneOS We do still recommend people who need their data secure indefinitely use a strong passphrase

    One thing that I am curious about is if it would be possible to increase the key derivation complexity to further frustrate an offline brute-force attack if desired by the users threat model (i.e similar to --iter-time with LUKS). Or is it a matter of the Titan chip doing it internally better than host CPU ever could and the number of iterations or if it is adjustable is unavailable?

      • [deleted]

      Finally!!! I just tested the feature and it works perfect. Thank you GrapheneOS developers!!!

      popsicleman The scrypt parameters can be increased but the final key derivation happens in the TEE via hardware-bound key derivation that's meant to prevent offloading it to a server farm even if the TEE firmware is exploited. It's not the secure element doing it but rather the TEE to take advantage of the SoC cryptographic hardware performance. We haven't looked into the precise details of this on current generations. We can't change the parameters for that at the moment. We can only increase scrypt time and memory, and bear in mind it runs on every unlock.

      @matchboxbananasynergy I just saw the threadlock on the PG forum. I didn't know about the MSAB marketing video until I saw the PC Mag article you linked. Can you point me to where the video is currently being mirrored? I'd like to keep it for posterity.

        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.

          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.

                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.

                    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.