Can GrapheneOS updates be compromised like Encro etc?

PushPush

Encro failed with their updating mechanism where law enforcement managed to push fale update(s) giving them full access to the phones. I tried searching on the forum about what GrapheneOS does to prevent this from ever happening but my search skills was not enough.

Can someone enlighten me... How can the auto update feature be trusted? I assume the update is signed by a GrapheneOS key which is verified before accepting update. But can these computer(s)/person(s) get hacked or identified or blackmailed?

What else is there to worry about in terms of updating safely and not installing an update with surveillance included?

I know Graphene is just a normal Android system but a lot more hardened and secure so any law enforcement should of course go and fxck themselves. But these days you never know how far they extend their long arm of the law, claiming its a "system used for criminals".

Please share all your input and information about this.

And, is it safer to apply Github updates manually?

Thanks for your wonderful work.

Dumdum

https://grapheneos.org/usage#updates-security

missing-root

Encrochat and their phone was a scam afaik.

If the servers and signing keys get compromised then yes of course.

de0u

missing-root If the servers and signing keys get compromised then yes of course.

Devices running GrapheneOS place no trust in the update servers. The device won't take an update over the network or via adb sideload unless it's properly signed, or unless a fairly shocking vulnerability is discovered.

If the signing keys are compromised, or a fairly shocking vulnerability is discovered in the signature-checking process, then GrapheneOS devices are vulnerable. But the same is true in any signed-code ecosystem: Apple devices are vulnerable if Apple's signing keys are compromised; Pixel devices running Google's OS are vulnerable if Google's signing keys are compromised; devices running Microsoft Windows are vulnerable if Microsoft signing keys are compromised...

At some point one must either build one's own computing infrastructure starting from melting sand to get the silicon, or one must place some trust in somebody.

P.S. Code-signing ecosystems are tricky. For example: "How a Microsoft blunder opened millions of PCs to potent malware attacks"

Velocity9490

