For security reasons we need to add some steps into u-boot to extend PCRs in our TPM. Because we are using the nano we can sign boot.img and use SecureBoot to ensure it hasn’t been changed. However if we generate boot.scr files and place them in the /boot directory in the first partition this is not protected by SecureBoot, as far as we can find.
What we are hoping is that there is a way to either add a boot.scr to the boot.img itself, or understand the right place to put our own c code to do the PCR extensions. This is our first requirement that has us compiling u-boot source.
Anyone who might have experience in this area willing to give us a few pointers?
please see-also Topic 225952 to create boot.scr for the usage.
in addition, uboot doesn’t verify the images. you may check similar thread, such as Topic 224000, please enable UBoot feature, Verified Boot for your use-case.
thanks
We had known about creating boot.scr and putting it in /boot in the APP partition. However, APP is not signed. Only boot.img is. So we cannot verify that an attacker has not changed APP in some way. We need to put our security code into boot.img instead. If we put a boot.scr into Linux_for_Tegra/bootloader/t210ref/p3450-0000 next to u-boot.bin will it be compiled into boot.img with mkbootimg?
Thank you for the link about Verified Boot, this might be something we can try if it fits in our use case.
The end result we are looking for is FDE using a key stored in the TPM and sealed with PCRs.
I am also having an issue getting commands sent to our TPM on SPI2 in u-boot:
note, Nano series doesn’t support APP partition protection.
please see-also Trusty, a Trusted Execution Environment, it’s applied to Jetson TX2, or later series.
We are aware. Which is why we are having to build the FDE solution ourselves to fulfill our security requirements for the project.
The first step is to get the u-boot measuring our Image, initrc, and dtb and extending the TPM’s PCRs. Then we will generate a key and seal it in the TPM. Then we will use initrd and LUKS to use the key during boot time to decrypt our partitions. The first step is where I am struggling to get u-boot to work with the TPM in a secure way.
Are you referring to the issue I have using SOFT_SPI in u-boot to communicate with our TPM? I will try and change our pinmux to use the regular GPIOs instead of SPI2. However, our TPM communication works great from the OS, so we can’t break that. I’ll change our pinmux and test today. Thanks for the pointer, I’ll let you know how it goes.
I confirmed that changing the PINMUX from SPI function to GPIO did not help our u-boot solution find the TPM, and it broke our TPM communication from the OS.