Method and system for performing measured boot operation on device

Abstract

A method of performing a measured boot operation on a device, where a plurality of software components forming a boot chain are loaded onto the device when the device is being booted, where the plurality of software components includes at least a first component and a second component, and where the second component executes before the first component, including steps, performed by the second component, of generating a first single-component attestation measurement of the first component by computing a hash over the first component, generating a second single-component attestation measurement of the first component by computing the state of a hash algorithm, generating one or more multi-component attestation measurements by computing the state of the hash algorithm, and encoding the first single-component attestation measurement, the second single- component attestation measurement and the one or more multi-component attestation measurements as attestation evidence.

Description

[0001] METHOD AND SYSTEM FOR PERFORMING MEASURED BOOT OPERATION ON DEVICE

[0002] TECHNICAL FIELD

[0003] The present disclosure relates generally to the field of measured boot; and more specifically, to a method and a system for performing a measured boot operation on a device.

[0004] BACKGROUND

[0005] Advancement in the field of secure boot mechanisms have gained popularity over the years due to their plethora of applications, such as ensuring the integrity and trustworthiness of device firmware and disk images. Secure boot mechanisms play a crucial role in establishing a chain of trust during the boot process, where each boot layer measures and verifies the integrity of the subsequent layer, forming a secure and tamper-resistant foundation for a device's operation. These mechanisms have significance in environments where the device may be exposed to potential attacks or unauthorized modifications. By employing techniques, such as measured boot and attestation evidence, secure boot mechanisms provide a means to verify the authenticity and integrity of the software and firmware components loaded during the boot process, thereby partially mitigating the risk of compromised systems and unauthorized access. However, the field of secure boot mechanisms faces certain challenges and limitations. One of the key problems is the mismatch in measurement granularity between the layer-by-layer measured boot process (e.g., a Device Identifier Composition Engine (DICE) architecture) and reference hashes that cover more than a single boot layer, such as hashes of disk or firmware images. This discrepancy makes it difficult and expensive to modify the format or computation of reference values, as it would require changes on verifier-side database reference values. Additionally, existing solutions often rely on hardware-based mechanisms, such as memory latches or hardware -implemented engines, which may impose additional hardware requirements and increase the complexity and cost of implementation. Furthermore, the requirement for a Trusted Execution Environment (TEE) or specific hardware support in some secure boot mechanisms limits their applicability and compatibility with a wide range of devices. Therefore, there is a need for innovative approaches that address these challenges and provide efficient and flexible secure boot solutions without requiring significant modifications to existing systems or hardware dependencies.

[0006] Therefore, in light of the foregoing discussion, there exists a need to overcome the aforementioned drawbacks associated with the conventional ways of implementing boot mechanisms.

[0007] SUMMARY

[0008] The aim of the present disclosure is to provide a method of performing a measured boot operation on a device to ensure the integrity of software or firmware components loaded during boot operation, thereby enhancing security and trustworthiness of the measured boot operation, and to address the potential risk (if any) of compromised or malicious components being loaded during boot operation. The present disclosure provides a solution to the existing problem of additional hardware requirements, i.e., complexifying and increasing the cost of implementation of partial secure boot mechanisms. An aim of the present disclosure is to provide a solution that overcomes at least partially the problems encountered in the prior art and provide an improved method and system for performing a measured boot operation on a device.

[0009] The object of the present disclosure is achieved by the solutions provided in the enclosed independent claims. Advantageous implementations of the present disclosure are further defined in the dependent claims.

[0010] In one aspect, the present disclosure provides a method of performing a measured boot operation on a device, where a plurality of software components forming a boot chain are loaded onto the device when the device is being booted, where the plurality of software components comprises at least a first component and a second component, and where the second component executes before the first component, comprising steps, performed by the second component, of generating a first single- component atestation measurement of the first component by computing a hash over the first component, generating a second single-component attestation measurement of the first component by computing the state of a hash algorithm, where the first component is provided as an input to the hash algorithm and where the computed state is non-finalised, where non-finalised means that a finish operation of the hash algorithm has not been performed, generating one or more multi-component attestation measurements by computing the state of the hash algorithm, where the first component is provided as an input to the hash algorithm, and further components of the plurality of software components are provided as further inputs to the hash algorithm, and where the computed state is non-finalised and encoding the first single-component atestation measurement, the second single-component atestation measurement and the one or more multi-component atestation measurements as atestation evidence.

[0011] The disclosed method resolves the technical challenge of mismatch in measurement granularity between a DICE -like (layer- by-layer) measured boot process and reference hashes that cover more than a single boot layer, such as hashes of disk or firmware images. The computation of the reference values or changing the format of the reference values is technically challenging and expensive. Such technical challenge is addressed by the disclosed method on an atester-side without changing the verifier-side database reference values. The disclosed method is applicable not only on the DICE -based boots but also, on any layer-wise measured boot. The disclosed method includes the generation of measurements and atestation evidence (e.g., X.509 certificates) in layer-by-layer (i.e., hierarchical, multi-stage) measured boot. The disclosed method also includes encoding of hashes as well as hash states (e.g., non-finalized hash states and partial hash states) with varying coverage in addition to a hash of a current layer measurements and allows the verifier to update the atested or reported hash states (i.e., the non-finalized hash states and partial hash states) with more data.

[0012] In an implementation form, generating the one or more multi-component atestation measurements comprises updating one or more previously computed hash algorithm states based on the first component, where the first component is used as additional input to the hash algorithm.

[0013] The updating of the one or more previously computed hash algorithm states based on the first component eliminates the requirement for additional hardware components and hence, enables a simplified and cost-effective implementation of the measured boot operation.

[0014] In a further implementation form, encoding atestation evidence comprises encoding along with the single-component measurements and the multi-component measurements, a cryptographic public key of the first component, and signing the atestation evidence using a cryptographic private key of the second component.

[0015] The inclusion of the cryptographic public key of the first component in encoding the atestation evidence and signing the atestation evidence using the cryptographic private key of the second component enhances the integrity and trustworthiness of the atestation evidence.

[0016] In a further implementation form, the second component receives a second single-component atestation measurement and multi-component atestation measurements that have been previously generated by another component in the boot chain for the second component.

[0017] The generation of the second single-component atestation measurement and multi-component atestation measurements for the second component by the other component in the boot chain enables a hierarchical or multi-stage measured boot process.

[0018] In a further implementation form, the second-single component attestation measurement and the multi-component attestation measurements encoded into atestation evidence by the second component comprise hashes of one or more partial hashes computed by the second component. The encoding of the second-single component attestation measurement and the multi-component attestation measurements into attestation evidence reduces the risk of compromised or malicious components being loaded during boot operation.

[0019] In a further implementation form, a subsequent component in the boot chain, receives the one or more partial hashes as part of an unprotected binary object.

[0020] The storage of the one or more partial hashes as part of the unprotected binary object saves space in the attestation evidence and thus leads to an optimization of memory consumption and data transmission.

[0021] In a further implementation form, the second component further computes final hashes from the one or more partial hashes and encodes the final hashes into the attestation evidence.

[0022] The computation of the final hashes from the one or more partial hashes and encoding the final hashes into the attestation evidence enhance the security and trustworthiness of the measured boot operation.

[0023] In a further implementation form, the attestation evidence is a certificate whose signature can be verified using a public key of the second component.

[0024] The verification of the attestation evidence using the public key of the second component further enhances the security of the measured boot operation.

