Quite often, when one thinks about security and cryptography in particular, the focus is on confidentiality: How do I keep my messages secret? How do I keep my computing device secure so that attackers cannot access my valuable data?
However, integrity is quite often even a prerequisite for confidentiality in a computer system. Therefore, one should also ask:
How do I know that the messages I send are received unmodified?
How do I know that my computing device behaves as intended and is not running some malicious piece of software that leaks all my secrets to an attacker?
In a personal computer, you might run an anti-malware tool that checks programs before execution and flags the program with suspicious traits as malware (such as known features from existing malware), preventing it from being executed. Anti-malware tools are well-established technology and work quite well as soon as they are running – however, the problem is that they are started up relatively late in the system boot cycle. Before anti-malfare tools, a lot of firmware and software are loaded into the system such as boot loaders, boot managers, operating system kernels, drivers, operating systems, and many other applications. Additionally, anti-malware tools do not provide cryptographic guarantees about software legitimacy.
If an attacker is able to inject malicious code in the low-level software components loaded during the system boot, then the game is lost before it even really started – after that point, the attacker may have full control over the computing device, or at least some very critical part of the system.
What does a secure boot do?
Secure boot refers to a piece of technology that ensures integrity of a computing system during its boot-up process, guaranteeing that a system is booted with firmware and/or software that can be trusted to originate from a known source. More specifically, secure boot ensures that a binary image that is loaded into the system is authentic – that is to say, it has been signed by a legitimate party (for example, the OEM). This is performed by verifying a digital signature, which is attached to the actual firmware/software, by using the legitimate party’s public key.
If secure boot is enabled in a system, then software is allowed to be executed in the system only if it has a digital signature that can be successfully verified. The component that verifies digital signatures and contains the public keys used in those verifications form the root-of-trust for the device. All subsequent trust is derived from this root-of-trust by forming a chain of trust: the root-of-trust verifies a (firmware/software) component, which then itself becomes a trusted component after successful verification and can be used for verifying further components.
What is required from secure boot?
The component that performs the secure boot must be trustworthy. It must be impossible for an attacker to modify the verification process or the public keys which are used in the verification process. In other words, the component must be tamper-proof.
In order to guarantee the immutability, it is often preferred to use a hardware root-of-trust: a tamper-proof hardware component, that can be used in secure boot for performing the verification and one-time programmable memories for public key storage. It is good to understand that sometimes the hardware root-of-trust may support other operations besides those needed in secure boot – hence, it can be used for other cryptographic services as well even during runtime.
One nice feature of secure boot with digital signatures is that the device where the authentication (secure boot) is performed does not need to include any cryptographic secrets, but only public keys. Because of this lack of secrets, the device is a much harder target for attacks. A successful attack would need to manipulate either the functionality of the digital hardware component or replace the public key with a malicious one, both of which are extremely difficult tasks to succeed due to the immutable nature of hardware. Moreover, even if an attacker is able to hack one device as a result of a difficult and laborious physical attack, they have not recovered any information (such as a secret key) that would automatically compromise similar devices. Importantly, the lack of secrets also means that they are not targets for side-channel attacks.
What if also the confidentiality of firmware must be protected?
Every now and then, there may be good reasons to protect both integrity (authenticity) and confidentiality of programs in secure boot; for example, when a firmware/software includes critical intellectual property or hardcoded cryptographic secrets. Good examples are configuration bit files for FPGAs which are typically protected for both confidentiality and authenticity.
In such cases, the aforementioned protection of integrity is not sufficient and actual encryption is required. It is possible to use symmetric encryption combined with message authentication (for example, AES + HMAC) or an authenticated encryption scheme (for example, AES-GCM).
However, in symmetric encryption, the decryption requires cryptographic secrets to be included in the secure boot component, consequently making the device a target for various implementation attacks including side-channel attacks. It is also seldom economically feasible to use a unique key for all devices of a product family (and thus a different firmware image for all of them), so cracking the secrets out of one device typically breaks a large number of similar devices. For this reason, it may be a good idea to use the secret symmetric key only for encryption/decryption (confidentiality protection), where it cannot be avoided, and still use digital signatures and public keys for the integrity protection – then, integrity protection is preserved even if the secret key is leaked from a device.
For more information about secure boot, visit the page for Xiphera’s quantum-resistant nQrux® Secure Boot.
WEBINAR: Quantum-Resilient Secure Boot – Building Trust from Power-up
The trust in a computing platform’s operation is established during its power-up. If this boot sequence is not secured, the entire computing platform may be compromised.
In the webinar Quantum-Resilient Secure Boot – Building Trust from Power-up, part of the webinar series Cryptography Under the Hood, we review how hardware-based cryptographic mechanisms can be used to secure the boot process of a computing platform. We will discover how to secure the confidentiality, integrity, and authenticity of the boot process with post-quantum secure boot.
Watch recording.
