Secure boot device for increased cryptographic and ownership resilience

Abstract

The present invention relates to the field of secure boot devices and, more specifically, to a secure boot device that enhances cryptographic and ownership resilience. Therefore, a secure boot device (100) for increased cryptographic and ownership resilience is proposed. The device (100) is configured to store, in a configurable manner, at least two owner profiles (101a, 101b) of the secure boot device (100), and to store, in a configurable manner, a first cryptographic scheme (102) for signing and validation of software (103) running on the secure boot device (100). The device (100) is further configured to determine a first number of valid signatures (104) of the software (103) running on the device (100), wherein each of the first number of valid signatures (104) is based on the owner profiles (101a, 101b) using the first cryptographic scheme (102). Then, if the first number of valid signatures (104) exceeds a predefined threshold (105), the device (100) is configured to execute the software (103), or if the first number of valid signatures (104) does not exceed the predefined threshold (105), to not execute the software (103).

Description

[0001] SECURE BOOT DEVICE FOR INCREASED CRYPTOGRAPHIC AND OWNERSHIP RESILIENCE

[0002] TECHNICAL FIELD

[0003] The present invention relates to the field of secure boot devices and, more specifically, to a secure boot device that enhances cryptographic and ownership resilience. Moreover, a corresponding method and computer program are provided.

[0004] BACKGROUND

[0005] Computing devices, e.g., loT devices as well as high-end servers, are made of a combination of hardware and software components that work together to achieve a certain functionality. Hardware is considered immutable, meaning that it is hard to be changed and usually impractical to change from software. Conversely, software is considered mutable, meaning that it can be easily changed or replaced, by design, such as e.g. through software updates, to fix bugs, add or improve functionality of the device. Software that is closely linked to the hardware of a device is often called “firmware”, but may generally be regarded software.

[0006] From the perspective of securing a computing device, one concern is that an attacker might be able to modify, i.e. to replace or tamper, the software running on top of the hardware in a given system. To prevent such a software modification, modem systems adopt hardware-based designs that rely on hardware components which can cryptographically verify the integrity and authenticity of the software before it is allowed to boot or run on the device. The hardware can be provisioned during manufacturing with the public part of a “root signing key”, which can be used to verify the digital signature of the said software. The root public key may belong to a hardware vendor and is fixed in hardware (e.g. part of the mask ROM, burned in eFuses or written in OTP memory). Thus, the key and the code performing the first digital signature verification are immutable, which means that they cannot be changed for the rest of the lifetime of the device, acting as the Root of Trust (RoT) for the authenticity and integrity verification of the device software. Such a design can be referred to as “Secure Boot” and can be extended in a chain of trust to an arbitrary number of boot stages, where each stage verifies the next stage before running it, e.g. BootROM (1st stage bootloader) > BIOS (2nd stage bootloader) > OS > Applications. In this case, the BootROM represents the RoT and it can be internal or external to a System on Chip (SoC) that runs the software of the device. Also, the BIOS or 2nd stage bootloader is sometimes referred to as the firmware.

[0007] However, using Secure Boot may involve certain challenges:

[0008] One aspect is device RoT ownership: Having only the vendor sign the software that is allowed to run on a device may not be acceptable if a customer who owns the device may be concerned that, after having bought the device, the device vendor may become compromised, go rogue (i.e. become malicious) or be coerced, with the result of malicious software being signed under the root signing key. An unsuspecting device RoT would thus blindly accept malicious software or updates, and the customer would not be able to prevent it. Also, certain customers may be concerned that the vendor may become unable to fulfill its servicing contract and continue to sign software updates for the device during the device lifetime. This would leave it in a critical situation, unable to be patched in case of security vulnerabilities in its software. Given that the software updates are verified by a commonly fixed RoT, there would be no way e.g. for the customer to provide updates by itself, because they would need to be signed with the private key corresponding to the public key which is fixed (“burned”) in the device RoT.

[0009] Another aspect is cryptographic resilience: The cryptographic schemes (i.e. algorithms) underpinning the conventional Secure Boot design are fixed in the RoT hardware, to avoid them being tampered by an attacker. Due to their immutability, in case they become broken or obsolete during the lifetime of the device, or if a critical vulnerability is found in their implementation, they cannot be updated and the device becomes untrustworthy and not repairable through software updates only. In particular, schemes such as RSA and ECC, which are the most common public key schemes for digital signature and are the most used in Secure Boot designs, are known to be broken by a sufficiently powerful quantum computer, making the prospect of them becoming obsolete more likely than ever before . The recent winning scheme proposals from the NIST PQC Competition that aim to provide quantum resistant digital signature capabilities are still not fully standardized and have not benefitted from the same amount of cryptanalysis attempts, and may become subject to the same concerns regarding the discovery of implementation vulnerabilities or becoming broken. The only existing standardized PQC schemes are hash-based signatures schemes. Moreover, there is a problem related to a challenge in the implementation of the Device Identifier Composition Engine (DICE) and of the Implicit Identity Based Device Attestation architecture. The problem relates to the re-certification of a device’s unique cryptographic identity (a.k.a. identifier) that is bound to both the hardware and the first software that is loaded on the device at boot time. Usually, this identity is certified by the device vendor during a secure manufacturing process, however if this first booted software is updated in the field, the certificate becomes invalid, because the unique identity changes. The problem is exacerbated by the fact that software updates are inevitable for devices with long device lifetimes.