[0025] In a further implementation form, the further components include metadata related to the first component.

[0026] The inclusion of the metadata related to the first component for updating the non-finalized hash states enhances the reliability of the measured boot operation.

[0027] In another aspect, the present disclosure provides a system comprising means adapted for carrying out all the steps of the method.

[0028] The system achieves all the advantages and effects of the method after execution of the method.

[0029] In a yet another aspect, the present disclosure provides a computer program comprising instructions for carrying out all the steps of the method, when said computer program is executed on a computer system.

[0030] The computer program achieves all the advantages and effects of the method after execution of the method.

[0031] It is to be appreciated that all the aforementioned implementation forms can be combined.

[0032] It has to be noted that all devices, elements, circuitry, units and means described in the present application couldbe 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. It will be appreciated that features of the present disclosure are susceptible to being combined in various combinations without departing from the scope of the present disclosure as defined by the appended claims. Additional aspects, advantages, features and objects of the present disclosure would be made apparent from the drawings and the detailed description of the illustrative implementations construed in conjunction with the appended claims that follow.

[0033] BRIEF DESCRIPTION OF THE DRAWINGS

[0034] The summary above, as well as the following detailed description of illustrative embodiments, is better understood when read in conjunction with the appended drawings. For the purpose of illustrating the present disclosure, exemplary constructions of the disclosure are shown in the drawings. However, the present disclosure is not limited to specific methods and instrumentalities disclosed herein. Moreover, those skilled in the art will understand that the drawings are not to scale. Wherever possible, like elements have been indicated by identical numbers.

[0035] Embodiments of the present disclosure will now be described, by way of example only, with reference to the following diagrams wherein:

[0036] FIG. 1 illustrates various exemplary components of a system for execution of a measured boot operation, in accordance with an embodiment of the present disclosure;

[0037] FIG. 2 is a flowchart of a method of performing a measured boot operation on a device, in accordance with an embodiment of the present disclosure;

[0038] FIG. 3 illustrates execution of a measured boot operation by a system, in accordance with an embodiment of the present disclosure;

[0039] FIG. 4 illustrates an exemplary use case scenario of a measured boot operation, in accordance with an embodiment of the present disclosure;

[0040] FIG. 5 illustrates an exemplary use case scenario of a measured boot operation, in accordance with another embodiment of the present disclosure;

[0041] FIG. 6 illustrates an exemplary use case scenario of a measured boot operation, in accordance with yet another embodiment of the present disclosure; and

[0042] FIG. 7 is a flowchart for execution of a measured boot operation by a system, in accordance with an embodiment of the present disclosure.

[0043] In the accompanying drawings, an underlined number is employed to represent an item over which the underlined number is positioned or an item to which the underlined number is adjacent. A non-underlined number relates to an item identified by a line linking the non-underlined number to the item. When a number is non-underlined and accompanied by an associated arrow, the non-underlined number is used to identify a general item at which the arrow is pointing.

[0044] DETAILED DESCRIPTION OF EMBODIMENTS

[0045] The following detailed description illustrates embodiments of the present disclosure and ways in which they can be implemented. Although some modes of carrying out the present disclosure have been disclosed, those skilled in the art would recognize that other embodiments for carrying out or practicing the present disclosure are also possible. FIG. 1 illustrates various exemplary components of a system for execution of a measured boot operation, in accordance with an embodiment of the present disclosure. With reference to FIG. 1, there is shown a system 100 that includes a computing device 102. The computing device 102 includes a processor 104, a Read Only Memory (ROM) 106, a Non-Volatile Random Access Memory (NVRAM) 108 and a Random Access Memory (RAM) 110. The ROM 106 includes a second component 112 and a Device Unique Secret (UDS) 114. The NVRAM 108 includes a first component 116, a third component 118 and so on. Each of the processor 104, the ROM 106, the NVRAM 108 and the RAM 110 is communicatively coupled to each other. Each of the ROM 106, the NVRAM 108 and the RAM 110 may be independent units, as shown in FIG. 1. In another implementation scenario, each of the ROM 106, the NVRAM 108 and the RAM 110 may be part of a single unit. The system 100 further includes a verifier 120 that is communicatively coupled to the device 102 through a communication network (not shown in FIG. 1, for sake of brevity).

[0046] There is provided the system 100 for performing a measured boot operation on the device 102, where a plurality of software components forming a boot chain are loaded onto the device 102 when the device 102 is being booted, where the plurality of software components comprises at least the first component 116 and the second component 112, and where the second component 112 executes before the first component 116. The system 100 is configured to resolve the technical challenge of mismatch in measurement granularity between a DICE -like (layer-by-layer) measured boot process and reference hashes that cover more than a single boot layer, such as hashes of disk or firmware images. The computation of the reference values or changing the format of the reference values is technically challenging and expensive. Such technical challenge is addressed by the system 100 on an attester-side (i.e., the device 102 side) without changing the verifier-side (i.e., the verifier 120 side) database reference values. The system 100 is applicable not only on the DICE -based boots but also, on any layer-wise measured boot. The system 100 includes the generation of measurements and attestation evidence (e.g., X.509 certificates) in layer-by- layer (i.e., hierarchical, multi-stage) measured boot. The system 100 also includes encoding of hashes or hash states with varying coverage in addition to a hash of a current layer measurements. Moreover, the system 100 includes encoding of nonfinalized hash states instead of hashes and allows the verifier 120 to update the hash state with more data.

[0047] The system 100 is configured to execute the measured boot operation. More specifically, the processor 104 of the device 102 of the system 100 is configured to execute the measured boot operation.

[0048] The device 102 may include suitable logic, circuitry, interfaces, or code that is configured to execute the measured boot operation. Examples of the device 102 may include, but are not limited to, a computing device, an attester, an attester device, a server, a laptop, a desktop, a smart phone, a tablet, a computing device in a computer cluster (e.g., massively parallel computer clusters), a supercomputer, and the like.

[0049] The processor 104 may include suitable logic, circuitry, interfaces, or code that is configured to execute the instructions stored in each of the ROM 106, the NVRAM 108 and the RAM 110. In an example, the processor 104 may be a general-purpose processor. Other examples of the processor 104 may include, but are not limited to a control unit, a central processing unit (CPU), a digital signal processor (DSP), a microprocessor, a microcontroller, a complex instruction set computing (CISC) processor, an application-specific integrated circuit (ASIC) processor, a reduced instruction set (RISC) processor, a very long instruction word (VLIW) processor, a state machine, a data processing unit, a graphics processing unit (GPU), and other processors or control circuitry. Moreover, the processor 104 may referto one or more individual processors, processing devices, a processing unit that is part of a machine, such as the device 102.

[0050] The ROM 106 may be referred to as a type of non-volatile memory that is used primarily in the device 102 and other electronic devices to store permanent or semi-permanent data, such as the second component 112 and the device unique secret 114. Examples of implementation of the ROM 106 may include, but are not limited to, a Mask ROM (MROM), Programmable Read-Only Memory (PROM), an Erasable Programmable Read-Only Memory (EPROM), an Electrically Erasable Programmable Read-Only Memory (EEPROM), a Flash memory, and the like.

[0051] The NVRAM 108 may refer to a type of memory that retains its stored data even when the power is turned off, similar to the ROM 106. However, unlike the ROM 106, the NVRAM 108 allows for both reading and writing of data. The NVRAM 108 may also be referred to as a Non-Volatile Memory (NVM). Examples of implementation of the NVRAM 108 may include, but are not limited to, an Electrically Erasable Programmable Read-Only Memory (EEPROM), a Flash memory, a Random Access Memory (RAM), and the like.

