To use our site, you agree to the use of cookies and data processing according to our privacy statement.
Close
Search

Master your Secure Boot Development: webinar Q&A

On the 30 June 2020, we had the pleasure to host the Master your Secure Boot development webinar. The topic of the webinar was the implementation mistakes we saw during 15 years of secure bootloader evaluations. During this time, we have seen them in all sizes, shapes, and development stages. We discovered that some mistakes in implementing secure bootloaders are very common. This is not surprising given that up until now, no course or book teaches developers how to add security to a bootloader.

Watch the webinar

To save billions of bootloaders from attacks, and help our customers save money from costly redevelopment and reputational damage, we have created an   showing you how to design a secure bootloader.

In this blog post, we answer all the questions that we did not cover during the live webinar. For the full experience, you can watch the webinar here.

The questions are answered by our experts: Martijn Bogaard [JMB], Rafael Boix Carpi [RBC], and Jasmina Omic [JO].

  • Is uboot a robust boot loader? Are there better alternatives?

[JMB]: The robustness of uboot depends a lot on the used configuration. Uboot provides a lot of functionality by default, such as a debug console, booting from USB, over the network, etc. The consequence of the default configuration is a massive attack surface. Most uboot configurations we encounter are not specifically hardened for security, and some of them don’t even provide secure boot.

  • How to handle control and key transitions between different parties during secure boot, such as chip owner, OEM, product developer?

[JO]: There are several approaches used in the market. Some vendors rely on setting up security requirements that the purchasing party should fulfill in a similar fashion to performance requirements. Other vendors request an independent penetration testing report from their supplier based on an open or closed approach (black box/white box). Certification with different schemes is an additional option for some products.

  • What is your opinion on using signed but unencrypted software images loaded by the secure bootloaders? What is the security level compared to signed and encrypted images?

[JMB]: In principle, it should not affect the security of the device. It can still only run the signed and authenticated code. However, it does allow an attacker to study the loaded image and potentially find vulnerabilities in them. However, it is mostly one barrier to make attacking the device (significantly) harder. Sufficiently determined attackers will find a way to bypass the encryption, and some attacks can even be performed without (much) knowledge of the device, even though more knowledge would make it easier. However, using signing might be sufficient to make your device an unattractive target.

  • Is authenticated boot the same as a secure boot?

[JMB]: The definitions and terminology used in the context of secure boot do not seem to be very standardized. We regularly encounter different understandings of the same terms. An authenticated boot typically defines that a system has the ability to check if the version of the software it runs is coming from a trusted source and does not prevent booting untrusted firmware. In many cases, this means that an attacker would already have access to the secrets stored in the device. Therefore, we consider this not to be a secure boot.

  • How do you use Secure Bootloader for Disaster Recovery, i.e., when the application is not downloaded in the field?

[JO]: The security principles can be used independently of the means the recovery –  over the air (OTA), using a USB or debug upload by the repair service. In any case, the update file should be cryptographically verified before installation, and the application that performs the update should not have vulnerabilities that can be exploited during the update process. Access to these debug/USB should be protected with access control mechanisms.

  • Should Bootloaders be stored in EEPROM or be stored in emulated  NAND Flash?

[JMB]: Secure Boot requires an immutable (read: hardware-based) root of trust as a starting point that will then load and authenticate every next boot stage. The storage location of these next boot stages is not relevant, as long as the firmware is loaded into memory and authenticated before it is executed. Theoretically (and there are even some devices that do this), it would even be possible to load the firmware every boot from the network. As long as it is always authenticated before it is executed, the secure boot chain is not interrupted.

  • Should Bootloaders turn off logging or retain it in the field?

[JMB]: Logging reveals helpful information to an attacker, but it does not make a bootloader inherently insecure. It can point an attacker in the direction of potential vulnerability, though.

  • What are the important design choices and pitfalls when designing a bootloader that includes an encrypted firmware flash/update functionality?

[JMB]: This is extensively discussed in the training course, but we often see issues related to software vulnerabilities such as buffer overflows, cryptographic issues such as using outdated algorithms or using well-known algorithms incorrectly, but also issues in the boot logic or having an update mechanism that is much weaker protected than the main boot flow.

  • How to handle vulnerabilities in the Boot ROM without replacing the hardware? (e.g., avoid jailbreak on iPhones with Boot ROM vulnerability)