[0010] The above problems apply to most computing devices, however they become particularly relevant for long-lived devices, such as telecommunication equipment, cars, airplanes, infrastructure and industrial loT devices, for which a lifetime of 10-15-20 or more years is commonly expected.

[0011] Conventional Secure Boot designs offer no solution to the presented problems.

[0012] SUMMARY

[0013] In view of the above-mentioned problem, an objective of embodiments of the present disclosure is to provide increased cryptographic resilience and multi-ownership of a secure boot device.

[0014] This or other objectives may be achieved by embodiments of the present disclosure as described in the enclosed independent claims. Advantageous implementations of embodiments of the present disclosure are further defined in the dependent claims.

[0015] A first aspect of the present disclosure provides a secure boot device for increased cryptographic and ownership resilience, wherein the device is configured to store, in a configurable manner, at least two owner profiles of the secure boot device; store, in a configurable manner, a first cryptographic scheme for signing and validation of software running on the secure boot device; determine a first number of valid signatures of the software running on the device, wherein each of the first number of valid signatures is based on the owner profiles using the first cryptographic scheme; and if the first number of valid signatures exceeds a predefined threshold, execute the software, or if the first number of valid signatures does not exceed the predefined threshold, do not execute the software. This ensures that device ownership and software signature verification can be decoupled from authenticity enforcement and from the identity management, allowing for flexible owner management. Thus, this concept may be called „multi-ownership“ and can be implemented and enforced by the device RoT (i.e., by the secure boot device).

[0016] The first aspect also ensures that the common-use cryptographic scheme i.e. that is used regularly for Secure Boot and Device Attestation can be decoupled from the long-term maintenance of said common scheme. This is in particular accomplished by moving the common-use cryptographic implementation into a first software stage of the device and outside of the RoT, and by keeping only a long-term, post quantum secure cryptographic scheme inside the immutable part of the RoT. This makes the software stage implementing the common-use cryptographic scheme securely replaceable, effectively allowing to migrate the cryptographic scheme or to fix bugs in its implementation. The concept can be called „ cryptographic resilience^

[0017] The first aspect further allows to re-certify a DICE-based device identity, because this identity depends on the first software stage, which is now securely replaceable, which means that a new identity depending on an updated first software stage can be re-certified in confidence by the RoT, and thus the vendor, or any other owner, can re-issue the certificate for the new identity key.

[0018] The present invention is compatible with traditional Secure Boot and Attestation designs, but the ownership verification and cryptographic scheme verifications are decoupled from the building of the chain of trust specific to Secure Boot and to DICE-based identities.

[0019] Thus, the concept of the present disclosure may also be referred to as “MONACO” (Multi Owner aNd post-quantum CryptO resilient Root of Trust).

[0020] In particular, the configurable manner comprises a replaceable manner.

[0021] In particular, the secure boot device can be external to a System-on-Chip, SoC, or can be comprised by the SoC. In particular, executing the software by the secure boot device includes direct and indirect execution. That is, the secure boot device may initiate execution of the software after a successful validation of the first number of signatures.

[0022] In particular, the software running on the device comprises a firmware of the device.

[0023] In an implementation form of the first aspect, each of the owner profiles is assigned with equal rights for configuring the secure boot device.

[0024] This ensures that all owners of the secure boot device can decide with equal rights.

[0025] In a further implementation form of the first aspect, the first cryptographic scheme comprises at least one of a private key corresponding to one of the owner profiles, a public key corresponding to one of the owner profiles, a certificate corresponding to one of the owner profiles.

[0026] This ensures that the respective owners can use cryptographic functions properly.

[0027] In a further implementation form of the first aspect, the secure boot device is further configured to store a first indication in the secure boot device, indicating, if a predefined number of owners agrees, perform, by the secure boot device, at least one of the following: adding a further owner profile to the secure boot device; removing an owner profile from the secure boot device; query a list of the owner profiles stored in the secure boot device.

[0028] This ensures that only with the acknowledgement of a sufficient number of owners, the respective multi ownership action can be performed.

