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