I have a use-case for the Zymkey 4 with a Raspberry Pi 4B where the “pull the update over the internet” option is impossible, and the “store it on external mass storage” option is undesirable.
In the documentation and searching around the forums, I wasn’t able to figure out whether there was any way to store it in either the encrypted shared data partition of an A/B boot configuration or in an extra partition reserved on the microSD card.
I’m guessing that the shared data partition isn’t decrypted during the image update process and that the configuration process to create the A/B/data partitions would clobber any extra partitions that had been created to hold the update images. Is that correct? And is there any other way to do what I’m thinking?
I was thinking of the same concept, my deployment model fits the same parameters, update via HTTPS is unviable, external media is undesirable…
I currently use a Zymkey4 along with an encrypted root partition set up completely offline, but I lack the secure boot chain that bootware would provide.
I was thinking of generating a separate partition on the SD during its firstboot phase and then using zbcli-imager to pass the .zi image to that, then run the update locally passing it the flag for the mounted partition as the media using A disk only, then collapse the staging partition afterwards to reclaim the typical 2 partition setup but now with an encrypted /root and /boot with the Zymkey HSM providing RoT.
Like I say keen to see if you got anywhere with that testing? Thanks
I ended up asking Zymbit support about this directly, and it turns out that you can pull a .zi image off of the encrypted data partition that the Zymbit tools can set up.
It’s been a while since I did the work to get it running, so I don’t remember the exact steps off the top of my head. I believe the key is that you need to point the update tool at the /dev/mapper/… mapping of the encrypted filesystem as opposed to the /dev/sdXN location of the partition on disk.
I’d been meaning to post an update on here, I managed to achieve this a month or so ago.
My requirement uses a custom RPi image from pi-gen to allow for complete offline setup.
I’ve achieved the above by generating the additional p3 and p4 manually prior to expanding the rfs, this allows me to generate a .zi image without user input, pass it to p4, then use this as the path for the update.
I finally clean up by removing the encrypted p3 and p4 as they aren’t required for my build.
Once I have time I can push some snippets of my modified code if any of it would be of interest.
In conclusion, this is a completely airgapped Secure Boot system with p1 and p2 encrypted file systems, that can be ran repeatedly without user input on new builds.