DEVICE, METHOD AND NON-TRANSITORIAL MACHINE-READY STORAGE MEDIUM

Abstract

A system is provided that includes interface switching logic, machine-readable instructions, and processing switching logic for executing the machine-readable instructions. The machine-readable instructions include instructions for recording an entry in a virtual integrity register. The entry is based on a measurement of a module. The module is part of a confidential computing environment. The machine-readable instructions also include instructions for loading the module into memory. The confidential computing environment can access this memory. Furthermore, the machine-readable instructions include instructions for recording an entry in a log. The log contains a load history. The entry includes information about the module's loading. Finally, the machine-readable instructions include instructions for recording an entry in an integrity measurement register.The entry is based on the recorded entry in the virtual integrity register.

Description

background

[0001] In the realm of confidential computing environments (CCE), it can be crucial to securely manage and verify the integrity of the hardware and software components within the CCE. Different components may be provided by different vendors, and each component may consist of modules from different vendors. The integrity of these components can be assessed based on component measurements and vendor reference values. However, the resources available for storing these integrity measurements within the CCE may be limited. Therefore, it is desirable to improve the process for demonstrating the integrity of these components and their parts, especially when they originate from different vendors. Brief description of the images

[0002] Some examples of facilities and / or procedures are described below by way of example and with reference to the accompanying illustrations, in which Fig. a block diagram of an example of a facility; Fig. a flowchart of an example of a procedure; Fig. Software components from different suppliers of a CCE are shown; Fig. a flowchart of a static module link is shown; Fig. the creation of artificially combined RIMs shows; Fig. shows an attestation workflow of a CCE 600, which includes a RIM; Fig. demonstrates a workflow of the CCE loading process using a virtual integrity register (vIR); Fig. an example of the transaction integrity of a workload using a vIR shows; and Fig. This demonstrates the hardening of a vIR using a Level 2 virtual machine (L2VM). Detailed description

[0003] Some examples are now described in more detail with reference to the accompanying figures. However, other possible examples are not limited to the features of these extensively described embodiments. Other examples may include modifications of the features as well as equivalents and alternatives to the features. Furthermore, the terminology used here to describe certain examples should not exclude other possible examples.

[0004] Throughout the description of the figures, identical or similar reference symbols refer to identical or similar elements and / or features, which may be implemented identically or in a modified form, while providing the same or a similar function. The thickness of lines, layers, and / or areas in the figures may also be exaggerated for clarity.

[0005] When two elements A and B are combined using "or," this is to be understood as revealing all possible combinations, i.e., only A, only B, and A and B, unless explicitly defined otherwise in a specific case. As an alternative formulation for the same combinations, "at least one of A and B" or "A and / or B" can be used. This applies equally to combinations of more than two elements.

[0006] When a singular form, such as "a," "an," and "the," "a," or "the," is used, and the use of only a single element is neither explicitly nor implicitly defined as mandatory, subsequent examples may also use multiple elements to implement the same function. If a function is subsequently described as being implemented using multiple elements, subsequent examples may implement the same function using a single element or a single processing entity.It is further understood that the terms “include”, “containing”, “encompass” and / or “comprehensive”, when used, describe the presence of the specified features, integers, steps, operations, processes, elements, components and / or a group thereof, but do not exclude the presence or addition of one or more other features, integers, steps, operations, processes, elements, components and / or a group thereof.

[0007] The following description presents specific details; however, examples of the technologies described herein can be implemented without these specific details. Well-known circuits, structures, and techniques have not been shown in detail to avoid complicating the understanding of the present description. "An example," "various examples," "some examples," and the like may include features, structures, or characteristics, but not every example necessarily exhibits those particular features, structures, or characteristics.

[0008] Some examples may exhibit some, all, or none of the features described for other examples. “First,” “second,” “third,” and the like describe a common element and indicate different instances of similar elements being referred to. Such adjectives do not imply that individual elements so described must be present in any given sequence, either temporally or spatially, in any order of precedence or in any other way. “Connected” may indicate that elements are in direct physical or electrical contact with one another, and “coupled” may indicate that elements cooperate or interact, though they may or may not be in direct physical or electrical contact with one another.

[0009] As used herein, the terms “working”, “executing” or “running” relating to software or firmware in respect of a system, device, platform or resource are used interchangeably and can refer to software or firmware stored on one or more computer-readable storage media which the system, device, platform or resource can access, even if software or firmware instructions are not actively executed by the system, device, platform or resource.

[0010] The description may use the expressions “in one example,” “in examples,” “in some examples,” and / or “in several examples,” each of which may refer to one or more of the same or to different examples. Furthermore, the terms “comprehensive,” “including,” “with,” and the like, as used in relation to examples in this disclosure, are synonymous.

[0011] Bootstrap integrity in CCEs can be complicated by their dependencies on the CCE module supply chain, where suppliers may release both hardware / software images that form an execution environment and Product Reference Integrity Manifests (RIMs) that can be consumed by attestation verifiers. If the supply chain, due to limitations in integrity registers and thus the restriction on the number of dynamically loaded images a CCE can support, requires static linking of disparate images, RIM files containing artificial suppliers must be artificially generated. This can confuse attestation verifiers who expect RIM files to originate from their correct supplier (as this is a pattern for a potential supply chain attack). Furthermore, architecture-specific metrics—both integrity registers (IRs) and hash algorithms—can be architecture-specific.Therefore, even the same software may exhibit different measurements in different CCEs. For example, the same Linux kernel on an Intel® TDX architecture might be measured against an RTMR1 integrity register, while on Secure Encrypted Virtualization (SEV) technology and a virtual Trusted Platform Module (vTPM), it might be measured against a PCR4 integrity register, each potentially using different hash algorithms. This can complicate the development of portable applications and the provision of RIMs for attestation verifiers. Furthermore, if multiple software modules can be loaded into the same CCE, extracting measurements of individual modules from the aggregated measurement and comparing them to RIMs can be challenging.

[0012] A CCE architecture can comprise multiple software components that can be protected by a (hardware) isolation environment (such as Intel® SGX, Intel® TDX, Intel® VTX, or other container isolation technology). A container image can comprise multiple software components (see Fig. below), some of which may be statically linked. A CCE (such as Intel® TDX Trusted Domains (TD)) can support dynamic loading of CCE images. For example, an initial loader program can load CCE commissioning code into an execution environment (such as a TD container). The commissioning code's measurement can be recorded in an integrity register (such as a Trusted Domain Measurement Register (MRTD)). The commissioning code can load a runtime image by measuring the runtime image and storing its measurement in a first runtime integrity register (such as Runtime Measurement Register 0 (RTMR0)).

