Secure Boot from Non-Volatile Memory for Programmable SoC Architectures

Streit, Franz-Josef; Fritz, Florian; Becher, Andreas; Wildermann, Stefan; Werner, Stefan; Schmidt-Korth, Martin; Pschyklenk, Michael; Teich, Jürgen

doi:10.48550/arxiv.2004.09453

Cited by 1 publication

(4 citation statements)

References 0 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Another example is the Olympus project [125], [127] whose specifications, source code and hardware are publicly available. We also found several open-hardware approaches documented in the scientific literature [118], [128], [129].…”

Section: ) Special Hardware Requiredmentioning

confidence: 67%

“…Therefore, no additional hardware is needed since the FPGA was already used for the processor. Other approaches [111], [129] also use an FPGA but as a security module on its own. In other words, the FPGA is dedicated to security tasks (boot chain verification, recovery, etc.)…”

Section: ) Platform Independentmentioning

confidence: 99%

“…In all cases, one or more pieces of data must be stored in a secure way in order to compare the calculated value to a known good value. The first method consists in calculating the hash of the not yet trusted layer and comparing it with a known good hash [49], [91], [109], [129], [132]. This method is the simplest to implement but requires to store a golden value per layer measured in a read-only memory.…”

Section: ) Measurement Algorithmmentioning

confidence: 99%

“…Assuming that the firmware cannot change the behavior of the hardware security (which should never be the case), attackers necessarily need physical access to achieve their goals. This method is used by all proprietary projects (see proprietary projects in Table 5) and by approaches using an FPGA as a hardware security module [111], [118], [119], [128], [129].…”

Section: ) First Measurement Stagementioning

confidence: 99%

See 3 more Smart Citations

Firmware Integrity Protection: A Survey

Marchand,

Imine,

Ouarnoughi

et al. 2023

IEEE Access

View full text Add to dashboard Cite

Over the last years, firmware integrity protection has significantly been addressed in various contexts such as internet of things, vehicles, wireless sensor networks and other systems. However, due to variety of studied systems, the proposed approaches often make divergent and sometimes even conflicting security assumptions. In this regard, we propose in this article a complete survey of the most relevant approaches addressing the firmware integrity protection regardless the considered system or field of application. We first organize the approaches in three main categories, depending on the protection type: 1. secure update, 2. attestation, and 3. secure boot. We then propose two new taxonomies, the first one concerns secure update mechanisms and the second one considers secure boot. Moreover, we extend the scope of an existing taxonomy for attestation mechanisms by studying new approaches and discussing limitations. Finally, we identify open research challenges and then give suggestions and guidelines on how to address them.

show abstract