Patent Description:
In computing, read-only memory has historically been embodied as a data storage device (i.e., ROM) that stores data that can be read by a computer system, but which cannot be generally modified by the computer system. Read-only memory can be advantageous for storing immutable data and/or executable code that is immune from corruption and attacks from malicious parties (e.g., rewrite attacks). Due at least in part to these advantages, recent innovations have created mixed memory situations that add in-place protections for various operations (e.g., read, write, and/or execute) on portions of a read/write storage device, such as random-access memory (RAM); specifically, some technologies mark specific sections of an otherwise writeable memory space as read-only after load, providing protections against corruption and attacks.

In some situations, read-only memory protection (ROMP) technologies that create read-only protected memory are implemented using second level address translation (SLAT), or nested paging, which is managed by a hypervisor. As a result, standard user-mode or kernel-mode software cannot interact with, and corrupt, read-only protected memory. In one example, the Windows and Secure Kernel from Microsoft Corporation of Redmond, Washington supports a ROMP technology known as Kernel Data Protection (KDP). KDP provides at least two ways to operate on memory that is read-only protected by a hypervisor. First, static KDP allows a section of a binary image, loaded in an operating system (OS) kernel, to be read-only protected through use of SLAT in the hypervisor; when the section is read-only protected, any attempt to write to the underlying physical memory backing the section will - by design - result in a system crash. Second, dynamic KDP allows any software running in kernel mode to request a chunk of pre-initialized, read-only protected memory; the returned memory can be freed, but any attempt to write to the read-only protected memory will - by design - result in a system crash. The two technologies can be used singly, or in combination, to create highly protected data which is tamper resistant to attacks to the kernel. Other ROMP technologies are implemented in hardware, such as by using a hardware-based trusted execution environment (ARM TrustZone, Intel Software Guard Extensions (SGX)), hardware-based page table (e.g., HLAT), and the like.

With the recent proliferation of security technologies that provide code and control flow integrity (e.g., Code Integrity and Control Flow Guard in the WINDOWS OS from Microsoft Corporation), the landscape for attacks is shifting towards data corruption. ROMP technologies, such as KDP and similar technologies, help to protect against these attacks by preventing modifications to read-only-at-rest data variables. <NPL> describes an end-to-end solution that helps you protect high-value assets by enforcing, controlling, and reporting the health of Windows <NUM>-based devices. <CIT> describes various approaches for implementing attestation using an attestation token are described. In an edge computing system deployment, an edge computing device includes an attestable feature (e.g., resource, service, entity, property, etc.) which is accessible from use of an attestation token, by the operations of: obtaining a first instance of a token that provides proof of attestation for an accessible feature of the edge computing device, with the token including data to indicate trust level designations for the feature as attested by an attestation provider; receiving, from a prospective user of the feature, a request to use the feature and a second instance of the token, with the second instance of the token originating from the attestation provider; and providing access to the feature based on a verification of the instances of the token, by using the verification to confirm attestation of the trust level designations for the feature.

The invention is set out in the appended set out of claims.

While ROMP technologies, such as KDP, are effective at protecting against corruption and attacks at a computer system, there is no solution for determining if a particular software component (e.g., OS, driver, and/or application) executing at a client computer system (client system) is protected by a ROMP technology when a relying party computer system (relying system) communicates with that client system. At least some embodiments described herein address this shortcoming by enabling generation of an attestation report that certifies that at least one software component executing at a client system is protected by a ROMP technology, such as KDP. In embodiments, this attestation report comprises one or more attested properties. In embodiments, these attested properties comprise one or more of: a binary image name for which ROMP is enabled, a binary image version, a digital signature at load time of the binary image, a base offset of a read-only protected memory section allocated to the binary image, a size of the read-only protected memory section, at least one attribute of the read-only protected memory section (e.g., whether the binary image can be unloaded, whether a read-only protected memory section is freeable or non-freeable, etc.), a status of a secure ROMP technology (e.g., KDP TrustZone, SGX, HLAT, etc.) protecting an underlying virtual to guest physical address mapping, a set of physical pages underlying the read-only protected memory section, an indication of content of the read-only protected memory section (e.g., at least one checksum, hash, cryptographic hash, etc.), or a range list of the memory content. In embodiments, the relying system uses this attestation report to verify these properties prior to sending data to the client system and/or prior to relying on data received by the client system.

In one example scenario, gaming software at a relying system (e.g., corresponding to a player, a game server, etc.) may want to verify that an anti-cheat component at a client system (e.g., corresponding to another player) has not been compromised (e.g., by modifying a driver, or data used by the driver) prior to engaging in a multi-player game with the client system. In this scenario, and in accordance with the embodiments herein, the client system uses a ROMP technology, such as KDP, to read-only protect at least a portion of memory corresponding to this anti-cheat component. The relying system obtains a cryptographically secured attestation report. The attestation report certifies one or more properties of the anti-cheat component, including at least one property relating to enablement of ROMP for the anti-cheat component. The relying system uses this attestation report to verify integrity of the anti-cheat component, based at least on verifying the presence and enablement of ROMP for the anti-cheat component. Based at least on verification of the integrity of the anti-cheat component, the gaming software at the relying system engages in the multi-player game with the client system.

In another example scenario, key distribution software at a relying system (e.g., corresponding to an audio or video distribution service, etc.) may want to verify that a media player at a client system (e.g., corresponding to a media consumption device) has not been compromised prior to sending a decryption key to the client system. The client system uses a ROMP technology to read-only protect at least a portion of memory corresponding to the media player. The relying system obtains a cryptographically secured attestation report, and uses this attestation report to verify integrity of the media player, based at least on verifying the presence and enablement of ROMP for the media player, and sends the client system the decryption key after a successful verification.

In some embodiments methods, systems, and computer program products are directed to attesting to read-only protected memory. Based on a communications request, a client computer system receives a nonce from a relying party computer system. The client computer system generates attestation evidence. The attestation evidence comprises one or more attested properties, including one or more ROMP attested properties for read-only protected memory allocated to a software component loaded at the computer system, the nonce, and a system security claim. The client computer system sends the attestation evidence toward an attestation service computer system. Based on sending the attestation evidence, the client computer system participates in a relying communication with the relying party computer system.

Technical effects of attesting to read-only protected memory in a distributed system include allowing verifiable assurances to be made of system state (e.g., state of a client system), improving the foundational capabilities for secure computing. These assurances, in turn, enable a relying system to objectively gauge its level of trust in the client system, which facilitates secure data communications between the client system and the relying system.

In embodiments, an attestation report has a finite validity window during which a relying system can rely on attested properties regarding a ROMP status for a software component at a client system. For example, a validity window may be based on a particular time at which an attestation report becomes invalid, a particular post-issuance validity time limit, etc. However, the attested-to ROMP status for the software component can change at the client system during this validity window (e.g., based on reloading of a driver). As such, a relying system could rely on attested properties that are no longer valid. At least some additional embodiments described herein take proactive remedial actions at a client system if attested-to properties regarding a ROMP status for a software component are no longer valid during an attestation validity period. Thus, these embodiments operate to enforce attestation of read-only protected memory during attestation validity period, and this enforcement may be determined by another attested property. For example, if the ROMP status for a software component changes during an attestation validity period, remedial actions may include suspending one or more processes corresponding to software component until the end of the attestation validity period, terminating one or more processes corresponding to software component, blocking one or more communications from the software component, notifying the relying system, invalidating a cryptographic key, making a cryptographic key no longer accessible, and the like.