[0029] In particular, the owners are owners corresponding to the respective owner profiles.

[0030] In particular, the predefined number of owners required to agree is determined based on a fixed number, and / or based on a formula. In particular, the formula is: m is the smallest integer number greater or equal tor x n, wherein m is the number of owners required to agree, r is a predefined proper fraction of owners required to agree and n is the number of owners stored on the device. In a further implementation form of the first aspect, the secure boot device is further configured to store a second indication in the secure boot device, indicating, if a predefined number of owners agrees, replace the first cryptographic scheme with a second cryptographic scheme.

[0031] This ensures that only with the acknowledgement of a sufficient number of owners, the respective cryptographic resilience action can be performed.

[0032] In particular, the first cryptographic scheme can be broken by using quantum computing. In particular, the second cryptographic scheme is a post-quantum cryptographic scheme. In particular, a post-quantum cryptographic scheme is resistant against quantum computing based attacks.

[0033] In a further implementation form of the first aspect, the secure boot device is further configured to determine the predefined number of owners by determining a second number of valid signatures, wherein each signature is created by one of the owners using the first cryptographic scheme.

[0034] This ensures that the acknowledgement for replacing the first cryptographic scheme can be provided by means of the cryptographic functionality provided by the first cryptographic scheme.

[0035] In a further implementation form of the first aspect, the second number of valid signatures is based on signatures relating to at least one of: a firmware image, a software image, a command, an add owner profile command, a remove owner profile command, a change cryptographic scheme command.

[0036] This provides several characteristics based on which it can be determined if the first cryptographic scheme is to be replaced.

[0037] In a further implementation form of the first aspect, the secure boot device is further configured to adapt at least one of the following to the second cryptographic scheme, when replacing the first cryptographic scheme with the second cryptographic scheme: a private key corresponding to one of the owner profiles, a public key corresponding to one of the owner profiles, a certificate corresponding to one of the owner profiles. This ensures that the first cryptographic scheme can be smoothly replaced with the second cryptographic scheme without loss of any cryptographic functionality.

[0038] In a further implementation form of the first aspect, the secure boot device is further configured to operate the first cryptographic scheme in a software stage of the secure boot device.

[0039] This has the advantage that the place for operating the first cryptographic scheme can be precisely defined.

[0040] In particular, the software stage is a first software stage of the secure boot device.

[0041] In a further implementation form of the first aspect, the secure boot device is further configured to operate the first cryptographic scheme in a second level bootloader of the secure boot device. This has the advantage that the place for operating the first cryptographic scheme can be even more precisely defined.

[0042] In particular, the second level bootloader comprises a BIOS.

[0043] In a further implementation form of the first aspect, the boot device is further configured to operate the first cryptographic scheme outside a first level bootloader of the secure boot device.

[0044] This has the advantage that the place for operating the first cryptographic scheme can be even more precisely defined.

[0045] In a further implementation form of the first aspect, the boot device is further configured to operate the first cryptographic scheme outside of a boot ROM and / or a root of trust of the secure boot device.

[0046] This has the advantage that the place for operating the first cryptographic scheme can be even more precisely defined.

[0047] In particular, the at least two owner profiles are stored outside of a first level bootloader, a boot ROM, or a root of trust of the secure boot device. In a further implementation form of the first aspect, the boot device is further configured to recertify a device identity of the secure boot device based on the second cryptographic scheme; and / or, the secure boot device is further configured to verify the second cryptographic scheme based on a third cryptographic scheme, the third cryptographic scheme in particular being a fixed cryptographic scheme.

[0048] This allows to use the second cryptographic scheme for increasing cryptographic resilience of the secure boot device.

[0049] A second aspect of the present disclosure provides a method for increased cryptographic resilience, wherein the method comprises the steps of storing, in a configurable manner, by a secure boot device, at least two owner profiles of the secure boot device, storing, in a configurable manner, by the secure boot device, a first cryptographic scheme for signing and validation of software running on the secure boot device, determining, by the secure boot device, a first number of valid signatures of the software running on the device, wherein each of the first number of valid signatures is based on the owner profiles using the first cryptographic scheme; and if the first number of valid signatures exceeds a predefined threshold, executing, by the secure boot device, the software, or if the first number of valid signatures does not exceed the predefined threshold, not executing, by the secure boot device, the software.

[0050] In an implementation form of the second aspect, each of the owner profiles is assigned with equal rights for configuring the secure boot device.

[0051] In a further implementation form of the second aspect, the first cryptographic scheme comprises at least one of a private key corresponding to one of the owner profiles, a public key corresponding to one of the owner profiles, a certificate corresponding to one of the owner profiles.

