Can GrapheneOS updates be compromised like Encro etc?

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.

de0u

GrapheneOS 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.

Oops, I had not considered that. It would take a well-resourced attacker, but if it is assumed that the project's signing keys have been compromised that would be a well-resourced attacker.

Joyride

GrapheneOS 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

I agree with the position that GrapheneOS should not be engaged in security theater, and I appreciate it very much.

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?

Just thinking out loud: I believe Pixel devices have some mechanism for ensuring they only boot signed OSs (which is why a GrapheneOS signing key compromise is necessary), 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? This would be a 2 of 2 multisig essentially, so an attacker would need to compromise both GrapheneOS's signing key and each user's signing key that they want to compromise. 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.

The primary threat actor I'm thinking about is border patrol in every country where they will often ask you to hand over your phone where someone will take it into a back room. In such a scenario, it would be nice to have confidence that if the phone still booted after you got it back then it likely wasn't compromised. While border patrol may gain access to GrapheneOS signing keys in the future, it is unlikely they will gain access to each individual traveler's signing key.

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).

GrapheneOS

de0u It doesn't require a lot of resources to open up the phone and directly connect to the SSD. It's a standard off-the-shelf component and isn't intended to be in any way protected against it.

de0u

GrapheneOS It doesn't require a lot of resources to open up the phone and directly connect to the SSD. It's a standard off-the-shelf component and isn't intended to be in any way protected against it.

That sounds like "computer engineering undergraduate student attacker" or "enterprising high-school student attacker". That is indeed a low bar.

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?

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.

Joyride

de0u 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.

I agree on the etymology, but I am seeing this term used more and more in security and privacy discussions to reference the collection and concentration of identity documents (usually as part of KYC processes) which then become targets for hackers to steal because they can break into one system and collect a huge volume of data. This is how I'm using the term here to refer to a single attack point that can be used to compromise a large volume of users, though happy to use a different term to get across the same point if you have a better one!

de0u immediately-actionable approach is for the user to sign/re-sign system images, as previously indicated

I think my multisig description above is basically just enshrining this as part of the normal process. When you download an image, it is signed by GrapheneOS and presumably during install the firmware(?) verifies that the public key that signed the OS being installed matches the one for the currently installed OS? One can imagine (I haven't thought too deeply, but it seems plausible) that GrapheneOS signs their packages in a way that their signing key can be aggregated with a user signing key later. During auto-update, the user would download the half-signed package (just like normal download in prep for installation today) and once the package was on the device the device would prompt the user for authentication at which point it would complete the signing using the user's on-device key. From here it would install like a normal auto-update.

The only real difference between this proposal and the current auto-update system is just that there is a step in the middle where the user needs to authenticate in order to finish the signing process of the OS package.

For side-loading, the user would presumably download the half-signed package, aggregate in their signature from another source (e.g., signing key on offline device, in password manager, from sticky note on desk, etc.). Once the second signature is aggregated in, the side-load would proceed exactly as normal today.

I'm pretty confident the cryptography is not a blocker here and if that is the source of uncertainty about this scheme's viability from others I'm happy to ask some cryptographers I know about how the scheme could work within Pixel's constraints, but I'm far less confident that my understanding of how Pixel devices authenticate OS updates is correct.

de0u

de0u 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 I agree on the etymology, but I am seeing this term used more and more in security and privacy discussions to reference the collection and concentration of identity documents (usually as part of KYC processes) which then become targets for hackers to steal because they can break into one system and collect a huge volume of data. This is how I'm using the term here to refer to a single attack point that can be used to compromise a large volume of users, though happy to use a different term to get across the same point if you have a better one!

The "fake lure" usage is documented widely online, e.g.: https://www.huntress.com/cybersecurity-education/cybersecurity-101. So far I haven't seen the other usage, but if links to reputable sources are available they may be of interest to this audience.

de0u

Joyride One can imagine (I haven't thought too deeply, but it seems plausible) that GrapheneOS signs their packages in a way that their signing key can be aggregated with a user signing key later.

The key consumer of signatures on system images is the bootloader, so any proposals about key aggregation must be made with that consumer in mind.

Joyride I'm pretty confident the cryptography is not a blocker here and if that is the source of uncertainty about this scheme's viability from others I'm happy to ask some cryptographers I know about how the scheme could work within Pixel's constraints, but I'm far less confident that my understanding of how Pixel devices authenticate OS updates is correct.

Here is some information about the verified boot mechanisms in use by modern Android devices:

VeryRob

Saying law enforcement can go @#$& themselves does lend to the idea all GOS users are criminals. Please don't give us law abiding people simply seeking to not give all our data to big tech a bad name.

« Previous Page