In other embodiments, methods, systems, and computer program products are directed to enforcing attestation of read-only protected memory during attestation validity period. A client computer system identifies a change in a ROMP status for a software component loaded at the client computer system. The client computer system then determines that a validity time period of an attestation report is unexpired. The attestation report comprises one or more attested properties, including one or more ROMP attested properties for read-only protected memory allocated to the software component. The client computer system also determines that at least one ROMP attested property for the software component is no longer valid due to the change in the ROMP status for a software component. Based on the at least one ROMP attested property for the software component being no longer valid, the client computer system initiates a remedial action to prevent interaction of the software component with a relying party computer system.

Technical effects of enforcing read-only protected memory during an attestation validity period include promoting computer security by ensuring that a relying party can actually rely on attestations made by a client computer system during the entire validity duration of an attestation report.

Notably, either embodiment promotes the use of RAM for read-only protected memory, rather than requiring a separate pool of physically write-once memory. As will be appreciated, using a separate pool of physically write-once memory adds hardware costs and presumes foreknowledge of how much of memory needs to be read-only protected. Thus, promoting the use of RAM for read-only protected memory reduces physical hardware requirements, and increases flexibility in use of physical hardware.

<FIG> illustrates an example distributed system architecture <NUM> that facilitates attestation of the presence of ROMP in a distributed computing environment, and enforcement those protections during an attestation validity period. As shown, distributed system architecture <NUM> comprises a client computer system <NUM> (client system <NUM>), an attestation service computer system <NUM> (attestation service <NUM>), and a relying party computer system <NUM> (relying system <NUM>), which-at least in <FIG>-are communicatively interconnected by one or more network(s) <NUM>. Although illustrated separately, in some embodiments the attestation service <NUM> and the relying system <NUM> are combined into the same computer system. Although illustrated as being separated from the client system <NUM> by network <NUM>, in some embodiments the relying system <NUM> executes within a secured context executing at client system <NUM>.

In embodiments, one or more of the client system <NUM>, the attestation service <NUM>, and the relying system <NUM> comprise computing hardware (e.g., processor(s), memory, disk storage, network adapter, etc.). Referring to client system <NUM> specifically, <FIG> illustrates additional detail of hardware <NUM> of client system <NUM>. As shown, this hardware <NUM> includes processor(s) <NUM>, memory <NUM> (e.g., main memory, such as RAM), storage <NUM> (e.g., disk storage, ROM, etc.), a network adapter (network <NUM>), and a trusted platform module (TPM <NUM>).

In general, distributed system architecture <NUM> operates to attest to the presence and status of read-only protected memory <NUM> allocated to a software component (attested software <NUM>) executing at the client system <NUM>. In embodiments, the read-only protected memory <NUM> is a chunk of memory allocated to the software component from memory <NUM>, and to which ROMP is applied. As will be explained in detail infra, the attestation service <NUM> generates an attestation report based on evidence generated by the client system <NUM>, and the relying system <NUM> uses this attestation report to verify that the attested software <NUM> satisfactorily utilizes read-only protected memory <NUM> (e.g., based on a policy <NUM>). After a successful verification, the relying system <NUM> makes a relying communication(s) with the client system <NUM>.

By way of example, <FIG> illustrates a configuration of client system <NUM> that could, as an example, be used to attest to the status of read-only protected memory <NUM> created using a software-based ROMP technology, such as KDP. However, the principles described herein are applicable to a wide variety of software- and/or hardware-based ROMP technologies, such those using KDP, TrustZone, SGX, HLAT, and the like.

In <FIG>, the hardware <NUM> at the client system <NUM> executes a hypervisor <NUM>. The hypervisor <NUM>, in turn, creates at least two security modes (e.g., partitions or virtual machines), including at least a lower-trust mode (mode <NUM>), and a higher trust mode (mode <NUM>). Other security modes are possible, such as a third security mode corresponding to the relying system <NUM> (e.g., when the relying system <NUM> executes within a secured context at client system <NUM>).

As shown, a secure kernel <NUM> executes within the context of mode <NUM>, while a more traditional OS kernel <NUM> executes within the context of mode <NUM>. Other software, such as attested software <NUM>, executes within the context of the OS kernel <NUM>. As an example, in some embodiments the attested software <NUM> is a driver. As shown, the secure kernel <NUM> comprises a memory protection component <NUM>, which operates to apply ROMP to allocations from memory <NUM>. In some embodiments the memory protection component <NUM> accomplishes these protections based, at least in part, on memory page permissions specified in SLAT <NUM> tables managed by the hypervisor <NUM>. In <FIG>, the attested software <NUM> is illustrated as having at least one read-only protected memory allocation (read-only protected memory <NUM>) for use by the attested software. The OS kernel <NUM> is also illustrated as potentially having at least one other read-only protected memory allocation (read-only protected memory <NUM>) for use by the OS kernel <NUM>.

In a particular example, the hypervisor <NUM> implements Virtual Secure Mode (VSM) from Microsoft Corporation, and each hypervisor-created mode corresponds to a different Virtual Trust Level (VTL)-e.g., VTL <NUM> for mode <NUM> and VTL <NUM> for mode <NUM>. In this particular example, an NT kernel (e.g., OS kernel <NUM>) runs in VTL <NUM> (mode <NUM>), while a Secure Kernel runs VTL <NUM> (mode <NUM>). In this particular example, the memory protection component <NUM> implements a software-based memory protection technology, such as KDP, which is usable to protect drivers and software running in the NT kernel (e.g., the OS code itself) against data-driven attacks.

In some implementations, KDP supports two types of protections: static KDP and dynamic KDP. In implementations, static KDP enables software running in kernel mode within VTL <NUM> to statically protect a section of its own image from being tampered with from any other entity in VTL <NUM>. In implementations, dynamic KDP enables kernel-mode software to allocate and release read-only protected memory from a "secure pool" in memory <NUM>, with the memory returned from the pool only permitted to be initialized once (i.e., it is read-only after initializations). In implementations, since memory managed by KDP is verified by the Secure Kernel within VTL <NUM>, and is protected using SLAT tables by the hypervisor, no software running in the NT kernel within VTL <NUM> is able to modify the content of the protected memory.

In embodiments, the attested software <NUM> requests allocation of read-only protected memory <NUM> based on making a call to APIs <NUM> provided by the OS kernel <NUM>, which in turn makes a call to the secure kernel <NUM> through the hypervisor <NUM>.

For example, continuing the KDP example, a software component such as a driver (e.g., attested software <NUM>), which wants a section of its image protected through static KDP can call an API (e.g., APIs <NUM>). Using this API call, the software component specifies an address located inside a data section of its binary image and, optionally, a size of the protected area and/or some flags. When the API call is successful, memory protection component <NUM> operates to ensure that the memory backing the static section (e.g., read-only protected memory <NUM>) becomes read-only for VTL <NUM> (e.g., mode <NUM>) and protected through a SLAT (e.g., SLAT <NUM>). In implementations, unloading a software component that has a protected section is not allowed, and attempting to do results in a fatal error (e.g., a "blue screen" error, a kernel panic, etc.). In some implementations a software component is permitted to specify that it can be unloaded (e.g., via a flag provided in connection with the API call just described). In this case, the kernel (e.g., OS kernel <NUM>) is permitted to unload the target software component; when this happens, the protected section is unprotected and then released.