[0052] In a further implementation form of the second aspect, the method further comprises storing, by the secure boot device, a first indication in the secure boot device, indicating, if a predefined number of owners agrees, perform, by the secure boot device, at least one of the following: adding a further owner profile to the secure boot device; removing an owner profile from the secure boot device; query a list of the owner profiles stored in the secure boot device.

[0053] In a further implementation form of the second aspect, the method further comprises storing, by the secure boot device, a second indication in the secure boot device, indicating, if a predefined number of owners agrees, replace the first cryptographic scheme with a second cryptographic scheme.

[0054] In a further implementation form of the second aspect, the method further comprises determining, by the secure boot device, the predefined number of owners by determining a second number of valid signatures, wherein each signature is created by one of the owners using the first cryptographic scheme.

[0055] In a further implementation form of the second aspect, the second number of valid signatures is based on signatures relating to at least one of: a firmware image, a software image, a command, an add owner profile command, a remove owner profile command, a change cryptographic scheme command.

[0056] In a further implementation form of the second aspect, the method further comprises adapting, by the secure boot device, at least one of the following to the second cryptographic scheme, when replacing the first cryptographic scheme with the second cryptographic scheme: a private key corresponding to one of the owner profiles, a public key corresponding to one of the owner profiles, a certificate corresponding to one of the owner profiles.

[0057] In a further implementation form of the second aspect, the method further comprises operating, by the secure boot device, the first cryptographic scheme in a software stage of the secure boot device.

[0058] In a further implementation form of the second aspect, the method further comprises operating, by the secure boot device, the first cryptographic scheme in a second level bootloader of the secure boot device. In a further implementation form of the second aspect, the method further comprises operating, by the secure boot device, the first cryptographic scheme outside a first level bootloader of the secure boot device.

[0059] In a further implementation form of the second aspect, the method further comprises operating, by the secure boot device, the first cryptographic scheme outside of a boot ROM and / or a root of trust of the secure boot device.

[0060] In a further implementation form of the second aspect, the method further comprises recertifying, by the secure boot device, a device identity of the secure boot device based on the second cryptographic scheme; and / or, verifying, by the secure boot device, the second cryptographic scheme based on a third cryptographic scheme, the third cryptographic scheme in particular being a fixed cryptographic scheme.

[0061] The second aspect and its implementation forms include the same advantages as the first aspect and its respective implementation forms.

[0062] A third aspect of the present disclosure provides a computer program comprising instructions which, when the program is executed by a computer, cause the computer to perform the method according to the second aspects or any of its implementation forms.

[0063] The third aspect includes the same advantages as the first aspect and its respective implementation forms.

[0064] It has to be noted that all devices, elements, units and means described in the present application could be implemented in the software or hardware elements or any kind of combination thereof. All steps which are performed by the various entities described in the present application as well as the functionalities described to be performed by the various entities are intended to mean that the respective entity is adapted to or configured to perform the respective steps and functionalities. Even if, in the following description of specific embodiments, a specific functionality or step to be performed by external entities is not reflected in the description of a specific detailed element of that entity which performs that specific step or functionality, it should be clear for a skilled person that these methods and functionalities can be implemented in respective software or hardware elements, or any kind of combination thereof. BRIEF DESCRIPTION OF DRAWINGS

[0065] The above-described aspects and implementation forms of the present disclosure will be explained in the following description of specific embodiments in relation to the enclosed drawings, in which

[0066] FIG. 1 shows a schematic view of a secure boot device according to an embodiment of the present disclosure;

[0067] FIG. 2 shows a schematic view of a secure boot device according to an embodiment of the present disclosure in more detail;

[0068] FIG. 3 shows another schematic view of a secure boot device according to an embodiment of the present disclosure;

[0069] FIG. 4 shows a comparison of single ownership and multi ownership according to the present disclosure;

[0070] FIG. 5 shows another schematic view of a secure boot device according to an embodiment of the present disclosure;

[0071] FIG. 6 shows another schematic view of a secure boot device according to an embodiment of the present disclosure;

[0072] FIG. 7 shows a detailed schematic view of an operating scenario of a secure boot device according to the present disclosure;

[0073] FIG. 8 shows a schematic view of a method according to an embodiment of the present disclosure.

[0074] DETAILED DESCRIPTION OF EMBODIMENTS

[0075] FIG. 1 shows a schematic view of a secure boot device 100. The device 100 is for increased cryptographic and ownership resilience. To this end, the secure boot device 100 stores, in a configurable manner, at least two owner profiles 101a, 101b of the secure boot device 100, and also stores, in a configurable manner, a first cryptographic scheme 102 for signing and validation of software 103 running on the secure boot device 100. The secure boot device 100 further determines a first number of valid signatures 104 of the software 103 running on the device 100 by using the first cryptographic scheme 102. Each of the first number of valid signatures 104 is based on the owner profiles 101a, 101b.