IIRC EncroChat servers were hacked by law enforcement (in cooperation with OVH, the server hosting company) and the updates were modified. This can never happen to GrapheneOS, since it has full Verified Boot, and updates are built and signed locally by the devs on their machines. Daniel Micay has shown in the past, that he has a very good hygiene with signing keys. The cloud servers are only responsible for distributing the updates, which are then checked on your device after downloading them. If the signature doesn't match the original signature that Graphene was signed with, the update won't be applied. In order to load compromised updates onto a device, you would have to compromise the entire OS from the beginning, which would easily be detected when performing normal post-installation steps (https://grapheneos.org/install/web#verified-boot-key-hash).

missing-root

Velocity9490 lol he wiped his hard drive.

This tells not much about his key hygene, not saying they are insecurely stored.

Lucian

Velocity9490 This can never happen to GrapheneOS, since it has full Verified Boot, and updates are built and signed locally by the devs on their machines. Daniel Micay has shown in the past, that he has a very good hygiene with signing keys.

Is this a multisig or a single sig?

Onion

GrapheneOS devs probably use air gapped computers with strong encryption for signing the updates. Even if the servers are compromised, no malicious update could pass full verified boot

Lavabit founder shut down his company rather than giving a backdoor access to the US gov. I believe Daniel Micay and the other lead developers of grapheneOS would do the same to protect users.

GrapheneOS is much more than a security focused android operating system, it's a long fight against shit like Pegasus, the NSA, Cellebrite, XRY, Google, millions of companies around the world violating the fundamental right of human to have privacy by collecting a vast amount of data every day, every hours, every seconds so threats are not a big concern for the devs

Joyride

Is there no way to remove this trust dependency?

I understand the argument about melting sand, and I have used it myself in the past, but it does feel like this is a trust dependency that could be removed by requiring an authenticated user to initiate the update. Is there no way on modern Pixel devices to require an existing authenticated user to initiate an update (even when side-loaded)?

The problem here is that I may trust that GrapheneOS signing keys are not compromised today, but that is very different from me trusting that GrapheneOS signing keys are never compromised in the future. As a user, I could protect myself from compromised signing keys by only using updates that have been published for an extended period of time before applying them, and also check third party resources to verify that GrapheneOS is still likely not compromised. If I see a news article that the GrapheneOS devs have all been taken into custody by the CCP I could refuse any updates from that point on for example (signed or not).

With the current design, if someone gets a hold of my phone and then GrapheneOS signing keys are compromised 10 years later, then it means (IIUC) in 10 years they can access my device and all of my data. I would much rather that the phone is secure no matter how long the attacker holds it for and even if GrapheneOS signing keys are compromised (now or in the future).

Johnnyloans

Joyride compromised 10 years later, then it means (IIUC) in 10 years they can access my device and all of my data. I would much rather that the phone is secure no matter how long the attacker holds it for and even if GrapheneOS signing keys are compromised (now or in the future).

This'll happen anyway. Encryption algorithms can be cut down until they're simple enough to crack.

If you want, you can disable the app 'System updater' then enable it for updates once you haven't heard any news. Although, if your situation was to happen, there would be no news and people would update, then their plan would be complete.

wizoatk

Joyride Is there no way to remove this trust dependency?

Sign the install and update images with your own key(s). That will remove the dependency, but likely not improve your security.

de0u

Joyride Are you saying that it is not possible to protect against someone swapping out the OS, or just that GrapheneOS currently doesn't have protections against it and if one wanted to add protections against it they would need to protect both side-loading and direct SSD access?

I believe that replacing a system image signed by GrapheneOS with a system image not signed by GrapheneOS will result in the storage encryption keys being unavailable (source; see at "hardware-bound key derivation"). But the question on the table (Joyride) was about making it difficult for somebody with physical possession of the device to install a malicious OS hypothetically signed by the official GrapheneOS signing key for the device. Both scenarios might qualify as "swapping out the OS", but the effects would be different.

Joyride Is it possible to make it easy for the OS to be dual signed, one key by GrapheneOS and the other key sourced from the user during setup?

I don't believe the bootloader checks signatures that way, or that the hardware key-management system is set up to handle that. And it is not clear from the question when or how it is expected that the key would be provided when booting or when upgrading the system partition.

Joyride This setup would make it so compromising GrapheneOS signing key would not compromise all users, essentially removing the honey pot that currently exists in GrapheneOS signing keys.

I think that among security researchers the term "honey pot" is used to indicate a fake system that is easy to break into, designed to lure attackers in order to study their behavior.

Joyride As with all 2/2 multisigs, there are risks that the user loses their signing key (they can't update anymore without wiping the device), but I think in theory the user signing key could be stored in the secure element so auto-updates could use it? If a user wanted to side-load an update they would need to counter-sign the package first (likely off-device).

If a user is concerned about the GrapheneOS signing keys hypothetically being compromised, the currently-supported and immediately-actionable approach is for the user to sign/re-sign system images, as previously indicated (wizoatk). Many other approaches are possible in theory, but I am not aware of devices implementing multi-signature bootloaders.

GrapheneOS

Johnnyloans Disabling updates ruins privacy and security through not getting crucial privacy and security patches anymore. The vast majority of people aren't going to manually stay updated. We see it happening all the time.

Joyride

wizoatk Sign the install and update images with your own key(s). That will remove the dependency, but likely not improve your security.

This is a clever technique. The challenge is that I would need to secure the signing key for the image. Ideally it would be on my mobile device (so no new attack vector introduced), but I would need a way to use that key to sign a build and have an offline device to actually do the build. Would be much easier if I could just disable unautheniticatud side loading.

Joyride

I agree that for many threat models and users auto updates are a net win. I don't think this is true for all threat models and users though.

Even if auto updates are turned on, can an attacker who compromised GrapheneOS signing keys initiate an auto update without unlocking the device other than through side loading the update? If not, then side loading without authentication is a vulnerability unrelated to auto updates.

Is the fact that one can side load without authentication something GrapheneOS can control, or is this related to how Pixel device firmware is designed?

de0u

Joyride Is the fact that one can side load without authentication something GrapheneOS can control, or is this related to how Pixel device firmware is designed?

Sideloading OTA updates is orchestrated by Recovery, for which the source code is available. It would be possible to add restrictions to Recovery, though not trivial. At the moment Recovery does not have a UI for entering passphrases or PINs, and does not have KeyMint running.

GrapheneOS

Joyride de0u An attacker with physical access to the device can directly write data to the SSD which means they can update the OS to a newer version regardless of what's implemented in recovery. There's no use in adding authentication to doing it from recovery. It would greatly reduce the ability to recovery from a device failing to boot without having to wipe it if it wasn't possible to update without reading persistent OS data to handle authentication. There's no real use in putting up insecure barriers which can be easily bypassed without any exploits or sophisticated tampering with the hardware. We don't do that kind of thing in GrapheneOS. It's also why we don't add a broken authentication system with shutting down while locked as Samsung does because someone can still turn off the device regardless. We're not going to add an easily bypassed opt-in toggle for authentication of sideloading in recovery when there's a very straightforward way to bypass it.

Onlyfun

Joyride disable unautheniticatud side loading

With mdm.

Joyride

Onlyfun With mdm.

What is MDM?

GrapheneOS

Onlyfun Joyride It's not possible for a device policy manager to do that.

Joyride

If someone acquires GrapheneOS signing keys without acquiring my PIN/Pasword/Fingerprint, what harm can they do? Will all of my data still be encrypted at rest and require authentication from me to decrypt, even if they have full control of the OS?

If all data is secured at rest, then at least this particular attack vector is limited to scenarios where a threat actor gains temporary access to your device and then gives it back to you, and the attack finishes as soon as you authenticate.

Would entering a duress PIN/Password after a threat actor with GrapheneOS signing keys gained temporary access to your device protect you, or can the OS disable duress features?

de0u

Joyride If someone acquires GrapheneOS signing keys without acquiring my PIN/Pasword/Fingerprint, what harm can they do? Will all of my data still be encrypted at rest and require authentication from me to decrypt, even if they have full control of the OS?

Yes, but a well-resourced attacker would presumably set up the fake GrapheneOS to exfiltrate the key (and probably some of the data encrypted by it).

Joyride Would entering a duress PIN/Password after a threat actor with GrapheneOS signing keys gained temporary access to your device protect you, or can the OS disable duress features?

Data wiping is implemented by the OS and triggered by system application code, so a fake OS could indeed ignore the duress code, though presumably that would be apparent.