In another example, and continuing to the KDP example, a software component such as a driver (e.g., attested software <NUM>), which wants a section of its image protected through dynamic KDP allocates and initializes read-only protected memory using services provided by a secure pool, which is managed by the memory protection component <NUM> in the secure kernel <NUM>. In implementations, the software component first creates a secure pool context associated with a tag; then, the software component's future memory allocations are associated with the created secure pool context. In implementations, after the context is created, read-only allocations (e.g., read-only protected memory <NUM>) can be performed through an API call (e.g., APIs <NUM>), and in implementations the software component can specify the size of the allocation and the initial buffer from where to copy the memory. In implementations, memory protection component <NUM> ensures that the returned memory region can't be modified by any entity running in VTL <NUM>. Similar to static KDP, in implementations the memory region can't be freed or modified by default. However, in implementations the software component can specify at allocation time that the allocation is freeable (e.g., using a flag).

In <FIG>, the secure kernel <NUM> comprises an attestation component <NUM> (e.g., a secure enclave). In general, the attestation component <NUM> measures various aspects of the client system <NUM> and submits those measurements as evidence to the attestation service <NUM> and/or to the relying system <NUM>. Upon receipt of the evidence (from the client system <NUM> and/or from the relying system <NUM>), the attestation service <NUM> generates an attestation report that can be used by the relying system <NUM> to validate one or more security properties of the client system <NUM>, and to ensure that the client system <NUM> is a desired (e.g., protected) state. In general, the evidence includes a system security claim comprising boot-time measurements that are loaded into secure hardware (such as the TPM <NUM>). In embodiments, this evidence validates that one or more of the OS kernel <NUM> or the secure kernel <NUM> are in a trusted state.

In accordance with the embodiments herein, these measurements are extended to include one or more properties relating to the attested software <NUM> and/or read-only protected memory <NUM>, and in particular to a state of the read-only protected memory <NUM> as it relates to the attested software <NUM>. Thus, in embodiments, the attestation component <NUM> provides a mechanism to report data that enables the client system <NUM> to perform reliable and secure attestation to the relying system <NUM>, so that the relying system <NUM> can ensure that the client system <NUM> is protecting a given memory region (or set of memory regions) with a secure ROMP technology, such as KDP, TrustZone, SGX, HLAT, etc..

In some embodiments the attestation component <NUM> attests that a particular binary image (from which the attested software <NUM> executes) is protected, such as by binary name and version number, and the relying system <NUM> infers from that attestation that the data it is concerned about is protected. In additional embodiments, however, the attestation component <NUM> attests to additional details to offer additional granularity to help the relying system <NUM> understand what memory is protected. As examples, this may be the memory region address and/or an indication of memory contents (e.g., driver data checksum or hash, read-only protected memory <NUM> checksum or hash).

In some embodiments the relying system <NUM> receives a generic attestation report with properties relating to the attested software <NUM> and makes its own attestation decisions. In some embodiments the relying system <NUM> submits one or more attestation criteria (e.g., information the relying system <NUM> needs to validate in the attestation report, and thus to decide on whether to proceed in trusting the attested software <NUM>) to the attestation service <NUM> as a policy <NUM>. In some embodiments the attestation service <NUM> uses this policy <NUM> to decide what to include in the attestation report and/or if the client system <NUM> is attested.

<FIG> illustrates an example <NUM> of additional details of the attestation component <NUM>. In example <NUM> the attestation component <NUM> comprises a measurement component <NUM> for gathering measurements at client system <NUM> (e.g., boot-time measurements of the TPM <NUM>, properties of the attested software <NUM> and the read-only protected memory <NUM>, etc.), and an evidence generation component <NUM> for generating evidence for submission to the attestation service <NUM>. In some embodiments the attestation component <NUM> also comprises a loading component <NUM> for initiating loading of the attested software <NUM> and/or a remediation component <NUM> that operates to ensure that the attested software <NUM> cannot operate contrary to the attested properties in an attestation report while that attestation report is valid.

<FIG> and <FIG> illustrate examples 300a/300b of timing of communications for attesting to read-only protected memory in a distributed system, including communications between the client system <NUM>, the attestation service <NUM>, and the relying system <NUM>. In example 300a the client system <NUM> communicates with the attestation service <NUM> directly, while in example 300b the client system <NUM> communicates with the attestation service <NUM> via the relying system <NUM>.

In embodiments, the relying system <NUM> optionally communicates an attestation policy <NUM> (e.g., policy <NUM> in <FIG>) to the attestation service <NUM> (i.e., time (i) in both example 300a/300b). As discussed, the attestation policy <NUM> comprises one or more criteria that are requested to be attested by the client system <NUM>. In embodiments this includes information the relying system <NUM> needs to validate in an attestation report produced by the attestation service <NUM>, and to thus decide on whether to proceed in trusting the attested software <NUM> at the client system <NUM>.

In embodiments, the client system <NUM> sends a communications request <NUM> to the relying system <NUM> (i.e., time (<NUM>) in both example 300a/300b). In embodiments the communications request <NUM> is a request for communication of some resource provided by the relying system <NUM>, such as a gaming resource, a decryption key, etc. In embodiments the relying system <NUM> only communicates such a resource to the client system <NUM> if the relying system <NUM> can validate that a particular component at the client system <NUM> (e.g., attested software <NUM>) utilizes memory (e.g., read-only protected memory <NUM>) that is protected by a ROMP technology, such as KDP, TrustZone, SGX, HLAT, and the like. For example, the relying system <NUM> may wish to verify that the attested software <NUM> utilizes read-only protected memory <NUM> to verify the integrity of an anti-cheating driver, a media playback driver, and the like.

In embodiments, the client system <NUM> receives a nonce 303a generated by the relying system <NUM>, and a nonce 303b generated by the attestation service <NUM>. In example 303a, the relying system <NUM> generates nonce 303a, and sends that nonce 303a to the client system <NUM> at time (<NUM>); the client system <NUM> then sends an attestation request <NUM> to the attestation service <NUM> at time (<NUM>), and the attestation service <NUM> replies by generating and sending a nonce 303b to the client system <NUM> at time (<NUM>). In example 303b, on the other hand, the relying system <NUM> sends an attestation request <NUM> to the attestation service <NUM> at time (<NUM>), the attestation service <NUM> replies by generating and sending a nonce 303b to the relying system <NUM> at time (<NUM>), and the relying system <NUM> then sends both nonces 303a/303b to the client system <NUM> at time (<NUM>). In embodiments each nonce is some unpredictable value, such as a randomly (or pseudo-randomly) generated value. As will be appreciated by one of ordinary skill on the art, use of nonce 303a enables the relying system <NUM> to avoid replay attacks, in which a malicious party attempts to present a previously valid attestation report, while use of nonce 303b enables the attestation service <NUM> to avoid replay attacks, in which a malicious party attempts to present old attestation evidence.