[0013] Similarly, the commissioning code can measure a first library in a second runtime integrity register (such as RTMR1) and a second library in a third runtime integrity register (RTMR2). The workload can be loaded by the commissioning code and a measurement stored in a fourth runtime integrity register (such as RTMR3). Because there is a fixed number of runtime integrity registers (for example, four), there is a limit to the number of modules that can be loaded. However, the supply chain that contributed to the loaded images produces more modules than the number of loadable images. For example, supplier A through supplier I might produce software modules that may need to be statically linked in various combinations, which are mapped to available registers (see Fig. Therefore, modules from multiple different vendors are measured and recorded in the same runtime integrity register. This can cause problems when evaluating the measurements and comparing them with the vendors' RIMs. In other words, static join might occur, for example, because there are not enough registers available to process dynamically loaded components individually. This forces the system to join the components into a single executable image at compile time so they fit into the limited number of registers.

[0014] Therefore, suppliers in the supply chain ecosystems can collaborate and form a pipeline of software delivery functions that generate software images composed of other software images (see Fig. (below). This means that modules from different vendors are linked to a single linked module. However, the respective vendors can produce both a software image and a Reference Integrity Manifest (RIM) (also known as a Bill of Materials (BOM)) for their module. This RIM can contain a set of cryptographic digests, initialization settings, or other values ​​that can be used to verify the integrity of a deployed image. For example, an executable image is distributed to customers through a supply chain, and the RIM is published electronically for use by integrity verification services, such as an attestation verifier.

[0015] Therefore, the corresponding RIMs for these linked modules also include values ​​from all linked modules that need to be generated. In other words, an artificial supply chain is required to provide artificially combined RIMs for these statically linked modules. This can lead to suppliers needing to synchronize and coordinate the design of statically linked modules and the creation of combined RIMs. For example, the combined RIM can be signed by a dominant supplier, while the subordinate supplier can remain hidden from downstream consumers of RIMs, such as attestation verifiers.

[0016] In a CCE attestation workflow, the recorded measurement values ​​from modules of a client environment are compared with the RIMs provided by the module supplier (see Fig. As described above, this can present challenges. For example, the measurements collected for the various components in the CCE can reflect a range of component integrations applied as part of supply chain processes or during some CCE loading operations. Loading operations can occur multiple times during the lifecycle CCE or throughout the lifecycle of a workload. Because integrity registers are a fixed resource (e.g., RTMRs), supply chain providers must coordinate the creation of RIMs and statically linked images, which are limited by the number of fixed resources. This can lead to additional costs and friction in the supply chain. Integrity registers can be used to protect the integrity of workload data.For example, a workload might execute transactions in a database, with each transaction acknowledgment resulting in an update to an integrity register. If a workload relies on a single integrity register (e.g., RTMR3 in . Fig. If the system is limited, transaction integrity can either be ignored or layered over the workload integrity measurement using a common integrity register (i.e., RTMR3). However, attestation verifiers must then subtract the overloaded values ​​before they can assess system integrity (see Fig. Similarly, the transaction integrity of a workload can be hindered by overloaded integrity registers, where the component integrity value may need to be subtracted before processing of a transaction log can continue.

[0017] Previous approaches to this challenge could utilize platform configuration registers (PCRs) within a Trusted Platform Module (TPM). In this case, the boot code could measure the PCR against a digest of the loaded code. Some PCRs could be partitioned for specific uses, such as pre-boot, OS boot, VMM / VM use, and application-specific use. PCRs could be locked (i.e., their further use prevented) or left unlocked if other code could extend them for other uses. However, PCRs are only reset on system reset. If a workload uses a PCR for transaction integrity and the system has to undergo a reset cycle, the transaction integrity is lost. Furthermore, if the PCR is used for transaction integrity, system integrity values ​​might need to be subtracted first.If the PCR is required for attestation (system integrity assessment) and is also extended with application-specific content, the application-specific content may need to be subtracted. These limitations can render PCRs unsuitable for a wide range of integrity use cases.

[0018] The technique proposed in this disclosure enables CCEs containing workloads that execute a variety of use cases to employ integrity registers as a per-segment and / or module (e.g., workload-specific) and architecture-independent approach to system- and usage-related integrity. The technique proposed in this disclosure creates and provides a resource-unlimited virtual integrity register (vIR) for any module and / or secure segment (e.g., per subdomain). For example, a commissioning module operating during CCE initialization can be considered a secure segment and / or module (e.g., a subdomain).A CCE runtime environment that responds to workload updates is a secured segment, and a workload that performs integrity checks on the transactions it processes can be another form of secured segment and / or module domain. When a secured segment extends a vIR, the control layer can create an entry in the load log (also called the activity log) and transfer a digest from the log to a runtime integrity register (e.g., an RTMR).

[0019] The proposed technique introduces additional resettable integrity registers, enabling the sharing of a limited number of integrity register resources. When an integrity register is reset, a report can be generated and signed, thus preserving the integrity register's state in a history file. The integrity register can then be deleted and used by another secured segment, module, and / or CCE. The combination of vIRs and resettable integrity registers can be used to achieve integrity and scalability as well as performance optimization.

[0020] For example, static integrity registers can confirm the status of secured segments, while runtime integrity registers can measure configurations or loaded code. Entities that verify a quote / attestation proof (e.g., a TDX quote), such as quoting environments (e.g., QTD) or attestation services, can verify and replay the load log to recalculate the vIR entries for all secured segments / modules. For example, an Intel® Trust Authority (ITA) attestation service can verify TDX quotes, replay load logs (such as RTMR logs), and recalculate vIR entries. Each independent software vendor (ISV) can independently provide reference values ​​in RIMs for its secured segment / module within the CCE. Attestation services can assess the trustworthiness of the control layer and all secured segments against the reference values / RIMs of the respective ISVs.For example, it signs newly calculated virtual measurements for use by other attestation services or directly by the relying party.

[0021] In some examples, a concise reference integrity manifest (CoRIM) defines an integrity register for measurement types, which can be a list of labeled digests. It can be used to capture dynamic / runtime measurements in a standardized format. The digest of the vIR entries can be integrity-protected using an integrity register (e.g., an RTMR). The vIR can also serve as a log, in which the digest of the load and / or update activities is also added to the IR. The module can be identified by its object identifier (OID), which can be modeled using CoRIM and / or a concise module identifier (CoMID). Each secured segment / module and each secured layer can generate its own vIR structure. If a higher layer wants to verify a lower layer, it can insert the results into another vIR entry containing the outcome, e.g.,Result digest = Hash (layer integrity register, verified, verifier key ID). In this way, multi-layered attestation and multi-layered verification can be performed simultaneously as needed.

[0022] The technique described above enables a limited number of resettable integrity register resources to be effectively shared across multiple secured segments / modules within a CCE or between multiple CCEs. Furthermore, the technique allows the creation of virtual integrity registers within a CCE-secured segment / module to adapt to the number and performance requirements of the secured segment / module and the workload demands. Additionally, the technique enables the dynamic application of software updates to the CCE, generating an integrity report specific to the integrity register. That is, when a single component is updated, a corresponding integrity report can be generated, containing attestation evidence that documents the change.Furthermore, the technique described above allows resettable integrity registers to decouple the actions of a first user from those of a second user without requiring a system / CCE reset. Additionally, the technique allows integrity register reports to be routed to the entity best suited to manage them. For example, attestation reports pertaining to a resettable integrity register and its associated vIR protocol can be managed by a quoting environment, while the integrity of an application-specific use case (such as transaction processing) can be managed by the workload.

[0023] In other words, the disclosed technique can define a virtual integrity register (vIR) and a virtual measurement frame (RIM) that enables software-defined measurements. This means that software can define vIR entries with arbitrary names and hash algorithms to measure the software image as well as any dynamically loaded code / data / configurations. The ISV simply needs to provide an architecture-independent RIM. Furthermore, the disclosed technique can define / group vIRs (as evidence of attestation) per secured segment / module, which represents the runtime environment of a module. This allows attestation verifiers to compare claims of secured segments / modules against the respective RIMs. Additionally, the disclosed technique can generate precise software bills of materials (SBOMs) (see [reference]). Fig. ).

[0024] Fig. This shows a block diagram of an example of a Device 100. The Device 100 includes switching logic configured to provide the functionality of the Device 100. For example, the Device 100 includes Fig. an interface switching logic 120, a processing switching logic 130 and an (optional) storage switching logic 140. For example, the processing switching logic 130 can be coupled with the interface switching logic 120 and optionally with the storage switching logic 140.

[0025] For example, the processing logic 130 can be configured to provide the functionality of the device 100 in conjunction with the interface logic 120. For example, the interface logic 120 is configured to exchange information, e.g., with other components inside or outside the device 100 and the storage logic 140. Similarly, the device 100 can include means configured to provide the functionality of the device 100.

[0026] The components of the device 100 are defined as component means that correspond to, or can be implemented by, the respective structural components of the facility 100. For example, the device 100 comprises Fig. Means for processing 130, which correspond to or can be implemented by the processing switching logic 130; means for communicating 120, which correspond to or can be implemented by the interface switching logic 120; and (optionally) means for storing information 140, which correspond to or can be implemented by the storage switching logic 140. The functionality of the device 100 is illustrated below with reference to the setup 100. Features described in connection with the setup 100 can therefore be applied equally to the corresponding device 100.

[0027] In general, the functionality of the processing logic 130 or the means of processing 130 can be implemented by the processing logic 130 or means of processing 130 executing machine-readable instructions. Accordingly, any feature attributed to the processing logic 130 or means of processing 130 can be defined by one or more instructions from a plurality of machine-readable instructions. The device 100 or apparatus 100 can include the machine-readable instructions, for example, within the storage logic 140 or means of storing information 140.

[0028] The interface switching logic 120 or means of communication 120 can correspond to one or more inputs and / or outputs for receiving and / or transmitting information, which may be in digital (bit) values ​​according to a specified code, within a module, between modules, or between modules of different entities. For example, the interface switching logic 120 or means of communication 120 can include switching logic configured to receive and / or transmit information.

[0029] For example, the processing logic 130 or the processing means 130 can be implemented using one or more processing units, one or more processing devices, or any processing means, such as a processor, a computer, or a programmable hardware component that can be operated with appropriately adapted software. In other words, the described function of the processing logic 130 or the processing means 130 can also be implemented in software that is then executed on one or more programmable hardware components. Such hardware components can include a general-purpose processor, a digital signal processor (DSP), a microcontroller, etc.

[0030] For example, the storage switching logic 140 or the means of storing information 140 may include at least one element of the group of a computer-readable storage medium, such as a magnetic or optical storage medium, e.g. a hard disk drive, flash memory, floppy disk, random access memory (RAM), read-only memory (ROM), programmable read-only memory (PROM), EPROM (EEPROM) or network storage.

[0031] The processing logic 130 is configured to record an entry in a virtual integrity register. The entry is based on a measurement of a module. The module is part of a confidential computing environment.

[0032] A CCE architecture can comprise a combination of specialized hardware and software components designed to protect data and computations from unauthorized access and manipulation within a computer system. The CCE architecture can provide secure processing logic responsible for executing sensitive workloads in an isolated environment. Additionally, the CCE architecture can provide secure memory, such as a protected area of ​​the computer system's RAM, where sensitive data can be stored during computation. To further protect this data, the CCE architecture can provide memory encryption, ensuring that the contents of system memory remain protected even if physical access to the memory is gained.For example, the CCE architecture can support I / O isolation and secure input / output operations, preventing data loss during communication between the processing switching logic and peripheral devices. In some examples, the CCE architecture can provide secure storage capabilities for the computer system, such as a secure partition within the system's main memory dedicated to storing cryptographic keys and sensitive configuration data. This secure storage ensures that critical data remains protected even at rest. In some examples, the CCE can also include separate secure storage components, such as a tamper-proof storage chip or an integrity measurement register, to securely store CCE measurements and / or critical data associated with the operation of the CCE.A host can create one or more instances of CCEs based on the CCE architecture. These instances of the CCE architecture can be referred to as CCEs (also known as Trusted Execution Environments). The CCE uses its components to enable the secure and isolated execution of workloads. A workload running in the CCE can consist of a set of applications, tasks, or processes that are actively managed and protected by these secure hardware components. This includes computational activities that utilize the CCE's resources, including CPU, memory, and storage, to perform their operations. Such activities can include running applications, processing sensitive data, performing calculations, and managing tasks that require a high level of security and confidentiality.The CCE ensures that these workloads are protected from unauthorized access and manipulation by using hardware-based security features and cryptographic measures, thereby maintaining the integrity and confidentiality of the data and processes during their execution.

[0033] The CCE can comprise one or more hierarchically layered environments, each specifically designed to perform different computational functions within the CCE. These environments can be categorized based on their roles and responsibilities, ensuring a structured and secure computational framework. A CCE environment can include one or more modules, each responsible for specific tasks or operations within that environment. A module within a CCE environment might be designed to perform specific functions, such as initializing the environment, running applications, managing data, performing cryptographic operations, or ensuring the integrity of the environment and its processes. These modules work together within their respective environments to maintain the security, integrity, and confidentiality of the CCE as a whole.For example, there can be one or more core CCE environments responsible for key security functions, such as the Root of Trust (RoT). The RoT can be a hardware-based security component that provides a secure and immutable root of trust for the layers above it. The core security environment provides the essential security mechanisms and root of trust upon which the entire framework is built. The core security framework provides the foundation for the security of the entire CCE. An example of a core security framework is the Device Identifier Composition Engine (DICE) specification. DICE is a hardware-based security mechanism that generates unique cryptographic identities and keys based on the initial measurement of a device's hardware and firmware state during boot.DICE comprises a process that derives cryptographic keys at each stage of the boot process. The keys derived based on DICE can be used to derive various cryptographic keys, including firmware keys and quoting keys, creating a chain of trust through layered identities and attestation. DICE can be defined in the Trusted Computing Group's DICE Attestation Architecture specification, Version 1.1, Revision 0.18, January 6, 2024. Furthermore, the underlying CCE environment can include a trusted platform manager (also known as a trusted platform module or TPM). The trusted platform manager can record CCE measurements to an integrity register and manage cryptographic keys to sign measurements for internal verification.The trusted platform manager ensures that the system starts from a trusted state, thus forming the basic security on which the CCE operates.

[0034] Another environment within the CCE can be the Quoting Environment (QE), also known as the Quoting Agent, which is responsible for collecting, formatting, reformatting, and signing measurements and generating attestation evidence (also called quotes) from other layered environments within the CCE. The QE can include modules responsible for handling cryptographic operations, such as formatting and signing the integrity measurements collected from higher layers. For example, the QE can receive measurements from an execution environment and format or sign them with a cryptographic key to create an attestation evidence. This attestation evidence can be consolidated and structured in a way that can be verified by an external attestation verifier.For example, the CCE can include an execution environment (such as a tenant environment (TE)) and a service environment (such as a migration environment (ME)). The execution environment can be a secure, isolated execution space dedicated to running a tenant's (user's) applications, data, and workloads.

[0035] In some examples, the module can be at least one of a runtime environment, a library, and a workload. In some examples, the module runs in a CCE execution environment. For example, the execution environment can include a runtime environment module, which may be an operating system layer that provides essential services for application execution. The execution environment can include library modules that provide common functionality required by the tenant's applications. The execution environment can include a workload, such as the tenant's application code, which performs specific tasks. The execution environment can also include a startup code module, which may be responsible for initializing and loading the components of the execution environment and for measuring the integrity of the execution environment and its modules.The commissioning code module can also be configured to secure the memory areas required for its operation, thereby creating a secure execution environment within the CCE. This execution environment can be built upon the basic hardware and firmware components that provide fundamental secure enclaves and isolated execution functions, ensuring that the tenant's resources are isolated from other tenants and protected from the underlying system.

[0036] In some examples, the module is a workload that performs one or more transactions with another party. The workload module can be responsible for executing and managing tasks that involve secure interactions between the CCE and an external entity, such as another system, service, or user. Transactions can include financial transactions, data processing tasks, or any operations that require secure communication and processing between the CCE and the other party. The integrity of these transactions can be ensured by recording entries in the virtual integrity register (vIR). Each transaction can be monitored and securely logged within the vIR, creating a tamper-proof record that can be used for verification and attestation purposes.This ensures that every transaction carried out by the module can be accurately tracked and validated to guarantee the overall security and trustworthiness of the CCE (see also . Fig. below).

[0037] Hierarchically layered environments can be structured so that a lower layer supports and attests to the integrity of a layer above it, ensuring a continuous chain of trust across the entire CCE. For example, a lower-layer CCE environment can receive a measurement from a higher-layer environment and sign it with its private key. In some examples, a measurement from a higher layer is signed by a lower layer to maintain a continuous chain of trust. This can be described as a trust dependency between the higher and lower layers. For example, the measurement from a higher layer is signed with the private key of a lower layer, and the public key of the higher layer's private-public key pair can also be signed with the lower layer's private key.This ensures that when the public key is used to verify the measurement, it is authenticated by the signature of the lower layer. A private-public key pair, also known as asymmetric cryptography or public-key cryptography, is a cryptographic tool used for secure communication and authentication. The private key is kept secret and is used to sign data, creating a digital signature that verifies the integrity and origin of the data. The corresponding public key is publicly shared and is used to verify the digital signature created by the private key, ensuring that the data has not been tampered with and confirming the sender's identity.This pair enables secure data exchange and authentication without having to share the private key, thus maintaining security.

[0038] A measurement of a CCE component represents the state of a software or hardware component participating in a multi-layered CCE environment at a specific point in time. For example, a measurement might be a cryptographic digest representing the state of the entire CCE, a specific environment within the CCE, a module within an environment, or any combination thereof at that point in time. These measurements are crucial for verifying the integrity of CCE components to ensure they have not been altered or tampered with. A measurement can be used in an attestation to validate the integrity of a CCE component. This measurement typically involves generating a cryptographic hash of the component, which may contain the binary executable code, configuration data, and / or initial state data of the software or hardware component.The hash is produced by reading the binary raw data of the system's software components and processing it through a cryptographic hash function (e.g., SHA-256) to generate a fixed-size hash value that uniquely represents the exact state of the component at that specific time.

[0039] A measurement can be performed, for example, when a component or module is first loaded into the CCE's memory (often referred to as a static measurement or load-time measurement). In this example, the binary image of the component or module, including its associated code and data, is hashed to capture its state upon entry into the CCE. This load-time or static measurement serves as a baseline, ensuring that the module starts in a known, safe state. However, during runtime, the CCE's components or modules (including the workload) may undergo changes, such as updates, the loading of additional code or configurations, or the like. For example, a measurement of the component can be performed dynamically during runtime (referred to as a runtime or dynamic measurement).Dynamic measurement captures the current state of the component and reflects changes that have occurred since the initial load. These dynamic measurements serve as continuous checks to ensure the component's integrity throughout its operational lifecycle. Each measurement can then be recorded in a virtual or hardware integrity register, as described below.

[0040] A secure segment of a CCE can be an isolated and specifically defined part of the CCE, dedicated to performing a particular task and / or function. For example, a secure segment might comprise one or more modules, environments, and / or components of the CCE. A secure segment operates within its own defined boundaries and has access only to the components and resources required for its specific task. For instance, a secure segment of the CCE might be isolated from other segments of the CCE with respect to memory access and / or execution. A secure segment can be a focused environment, such as the execution environment or parts thereof, each serving a distinct purpose within the broader CCE framework.Secured segments can be protected by stringent security measures, including cryptographic techniques and access controls, which ensure the integrity and confidentiality of their components. By isolating and securing these segments, the CCE can effectively manage and verify the security of its various components, thereby maintaining the overall integrity and trustworthiness of the environment. For example, if the CCE is an Intel® TDX, the secured segment can be a subdomain of a trusted domain.

[0041] The virtual integrity register (vIR) can be a software-defined register for storing measurements of components of the CCE. The vIR can be a structured memory location, organized, for example, as a sequence of entries, where each entry contains specific data. For instance, there can be a separate entry in the vIR for each module of the CCE. In another example, there can be a separate entry in the vIR for each secure segment of the CCE (in some examples, a module can correspond to a secure segment). Recording a new entry in the vIR can involve adding new information, such as the module's measurement, to this existing structure.For example, each entry in the vIR is stored in a defined format, allowing the register to maintain a clear record of all measurements or events that can be accessed or reviewed later to ensure system integrity and security. The vIR is not subject to the limitations of physical hardware, as is the case with a hardware integrity register. The vIR can dynamically allocate space within the secure memory that the CCE can access to record measurements. Therefore, the vIR can only be limited by the available secure memory of the CCE, not by the size limitations of hardware integrity registers. The secure memory that the CCE can access could, for example, be a protected area of ​​the computer system's RAM where the CCE is hosted, isolated from the rest of the system.This ensures that the data stored in the vIR remains secure and inaccessible to unauthorized processes. For example, the generation of attestation certificates (also known as quotes) can be based on these recorded measurements, which provide proof of the integrity of the modules and / or secured segments.

[0042] In some examples, the processing logic 130 can be configured to create the virtual integrity register (vIR). The vIR can reside in memory accessible to the CCE, such as a protected area of ​​RAM within the computer system hosting the CCE. Creating the vIR may involve dynamically allocating space within this secure memory, which is isolated from the rest of the system to ensure security and integrity. This process may include initializing the vIR as a structured data area specifically designed to store cryptographic measurements of the modules and / or secured segments of the CCE.

[0043] The processing logic 130 is further configured to load the module into memory. This memory is accessible to the CCE. Loading the module can involve placing the module's binary code and data into the memory accessible to the CCE. The memory accessible to the CCE can be a protected area of ​​RAM within the computer system hosting the CCE. This could be, for example, the same or a different protected area of ​​RAM where the vIR is stored. This memory can be specifically allocated for use by the CCE to ensure that the module operates in a protected environment. The secure memory is designed to prevent unauthorized access and manipulation, ensuring that only trusted processes within the CCE can interact with the loaded module.

[0044] The processing logic 130 is further configured to load the module into memory accessible to the CCE. Loading the module may involve placing the module's binary code and data into this designated memory location, which is typically a protected area of ​​RAM within the computer system hosting the CCE. This secure memory area may be identical to or different from the area where the vIR is stored. For security reasons, this memory area may be isolated from the rest of the system. The purpose of using this protected memory is to ensure that the module operates in a secure environment, protected from unauthorized access and manipulation.Only trusted processes within the CCE can interact with the module in this memory, ensuring that its execution remains secure and the overall integrity of the system is maintained.

[0045] In some examples, the measurement on which the vIR entry is based can be determined before the module is loaded into memory. This can be considered a static measurement or a load-time measurement in the sense described above. This measurement can capture the module's state at the time of loading and serves as a safe baseline by hashing its binary image, including code and data, to ensure it starts in a known, unaltered state. In other examples, the measurement on which the vIR entry is based can be determined after the module is loaded into memory. This can be considered a runtime measurement or a dynamic measurement in the sense described above. This measurement can capture the current state of the modules and reflects any changes, updates, or additional configurations that occur during operation.

[0046] The processing logic 130 is further configured to record an entry in a log (also known as a load log or activity log). The log includes a loading and / or modification history of modules, for example, during the lifecycle of the CCE (e.g., the CCE instance). In some examples, an installer (see Installer 720 in Fig. Create an initial commissioning module, which can be the first module that the installer can also write to the load log. This entry includes information about the module's loading. The load log can be a structured data record that captures the detailed history of the modules as they are loaded into the CCE. For example, the load log can record the history of all modules loaded during the workload's lifecycle. Specifically, the load log can record the history of all modules loaded during the lifecycle CCE (the CCE instance). The log can be organized as a sequential list or a series of entries, with each entry containing information about a module's loading process, thus forming a comprehensive load history.Recording a new entry in the load log can involve capturing information about the loaded module and any relevant context, and writing this information to the log. The log can be stored in secure memory, such as a protected RAM area, ensuring that it is accessible only to authorized processes within the CCE and protected from unauthorized access or manipulation. In some examples, information about the module loading and / or information about previously loaded modules can include at least one of the following: a timestamp for the module loading, a position within a sequence of loaded modules, and a module identifier. A timestamp for the module loading can indicate the precise moment the module was loaded into the CCE, thus providing a chronological reference for the loading event.The position within the sequence of loaded modules can reflect the order in which the module was loaded relative to other modules, helping to establish the load order and dependencies between modules. A module identifier can be a unique value that distinguishes the module from others, ensuring precise tracking and verification. For example, the module identifier can be a cryptographic digest of the module's firmware, which can also serve as an attested value. This attested value can be further supplemented by a confirmation statement from the module's vendor, containing additional information such as the module's version number, the quality metrics applied during manufacturing, or the taxonomies and ontologies to which the module belongs.

[0047] In some examples, a loaded image can be patched (without unloading / reloading the image). For example, when the image is patched, the log can also be updated (e.g., by the installer that applied the patch) to reflect the patch application, ensuring that no change made to the CCE goes unnoticed. In some examples, the log can also include deltas from the underlying trusted layers.

[0048] Furthermore, the processing logic 130 is configured to record an entry in an integrity measurement register. This entry is based on the recorded entry in the virtual integrity register. The integrity measurement register (IMR) is a secure memory component within the CCE (Confidential Computing Environment) used to store values ​​based on measurements taken by the CCE. For example, the IMR is non-volatile memory that is physically separate from other memory and storage media accessible to the confidential computing environment, thus ensuring a higher level of security and protection against tampering. For instance, the IMR can be a runtime integrity measurement register (RTMR).

[0049] Recording an entry in the IMR can involve creating a new entry containing data based on the recorded vIR entry. For example, the data based on the recorded vIR entry might include a cryptographic hash (also known as a digest) based on the recorded vIR entry. Alternatively, recording an entry in the IMR might involve adding data based on the recorded vIR entry to an existing entry in the IMR without deleting the information of the existing entry. For example, the data based on the vIR entry might be a cryptographic hash or digest concatenated with the data of the existing IMR entry.The concatenated data can then be hashed, and the resulting hash can replace the previous entry in the IMR (this process can be referred to as extending the new data into the IMR). This extension mechanism allows the IMR to maintain a continuous, tamper-proof record of the integrity of the CCE over time.

[0050] In some examples, the processing logic 130 is further configured to transmit an attestation certificate, based on one or more recorded entries from the integrity measurement register, along with the load log to an attestation verifier. The attestation verifier is configured to evaluate the integrity of one or more modules, components, or secured segments of the CCE, on whose measurements the one or more entries of the IMR are based. For example, the attestation verifier can use the load log to reconstruct the load sequence and the one or more measurements as stored in the vIR entry. The attestation verifier can then create a digest of the reconstructed vIR entry and compare it to the entry stored in the IMR. If they match, the load log accurately reflects the state of the system.Once this match is confirmed, the attestation verifier can compare the IMR digest entry with the expected value provided in a Reference Integrity Manifest (RIM). This final comparison ensures that the one or more modules, components, or secured segments of the CCE are operating in an unaltered and expected state as defined by the RIM, thereby confirming the integrity of these elements.

[0051] The described technique offers a robust and scalable approach to maintaining the integrity of a CCE and / or its components by integrating a virtual integrity register (vIR) with hardware-based integrity registers such as the integrated integrity register (IMR). By recording entries in a vIR based on measurements of individual modules or secured segments, the integrity of components within the CCE can be dynamically tracked and managed, ensuring precise and scalable monitoring tailored to specific performance and security requirements without being limited by the IMR's storage capacity constraints. Linking the vIR entries to the IMR enables efficient sharing of limited hardware resources across multiple modules or even multiple CCE instances, while simultaneously ensuring that the vIR entries remain protected by the IMR.This link ensures continuous, tamper-proof integrity across various use cases, from system-level security to application-specific processes such as transaction processing. The vIR can be dynamically scaled according to the number and performance requirements of the modules or workloads, allowing updates to be measured and recorded in real time. The attestation verifier, in turn, uses the load log to reconstruct the load sequence and vIR entries and generates a digest that is compared to the IMR. If they match, the load log is validated as an accurate representation of the load events.

[0052] As described above, one or more vIR entries can be hashed to generate a digest, which is then stored in an IMR entry, or an IMR entry can be extended with this digest. This makes the vIR entries IMR-secured. Furthermore, an attestation certificate is generated based on one or more IMR entries. The attestation certificate can consist of one or more IMR entries and a signature of one or more of the IMR entries. In some examples, the processing logic 130 is also configured to generate a digest from one or more IMR entries. In this case, the attestation certificate can then consist of the digest of one or more IMR entries and the corresponding signature.In some examples, the processing logic is further configured to transmit the one or more signed entries of the IMR (for example, as part of an attestation certificate) and the loading protocol to an attestation verifier.

[0053] In some examples, the processing logic 130 can further be configured to sign one or more entries of the IMR with a cryptographic key. This results in a signature of the one or more IMR entries. Signing an entry of the IMR or a digest of an entry of the IMR can involve generating a digital signature by encrypting the entry of the IMR or a digest of an entry with a private key from a private-public key pair, thereby ensuring the authenticity and integrity of the measurement. For example, generating a digital signature can involve generating a cryptographic hash of the measurement (the state of the component) and then signing this hash with a private key to generate a digital signature, thereby ensuring the integrity and authenticity of the measurement.The verifier can use the corresponding public key to authenticate the signature. If multiple IMR entries are involved, these entries can first be concatenated and hashed. The resulting hash can then be treated as a single entry, which can be processed as described above.

[0054] In some examples, the processing logic 130 is further configured to store a report IMR based on one or more entries of the IMR in memory accessible to the CCE. The IRM report may include some or all of the IMR entries and / or their corresponding signatures that authenticate those entries. In some examples, the IRM report may include the root of a hash tree constructed from some or all of the IMR entries, and in some examples, the root may be digitally signed. The memory accessible to the CCE could be a protected area of ​​RAM within the computer system hosting the CCE, for example, the same or a different protected area of ​​RAM where the vIR is stored.This storage can be specifically allocated for use by the CCE to ensure that the report is securely stored and accessed in a protected environment designed to prevent unauthorized access and manipulation. This secure storage facility ensures that only trusted processes within the CCE can load and / or transmit the stored report. The report can later be used for attestation or verification purposes, such as generating attestation certificates that can be transmitted to an attestation verifier upon request. Storing the report in a repository accessible to the CCE allows the system to maintain a verifiable record of the IMR's contents, which can be referenced or transmitted to confirm the integrity of the CCE's state.For example, the report can be generated and saved before the IMR is reset, as it may be needed to verify other vIR entries, such as those relating to a different module or a different secured segment.

[0055] In some examples, the processing logic 130 can be configured to reset the IMR. Resetting the IMR can involve deleting some or all of its entries and preparing to record new data based on entries from the vIR. For example, the IMR can be reset after a report containing its entries has been saved to a memory accessible to the CCE, as described above. The reset process can also be triggered when a new workload is started in the CCE or when a new instance of the CCE is initiated on the host system. For example, the IMR can be reset when a new module or secured segment is measured into the vIR, which is then extended into the IMR. This technique can be referred to as a resettable IMR (or, in the case of an RTMR, a resettable RTMR (R.RTMR)).

[0056] For example, the resettable IMR allows the system to decouple the actions of different users without requiring a CCE reset. IMR reports can be forwarded to a system-level reporting quoting environment, while application-specific integrity, such as for transaction processing, can be managed directly by the workload itself.

[0057] In some examples, the entry recorded in the IMR can be based on multiple vIR entries. For instance, an entry based on the first vIR entry can be extended by adding one or more subsequent vIR entries. That is, the IMR entry can be extended as described above by concatenating and hashing the new data with the existing IMR entry. In another example, multiple vIR entries can be combined into a single digest, and this digest can then be stored in a new IMR entry or used to extend an existing one.

[0058] In some examples, the processing logic 130 is further configured to generate a hash tree based on a multitude of vIR entries. A hash tree (also known as a Merkle tree) is a cryptographic data structure that combines individual data hashes into a tree-like structure, with the root hash representing the integrity of all data within the tree. For example, multiple vIR entries are hashed into a hash tree. That is, each of the vIR entries is hashed individually, and these hashes are then combined into a hash tree structure. The final hash of the tree, known as the root hash, provides a single, compact representation of the integrity of all vIR entries. This root hash can be used to efficiently verify the integrity of each entry, thus ensuring that the multitude of vIR entries remains secure and tamper-proof.The root hash of this hash tree can be recorded in the IMR. For example, the root hash of the hash tree can be signed.

[0059] As described above, in some examples the load log can be stored in secure memory, such as a protected RAM area, ensuring that it is accessible only to authorized processes within the CCE and protected from unauthorized access or manipulation. In this case, the integrity of the log can be indirectly verified by comparing the reconstructed measurements, derived from the sequence of module loads detailed in the log, with the digest stored in the IMR. The load log records the module loading process and the corresponding measurements. During verification, the verifier uses the load log to reconstruct the expected measurements and then generates a digest from them. This reconstructed digest is then compared with the digest already stored in the IMR.If they match, this confirms that the charging protocol accurately reflects the system's state and has not been manipulated. If they do not match, this suggests possible manipulation, as the charging protocol would not accurately reflect the measurements stored in the IMR.

[0060] In some examples, the processing logic 130 is further configured to generate a digest of the load protocol. The processing logic 130 can also be configured to write the digest to the IMR. The IMR ensures that the integrity of the load protocol is securely recorded and can be verified later. This provides a tamper-proof, compact representation of the load protocol, enabling efficient and reliable integrity testing of the CCE's state without having to store or process the entire protocol during attestation. During attestation, the system provides the load protocol and the stored digest of the load protocol to the attestation verifier, which reconstructs the load protocol and generates a corresponding digest. The verifier then compares this newly generated digest with the one stored in the IMR.If the digests match, this confirms the integrity and authenticity of the charging protocol, ensuring that the CCE state has not been tampered with. This method provides a safe and efficient way to verify the integrity of the CCE using a compact digest, rather than processing the entire charging protocol.

[0061] In some examples, the Setup 100 can be at least one of the following, or at least part of one of them: a cloud server, an edge server, or a user device. In cloud computing, the server running the Setup 100 technique can be a cloud server. The cloud server can be designed to handle large workloads with robust processing capabilities, high availability, and scalability. The cloud server can be optimized to manage a large number of virtualized instances, ensuring that the workloads they host are securely isolated and efficiently managed. In an edge computing scenario, the Setup 100 can be implemented on an edge server.The edge server can be located closer to the end user and configured for low-latency processing, making it ideal for tasks requiring real-time data processing and fast response times. The edge server can execute the Setup 100 technique to manage and attest to the integrity of workloads running in resource-constrained environments with high performance and responsiveness requirements. In an edge-to-cloud infrastructure, the specific entity performing the Setup 100 technique (cloud server, edge server, or user agent) can depend on the workload requirements and desired performance characteristics. The edge server may be the one performing these steps if the workload requires low-latency access and is sensitive to proximity of data processing, such as in IoT applications or real-time analytics.The cloud server may be better suited for tasks requiring significant computing resources, centralized data management, or long-term storage. The Facility 100 can be designed to be adaptable, allowing workloads to be scheduled across any node within the edge-to-cloud spectrum, based on factors such as performance, latency, and availability. This flexibility ensures that the Facility 100 can optimize workload placement, whether it resides in a high-performance cloud environment, a responsive edge server, or another suitable node in the infrastructure.

[0062] Further details and aspects will be mentioned in connection with the examples described below. The in Fig. The example shown may have one or more optional additional features corresponding to one or more aspects mentioned in connection with the proposed concept, or to one or more examples described below (e.g., Fig. ).

[0063] Fig. Figure 200 shows a flowchart of an example of Procedure 200. Procedure 200 can be performed, for example, by a facility such as facility 100, as described herein. Procedure 200 includes recording 210 an entry in a virtual integrity register. The entry is based on a measurement of a module. The module is part of a confidential computing environment. Procedure 200 further includes loading 220 the module into memory. The memory is accessible to the CCE. The procedure further includes recording 230 an entry in a log. The log contains a load history. The entry includes information about the loading of the module. The procedure further includes recording 240 an entry in an integrity measurement register. The entry is based on the recorded entry in the virtual integrity register.

[0064] Further details and aspects of Procedure 200 will be discussed in connection with the proposed technique or one or more of the above (e.g., with reference to Fig. ) or as explained in the examples described below. Method 200 may include one or more additional optional features corresponding to one or more aspects of the proposed technique, or one or more of the above (e.g., Fig. ) or below (e.g. Fig. ) include the examples described. Further examples

[0065] Fig. can describe a challenge that arises, for example, due to a limited integrity register resource in a CCE. Fig. can describe further examples of the technique proposed in this revelation.

[0066] Fig. This shows software components from different vendors of a CCE 300. The CCE 300 comprises a basic environment 310, a resource manager (for example, a hypervisor) 320, and a tenant environment 330. The tenant environment includes a commissioning code 331, a runtime environment 332, a first library 333, a second library 334, and a workload 335. Vendors A and B produced software modules that are statically linked in the workload. Vendors C and D produced software modules that are statically linked in the second library 334. Vendors E and F produced software modules that are statically linked in the first library 334. Vendors G and H produced software modules that are statically linked in the runtime environment 332. Vendor I produced software modules for the commissioning code 334. A measurement of the commissioning code 331 is recorded in an MRTD register 341.The commissioning code measures and records the runtime environment 332 in runtime integrity register RTMR0, register 342. The commissioning code measures and records the first library 333 in runtime integrity register RTMR1, register 343. The commissioning code measures and records the second library 334 in runtime integrity register RTMR2, register 344. The commissioning code measures and records the workload 335 in runtime integrity register RTMR3, register 345. Since there are only four runtime integrity registers, there is a limit to the number of modules that can be loaded.

[0067] Fig. This shows a flowchart of a static module link. In step 402, Supplier 1 develops software or hardware module Y. In step 404, Supplier 1 creates a RIM of module Y. In step 406, Supplier 1 publishes the RIM of module Y for use by integrity verification services, such as an attestation verifier. In step 408, Supplier 2 develops software or hardware module Z. In step 410, module Y and module Z are linked to form a linked module. In step 412, Supplier 3 loads and / or executes the linked module.

[0068] Fig. This shows the creation of artificially combined RIMs. Supplier A creates RIM A 502, which includes a first workload reference value 522. Supplier B creates RIM B 504, which includes a second workload reference value 524. The first workload reference value 522 and the second workload reference value 524 are combined to form a combined workload reference value 542. The combined workload reference value 542 is used as a combined RIM A_B 552. Supplier C creates RIM C 506, which includes a first library-two reference value 526. Supplier D creates RIM D 508, which includes a second library-two reference value 528. The first library-two reference value 526 and the second library-two reference value 528 are combined to form a combined library-two reference value 544. The combined library-two reference value 544 is used as a combined RIM C_D 554. Supplier E generates RIM E 510, which includes a first library-one reference value 530.Supplier F generates RIM F 512, which includes a second library-one reference value 532. The first library-one reference value 530 and the second library-one reference value 532 are combined to form a combined library-one reference value 546. The combined library-one reference value 546 is used as a combined RIM E_F 556. Supplier G generates RIM G 514, which includes a first runtime environment reference value 534. Supplier H generates RIM H 516, which includes a second runtime environment reference value 536. The first runtime environment reference value 534 and the second runtime environment reference value 536 are combined to form a combined runtime environment reference value 548. The combined runtime environment reference value 548 is used as a combined RIM G_H 558.

[0069] Fig. This shows an attestation workflow of a CCE 600, which includes a RIM. The CCE 600 includes a basic environment 610 and a resource manager 620 (for example, a hypervisor). The CCE 600 includes a tenant environment 630, which includes a workload, libraries, and a runtime environment. The CCE 600 includes a quoting agent 640. The vendor 650 provides modules 652, which are loaded into the tenant environment 630. The vendor 650 also provides RIMs 654 of its modules, which are provided to an attestation verifier 660. The CCE (for example, the hypervisor 620) can collect measurements from images of the tenant environment 630 as they are loaded. The measurements are provided to the quoting agent 640, which compiles them for use by the attestation verifier 660 (for example, an Intel® Trust Authority). This means that the Quoting Agent 640 can generate a certificate of attestation based on these measurements.The attestation evidence is provided to the attestation verifier 660 by the quoting agent 640. The attestation verifier can compare the received RIMs with the attestation evidence to assess whether the integrity of a module has been compromised. If they match, the CCE can be considered untampered with and secure. The attestation verifier can provide these attestation results to a requesting party 670.

[0070] Further details and aspects will be mentioned in connection with the examples described above or below. The examples in Fig. The examples shown may have one or more optional additional features that relate to one or more aspects mentioned in connection with the proposed concept, or to one or more of the above (e.g. Fig. ) or below (e.g. Fig. ) correspond to the examples described.

[0071] Fig. Figure 700 shows a workflow of the CCE loading process using a vIR. The CCE includes a client environment 710. The client environment includes a workload (AL), a library (Bib), a runtime environment (LU), a commissioning code module (commissioning), and a loading protocol. The CCE also includes an RTMR register 712 and a quoting environment 714. In a first step 730, an installer 720 delivers executable images to the commissioning code. The installer 720 can also create an initial commissioning module, which is the first module that can also be written to the loading protocol by the installer 720. In a second step 731, the commissioning code measures the runtime environment and records it (for example, extended) in the first vIR register vIR0. In a third step 731, the commissioning code measures the library and records it (for example, extended) in the second vIR register vIR1.In a fourth step (733), the commissioning code measures the workload and records it (for example, augmented) in a third vIR register (vIRm). In step 734, each of the measured images is loaded into the CCE's memory. The vIR values ​​can then be stored (for example, augmented) in the RTMR (712), which further protects the integrity of the vIR registers. In step 735, the entry or RTMR can be obtained through the quoting environment (714), which can generate a digest D0 of the RTMR entry and a signature S0 of the digest. In step 736, the commissioning code can construct a load log containing a history of the load steps. The integrity of the load log can be protected by the RTMR (712). In step 737, an attestation verifier (740) can request the load log and an attestation certificate based on the digest D0 to assess the integrity of the load process.The attestation verifier 740 can use the load log to reconstruct the load sequence and vIR values. A digest of the vIR entries, determined by the attestation verifier 740, can be compared to the D0 digest in the attestation record. If they match, the load log is an accurate representation of load events. The quote signature S0 authenticates D0.

[0072] Further details and aspects will be mentioned in connection with the examples described above or below. The examples in Fig. The examples shown may have one or more optional additional features that relate to one or more aspects mentioned in connection with the proposed concept, or to one or more of the above (e.g. Fig. ) or below (e.g. Fig. ) correspond to the examples described.

[0073] Fig. This shows an example of transaction integrity for a workload using a virtual integrity register (vIR). A client control environment (CCE) executing the workload transaction includes a tenant environment (810). The tenant environment (810) includes a workload (812), a runtime environment (814), and a transaction log (816). The workload (812) works with workload peers (820) to process a stream of transactions. The runtime environment (841) provides a virtual integrity register (vIR) limited only by the amount of memory configured for use by the CCE's runtime. The transaction stream is split into two batches. The first batch (818), consisting of transactions 0 to m, is recorded in vIR entries vIR0 to vIRm. The second batch (819), consisting of transactions m+1 to m+n, is recorded in vIR entries vIRm+1 to vIRm+n. When the m-th transaction is processed, the runtime environment 814 passes the first...A batch of transactions is sent to a resettable RTMR 830, which ensures the integrity of the first batch of transactions 818 using the hardware integrity register 830. If an attestation occurs at this time, the first batch of transactions 818 is reported to the quoting environment under the key. When the second batch of vIRs is complete, if no more resettable RTMRs are available, the runtime environment 814 can reset RTMR 830, which can trigger a quote-like integrity register report. This report consists of the RTMR name (e.g., "Tx 0,..., m"), the RTMR digest D0, and a signature S0 provided by a quoting environment (e.g., QTD). The integrity register report (also known as a resettable RTMR report (RRR)) can be securely archived in the workload transaction log 816. The workload transaction protocol 816 may not require a secure storage subsystem.The RTMR 830 is set to zero (reset), whereby the second batch of transaction vIR entries can be integrity protected by reusing the same RTMR 830.

[0074] This process can be used for other use cases, such as loading images into the CCE. Multiple integrity register reports can be generated from several loadable images, each using a separate vIR managed by the commissioning loader. After the rest of the loadable CCE images have been loaded, the resettable RTMR is reset, generating a signed integrity register report. In this case, the quoting environment can maintain a log of signed integrity register reports by signaling to the quoting environment that the resettable RTMR is being used for system integrity. After booting, the runtime environment can acquire the use of the resettable RTMR for other purposes.

[0075] A wide range of use cases can be supported by vIR and resettable RTMRs. This technique can be used, for example, for system integrity collection and reporting via attestation ecosystems (such as Intel® Trust Authority and edge / cloud workload processing).

[0076] In the context of system integrity processing, the supply chain can, for example, operate independently of other vendors to release software independently, including the release of RIM files that can be used directly by attestation verifiers. The CCE commissioning loader can be free to load as many images as required to support a given workload. The series of integrity register reports describing a batch of load operations can be made available on request for output to attestation verifiers as a historical representation of what was loaded. If a workload image can be updated or another workload image is added, the vIR and resettable RTMR architectures can be used to capture individual changes to the CCE image after the bootstrap operation.

[0077] Further details and aspects will be mentioned in connection with the examples described above or below. The examples in Fig. The examples shown may have one or more optional additional features that relate to one or more aspects mentioned in connection with the proposed concept, or to one or more of the above (e.g. Fig. ) or below (e.g. Fig. ) correspond to the examples described.

[0078] Fig. This demonstrates the hardening of a vIR using a Level 2 virtual machine (L2VM). A tenant environment 900 comprises the tenant workload 910. The tenant workload 910 can pose a risk to the proper operation of a runtime environment 922 that controls vIR resources 924, as vulnerable workload code could be used as a starting point for deeper exploits that compromise the operational integrity of the vIRs 924 or the vIR protocol 926. This threat can be mitigated by placing an L2VM 920 within the tenant environment, which contains the runtime environment 922, the vIR resources 924, and the vIR protocol 926. This VM isolation technology creates an additional barrier that resists deeper exploits. Other CCE technologies could also be used, such as running an Intel® SGX enclave within or as a sidecar to the Intel® TDX TTD.

[0079] Further details and aspects will be mentioned in connection with the examples described above. The in Fig. The examples shown may have one or more optional additional features corresponding to one or more aspects mentioned in connection with the proposed concept, or to one or more examples described above (e.g. Fig. ).

[0080] The following are some examples of the proposed concept: An example (e.g., Example 1) refers to a device that includes interface switching logic, machine-readable instructions, and processing switching logic for executing the machine-readable instructions to record an entry in a virtual integrity register, wherein the entry is based on a measurement of a module, where the module is part of a confidential computing environment; to load the module into memory, where the memory can be accessed via the confidential computing environment; to record an entry of a log, where the log includes a load history, where the entry includes information about the loading of the module; and to record an entry in an integrity measurement register, where the entry is based on the recorded virtual integrity register entry.

[0081] Another example (e.g., Example 2) refers to a previous example (e.g., Example 1) or to any other example and further includes the fact that the recorded entry in the integrity measurement register is based on a multitude of virtual integrity register entries.

[0082] Another example (e.g., Example 3) refers to a previous example (e.g., one of Examples 1 to 2) or to any other example and further includes the processing switching logic executing the machine-readable instructions to generate a hash tree based on a multitude of entries in the virtual integrity register.

[0083] Another example (e.g., Example 4) refers to a previous example (e.g., one of Examples 1 to 3) or to any other example and further includes the processing switching logic executing the machine-readable instructions to sign one or more entries of the integrity measurement register with a cryptographic key.

[0084] Another example (e.g., Example 5) refers to a previous example (e.g., one of Examples 1 to 4) or to any other example and further includes the processing switching logic executing the machine-readable instructions to transmit an attestation proof, based on one or more recorded entries of the integrity measurement register, and the log to an attestation verifier, the verifier being configured to evaluate the integrity of the module based on the attestation proof and the log.

[0085] Another example (e.g., Example 6) refers to a previous example (e.g., one of Examples 1 to 5) or to any other example and further includes the processing switching logic executing the machine-readable instructions to store an integrity measurement register report based on one or more entries of the integrity measurement register in a memory that the confidential computing environment can access.

[0086] Another example (e.g., Example 7) refers to a previous example (e.g., one of Examples 1 to 6) or to any other example and further includes the processing switching logic executing the machine-readable instructions to reset the integrity measurement register.

[0087] Another example (e.g., Example 8) refers to a previous example (e.g., one of Examples 1 to 7) or any other example and further includes the processing switching logic executing the machine-readable instructions to create the virtual integrity register, the virtual integrity register being located in a memory accessible to the confidential computing environment.

[0088] Another example (e.g., Example 9) refers to a previous example (e.g., one of Examples 1 to 8) or any other example and further includes that the module is at least one of a runtime environment, a library, and a workload.

[0089] Another example (e.g., Example 10) refers to a previous example (e.g., one of Examples 1 to 9) or to any other example and further includes that the module is a workload that performs one or more transactions with another party.

[0090] Another example (e.g., example 11) refers to a previous example (e.g., one of examples 1 to 10) or to any other example and additionally includes the measurement of the module taking place before the module is loaded into memory.

[0091] Another example (e.g., Example 12) refers to a previous example (e.g., one of Examples 1 to 10) or any other example and additionally includes that the measurement of the module is obtained after the module has been loaded into memory.

[0092] Another example (e.g., Example 13) refers to a previous example (e.g., one of Examples 1 to 12) or to any other example and further includes the processing switching logic executing the machine-readable instructions to generate a digest of the protocol and write the digest to the integrity measurement register.

[0093] Another example (e.g., Example 14) refers to a previous example (e.g., one of Examples 1 to 13) or to any other example and further includes that the information about loading the module includes at least one of a time step of loading the module, a position within a sequence of loaded modules, and an identifier of the module.

[0094] Another example (e.g., Example 15) refers to a previous example (e.g., one of Examples 1 to 14) or to any other example and further includes that the integrity measurement register is a non-volatile memory that is physically separate from other memories and storage media that the confidential computing environment can access.

[0095] Another example (e.g., Example 16) refers to a previous example (e.g., one of Examples 1 to 15) or any other example and additionally includes the fact that the module is executed in an execution environment of the confidential computing environment.

[0096] Another example (e.g., Example 17) refers to an edge server that includes the setup according to one of Examples 1 to 15.

[0097] An example (e.g., Example 18) relates to a procedure that includes recording an entry in a virtual integrity register, wherein the entry is based on a measurement of a module, the module being part of a confidential computing environment; loading the module into memory, the memory being accessible via the confidential computing environment; recording an entry in a log, the log containing a load history, the entry containing information about the loading of the module; and recording an entry in an integrity measurement register, the entry being based on the recorded virtual integrity register entry.

[0098] Another example (e.g., Example 19) refers to a previous example (e.g., Example 17) or to any other example and further includes the fact that the recorded entry in the integrity measurement register is based on a multitude of virtual integrity register entries.

[0099] Another example (e.g., Example 20) refers to a previous example (e.g., one of Examples 18 to 19) or to any other example and further includes generating a hash tree based on a large number of entries from the virtual integrity register.

[0100] Another example (e.g., Example 21) refers to a previous example (e.g., one of Examples 18 to 20) or to any other example and further includes signing one or more entries of the integrity measurement register with a cryptographic key.

[0101] Another example (e.g., Example 22) refers to a previous example (e.g., one of Examples 18 to 21) or to any other example and further includes transmitting a certificate of attestation, based on one or more recorded entries of the integrity measurement register and the log, to a certificate of attestation verifier, the verifier being configured to evaluate the integrity of the module based on the certificate of attestation and the log.

[0102] Another example (e.g., Example 23) refers to a previous example (e.g., one of Examples 18 to 22) or to any other example and additionally includes storing an integrity measurement register report based on one or more entries of the integrity measurement register in a memory that the confidential computing environment can access.

[0103] Another example (e.g., Example 24) refers to a previous example (e.g., one of Examples 18 to 23) or to any other example and additionally includes resetting the integrity measurement register.

[0104] Another example (e.g., Example 25) refers to a previous example (e.g., one of Examples 18 to 24) or any other example and further includes the creation of the virtual integrity register, wherein the virtual integrity register is located in a memory that the confidential computing environment can access.

[0105] Another example (e.g., Example 26) refers to a previous example (e.g., one of Examples 18 to 25) or any other example and additionally includes that the module is at least one of a runtime environment, a library, and a workload.

[0106] Another example (e.g., Example 27) refers to a previous example (e.g., one of Examples 18 to 26) or to any other example and further includes that the module is a workload that performs one or more transactions with another party.

[0107] Another example (e.g., Example 28) refers to a previous example (e.g., one of Examples 18 to 27) or to any other example and additionally includes the measurement of the module taking place before the module is loaded into memory.

[0108] Another example (e.g., Example 29) refers to a previous example (e.g., one of Examples 18 to 27) or any other example and additionally includes that the measurement of the module is obtained after the module has been loaded into memory.

[0109] Another example (e.g., Example 30) refers to a previous example (e.g., one of Examples 18 to 29) or to any other example and additionally includes generating a digest of the protocol and writing the digest to the integrity measurement register.

[0110] Another example (e.g., Example 31) refers to a previous example (e.g., one of Examples 18 to 30) or to any other example and further includes that the information about loading the module comprises at least one of a time step of loading the module, a position within a sequence of loaded modules, and an identifier of the module.

[0111] Another example (e.g., Example 32) refers to a previous example (e.g., one of Examples 18 to 31) or to any other example and further includes that the integrity measurement register is a non-volatile memory that is physically separate from other memories and storage media that the confidential computing environment can access.

[0112] Another example (e.g., Example 33) refers to a previous example (e.g., one of Examples 18 to 32) or any other example and additionally includes the fact that the module is executed in an execution environment of the confidential computing environment.

[0113] An example (e.g., Example 34) relates to a device with processor switching logic configured to record an entry in an integrity measurement register, wherein the entry is based on a measurement of a module, where the module is part of a confidential computing environment; load the module into memory, where the memory can be accessed via the confidential computing environment; record an entry in a log, where the log includes a load history, where the entry includes information about the loading of the module; and record an entry in an integrity measurement register, where the entry is based on the recorded virtual integrity register entry.

[0114] An example (e.g., Example 35) relates to a device comprising means for processing, recording an entry in a virtual integrity register, wherein the entry is based on a measurement of a module, wherein the module is part of a confidential computing environment, loading the module into a memory, wherein the memory can be accessed via the confidential computing environment, recording an entry in a log, wherein the log includes a load history, wherein the entry includes information about the loading of the module, and recording an entry in an integrity measurement register, wherein the entry is based on the recorded virtual integrity register entry.

[0115] Another example (e.g., Example 36) relates to a non-transitory machine-readable storage medium containing program code which, when executed, causes a machine to perform the procedure according to any one of Examples 18 to 33.

[0116] Another example (e.g., Example 37) refers to a computer program with program code for performing the procedure of any of Examples 18 to 33, when the computer program is executed on a computer, a processor, or a programmable hardware component.

[0117] Another example (e.g., Example 38) relates to a machine-readable memory containing machine-readable instructions which, when executed, implement a method or realize a device as claimed in one of the pending claims.

[0118] The aspects and features described in relation to a particular of the previous examples can also be combined with one or more of the further examples to replace an identical or similar feature of that further example or to additionally introduce the features into the further example.

[0119] Examples may also include a (computer) program with program code to execute one or more of the above procedures, when the program is executed on a computer, processor, or other programmable hardware component. Thus, steps, operations, or processes of different procedures described above may also be executed by programmed computers, processors, or other programmable hardware components. Examples may also include program storage devices, such as digital data storage media, that are machine-, processor-, or computer-readable and can encode and / or contain machine-executable, processor-executable, or computer-executable programs and instructions. Program storage devices may include, for example, digital storage devices, magnetic storage media such as magnetic disks and tapes, hard disks, or optically readable digital data storage media.Other examples may include computers, processors, control units, (field-)programmable logic arrays ((F)PLAs), (field-)programmable gate arrays ((F)PGAs), graphics processing units (GPUs), application-specific integrated circuits (ASICs), integrated circuits (ICs), or system-on-a-chip (SoC) systems programmed to perform the steps of the procedures described above.

[0120] It is further understood that the disclosure of multiple steps, processes, operations, or functions in the description or claims is not to be interpreted as implying that these operations necessarily depend on the described sequence, unless explicitly stated in a specific case or required for technical reasons. Therefore, the preceding description does not restrict the execution of multiple steps or functions to a specific sequence. Furthermore, in other examples, a single step, function, process, or operation may include and / or be subdivided into multiple sub-steps, functions, processes, or operations.

[0121] If certain aspects relating to a device or system have been described, these aspects should also be understood as a description of the corresponding procedure. For example, a block, device, or functional aspect of the device or system may correspond to a feature, such as a process step, of the corresponding procedure. Accordingly, aspects described in relation to a procedure should also be understood as a description of a corresponding block, element, property, or functional feature of a corresponding device or system.

[0122] As used herein, the term "module" refers to logic that may be implemented in a hardware component or device, software or firmware running on a processing unit, or a combination thereof, to perform one or more operations consistent with the present disclosure. Software and firmware may be implemented as instructions and / or data stored on non-volatile, computer-readable storage media. As used herein, the term "switching logic," alone or in any combination, may include: non-programmable (hard-wired) switching logic, programmable switching logic such as processing units, state machine switching logic, and / or firmware that stores instructions executable by programmable switching logic.The modules described herein can be embodied collectively or individually as a switching logic that forms part of a computing system. Thus, any of the modules can be implemented as switching logic. A computing system described as being programmed to perform a procedure can be programmed to perform the procedure using software, hardware, firmware, or combinations thereof.

[0123] Any of the disclosed methods (or any part thereof) may be implemented as computer-executable instructions or a computer program product. Such instructions can cause a computing system or one or more processing units capable of executing computer-executable instructions to perform any of the disclosed methods. As used herein, the term "computer" refers to any computing system or device described or mentioned herein. Thus, the term "computer-executable instructions" refers to instructions that can be executed by any computing system or device described or mentioned herein.

[0124] The computer-executable instructions can be, for example, part of the operating system of the computing system, an application stored locally on the computing system, or a remote application accessible to the computing system (e.g., via a web browser). Any of the procedures described herein can be performed by computer-executable instructions carried out by a single computing system or by one or more networked computing systems operating in a network environment. Computer-executable instructions and updates to computer-executable instructions can be downloaded to a computing system from a remote server.

[0125] Furthermore, it is understood that an implementation of the disclosed technologies is not limited to any specific computer language or computer program. For example, the disclosed technologies can be implemented by software written in C++, C#, Java, Perl, Python, JavaScript, Adobe Flash, assembly language, or any other programming language. Likewise, the disclosed technologies are not limited to any particular computer system or type of hardware.

[0126] Furthermore, any of the software-based examples (which include, for example, computer-executable instructions for causing a computer to perform any of the disclosed methods) can be uploaded, downloaded, or remotely accessed by suitable means of communication. Such suitable means of communication include, for example, the Internet, the World Wide Web, an intranet, cables (including fiber optic cables), magnetic communication, electromagnetic communication (including RF, microwave, ultrasonic, and infrared communication), electronic communication, or other such means of communication.

[0127] The disclosed methods, devices, and systems are not to be understood as being restrictive in any way. Instead, the present disclosure is directed to all new and non-obvious features and aspects of the various disclosed examples, both individually and in various combinations and sub-combinations. The disclosed methods, devices, and systems are not limited to any specific aspect or feature, nor do the disclosed examples require that any specific advantages or problems be solved.

[0128] Operating theories, scientific principles, or other theoretical descriptions presented herein with reference to the devices or methods of this disclosure are provided for convenience only and are not intended to limit the scope. The devices and methods in the appended claims are not limited to those devices and methods that operate in the manner described by such operating theories.

[0129] The following claims are hereby incorporated into the detailed description, each claim standing independently as a separate example. It should also be noted that, although in the claims a dependent claim refers to a specific combination with one or more other claims, other examples may also include a combination of the dependent claim with the subject matter of any other dependent or independent claim. Such combinations are hereby expressly suggested unless it is stated in a particular case that a specific combination is not intended. Furthermore, features of a claim should also be included for any other independent claim, even if that claim is not directly defined as dependent on that other independent claim. QUOTES INCLUDED IN THE DESCRIPTION

[0000] This list of documents cited by the applicant was automatically generated and is included solely for the reader's convenience. The list is not part of the German patent or utility model application. The DPMA accepts no liability for any errors or omissions. Cited non-patent literature

[0000] DICE Attestation Architecture” by the Trusted Computing Group, Version 1.1, Revision 0.18, 6 January 2024

[0033]

Claims

[1] A setup comprising a processing switching logic configured to: Recording an entry in a virtual integrity register, wherein the entry is based on a measurement of a module, the module being part of a confidential computing environment; Loading the module into memory, whereby the memory can be accessed via the confidential computing environment; Recording an entry of a log, wherein the log includes a loading history, and the entry includes information about the loading of the module; Recording an entry in an integrity measurement register, wherein the entry is based on the recorded virtual integrity register entry. [2] Device according to claim 1, wherein the recorded entry in the integrity measurement register is based on a plurality of virtual integrity register entries. [3] Device according to one of claims 1 to 2, wherein the processing switching logic is further configured to generate a hash tree based on a plurality of entries of the virtual integrity register. [4] Device according to one of claims 1 to 3, wherein the processing switching logic is further configured to sign one or more entries of the integrity measurement register with a cryptographic key. [5] Device according to any one of claims 1 to 4, wherein the processing switching logic is further configured to transmit an attestation proof based on one or more recorded entries of the integrity measurement register and the log to an attestation verifier, wherein the verifier is configured to evaluate the integrity of the module on the basis of the attestation proof and the log. [6] Device according to any one of claims 1 to 5, wherein the processing switching logic is further configured to store an integrity measurement register report based on one or more entries of the integrity measurement register in a memory that can be accessed by the confidential computing environment. [7] Device according to any one of claims 1 to 6, wherein the processing switching logic is further configured to reset the integrity measurement register. [8] Device according to any one of claims 1 to 7, wherein the processing switching logic is further configured to generate the virtual integrity register, the virtual integrity register being located in a memory which the confidential computing environment can access. [9] Device according to any one of claims 1 to 8, wherein the module is at least one of a runtime environment, a library and a workload. [10] Device according to any one of claims 1 to 9, wherein the module is a workload that performs one or more transactions with another party. [11] Device according to any one of claims 1 to 10, wherein the measurement of the module is carried out before the module is loaded into the memory. [12] Device according to any one of claims 1 to 11, wherein the measurement of the module is carried out after the module has been loaded into the memory. [13] Device according to any one of claims 1 to 12, wherein the processing switching logic is further configured to generate a digest of the protocol and write the digest to the integrity measurement register. [14] Device according to any one of claims 1 to 13, wherein the information about the loading of the module comprises at least one of a time step of the loading of the module, a position within a sequence of loaded modules and an identifier of the module. [15] Device according to any one of claims 1 to 14, wherein the integrity measurement register is a non-volatile memory that is physically separate from other memories and storage media that the confidential computing environment can access. [16] Device according to any one of claims 1 to 15, wherein the module is executed in an execution environment of the confidential computing environment. [17] Method comprising the following: Recording an entry in a virtual integrity register, wherein the entry is based on a measurement of a module, the module being part of a confidential computing environment; Loading the module into memory, whereby the memory can be accessed via the confidential computing environment; Recording an entry of a log, wherein the log includes a loading history, and the entry includes information about the loading of the module; Recording an entry in an integrity measurement register, wherein the entry is based on the recorded virtual integrity register entry. [18] Method according to claim 17, wherein the recorded entry in the integrity measurement register is based on a plurality of virtual integrity register entries. [19] Method according to one of claims 17 to 18, further comprising signing one or more entries of the integrity measurement register with a cryptographic key. [20] Non-transitory machine-readable storage medium containing program code which, when executed, causes a machine to perform the method according to any one of claims 17 to 19.

Images