[JMB]: In principle, a ROM vulnerability is not something you can recover from, and in most cases, it requires replacement of the chip and thus device. However, some (high-end) chips have a proprietary ROM patching mechanism that might help in these cases. Although often, these patching mechanisms have limitations on what kind of issues can be resolved this way and are not a substitute for trying as hard as possible to make the ROM free of vulnerabilities.

  • Are there any real attacks on bootloader?

[RBC]: Unfortunately, there exist many real attacks on bootloader implementations, as it is a common target for attackers; a quick search of “bootloader hack” in your favorite web search engine will yield many results on real products. In the webinar, we mentioned a couple of examples: a vulnerability found in the bootloader process of the OnePlus 6 phone, or an issue with signature verification on early versions of the Nintendo Wii operating system.

  • Is there any universal secure bootloader? For bare metal and OS based?

[RBC]: There exist intermediate bootloader stages with multi-platform compatibility and security features support, such as U-boot; however, as addressed in a previous question in this post, it is up to the implementer to configure all the security features correctly. Using the default configuration usually leads to relaxed security settings, and by default, it does not enable a secure boot chain.

  • How do Secure Bootloaders reduce boot-up times while staying fully secure? What are your recommendations?

[JO]: Security and functionality do not implicitly mean conflicting requirements.  No device is“fully secure.” Product and devices are secure against certain threats and for a period of time. The development of security functions and hardware is advancing, and as with any progress, security is becoming more available and more exposed at the same time. NDAs prohibit us from giving a more in-depth answer.

  • In the automotive sector, where we get ECUs from different suppliers, who should be testing the secure boot. OEM or supplier or both. It can be a generic question, not only for Automotive.

[RBC]: In the automotive domain, cybersecurity-related standards and activities are relatively new if compared to other market segments, and there is no consensus or formal requirement on who should perform this testing activity. As an example, a recent standard such as ISO/SAE 21434 DIS does not specify requirements for which entity in the development process (OEM, Tier1, Tier2) should perform specific cybersecurity activities such as the testing of a secure boot implementation. However, the same standard requires in its Clause 15 that there should exist a document on distributed cybersecurity activities called Cybersecurity interface agreement; this document should describe in detail who does what (regarding cybersecurity) in the customer-supplier relationships. This enables every OEM to tailor its cybersecurity management process in the most appropriate & effective way.

  • What about the IoT market? Did you check ietf-suit draft? STANDARDS: What about the draft from the IETF group SUIT? (offline info about suit) It has interesting guidelines on writing small parsers and cryptography

[JO]: Several standards cover general principles regarding cryptography and security. Still, we are not aware of any standard that focuses on secure boot and covers general concepts relevant for secure boot such as privilege control, secure hardware setup, and data and stages verification. (maybe to mentioned just a few J3101, IETF SUIT, IEC 62443-4-2 – they have something related to secure boot but no details. Sometimes they have details on cryptography but not on how to secure boot with it.) Nevertheless, many resources could be used during the development of secure boot, but the developer will have to consider the whole process and final security goal of the development.

  • How can you protect this bootloader from a fault injection that will make you skip line 77?

[RBC]: There are different approaches to harden a bootloader implementation against fault injection attack, both in the hardware domain and in the software domain. Hardware countermeasures are out of scope for software developers and depend on your platform choice: the supplier will detail how fault injection is mitigated if done by hardware components (e.g., buffers, glitch detectors, shields, etc.). However, in the software domain, there are design patterns that can be followed in order to harden an implementation against Fault Injection. We strongly recommend the Riscure publication “Secure Application Programming in the presence of Side Channel Attacks” by Marc Witteman, where several of these software countermeasures are described.

For these questions, watch the webinar for answers:

  • Are there any good standards?
  • Would it make sense to go to common criteria for bootloader security evaluation?
  • The example is based on mobile devices (Android, I guess). Do you limit testing to SW attacks?
  • When you do an evaluation of bootloaders, what does it mean actually? Only SW evaluation or also HW (device) evaluation?
  • Do you evaluate HW-based attacks like glitch-based attacks (ex. using a ChipShouter)?
  • Can you also evaluate fault injection attacking your simulator?
  • Do you also have tests against hash collision attacks? I saw that you are calculating a SHA1 hash.

Watch the full webinar via this link