At time (<NUM>) in both examples 303a/303b, the client system <NUM> sends attestation evidence <NUM> toward the attestation service <NUM>. In example 300a, the client system <NUM> sends the attestation evidence <NUM> to the attestation service <NUM> directly, while in example 300b the client system <NUM> sends the attestation evidence <NUM> to the relying system <NUM>, and the relying system then forwards the attestation evidence <NUM> to the attestation service <NUM> at time (<NUM>). In either embodiment, the measurement component <NUM> gathers measurements at the client system <NUM>, the evidence generation component <NUM> generates the attestation evidence <NUM> from those measurements, and the OS kernel <NUM> then sends that evidence (over the network <NUM> or via the hypervisor <NUM>) to at least one of the relying system <NUM> or the attestation service <NUM>. In embodiments the attestation evidence <NUM> comprises a key <NUM>, one or more attested properties <NUM>, the nonces 303a/303b, and a system security claim <NUM>.

In embodiments the secure kernel <NUM> generates a private / public key pair (e.g., SKA and PKA), and the key <NUM> is the public key in this pair. In embodiments the attested properties <NUM> comprise one or more of a binary image name (for the binary or binaries corresponding to the <NUM>), a digital signature (e.g., of the binary image) at load time of the binary image, a base offset and size of the read-only protected memory <NUM> and its attributes (e.g., whether the binary image can be unloaded, whether a read-only protected memory section is freeable or non-freeable, etc.), a status of secure ROMP technology (e.g., KDP TrustZone, SGX, HLAT, etc.) protecting an underlying virtual address to guest physical address mapping of the protected physical pages, a list of physical pages in memory <NUM> backing the read-only protected memory <NUM>, a section name and index a driver that has been made read-only, an indication of the content of the read-only protected memory <NUM> (e.g., a checksum or a hash), or a range list of the read-only protected memory <NUM> (which in embodiments allows dynamic content to not be included in the attestation report). In embodiments the system security claim <NUM> is a signed TPM claim, which in implementations comprises a blob of data including the platform configuration registers (PCRs) of the TPM <NUM> and a TCG log (which contains a log of what has been measured). In embodiments the TPM claim is signed by an attestation identity key (AIK) held in the TPM <NUM>.

In embodiments the attestation component <NUM> signs the attestation evidence <NUM>. In some implementations, the attestation evidence <NUM> is signed using a system IDKs (e.g., a VSM master key). In embodiments a public portion of the IDKs is stored in the TPM measurements, which means that the attestation service <NUM> can verify that the IDK is genuine and resides in VTL <NUM>. In embodiments the secure kernel <NUM> returns the attestation evidence <NUM>, together with a certificate issued to the TPM <NUM> by the attestation service <NUM> (e.g., a Microsoft Attestation CA (CERTTPM)), to the OS kernel <NUM>. The OS kernel <NUM> then sends the attestation evidence <NUM> and relevant certificate(s) to the attestation service <NUM>.

Based on receiving the attestation evidence <NUM>, the attestation service <NUM> sends an attestation report <NUM> to at least one of the relying system <NUM> or the client system <NUM>. In example 300a, the attestation service <NUM> sends the attestation report <NUM> to the client system <NUM> at time (<NUM>), and the client system <NUM> sends the attestation report <NUM> to the relying system <NUM> at time (<NUM>). In example 300b, the attestation service <NUM> sends the attestation report <NUM> to the relying system <NUM> at time (<NUM>). Regardless, the relying system <NUM> receives the attestation report <NUM>. For example, based on receiving the attestation evidence <NUM>, the attestation service <NUM> verifies the integrity of the attestation evidence <NUM>. In embodiments the verification includes verifying that the nonce 303b included in the attestation evidence <NUM> matches the nonce 303b generated by the attestation service <NUM> (i.e., at time (<NUM>) in example 300a, or time (<NUM>) in example 300b).

In embodiments the verification includes verifying a certificate chain of the TPM certificate (e.g., CERTTPM) received along with the attestation report <NUM>, which allows the AIK to be treated as trustworthy. In embodiments the verification also includes validating the PCRs and TCG log of the TPM <NUM>, to ensure that the TPM measurements in the system security claim <NUM> are valid and trusted. In embodiments the verification also includes parsing the TCG log, re-creating the same PCR values, and checking that the re-created values from the TCG log corresponds to the received ones; if they match, it means that the TCG log and TPM can be treated as trusted. In embodiments the verification also includes checking that the IDKs can be used to verify the signature of the evidence. In embodiments this process involves validating that the IDKS (public key) is the same as the one measured in the TPM <NUM>, which ensures that the IDKS is the one that was measured at boot time. In embodiments, after this validation, the attestation service <NUM> knows that the public part of the IDKs is authentic, because only the authentic private key part of the IDKs was able to sign the attestation evidence <NUM>. As such, the attestation service <NUM> can infer that the attestation evidence <NUM> is authentic.

Additionally, in embodiments the attestation service <NUM> uses the attestation policy <NUM> (defined by the relying system <NUM>) to accept or reject the attested properties <NUM> contained in the attestation evidence <NUM>. For example, the relying system <NUM> can request rejection of the attestation evidence <NUM> if Secure Boot (or similar technology) is disabled, if the attested software <NUM> uses the read-only protected memory <NUM> on the wrong memory page, etc. If the attestation service <NUM> accepts the attestation evidence <NUM>, then the attestation service <NUM> creates the attestation report <NUM> which includes the properties that it has previously verified (e.g., attested properties <NUM>), potentially with the nonce 303a, and sends the attestation report <NUM> the client system <NUM> (e.g., time (<NUM>) in example 300a) or to the relying system <NUM> (i.e., time (<NUM>) in example 300b). In embodiments the attestation service <NUM> signs the attestation report <NUM> and also sends the certificate used for the signing.

Notably, there could be different embodiments of validation of the nonce 303a. In one embodiment, the attestation service <NUM> includes the nonce 303a in the attestation report <NUM> (i.e., as shown in <FIG>/<FIG>), so that the relying system <NUM> can validate that the nonce 303a matches the nonce it set to the client system <NUM>. In another embodiment, the service attestation service <NUM> validates the nonce 303a nonce as part of its attestation.

Regardless of how the attestation report <NUM> makes it to the relying system <NUM>, the relying system <NUM> verifies the attestation report <NUM>. In particular, the relying system <NUM> potentially verifies that the nonce 303a included in the attestation report <NUM> matches the nonce 303a previously generated by the relying system <NUM>. If the nonces match, the relying system <NUM> determines that the attestation report <NUM> has not been sent from a malicious party as a replay attack. The relying system <NUM> also verifies the signature on the attestation report <NUM>, to verify that it came from the attestation service <NUM>. Once these verifications are successful, the relying system <NUM> uses the attested properties <NUM> to verify that the attested software <NUM> utilizes read-only protected memory <NUM> in a manner desired by the relying system <NUM>. If so, then at time (<NUM>) in both examples 300a/300b the relying system <NUM> engages in a relying communication <NUM> with the client system <NUM>.

