GrapheneOS version 2024101801 released:
https://grapheneos.org/releases#2024101801
See the linked release notes for a summary of the improvements over the previous release.
Forum discussion thread:
https://discuss.grapheneos.org/d/16564-grapheneos-version-2024101801-released
#GrapheneOS #privacy #security
@daedaevibin GrapheneOS has always used verified boot as long as it has been available. Why do you think we don’t use verified boot? It’s clearly listed in our hardware requirements:
https://grapheneos.org/faq#future-devices
We substantially improve the implementation rather than greatly reducing it through the LineageOS changes that are in DivestOS. It doesn’t change that none of these is certified by Google. Some of our improvements to verified boot are included on our features page:
https://grapheneos.org/features
@daedaevibin The Pixel firmware and driver patches depend on Android 15 since it was released on October 15. Additionally, the full Android privacy and security devices across devices now require Android 15. Only a subset of the patches are backported to older Android releases. If you’re using DivestOS on a Pixel, you’re not getting current privacy/security patches. It’s also a much less hardened OS than GrapheneOS with only a subset of the privacy and security features ported to LineageOS.
@[email protected] DivestOS does what they can to undo the reduction of privacy and security caused by LineageOS, which they use for broad device support rather than because it’s a good base for a private or secure OS. DivestOS themselves recommends using GrapheneOS if you can afford a device supporting it. Anyway, it’s very strange that you would think GrapheneOS was the first alternate OS using it. We’ve made substantial improvements to verified boot over the standard Android implementation…
@[email protected] It’s not clear where you get the idea that we don’t use verified boot. That’s clearly contradicted across our documentation. If you look at https://grapheneos.org/install/web, https://grapheneos.org/install/cli, https://grapheneos.org/features, etc. you can clearly see we don’t only use verified boot but significantly improve it over the standard Android implementation. We also provide our Auditor app using the secure element for hardware attestation using per-pairing attestation signing keys.
@GrapheneOS yes, I’m aware of the security and outdated releases of DivestOS. I was simply using it to make relations to what I was saying. They are severely outdated, only having A13 for bluejay.
I would like to request a bit more customization options though, such as fonts or icons designs etc. maybe have a look at EvoX if you really really want to get into the specifics?
I was simply wondering why GrapheneOS didn’t provide a ***pkmd.bin file as well, unlike DivestOS does. It seems to be a more efficient way to get it into the system for verification properly instead of other methods I’ve seen. Maybe there’s something done differently?
@daedaevibin
> I was simply wondering why GrapheneOS didn’t provide a ***pkmd.bin file as well
This is wrong and it’s not clear where you get the idea that we don’t use it. We were the first alternate OS using verified boot and DivestOS implemented it based on our documentation and scripts. We were the ones to reverse engineer the firmware, discover the avb_custom_key support and submitted the documentation to AOSP for it.
> avb_custom_key partition
It is not a partition.
@[email protected]
> It seems to be a more efficient way to get it into the system for verification properly instead of other methods I’ve seen.
There is no other way to flash a key to the secure element for verified boot. That is how verified boot is implemented for an alternate OS. Both of our install processes flash the verified boot public key after flashing the OS. We were the first ones to ever use this functionality before they had official documentation, and we made the initial AOSP docs.
@GrapheneOS ah, got it. I see, like everything else since you don’t seem to provide direct downloads you just have it all flashed at one time through the web interface (or whatever is being used). Right?
@daedaevibin It’s included in the installation zip and flashed by either the web installer or the command-line flashing script included inside of the zip (flash-all.sh). We previously added the AVB public key to the standard factory images zip format but we recently moved to our own improved install zip format which we generate by converting factory images. Our own format is more efficient and allows installing significantly faster while using less memory and storage, that’s all.
@[email protected] We do provide direct downloads, which are available at https://grapheneos.org/releases#devices. Our CLI install process is documented at https://grapheneos.org/install/cli. The install zip is used for both CLI and web install. It includes the verified boot public key. There’s no reason to make people flash it by hand with an extra command, we just flash it after flashing all the firmware and OS images.
@GrapheneOS then what is it if it’s not a partition? It does exist on the pixel 6a/bluejay, and you can flash pkmd.bin files to it. Whenever you do so, or do it incorrectly, etc, fastboot calls it a partition. I guess I must be missing a lot of information somewhere, but all the same, would love to see GrapheneOS develop further and be properly allowed to pass play integrity API.
@daedaevibin It’s not a partition. It gets flashed to the secure element via an API provided by the secure element. The fastboot firmware implemented support for flashing it via the image flashing interface. There’s also not actually a bootloader partition but rather those are containers with images nested inside. There a whole bunch of boot firmware images flashed to separate partitions from bootloader.img. An over-the-air update has them as separate images, not bundled into the bootloader.img.
@[email protected]
> would love to see GrapheneOS develop further and be properly allowed to pass play integrity API.
We fully preserve the privacy/security model and then substantially improve it. We use all of the same hardware-based security features as the stock Pixel OS but also a lot more including MTE (hardware memory tagging), PAC/BTI for userspace too, hardware-level disabling of new USB connections, USB data and the overall port for our USB-C port control feature and other features.
@[email protected]
GrapheneOS fully supports hardware-based attestation. Google is entirely capable of verifying a device runs the genuine GrapheneOS releases:
https://grapheneos.org/articles/attestation-compatibility-guide
Play Integrity API has nothing to do with security regardless of how it’s marketed. It allows a device to pass if it hasn’t received security patches for 8 years. All it does is check if it’s a Google certified device and tries to stop spoofing within constraints of allowing highly insecure, ancient devices to pass.