Fingerprint components when booting from encrypted USB storage

ZYMKEY4 Encrypting File System
1

Everything I’ve found suggests that the zymkey derives the “fingerprint” for the device id /authentication from the host computer and the SD card serial numbers.

However, …

  1. What if the pi is booting from encrypted USB storage and does not have an SD card inserted? Does it use the USB device vendor id instead?

  2. If so, does the zymkey use all attached USB device ids as components of it’s fingerprint? In other words, will attaching other USB devices (for instance, additional but non-bootable unencrypted storage) change the fingerprint and disable the zymkey?

1 Like
2

Is there any additional information regarding this question?

3

A little more information since this came up again…

If you started with the /boot partition on your SD card, encrypted, then put into Production Mode, the setup will only work with that same SD card.

If you were to start without an SD card, say with your /boot and /root partitions on a USB stick, then the USB id would be used. In Production Mode, you would not be able to swap in a different USB stick. Only the USB stick with the /boot partition would be considered for the fingerprint. If you plugged an additional USB stick in, it would not be taken into account. Note also that our encryption script assumes a source device of /dev/mmcblk0. You would have to edit our encryption script to use in this scenario.

More detail on how the fingerprint works.

Salt file: The ZYMKEY salt file is a file that holds a random generated HMAC of the device fingerprint.

  • The device fingerprint is made up of these components:

    • ZYMKEY id

    • pi cpu id

    • pi cpu hardware rev

    • pi cpu model

    • sd card/emmc/usb id

    • mac address

  • To run the standalone apps or zkifc (APIs), the salt must be accepted during the binding process.

  • The salt is always stored in /var/lib/zymbit/(device fingerprint serial number)/s1_fp_salt.bin

Developer mode: Developer mode is very lenient when trying to bind with a salt file.

  • When the ZYMKEY opens a session with the salt, it will store the new salt into the ZYMKEY’s data store.

  • The ZYMKEY will create a salt file when zkifc starts up. zkifc re-creates this salt file whenever it can not see a salt file or the existing one doesn’t match the salt file stored in the ZYMKEY.

  • The standalone apps (zklock/zkunlock/zkgrifs) will not re-create the salt but will accept an existing non-null salt even if it doesn’t match the one stored in the ZYMKEY.

  • Because the standalone apps and zkifc are independent processes, if the user uses a different salt for each process, it will always cause zkifc to regenerate a new salt. This can be dangerous to encrypted filesystems if the different salts are being used in the system prior to being put into production mode.

Production mode: Production mode is very strict when trying to bind with a salt file.

  • Both zkifc and standalone apps will no longer tolerate any salt file that doesn’t match the latest one stored in the ZYMKEY.