[0052] The RAM 110 may refer to a type of volatile memory that allows data to be accessed randomly, meaning any byte of memory can be accessed without touching the preceding bytes. The RAM 110 is used by the device 102 and other electronic devices to temporarily store data that can be quickly accessed by the processor 104 or other hardware components. Examples of implementation of the RAM 110 may include, but are not limited to, a Dynamic RAM (DRAM), a Static RAM (SRAM), a Synchronous Dynamic RAM (SDRAM), a Double Data Rate (DDR) SDRAM, and the like.

[0053] In an implementation scenario, the second component 112 may be referred to as a first-stage bootloader or a DICE engine or a boot layer -1. The DICE engine has an exclusive access to the device unique secret 114. The device unique secret 114 may refer to a piece of information or a cryptographic key that is unique to a particular device, such as the device 102. The device unique secret 114 is used for secure communication, authentication, and encryption purposes to ensure the integrity, confidentiality, and authenticity of data transmitted or stored by the device 102. The first component 116 may be referred to as a second-stage bootloader (BL1) and the third component 118 may be referred to as a third-stage bootloader (BL2).

[0054] In another implementation scenario, the NVRAM 108 may store a number of software or firmware components in addition to the first component 116 and the third component 118.

[0055] The verifier 120 may be referred to as an entity responsible for verifying the integrity and authenticity of the measured boot operation. The verifier 120 may be configured to check the measurements or cryptographic hashes of a bootloader, kernel, firmware, and other software or firmware components involved in the measured boot operation against known trusted values or a predefined policy. If the measurements match the expected values, this indicates that the boot process has not been tampered with and can be considered trustworthy. In an implementation scenario, the verifier 120 may be a part of a remote attestation device or a remote attestation server.

[0056] The processor 104 may be configured to execute instructions from the RAM 110 and the ROM 106. The device 102 also includes the NVRAM 108. When the processor 104 is reset or startup occurs, the processor 104 may be configured to execute the instructions belonging to the second component 112 (i.e., the first-stage bootloader) stored in the ROM 106. The second component 112 (i.e., the first-stage bootloader) measures the first component 116 (i.e., the second-stage bootloader (BL1)) and configures the processor 104 to load the first component 116 (i.e., the second-stage bootloader (BL1)) from the NVRAM 108 to the RAM 110. The first component 116 (i.e., the second-stage bootloader (BL 1)) measures the third component 118 (i.e., the third-stage bootloader (BL2)) and configures the processor 104 to load the third component 118 (i.e., the third-stage bootloader (BL2)) from the NVRAM 108 to the RAM 110. Each bootloader contributes to the startup configuration of the device 102.

[0057] In operation, the second component 112 is configured to generate a first single-component attestation measurement of the first component 116 by computing a hash over the first component 116. The second component 112 (i.e., the first-stage bootloader or the DICE engine) measures the binary code and configuration of the first component 116 (i.e., the second-stage bootloader, BL1). Alternatively, may be stated as, the first-stage bootloader measures the second-stage bootloader’s code and the result is the hash, hO. The first single-component attestation measurement corresponds to the hash, hO that is computed using the binary code and configuration of the first component 116 (i.e., the second-stage bootloader, BL1).

[0058] The second component 112 is further configured to generate a second single-component attestation measurement of the first component 116 by computing the state of a hash algorithm, where the first component 116 is provided as an input to the hash algorithm and where the computed state is non-finalized, where non-finalized means that a finish operation of the hash algorithm has not been performed. The second single-component attestation measurement of the first component 116 corresponds to the state of the hash algorithm (e.g., a new hash state). The term "state" of a hash algorithm typically refers to the current internal state or context of the algorithm during computation of the hash algorithm. In the context of cryptographic hash functions, which are used to map an input data of arbitrary size to a fixed-size output (hash value or digest), the state represents the ongoing computation of the hash function as it processes the input data. The state of the hash algorithm is computed using bytes of a memory range (e.g., an address range of the first component 116) as the input to the hash algorithm. The memory range may consist of the bytes that the first component 116 (i.e., the second-stage bootloader, BL1) is able to decode. Moreover, the computed hash state is non-finalized which, means that the finish operation of the hash algorithm is not executed. The finish operation corresponds to one of three operations, such as Init, Update and Finish, executed in typical hash algorithms (e.g., Secure Hash Algorithm (SHA)-256). The Init operation computes a hash state (e.g., 2f56 bits in case of the SHA-256) deterministically based on constant values. The Update operation updates the state of the hash algorithm based on the input data. The Update operation can be called as many times as required. The Finish operation finalizes the state of the hash algorithm (e.g. by updating it based on the total length of the input) and produces the final hash, also called a digest. After execution of the Finish operation, it is not possible to update the hash state any longer. The computed hash state of the first component 116 is shown and described, in detail, for example, in FIG. 3.

[0059] The second component 112 is further configured to generate one or more multi-component attestation measurements by computing the state of the hash algorithm, where the first component 116 is provided as an input to the hash algorithm, and further components of the plurality of software components are provided as further inputs to the hash algorithm, and wherein the computed state is non-finalized. Similar to the generation of the first single-component attestation measurement and the second single-component attestation measurement of the first component 116 (i.e., the first-stage bootloader), the one or more multi-component attestation measurements for the one or more software components (or software layers), are generated. The one or more multi-component attestation measurements corresponds to computation of the state of the hash algorithm for the one or more software components (or software layers), such as the third component 118 (i.e., the third-stage bootloader, BL2), and the like. During computation of the state of the hash algorithm for the one or more software components, the address range of the first component 116 (i.e., the second-stage bootloader, BL1) is used as the input to the hash algorithm.

[0060] In addition to the address range of the first component 116, the further components, such as metadata of the one or more software components are also used as the input to the hash algorithm. Moreover, the computed state of the hash algorithm for the one or more software components is non-finalized means that the finish operation of the hash algorithm is not yet executed.

[0061] In accordance with an embodiment, the further components include metadata related to the first component 116. In an implementation, the further components include the metadata related to the first component 116 (i.e., the second-stage bootloader, BL1). In another implementation, the further components may include the metadata related to the one or more software components, such as the third component 118 (i.e., the third-stage bootloader, BL2), and the like.

[0062] In accordance with an embodiment, generation of the one or more multi-component attestation measurements comprises updating one or more previously computed hash algorithm states based on the first component 116, where the first component 116 is used as additional input to the hash algorithm. The one or more multi-component attestation measurements may include computing the hash algorithm states for the one or more software components, such as third component 118 (i.e., the third- stage bootloader, BL2), and the like, where the computed hash algorithm states are non-finalized. The one or more multicomponent attestation measurements may also include updating the computed hash algorithm states using the first component 116 (i.e., the second-stage bootloader, BL1). For example, if the first component 116 (i.e., the second-stage bootloader, BL1) is configured to decode metadata and load binary code of a subsequent component then, the first component 116 may update the state of the hash algorithm with both the metadata and the binary code. In an implementation scenario, the first component 116 may start another hash state and update it with only the binary code or only the metadata.

