1

I need to rate the risk of not having secure boot for a specific embedded device. It is clear to me that secure boot is an essential part of the root of trust of a system.

In the scenario however, I have difficulties describing the specific vulnerabilitiy the device is subject to (And I am pretty sure I am missing an important point of why not having secure boot is a problem). It is a Linux embedded device, it has no direct internet access, it is a managed device, no users log in to the system. It has a webserver with an admin ui, and a few services like ssh.

If a rate the risk I would say, the firmware can be manipulated when the device has already been broken into, so no additional security by adding secure boot. My question: What is the risk of not having secure boot in this specific context? Thank you

6
  • 3
    Does this answer your question? What are the threats addressed by a Hardware Root-of-Trust?
    – vidarlo
    Feb 16, 2023 at 9:29
  • Hi @vidarlo, you are right, the question subject is pretty much the same. I changed it because that response does not answer my question. I understand why a Playstation needs a hardware root of trust and secure boot. But do I need it and why?
    – Rodolfo B
    Feb 16, 2023 at 15:51
  • 1
    "But do I need it and why?" that's something you have to answer. Is there anything on your system that could be compromised if an attacker ran unauthenticated code?
    – ThoriumBR
    Feb 16, 2023 at 16:01
  • It is a Linux embedded device, it has no direct internet access, it is a managed device, no users log in to the system. - Secure Boot sounds irrelevant in this case. the firmware can be manipulated when the device has already been broken into, so no additional security by adding secure boot if this has really happened enabling secure boot is completely useless. Compromised systems need to be wiped and reinstalled. This even includes firmware in rare cases. Real firmware e.g. EFI BIOS, I'm not talking about ROM/storage. Feb 16, 2023 at 22:01
  • @ThoriumBR yes if an attacker runs unauthenticated code anything can happen. But it is not "more" dangerous than having root access to system in this case. So, I need to secure the system, but secure boot seems not to be necessary. And this is the reason why I don't know if not having secure boot is a security problem.
    – Rodolfo B
    Feb 17, 2023 at 14:25

1 Answer 1

2

If a rate the risk I would say, the firmware can be manipulated when the device has already been broken into, so no additional security by adding secure boot. My question: What is the risk of not having secure boot in this specific context? Thank you

In a proper secure boot, firmware cannot be manipulated if the device has been broken into. If it is, it won't boot. If the attacker wipes the device, the key should be held by the SOC durably so newly loaded software cannot be loaded if it is not signed by the installed manufacturer key. Secure boot is about assuring the engineer and the customer that proper operation will be maintained even in the face of physical access to the device. If all of this is not true of one's device the allure of secure boot can be diminished.

Embedded system software is often (and probably should always be) highly limited to exactly what the system needs to run. In these cases root can do little more than run valid software. Some threats of an attacker adding software with this assumption:

  • Attacker added software can cause unexpected behavior causing a reduction in customer perception of the product (ie causing crashes, slow operation, etc).
  • Attacker added software can cause material harm to user or user's property (overrunning factory equipment, disable brakes on a vehicle, etc).
  • Attacker added software can assist in reverse engineering, secrets exfiltration, customer information spying, etc.

Most of these are of course also possible if there is a runtime vulnerability (remote code execution, etc). But adding a file to disk is a lot easier than finding and exploiting a runtime vulnerability. When I did TARAs this was covered under 'likelihood' rather than 'severity.'

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .