AnsweredAssumed Answered

Is my HAB approach entirely secure?

Question asked by Vladimir Pustosmehov on Oct 21, 2014
Latest reply on Mar 27, 2017 by Yuri Muhin

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?

Outcomes