As used herein, the relying communication <NUM> is a communication between the relying system <NUM> and the client system <NUM> that the relying system <NUM> would not engage in without having first verified that the attested software <NUM> at the client system <NUM> utilizes read-only protected memory <NUM> in a manner desired by the relying system <NUM>. For example, the relying communication <NUM> may involve sending the client system <NUM> a sensitive resource, such as a decryption key, that the relying system <NUM> only sends to the client system <NUM> after verifying that the attested software <NUM> at the client system <NUM> utilizes read-only protected memory <NUM> in a manner desired by the relying system <NUM>. As another example, the relying system <NUM> may comprise data that (e.g., due to regulatory requirements) must be encrypted-at-rest, and the relying system <NUM> only sends such data to the client system <NUM> after verifying that the attested software <NUM> at the client system <NUM> is utilizing non-freeable, read-only protected memory for a configuration setting, and verifies the configuration setting indicates compliance with the encryption-at-rest requirement. In this way, the client may be assured that the encryption-at-rest configuration setting will not be changed between a time-of-check (e.g., attestation or other verification) and time-of-use (e.g., the time of the relying communication).

As mentioned, the attestation component <NUM> may also include a loading component <NUM>. In embodiments the loading component <NUM> instructs the OS kernel <NUM> to load the attested software <NUM> after receipt of the nonce 303a, if that attested software <NUM> is not already loaded. Once loaded, the attested software <NUM> typically requests allocation of read-only protected memory <NUM> via APIs <NUM>, as described previously.

To provide additional context for the communications of examples 300a/300b, <FIG> illustrates an example flow diagram <NUM> for attesting to read-only protected memory in a distributed system. In flow diagram <NUM> a client system (e.g., client system <NUM>) boots at step <NUM>. As part of the boot-up process boot-time attestation measurements are sealed to the TPM <NUM> (e.g., by the attestation component <NUM>) at step <NUM>. As such, at step <NUM> a secure system is initialized at the client system. Next, while the secure system runs at step <NUM>, a relying party (e.g., relying system <NUM>) generates a nonce (nonce 303a) at step <NUM>, and this nonce is communicated to the client system. For example, step <NUM> may correspond to time (<NUM>) in example 300a or time (<NUM>) in example 300b, in which nonce 303a is sent to the client system by the relying system <NUM>. Additionally, while the secure system runs at step <NUM>, a driver (e.g., attested software <NUM>) loads read-only protected memory (e.g., read-only protected memory <NUM>) at step <NUM>. Step <NUM> may occur prior to step <NUM>, or after step <NUM> (e.g., in which case the loading component <NUM> loads the attested software <NUM>).

Based on receiving the nonce generated in step <NUM>, the client system submits evidence (e.g., attestation evidence <NUM>), along with the nonce, at step <NUM>. This evidence includes properties relating to the driver loaded read-only protected memory in the attestation report. For example, step <NUM> may correspond to time (<NUM>) in examples 300a/300b, in which the client system <NUM> sends the attestation evidence <NUM> towards the attestation service <NUM>, either directly or via the relying system <NUM>. At step <NUM>, the attestation service verifies the evidence and generates an attestation report (e.g., attestation report <NUM>). At step <NUM>, the attestation service and/or the client system submits the attestation report to the relying party. For example, step <NUM> may correspond to time (<NUM>) in examples 300a/300b. At step <NUM>, the relying party validates the properties (including properties relating to the driver loaded read-only protected memory in the attestation report), and the nonce; if verified, the relying party trusts the client at step <NUM>. This trust is demonstrated at time (<NUM>) of examples 300a/300b in which the relying system <NUM> engages in a relying communication <NUM> with the client system <NUM>.

As mentioned, the attestation component <NUM> may also include a remediation component <NUM>. In embodiments the remediation component <NUM> ensures that, when the attestation report <NUM> is valid, the attested software <NUM> cannot operate contrary to the attested properties in the attestation report <NUM>. In particular, it is noted that in embodiments the attestation report <NUM> has a finite validity window during which the client system <NUM> can rely on the attested properties <NUM> regarding a ROMP status the attested software <NUM>. For example, a validity window may be based on a particular time at which an attestation report becomes invalid, a particular post-issuance validity time limit, etc. However, it may be possible for the attested-to ROMP status of the attested software <NUM> to change at the client system <NUM> during this validity window. In one example, the attested software <NUM> could be terminated or reloaded. If reloaded, the reload could potentially change the code executing as attested software <NUM> (e.g., due to a software update, a malicious code modification, etc.), and/or the state of the read-only protected memory <NUM> (e.g., location, size, contents, etc.). In another example (e.g., when using dynamic KDP), the read-only protected memory <NUM> could be freed. If these situations were to occur, the relying system <NUM> could rely on attested properties of the attested software <NUM> and/or the read-only protected memory <NUM> that are no longer valid until the end of validity of the attestation report <NUM>.

Thus, in some scenarios it may be desired for the client system <NUM> to not only attest to the configuration and current protected memory (e.g., read-only protected memory <NUM>), but to also monitor the current state of the client system <NUM> and ensure those attestations remain valid. In embodiments the attestation component <NUM> therefore comprises the remediation component <NUM> which ensures that the attested software <NUM> operates according to the assertions made in the attestation report <NUM> during validity of the attestation report <NUM>. In embodiments the remediation component <NUM> also takes proactive remedial actions at the client system <NUM> if attested-to properties regarding a ROMP status for the attested software <NUM> are no longer valid during the attestation validity period. Thus, these embodiments operate to enforce attestation of read-only protected memory during attestation validity period.

As shown, the remediation component <NUM> comprises a state change detection component <NUM>, which operates to identify a change in a ROMP status for the attested software <NUM> loaded at the client system <NUM>. For example, the state change detection component <NUM> detects when the attested software <NUM> has been reloaded, when the read-only protected memory <NUM> has been freed, etc..

The remediation component <NUM> also comprises an attested property validity determination component <NUM>, which determines whether a validity time period of a corresponding attestation report is expired or unexpired and, if unexpired, whether at least one ROMP attested property for the attested software <NUM> is no longer valid due to the change in the ROMP status.

When there is an unexpired attestation report, changes that can make a ROMP attested property for the attested software <NUM> no longer valid can vary. Some examples of such changes include (i) unloading the attested software <NUM>, (ii) freeing an existing read-only protected section (e.g., the read-only protected memory <NUM>) while allowing additional allocations by the attested software <NUM> without remediation, (iii) a new allocation of a read-only protected memory section by the attested software <NUM> while allowing freeing of the newly allocated section without remediation, (iv) freeing an existing read-only protected section (e.g., the read-only protected memory <NUM>) or freeing a new allocation of a read-only protected memory section, (iv) detection of active malware signals with respect to the attested software <NUM>, (v) a change in the system security state that changes state from what was attested in a system security claim (e.g., system security claim <NUM>), and the like. In embodiments, one or more of these changes are tracked per-virtual machine, per-address space identifier, per-process, or per partition, while in other embodiments these changes are tracked globally.

The remediation component <NUM> also comprises a remedial action component <NUM> which takes one or more remedial actions when the state change detection component <NUM> detects a state change, and when attested property validity determination component <NUM> identifies an unexpired attestation report and an attested property that no longer valid due to the state change. For example, if the ROMP status for the attested software <NUM> changes during an attestation validity period of the attestation report <NUM>, remedial action(s) taken by the remediation component <NUM> may include suspending the attested software <NUM> until the end of the attestation validity period, terminating the attested software <NUM>, blocking communications from the attested software <NUM> (e.g., communications to the relying system <NUM>), notifying the relying system <NUM> of the change in ROMP status, signaling an endpoint protection system (e.g., Windows Defender), obtaining a new attestation report (which would allow resumption or recreation of the processes that relied upon the prior attestation), and the like.

