Secure execution of software based on cryptographically verified instructions.

Abstract

1. Secure execution of instructions of the software on a computerized device by: accessing software of a computerized device, the software including a plurality of instructions and a respective reference message authentication code (MAC); generating a cryptographic key based at least in part on a key derivation function, an argument of the key derivation function based at least in part on a unique identifier of the computerized device and a value extended from a measurement of contents of the software of an extension mechanism of a platform configuration register of the computerized device; verifying instructions of the plurality of instructions of the software based at least in part on the cryptographic key and the respective reference MACs; and executing the instructions in response to verifying the instructions of the plurality of instructions of the software.

Description

Technical Field

[0001] This disclosure generally relates to computer security. In particular, this disclosure relates to secure execution of instructions on a computerized device.

Background Art

[0002] Human activities and their security often rely on the operation of security and safety - focused systems built from highly - trusted security devices. For example, banks and governments rely on hardware security modules to protect cryptographic materials used for digitally attesting and encrypting data, a nuclear power plant's cooling system relies on sensor outputs, and patient health management in hospitals requires autonomous instrumentation for controlling biological functions. Malicious actors having physical access to such devices can threaten security and safety - focused systems, and thus put human activities, health, or life at risk.

[0003] Highly - trusted security devices need to comply with certain standards such as Federal Information Processing Standard (FIPS) Publication 140 - 2. Such standards certify that the device provides sufficient assurance against a certain class of threats. Manufacturers implement various mitigation techniques (both in software and hardware) to meet such standards. However, adversaries may avoid security protection by tampering with the software that controls the device. Specifically, by modifying the device's memory contents, an adversary can load arbitrary software. This software may disable security checks (thus violating control - flow integrity), provide false values (violating data integrity), read data processed by the device (violating data confidentiality), or a combination thereof.

[0004] Various mitigation mechanisms are known, which primarily focus on achieving software integrity during system boot, protecting data integrity and confidentiality when loading data into system memory, authenticating software instructions before execution, protecting software control flow integrity using static analysis at the compile level, and protecting cryptographic materials necessary to verify or prove device integrity through tamper-responsive mechanisms.

[0005] More specifically, Secure Boot is a design that guarantees the integrity of software loaded into memory from the moment the computer is powered on. The bootstrap process begins within the Central Processing Unit (CPU) package and continues by enabling subsequent hardware components by loading more complex software. The Secure Boot design requires each piece of software to verify the cryptographic signature of the next piece of software before execution. This prevents adversaries from forging digital signatures and thus prevents the loading of malicious software. Such a design assumes that the software implementation is free from memory vulnerabilities. However, software may contain bugs that can be exploited to load arbitrary software into memory. Even with officially proven software free from such vulnerabilities, adversaries may be able to skip the Secure Boot verification process by launching a hardware side-channel attack. For example, an adversary may alter control flow integrity by inverting memory bits in legitimate software already loaded into memory. Thus, program execution may skip certain instructions, i.e., security checks, thereby allowing the loading of unsigned software.

[0006] Memory encryption is a technology that protects devices from attacks where adversaries directly modify data residing in random-access memory (RAM). Specifically, memory encryption protects against adversaries who control peripheral devices via direct memory access (DMA), adversaries who can hijack communication between the CPU and RAM, or adversaries who can steal and later read memory cards (cold boot attacks). The memory management unit (MMU) located inside the CPU package uses encryption keys to encrypt and decrypt all data entering and leaving the CPU package. However, memory encryption does not protect against adversaries who directly boot arbitrary software by modifying the firmware, load custom instructions into RAM by exploiting legitimate software using memory corruption techniques, or execute custom applications by exploiting software vulnerabilities and misconfigurations.

[0007] Some CPU designs propose mitigating software vulnerabilities within the CPU package. Such designs require a dedicated programmable unit for metadata processing. A dedicated function, running in parallel with the instruction processing pipeline, verifies whether an instruction conforms to a policy using the instruction metadata, instruction opcode, registers, and program counters. The policy is loaded during the boot process. Processor architectures have been developed that aim to provide confidentiality, integrity, and authenticity of instructions executed by the CPU according to such CPU designs. Such architectures use metadata to store the Message Authentication Code (MAC) for each instruction. In addition, each instruction is encrypted with a key stored inside the CPU package registers. The main drawback of these solutions is that the policy or encryption key must be loaded during boot. Here, an adversary with physical control of the device could load an arbitrary policy or encryption key, thereby allowing the adversary to execute arbitrary software. Furthermore, the above designs do not provide protection against downgrading software to a vulnerable version, i.e., against rollback attacks.

[0008] FIPS 140-2 Level 3 is a standard used for highly reliable security devices exposed to adversaries who physically control the device. This standard assumes a low probability that an adversary could tamper with device integrity, for example, when the device and tamper-response circuits are powered off. As a result, the adversary could attempt to bypass software-level protections after gaining access to device memory, i.e., read-only memory (ROM), RAM, or CPU cache. FIPS 140-2 Level 4 currently provides the highest level of security. It requires active detection of any physical attack and the removal of critical security parameters stored within the device upon attack detection. However, implementing such mechanisms requires devices to have sophisticated tamper-responsive enclosures that require constant power supply. Therefore, new solutions are needed for securely executing instructions on computerized devices. [Overview of the project]

[0009] The following is an overview to provide a basic understanding of one or more embodiments of this disclosure. This overview is not intended to identify any major or important elements or to define any scope of any particular embodiment or any scope of any claim. Its sole purpose is to present the concepts in a simplified form as a prelude to a more detailed description later. In one or more embodiments described herein, a device, system, computer implementation, apparatus, or computer program product or combination thereof enables the secure execution of instructions on a computerized device.

[0010] Aspects of the present invention disclose a method, system, and computer-readable medium relating to the secure execution of software instructions on a computerized device, wherein the software includes a plurality of instructions and their respective reference message authentication codes (MACs), and the method involves accessing the software, the software comprising a plurality of instructions and their respective reference message authentication codes (MACs), generating a cryptographic key at least in part based on a key derivation function, the arguments of which are at least in part based on a unique identifier of the computerized device and an extended value derived from a measurement of the software content of an extension mechanism of the computerized device's platform configuration registers, verifying an instruction among a plurality of instructions of the software at least in part based on the cryptographic key and their respective reference MACs, and executing the instruction in response to the verification of the instruction among a plurality of instructions of the software. As a result, the method of disclosure derives a deterministic cryptographic key specific to the CPU chip and software, providing rollback protection and stronger security assurances against adversaries with physical access to the device.

[0011] Aspects of the present invention disclose a method for interrupting the execution of a software instruction in response to a failure to validate one of several software instructions, thereby ensuring the authenticity of the code and data even in the presence of a physical adversary.

[0012] The above and other purposes, features, and advantages of this disclosure will become more apparent through a more detailed description of some embodiments of this disclosure shown in the accompanying drawings. The same reference numerals generally refer to the same components in embodiments of this disclosure. [Brief explanation of the drawing]