[0063] The second component 112 is further configured to encode the first single-component attestation measurement, the second single-component attestation measurement and the one or more multi-component attestation measurements as attestation evidence. The first single-component attestation measurement (i.e., the computed hash over the first component 116), the second single-component attestation measurement (i.e., the computed state of the hash algorithm) and the one or more multicomponent attestation measurements are encoded into a certificate, also known as the attestation evidence. For example, in an implementation scenario, the attestation evidence may be a X.509 certificate containing a public key and the first component’s measurements (i.e., the first single-component attestation measurement, the second single-component attestation measurement and the one or more multi-component attestation measurements). The attestation evidence may be encoded into an X.509 v3 extension, for example, using the features that Trusted Computing Group (TCG) has defined, that is the Trusted Computing Base (TCB) information extension in the context of measured boot operations.

[0064] The encoding of the first single-component attestation measurement, the second single-component attestation measurement and the one or more multi-component attestation measurements as the attestation evidence includes collecting, structuring, and protecting the measurements in a standardized and verifiable format. The encoding ensures that the attestation evidence can be reliably interpreted, verified, and trusted by the relying party or verifier (i.e., the verifier 120).

[0065] In accordance with an embodiment, encoding attestation evidence comprises encoding along with the single-component measurements and the multi-component measurements, a cryptographic public key of the first component 116, and signing the attestation evidence using a cryptographic private key of the second component 112. The second component 112 (i.e., the first- stage bootloader or the DICE engine) generates the attestation evidence and an attestation key (i.e., the cryptographic public key) for the first component 116. The attestation key (i.e., the cryptographic public key) is derived from the accumulated layer measurements (i.e., the first single-component attestation measurement, the second single-component attestation measurement and the one or more multi-component attestation measurements), called Compound Device Identifier (CDI) and the measurements of the subsequent component in the boot chain. The second component 112 (i.e., the first-stage bootloader or the DICE engine) is configured to sign the attestation evidence using the cryptographic private key.

[0066] In accordance with an embodiment, the attestation evidence is a certificate whose signature can be verified using a public key of the second component 112. In an implementation, the attestation evidence comprising the first single-component attestation measurement, the second single-component attestation measurement and the one or more multi-component attestation measurements and the cryptographic public key of the first component 116, may be sent to the verifier 120. The verifier 120 may be configured to use the public key of the second component 112 in order to validate the signature of the certificate (i.e., the attestation evidence). In an implementation scenario of having the multiple software and firmware components in the boot chain, the verifier 120 may receive a chain of attestation evidences (or certificates) comprising the measurements and public keys of each component (or boot layer). In case of receiving the chain of attestation evidences (or certificates), the last component (e.g., a boot layer 4) in the boot chain may receive a nonce from the verifier 120. The last component (i.e., the boot layer 4) then uses its DICE private key (generated for the last component by a preceding component (e.g., a boot layer 3) in the boot chain) to sign the nonce and sends the signature and the certificate chain to the verifier 120. The verifier 120 first validates the certificate chain signatures, and then, uses the public key from the certificate (e.g., a final certificate) to validate the signature of the nonce. The verifier 120 then, looks at each certificate in turn, and tries to find a reference value that matches with the measurement hash in the certificate. If each hash has a corresponding trusted reference value, the verifier 120 accepts the attestation evidences and deems the last component (i.e., the boot layer 4) as trustworthy.

[0067] In accordance with an embodiment, the second component 112 is further configured to receive a second single-component attestation measurement and multi-component attestation measurements that have been previously generated by another component in the boot chain for the second component 112. In a similar pattern of where the second component 112 (i.e., the first-stage bootloader or the DICE engine) generated the first single-component attestation measurement, the second singlecomponent attestation measurement and one or more multi-component attestation measurements for the first component 116 (i.e., the second-stage bootloader, BL1), the other component preceding the second component 112 in the boot chain, may have generated the second single-component attestation measurement and multi-component attestation measurements for the second component 112 (i.e., the first-stage bootloader or the DICE engine). This way, the second component 112 (i.e., the first-stage bootloader or the DICE engine) may receive the second single-component attestation measurement and multi-component attestation measurements from the other component preceding the second component 112 in the boot chain.

[0068] In accordance with an embodiment, the second-single component attestation measurement and the multi-component attestation measurements encoded into attestation evidence by the second component 112 comprise hashes of one or more partial hashes computed by the second component 112. The second component 112 may also check if there is any partial hash present in the attestation evidence, in case of yes, the second component 112 may also compute the final hash by executing the Finish operation of the hash state algorithm.

[0069] In accordance with an embodiment, the second component 112 is further configured to compute final hashes from the one or more partial hashes and encode the final hashes into the attestation evidence. In case of the presence of the one or more partial hashes in the attestation evidence, the second component 112 is configured to compute the final hashes and encode the computed final hashes into the attestation evidence.

[0070] In accordance with an embodiment, a subsequent component in the boot chain, receives the one or more partial hashes as part of an unprotected binary object. The one or more partial hash states are not stored in the attestation evidence (i.e., the certificate) itself. Instead, a single hash is stored in each evidence, shown and described in detail, for example, in FIG. 6. The one or more partial hash states are stored in possibly unprotected binary large objects (blobs). The verifier 120 can extract the one or more partial hash states from the blob and validate them using the hashes from the attestation evidences. This saves space in the attestation evidence and thus, optimizes memory consumption and data transmission.

[0071] Thus, the system 100 provides an efficient and flexible secure boot mechanism without requiring significant modifications to existing systems or hardware dependencies. The system 100 includes computation and encoding of non-finalized hash states in the attestation evidence in addition to measurement of the hash, for each software or firmware component in the boot chain. Therefore, the system 100 enables a wide coverage of hash states in the attestation evidence for each component and allows the verifier 120 to update the non-finalized hash states with more information. Each component (or boot layer) in the boot chain updates a running hash state (which the component can for example, extract from its own attestation evidence) based on the next component layer data, such as metadata and binary code. Thus, the system 100 manifests a dynamic scope of the measurements in contrast to fixed one used in a conventional DICE -based system. The system 100 does not require changes to existing reference value format at the verifier side. Moreover, the system 100 provides more information to the verifier 120 in comparison to the conventional DICE -based system. For example, the conventional DICE certificates only describe hashes of the loaded code. Moreover, the system 100 is simple to implement as a small extension to the DICE -capable bootloaders. The system 100 eliminates the requirement of additional hardware components hence, simplifying the implementation of the measured boot operation. The system 100 resolves the technical challenge of mismatch in measurement granularity between the DICE -like (layer-by-layer) measured boot process and reference hashes that cover more than a single boot layer, such as hashes of disk or firmware images. However, in the conventional DICE-based system, it is difficult to match the DICE measurements against the reference value database due to granularity mismatch.

[0072] FIG. 2 is a flowchart of a method of performing a measured boot operation on a device, in accordance with an embodiment of the present disclosure. FIG. 2 is described in conjunction with elements from FIG. 1. With reference to FIG. 2, there is shown a method 200 of performing a measured boot operation on the device 102. The method 200 includes steps 202 to 208.

[0073] There is provided the method 200 of performing a measured boot operation on the device 102, where a plurality of software components forming a boot chain are loaded onto the device 102 when the device 102 is being booted, where the plurality of software components comprises at least the first component 116 and the second component 112, and where the second component 112 executes before the first component 116, comprising steps, performed by the second component 112. The method 200 is described in more detail in the following way.

[0074] In an implementation, the method 200 may be applicable to a typical DICE -enabled measured boot, used in smartphones. The plurality of software components forming a boot chain, may include, DICE engine, a preloader, a xloader, a Borderlands 2 (BL2), a Trusted Execution Environment Operating System (TEE OS), a Rich Execution Environment (REE) kernel, and the like, are loaded onto the device 102 when the device 102 is being booted. The preloader may be considered as the first component 116 (may also be considered as a boot layer 0) and the DICE engine may be considered as the second component 112 (may also be considered as a boot layer -1) in the boot chain. The second component 112 (i.e., the DICE engine) executes before the first component 116 (i.e., the preloader). The processor 104 of the device 102 (of FIG. 1) causes the second component 112 (i.e., the DICE engine) to execute the steps 202 to 208 of the method 200.

[0075] At step 202, the method 200 comprises generating a first single-component attestation measurement of the first component 116 by computing a hash over the first component 116. The second component 112 (i.e., the DICE engine) measures the binary code of the first component 116 (i.e., the preloader). Alternatively, may be stated as, the DICE engine measures the layer 0 code and the result is the hash, hO — hash( p(), pl)). The first single-component attestation measurement corresponds to the hash, hO — hash( p(l pl)) that is computed overthe address range ( [p 0, pl)) of the first component 116 (i.e., the preloader). The address range of the first component 116 (i.e., the preloader) is shown and described, for example, in FIG. 3.

[0076] At step 204, the method 200 further comprises generating a second single-component attestation measurement of the first component 116 by computing the state of a hash algorithm, where the first component 116 is provided as an input to the hash algorithm and where the computed state is non-finalized, wherein non-finalized means that a finish operation of the hash algorithm has not been performed. The second single-component attestation measurement of the first component 116 corresponds to the state of the hash algorithm. The state of the hash algorithm is computed using bytes of a memory range (e.g., an address range of the first component 116, i.e., ( [p 0, pl))) as the input to the hash algorithm. The memory range may consist of the bytes that the first component 116 (i.e., the preloader) is able to decode. Moreover, the computed hash state is nonfinalized which, means that the finish operation of the hash algorithm is not executed. Various operations (i.e., the Init, Update and Finish operations) of the hash algorithm have been described in detail, for example, in FIG. 1.

[0077] At step 206, the method 200 further comprises generating one or more multi-component attestation measurements by computing the state of the hash algorithm, where the first component 116 is provided as an input to the hash algorithm, and further components of the plurality of software components are provided as further inputs to the hash algorithm, and where the computed state is non-finalized. Similar to the generation of the first single-component attestation measurement and the second single-component attestation measurement of the first component 116 (i.e., the preloader), the one or more multi-component attestation measurements for the one or more software components (or software layers), are generated. The one or more multicomponent attestation measurements corresponds to computation of the state of the hash algorithm for the one or more software components (or software layers), such as the xloader, the BL2, the TEE OS, and the like. During computation of the state of the hash algorithm for the one or more software components, the address range (i.e., ( [p 0, pl))) of the first component 116 (i.e., the preloader) is used as the input to the hash algorithm.

[0078] In accordance with an embodiment, the further components include metadata related to the first component 116. In an implementation, the further components include the metadata related to the first component 116 (i.e., the preloader). In another implementation, the further components may include the metadata related to the one or more software components, such as the xloader, the BL2, the TEE OS, and the like.

[0079] In accordance with an embodiment, generating the one or more multi-component attestation measurements comprises updating one or more previously computed hash algorithm states based on the first component 116, where the first component 116 is used as additional input to the hash algorithm. The one or more multi-component attestation measurements may include computing the hash algorithm states for the one or more software components, such as the xloader, the BL2, the TEE OS, and the like, where the computed hash algorithm states are non-finalized. The one or more multi-component attestation measurements may also include updating the computed hash algorithm states using the first component 116 (i.e., the preloader).

[0080] At step 208, the method 200 further comprises encoding the first single-component attestation measurement, the second singlecomponent attestation measurement and the one or more multi-component attestation measurements as attestation evidence. The first single-component attestation measurement (i.e., the computed hash overthe first component 116), the second singlecomponent attestation measurement (i.e., the computed state of the hash algorithm) and the one or more multi-component attestation measurements are encoded into a certificate, also known as the attestation evidence, have been described in detail, for example, in FIG. 1.

[0081] In accordance with an embodiment, encoding attestation evidence comprises encoding along with the single-component measurements and the multi-component measurements, a cryptographic public key of the first component 116, and signing the attestation evidence using a cryptographic private key of the second component 112. The second component 112 (i.e., the DICE engine) generates the attestation evidence and an attestation key (i.e., the cryptographic public key) for the first component 116. The second component 112 (i.e., the DICE engine) signs the attestation evidence using the cryptographic private key.

[0082] In accordance with an embodiment, the attestation evidence is a certificate whose signature can be verified using a public key of the second component 112. In an implementation, the attestation evidence is the certificate comprising the first singlecomponent attestation measurement, the second single-component attestation measurement and the one or more multicomponent attestation measurements and the cryptographic public key of the first component 116. The certificate is verified using the public key of the second component 112.

[0083] In accordance with an embodiment, the second component 112 receives a second single-component attestation measurement and multi-component attestation measurements that have been previously generated by another component in the boot chain for the second component 112. The other component preceding the second component 112 in the boot chain, may have generated the second single-component attestation measurement and multi-component attestation measurements for the second component 112 (i.e., the DICE engine). Therefore, the second component 112 (i.e., the DICE engine) may receive the second single-component attestation measurement and multi-component attestation measurements from the other component preceding the second component 112 in the boot chain.

[0084] In accordance with an embodiment, the second-single component attestation measurement and the multi-component attestation measurements encoded into attestation evidence by the second component 112 comprise hashes of one or more partial hashes computed by the second component 112. The second component 112 may also check if there is any partial hash present in the atestation evidence, in case of yes, the second component 112 may also compute the final hash by executing the Finish operation of the hash state algorithm.

[0085] In accordance with an embodiment, the second component 112 further computes final hashes from the one or more partial hashes and encodes the final hashes into the atestation evidence. The computation of the final hashes from the one or more partial hashes and encoding of the final hashes into the attestation evidence is shown and described in detail, for example, in FIGs. 3, 4 and 5.

[0086] In accordance with an embodiment, a subsequent component in the boot chain, receives the one or more partial hashes as part of an unprotected binary object. The reception of the one or more partial hashes as part of the unprotected binary object by the subsequent component in the boot chain is shown and described in detail, for example, in FIG. 6.

[0087] The steps 202 to 208 are only illustrative, and other alternatives can also be provided where one or more steps are added, or one or more steps are provided in a different sequence without departing from the scope of the claims herein.

[0088] There is provided a computer program comprising instructions for carrying out all the steps of the method 200. The computer program is executed on a computer system. The computer program is implemented as an algorithm, embedded in a software stored in the non-transitory computer-readable storage medium having program instructions stored thereon, the program instructions being executable by the one or more processors in the computer system to execute the method 200. The non- transitory computer-readable storage means may include, but are not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing. Examples of implementation of computer-readable storage medium, but are not limited to, an Electrically Erasable Programmable Read-Only Memory (EEPROM), a Random Access Memory (RAM), a Read Only Memory (ROM), a Hard Disk Drive (HDD), a Flash memory, a Secure Digital (SD) card, a Solid-State Drive (SSD), a computer-readable storage medium, and / or a CPU cache memory.

