Pixel Update

MoonshineMidnight

So I just got a "Pixel update" on my GOS 6a that required a restart yesterday. Would this not be a good attack vector for whomever - hacker, guv, etc.?

applesbana

MoonshineMidnight

Yeah, I never fully understood why updates are pushed this way. I prefer how it works in Linux, I have to give permission for my computer to update if/when I want to.

other8026

MoonshineMidnight applesbana basically because updates are signed with a key, a key that's impossible to brute force. I believe I've read that GrapheneOS releases are even built on air gapped machines. Pair that with the fact that your phone fetches updates from GrapheneOS's update server, which is secured with HTTPS. It appears the update app also uses certificate pinning. There are other things that I don't fully understand that GrapheneOS does to make sure that their servers are not spoofed, making man in the middle attacks (and probably others) impossible. Our phones do not just simply trust the server. Connections / updates will fail if anything is out of place.

So that's three+ different ways you're protected with modern, secure, and battle tested cryptography when updating via OTA updates. Updating this way is very safe.

router99

applesbana Agree 100%. There should be some selectable options for downloading and installing updates.

Many years ago, automatic software updates without an easy / readily visible option to disable automatic updates started creeping into desktop/laptop applications. Google Chrome browser especially stands out in my mind. Google Chrome doesn't even include the choice in the browser preferences anymore: it must be done via editing the registry, and I don't know if that is even an option anymore. Over the years, the general public became complacent to this. We collectively have largely ceded control of the update process to those who "know what's best for us".

I don't know about you, but I don't like anybody making choices, and deciding what's best, for me.

applesbana

other8026

I appreciate the thoughtful response.

I’m still not sure (and open to being wrong about this), why a forced push update is better than giving a user choice. In the unlikely (but I think you’d agree, not impossible) situation that a malicious update was created (perhaps the nsa holds a gun to the devs heads in this hypothetical?), it would be great if a few initial power users who can actually read code put out an alarm prior to everyone being on the infected software simultaneously.

More realistically, it may not be a malicious update but just one that needs some bugs ironed out that the devs missed. I guess that’s the point of alpha/beta channels, but I think we can all agree that some bugs continue to make it into the main channel as well.

WhoTheFuckisAlice

other8026 I'm intentionally exaggerating here.
Okay, I'm imagining a scenario where one of the people who has admin rights to upload and sign an update receives a phone call making it unequivocally clear that if the data he receives is not uploaded and signed immediately, his family will disappear forever?
And believe me, people don't have to feel that much power to do things that are offered, sometimes money is enough.
How can you protect us from something like that?

Edit: look the first has the same question nice :D

other8026

applesbana WhoTheFuckisAlice I can't answer the question you're both asking because dreaming of hypothetical scenarios can get out of hand. The fact is GrapheneOS has several full time and part time developers from different countries around the world. For all I know, multiple devs need to be involved in building and/or publishing a release.

If you don't want updates to be installed automatically, you can disable the updater app and enable when you want to update, or you can sideload updates if you'd like.

WhoTheFuckisAlice

other8026 can't answer the question you're both asking because dreaming of hypothetical scenarios can get out of hand.

But this scenario is not that unlikely, it happened a few years ago in France, where the French secret service infiltrated an employee, or simply "convinced" an employee of a company that sold secure smartphones. Since these were considered to be very secure smartphones, they were used by many criminals in addition to people who place a lot of value on privacy, which is why the employee installed a malicious code on the smartphones via an update, with which all encryption was broken and the secret service was able to record everything for several months. Also everything from non-criminals well noted, it was not about a specific person but all users!
I am not interested in becoming a victim of such measures, and I am sure most people here are not either.
Therefore, it would be interesting to see exactly how the process behind the updates looks like and how the developers could counteract such a scenario.
I understand that we are not talking about a company that sells anything, but about a great project that contributes a lot to counteract the data octopus, for that my greatest respect.

But what if an update rolls out which makes the smartphones insecure or unusable, let's move away from intelligence services, etc. because I also found it very strange that after my first installation, the OS made itself independent directly after Internet access without what you can do against it.

applesbana

other8026