[0013] [Figure 1] A schematic diagram of a computerized device relating to one embodiment of the present invention is provided. [Figure 2]This document provides a diagram illustrating the operation performed in the computerized device shown in Figure 1, which relates to one embodiment of the present invention. [Figure 3] A flowchart is provided showing the operation sequence of the pre-steps for storing instructions and their respective message authentication codes, according to one embodiment of the present invention. [Figure 4] This document provides a flowchart illustrating the operation sequence related to a device. [Figure 5] A flowchart showing the operation sequence of steps in a verification method according to one embodiment of the present invention is provided. [Figure 6] This document provides a diagram illustrating an authenticated encryption scheme with related data relating to one embodiment of the present invention. [Figure 7] A schematic diagram of the operation pipeline related to one embodiment of the present invention is provided. [Modes for carrying out the invention]

[0014] Some embodiments of this disclosure will be described in more detail with reference to the accompanying drawings illustrating embodiments of this disclosure. However, this disclosure may be carried out in various ways and should therefore not be construed as being limited to the embodiments disclosed herein.

[0015] In one embodiment, one or more components of the system may use hardware, software, or both to solve inherently highly technical problems (e.g., secure execution of software instructions on a computerized device, mitigating software vulnerabilities within a CPU package, protecting a device from attacks where an adversary directly modifies data residing in random-access memory (RAM)). These solutions are not abstract and cannot be performed as a series of mental actions by humans, for example, due to the processing power required to facilitate the secure execution of instructions on a computerized device. Furthermore, some of the processes performed may be carried out by a special computer for performing defined tasks related to the generation of cryptographic keys, at least in part, based on a key derivation function. For example, a special computer may be used to perform tasks related to encryption and decryption algorithms, etc.

[0016] Embodiments of the present invention may be carried out in various forms, and details of exemplary embodiments are discussed below with reference to the drawings.

[0017] Herein, various embodiments of the present invention concerning a computerized method for securely running software on a computerized device will be described in detail with reference to Figures 1, 2, 4, 6, and 7. The present method and its variations will be collectively referred to as "the present method." All reference numerals Sn refer to steps of the method shown in Figures 3 to 6, while reference numerals refer to physical parts or components of the computerized device shown in Figures 1 and 2.

[0018] Generally, this method cryptographically verifies software instructions based on a Message Authentication Code (MAC) before executing the instruction. Verification is performed using a cryptographic key derived at runtime based on the instruction and MAC, according to the Unique Identifier (UID) of the computerized device and values ​​extended from measurements of the software content according to the extension mechanism of the computerized device's Platform Configuration Register (PCR). Thus, this method leverages both the PCR extension mechanism and the UID of the computerized device to establish a trust chain up to the runtime verification of the instruction.

[0019] Figure 1 shows a block diagram of the components of a computerized device (e.g., device 10) according to an exemplary embodiment of the present invention. It should be understood that Figure 1 merely provides an example of one embodiment and does not imply any limitation regarding the environment in which various embodiments may be carried out. Numerous modifications to the illustrated environment may be made.

[0020] Figure 1 includes storage 11, memory 12, a computer processing unit (CPU) 14, a hardware module 20, a circuit 21, and a memory circuit 22. Storage 11 includes components of a computerized device that enable long-term storage and access of data. For example, storage 11 may include forms such as a solid-state drive or a hard drive. Memory 12 is a computer-readable storage medium. In this embodiment, memory 12 includes random-access memory (RAM). Generally, memory 12 may include any suitable volatile or non-volatile computer-readable storage medium. CPU 14 is an electronic circuit that executes instructions, including computer programs. For example, CPU 14 performs basic arithmetic, logical, control, and input / output (I / O) operations specified by instructions in the program. Hardware module 20 is a physical computing device that protects and manages digital keys and performs encryption and decryption functions for digital signatures, strong authentication, and other cryptographic functions. Circuit 21 is a dedicated circuit for measuring the properties of CPU 14 and generating a UID. The memory circuit 22 is a dedicated, fixed-size memory. For example, the memory circuit 22 is one of a small set of data (i.e., a register) that holds a location and is part of the CPU 14.

[0021] Figure 2 is a schematic diagram illustrating the operations performed in device 10 in Figure 1. Figure 2 includes a legitimate entity 5, key 31, and key 32. The legitimate entity 5 is an authorized device (e.g., a software manufacturer or owner) that requests and uses access to computer system or network resources. Key 31 is a cryptographic key derived using the legitimate entity 5. Key 32 is a cryptographic key derived using device 10.

[0022] Referring now to FIG. 4, embodiments of the present disclosure will be described with respect to FIGS. 1 and 2. After the program starts in step S110, a method for securely executing software on a computerized device accesses device storage. In one embodiment, the method first includes accessing software stored in storage 11 of device 10. The software includes instructions and a message authentication code (MAC), also known as a message integrity code. The MAC corresponds to the instructions and is associated with these instructions within the software. Such a MAC is intended to be used as a reference for verifying the instructions, and thus the MAC is referred to herein as a "reference MAC."

[0023] In step S120, the method loads the accessed instructions and MAC into memory 12 of device 10 for the purpose of verifying and executing the instructions. For that purpose, the instructions (loaded into the main memory) and the corresponding MAC are loaded into the processor registers of CPU 14 of device 10.

[0024] In step S170, the method then executes the instructions in response to verification of the instructions (steps S140 - S160). For example, the instructions are verified before CPU 14 executes them. In this example, hardware module 20 verifies the instructions by performing cryptographic verification operations, as described below.

[0025] In various embodiments of this disclosure, verification is performed on the cryptographic key 32, requiring instructions and reference MACs. In step S140, the method generates the key at runtime using a key derivation function (KDF). In one embodiment, the method generates the cryptographic key 32 using a hardware module 20. In this embodiment, the argument of the KDF may be based on a value obtained from the device 10, for example, a unique identifier (UID) of circuit 21, or a platform configuration register (PCR) of device 10 (e.g., memory circuit 22), or both. In addition, the method extends this value from a measurement of the software content according to a PCR extension mechanism. This extended value is also referred to as the "PCR value" in this description.

[0026] In various embodiments of this disclosure, the KDF takes multiple arguments. However, such a function may be computed in various ways. In particular, the method may combine (e.g., concatenate) the arguments to form a single value used as input by the KDF, as in the embodiments described later.

[0027] This approach relies on a shared secret key between the device owner (e.g., manufacturer, any legitimate entity, etc.) and a verification mechanism implemented in device 10. More precisely, the device owner and device 10 share a recipe (e.g., an encryption recipe) for suitably deriving an encryption key. With respect to this recipe, the method enables device 10 to decrypt such instructions by re-deriving a key 32 used to check the integrity and authenticity of the instructions.

[0028] In various embodiments of this disclosure, the instructions stored in the software are program instructions, i.e., program code. For example, the instructions may be encrypted, as in the embodiments described below. In principle, such instructions may form the interpreter layer, i.e., high-level instructions, i.e., source code written in a high-level language, which are interpreted in real time for a program running during the execution of the method. However, machine code instructions that can be directly interpreted by the CPU14, such as instruction set architecture (ISA) specific code, may offer greater advantages in terms of processing resources. As an example, the method operates in compiled software, which also includes MACs related to binary instructions.

[0029] This MAC should be understood in a broad sense. For example, the MAC may be a keyed hash obtained from an instruction using key 32. In addition, the MAC may be obtained using a cryptographic hash function together with key 32, similar to a hash-based message authentication code (HMAC). In a more sophisticated approach, the MAC may be computed to guarantee the overall integrity of the instruction, including the order of instructions. For this purpose, the MAC values ​​may be interdependent. For example, control flow integrity may be achieved by calculating the MAC of the next instruction using the MAC of the previous instruction, as in the embodiment discussed below. Such an approach may be used to guarantee the order in which instructions are executed.

[0030] In one embodiment, the encryption key 32 may be used, in particular, for device 10 to explicitly calculate a verification MAC, which the method later compares with a reference MAC. In an alternative embodiment, the calculation of the verification MAC and the comparison with the reference MAC may be merely implicit, depending on the verification mechanism used. For example, as in the embodiment discussed below, when an authenticated encryption with associated data (AEAD) algorithm is used, the instruction may be encrypted, and the software may optionally include additional data. When using the AEAD scheme, decryption of the instruction utilizes the instruction, the reference MAC, and the additional data. In this case, the authenticity and integrity of the instruction are guaranteed by the AEAD decryption mechanism.

[0031] In one embodiment, the method, in all cases, uses a reference MAC to check (and potentially decode) the completeness and authenticity of instructions at runtime. PCR values, according to an extended mechanism, ensure the integrity of the software after booting.

[0032] In one embodiment, the UID used with the PCR value to derive key 32 is preferably a unique identifier of the CPU 14 of device 10. In this embodiment, it is more preferable that the UID reflects the physically hard-to-replicate function (PUF) of the CPU 14. Thus, by relying on the UID, the method can associate software integrity (by PCR value) with hardware in order to derive the key. In one embodiment, a device owner who has access to the UID to initially obtain MACs and store them in the software along with instructions may derive a first key 31 using the same KDF as device 10 before storing the software in device 10, i.e., at build time. In contrast, the second key 32 is derived by device 10 at runtime. For example, the two keys 31 and 32 are not the same because they are generated by two different devices 5 and 10 at two different points in time, respectively. However, the two keys must have identical values ​​so that the instructions can be executed. Otherwise, according to the proposed method, software execution will be interrupted.

[0033] All of this will now be described in detail with respect to specific embodiments of the present disclosure. In various embodiments of the present disclosure, the method performs the cryptographic verification operations of S140-S160 by explicitly calculating a verification MAC in device 10 to verify the instruction.

[0034] In one embodiment, the method uses a hardware module 20 to verify the MAC. For example, the method recalculates the verification MAC corresponding to each instruction in device 10 (at runtime) and performs verification using the verification MAC. In this example, the method may perform the verification operation using an encryption key 32. For example, the method calculates both the reference MAC and the verification MAC as HMACs. In this example, the method performs verification by comparing the verification MAC with the reference MAC. For this purpose, the method may load the reference MAC into a CPU register (e.g., memory circuit 22), similar to the instructions. For example, in order for the method to perform verification in the CPU pipeline, each instruction and its corresponding reference MAC may be loaded into main memory (e.g., memory 12), and then from main memory into a CPU register.

[0035] In an alternative example, the method verifies all instructions simultaneously, i.e., as a whole, before executing them. However, with respect to processing resources, it is advantageous to verify the instructions sequentially and execute them according to the verification. In step S160, the method verifies the instructions. In one embodiment, the method uses the hardware module 20 to decide whether or not to execute the instructions in memory 12. For example, the method processes the instructions sequentially, so that each instruction is first verified and then executed unless the verification fails. In one scenario, if the method determines that the key value corresponding to the instruction does not match the key value of the hardware module 20, i.e., the verification fails (step S160: no), the method interrupts the execution of the software instructions, i.e., S180. The method interrupts software execution as soon as any of the verifications fail. By sequentially validating instructions, the CPU can directly validate each instruction and then execute it on the fly, without the need for further interaction with main memory or memory cache, for example, without storing validated instructions (outside of CPU registers) and calling them for execution. In other words, as shown in Figure 7, each instruction can be processed sequentially in the CPU pipeline.

[0036] The method may include a series of preliminary steps in which a reference MAC and any data necessary for a later verification step are calculated. Referring to Figure 3, in step S10, the method derives a key. In one embodiment, the method derives a key 31 using a canonical entity 5. For example, canonical entity 5 generates an initial cryptographic key using the same KDF that will later be used by device 10. In step S20, the method calculates a MAC. In one embodiment, the method calculates a reference MAC using canonical entity 5. For example, canonical entity 5 (e.g., device owner or manufacturer) may calculate a reference MAC based on the initial cryptographic key derived in step S10. In step S30, the method stores the instruction in software along with the MAC. In one embodiment, the method uses canonical entity 5 to store the calculated reference MAC in the storage 11 of device 10 along with the software instruction. For example, the reference MAC is stored in the software along with the instruction before the instruction and reference MAC are stored in the computerized device. In this example, each reference MAC corresponds to a software instruction before the software is loaded into the computerized device's memory. In step S40, the method loads the software into the computerized device. In one embodiment, the method stores the calculated reference MAC along with the software instructions in the memory 12 of the device 10. If the instructions are encrypted using, for example, the AEAD scheme, in addition to the calculated reference MAC and instructions, the software may optionally include a nonce and additional data for decrypting and verifying the instructions.

[0037] In various embodiments of this disclosure, the reference MAC may incorporate an interdependence scheme to further ensure the integrity of the order in which instructions are executed, as assumed in the diagram of Figure 6. That is, the method may first compute the reference MAC by performing a cryptographic encoding operation based on the instructions and KDF according to this interdependence scheme.

[0038] For example, this interdependence scheme may be designed such that each of the reference MACs, except for the first MAC, depends on a previous reference MAC (or information derived therefrom). By using the MAC of the previous instruction to calculate the MAC of the next instruction, the method can protect control flow integrity. The calculation of the very first MAC may use any suitable initial value. In that case, the software further includes interdependence data that reflects this interdependence scheme. At runtime, the method may load the interdependence data (in addition to the instruction and reference MACs) into the memory 12 of device 10 so that the verification performed in steps S140 to S160 correctly applies the interdependence scheme.

[0039] In various embodiments of this disclosure, more sophisticated interdependence schemes may be deployed. For example, the method may utilize a hierarchical scheme in which each MAC, excluding the first n MACs, is computed with respect to information contained in or derived from the n previous MACs. Cryptographic verification operations may be performed in accordance with this. For example, the method may compute a verification MAC at runtime based on previously obtained MACs if at least the explicit computation of MACs is required. Furthermore, explicitly computing a verification MAC may be useful when the instructions stored in the software are not encrypted. However, this is not necessarily required, especially if further encryption / decryption operations are required to encrypt and decrypt the instructions. In that case, the interdependence may be suitably incorporated as rules encoded by additional data AD and nonce N, as assumed in the diagram of Figure 6. The method may compute the additional data AD in accordance with nonce N between the pre-steps S18-S19, i.e., before step S20, which computes the reference MAC. See also Figure 3.

[0040] In this embodiment, the instruction is encrypted according to an encryption algorithm using the KDF defined above. In Figure 6, the reference codes "P" and "C" represent the unencrypted instruction and the encrypted instruction, respectively (P and C represent "plaintext" and "ciphertext," respectively). This encryption algorithm may trigger the execution of the encryption encoding operation described above. Then, at runtime, the instruction can be verified simply by decrypting the encrypted instruction, as shown in Figure 6. For this purpose, the decryption algorithm used must be designed to be consistent with the encryption algorithm used to encrypt the instruction. Decryption is performed on the encryption key 32, using the reference MAC and the instruction as input.

[0041] Various encryption algorithms may be used, such as post-encryption MAC or post-MAC encryption algorithms. However, in a preferred embodiment, the encryption and decryption algorithms rely on the AEAD scheme, as will be described in detail with respect to Figure 6. In this context, the AEAD algorithm provides higher security than post-encryption MAC or post-MAC encryption algorithms.

[0042] As shown in Figure 6, for each plaintext instruction P, the AEAD encryption algorithm first generates the corresponding encryption instruction C and the corresponding reference MAC in S20 (e.g., calculating the MAC). The AEAD encryption algorithm uses additional data AD and nonce N to suitably encrypt the instruction and generate the MAC. As seen in Figure 6, the additional data AD and nonce N are passed from the encrypting side to the decrypting side. In this exemplary embodiment, the method embeds the data in software. As a result, the software may include the additional data AD and nonce N in addition to the encryption instruction and reference MAC.

[0043] More specifically, the method, as shown in Figure 6, generates matching additional data AD and nonce N in steps S18-S19 in order to calculate the MAC from the plaintext instruction P (e.g., step S20) using the key 31 derived in step S10 during the build process. The entity that encrypts the software is usually the entity that also selects the nonce and generates the additional data AD. The nonce may be chosen arbitrarily, however, it should be unique for each instruction and each encryption key. For a given key, the nonce may be, for example, a natural number that increases from 1 up to the number of instructions.

[0044] In one embodiment, the method obtains a reference MAC and an encryption instruction C from the output of the encryption algorithm (e.g., S20 in Figure 6). The method passes the additional data AD, nonce N, and encryption instruction C to the decryption algorithm. According to the AEAD scheme, the decryption algorithm can only decrypt correctly if it uses the same nonce used during encryption. Therefore, in the decryption process, the method decrypts instruction C using the methodology of step S150, the key 32 derived in step S140 at runtime (see Figure 4), as well as the additional data AD and nonce N. The AEAD decryption process makes it possible to verify the integrity and authenticity of the instruction while decrypting instruction C.

[0045] In various embodiments of this disclosure, it is preferable that the instructions C be decrypted one by one for improved security. To this end, the method loads additional data AD and nonce into memory 12 (i.e., instruction C and reference MAC). The method then loads each instruction into a processor register, along with the corresponding nonce and additional data necessary for the decryption algorithm to suitably decrypt and verify the encrypted instruction C, as part of a CPU pipeline, for example, as shown in Figure 7. In an alternative embodiment, the method may decrypt all instructions C simultaneously at the beginning. In this case, the decrypted instructions P would typically need to be stored in plaintext in the CPU cache, which means that in addition to additional data exchange between the CPU core and cache memory, a broader vector of attacks would occur. Indeed, such an approach is more vulnerable to attacks targeting data stored in the cache. Therefore, in one embodiment, the method decrypts the instructions sequentially, so that all necessary operations are performed locally by the CPU core without any decrypted instructions needing to be stored in the cache.

[0046] As mentioned above, the cryptographic keys 31 and 32 are derived from the PCR value and UID, either at build time or runtime. Nevertheless, for reasons that will become clear later, additional data such as monotonic counter values ​​may be used to derive keys 31 and 32. In all cases, a unique key may be available for each computerized device 10 and each piece of software running on device 10.

[0047] In one embodiment, the method appropriately selects a nonce to ensure control flow integrity. In the AEAD approach, the nonce for the current instruction can be obtained using the MAC (e.g., value) of the previous instruction. During operation, the MAC of the previous instruction is temporarily stored internally (or in the cache) of the CPU. The CPU uses this value to calculate the nonce for the current instruction. That is, the next instruction the CPU executes must first be decrypted and verified. Once the CPU has calculated the nonce for the current instruction, it attempts to decrypt the current instruction. The nonce may be calculated in several ways. For example, the nonce may be calculated using the instruction's address, resulting in a unique nonce for each instruction. Another example is deriving the nonces and storing them in associated data adjacent to the encryption instruction.

[0048] In various embodiments of this disclosure, the arguments of the KDF may be based on both the UID and PCR value of device 10, meaning that the arguments must be obtained from the UID and PCR value in some way. For example, in an embodiment, such an argument includes the PCR value and the output of an intermediate function f(.) of the UID, i.e., f(UID). The two values ​​(i.e., the PCR value and the output) may then be concatenated to form a single argument that is taken as input by the KDF. In this scenario, the KDF can be considered as a function with a single argument. For example, the cryptographic key 32 may be obtained, for example, as follows: Encryption key = KDF(f(UID)||PCR value)

[0049] The intermediate function can be any suitable function, such as a hash function. It can also be the identity function, in which case it is as follows: Encryption key = KDF (UID || PCR value)

[0050] The intermediate function may be the KDF itself if it is considered a single-argument function. For example, key 32 may be obtained as follows: Encryption key = KDF (KDF(UID)||PCR value)

[0051] In further embodiments of this disclosure, the arguments of the KDF further include the current value of a monotonic counter MC, as assumed in Figures 2 and 7. The function of the monotonic counter MC is to capture the current version of the software stored in device 10. That is, the monotonic counter MC is set (e.g., by the CPU or its dedicated circuitry) to monotonically increase with software updates. As a result, any software update causes an increase in this counter, which affects the derived keys 31, 32, whether at build time or runtime. Consequently, as will be discussed in detail later, the regular entity 5 can track and verify the current software version running on device 10.

[0052] For example, if the method uses a monotonic counter value in addition to the UID and PCR value, the arguments of the KDF may include the PCR value, the output of the intermediate function f(.) of the UID, and the current value of the monotonic counter MC. In this example, key 32 may be obtained as follows. Encryption key = KDF(f(UID)||PCR value||MC), or Encryption key = KDF(f(UID||MC)||PCR value)

[0053] In another example, the method calculates key 32 as follows: Encryption key = KDF(KDF(UID||MC)||PCR value)

[0054] Figure 5 shows a flowchart illustrating how a legitimate entity verifies the current version of software running on device 10 using the current counter value MC. In various embodiments of this disclosure, such verification relies on a PCR value, a monotonic counter value MC, and a nonce. In step S210, the method sends a request to the computerized device along with the nonce. In one embodiment, the method uses a legitimate entity 5 to send a request including the nonce to device 10. For example, the nonce is sent to device 10 by the legitimate entity 5 in S210. In step S220, the computerized device receives the request from the verification device. In one embodiment, the method receives confirmation that the request sent by the legitimate entity 5 has been received by device 10. In step S230, the computerized device signs a quote including the nonce. In one embodiment, device 10 signs a quote of the request from the legitimate entity 5. For example, the computerized device (e.g., device 10) digitally signs the quote including the nonce using a key 32 derived, for example, in step S140 of Figure 4. In step S240, the computerized device sends a signed quote. In one embodiment, device 10 sends the signed quote to canonical entity 5. For example, the computerized device (e.g., device 10) sends a digitally signed quote to the verification device (e.g., canonical entity 5). In step S250, the method receives the signed quote. In one embodiment, canonical entity 5 receives the signed quote from device 10. For example, the verification device (e.g., canonical entity 5) receives the digitally signed quote from the computerized device (e.g., device 10).

[0055] In step S260, the method verifies the signature and extracts the nonce. In one embodiment, the method uses the canonical entity 5 to verify the signed quote of device 10. For example, the method verifies the signature of the quote provided by the computerized device and extracts the nonce of the quote. In step S270, the method compares the nonce to an expected value. In one embodiment, the method compares the nonce of the signed quote of device 10 to the value of the canonical entity 5. For example, the method compares the extracted nonce of the quote to an expected value, i.e., the nonce value initially used in step S210. Only the correct key 32 (i.e., derived based on the correct parameters, see Figure 2) can prove the correct version of the software running on device 10. This nonce is used to prevent replay attacks and should be distinguished from the nonce value used in the AEAD scheme described above. Figure 5 is described in detail below. In various embodiments of this disclosure, the quote may be encrypted using key 32 (rather than being signed) in step S230 and then decrypted using key 31 (rather than being verified) in step S260. Encryption / decryption of the quote may be used when confidentiality is a concern.

[0056] In various embodiments of this disclosure, the method may obtain a UID, which is an identifier, from the physically hard-to-replicate function (PUF) of device 10. In addition, the PUF may be the physically hard-to-replicate function of the CPU 14 of device 10, as illustrated in Figure 1. As an example, the method may obtain the UID from circuit 21 of the CPU 14 of device 10 before generating the cryptographic key 32. For example, the CPU 14 may include circuit 21 configured to measure the properties of the device (or actually the CPU) and generate a digital fingerprint (e.g., a UID) accordingly. The method uses the obtained UID to derive the key 32. In addition, those skilled in the art will recognize that circuit 21 is designed to prevent anyone with physical access to circuit 21 (i.e., via a debug port) from learning the UID. Thus, the output of circuit 21 is accessible only by a KDF circuit.

[0057] For example, as shown in Figure 1, circuit 21 may form part of a hardware module 20 that can be designed to perform all sensitive operations, including verification steps S130-S180 in Figure 4. Various examples of circuits that enable the derivation of a digital fingerprint from the physical properties of a device are known in the prior art, particularly in the field of hardware security modules (HSMs).

[0058] The CPU 14 of device 10 may have additional special features. For example, the CPU 14 may include a memory circuit 22 which may be dedicated and of fixed size. The memory circuit 22 may form part of the hardware module 20, as shown in Figure 1. In one example, the memory circuit 22 may have a fixed size and is used to implement platform configuration registers. Furthermore, the method may further include measuring the software content as soon as device 10 is booted and expanding the values ​​according to the expansion mechanism described above to obtain PCR values.

[0059] Various embodiments of the present disclosure relating to device 10 will now be described in detail with reference to Figures 1, 2, and 7. The main features of device 10 have already been described with respect to this method, either implicitly or otherwise. Therefore, such features will be described briefly below. In general, device 10 securely executes software based on MACs. Device 10 may include storage 11 in which the software is stored by the steps described above with respect to Figure 3, i.e., the software includes a given instruction and its respective reference MAC. Device 10 further includes processing means, such as a CPU 14, which may include platform configuration registers for performing the operations described above with respect to Figure 4. In addition, device 10 includes memory 12 intended to function as the main memory of device 10 during operation.

[0060] In one embodiment, device 10 performs the steps according to the method, i.e., executes instructions in accordance with their verification. In this embodiment, the instructions and reference MACs are typically loaded into the memory 12 of device 10 before verification. As previously stated, the verification performed requires the instructions and reference MACs in memory 12, as well as a cryptographic key 32 generated at runtime. In this embodiment, device 10 generates the key 32 according to a KDF, the arguments of which are based on the UID and PCR value of device 10. For example, device 10 obtains the PCR value from a measurement of the software content according to an extension mechanism implemented by the platform configuration registers of the CPU 14 (e.g., memory circuit 22).

[0061] In one embodiment, device 10 sets a monotonic counter MC such that, during operation, the monotonic counter increases monotonically with software updates. In this embodiment, the argument of KDF may include the current value of the monotonic counter. As discussed above, the UID correlates to the PUF of device 10, or in particular to the PUF of CPU 14. In this embodiment, the CPU 14 of device 10 may include a dedicated circuit 21 that outputs the UID during operation. In addition, the CPU 14 may include a dedicated fixed-size memory circuit 22 that implements a PCR, which provides a PCR value used to derive the key 32 during operation. For example, the PCR, monotonic counter MC, and PUF may be considered to be implemented as part of the physical layer, while the values ​​derived from them (i.e., the PCR value, counter value, and UID) may be considered to operate in the execution layer above this physical layer.

[0062] In one embodiment, as shown in Figure 1, the CPU 14 may include a dedicated hardware module 20 that performs the confidential operations of steps S130 to S180 in Figure 4. The hardware module 20 may also include circuits 21 and 22.

[0063] In another embodiment, the method may be embodied as a computer program product. The computer program product comprises a computer-readable storage medium embodying program instructions. Such program instructions may, in particular, be loaded into the CPU 14 of device 10 as described above. These program instructions are executable by the CPU 14 such that device 10 performs the steps relating to the method, for example, by loading a given instruction and reference MAC into the main memory (e.g., memory 12) of device 10, executing the given instruction according to its verification, thereby performing the cryptographic verification operation described above, and thus ensuring that the instruction is verified before execution. Further considerations relating to this computer program product are presented below.

[0064] The embodiments described above are briefly explained with reference to the attached drawings and may include numerous modifications. Several combinations of the above features are conceivable.

[0065] The following describes exemplary embodiments that rely on CPU extensions to ensure that a highly reliable security device runs only authorized software. Such embodiments assume a model of a powerful threat. For example, an adversary with physical access to the device may tamper with the memory contents. Alternatively, the adversary may exploit memory corruption vulnerabilities in the software running on the device. To mitigate these threats, various embodiments of this disclosure propose solutions that operate at the instruction-level granularity to ensure that fetched instructions are authorized to run on a given CPU, form part of the loaded software, and conform to the control flow integrity of the software.

[0066] In one embodiment of this disclosure, software and hardware are associated. For example, the CPU may include a CPU core, access a unique device number (UID), implement a key derivation function, and operate a verification module. The UID is unique for each CPU and is typically known only to the hardware owner. The key derivation function is a cryptographic algorithm that generates an encryption key 32 from the UID, the PCR value discussed above, or other software-specific data or a combination thereof.

[0067] In this example, the hardware module 20 is part of the CPU core and operates between the "fetch" and "execute" phases in the CPU pipeline shown in Figure 7. The hardware module 20 uses the cryptographic key 32 to decode / verify each instruction before execution.

[0068] In this example, the binary is modifiable by the hardware owner. Each software instruction is extended to include additional data that allows the hardware module 20 to validate the instruction.

[0069] In one embodiment, the CPU checks the authenticity and integrity of instructions but does not ensure their confidentiality. In this embodiment, a reference MAC is initially calculated for each instruction using the encryption key 31. See Figure 3. In the binary, each instruction occupies more space than the original instruction to include the reference MAC. Confidentiality can be added by initially encrypting each instruction using the AEAD encryption scheme. In this scenario, software integrity is calculated for a portion of the associated data that stores the fingerprint of the instruction.

[0070] Various embodiments of this disclosure enable software version updates without hindering this approach. As a result, software updates become secure against rollback attacks. In one embodiment, the CPU tracks the software version using a monotonic counter. For example, the monotonic counter is hardcoded. In this example, the monotonic counter is embedded as a non-volatile register that stores a number. This number can only be increased according to monotonicity, and when a software update is installed, the monotonic counter is increased, for example by a dedicated CPU instruction that increments the monotonic counter. In such cases, the CPU uses a cryptographic key generated by a key derivation function that takes the monotonic counter into account, as described above.

[0071] In one embodiment, in addition to the execution order to be implemented, secure boot may be implemented. For this purpose, the hardware may embed a platform configuration register (PCR). The PCR may be considered a fixed-size register that stores an integrity measurement. Such an integrity measurement is typically obtained in the output of a cryptographic hash function on software content (e.g., binary). The PCR is reset to a suitable initial value when the CPU is reset (e.g., upon reboot). The PCR cannot be directly written to, but can only be extended. For example, the value of the PCR may be replaced by the output of a cryptographic hash function with the current PCR value and a new value as arguments. In this example, the PCR value changes when new firmware / software is loaded into memory. As a result, a new cryptographic key is generated by a key derivation function. Furthermore, the newly loaded software is only executable if it is signed / encrypted with a key derived from a PCR value that reflects the boot order and integrity of the boot software.

[0072] Various embodiments of this disclosure enable the acquisition of an attestation. The purpose of this is for the hardware owner (or any other legitimate entity) to verify that the device is running the latest version of the software.

[0073] Referring here to Figures 3 and 6, in an exemplary embodiment, the hardware owner derives the key 31 based on the correct values ​​of the PCR value, UID, and monotonic counter MC, as shown in Figure 3, S10. The hardware owner's device then calculates the reference MAC, S20, taking into account the instructions that constitute the target software. In this example, it may be necessary to first calculate the additional data (AD) and nonce values, S18-S19, as shown in Figure 6. The hardware owner's device also places the instructions and reference MAC, along with the additional data and nonce, into the software, S30, if necessary. In this example, the software is stored in device 10, S40, and device 10 is ready to securely execute the software, as described in the flow of Figure 4.

[0074] Referring here to Figures 4 and 6, various embodiments of the present disclosure secure execution on a device. In an exemplary embodiment, when the software is executed on device 10, device 10 accesses the software (which is initially stored in the storage 11 of device 10) S110 and loads the instruction (which may be encrypted), the reference MAC, and any other desired data such as additional data AD and nonce value N into memory 12 S120. In this exemplary embodiment, device 10 processes instructions sequentially for verification and execution. The process terminates when the last instruction has been processed (S130: yes). Each time device 10 selects a new instruction S135, device 10 verifies the new instruction S150 using the key 32 derived in step S140, as described above. Verification S150 relies on the reference MAC and other data (AD, N) if necessary. In one scenario, if device 10 verifies the current instruction (step S160: yes), device 10 executes the instruction S170. In another scenario, if device 10 does not validate the current instruction (step S160: no), device 10 suspends software execution S180.

[0075] In an alternative exemplary embodiment, if device 10 utilizes the AEAD scheme, verification S150 proceeds as shown in Figure 6. For example, device 10 uses the encryption instruction C, additional data AD, and nonce value N to decrypt the instruction using the key 32 derived in step S140. In this example, device 10 utilizes the AEAD scheme not only for decryption but also to prove the integrity and authenticity of each instruction.

[0076] Referring here to Figure 5, various embodiments of the present disclosure provide attestation methodologies that include a set of steps for verifying the current version of the software. In one embodiment, a verification entity uses a canonical entity 5 to assemble a request including a nonce and sends the request to a device 10 (step S210). The device 10 receives the request in step S220. Next, in step S230, the device 10 signs the quote including the nonce using a cryptographic key 32. The key 32 may have been derived in advance, for example in step S140 of Figure 4, and stored in the device 10 (possibly in a wrapped form). In one scenario, if the key has not been derived in advance, the key should be re-derived using the same KDF described above. In step S240, the device 10 sends the signed quote to the canonical entity 5. In step S250, the canonical entity 5 receives the signed quote and verifies the signed quote in step S260 using a key 31 derived using the same KDF. In this embodiment, the canonical entity 5 may derive the key 31 using the data of the software instruction, as it did initially to store the instruction in the software (see step S30 in Figure 3). In step S270, the canonical entity 5 may extract the nonce contained in the signed quote and compare the nonce with the corresponding expected value. As a result, the canonical entity 5 can verify the current version of the software running on device 10.

[0077] The above scheme utilizes keys 31 and 32 derived at least partially based on the UID and PCR value. In various embodiments of this disclosure, the quote may be encrypted by device 10 in step S230 and then decrypted by canonical entity 5 in step S260. In addition, device 10 and canonical entity 5 may rely on a different cryptographic key (i.e., separate from keys 31 and 32) to sign / encrypt and then verify / decrypt the quote. For example, the key may be derived from the expected / current monotonic counter value. However, this method can provide improved security by associating the key with the UID and PCR value as well, and thus offer advantages over relying on keys 31 and 32. In another example, canonical entity 5 first forms a request based on the PCR value, the expected monotonic counter value, or the UID or a combination thereof, in addition to the nonce. As a result, it can sign / encrypt and then verify / decrypt the quote using any suitable cryptographic key shared by device 10 and canonical entity 5.

[0078] Referring to Figure 7, in one embodiment, the CPU sequentially fetches instructions from an instruction bus, which may be stored in a cache (e.g., an instruction cache), including MAC, additional data, and any other necessary data such as a nonce. The cache is considered to be closer to the CPU but forms part of the main memory. In this embodiment, the CPU sequentially loads each instruction into the CPU pipeline along with any other necessary data and verifies the instruction (e.g., verifies AEAD) using an AEAD scheme with a key derived from the PCR value, UID, and current monotonic counter value, as described above. As AEAD decoding progresses, the CPU decodes each instruction into a format that the CPU can execute (e.g., execute). The decoding step is separate from the AEAD decoding and verification process, which decodes the instruction and verifies its integrity and authenticity. In addition, the CPU writes all results at the same stage of the pipeline (e.g., memory access, memory, etc.). The results of such execution may be passed to a data cache (e.g., a data cache) and then to a data bus (e.g., a data bus). Furthermore, once an instruction is executed and its result is calculated, the CPU uses a commit unit to determine when it is safe to store the result (e.g., commit it).

[0079] Depending on the CPU design, the pipeline may include more or fewer stages, or, for example, several stages may be combined. However, in the context of Figure 7, it is essential that instructions are validated after fetching and before execution.

[0080] The present invention may be a system, method, or computer program product or combination thereof at any possible level of technical detail integration. The present invention may be beneficially implemented in any single or parallel system that processes instruction streams. The computer program product may include a computer-readable storage medium (or more mediums) having computer-readable program instructions for causing a processor to perform an aspect of the present invention.

[0081] The present invention may be a method, device, or computer program product or combination thereof. The computer program product may include a computer-readable storage medium (or a set of mediums) having computer-readable program instructions for causing a processor to perform an aspect of the present invention.

[0082] A computer-readable storage medium can be a tangible device capable of holding and storing instructions for use by an instruction execution device. A computer-readable storage medium may be, but is not limited to, electronic storage devices, magnetic storage devices, optical storage devices, electromagnetic storage devices, semiconductor storage devices, or any preferred combination thereof. A non-exhaustive list of more specific examples of computer-readable storage media includes, namely, portable computer diskettes, hard disks, random-access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random-access memory (SRAM), portable compact disk read-only memory (CD-ROM), digital versatile disk (DVD), memory sticks, floppy disks, mechanical encoding devices such as punch cards or grooved-reinforced structures on which instructions are recorded, and any preferred combination thereof. As used herein, computer-readable storage media should not be interpreted as being transient signals in themselves, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through waveguides or other transmission media (e.g., light pulses passing through optical fiber cables), or electrical signals transmitted through wires.

[0083] The computer-readable program instructions described herein may be downloaded from a computer-readable storage medium to each computing / processing device, or to an external computer or external storage device via a network, such as the Internet, a local area network, a wide area network, or a wireless network, or a combination thereof. The network may include copper transmission cables, optical transmission fibers, wireless transmissions, routers, firewalls, switches, gateway computers, or edge servers, or a combination thereof. A network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and transfers the computer-readable program instructions for storage in a computer-readable storage medium within each computing / processing device.

[0084] The computer-readable program instructions for realizing the operation of the present invention may be assembler instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, configuration data for integrated circuits, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Smalltalk(R) and C++, and procedural programming languages ​​such as the C programming language or similar programming languages. The computer-readable program instructions may be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer via any type of network, including a local area network (LAN) or wide area network (WAN), or it may be connected to an external computer (for example, via the Internet using an Internet service provider). In some embodiments, an electronic circuit including, for example, a programmable logic circuit, a field-programmable gate array (FPGA), or a programmable logic array (PLA) may execute a computer-readable program instruction by personalizing the electronic circuit using state information of the computer-readable program instruction in order to perform an aspect of the present invention.

[0085] Aspects of the present invention are described herein with respect to flowcharts or block diagrams, or both, of methods, systems, and computer program products according to embodiments of the present invention. It should be understood that each block in a flowchart or block diagram, or both, and any combination of blocks in a flowchart or block diagram, or both, can be implemented by computer-readable program instructions.

[0086] These computer-readable program instructions may be provided to a general-purpose computer, a dedicated computer, or a processor of another programmable data processing device to generate a machine, such that instructions executed via the processor of a computer or other programmable data processing device form means for performing functions / operations specified in one or more blocks of a flowchart or block diagram, or both. These computer-readable program instructions may be stored in a computer-readable storage medium that can instruct a computer, a programmable data processing device, or other device or combination thereof to function in a particular manner, such that the computer-readable storage medium storing the instructions comprises a product containing instructions that perform the modes of functions / operations specified in one or more blocks of a flowchart or diagram, or both.

[0087] Computer-readable program instructions may generate a computer-executed process by loading instructions that are executed on a computer, other programmable device, or other device into a computer, other programmable data processing device, or other device, so as to perform a series of operational steps on the computer, other programmable device, or other device, in order to perform a function / operation specified in one or more blocks of a flowchart or block diagram, or both.

[0088] The flowcharts and block diagrams in the drawings illustrate the architecture, functionality, and operation of possible embodiments of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of instructions containing one or more executable instructions for performing a specified logical function. In some alternative embodiments, the functions described in a block may be performed in an order other than that shown in the drawings. For example, two blocks shown consecutively may actually be executed substantially simultaneously, or they may be executed in reverse order depending on the functions they relate to. It should also be noted that each block in a block diagram or flowchart, or both, and combinations of blocks in a block diagram or flowchart, or both, may be implemented by a dedicated hardware-based system that performs a specified function or operation or realizes a combination of dedicated hardware and computer instructions.

[0089] While the present invention has been described with respect to a limited number of embodiments, modifications, and accompanying drawings, it will be understood by those skilled in the art that various modifications are possible and equivalents may be substituted without departing from the scope of the invention. In particular, features (such as devices or methods) referenced in or shown in the drawings of a given embodiment or modification may be combined with or replaced by other features in another embodiment, modification, or drawing, without departing from the scope of the invention. Thus, various combinations of features described with respect to any of the above embodiments or modifications may be envisioned that fall within the scope of the appended claims. In addition, numerous minor modifications may be made to adapt the teachings of the invention to specific situations or materials, without departing from the scope of the invention. Thus, the invention is not limited to the specific embodiments disclosed, and the invention is intended to include all embodiments that fall within the scope of the appended claims. In addition, numerous modifications other than those explicitly mentioned above may be envisioned. For example, other CPU pipelines may be designed, and the key derivation function may use additional data in addition to the PCR value, UID, and monotonic counter value.

[0090] The terms “one embodiment,” “one embodiment,” and “exemplary embodiment” used herein indicate that the embodiments described may include certain features, structures, or characteristics, but not all embodiments necessarily include such features, structures, or characteristics. Furthermore, such terms do not necessarily refer to the same embodiment. In addition, if certain features, structures, or characteristics are described in relation to one embodiment, it is presented that any influence on such features, structures, or characteristics in relation to other embodiments, whether explicitly described or not, is within the knowledge of those skilled in the art.

[0091] The terms used herein are for the sole purpose of describing specific embodiments and are not intended to limit the invention. Where used herein, the singular forms “one” and “it” are intended to include the plural form unless the context explicitly indicates otherwise. Furthermore, where used herein, the term “equipped with” indicates the presence of a described feature, integer, step, operation, element, or component, or a combination thereof, but it should be understood that this does not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, or groups thereof or combinations thereof.

[0092] "Software" may be considered a set of basic blocks having a known correct control flow, which can be derived during compilation in the form of a control flow graph or by symbolic execution. Each basic block is a list of instructions to be executed sequentially, ending with a branch instruction.