The following discussion now refers to a number of methods and method acts. Although the method acts may be discussed in certain orders, or may be illustrated in a flow chart as occurring in a particular order, no particular ordering is required unless specifically stated, or required because an act is dependent on another act being completed prior to the act being performed.

<FIG> illustrates a flow chart of an example method <NUM> for attesting to read-only protected memory. Method <NUM> will be described with respect to the components and data of distributed system architecture <NUM>. In embodiments instructions for implementing method <NUM> are encoded as computer-executable instructions (e.g., attestation component <NUM>, OS kernel <NUM>) stored on a hardware storage device (e.g., storage <NUM>) that are executable by a processor (e.g., processor <NUM>) to cause a computer system (e.g., client system <NUM>) to perform method <NUM>.

In at least some embodiments, method <NUM> comprises an act <NUM> of sending a communications request to a relying party. In some embodiments act <NUM> comprises sending a communications request to a relying party computer system, the communications requesting access to a resource at the relying party computer system. In an example, and as illustrated at time (<NUM>) in examples 300a/300b, based on a request from the attested software <NUM> the OS kernel <NUM> sends a communications request <NUM> to the relying system <NUM>. In general, the communications request <NUM> comprises a request for communication of some resource provided by the relying system <NUM>, such as a gaming resource, a decryption key, etc. In embodiments the relying system <NUM> will only participate in such a communication if it can verify that it can rely on the security/integrity of the attested software <NUM>. Thus, based on communications request <NUM>, the relying system <NUM> initiates attestation of the attested software <NUM> by generating a nonce 303a and by sending the nonce 303a towards the client system <NUM>. As discussed in connection with time (<NUM>) of example 300a and time (<NUM>) of example 300b, the relying system <NUM> sends the nonce 303a to the client system <NUM>. Technical effects of act <NUM> include the initiation of an attestation of the attested software <NUM> by the relying system <NUM>.

Based on the request in act <NUM>, method <NUM> comprises an act <NUM> of receiving a nonce from the relying party. In some embodiments act <NUM> comprises, based on a communications request, receiving a nonce from the relying party computer system. In an example, the OS kernel <NUM> receives the nonce 303a over the network <NUM>, via the hypervisor <NUM> (e.g., when the relying system <NUM> executes in a secured context), etc. The OS kernel <NUM> may receive the nonce 303a from the relying system <NUM> directly, or via the attestation service <NUM>. While the nonce 303a can comprise a variety of data sizes and types, in embodiments the nonce 303a is some unpredictable value, such as a randomly (or pseudo-randomly) generated value. Technical effects of act <NUM> comprise communication of a secret from the relying system <NUM>, which is later usable by the relying system <NUM> to validate that an attestation report (attestation report <NUM>) is not being reused/replayed by the client system <NUM>.

As discussed, in some embodiments the attestation component <NUM> may also include a loading component <NUM>, which instructs the OS kernel <NUM> to load the attested software <NUM> after receipt of the nonce 303a if that attested software <NUM> is not already loaded. Thus, in some embodiments method <NUM> comprises loading the software component at the computer system after receiving the nonce.

Method <NUM> comprises an act <NUM> of generating attestation evidence, including ROMP attested properties. In some embodiments act <NUM> comprises generating attestation evidence, the attestation evidence comprising: one or more attested properties, including one or more ROMP attested properties for read-only protected memory allocated to a software component loaded at the computer system, the nonce, and a system security claim. In an example, the OS kernel <NUM> conveys the nonce 303a received in act <NUM> to the attestation component <NUM>. The attestation component <NUM>, in turn, uses the measurement component <NUM> to collect the attested properties <NUM> and the system security claim <NUM> (e.g., a TPM claim), and uses the evidence generation component <NUM> to generate attestation evidence <NUM> from that gathered information. As discussed, the attested properties <NUM> comprise information relating to the read-only protected memory <NUM> allocated to the attested software <NUM>. Technical effects of act <NUM> include generation of evidence that can be used as the basis of an attestation report.

In embodiments, the one or more ROMP attested properties for the software component comprise one or more of a name of a binary image corresponding to the software component, a version of the binary image, or a digital signature at load time of the binary image. When included in an attestation report <NUM>, this information enables the relying system <NUM> to verify what code is executing as part of attested software <NUM>.

Additionally, or alternatively, the one or more ROMP attested properties for the software component comprise one or more of a base offset of a read-only protected memory section allocated to the binary image, or a size of the read-only protected memory section. When included in an attestation report <NUM>, this information enables the relying system <NUM> to verify a size and/or location of the read-only protected memory <NUM>.

Additionally, or alternatively, the one or more ROMP attested properties for the software component comprise an attribute of the read-only protected memory section. In embodiments this attribute is an unload ability (e.g., whether the binary image can be unloaded), whether the read-only protected memory section is freeable or non-freeable, etc. When included in an attestation report <NUM>, this information enables the relying system <NUM> to determine whether or not the attested software <NUM> can be unloaded.

Additionally, or alternatively, the one or more ROMP attested properties for the software component comprise a status of a ROMP technology protecting a virtual to physical address mapping (e.g., guest physical addresses). When included in an attestation report <NUM>, this information enables the relying system <NUM> to determine how read-only protected memory <NUM> has been established.

Additionally, or alternatively, the one or more ROMP attested properties for the software component comprise a set of physical pages underlying the read-only protected memory section. When included in an attestation report <NUM>, this information enables the relying system <NUM> to determine what portion(s) of memory <NUM> are used to back read-only protected memory <NUM>.

Additionally, or alternatively, the one or more ROMP attested properties for the software component comprise an indication of content of the read-only protected memory section. In embodiments, this indication is one or more of a checksum, a hash, or a cryptographic hash. When included in an attestation report <NUM>, this information enables the relying system <NUM> to determine content of the read-only protected memory <NUM>.

Additionally, or alternatively, the one or more ROMP attested properties for the software component comprise a range list of the content of the read-only protected memory section. When included in an attestation report <NUM>, this information enables the attestation component <NUM> to exclude dynamic content from being specified in the attestation report.

Method <NUM> comprises an act <NUM> of sending attestation evidence. In some embodiments act <NUM> comprises sending the attestation evidence toward an attestation service computer system. In an example, the OS kernel <NUM> sends the attestation evidence <NUM> over the network <NUM>, or via the hypervisor <NUM> (e.g., when the relying system <NUM> executes in a secured context), towards the attestation service <NUM>. As illustrated at time (<NUM>) of examples 300a/300b, this can include sending the attestation evidence <NUM> to the attestation service <NUM> directly, or through the relying system <NUM>. Technical effects of act <NUM> include relaying information usable by the attestation service <NUM> to verify and attest to the presence/state of read-only protected memory <NUM> as it relates to attested software <NUM>.

After the client system <NUM> sends the attestation evidence <NUM>, the attestation service <NUM> validates the attestation evidence <NUM> as described supra and generates an attestation report <NUM>. At shown in examples 300a/300b, the attestation service <NUM> sends the attestation report <NUM> to client system <NUM> (i.e., time (<NUM>) in example 300a) or to the relying system <NUM> (i.e., time (<NUM>) in example 300b). In embodiments, this attestation report <NUM> includes the one or more ROMP attested properties are included in the attestation report. In some embodiments these ROMP attested properties are included in the attestation report <NUM> based at least on a policy <NUM> sent to the attestation service <NUM> by the relying system <NUM> (e.g., time (i) in examples 300a/300b). Thus, in some embodiments the one or more ROMP attested properties are included in the attestation report based on a validation against an attestation policy defined by the relying party computer system.