[0076] If the first number of valid signatures 104 exceeds a predefined threshold 105, the secure boot device 100 executes the software 103. If the first number of valid signatures 104 does not exceed the predefined threshold 105, the device 100 does not execute the software 103.

[0077] The device 100 is now going to be described in more detail in view of FIG. 2. The device 100 of FIG. 2 includes all functions and features of the device 100 as described in view of FIG. 1.

[0078] As it is illustrated in FIG. 2, each of the owner profiles 101a, 101b optionally can be assigned with equal rights for configuring the secure boot device 100. That is, an owner profile may store an identity of an owner, and respective rights of an owner. If each owner has equal rights, making a decision can be effectively controlled.

[0079] Further optionally, the first cryptographic scheme 102 comprises a private key 201 corresponding to one of the owner profiles 101a, 101b, a public key 202 corresponding to one of the owner profiles 101a, 101b, and / or a certificate 203 corresponding to one of the owner profiles 101a, 101b. Thus, each owner can use and / or benefit from the first cryptographic scheme 102.

[0080] As it is further shown in FIG. 2, a first indication 204 can be stored in the secure boot device 100. The first indication 204 can indicate, if a predefined number of owners agrees. If so, the secure boot device 100, can perform at least one of the following actions: adding a further owner profile to the secure boot device; removing an owner profile from the secure boot device; query a list of the owner profiles stored in the secure boot device. That is, the first indication characterizes the consent that is necessary, to make changes regarding the owners or owner profiles. Further optionally, a second indication 205 can be stored in the secure boot device 100, indicating that, if a predefined number of owners agrees, the first cryptographic scheme 102 should be replaced with a second cryptographic scheme 206. That is, the second indication characterizes the consent that is necessary, to make changes regarding the cryptographic profile.

[0081] Further optionally, the secure boot device 100 can determine the predefined number of owners by determining a second number of valid signatures 207. In particular, each signature can be created by one of the owners using the first cryptographic scheme 102. That is, the owners can consent to the replacement of the first cryptographic scheme by respective signature actions. In particular, the second number of valid signatures 207 is can be based on signatures relating to at least one of a firmware image, a software image, a command, an add owner profile command, a remove owner profile command, a change cryptographic scheme command. That is, a signature relating one of the listed entities can be taken into account, when determining the second number of valid signatures.

[0082] Further optionally, and as shown in FIG. 2, the secure boot device 100 can adapt at least one of the following to the second cryptographic scheme 206: a private key 201 corresponding to one of the owner profiles 101a, 101b, a public key 202 corresponding to one of the owner profiles 101a, 101b, a certificate 203 corresponding to one of the owner profiles 101a, 101b. That is, when replacing the first cryptographic scheme 102 with the second cryptographic scheme 206, keys and certificates can be adapted according to the new scheme.

[0083] Further optionally, the secure boot device can operate the first cryptographic scheme 102 in a software stage of the secure boot device 100. Further optionally, the secure boot device can operate the first cryptographic scheme 102 in a second level bootloader of the secure boot device 100. Further optionally, the secure boot device can operate the first cryptographic scheme 102 outside a first level bootloader of the secure boot device 100. Further optionally, the secure boot device can operate the first cryptographic scheme 102 outside of a boot ROM and / or a root of trust of the secure boot device 100.

[0084] Further optionally, the secure boot device can re-certify a device identity of the secure boot device 100 based on the second cryptographic scheme 206. Further optionally, the secure boot device can verify the second cryptographic scheme 206 based on a third cryptographic scheme, the third cryptographic scheme in particular being a fixed cryptographic scheme. FIG. 3 shows another schematic view of a secure boot device 100 in which the multi ownership functions and the combined crypto resilience functions are explained in more detail. In the following description, the secure boot device 100 can also be called Root of Trust (RoT).

[0085] The secure boot device 100 provides a hardware-based multi-owner RoT design which supports a sufficiently large number N of owner “slots”, that allows to dynamically add or remove equally powerful owners to the device, without depending on a super-owner, and a threshold based “K-out-of-N Secure Boot” capability, where K / N asymmetric signatures must be successfully verified by the RoT during Secure Boot, or for updating the list of active owners, where K<=N. This in particular corresponds to the first indication 204.

[0086] The secure boot device 100 also provides a design where the cryptographic scheme 102 for software signing is upgradable / replaceable and can enable the long-term secure migration of a software signing scheme that is hardware-anchored in a multi-owner RoT from an existing standardized asymmetric crypto scheme (e.g. based on RSA or ECC) to another, likely postquantum asymmetric crypto scheme (e.g. based on Dilithium, SPHINCS+ etc.), that is potentially unknown or non-standardized at the time of the RoT manufacturing. The device 100 also can securely convert all private keys, public keys and certificates of the owners and of the device to the new cryptographic scheme 206. The device also can perform a threshold based Secure Boot authenticity verification of the common-use cryptographic scheme by requiring K / N signature validations. This corresponds to the second indication 205.