[0093] "Hardware" is an electronic device 10 that includes at least a CPU and memory (read-only memory or dynamic memory).

[0094] A "hardware owner" is an entity that owns the hardware or has legitimate access to the hardware.

[0095] A "binary" is the source code after it has been converted to an architecture-specific (ISA-specific) format, i.e., after the compilation and linking processes. It consists of instructions and their respective memory addresses.

Claims

1. A computer implementation method for securely executing software instructions on a computerized device, Accessing the software of the computerized device, wherein the software includes a plurality of instructions and their respective reference message authentication codes (MACs), Generating an encryption key based at least in part on a key derivation function, wherein the arguments of the key derivation function are at least in part on a unique identifier of the computerized device, a value extended from a measurement of the software content of the platform configuration register extension mechanism of the computerized device, and the current value of a monotonically increasing monotonic counter with software updates. The process involves verifying one of the instructions in the software based at least partially on the encryption key and the reference MAC of each of the reference MACs, In response to verifying the instruction among the plurality of instructions of the software, the instruction is executed. Methods that include...

2. Verifying the instruction among the plurality of instructions of the software is: Calculating a verification MAC corresponding to the instruction based at least partially on the aforementioned encryption key, Comparing the verification MAC with the reference MAC The method according to claim 1, further comprising:

3. Executing the aforementioned instruction means In response to a failure to validate the instruction among the plurality of instructions of the software, the execution of the instruction of the software is suspended. The method according to claim 1, further comprising:

4. The method according to claim 3, wherein each of the aforementioned reference MACs is a MAC calculated based on an interdependence scheme, the software further includes interdependence data that reflects the interdependence scheme, and the verification of the instruction is based on the interdependence scheme.

5. The plurality of instructions of the software are encoded using the key derivation function, at least partially based on the encryption algorithm, Decoding the plurality of instructions of the software at least in part on a decryption algorithm, wherein the decryption algorithm uses the generated cryptographic key and the reference MAC, and The method according to claim 1, further comprising:

6. The method according to claim 5, wherein the encryption algorithm and the decryption algorithm conform to an authenticated encryption algorithm with associated data, the software further includes additional data used to encrypt the plurality of instructions, and the decryption algorithm uses the additional data to decrypt and verify the plurality of instructions of the software.

7. The method according to claim 1, wherein the argument of the key derivation function includes the value extended from the measurement of the content and the output of an intermediate function for the unique identifier.

8. The method according to claim 1, wherein the argument includes the value extended from the measurement of the content, the output of the intermediate function of the unique identifier, and the current value of the monotonic counter.

9. The current version of the software is verified based on the extended value, the value of the monotonic counter, and the nonce. The method according to claim 1, further comprising:

10. A computer implementation method for securely executing software instructions on a computerized device, Accessing the software of the computerized device, wherein the software includes a plurality of instructions and their respective reference message authentication codes (MACs), Generating an encryption key based at least in part on a key derivation function, wherein the arguments of the key derivation function are at least in part on a unique identifier obtained from a physically hard-to-replicate function of the computerized device and a value extended from a measurement of the software content of the platform configuration register extension mechanism of the computerized device. The process involves verifying one of the instructions in the software based at least partially on the encryption key and the reference MAC of each of the reference MACs, In response to verifying the instruction among the plurality of instructions of the software, the instruction is executed. Methods that include...

11. The method according to claim 10, further comprising obtaining the unique identifier from a dedicated circuit of the processing means of the computerized device, wherein the unique identifier is a unique identifier of the processing means of the computerized device.

12. In response to booting the computerized device, measure the content of the software, To obtain the extended value, the extension is performed by extending the value based on the extension mechanism, wherein the processing means of the computerized device includes a dedicated fixed-size memory for implementing the platform configuration register. The method according to claim 1, further comprising:

13. The method according to claim 1, wherein a module of the processing means of the computerized device performs the verification of the instruction.

14. The reference MAC is calculated based on the initial encryption key derived using the key derivation function, The aforementioned reference MAC is stored in the software along with the plurality of instructions, The software is stored in the computerized device. The method according to claim 1, further comprising:

15. The method according to claim 1, wherein the plurality of instructions included in the accessed software are machine code instructions that can be directly interpreted by the processing means of the computerized device.

16. A computer implementation method for verifying the current version of software on a computerized device, Sending a request to the computerized device to verify the current version of the software on the computerized device, wherein the request includes a nonce, Receiving a signed quote from the computerized device corresponding to the request, wherein the signed quote includes the nonce, at least in part, based on the cryptographic key, The derivation of the cryptographic key is at least partially based on a key derivation function, wherein the arguments of the key derivation function are at least partially based on a unique identifier of the computerized device, a value of a monotonic counter, and a value extended from a measurement of the software content of the expansion mechanism of the platform configuration registers of the computerized device, wherein the monotonic counter is monotonically increasing with software updates. The derived cryptographic key is used to verify the signature of the signed quote, The nonce extracted from the verified quote is compared with the expected value. Methods that further include this.

17. A computing system for securely executing software instructions on a computerized device, One or more computer processors, One or more computer-readable storage devices, Program instructions stored in the one or more computer-readable storage devices for execution by the one or more computer processors and The stored program instructions are provided, A program instruction for accessing the software of the computerized device, wherein the software includes a plurality of instructions and their respective reference message authentication codes (MACs), A program instruction for generating an encryption key based at least in part on a key derivation function, wherein the arguments of the key derivation function are at least in part on a unique identifier of the computerized device, a value extended from a measurement of the software content of an extension mechanism of the platform configuration registers of the computerized device, and the current value of a monotonically increasing monotonic counter with updates to the software, A program instruction for verifying one of the multiple instructions of the software based at least partially on the encryption key and the reference MAC of each of the reference MACs, In response to verifying the instruction among the plurality of instructions of the software, a program instruction for executing the instruction and including, Computing system.

18. A computing system for verifying the current version of software on a computerized device, One or more computer processors, One or more computer-readable storage devices, Program instructions stored in the one or more computer-readable storage devices for execution by the one or more computer processors and The stored program instructions are provided, A program instruction for sending a request to the computerized device for verifying the current version of the software on the computerized device, wherein the request includes a nonce, and the program instruction for sending the request includes a nonce. A program instruction for receiving a signed quote from the computerized device corresponding to the aforementioned request, wherein the signed quote includes the nonce, at least partially based on the cryptographic key, and comprises the program instruction for receiving the quote. A program instruction for deriving the cryptographic key, at least in part, based on a key derivation function, wherein the arguments of the key derivation function are at least in part based on a unique identifier of the computerized device, a value of a monotonic counter, and a value extended from a measurement of the software content of an extension mechanism of the platform configuration registers of the computerized device, wherein the monotonic counter is monotonically increasing with software updates, and the program instruction for derivation, A program instruction for verifying the signature of the signed quote using the derived cryptographic key, A program instruction for comparing the nonce extracted from the verified quote with the expected value, A computing system that includes [this].

Images