In at least some embodiments, method <NUM> comprises an act <NUM> of receiving an attestation report, including the ROMP attested properties. In some embodiments act <NUM> comprises, based at least on sending the attestation evidence, the computer system receiving an attestation report generated by the attestation service computer system, the attestation report comprising the one or more attested properties and the nonce. For instance, example 300a illustrates at time (<NUM>) that the attestation service <NUM> sends the attestation report <NUM> to the client system <NUM> It is noted that in some embodiments act <NUM> is optional. In particular, the attestation service <NUM> may send the attestation report <NUM> directly to the relying system <NUM> (e.g., time (<NUM>) in example 300b), and the relying system <NUM> may not forward the relying system <NUM> to the client system <NUM>.

In at least some embodiments, and when act <NUM> occurs, method <NUM> comprises an act <NUM> of sending the attestation report to the relying party. In some embodiments act <NUM> comprises sending the attestation report to the relying party computer system prior to participating in the relying communication with the relying party computer system. For instance, example 300a illustrates that at time (<NUM>) that the attestation service <NUM> sends the attestation report <NUM> to the client system <NUM>, and that at time (<NUM>) the client system <NUM> sends the attestation report <NUM> to the relying system <NUM>.

Method <NUM> comprises an act <NUM> of participating in a relying communication with the relying party. In some embodiments act <NUM> comprises based on sending the attestation evidence to the attestation service computer system, participating in a relying communication with the relying party computer system. In an example, based on verifying the attestation report <NUM>, including verifying the attested properties <NUM> included in the attestation report <NUM>, the relying system <NUM> determines that it can rely on attested software <NUM> and communicate with client system <NUM>. Thus, on behalf of the attested software <NUM>, the OS kernel <NUM> participates in the relying communication <NUM> with the relying system <NUM> (e.g., over the network <NUM> or via the hypervisor <NUM>). In embodiments, this relying communication <NUM> communicates the resource requested in act <NUM>. Technical effects of act <NUM> include communication of a data resource between an attested software <NUM> that utilizes read-only protected memory <NUM> and a relying system <NUM> that has validated the use of the read-only protected memory <NUM> by the attested software <NUM>.

As discussed, although illustrated separately, in some embodiments the attestation service <NUM> and the relying system <NUM> are combined into the same computer system. As such, in some embodiments of method <NUM> the relying party computer system comprises the attestation service computer system, or the attestation service computer system comprises the relying party computer system. As also discussed, although illustrated as being separated from the client system <NUM> by network <NUM>, in some embodiments the relying system <NUM> executes within a secured context executing at client system <NUM>. Thus, in some embodiments of method <NUM> the relying party computer system executes within a secured context at the computer system.

Accordingly, embodiments described herein attest to read-only protected memory in a distributed system. These embodiments enable generation of an attestation report that certifies that a software component executing at a client system is protected by a ROMP technology. This attestation report comprises attested properties relating to the ROMP status of this software component. A relying system uses this attestation report to verify these properties prior to sending data to the client system and/or prior to relying on data received by the client system. Technical effects of attesting to read-only protected memory in a distributed system include allowing verifiable assurances to be made of system state (e.g., state of a client system), improving the foundational capabilities for secure computing. These assurances, in turn, enable a relying system to objectively gauge its level of trust in the client system, which facilitates secure data communications between the client system and the relying system.

<FIG> illustrates a flow chart of an example method <NUM> for enforcing read-only protected memory during an attestation validity period. Method <NUM> will be described with respect to the components and data of distributed system architecture <NUM>. In embodiments instructions for implementing method <NUM> are encoded as computer-executable instructions (e.g., remediation component <NUM>) stored on a hardware storage device (e.g., storage <NUM>) that are executable by a processor (e.g., processor <NUM>) to cause a computer system (e.g., client system <NUM>) to perform method <NUM>.

As shown, method <NUM> can begin after completion of method <NUM>-which causes generation of an attestation report <NUM> that includes attested properties for one or more of attested software <NUM> and read-only protected memory <NUM>. Thus, in some embodiments method <NUM> can be viewed as an extension to method <NUM>.

Method <NUM> comprises an act <NUM> of identifying a change in ROMP for a software component. In some embodiments act <NUM> comprises identifying a change in a ROMP status for a software component loaded at the computer system. In an example, the remediation component <NUM> detects a change in one, or both of attested software <NUM> and read-only protected memory <NUM>. For instance, a change in attested software <NUM> can include an unloading of attested software <NUM>, a reloading of attested software <NUM>, a change in a binary image corresponding to attested software <NUM>, etc. A change in read-only protected memory <NUM> can include freeing of read-only protected memory <NUM> (e.g., based on use of dynamic KDP, based on reloading of attested software <NUM>, etc.). Technical effects of act <NUM> include detection of a change at client system <NUM> that could render one or more attested properties in the attestation report <NUM> generated in method <NUM> invalid while it is unexpired.

Method <NUM> also comprises an act <NUM> of determining that there is an unexpired validity time period for an attestation report. In some embodiments act <NUM> comprises determining that a validity time period of an attestation report is unexpired, the attestation report comprising one or more attested properties, including one or more ROMP attested properties for read-only protected memory allocated to the software component. In an example, the attested property validity determination component <NUM> identifies attestation report <NUM> corresponding to attested software <NUM> and/or read-only protected memory <NUM>. Technical effects of act <NUM> include detection of an attestation report <NUM> that is relevant to the state change detected in act <NUM>.

Method <NUM> also comprises an act <NUM> of determining that a ROMP attested property for the software component is no longer valid due to the change. In some embodiments act <NUM> comprises determining that at least one ROMP attested property for the software component is no longer valid due to the change in the ROMP status for a software component. In an example, the attested property validity determination component <NUM> identifies one or more of the attested properties <NUM> that are no longer valid due to the state change detected in act <NUM>. Technical effects of act <NUM> include detection of an attested property that, while presently attested to in the attestation report <NUM>, is no longer valid at client system <NUM>.

Method <NUM> also comprises an act <NUM> of initiating a remedial action. In some embodiments act <NUM> comprises, based on the at least one ROMP attested property for the software component being no longer valid, initiating a remedial action to prevent interaction of the software component with a relying party computer system. In an example, the remedial action component <NUM> initiates a remedial action to prevent reliance by the relying system <NUM> on the attested software <NUM>. Technical effects of act <NUM> include preventing the relying system <NUM> from interacting with the attested software <NUM> which the attested software <NUM> is not operating under the attested conditions included in the attestation report <NUM>.

In some embodiments, the remedial action prevents interaction of the software component with the relying system <NUM> until at least expiration of the validity time period. In some embodiments, the remediation prevents the interaction only if the interaction was based on the attestation report identified in act <NUM>. For instance, if a new attestation report is generated with the updated ROMP attested properties, then in some embodiments the expiration of the prior attestation report's validity time period is not relevant. Thus, in examples, the prior attestation report could have been linked to specific encryption keys being used, and the embodiments herein allow revocation, destruction, inaccessibility, etc. of those keys.