[0087] The secure boot device 100 further provides a RoT design that supports TCG Device Identifier Composition Engine (DICE)-based Device Identity (DevID) re-certification in case of changing the first (mutable) software stage of a device. This in particular corresponds to the secure boot device 100 being configured to re-certify a device identity of the secure boot device 100 based on the second cryptographic scheme 206; and / or to the secure boot device 100 being configured to verify the second cryptographic scheme 206 based on a third cryptographic scheme, the third cryptographic scheme in particular being a fixed cryptographic scheme.

[0088] FIG. 4 shows a comparison of a single ownership and a multi ownership concept. In contrast to a conventional solution in which a single party (e.g., a single owner) signs a firmware (e.g., a software 103), the secure boot device 100 supports multiple owners with equal power. Hence, the secure boot device 100 allows to require for example that at least two owners (e.g., represented by the at least two owner profiles 101a, 101b) sign a piece of firmware in order for the device 100 to execute it. This functionality allows to implement explicit trust relationships among multiple parties, and to enforce them over the lifetime of devices. Owners may be added or removed in the field, and it is possible to query the list of current owners. These operations themselves require a certain number of owners to agree for a device to execute them. FIG. 4 depicts the multi-owner architecture.

[0089] There may be two classes of actors in the scheme proposed by the present disclosure: the owners and the device. They can interact with each other through a number of specified commands. Concerning the owners, it is described what actions they need to perform among each other and the expected format of commands to devices. It can be assumed that owners take the necessary steps to comply with this design and that they take the necessary measures to protect their keys and trust in certificates.

[0090] One example of dis disclosure shows a device architecture where the RoT (i.e., the secure boot device 100) is integrated in an SoC of a device, as depicted in FIG. 5. An alternative example would be a device architecture where the RoT (i.e., the secure boot device 100) is discrete, i.e. external to the SoC, such as in FIG. 6. From the perspective of the present disclosure, there is no functional difference between the two examples and it may be adapted to other device architecture variations.

[0091] In contrast to a conventional solution which uses a forever fixed cryptographic scheme (typically RS A or ECC), the first cryptographic scheme 102 that is used to realize the secure boot functionality in the secure boot device 100 (also called it in the rest of the document) can be changed. A default example, the it scheme can be a form of ECC. However, due to the threat of quantum computers to conventional public-key cryptography like RSA and ECC, an update of the scheme to some not-yet determined or standardized scheme may be necessary within the lifetime of the secure boot device 100. The update mechanism itself is secured with so called post-quantum or quantum secure cryptography. A number of such it updates can be supported.

[0092] The secure boot device 100 may use two different cryptographic schemes for distinct purposes in a layered structure. The it scheme is the main scheme used for common operations and it is primarily used to authenticate firmware. This is regarded the lower layer. The second scheme, on the upper layer, is called XMSS. It can be a standardized signature scheme which can resist all known attacks including those based on quantum computing. One limitation of XMSS can be that one can sign only a limited number of messages. That is why the secure boot device 100 can use XMSS only for owner management and for updates of the it cryptographic scheme. All other operations are secured using it signatures. There can be no limitation on the number of it signatures.

[0093] From an implementation view, there can be a first-level bootloader (bootROM), a second-level bootloader (FK) and the actual software (F). The bootROM can authenticate the second-level bootloader and the second-level bootloader can authenticate the next software stage. All operations that involve either of the two cryptographic schemes can be clearly separated. The XMSS scheme and its operations are only available from the bootROM, as this is the most trusted environment because the code is in ROM and immutable. The it scheme and its operations are only available in the second-level bootloader, because they necessarily need to be implemented in software in order to be updateable, and because this bootloader is still a trusted environment. OTP which is used to store a device’s sensitive information is only accessible from bootROM. A depiction of such an implementation is available in FIG. 7.

[0094] The present disclosure can be applied to computing devices, such as telecommunication equipment (routers, base stations, switches, terminals), servers, cars, airplanes, infrastructure and industrial loT devices and so on. The cryptographic resilience design present in this disclosure becomes especially relevant when such devices are expected to last a long lifetime of e.g. 10, 15, 20 or more years.

[0095] In other words, the multi-owner aspect of the design can be managed using a series of certificates that owners sign on each other’s public keys, providing a dynamic root of trust. Security can be guaranteed by thresholds on the number of signatures that must be valid to add owners, remove owners, etc.