[0089] FIG. 3 illustrates execution of a measured boot operation by a system, in accordance with an embodiment of the present disclosure. FIG. 3 is described in conjunction with elements from FIGs. 1 and 2. With reference to FIG. 3, there is shown a flow of execution of a measured boot operation by the system 100 (of FIG. 1). As shown in the FIG. 3, a plurality of software components 302 forming a boot chain are loaded onto the device 102 when the device 102 is being booted. Each of the plurality of software components 302 may be referred to as an executable or loadable code. The plurality of software components 302 may comprise the second component 112 (i.e., the DICE engine), the first component 116 (i.e., the preloader), the third component 118 (i.e., the xloader), a fourth component 304 (e.g., a BL2), a fifth component 306 (e.g., a TEE OS) and a sixth component 308 (e.g., a REE Kernel). The second component 112 (i.e., the DICE engine) executes before the first component 116 (i.e., the preloader). Each of the second component 112 (i.e., the DICE engine), the first component 116 (i.e., the preloader), the third component 118 (i.e., the xloader), the fourth component 304 (i.e., the BL2), the fifth component 306 (i.e., the TEE OS) and the sixth component 308 (i.e., the REE Kernel) may also be represented as a layer -1, layer 0, layer 1, layer 2, layer 3 and layer 4, respectively. The second component 112 (i.e., the DICE engine) is stored in the ROM 106 whereas the first component 116 (i.e., the preloader), the third component 118 (i.e., the xloader), the fourth component 304 (i.e., the BL2), the fifth component 306 (i.e., the TEE OS) and the sixth component 308 (i.e., the REE Kernel) are stored in the NVRAM 108. During execution of the method 200 (i.e., the measured boot operation), the processor 104 of the device 102 is configured to load the first component 116 (i.e., the preloader), the third component 118 (i.e., the xloader), the fourth component 304 (i.e., the BL2), the fifth component 306 (i.e., the TEE OS) and the sixth component 308 (i.e., the REE Kernel) from the NVRAM 108 to the RAM 110, sequentially. Moreover, each of the first component 116 (i.e., the preloader), the third component 118 (i.e., the xloader), the fourth component 304 (i.e., the BL2), the fifth component 306 (i.e., the TEE OS) and the sixth component 308 (i.e., the REE Kernel) has a memory address range. For example, the first component 116 (i.e., the preloader) has a memory address range 116A specified over the interval [p 0, pl). Alternatively, may be stated as, the binary code of the first component 116 (i.e., the preloader) lies at a memory address range 116A specified over the interval [pO,pl). Similarly, the third component 118 (i.e., the xloader) has a memory address range 118A specified over the interval [p2, p3). The fourth component 304 (i.e., the BL2) has a memory address range 304A specified over the interval [p6,p7). The fifth component 306 (i.e., the TEE OS) has a memory address range 306A specified over the interval [p9,pl0). The sixth component 308 (i.e., the REE Kernel) has a memory address range 308A specified over the interval [pl 1, pl2). Furthermore, the memory address range specified over the interval [pl, p2) includes metadata. Similarly, the memory address range specified over the intervals [p3, p4), [p4, p5), [p5, p6), [p7, p8), [p8, p9), [plO, pll) includes metadata related to the plurality of software components 302 loaded onto the device 102. There is further shown other services performed by the system 100 in the memory address range 310. There is further shown disk or firmware images which cover more than a single component (or a single boot layer), such as preload.img, boot.img, system.img, and the like. Furthermore, there is shown a number of hash states, such as s0, st, s2, s3associated with the first component 116 (i.e., the preloader), the third component 118 (i.e., the xloader), the fourth component 304 (i.e., the BL2), and the fifth component 306 (i.e., the TEE OS), respectively. There is further shown one or more partial hash states, such as s2and s3.

[0090] In operation, the measured boot operation starts from the ROM 106 which stores the second component 112 (i.e., the DICE engine). The subsequent coot components are located in long-term storage (i.e., the NVRAM 108). The plurality of software components 302 (i.e., the boot components) are stored as executable (loadable) code and metadata. FIG. 3 shows the memory address ranges of the executable codes (i.e., the plurality of software components 302) and metadata. For example, a binary code of the third component 118 (i.e., the xloader’s code) is stored in the memory address range [p2, p3). The memory address range [pl,p2) contains some metadata related to the third component 118 (i.e., the xloader). The metadata may contain, for example, runtime configuration data, or instructions on how to load the executable codes (i.e., the plurality of software components 302) from the NVRAM 108 to the RAM 110.

