Production mode at boot?

ZYMKEY4
1

Hi everyone,
I just got my zymkey to work with a full root disk encryption with the following setup:

  • Last raspberry pi OS
  • USB boot (no sd card)
  • Initramfs decrypt the drive using the zymkey and the “.lock” key file.

The way my IOT is intended to work implies that nobody could interact with the PI physically.

My next step is to have the production mode enabled, which raises a few concerns:

1/ What are the information used to create the pi “fingerprint”? Are these information available on early boot stage? Should I add additional binaries to my initramfs for the production mode?

2/ According to the table found at https://docs.zymbit.com/reference/binding/ , the dev mode doesn’t work with a copied image. In my use-case, I will have to remaster the USB drive after a few operations. Will this prevent the zymkey to work if I use the same PI, same zymkey, same USB drive and an image acquired after (or before?) setting production mode?

3/ Does adding/modifying an USB drive will allow the zymkey to work? If someone takes the USB key out, extract the initramfs he will have the “.lock” file. Does anything prevents him to create a new initramfs, boot another OS (added on a new partition of the original drive or using a second USB) then decrypting the original root drive?

Thank you for your help

2

@umoox1 - Glad you got things working!

1/ What are the information used to create the pi “fingerprint”? Are these information available on early boot stage? Should I add additional binaries to my initramfs for the production mode?

The Zymkey uses the PI serial number, USB UUID, and the ZYMKEY serial number to create a hash and uses that along with additional salt as a fingerprint. All of the information is available early on. You do not need to add anything else to your initramfs going to Production Mode from Development Mode.

2/ According to the table found at https://docs.zymbit.com/reference/binding/ , the dev mode doesn’t work with a copied image. In my use-case, I will have to remaster the USB drive after a few operations. Will this prevent the zymkey to work if I use the same PI, same zymkey, same USB drive and an image acquired after (or before?) setting production mode?

The table says in Development Mode, you can use a copied image,

Summary: Developer Mode is lenient and will accommodate an SD card change, or a PI4 change (or both). You cannot use a different ZYMKEY. You also can always start over and re-use the ZYMKEY in a new setup

Meaning, if you made an image copy of your USB stick, you could put that on a new USB stick, and in Development Mode, you could use that new USB stick even with a different PI with the same Zymkey.

Once you switch to Production Mode, you cannot switch any of the components, nor use the Zymkey again in a different setup.

Summary: Production Mode is strict and will not unlock an encrypted rootfs without the original SD card, original ZYMKEY and original PI. You cannot re-use that ZYMKEY in a different setup.

3/ Does adding/modifying an USB drive will allow the zymkey to work? If someone takes the USB key out, extract the initramfs he will have the “.lock” file. Does anything prevents him to create a new initramfs, boot another OS (added on a new partition of the original drive or using a second USB) then decrypting the original root drive?

The Zymkey is required to unlock the LUKS keyfile in the initramfs. If someone takes the USB alone, they cannot decrypt the LUKS key in initramfs and therefore cannot unlock the rootfs.

Hope that helps.

Bob

3

Thank you Bob.

For my point “2”, I was thinking “prod” but wrote “dev”, so the think will more likely be:

  • Build the hardware.
  • Create a base image per Hardware (I will have several PI, with their own Zymkey)
  • Backup the full usb image (using dd).
  • Going into production mode.
  • Once every 3/4 month, “dd” the image back to the same USB. The usb ID will not change, neither will the partition UUID.

This should, as I understand things, work. Can you confirm?

Also, should I’ve read that some OS update could make the setup to broke, but I can’t see in which case such a thing might occur.