I am currently working with my Master’s thesis on researching and implementing/testing state of the art techniques of Verified boot in embedded systems with hard real-time constraints. I thought that it was a good idea to buy a Raspberry Pi 3 (RPi3) to do some tests.
I have been searching for some dedicated cryptographic co-processors with the TPM specification implemented or just a general Hardware Security Module (HSM) for the RPi3 for the past days. One of the options is your product which seems to be a promising solution to my problem.
My question is whether or not you provide drivers or code alike to make it possible for the RPi3 to communicate with your security module during the bootup process (e.g. during the second stage bootloader or earlier)? And if so, are there guides?. Because I would like to verify the integrity of certain stages during the boot process by comparing the hash values or signatures (depending on the technique I use) of images containing the code for the different bootup stages. So basically my plan is to implement a simple Chain of Trust (CoT) concept to provide a Verified boot process.
As far as I understood, the Zymbit security module is (only?) accessible after a fully successful bootup (from the application layer), which in that case would be pointless for me to purchase.
As you’ve probably ascertained, Zymkey is more of a generic HSM than a TPM. As such, it isn’t (and cannot) be used at the core of the boot process. To date, the Raspberry Pi does not implement an HAB strategy. Typically, an HAB strategy employs digital signature verification for each of the low level components along the way in the boot process. On the i.MX6, for example, this feature is implemented with ROM code that knows how to do verify signatures based on fusible material which describes booting options and public keys. Essentially this looks like:
Reset
ROM boot strap checks HAB fuse and verifies signature of 2nd stage bootloader using fused public key
2nd stage bootloader verifies kernel signature using same fused public key and loads kernel if signature is verified
As you may already know, in the Raspberry Pi, the GPU starts the boot process, not the ARM CPU and there is no OTP space available for programming public keys. The Broadcom GPU is proprietary and really can’t be programmed (discounting the open source compiler based on reverse engineering). This means that the soonest that an evaluation could be performed is in the kernel or later.
Zymbit, however, is working on a strategy that could be used to provide a reliable boot process which requires an encrypted root file system plus an initramfs. Measurements for the boot components are stored on the crypto rootfs and are evaluated by the second stage init on the crypto rootfs prior to continuing the boot process:
GPU boots Pi via ROM bootstrap, start.elf, etc.
GPU loads kernel and initramfs and hands off to ARM CPU.
initramfs init uses Zymkey to decrypt a black blob which contains the LUKS key for a dm-crypt rootfs. initramfs hands over to the crypto filesystem with the LUKS key.
The init script on the crypto rootfs evaluates signatures for all of the early components prior to entering the crypto rootfs (e.g. start.elf, initramfs, kernel, bootcfg.txt). If any of these components fails, the system shuts down.
Of course, the above only works if the final crypto rootfs can be sufficiently locked down with good password hygiene and/or ssh keys. Also, there are logistics associated with upgrade of the various boot components.
I hope this answers your questions. Please feel free to follow up.
I have a follow up question. Is it possible we save the boot record somewhere (of course, signed by the Zymbit) so that it can be verified later by either local or remote attestation? How do I know ( or other remote verifier know) this RPi boot the correct and secure way?
Our latest product the SEN (Secure Edge Node) has a feature called supervised boot. Supervised boot will sign /boot files and store the signatures within our secure element on the device. On boot-up the supervised boot feature will verify the signatures on the RPi CM4, before loading all the boot artifacts and allowing the RPi to boot up. This feature can also have a self-destruct (key scrubbing) policy enabled if the user wants.
We do not have any links on integrating directly into a custom kernel.
You do not need to incorporate the zymkey with the kernel to run our security features.
As mentioned above, If you want to secure your kernel. You can use our supervised boot feature to digitally sign that kernel and have it get verified on boot.
The supervised boot feature is not provided in our older products like the Zymkey4.