1

The whole idea about using Secure Boot in Embedded Systems to boot an operating system is new to me. I've never paid much attention to it previously. I just know that it prevents the loading at start-up of code which has bad credentials which could be potentially a virus.

Recently it has become a requirement in a project we are working on. We use Raspberry Pi and Beaglebone boards with embedded linux for prototyping. It seems that the hardware on these boards do not support secure boot, which I did not know.

I've been searching for exact hardware requirements for secure boot online without too many answers.

My queries are, must the microcontroller be a special one that supports secure boot? Would any ARM core not work? I would have thought that permanently programmable ROM would be all that is needed in order to burn the special key.

I'm just confused about the exact hardware requirements for this, and hopefully, someone with knowledge could shed some light on this. Thanks

  • 1
    What threat are you trying to avoid with Secure Boot? Despite the name, it does not do much to secure the boot process. It is not measured/verified boot. – forest Sep 12 '18 at 19:59
  • Potentially the bootloader trying to load modules / drivers at startup which have bad credentials, hence we would fully load the OS without knowing that there's possibly a virus there. – Engineer999 Sep 13 '18 at 5:29
  • So is it measured boot you want? That is, a chain of trust that goes all the way down to hardware, so the hardware verifies software before it is run initially? – forest Sep 13 '18 at 6:27
  • Yes, exactly, that's the intention – Engineer999 Sep 13 '18 at 6:28
1

If you want to have hardware ensure that software is valid before you boot, you would want to use something like a TPM for measured boot. A TPM is meant to be platform-independent, even if it is most commonly seen on x86 systems. This means it can be made to work with a Raspberry Pi. A TPM will measure the bootloader, kernel, and even firmware before it unseals a secret value. That value can be an encryption key, for example, so that only if the TPM unseals itself will the system be able to continue booting. Since the TPM will only unseal itself if the bootloader and other components of the boot process are in a known-good state, the system will refuse to boot no matter how much modification is done to writable, unencrypted components.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.