1

Can we consider the Integrity Check on power-on and the secure boot equal from security point of view?

Secure boot is about allowing only a trusted SW to boot on the processor. A chain of trust can be built as a result of sequence of a securely booted Software components: for example:

  • Bootloader authenticates the OS.
  • The OS authenticates Application.

Let's imagine that a system provides an Integrity check on power on, which means on power-on, the stored data (Bootloader, OS, Application) is hashed and the new hash is compared to the old stored hash of the same data. In this case, the integrity of all the stored SW component are going to be checked all together. Then a boot-up is only allowed when the integrity check was successful.

Does it make a difference to check the integrity/authenticity of the SW one after one (secure boot) or to conduct an integrity check on all of them together on power-on? In other words, when can we consider the integrity check and the secure boot equal?

3
  • 1
    How does your integrity check work? is is a hash or is it a key based signutare? Also what is it you are trying to protect against? – LvB Jan 28 '20 at 15:13
  • @lvB the integrity check is hash based. On power-on, a hash is conducted on the whole ROM area and the new digest is compared to the reference digest. In case of mismatch, the system still allowed to boot but a message is sent to a some kind of control unit within the SoC. – Lavender Jan 30 '20 at 8:02
  • @lvB and I would like to ensure that only trusted SW run on the SoC. – Lavender Jan 30 '20 at 8:27
2

The advantage of Secure Boot vs your Integrity check is that Secure Boot allows updating. Secure boot verifies the bootloader's signature, so the bootloader can be updated without changing the the SecureBoot bios. The bootloader checks the kernel's signature, so the kernel can be updated without updating the bootloader.

This means that the BIOS can be made by a different group from the bootloader, and similarly the bootloader can be different from the kernel, ditto os, and applications.

A hashed thing can't be updated without updating the hash, so the entire stack has to be updatable or nothing is. If the root is updatable then it is a risk of the entire update infrastructure. For SecureBoot, if you can protect the signing key, the actual way of getting the update to the device can be broken without risking the device running malicious code. (It might end up running old versions of the legitimate code though).

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.