In some embodiments the remedial action in act <NUM> comprises suspending one or more processes corresponding to software component. For example, the remedial action component <NUM> suspends one or more processes executing within the context of the OS kernel <NUM>, and that correspond to attested software <NUM>. This has a technical effect of preventing the attested software <NUM> from communicating with the relying system <NUM>, since the attested software <NUM> is no longer actively executing at the client system <NUM>.

In additional, or alternative, embodiments, the remedial action in act <NUM> comprises resuming the one or more processes after expiration of the validity time period. For example, the remedial action component <NUM> resumes one or more processes executing within the context of the OS kernel <NUM>, and that correspond to attested software <NUM>. This has a technical effect of enabling the attested software <NUM> to again operate. However, since the attestation report <NUM> is now expired, the relying system <NUM> is not at risk of relying on an attested property that is no longer valid.

In additional, or alternative, embodiments, the remedial action in act <NUM> terminating one or more processes corresponding to software component. For example, the remedial action component <NUM> terminates one or more processes executing within the context of the OS kernel <NUM>, and that correspond to attested software <NUM>. This has a technical effect of preventing the attested software <NUM> from communicating with the relying system <NUM>, since the attested software <NUM> is no longer present at the client system <NUM>.

In additional, or alternative, embodiments, the remedial action in act <NUM> comprises blocking one or more communications from the software component. For example, the remedial action component <NUM> blocks one or one more network communications or hypercalls generated by (or on behalf of) the attested software <NUM>, and which are destined for the relying system <NUM>. This has a technical effect of preventing the attested software <NUM> from communicating with the relying system <NUM>, since the communications from the attested software <NUM> cannot reach the relying system <NUM>.

In additional, or alternative, embodiments, the remedial action in act <NUM> permitting communications by the software component after expiration of the validity time period. For example, the remedial action component <NUM> permits one or one more network communications or hypercalls generated by (or on behalf of) the attested software <NUM> after a validity period for the attestation report <NUM> has expired. This has a technical effect of enabling the attested software <NUM> to again communicate with the relying system <NUM>. However, since the attestation report <NUM> is now expired, the relying system <NUM> is not at risk of relying on an attested property that is no longer valid.

In additional, or alternative, embodiments, the remedial action in act <NUM> comprises initiating obtaining of a new attestation report. In an example, the remedial action component <NUM> contacts one, or both, of the relying system <NUM> or the attestation service <NUM> in order to obtain a new attestation report. This has a technical effect of proactively reducing a period during which the relying system <NUM> is prevented from interacting with the attested software <NUM>.

In additional, or alternative, embodiments, the remedial action in act <NUM> comprises notifying a relying party computer system. In an example, the remedial action component <NUM> contacts the relying system <NUM> to inform the relying system <NUM> that an attested-to property is no longer valid. This has a technical effect of enabling the relying system <NUM> to cease communications with the client system <NUM>.

Accordingly, additional embodiments described herein take proactive remedial actions at the client system if attested-to properties regarding a ROMP status for a software component are no longer valid during an attestation validity period. Thus, these embodiments operate to enforce attestation of read-only protected memory during attestation validity period. Technical effects of enforcing read-only protected memory during an attestation validity period include promoting computer security by ensuring that a relying party can actually rely on attestations made by a client computer system during the entire validity duration of an attestation report.

Although the subject matter has been described in language specific to structural features and/or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the described features or acts described above, or the order of the acts described above.

Embodiments of the present invention may comprise or utilize a special-purpose or general-purpose computer system that includes computer hardware, such as, for example, one or more processors and system memory, as discussed in greater detail below. Such computer-readable media can be any available media that can be accessed by a general-purpose or special-purpose computer system. Computer-readable media that store computer-executable instructions and/or data structures are computer storage media. Computer-readable media that carry computer-executable instructions and/or data structures are transmission media. Thus, by way of example, and not limitation, embodiments of the invention can comprise at least two distinctly different kinds of computer-readable media: computer storage media and transmission media.

Computer storage media are physical storage media that store computer-executable instructions and/or data structures. Physical storage media include computer hardware, such as RAM, ROM, EEPROM, solid state drives ("SSDs"), flash memory, phase-change memory ("PCM"), optical disk storage, magnetic disk storage or other magnetic storage devices, or any other hardware storage device(s) which can be used to store program code in the form of computer-executable instructions or data structures, which can be accessed and executed by a general-purpose or special-purpose computer system to implement the disclosed functionality of the invention.

Further, upon reaching various computer system components, program code in the form of computer-executable instructions or data structures can be transferred automatically from transmission media to computer storage media (or vice versa). For example, computer-executable instructions or data structures received over a network or data link can be buffered in RAM within a network interface module (e.g., a "NIC"), and then eventually transferred to computer system RAM and/or to less volatile computer storage media at a computer system.

Those skilled in the art will appreciate that the invention may be practiced in network computing environments with many types of computer system configurations, including, personal computers, desktop computers, laptop computers, message processors, hand-held devices, multi-processor systems, microprocessor-based or programmable consumer electronics, network PCs, minicomputers, mainframe computers, mobile telephones, PDAs, tablets, pagers, routers, switches, and the like. As such, in a distributed system environment, a computer system may include a plurality of constituent computer systems.

A cloud computing model can be composed of various characteristics, such as on-demand self-service, broad network access, resource pooling, rapid elasticity, measured service, and so forth. A cloud computing model may also come in the form of various service models such as, for example, Software as a Service ("SaaS"), Platform as a Service ("PaaS"), and Infrastructure as a Service ("laaS"). The cloud computing model may also be deployed using different deployment models such as private cloud, community cloud, public cloud, hybrid cloud, and so forth.

Some embodiments, such as a cloud computing environment, may comprise a system that includes one or more hosts that are each capable of running one or more virtual machines. During operation, virtual machines emulate an operational computing system, supporting an operating system and perhaps one or more other applications as well. In some embodiments each host includes a hypervisor that emulates virtual resources for the virtual machines using physical resources that are abstracted from view of the virtual machines. The hypervisor also provides proper isolation between the virtual machines. Thus, from the perspective of any given virtual machine, the hypervisor provides the illusion that the virtual machine is interfacing with a physical resource, even though the virtual machine only interfaces with the appearance (e.g., a virtual resource) of a physical resource. Examples of physical resources including processing capacity, memory, disk space, network bandwidth, media drives, and so forth.

Claim 1:
A computer system (<NUM>) for enforcing attestation of read-only protected memory during attestation validity period, comprising:
a processor (<NUM>); and
a hardware storage device (<NUM>) that stores computer-executable instructions that are executable by the processor to cause the computer system to at least:
identify (<NUM>) a change in a read-only memory protection, ROMP, status for a software component (<NUM>) loaded at the computer system;
determine (<NUM>) that a validity time period of an attestation report (<NUM>) is unexpired, the attestation report comprising one or more attested properties (<NUM>), including one or more ROMP attested properties for read-only protected memory (<NUM>) allocated to the software component;
determine (<NUM>) that at least one ROMP attested property for the software component is no longer valid due to the change in the ROMP status for a software component; and
based on the at least one ROMP attested property for the software component being no longer valid, initiate (<NUM>) a remedial action to prevent interaction of the software component with a relying party computer system (<NUM>).