[0091] The second component 112 (i.e., the DICE engine), measures the binary code and configuration of the first component 116 (i.e., the preloader’s code) and result is hash hO — h([pO, pl)). The computed hash, hO — h([pO, p )) corresponds to the first single-component attestation measurement. In addition to the first single-component attestation measurement (i.e., the singlelayer hash measurement), the second component 112 (i.e., the DICE engine) measures the second single-component attestation measurement of the first component 116 (i.e., the preloader) by computing the state of the hash algorithm. The computed state of the hash algorithm of the first component 116 may be represented as s0= upd(init, [pO, pl)). The computed state, s0is not finalized which means that the finish operation of the hash algorithm has not been performed. Additionally, the second component 112 (i.e., the DICE engine) may be configured to update the computed state s0using the bytes from the memory address range 116A specified over the interval [ 0, pl). As shown in FIG. 3, the second component 112 (i.e., the DICE engine) encodes the computed hash (i.e., hO — h([pO, pl))) and the computed hash state (i.e., s0= upd(init, [pO, pl))) into attestation evidence (i.e., a certificate c0) and passes the control to the layer 0 (i.e., the first component 116 or the preloader). Similar to the second component 112, the first component 116 (i.e., the preloader or the layer 0) computes the hash and the hash state for the third component 118 (i.e., the xloader of the layer 1) and the computed hash is ht— h([p2, p3)), and the computed hash state is s, = upd(s0, [pl,p3)). For example, if the current layer (i.e., the first component 116) is configured to decode metadata and load binary code of the next layer (i.e., the third component, xloader’s code), then the current layer (i.e., the first component 116) is configured to update the hash state with both the metadata and the binary code. After computing the hash and the hash state, the first component 116 (i.e., the preloader) encodes the computed hash (i.e., ht— h([p2, p3))) and the computed hash state (i.e., s, = upd(s0, [pl, p3))) into attestation evidence (i.e., a certificate q) and passes the control to the layer 1 (i.e., the third component 118 or the xloader). Similar to the first component 116, the third component 118 (i.e., the xloader or the layer 1) computes the hash and the hash state for the fourth component 304 (i.e., the xloader of the layer 1) and the computed hash is h2— h([p6, p7)), and the computed hash state is s2= upd(st, [p5, p7)). The third component 118 (i.e., the xloader or the

[0092] The system 100 employing the measured boot operation may be useful in a use case where the boot image (i.e., boot.img) contains a standard BL2 but possibly a different TEE OS than the one booted on the device 102. In such case, the verifier 120 can extend the partial hash state from BL2 certificate to cover the TEE OS version included in the boot.img (assuming that the verifier 120 knows the TEE OS code). This further allows using h(boot.img) as a reference hash for BL2 only.

[0093] FIG. 4 illustrates an exemplary use case scenario of a measured boot operation, in accordance with an embodiment of the present disclosure. FIG. 4 is described in conjunction with elements from FIGs. 1, 2, and 3. With reference to FIG. 4, there is shown an exemplary use case scenario 400 of the measured boot operation. There is shown a first plurality of hash states, such as s0, s01, s02, s03, which are computed for the first component 116 (i.e., the preloader), the third component 118 (i.e., the xloader), the fourth component 304 (i.e., BL2) and the fifth component 306 (i.e., TEE OS), respectively, using the first component 116 (i.e., the preloader) as the input to the hash algorithm. There is further shown a second plurality of hash states, such as st, s12, s13, which are computed for the third component 118 (i.e., the xloader), the fourth component 304 (i.e., BL2) and the fifth component 306 (i.e., TEE OS), respectively, using the third component 118 (i.e., the xloader) as the input to the hash algorithm. There is further shown a third plurality of hash states, such as s2, s23, which are computed for the fourth component 304 (i.e., BL2) and the fifth component 306 (i.e., TEE OS), respectively, using the fourth component 304 (i.e., the BL2) as the input to the hash algorithm. Furthermore, there is shown a hash state s3computed for the fifth component 306 (i.e., TEE OS). Moreover, there is shown a preload image 402 (i.e., preload.img) extending over the interval [p 0, p3) and a security operating image 404 (secos.img) extending over the interval [p7, plO). There is further shown a database 406 comprising reference hashes and hash states for each of the first component 116 (i.e., the preloader), the third component 118 (i.e., the xloader), the fourth component 304 (i.e., BL2) and the fifth component 306 (i.e., TEE OS).

[0094] In the exemplary use case scenario 400, the certificate c0for the first component 116 (i.e., the preloader) includes the computed hash state s0. The certificate q forthe third component 118 (i.e., the xloader) includes the computed hash states s0and st. The certificate c2for the fourth component 304 (i.e., the BL2) includes the computed hash states s02, s12and s2. The certificate c3for the fifth component 306 (i.e., the TEE OS) includes the computed hash states s03, s13, s23and s3.

[0095] Case 1 : the database 406 has reference value, h[pO, pl) that means the reference hash covers the first component 116 (i.e., the preloader) only. In response to, the verifier 120 is configured to compute the measurements hash as h' — fin(s0) and the verifier 120 accepts if h == h'.

[0096] Case 2: the database 406 has reference value, h[p2, p7) that means the reference hash covers from the third component 118 (i.e., the xloader) to the fourth component 304 (i.e., the BL2). In response to, the verifier 120 is configured to compute the measurements hash as h' — fin(sl 2) and the verifier 120 accepts if h —— h' .

[0097] Case 3 : the database 406 has reference value, h([pO, p3), [p7, plO)) and h2([p7, plO)) that means the reference hash covers from the first component 116 to the third component 118 (i.e., from the preloader to the xloader), and the fifth component 306 (i.e., the TEE OS) but not the fourth component 304 (i.e., the BL2). In response to, the verifier 120 is configured to compute the measurements hash h' — fin(upd(s01,X) where X contains the code of the fifth component 306 (i.e., the TEE OS) and the preceding metadata, i.e., X — [p7, plO). The verifier 120 can get X from an external source, such as from the NVRAM 108 of the device 102 (in case of a local verifier) or from a reference disk image (in case of a remote verifier). Thereafter, the verifier 120 is configured to compute the second measurement hash as h" — fin(s-i) and the verifier 120 accepts if h —— h' AND h" == h2.

[0098] FIG. 5 illustrates an exemplary use case scenario of a measured boot operation, in accordance with another embodiment of the present disclosure. FIG. 5 is described in conjunction with elements from FIGs. 1, 2, 3, and 4. With reference to FIG. 5, there is shown an exemplary use case scenario 500 of the measured boot operation. There is shown a first plurality of hash states, such as s0, s01, s02, s03, which are computed for the first component 116 (i.e., the preloader), the third component 118 (i.e., the xloader), the fourth component 304 (i.e., BL2) and the fifth component 306 (i.e., TEE OS), respectively, using the first component 116 (i.e., the preloader) as the input to the hash algorithm. There is further shown a second plurality of hash states, such as st, s12, s13, which are computed for the third component 118 (i.e., the xloader), the fourth component 304 (i.e., BL2) and the fifth component 306 (i.e., TEE OS), respectively, using the third component 118 (i.e., the xloader) as the input to the hash algorithm. There is further shown a third plurality of hash states, such as s2, s23, which are computed for the fourth component 304 (i.e., BL2) and the fifth component 306 (i.e., TEE OS), respectively, using the fourth component 304 (i.e., the BL2) as the input to the hash algorithm. Furthermore, there is shown a hash state s3computed for the fifth component 306 (i.e., TEE OS). Moreover, there is shown a preload image 402 (i.e., preload.img) extending over the interval [pO, p3) and a security operating image 404 (secos.img) extending over the interval [p7, plO). There is further shown a database 502 comprising reference hashes and hash states for each of the first component 116 (i.e., the preloader), the third component 118 (i.e., the xloader), the fourth component 304 (i.e., BL2) and the fifth component 306 (i.e., TEE OS).

[0099] In the exemplary use case scenario 500, there is shown that the certificate c0for the first component 116 (i.e., the preloader) includes the computed hash state s0. The certificate forthe third component 118 (i.e., the xloader) includes the computed hash states s0and st. The certificate c2for the fourth component 304 (i.e., the BL2) includes the computed hash states s02, s12and s2. The certificate c3for the fifth component 306 (i.e., the TEE OS) includes the computed hash states s03, s13, s23and s3.

[0100] Case 4: the database 502 has following values, the hashes of the first component 116 (i.e., the preloader), the third component 118 (i.e., the xloader) and code of the fourth component 304 (i.e., the BL2) without metadata. The database 502 further has a trusted reference copy of code of the fourth component 304 (i.e., the BL2) and metadata. For example, an operator (or user) of the database 502 may have access to the fourth component 304 (i.e., the BL2), but the first component 116 (i.e., the preloader), the third component 118 (i.e., the xloader) are provided by an external source (e.g., a system-on-chip (SoC) vendor). In such case, the verifier 120 may be configured to validate the first component 116 (i.e., the preloader) by finalizing the hash state, s0and compare the result against h(preloader). Similarly, the verifier 120 is further configured to validate the third component 118 (i.e., the xloader) by finalizing the hash state, s, and compare the result against h(xloader). The verifier 120 is further configured to validate the fourth component 304 (i.e., the BL2) after validating the first component 116 (i.e., the preloader) and the third component 118 (i.e., the xloader). The verifier 120 is configured to update the hash state s01with the trusted reference copy of the fourth component 304 (i.e., the BL2) and metadata and compare the result against the hash state s02.

[0101] FIG. 6 illustrates an exemplary use case scenario of a measured boot operation, in accordance with yet another embodiment of the present disclosure. FIG. 6 is described in conjunction with elements from FIGs. 1, 2, 3, 4, and 5. With reference to FIG. 6, there is shown an exemplary use case scenario 600 of the measured boot operation.

[0102] In the exemplary use case scenario 600, the hash states are not stored in the attestation evidences (i.e., the certificates) itself. Instead, a single hash is stored in each evidence. The hash states are stored in possibly unprotected blobs. The verifier 120 can extract the hash states from the blobs and validate the extracted hash states using the hashes from the evidences. This saves space in the attestation evidence and thus, optimizes memory consumption and data transmission. In the exemplary use case scenario 600, the list of hash states is replaced with single hash. Therefore, the certificate c0for the first component 116 (i.e., the preloader) includes the hash / i(s0). The certificate q for the third component 118 (i.e., the xloader) includes the hash / i(s01, s, ). The certificate c2for the fourth component 304 (i.e., the BL2) includes the hash / i(s02, s12, s2). The certificate c3for the fifth component 306 (i.e., the TEE OS) includes the hash / i(s03, s13, s23, s3). Each component (or layer) has access to the previous hash states, for example, the fourth component 304 (i.e., the BL2) has access to the hash states, s0, s01,si- During attestation, layer can provide hash states in separate blob that is the unprotected blobs. The verifier 120 can validate hash (statelist) that can be found inside the certificate of each layer.

[0103] Case 1: the database (e.g., either the database 406 or the database 502) has reference value, h — h[p2, p3') that means the reference hash covers the third component 118 (i.e., the xloader) only. In response to, the verifier 120 reads the hash states s01, s , from the blob and check / i(s01, s , ) is in c, and the verifier 120 can ensure the integrity of the certificate q. The verifier 120 can be configured to compute the measurement hash as h' — fin(st) and the verifier 120 accepts if h —— h' .

[0104] FIG. 7 is a flowchart for execution of a measured boot operation by a system, in accordance with an embodiment of the present disclosure. FIG. 7 is described in conjunction with elements from FIGs. 1, 2, 3, 4, 5 and 6. With reference to FIG. 7, there is shown a flowchart 700 for execution of the measured boot operation by the system 100 (of FIG. 1). The flowchart 700 includes operations from 702 to 726.

[0105] At operation 702, the device 102 of the system 102 is reset. More specifically, the processor 104 of the device 102 is reset.

[0106] At operation 704, when the processor 104 is reset, the first-stage bootloader (i.e., the second component 112) stored in the ROM 106 is loaded and executed. At operation 706, the processor 104 is configured to extract the device secret, which may be a cryptographic key that is unique to the device 102 and generate a cryptographic private key of the second component 112 (i.e., the first-stage bootloader).

[0107] At operation 708, the processor 104 is configured to cause the second component 112 (i.e., the first-stage bootloader) to initialize a new hash state for the first component 116 (i.e., the second-stage bootloader).

[0108] At operation 710, the processor 104 is configured to cause the second component 112 to update the previous hash states using the first component 116 (or next layer measurements) as input to the hash algorithm.

[0109] At operation 712, the processor 104 is configured to cause the second component 112 to encode the new hash state and the updated previous hash states into the attestation evidence, for example, the certificate c0for the first component 116.

[0110] At operation 714, the processor 104 is configured to cause the second component 112 to encode a cryptographic public key of the first component 116 into the attestation evidence (i.e., the certificate c0).

[0111] At operation 716, the processor 104 is configured to cause the second component 112 to sign the attestation evidence (i.e., the certificate c0) encoded for the first component 116 with own cryptographic private key.

[0112] At operation 718, the processor 104 is configured to cause the second component 112 to generate the cryptographic private key for the next layer (i.e., the first component 116).

[0113] At operation 720, the processor 104 is configured to cause the second component 112 to check if there more components (or boot layers) available in the boot chain. In case of the absence of more boot layers, the operations 722 and 724 are executed, otherwise the operation 726 is executed.

[0114] At operation 722, the processor 104 is configured to cause the second component 112 to execute the application code.

[0115] At operation 724, on remote attestation, the processor 104 is configured to cause the second component 112 to use own cryptographic key and send the attestation evidences computed for each component (or boot layer) to a verifier (i.e. , the verifier 120).

[0116] At operation 726, the processor 104 is configured to cause the second component 112 to load and execute next boot layer in the boot chain and pass the cryptographic private key and attestation evidence computed for the next boot layer. Thereafter, the operations 708 to 720 are executed repeatedly, for each subsequent boot layer in the boot chain.

[0117] Modifications to embodiments of the present disclosure described in the foregoing are possible without departing from the scope of the present disclosure as defined by the accompanying claims. Expressions such as "including", "comprising", "incorporating", "have", "is" used to describe and claim the present disclosure are intended to be constmed in a non-exclusive manner, namely allowing for items, components or elements not explicitly described also to be present. Reference to the singular is also to be constmed to relate to the plural. The word "exemplary" is used herein to mean "serving as an example, instance or illustration". Any embodiment described as “exemplary” is not necessarily to be constmed as preferred or advantageous over other embodiments and / or to exclude the incorporation of features from other embodiments. The word "optionally" is used herein to mean "is provided in some embodiments and not provided in other embodiments". It is appreciated that certain features of the present disclosure, which are, for clarity, described in the context of separate embodiments, may also be provided in combination in a single embodiment. Conversely, various features of the present disclosure, which are, for brevity, described in the context of a single embodiment, may also be provided separately or in any suitable combination or as suitable in any other described embodiment of the disclosure.

Claims

1. CLAIMS1. A method (200) of performing a measured boot operation on a device (102), wherein a plurality of software components (302) forming a boot chain are loaded onto the device (102) when the device (102) is being booted, wherein the plurality of software components comprises (302) at least a first component (116) and a second component (112), and wherein the second component (112) executes before the first component (116), comprising steps, performed by the second component (112), of: generating a first single-component attestation measurement of the first component (116) by computing a hash over the first component (116); and generating a second single-component attestation measurement of the first component (116) by computing the state of a hash algorithm, wherein the first component (116) is provided as an input to the hash algorithm and wherein the computed state is non-finalized, wherein non-finalized means that a finish operation of the hash algorithm has not been performed; generating one or more multi-component attestation measurements by computing the state of the hash algorithm, wherein the first component (116) is provided as an input to the hash algorithm, and further components of the plurality of software components (302) are provided as further inputs to the hash algorithm, and wherein the computed state is non-finalized; and encoding the first single-component attestation measurement, the second single-component attestation measurement and the one or more multi-component attestation measurements as attestation evidence.

2. The method (200) of claim 1, wherein generating the one or more multi-component attestation measurements comprises updating one or more previously computed hash algorithm states based on the first component (116), wherein the first component (116) is used as additional input to the hash algorithm.

3. The method (200) of claim 1, wherein encoding attestation evidence comprises encoding along with the singlecomponent measurements and the multi-component measurements, a cryptographic public key of the first component (116), and signing the attestation evidence using a cryptographic private key of the second component (112).

4. The method (200) of claim 1, wherein the second component (112) receives a second single-component attestation measurement and multi-component attestation measurements that have been previously generated by another component in the boot chain for the second component (112).

5. The method (200) of claim 1, wherein the second-single component attestation measurement and the multicomponent attestation measurements encoded into attestation evidence by the second component (112) comprise hashes of one or more partial hashes computed by the second component (112).

6. The method (200) of claim 5, wherein a subsequent component in the boot chain, receives the one or more partial hashes as part of an unprotected binary object.

7. The method (200) of claim 5, wherein the second component (112) further computes final hashes from the one or more partial hashes and encodes the final hashes into the attestation evidence.

8. The method (200) of claim 1, wherein the attestation evidence is a certificate whose signature can be verified using a public key of the second component (112).

9. The method (200) of claim 1, wherein the further components include metadata related to the first component (116).

10. A system (100) comprising means adapted for carrying out all the steps of the method (200) according to any preceding method claim.

11. A computer program comprising instructions for carrying out all the steps of the method (200) according to any preceding method claim, when said computer program is executed on a computer system.

Images