topic Re: Is my HAB approach entirely secure? in i.MX Processors

Is my HAB approach entirely secure?

themylogin — Wed, 22 Oct 2014 05:04:22 GMT

We need to encrypt SD card in our i.MX6 board so no one can read it and steal our software. I am surprised there is no tutorial on the web how to do it (only how to sign u-boot & kernel — but what's the point if user-space code can still be substituted?) so here is my approach.

Board is Hummingboard, so I use SolidRun/u-boot-imx6 · GitHub (u-boot 2013, not 2009 that is covered in all tutorials, that consists of SPL and u-boot itself) and SolidRun/linux-imx6-3.14 · GitHub
The first-stage bootloader that is authenticated by chip itself is SPL — so it is signed as in tutorial.
void __noreturn jump_to_image_no_args(struct spl_image_info *spl_image) is overrided in arch/arm/cpu/armv7/mx6/hab.c (as it is originally declared weak) to authenticate executed u-boot image
kernel and initrd images are authenticated by u-boot in arch/arm/lib/bootm.c static void boot_jump_linux(bootm_headers_t *images, int flag).
rootfs is encrypted by luks. Key is supplied by following keyscript: cat /sys/fsl_otp/HW_OCOTP_SRK? | sed ':a;N;$!ba;s/\n//g'.
No user can log in to our board via tty or ssh as all accounts are either non-login shell or password-protected, there are no other ways for user to execute code via running Linux

So no SPL code can be executed except ours, that authenticates u-boot and does not steal SRK fuses values. No u-boot code can be executed except ours, that authenticates kernel and initrd and does not steal SRK fuses values. Kernel and initrd also do not steal SRK fuses values except for internal usage and when kernel is running no other user-space code can be executed as well so SRK fuses values (which should be used to decrypt rootfs) can't be read by user.

Is my approach correct or are there any security holes left in it that can allow user to extract our rootfs contents?

Re: Is my HAB approach entirely secure?

Yuri — Thu, 23 Oct 2014 08:13:12 GMT

Under the HAB technology the SRK fuses contain the hash of the SRK public key and the fuses

can be read. This restriction may be overcome if BSP uses GUI, does not support terminal program,
JTAG is disabled.

As for encryption boot under i.MX6 : in order to generate a Data Encryption Key (DEK) blob for
encrypted boot, the OTPMK must be used, so blobs must be generated on the i.MX6.

Next, this requires the device be in the Closed configuration, so the Mfg Tool U-boot and OS Kernel
images must be signed - in order to use the OTP Master Key. Today we do not have recommendations
and tools for customers how to perform it, sorry.

Have a great day,
Yuri

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

Re: Is my HAB approach entirely secure?

duellm — Tue, 29 Sep 2015 11:07:07 GMT

Using /sys/fsl_otp/HW_OCOTP_SRK? as a secret is insecure because it is just a hash value that can be computed from your signatures public key.

Re: Is my HAB approach entirely secure?

satyadamarla — Wed, 15 Mar 2017 12:57:12 GMT

hello Guys,

Where exactly do you think the key for encrypted rootfs should be? Initramfs or eMMC, etc. What is the best practise followed?

Thanks,

Satya

Re: Is my HAB approach entirely secure?

Yuri — Tue, 21 Mar 2017 04:44:28 GMT

Hello,

perhaps, the following helps.

Passwordless Encrypted Root in Debian

Regards,

Yuri.

Re: Is my HAB approach entirely secure?

satyadamarla — Mon, 27 Mar 2017 12:30:28 GMT

Hello Yurin,

Thanks for the above link. The above works and I have tested it long time ago but I am looking for a solution like

Saving a key in RPMB (Reply Protected Memory Block) of eMMC. Using this key to en/decrypt the key and place it in the initramfs (OR)
Using the unique Device Secret Key of iMX6 processor and using it to for creating a blob of the rootfs key. Using this key to decrypt the rootfs later.

Do you think the concept of encrypted boot (DEK Blob) can be used for decrypting the key that can decrypt the rootfs?

Greets,

Satya

Re: Is my HAB approach entirely secure?

Yuri — Tue, 28 Mar 2017 06:52:37 GMT

Hello,

I think "the concept of encrypted boot (DEK Blob) can be used for decrypting the key

that can decrypt the rootfs". You can use the rootfs key as part of U-boot (in fixed location).

Regards,

Yuri.