Hmm, you can remove the hypothetical if you’d like. The point being, how does one prevent a malicious/faulty update infecting the entire graphene user base when updates are pushed out automatically? Doesn’t matter why it is malicious/faulty.

Another highly security conscious community, the bitcoin community, takes the approach of bitcoin core needing to be updated by the users if and when they choose to. Power to the users. It requires some level of user responsibility though, I guess everything has trade offs

de0u

WhoTheFuckisAlice It happened a few years ago in France, where the French secret service infiltrated an employee, or simply "convinced" an employee of a company that sold secure smartphones. Since these were considered to be very secure smartphones, they were used by many criminals in addition to people who place a lot of value on privacy, which is why the employee installed a malicious code on the smartphones via an update, with which all encryption was broken and the secret service was able to record everything for several months.

When possible it is productive, and supportive of informed discourse, to provide a link to a solid source when presenting a claim like this.
Clearly this could happen, and I'm not doubting that it did, but citing sources is always a good idea when advocating for a policy change.

matchboxbananasynergy

The updater can be disabled:

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

You can either use a feed reader to be notified about GrapheneOS releases and re-enable it to update it, or you can keep it disabled and sideload whenever you want. We recommend that people stay up to date as fixes, including security fixes come through updates, but you can choose your own adventure. Here are steps on how to sideload should you choose to do so:

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

Furthermore, GrapheneOS is reproducible (something that it inherits from AOSP). One can build GrapheneOS and compare it with the releases to see that the code in the release matches the source code.

There's an unofficial effort to make doing exactly that palatable for every day users as well, for those that feel the need to get that extra confirmation, but it's not done yet.

I would also recommend giving this section in the usage guide a read:

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

The update server isn't a trusted party since updates are signed and verified along with downgrade attacks being prevented. The update protocol doesn't send identifiable information to the update server and works well over a VPN / Tor. GrapheneOS isn't able to comply with a government order to build, sign and ship a malicious update to a specific user's device based on information like the IMEI, serial number, etc. The update server only ends up knowing the IP address used to connect to it and the version being upgraded from based on the requested incremental.

Android updates can support serialno constraints to make them validate only on a certain device but GrapheneOS rejects any update with a serialno constraint for both over-the-air updates (Updater app) and sideloaded updates (recovery).

WhoTheFuckisAlice

de0u
no problem i thought this news had be a world wide effect

https://en.m.wikipedia.org/wiki/EncroChat

https://news.sky.com/story/encrochat-what-it-is-who-was-running-it-and-how-did-criminals-get-their-encrypted-phones-12019678

https://www.reuters.com/world/europe/encrypted-phone-service-encrochat-shutdown-leads-6500-arrests-europol-2023-06-27/

https://www.europarl.europa.eu/RegData/etudes/ATAG/2022/739268/EPRS_ATA(2022)739268_EN.pdf

WhoTheFuckisAlice

Thanks a lot for the possibilitys you given.

This automated update system how could I understand? All devs must give a GO and then the code is sign and roll out, or is it a section time thing, the work must be down and all later patches has to wait till next round?

A possibility to compile the code itself is certainly a fine thing, is that possible on any machine, or does it need a Linux outside of Android? It would be very nice if the system does it on its own but waits for a confirmation from the user before applying the update.
I read the manual, but unfortunately not all questions were answered, there are enough reasons why I ended up here... I do not want to talk bad here, I just noticed a few things that I bring up... as so often found something that is in itself fully ingenious, but so few little things where you look up there are everywhere.

de0u

WhoTheFuckisAlice A possibility to compile the code itself is certainly a fine thing, is that possible on any machine, or does it need a Linux outside of Android?

I believe at present it does require a desktop/server Linux: https://grapheneos.org/build

WhoTheFuckisAlice It would be very nice if the system does it on its own but waits for a confirmation from the user before applying the update.

I think it would take at least days for GrapheneOS to compile itself on a GrapheneOS device - maybe weeks. And I think it would wear the flash storage out quickly, if there is even enough to complete a build. I think this is not possible at present or soon.

de0u

WhoTheFuckisAlice no problem i thought this news had be a world wide effect

Thanks! I hadn't heard about that particular incident. And now I have.