Secure/Verified boot on Raspberry Pi 3


#1

Hi,

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.

Thanks in advance,
Mmbg


#2

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:

  1. Reset
  2. ROM boot strap checks HAB fuse and verifies signature of 2nd stage bootloader using fused public key
  3. 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:

  1. GPU boots Pi via ROM bootstrap, start.elf, etc.
  2. GPU loads kernel and initramfs and hands off to ARM CPU.
  3. 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.
  4. 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.