[0096] Again in other words, two cryptographic schemes can be used in parallel: a regular asymmetric scheme (say, ECC) used for firmware signature and a quantum-secure one used for owner management and to secure the possible migration of the first one. The second scheme, XMSS, can be a stateful hash-based signature scheme specified in RFC8391. Hash-based signature schemes can be quantum-resistant, meaning the security of the migration is not impacted by the compromise of the current scheme through quantum computers. Such schemes may however limited in the number of messages they can sign. This makes the combination of the two schemes well positioned to meet the dual requirements of the project.

[0097] There can be a number of commands that the owners may exchange in order to agree on e.g. signing a new firmware update for the device 100, or for adding or removing other owners 101a, 101b, or for changing the “pi” cryptographic scheme.

[0098] In the following, some concepts underlying the present invention are again described in other words:

[0099] Multi-ownership: It makes Secure Boot flexible, scalable and secure in a regular operational environment. It is advantageous compared to state-of-the-art schemes which include only one owner, are either pre-provisioned at manufacturing time or only up to one additional owner can be provisioned in the field, in a secure environment.

[0100] The ability to change owners (e.g. from a first customer to a second customer) securely enables to achieve a circular economy in which devices personalized for the first customer do not need to be scraped, and a new owner can deploy and re-use second-hand devices in confidence that the previous customer must not be trusted that it wouldn’t abuse the privileges provided by the prior personalization.

[0101] By supporting multi-ownership, a vendor does not need to totally relinquish control over a sold device and can still provide the legally mandatory warranty services in confidence that a device has always run vendor-approved firmware and software. Complementarily, the customer receives strong control over what software the device is allowed to run and does not need to blindly trust the vendor for always providing trustworthy updates. Moreover, e.g. a regulatory agency does not need to blindly trust the vendor and the operator of a critical infrastructure for always installing benign, high-quality software on the devices, or can prevent the addition of new functionalities that would not satisfy e.g. new national regulations. Additionally, collusion between any subset of the owners can be prevented by the design through careful selection of the parameter values, supporting use cases such as the escrow of source code between the vendor, the customer and escrow partner(s). Cryptographic resilience scheme: It addresses a longstanding concern of cryptographic obsolescence of devices due to the Post Quantum Computer threat or cryptanalysis attacks, it makes novel use of hash-based signatures. The two-layer crypto improves on the state-of-the- art schemes which replace directly RS A or ECC based signature algorithm with XMSS thus suffer from the limitations of XMSS (limited number of signatures, big sizes). The smart combination of XMSS with an existing or upcoming general-purpose signing algorithm is a big novelty that is feasible and cost-effective.

[0102] With this design, vendors and customers can ensure long-term cryptographic compliance of their devices, possibly fortheir entire lifetime, because the scheme fixes only the XMSS scheme in hardware, which is already openly standardized and recommended by many national regulations, while the Fpi scheme can be software-updated to the enforced regulation of the day (more likely “of the decade”).

[0103] Ownership and cryptographic management decoupling: The decoupling of ownership and cryptographic management from the enforcement part of Secure Boot is a key design decision that allows for the above key points to exist.

[0104] The separation of crypto algorithms in two layers: It allows by design the re-certification of DICE keys derived from the first mutable code (firmware) of the device, because this is implemented now as Fpi, so there is always a trusted XMSS device identity key which can certify the DICE-based Fpi key.

[0105] FIG. 8 shows a schematic view of a method 800. The method 800 is for increased cryptographic resilience and comprises a first step of storing 801, in a configurable manner, by a secure boot device 100, at least two owner profiles 101a, 101b of the secure boot device 100. The method comprises a second step of storing 802, in a configurable manner, by the secure boot device 100, a first cryptographic scheme 102 for signing and validation of software 103 running on the secure boot device 100. The method comprises a third step of determining 803, by the secure boot device 100, a first number of valid signatures 104 of the software 103 running on the device 100, wherein each of the first number of valid signatures 104 is based on the owner profiles 101a, 101b using the first cryptographic scheme 102. The method comprises a last step of, if the first number of valid signatures 104 exceeds a predefined threshold 105, executing 804, by the secure boot device 100, the software 103, or if the first number of valid signatures 104 does not exceed the predefined threshold 105, not executing, by the secure boot device 100, the software 103.

[0106] The present disclosure has been described in conjunction with various embodiments as examples as well as implementations. However, other variations can be understood and effected by those persons skilled in the art and practicing the claimed disclosure, from the studies of the drawings, this disclosure, and the independent claims. In the claims as well as in the description, the word “comprising” does not exclude other elements or steps and the indefinite article “a” or “an” does not exclude a plurality. A single element or other unit may fulfill the functions of several entities or items recited in the claims. The mere fact that certain measures are recited in the mutual different dependent claims does not indicate that a combination of these measures cannot be used in an advantageous implementation.

Claims

CLAIMS1. A secure boot device (100) for increased cryptographic and ownership resilience, wherein the device (100) is configured to:- store, in a configurable manner, at least two owner profiles (101a, 101b) of the secure boot device (100),- store, in a configurable manner, a first cryptographic scheme (102) for signing and validation of software (103) running on the secure boot device (100),- determine a first number of valid signatures (104) of the software (103) running on the device (100), wherein each of the first number of valid signatures (104) is based on the owner profiles (101a, 101b) using the first cryptographic scheme (102); and- if the first number of valid signatures (104) exceeds a predefined threshold (105), execute the software (103), or- if the first number of valid signatures (104) does not exceed the predefined threshold (105), do not execute the software (103).

2. The secure boot device (100) according to claim 1, wherein each of the owner profiles (101a, 101b) is assigned with equal rights for configuring the secure boot device (100).

3. The secure boot device (100) according to claim 1 or 2, wherein the first cryptographic scheme (102) comprises at least one of: a private key (201) corresponding to one of the owner profiles (101a, 101b), a public key (202) corresponding to one of the owner profiles (101a, 101b), a certificate (203) corresponding to one of the owner profiles (101a, 101b).

4. The secure boot device (100) according to any one of the preceding claims, further configured to store a first indication (204) in the secure boot device (100), indicating, if a predefined number of owners agrees, perform, by the secure boot device (100), at least one of the following: adding a further owner profile to the secure boot device; removing an owner profile from the secure boot device; query a list of the owner profiles stored in the secure boot device.

5. The secure boot device (100) according to any one of the preceding claims, further configured to store a second indication (205) in the secure boot device (100), indicating, if apredefined number of owners agrees, replace the first cryptographic scheme (102) with a second cryptographic scheme (206).

6. The secure boot device (100) according to claim 4 or 5, further configured to determine the predefined number of owners by determining a second number of valid signatures (207), wherein each signature is created by one of the owners using the first cryptographic scheme (102).

7. The secure boot device (100) according to any one of the preceding claims, wherein the second number of valid signatures (207) is based on signatures relating to at least one of a firmware image, a software image, a command, an add owner profile command, a remove owner profile command, a change cryptographic scheme command.

8. The secure boot device (100) according to any one of claims 5 to 7, further configured to adapt at least one of the following to the second cryptographic scheme (206), when replacing the first cryptographic scheme (102) with the second cryptographic scheme (206): a private key (201) corresponding to one of the owner profiles (101a, 101b), a public key (202) corresponding to one of the owner profiles (101a, 101b), a certificate (203) corresponding to one of the owner profiles (101a, 101b).

9. The secure boot device (100) according to any one of the preceding claims, further configured to operate the first cryptographic scheme (102) in a software stage of the secure boot device (100).

10. The secure boot device (100) according to claim 9, further configured to operate the first cryptographic scheme (102) in a second level bootloader of the secure boot device (100).

11. The secure boot device (100) according to claim 9 or 10, further configured to operate the first cryptographic scheme (102) outside a first level bootloader of the secure boot device (100).

12. The secure boot device (100) according to claim 9, 10 or 11, further configured to operate the first cryptographic scheme (102) outside of a boot ROM and / or a root of trust of the secure boot device (100).

13. The secure boot device (100) according to any one of claims 5 to 12, wherein the secure boot device (100) is further configured to re-certify a device identity of the secure boot device (100) based on the second cryptographic scheme (206); and / or, wherein the secure boot device (100) is further configured to verify the second cryptographic scheme (206) based on a third cryptographic scheme, the third cryptographic scheme in particular being a fixed cryptographic scheme.

14. A method (800) for increased cryptographic resilience, wherein the method (800) comprises the steps of- storing (801), in a configurable manner, by a secure boot device (100), at least two owner profiles (101a, 101b) of the secure boot device (100),- storing (802), in a configurable manner, by the secure boot device (100), a first cryptographic scheme (102) for signing and validation of software (103) running on the secure boot device (100),- determining (803), by the secure boot device (100), a first number of valid signatures (104) of the software (103) running on the device (100), wherein each of the first number of valid signatures (104) is based on the owner profiles (101a, 101b) using the first cryptographic scheme (102); and- if the first number of valid signatures (104) exceeds a predefined threshold (105), executing (804), by the secure boot device (100), the software (103), or if the first number of valid signatures (104) does not exceed the predefined threshold (105), not executing, by the secure boot device (100), the software (103).

15. A computer program comprising instructions which, when the program is executed by a computer, cause the computer to perform the method according to claim 14.

Images