Enforcement of the attestation of a read-only protected memory during the attestation validity period

Abstract

Enforce attestation of a read-only protected memory during a validity period of the attestation. The client computer system identifies a change in the state of read-only protected memory protection for a software component loaded on the client computer system. The client computer system then determines that the validity period of the attestation report has not expired. The attestation report includes one or more attested properties, including one or more properties attested by read-only memory protection (ROMP) for the software component. The client computer system also determines that at least one property attested by ROMP for the software component is no longer valid due to the change in the state of read-only protected memory protection for the software component. Based on the fact that at least one property attested by ROMP for the software component is no longer valid, the client computer system initiates a remediation action to prevent the software component from interacting with the dependent computer system.

Description

Technical Field

[0001] The present disclosure relates to systems, methods, and devices for ensuring the use of read-only protected memories. Background Art

[0002] In computing, read-only memories have historically been embodied as data storage devices (i.e., ROMs) that store data that can be read by a computer system but generally cannot be modified by the computer system. Read-only memories can be beneficial for storing immutable data and / or executable code that is protected from corruption and attacks (e.g., rewrite attacks) by malicious parties. At least in part due to these advantages, recent innovations have created hybrid memory scenarios that add in-place protection for various operations (e.g., read, write, and / or execute) on portions of read / write storage devices such as random access memories (RAMs); specifically, certain techniques mark specific portions of writable memory space as read-only after loading, thereby providing protection against corruption and attacks.

[0003] In some cases, read-only memory protection (ROMP) techniques for creating read-only protected memories are implemented using second-level address translation (SLAT) or nested paging managed by a hypervisor. Thus, standard user-mode or kernel-mode software cannot interact with read-only protected memories or corrupt them. In one example, Windows and the security kernel from Microsoft Corporation in Redmond, Washington, support a ROMP technique called Kernel Data Protection (KDP). KDP provides at least two ways to operate on memories protected as read-only by a hypervisor. First, static KDP allows for read-only protection of a portion of a binary image loaded into an operating system (OS) kernel by using SLAT in the hypervisor; when that portion is read-only protected, any attempt to write to the underlying physical memory supporting that portion will cause a system crash by design. Second, dynamic KDP allows any software running in kernel mode to request a block of pre-initialized read-only protected memory; the returned memory can be freed, but any attempt to write to that read-only protected memory will cause a system crash by design. These two techniques can be used alone or in combination to create highly protected data that can resist attack and tampering of the kernel. Other ROMP techniques are implemented in hardware, such as by using hardware-based trusted execution environments (ARM TrustZone, Intel Software Guard Extensions (SGX)), hardware-based page tables (e.g., HLAT), etc.

[0004] With the recent proliferation of security technologies that provide code and control flow integrity (e.g., code integrity and control flow protection in the WINDOWS operating system from Microsoft Corporation), the landscape for attacks is shifting towards data corruption. ROMP technologies (such as KDP and similar technologies) help guard against these attacks by preventing modification of read-only static data variables. SUMMARY OF THE INVENTION

[0005] While ROMP technologies (such as KDP) effectively prevent corruption and attacks at a computer system, there is no solution for determining whether a particular software component (e.g., OS, driver, and / or application) executing at a client computer system (client system) is protected by ROMP technology when a relying party computer system (relying system) communicates with the client system. At least some embodiments described herein address this shortcoming by supporting the generation of a proof report that attests that at least one software component executing at the client system is protected by ROMP technology (such as KDP). In an embodiment, the proof report includes one or more attested properties. In an embodiment, these attested properties include one or more of the following: the name of the binary image for which ROMP is enabled, the binary image version, the digital signature at load time of the binary image, the base offset of the read-only protected memory section assigned to the binary image, the size of the read-only protected memory section, at least one property of the read-only protected memory section (e.g., whether the binary image can be unloaded, whether the read-only protected memory section is releasable or non-releasable, etc.), the status of the secure ROMP technology (such as KDP TrustZone, SGX, HLAT, etc.) that protects the underlying virtual to guest physical address mapping, the set of physical pages underlying the read-only protected memory section, an indication of the content of the read-only protected memory section (e.g., at least one checksum, hash, cryptographic hash, etc.), or a list of ranges of memory content. In an embodiment, the relying system uses the proof report to verify these properties before sending data to the client system and / or before relying on data received by the client system.

[0006] In an example scenario, game software at a relying system (e.g., corresponding to a player, 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) before participating in a multi-player game with the client system. In such a scenario, and in accordance with embodiments herein, the client system uses ROMP techniques (such as KDP) to read-only protect at least a portion of the memory corresponding to the anti-cheat component. The relying system obtains a cryptographically protected attestation report. The attestation report verifies one or more properties of the anti-cheat component, including at least one property related to the enabling of ROMP for the anti-cheat component. The relying system uses the attestation report to verify the integrity of the anti-cheat component based at least on verifying the existence and enabling of ROMP for the anti-cheat component. Based at least on the verification of the integrity of the anti-cheat component, the game software at the relying system participates in a multi-player game with the client system.

[0007] 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 before sending a decryption key to the client system. The client system uses ROMP techniques to read-only protect at least a portion of the memory corresponding to the media player. The relying system obtains a cryptographically protected attestation report and uses the attestation report to verify the integrity of the media player based at least on verifying the existence and enabling of ROMP for the media player, and sends a decryption key to the client system after successful verification.

[0008] In some embodiments, a method, system, and computer program product attest for read-only protected memory. Based on a communication request, a client computer system receives a nonce from a relying party computer system. The client computer system generates attestation evidence. The attestation evidence includes one or more attested properties, the one or more attested properties including one or more ROMP-attested properties for read-only protected memory assigned to a software component loaded at the computer system, the nonce, and a system security statement. The client computer system sends the attestation evidence to 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.

[0009] The technical effects of techniques for attesting to read-only protected memory in a distributed system include allowing verifiable guarantees about the system state (e.g., the state of a client system), enhancing the underlying capabilities for secure computing. These guarantees in turn enable a relying system to objectively measure its level of trust in a client system, which promotes secure data communication between the client system and the relying system.

[0010] In an embodiment, a proof report has a limited validity window during which a relying system can rely on the proven properties regarding the ROMP state of a software component at a client system. For example, the validity window can be based on a specific time when the proof report becomes invalid, a specific post - release validity time limit, etc. However, the proven ROMP state of a software component can change at the client system during this validity window (e.g., based on a driver reload). Thus, the relying system may rely on proven properties that are no longer valid. If the proven properties regarding the ROMP state of a software component are no longer valid during the proof validity period, at least some additional embodiments described herein take proactive remedial actions at the client system. Thus, these embodiments operate to enforce the proof of read - only protected memory during the proof validity period, and this enforcement can be determined by another proven property. For example, if the ROMP state of a software component changes during the proof validity period, the remedial action can include pausing one or more processes corresponding to the software component until the end of the proof validity period, terminating one or more processes corresponding to the software component, blocking one or more communications from the software component, notifying the relying system, invalidating encryption keys, making encryption keys no longer accessible, etc.

[0011] In other embodiments, a method, system, and computer program product enforce the proof of read - only protected memory during a proof validity period. A client computer system identifies a change in the ROMP state of a software component loaded at the computer system. Then, the client computing system determines that the validity time period of a proof report has not expired. The proof report includes one or more proven properties, and the one or more proven properties include one or more ROMP - proven properties for the read - only protected memory assigned to the software component. The client computer system also determines that at least one ROMP - proven property for the software component is no longer valid due to the change in the ROMP state of the software component. Based on the fact that at least one ROMP - proven property for the software component is no longer valid, the client computer system initiates a remedial action to prevent the software component from interacting with a relying - party computer system.

[0012] The technical effect of enforcing the read - only protected memory during the proof validity period includes promoting computer security by ensuring that a relying party can actually rely on the proofs made by the client computer system throughout the validity duration of the proof report.

[0013] Note that any embodiment facilitates the use of RAM for read-only protected memory without the need for a separate pool of physically write-once memory. As will be appreciated, using a separate pool of physically write-once memory increases hardware costs and assumes prior knowledge of how much memory needs to be read-only protected. Thus, facilitating the use of RAM for read-only protected memory reduces physical hardware requirements and increases the flexibility of physical hardware usage.

[0014] This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter. BRIEF DESCRIPTION OF THE DRAWINGS

[0015] To describe the above and other advantages and features of the present invention in the manner in which they are obtained, a more specific description of the present invention briefly described above will be presented with reference to the specific embodiments thereof shown in the drawings. It should be understood that these drawings depict only typical embodiments of the present invention and should not be considered as limiting its scope. The present invention will be described and explained with additional features and details by using the drawings, in which:

[0016] Figure 1 An example computer architecture is shown that facilitates a proof of the presence of ROMP in a distributed computing environment and enforces those protections during a proof validity period;

[0017] Figure 2 An example of a proof component is shown;

[0018] Figure 3A An example timing for proving communication to read-only protected memory in a distributed system is shown, where the client system communicates directly with the proof service;

[0019] Figure 3B An example timing for proving communication to read-only protected storage in a distributed system is shown, where the client system communicates with the proof service via a dependent system;

[0020] Figure 4 An example flowchart for proving read-only protected memory in a distributed system is shown;

[0021] Figure 5 A flowchart of an example method for proving read-only protected memory is shown; and

[0022] Figure 6 A flowchart of an example method for enforcing a proof of read-only protected memory during a proof validity period is shown. Detailed Implementation Modes

[0023] Figure 1 An example distributed system architecture 100 is shown, which facilitates a proof of the existence of ROMP in a distributed computing environment and enforces those protections during a proof validity period. As shown, the distributed system architecture 100 includes a client computer system 101 (client system 101), a proof service computer system 120 (proof service 120), and a relying party computer system 121 (relying system 121), which are communicatively interconnected by one or more networks 122 - at least in Figure 1 - among. Although shown separately, in some embodiments, the proof service 120 and the relying system 121 are combined into the same computer system. Although shown as separate from the client system 101 via the network 122, in some embodiments, the relying system 121 executes within the security context executed at the client system 101.

[0024] In an embodiment, one or more of the client system 101, the proof service 120, and the relying system 121 include computing hardware (e.g., (a) processor(s), memory, disk storage, and a network adapter, etc.). Specifically referring to the client system 101, Figure 1 additional details of the hardware 102 of the client system 101 are shown. As shown, the hardware 102 includes (a) processor(s) 103, memory 104 (e.g., main memory, such as RAM), storage device 105 (e.g., disk storage, ROM, etc.), a network adapter (network 106), and a trusted platform module (TPM 107).

[0025] Generally, the distributed system architecture 100 operates to prove the existence and status of read - only protected memory 116 assigned to a software component (proven software 115) executed at the client system 101. In an embodiment, the read - only protected memory 116 is a block of memory that is allocated from the memory 104 to the software component and to which ROMP is applied. As will be explained in detail below, the proof service 120 generates a proof report based on evidence generated by the client system 101, and the relying system 121 uses the proof report to verify that the proven software 115 appropriately utilizes the read - only protected memory 116 (e.g., based on policy 123). After successful verification, the relying system 121 conducts (a) relying communication with the client system 101.

[0026] By way of example, Figure 1Illustrates the configuration of client system 101. As an example, client system 101 can be used to demonstrate the state of read-only protected memory 116 created using software-based ROMP techniques such as KDP. However, the principles described herein apply to a variety of software- and / or hardware-based ROMP techniques, such as those using KDP, TrustZone, SGX, HLAT, etc.

[0027] In Figure 1 this, the hardware 102 at the client system 101 executes the hypervisor 108. The hypervisor 108 in turn creates at least two security modes (e.g., partitions or virtual machines), including at least one lower trust mode (mode 110) and a higher trust mode (mode 111). Other security modes are possible, such as a third security mode corresponding to the dependent system 121 (e.g., when the dependent system 121 executes within the security context of the client system 101).

[0028] As shown, the secure kernel 117 executes within the context of mode 111, while the more traditional OS kernel 112 executes within the context of mode 110. Other software (such as attested software 115) executes within the context of the OS kernel 112. As an example, in some embodiments, the attested software 115 is a driver. As shown, the secure kernel 117 includes a memory protection component 118 that operates to apply ROMP to allocations from the memory 104. In some embodiments, the memory protection component 118 accomplishes these protections at least in part based on the memory page permissions specified in the SLAT 109 table managed by the hypervisor 108. In Figure 1 this, the attested software 115 is shown as having at least one read-only protected memory allocation (read-only protected memory 116) for use by the attested software. The OS kernel 112 is also shown as potentially having at least one other read-only protected memory allocation (read-only protected memory 114) for use by the OS kernel 112.

[0029] In a specific example, the hypervisor 108 implements the Virtual Secure Mode (VSM) from Microsoft Corporation, and each mode created by the hypervisor corresponds to a different Virtual Trust Level (VTL) - for example, VTL 0 for mode 110 and VTL 1 for mode 111. In this specific example, the NT kernel (e.g., the OS kernel 112) runs at VTL 0 (mode 110), while the secure kernel runs at VTL 1 (mode 111). In this specific example, the memory protection component 118 implements a software-based memory protection technique such as KDP, which can be used to protect drivers and software running in the NT kernel (e.g., the OS code itself) from data-driven attacks.

[0030] In some implementations, KDP supports two types of protection: static KDP and dynamic KDP. In an implementation, static KDP enables software running in kernel mode within VTL 0 to statically protect a portion of its own image from being tampered with by any other entity in VTL 0. In an implementation, dynamic KDP enables kernel-mode software to allocate and release read-only protected memory from a "secure pool" in memory 104, and the memory returned from the pool is only allowed to be initialized once (i.e., it is read-only after initialization). In an implementation, since the memory managed by KDP is verified by a secure kernel within VTL 1 and protected by the hypervisor using the SLAT table, no software running in the NT kernel within VTL 0 can modify the content of the protected memory.

[0031] In an embodiment, the proven software 115 requests the allocation of read-only protected memory 116 based on a call to the API 113 provided by the OS kernel 112, and the OS kernel 112 in turn makes a call to the secure kernel 117 through the hypervisor 108.

[0032] For example, continuing with the KDP example, a software component (such as a driver (e.g., the proven software 115)) that wants to protect a portion of its image through static KDP can call an API (e.g., API 113). Using this API call, the software component specifies an address located within the data portion of its binary image, as well as an optional size of the protected region and / or some flags. When the API call is successful, the memory protection component 118 operates to ensure that the memory supporting the static portion (e.g., the read-only protected memory 116) becomes read-only for VTL 0 (e.g., mode 110) and is protected by the SLAT (e.g., SLAT 109). In an implementation, unloading a software component with a protected portion is not allowed, and attempting to do so will cause a fatal error (e.g., a "blue screen" error, kernel panic, etc.). In some implementations, the software component is allowed to specify that it can be unloaded (e.g., via a flag provided in relation to the API call just described). In this case, the kernel (e.g., the OS kernel 112) is allowed to unload the target software component; when this occurs, the protected portion will no longer be protected and will then be released.

[0033] In another example, and continuing with the KDP example, a software component (such as a driver (e.g., attested software 115)) that wants to protect a portion of its image via dynamic KDP uses services provided by a security pool, which is managed by a memory protection component 118 in the security kernel 117, to allocate and initialize read-only protected memory. In an implementation, the software component first creates a security pool context associated with a label; then, future memory allocations of the software component are associated with the created security pool context. In an implementation, after the context is created, a read-only allocation (e.g., read-only protected memory 116) can be performed via an API call (e.g., API 113), and in an implementation, the software component can specify the size of the allocation and an initial buffer from which to copy the memory. In an implementation, the memory protection component 118 ensures that the returned memory region cannot be modified by any entity running in VTL 0. Similar to static KDP, in an implementation, the default memory region cannot be freed or modified. However, in an implementation, the software component can specify at allocation time that the allocation is freeable (e.g., using a flag).

[0034] In Figure 1 , the security kernel 117 includes an attestation component 119 (e.g., a secure enclave). Generally, the attestation component 119 measures various aspects of the client system 101 and submits those measurements as evidence to an attestation service 120 and / or a relying system 121. When receiving evidence (from the client system 101 and / or from the relying system 121), the attestation service 120 generates an attestation report, which can be used by the relying system 121 to verify one or more security properties of the client system 101 and ensure that the client system 101 is in a desired (e.g., protected) state. Generally, the evidence includes a system security statement, which includes boot-time measurements loaded into secure hardware (such as a TPM 107). In an embodiment, the evidence verifies that one or more of the OS kernel 112 or the security kernel 117 are in a trusted state.

[0035] According to embodiments herein, these measurements are extended to include one or more attributes that are related to the attested software 115 and / or the read-only protected memory 116 and in particular to the state of the read-only protected memory 116 as it relates to the attested software 115. Thus, in an embodiment, the attestation component 119 provides a mechanism for reporting data that enables the client system 101 to perform a reliable and secure attestation to the relying system 121 such that the relying system 121 can ensure that the client system 101 is protecting a given memory region (or set of memory regions) using a secure ROMP technology (such as KDP, TrustZone, SGX, HLAT, etc.).

[0036] In some embodiments, the attestation component 119 attests that a particular binary image (from which the attested software 115 executes), such as by binary name and version number, is protected, and the relying system 121 infers from this attestation that the data it is concerned with is protected. However, in additional embodiments, the attestation component 119 attests additional details to provide additional granularity to assist the relying system 121 in understanding what memory is protected. As an example, this can be an indication of memory region addresses and / or memory contents (e.g., drive data checksums or hashes, read-only protected memory 116 checksums or hashes).

[0037] In some embodiments, the relying system 121 receives a general attestation report having attributes related to the attested software 115 and makes its own attestation decision. In some embodiments, the relying system 121 submits one or more attestation criteria (e.g., information that the relying system 121 needs to verify in the attestation report and thus decide whether to continue to trust the attested software 115) to the attestation service 120 as a policy 123. In some embodiments, the attestation service 120 uses this policy 123 to decide what to include in the attestation report and / or whether the client system 101 is attested.

[0038] Figure 2 Example 200 shows additional details of the attestation component 119. In Example 200, the attestation component 119 includes a measurement component 124 for collecting measurements at the client system 101 (e.g., boot time measurements of the TPM 107, attributes of the attestation software 115 and the read-only protected memory 116, etc.), and an evidence generation component 125 for generating evidence to be submitted to the attestation service 120. In some embodiments, the attestation component 119 further includes a loading component 126 for initiating the loading of the attested software 115 and / or a remediation component 127 that operates to ensure that the attested software 115 cannot operate contrary to the attested attributes in the attestation report while the attestation report is valid.

[0039] Figure 3A and 3B Example 300a / 300b shows the timing of communications for attesting read-only protected memory in a distributed system, including communications between the client system 101, the attestation service 120, and the relying system 121. In Example 300a, the client system 101 communicates directly with the attestation service 120, while in Example 300b, the client system 101 communicates with the attestation service 120 via the relying system 121.

[0040] In an embodiment, the relying system 121 optionally provides an attestation policy 301 (e.g., Figure 1The strategy in [0] is sent to the attestation service 120 (i.e., time (i) in both examples 300a / 300b). As discussed, the attestation strategy 301 includes one or more criteria to be attested by the client system 101 via attestation. In an embodiment, this includes information that the relying system 121 needs to verify in the attestation report generated by the attestation service 120 and thus decide whether to continue to trust the attested software 115 at the client system 101.

[0041] In an embodiment, the client system 101 sends a communication request 302 to the relying system 121 (i.e., time (1) in both examples 300a / 300b). In an embodiment, the communication request 302 is a request for communication of a certain resource (such as a game resource, a decryption key, etc.) provided by the relying system 121. In an embodiment, the relying system 121 transmits such a resource to the client system 101 only if the relying system 121 can verify that a specific component (e.g., the attested software 115) at the client system 101 utilizes a memory (e.g., the read-only protected memory 116) protected by ROMP technologies (such as KDP, TrustZone, SGX, HLAT, etc.). For example, the relying system 121 may wish to verify that the attested software 115 utilizes the read-only protected memory 116 to verify the integrity of an anti-cheat driver, a media playback driver, etc.

[0042] In an embodiment, the client system 101 receives a random number 303a generated by the relying system 121 and a random number 303b generated by the attestation service 120. In example 303a, the relying system 121 generates the random number 303a and sends the random number 303a to the client system 101 at time (2); then, the client system 101 sends an attestation request 310 to the attestation service 120 at time (3), and the attestation service 120 replies by generating the random number 303b at time (4) and sending it to the client system 101. On the other hand, in example 303b, the relying system 121 sends an attestation request 310 to the attestation service 120 at time (2), the attestation service 120 replies by generating the random number 303b at time (3) and sending it to the relying system 121, and the relying system 121 then sends both the random numbers 303a / 303b to the client system 101 at time (4). In an embodiment, each random number is some unpredictable value, such as a randomly (or pseudo-randomly) generated value. As will be understood by those of ordinary skill in the art, the use of the random number 303a enables the relying system 121 to avoid replay attacks, where a malicious party attempts to present a previously valid attestation report, while the use of the random number 303b enables the attestation service 120 to avoid replay attacks, where a malicious party attempts to present old attestation evidence.

[0043] At time (5) in both Examples 303a / 303b, the client system 101 sends attestation evidence 304 to the attestation service 120. In Example 300a, the client system 101 sends the attestation evidence 304 directly to the attestation service 120, while in Example 300b, the client system 101 sends the attestation evidence 304 to the relying system 121, and the relying system then forwards the attestation evidence 304 to the attestation service 120 at time (6). In any embodiment, the measurement component 124 collects measurements at the client system 101, the evidence generation component 125 generates the attestation evidence 304 from those measurements, and the OS kernel 112 then sends the evidence (over the network 122 or via the hypervisor 108) to at least one of the relying system 121 or the attestation service 120. In an embodiment, the attestation evidence 304 includes a key 307, one or more attested attributes 308, a nonce 303a / 303b, and a system security statement 309.

[0044] In an embodiment, the security kernel 117 generates a private key / public key pair (e.g., SK A and PK A ), and the key 307 is the public key in the pair. In an embodiment, the attested attributes 308 include one or more of the following: binary image name (for one or more binary files corresponding to 115), digital signature at the time of loading of the binary image (e.g., of the binary image), base offset and size of the read-only protected memory 116 and its properties (e.g., whether the binary image can be unloaded, whether the read-only protected memory portion is releaseable or non-releaseable, etc.), status of the secure ROMP technology (e.g., KDP TrustZone, SGX, HLAT, etc.) that protects the underlying virtual address to guest physical address mapping of the protected physical pages, list of physical pages in the memory 104 that support the read-only protected memory 116, section name and index of the drive that has been set to read-only, indication of the content of the read-only protected memory 116 (e.g., checksum or hash), or list of ranges of the read-only protected memory 116 (in an embodiment allowing dynamic content not to be included in the attestation report). In an embodiment, the system security statement 309 is a signed TPM statement, which in implementation includes a large object (blob) of data that includes the platform configuration register (PCR) of the TPM 107 and the TCG log (which contains a log of the measured content). In an embodiment, the TPM statement is signed by the attestation identity key (A IK ) stored in the TPM 107.

[0045] In an embodiment, the attestation component 119 signs the attestation evidence 304. In some implementations, the attestation evidence 304 uses the system IDK s(e.g., the VSM master key) is signed. In an embodiment, the public portion of IDK s is stored in the TPM measurement, which means that the attestation service 120 can verify that the IDK is authentic and resides in the VTL 1. In an embodiment, the secure kernel 117 returns the attestation evidence 304 to the OS kernel 112 together with the certificate issued by the attestation service 120 (e.g., Microsoft Attestation CA (CERT TPM )) to the TPM 107. The OS kernel 112 then sends the attestation evidence 304 and the relevant certificate(s) to the attestation service 120.

[0046] Based on the received attestation evidence 304, the attestation service 120 sends an attestation report 305 to at least one of the relying system 121 or the client system 101. In example 300a, the attestation service 120 sends the attestation report 305 to the client system 101 at time (6), and the client system 101 sends the attestation report 305 to the relying system 121 at time (7). In example 300b, the attestation service 120 sends the attestation report 305 to the relying system 121 at time (7). In any case, the relying system 121 receives the attestation report 305. For example, based on the received attestation evidence 304, the attestation service 120 verifies the integrity of the attestation evidence 304. In an embodiment, the verification includes verifying that the nonce 303b included in the attestation evidence 304 matches the nonce 303b generated by the attestation service 120 (i.e., at time (4) in example 300a, or at time (3) in example 300b).

[0047] In an embodiment, the verification includes verifying the certificate chain of the TPM certificate (e.g., CERT TPM ) received together with the attestation report 305, which allows A IK to be considered trustworthy. In an embodiment, the verification also includes verifying the PCR and TCG logs of the TPM 107 to ensure that the TPM measurements in the system security statement 309 are valid and trustworthy. In an embodiment, the verification also includes parsing the TCG log, recreating the same PCR values, and checking that the recreated values from the TCG log correspond to the received values; if they match, it means that the TCG log and the TPM can be considered trustworthy. In an embodiment, the verification also includes checking that IDK s can be used to verify the signature of the evidence. In an embodiment, the process involves verifying that IDK s (public key) is the same as the IDK measured in the TPM 107, which ensures that IDK s is the IDK measured at boot time s . In an embodiment, after this verification, the attestation service 120 knows that the public portion of IDK s is authentic because only IDKs The true private key part can sign the proof evidence 304. Therefore, the proof service 120 can infer that the proof evidence 304 is authentic.

[0048] In addition, in an embodiment, the proof service 120 uses a proof strategy 301 (defined by the relying system 121) to accept or reject the attested attributes 308 included in the proof evidence 304. For example, if secure boot (or a similar technique) is disabled, if the attested software 115 uses the read-only protected memory 116 on the wrong memory page, etc., the relying system 121 can request to reject the proof evidence 304. If the proof service 120 accepts the proof evidence 304, the proof service 120 creates a proof report 305 and sends the proof report 305 to the client system 101 (e.g., the time (6) in Example 300a) or to the relying system 121 (i.e., the time (7) in Example 300b). The proof report 305 includes the attributes previously verified by the proof service 120 (e.g., the attested attributes 308) and may have a nonce 303a. In an embodiment, the proof service 120 signs the proof report 305 and also sends the certificate used for the signature.

[0049] It is worth noting that there can be different embodiments for the verification of the nonce 303a. In one embodiment, the proof service 120 includes the nonce 303a in the proof report 305 (i.e., as shown in Figure 3A / 3B), such that the relying system 121 can verify that the nonce 303a matches the nonce it set for the client system 101. In another embodiment, the proof service 120 verifies the nonce 303a as part of its proof.

[0050] Regardless of how the proof report 305 reaches the relying system 121, the relying system 121 verifies the proof report 305. Specifically, the relying system 121 potentially verifies that the nonce 303a included in the proof report 305 matches the nonce 303a previously generated by the relying system 121. If the nonces match, the relying system 121 determines that the proof report 305 has not been sent from a malicious party as a replay attack. The relying system 121 also verifies the signature on the proof report 305 to verify that it comes from the proof service 120. Once these verifications are successful, the relying system 121 uses the attested attributes 308 to verify that the attested software 115 utilizes the read-only protected memory 116 in the manner expected by the relying system 121. If so, at time (8) in both Example 300a / 300b, the relying system 121 participates in the relying communication 306 with the client system 101.

[0051] As used herein, a dependency communication 306 is a communication between a dependency system 121 and a client system 101 where the dependency system 121 will not participate in the communication without first verifying that the proven software 115 at the client system 101 utilizes the read-only protected memory 116 in a manner expected by the dependency system 121. For example, a dependency communication 306 can involve sending a sensitive resource (such as a decryption key) to the client system 101, and the dependency system 121 will only send it to the client system 101 after verifying that the proven software 115 at the client system 101 utilizes the read-only protected memory 116 in a manner expected by the dependency system 121. As another example, the dependency system 121 can include data (e.g., due to regulatory requirements) that must be encrypted at rest, and the dependency system 121 will only send such data to the client system 101 after verifying that the proven software 115 at the client system 101 is utilizing the non-releasable read-only protected memory for configuration settings and verifying that the configuration settings indicate compliance with the at-rest encryption requirements. In this way, the client can be confident that the at-rest encryption configuration settings will not be changed between the time of inspection (e.g., attestation or other verification) and the time of use (e.g., the time of the dependency communication).

[0052] As mentioned, the attestation component 119 can also include a loading component 126. In an embodiment, if the proven software 115 has not been loaded, the loading component 126 instructs the OS kernel 112 to load the proven software 115 after receipt of the random number 303a. Once loaded, the proven software 115 typically requests allocation of the read-only protected memory 116 via the API 113, as previously described.

[0053] To provide additional context for the communication of Examples 300a / 300b, Figure 4Shows an example flowchart 400 for demonstrating read-only protected memory in a distributed system. In flowchart 400, a client system (e.g., client system 101) starts at step 401. As part of the startup process, at step 402, a startup time proof measurement is sealed to the TPM 107 (e.g., by the attestation component 119). Thus, at step 403, the security system is initialized at the client system. Next, when the security system is running at step 404, a relying party (e.g., relying system 121) generates a random number (random number 303a) at step 406, and this random number is transmitted to the client system. For example, step 406 may correspond to time (2) in example 300a or time (4) in example 300b, where the random number 303a is sent from the relying system 121 to the client system. Additionally, while the security system is running at step 404, a driver (e.g., attested software 115) loads the read-only protected memory (e.g., read-only protected memory 116) at step 405. Step 405 may occur before step 406, or after step 406 (e.g., in this case, the loading component 126 loads the attested software 115).

[0054] Based on the received random number generated in step 406, the client system submits evidence (e.g., attestation evidence 304) together with the random number at step 407. This evidence includes attributes related to the read-only protected memory loaded by the driver in the attestation report. For example, step 407 may correspond to time (5) in example 300a / 300b, where the client system 101 sends the attestation evidence 304 directly or via the relying system 121 to the attestation service 120. At step 408, the attestation service verifies the evidence and generates an attestation report (e.g., attestation report 305). At step 409, the attestation service and / or the client system submit the attestation report to the relying party. For example, step 409 may correspond to time (7) in example 300a / 300b. At step 410, the relying party verifies the attributes (including the attributes related to the read-only protected memory loaded by the driver in the attestation report) and the random number; if verified, at step 411, the relying party trusts the client. This trust is demonstrated at time (8) in example 300a / 300b, where the relying system 121 participates in the relying communication 306 with the client system 101.

[0055] As mentioned, the attestation component 119 may also include a remediation component 127. In an embodiment, the remediation component 127 ensures that when the attestation report 305 is valid, the attested software 115 cannot operate contrary to the attested properties in the attestation report 305. Specifically, it should be noted that in an embodiment, the attestation report 305 has a finite validity window during which the client system 101 can rely on the attested properties 308 regarding the ROMP state of the attested software 115. For example, the validity window can be based on a specific time at which the attestation report becomes invalid, a specific post-release validity time limit, etc. However, during this validity window, it is possible for the attested ROMP state of the attested software 115 to change at the client system 101. In one example, the attested software 115 can be terminated or reloaded. If reloaded, the reload may potentially change the code executed as the attested software 115 (e.g., due to software updates, malicious code modifications, etc.) and / or the state of the read-only protected memory 116 (e.g., location, size, content, etc.). In another example (e.g., when using dynamic KDP), the read-only protected memory 116 can be released. If these situations occur, the relying system 121 may rely on the attested properties of the attested software 115 and / or the read-only protected memory 116, which are no longer valid before the end of the validity of the attestation report 305.

[0056] Thus, in some scenarios, it may be desirable for the client system 101 to not only attest the configuration and the current protected memory (e.g., the read-only protected memory 116), but also monitor the current state of the client system 101 and ensure that those attestations remain valid. Accordingly, in an embodiment, the attestation component 119 includes a remediation component 127 that ensures the attested software 115 operates according to the assertions made in the attestation report 305 during the validity of the attestation report 305. In an embodiment, if the attested properties regarding the ROMP state of the attested software 115 are no longer valid during the attestation validity period, the remediation component 127 also takes proactive remediation actions at the client system 101. Thus, these embodiments operate to enforce the attestation of the read-only protected memory during the attestation validity period.

[0057] As shown, the remediation component 127 includes a state change detection component 128 that operates to identify changes to the ROMP state of the attested software 115 loaded at the client system 101. For example, the state change detection component 128 detects when the attested software 115 has been reloaded, when the read-only protected memory 116 has been released, etc.

[0058] The remediation component 127 also includes a proven property validity determination component 129 that determines whether the validity period of the corresponding proof report has expired or not, and if not, determines whether at least one ROMP-proven property of the proven software 115 is no longer valid due to a change in the ROMP state.

[0059] When there is an unexpired proof report, changes that can render ROMP-proven properties of the proven software 115 no longer valid can vary. Some examples of such changes include (i) uninstalling the proven software 115, (ii) releasing an existing read-only protected portion (e.g., read-only protected memory 116), while allowing additional allocations by the proven software 115 without remediation, (iii) new allocation of a read-only protected memory portion by the proven software 115, while allowing the release of the newly allocated portion without remediation, (iv) releasing an existing read-only protected portion (e.g., read-only protected memory 116) or releasing a new allocation of a read-only protected memory portion, (iv) detection of an active malware signal associated with the proven software 115, (v) a change in the system security state that changes the proven state in the system security statement (e.g., system security statement 309), etc. In an embodiment, 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.

[0060] The remediation component 127 also includes a remediation action component 130 that takes one or more remediation actions when the state change detection component 128 detects a state change, and when the proven property validity determination component 129 identifies an unexpired proof report and a proven property that is no longer valid due to the state change. For example, if the ROMP state for the proven software 115 changes during the proof validity period of the proof report 305, the (multiple) remediation actions taken by the remediation component 127 can include pausing the proven software 115 until the end of the proof validity period, terminating the proven software 115, blocking communication from the proven software 115 (e.g., communication to the dependent system 121), notifying the dependent system 121 of the change in the ROMP state, sending a signal to an endpoint protection system (e.g., Windows Defender), obtaining a new proof report (which will allow the restoration or recreation of a process that depends on the previous proof), etc.

[0061] The following discussion now refers to some methods and method acts. Although method acts may be discussed in some order, or may be shown in a flowchart as occurring in a particular order, no particular order is required unless specifically stated, or required because one act depends on another act being completed before that act is performed.

[0062] Figure 5 A flowchart of an example method 500 for attesting a read-only protected memory is shown. Method 500 will be described with respect to the components and data of the distributed system architecture 100. In an embodiment, the instructions for implementing method 500 are encoded as computer-executable instructions (e.g., attestation component 119, OS kernel 112) stored on a hardware storage device (e.g., storage device 105), the computer-executable instructions being executable by a processor (e.g., processor 103) to cause a computer system (e.g., client system 101) to perform method 500.

[0063] In at least some embodiments, method 500 includes an act 501 of sending a communication request to a relying party. In some embodiments, act 501 includes sending a communication request to a relying party computer system that accesses a resource at the relying party computer system. In an example, and as shown at time (1) in examples 300a / 300b, based on a request from the attested software 115, the OS kernel 112 sends a communication request 302 to the relying system 121. Generally, the communication request 302 includes a request for communication for a certain resource (such as a game resource, decryption key, etc.) provided by the relying system 121. In an embodiment, the relying system 121 will only participate in such communication if it can verify that it can rely on the security / integrity of the attested software 115. Thus, based on the communication request 302, the relying system 121 initiates an attestation of the attested software 115 by generating a random number 303a and by sending the random number 303a to the client system 101. As discussed in connection with time (2) of example 300a and time (4) of example 300b, the relying system 121 sends the random number 303a to the client system 101. The technical effect of act 501 includes the attestation of the attested software 115 initiated by the relying system 121.

[0064] Based on the request in action 501, method 500 includes action 502 of receiving a random number from a relying party. In some embodiments, action 502 includes receiving a random number from a relying party computer system based on a communication request. In an example, the OS kernel 112 receives the random number 303a via the hypervisor 108 over the network 122 (e.g., when the relying system 121 is executing in a secure context), etc. The OS kernel 112 may receive the random number 303a directly from the relying system 121 or via the attestation service 120. Although the random number 303a may include various data sizes and types, in an embodiment, the random number 303a is some unpredictable value, such as a randomly (or pseudo-randomly) generated value. The technical effect of action 502 includes confidential communication from the relying system 121, which can subsequently be used by the relying system 121 to verify that the attestation report (attestation report 305) has not been reused / replayed by the client system 101.

[0065] As discussed, in some embodiments, the attestation component 119 may further include a loading component 126 that, if the attested software 115 has not been loaded, instructs the OS kernel 112 to load the attested software 115 after the receipt of the random number 303a. Thus, in some embodiments, method 500 includes loading a software component at a computer system after receiving a random number.

[0066] Method 500 includes action 503 of generating attestation evidence, including properties attested by ROMP. In some embodiments, action 503 includes generating attestation evidence that includes: one or more attested properties, including one or more properties attested by ROMP for read-only protected memory assigned to a software component loaded on the computer system, a random number, and a system security statement. In an example, the OS kernel 112 conveys the random number 303a received in action 502 to the attestation component 119. The attestation component 119 then uses the measurement component 124 to collect the attested properties 308 and the system security statement 309 (e.g., TPM statement), and uses the evidence generation component 125 to generate the attestation evidence 304 from the collected information. As discussed, the attested properties 308 include information related to the read-only protected memory 116 assigned to the attested software 115. The technical effect of action 503 includes the generation of evidence that can be used as a basis for an attestation report.

[0067] In an embodiment, one or more properties attested by ROMP for a software component include one or more of the following: the name of the binary image corresponding to the software component, the version of the binary image, or the digital signature at the time of loading of the binary image. When included in the attestation report 305, this information enables the relying system 121 to verify what code is being executed as part of the attested software 115.

[0068] Additionally or alternatively, one or more ROMP-certified properties for a software component include one or more of the following: a base offset of a read-only protected memory portion assigned to a binary image, or a size of the read-only protected memory portion. When included in the attestation report 305, this information enables the relying system 121 to verify the size and / or location of the read-only protected memory 116.

[0069] Additionally or alternatively, one or more ROMP-certified properties for a software component include the nature of the read-only protected memory portion. In an embodiment, the nature is an offload ability (e.g., whether the binary image can be offloaded), whether the read-only protected memory portion is releasable or non-releasable, etc. When included in the attestation report 305, this information enables the relying system 121 to determine whether the attested software 115 can be offloaded.

[0070] Additionally or alternatively, one or more ROMP-certified properties for a software component include the state of the ROMP technique that protects the virtual-to-physical address mapping (e.g., the guest physical address). When included in the attestation report 305, this information enables the relying system 121 to determine how the read-only protected memory 116 has been established.

[0071] Additionally or alternatively, one or more ROMP-certified properties for a software component include a set of physical pages underlying the read-only protected memory portion. When included in the attestation report 305, this information enables the relying system 121 to determine which part(s) of the memory 104 are used to support the read-only protected memory 116.

[0072] Additionally or alternatively, one or more ROMP-certified properties for a software component include an indication of the content of the read-only protected memory portion. In an embodiment, the indication is one or more of a checksum, a hash, or a cryptographic hash. When included in the attestation report 305, this information enables the relying system 121 to determine the content of the read-only protected memory 116.

[0073] Additionally or alternatively, one or more ROMP-certified properties for a software component include a list of ranges of the content of the read-only protected memory portion. When included in the attestation report 305, this information enables the attestation component 119 to exclude dynamic content from being specified in the attestation report.

[0074] Method 500 includes an action 504 of sending attestation evidence. In some embodiments, action 503 includes sending the attestation evidence to an attestation service computer system. In an example, the OS kernel 112 sends the attestation evidence 304 to the attestation service 120 via the network 122 or via the hypervisor 108 (e.g., when the dependent system 121 executes in a secure context). As shown at time (5) of example 300a / 300b, this can include sending the attestation evidence 304 directly or via the dependent system 121 to the attestation service 120. The technical effect of action 504 includes relaying information usable by the attestation service 120 to verify and attest to the existence / status of the read-only protected memory 116 as it relates to the attested software 115.

[0075] After the client system 101 sends the attestation evidence 304, the attestation service 120 verifies the attestation evidence 304 as described above and generates an attestation report 305. As shown in example 300a / 300b, the attestation service 120 sends the attestation report 305 to the client system 101 (i.e., at time (6) in example 300a) or to the dependent system 121 (i.e., at time (7) in example 300b). In an embodiment, the attestation report 305 includes one or more ROMP-attested attributes included in the attestation report. In some embodiments, these ROMP-attested attributes are included in the attestation report 305 based at least on a policy 123 sent to the attestation service 120 by the dependent system 121 (e.g., at time (i) in example 300a / 300b). Thus, in some embodiments, one or more ROMP-attested attributes are included in the attestation report based on a verification against an attestation policy defined for the dependent party computer system.

[0076] In at least some embodiments, method 500 includes an action 505 of receiving an attestation report that includes ROMP-attested attributes. In some embodiments, action 505 includes the computer system receiving, at least based on sending the attestation evidence, an attestation report generated by the attestation service computer system that includes one or more attested attributes and a nonce. For example, example 300a shows the attestation service 120 sending the attestation report 305 to the client system 101 at time (6). Note that in some embodiments, action 505 is optional. Specifically, the attestation service 120 can send the attestation report 305 directly to the dependent system 121 (e.g., at time (7) in example 300b), and the dependent system 121 may not forward the dependent system 121 to the client system 101.

[0077] In at least some embodiments, and when action 505 occurs, method 500 includes an action 506 of sending an attestation report to a relying party. In some embodiments, action 506 includes sending an attestation report to a relying party computer system prior to participating in a relying communication with the relying party computer system. For example, example 300a shows that at time (6), the attestation service 120 sends an attestation report 305 to the client system 101, and at time (7), the client system 101 sends the attestation report 305 to the relying system 121.

[0078] Method 500 includes an action 507 of participating in a relying communication with a relying party. In some embodiments, action 507 includes participating in a relying communication with a relying party computer system based on sending attestation evidence to an attestation service computer system. In the example, based on verifying the attestation report 305, including verifying the attested attributes 308 included in the attestation report 305, the relying system 121 determines that it can rely on the attested software 115 and communicate with the client system 101. Thus, on behalf of the attested software 115, the OS kernel 112 participates in a relying communication 306 with the relying system 121 (e.g., via network 122 or via hypervisor 108). In an embodiment, this relying communication 306 transfers the resources requested in action 501. The technical effect of action 507 includes communication of data resources between the attested software 115 that utilizes the read-only protected memory 116 and the relying system 121 that has verified the use of the read-only protected memory 116 by the attested software 115.

[0079] As discussed, although shown separately, in some embodiments, the attestation service 120 and the relying system 121 are combined into the same computer system. Thus, in some embodiments of method 500, the relying party computer system includes the attestation service computer system, or the attestation service computer system includes the relying party computer system. Also as discussed, although shown as separate from the client system 101 via network 122, in some embodiments, the relying party computer system 121 executes within the security context executed at the client system 101. Thus, in some embodiments of method 500, the relying party computer system executes within the security context of the computer system.

[0080] Accordingly, the embodiments described herein demonstrate a read-only protected memory in a distributed system. These embodiments enable the generation of a proof report that attests that software components executed at a client system are protected by ROMP technology. The proof report includes attested properties related to the ROMP state of the software component. A relying system uses the proof report to verify these properties before sending data to the client system and / or before relying on data received by the client system. The technical effect of demonstrating a read-only protected memory in a distributed system includes allowing verifiable guarantees to be made about the state of the system (e.g., the state of the client system), thereby enhancing the underlying capabilities for secure computing. These guarantees in turn enable the relying system to objectively measure the level of its trust in the client system, which facilitates secure data communication between the client system and the relying system.

[0081] Figure 6 A flowchart of an example method 600 for enforcing a read-only protected memory during a proof validity period is shown. Method 600 will be described with respect to the components and data of the distributed system architecture 100. In an embodiment, the instructions for implementing method 600 are encoded as computer-executable instructions (e.g., remediation component 127) stored on a hardware storage device (e.g., storage device 105), which are executable by a processor (e.g., processor 103) to cause a computer system (e.g., client system 101) to execute method 600.

[0082] As shown, method 600 may begin after method 500 is completed - which results in the generation of a proof report 305 that includes attested properties for one or more of the attested software 115 and the read-only protected memory 116. Thus, in some embodiments, method 600 may be considered an extension of method 500.

[0083] Method 600 includes an action 601 of identifying a change to the ROMP for a software component. In some embodiments, action 601 includes identifying a change to the ROMP state for a software component loaded at a computer system. In an example, the remediation component 127 detects a change in one or both of the attested software 115 and the read-only protected memory 116. For example, a change to the attested software 115 may include uninstallation of the attested software 115, reloading of the attested software 115, a change to the binary image corresponding to the attested software 115, etc. A change to the read-only protected memory 116 may include release of the read-only protected memory 116 (e.g., based on the use of dynamic KDP, reloading of the attested software 115, etc.). The technical effect of action 601 includes detection of a change at the client system 101 that may invalidate one or more attested properties in the attestation report 305 generated in method 500 while they are not yet expired.

[0084] Method 600 further includes an action 602 of determining that there is an unexpired validity period for an attestation report. In some embodiments, action 602 includes determining that the validity period of an attestation report, which includes one or more attested properties, where the one or more attested properties include one or more ROMP-attested properties for a read-only protected memory assigned to a software component, has not expired. In an example, the attested property validity determination component 129 identifies the attestation report 305 corresponding to the attested software 115 and / or the read-only protected memory 116. The technical effect of action 602 includes detection of the attestation report 305 related to the state change detected in action 601.

[0085] Method 600 further includes an action 603 of determining that an ROMP-attested property for a software component is no longer valid due to the change. In some embodiments, action 603 includes determining that at least one ROMP-attested property for a software component is no longer valid due to a change to the ROMP state for the software component. In an example, the attested property validity determination component 129 identifies one or more attested properties 308 that are no longer valid due to the state change detected in action 601. The technical effect of action 603 includes detection of attested properties that are no longer valid at the client system 101 while being attested in the current attestation report 305.

[0086] Method 600 further includes an action 604 to initiate a remediation action. In some embodiments, action 604 includes initiating a remediation action to prevent interaction of the software component with the dependent party computer system based on at least one ROMProven property of the software component no longer being valid. In an example, the remediation action component 130 initiates a remediation action to prevent the dependent system 121 from depending on the proven software 115. The technical effect of action 604 includes preventing the dependent system 121 from interacting with the proven software 115, where the proven software 115 is not operating under the proven conditions included in the proof report 305.

[0087] In some embodiments, the remediation action prevents interaction of the software component with the dependent system 121, at least until the expiration of the validity period. In some embodiments, the remediation prevents interaction only if the interaction is based on the proof report identified in action 602. For example, if a new proof report is generated with updated ROMProven properties, in some embodiments, the expiration of the validity period of the previous proof report is irrelevant. Thus, in an example, the previous proof report may have been linked to a specific encryption key being used, and the embodiments herein allow for the revocation, destruction, inaccessibility, etc. of those keys.

[0088] In some embodiments, the remediation action in action 604 includes pausing one or more processes corresponding to the software component. For example, the remediation action component 130 pauses one or more processes that are executing within the context of the OS kernel 112 and that correspond to the proven software 115. This has the technical effect of preventing the proven software 115 from communicating with the dependent system 121 because the proven software 115 is no longer actively executing at the client system 101.

[0089] In additional or alternative embodiments, the remediation action in action 604 includes resuming one or more processes after the expiration of the validity period. For example, the remediation action component 130 resumes one or more processes that are executing within the context of the OS kernel 112 and that correspond to the proven software 115. This has the technical effect of enabling the proven software 115 to operate again. However, since the proof report 305 has now expired, there is no risk that the dependent system 121 depends on proven properties that are no longer valid.

[0090] In additional or alternative embodiments, the remediation action in action 604 terminates one or more processes corresponding to the software component. For example, the remediation action component 130 terminates one or more processes that are executing within the context of the OS kernel 112 and that correspond to the proven software 115. This has the technical effect of preventing the proven software 115 from communicating with the dependent system 121 because the proven software 115 no longer exists at the client system 101.

[0091] In additional or alternative embodiments, the remedial action in action 604 includes blocking one or more communications from a software component. For example, the remedial action component 130 blocks one or more network communications or hypercalls generated by (or on behalf of) the attested software 115 and destined for the dependent system 121. This has the technical effect of preventing the attested software 115 from communicating with the dependent system 121, because communications from the attested software 115 cannot reach the dependent system 121.

[0092] In additional or alternative embodiments, the remedial action in action 604 allows communications by a software component after the expiration of the validity period. For example, the remedial action component 130 allows one or more network communications or hypercalls generated by (or on behalf of) the attested software 115 after the validity period for the attestation report 305 has expired. This has the technical effect of enabling the attested software 115 to communicate with the dependent system 121 again. However, since the attestation report 305 is now expired, there is no risk that the dependent system 121 depends on attested attributes that are no longer valid.

[0093] In additional or alternative embodiments, the remedial action in action 604 includes initiating the acquisition of a new attestation report. In an example, the remedial action component 130 contacts one or both of the dependent system 121 or the attestation service 120 to obtain a new attestation report. This has the technical effect of proactively reducing the period during which the dependent system 121 is prevented from interacting with the attested software 115.

[0094] In additional or alternative embodiments, the remedial action in action 604 includes notifying the dependent computer system. In an example, the remedial action component 130 contacts the dependent system 121 to notify the dependent system 121 that the attested attributes are no longer valid. This has the technical effect of enabling the dependent system 121 to stop communicating with the client system 101.

[0095] Accordingly, the additional embodiments described herein take proactive remedial actions at the client system in the case where attested attributes regarding the ROMP state of a software component are no longer valid during the attestation validity period. Thus, these embodiments operate to enforce the attestation of read-only protected memory during the attestation validity period. The technical effects of enforcing read-only protected memory during the attestation validity period include promoting computer security by ensuring that a dependent party can actually rely on the attestation made by the client computer system throughout the validity duration of the authentication report.

[0096] 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 above features or acts, or the order of the above acts. Rather, the described features and acts are disclosed as example forms of implementing the claims.

[0097] Embodiments of the invention may include 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 more detail below. Embodiments within the scope of the invention also include physical and other computer-readable media for carrying or storing computer-executable instructions and / or data structures. Such computer-readable media can be any available media that can be accessed by a general purpose or special purpose computer system. A computer-readable medium storing computer-executable instructions and / or data structures is a computer storage medium. A computer-readable medium carrying computer-executable instructions and / or data structures is a transmission medium. Thus, by way of example and not limitation, embodiments of the invention may include at least two distinctly different computer-readable media: computer storage media and transmission media.

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

[0099] Transmission media can include a network and / or data link(s) that can be used to carry program code in the form of computer-executable instructions or data structures and that can be accessed by a general purpose or special purpose computer system. "Network" is defined as one or more data links that enable the transport of electronic data between computer systems and / or modules and / or other electronic devices. When information is transferred or provided to a computer system via a network or another communication connection (either hardwired, wireless, or a combination of hardwired or wireless), the computer system can view the connection as a transmission medium. Combinations of the above should also be included within the scope of computer-readable media.

[0100] In addition, upon reaching various computer system components, program code in the form of computer-executable instructions or data structures can automatically be transferred from a transmission medium to a computer storage medium (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 ultimately transferred to a computer system RAM and / or a more persistent computer storage medium at the computer system. Thus, it should be understood that computer storage media can be included in computer system components that also (or even primarily) utilize a transmission medium.

[0101] Computer-executable instructions include, for example, instructions and data that, when executed at one or more processors, cause a general-purpose computer system, a special-purpose computer system, or a special-purpose processing device to perform a particular function or a set of functions. Computer-executable instructions can be, for example, binary, intermediate format instructions (such as assembly language), or even source code.

[0102] Those skilled in the art will appreciate that the present invention can be practiced in a network computing environment having many types of computer system configurations, including personal computers, desktop computers, laptop computers, messaging processors, handheld devices, multiprocessor systems, microprocessor-based or programmable consumer electronics, network PCs, minicomputers, mainframe computers, mobile phones, PDAs, tablet computers, pagers, routers, switches, and the like. The present invention can also be practiced in a distributed system environment where both local and remote computer systems, linked by a network (or by a hardwired data link, a wireless data link, or by a combination of hardwired and wireless data links), perform tasks. Thus, in a distributed system environment, a computer system can include multiple constituent computer systems. In a distributed system environment, program modules can be located in both local and remote memory storage devices.

[0103] Those skilled in the art will also appreciate that the present invention can be practiced in a cloud computing environment. A cloud computing environment can be distributed, although this is not required. When distributed, a cloud computing environment can be distributed internationally within an organization and / or have components owned by multiple organizations. In this specification and the appended claims, "cloud computing" is defined as a model for enabling on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services). The definition of "cloud computing" is not limited to any one of the many other advantages that can be obtained from such a model when properly deployed.

[0104] Cloud computing models can include various features such as on-demand self-service, broad network access, resource pooling, rapid elasticity, measured service, etc. Cloud computing models can also take 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 (“IaaS”). Cloud computing models can also be deployed using different deployment models such as private cloud, community cloud, public cloud, hybrid cloud, etc.

[0105] Some embodiments, such as cloud computing environments, can include a system that includes one or more hosts, each host being capable of running one or more virtual machines. During operation, the virtual machines simulate an operating computing system, supporting an operating system and possibly also one or more other applications. In some embodiments, each host includes a hypervisor that uses physical resources abstracted from the view of the virtual machines to simulate virtual resources for the virtual machines. The hypervisor also provides appropriate isolation between the virtual machines. Thus, from the perspective of any given virtual machine, the hypervisor provides the illusion that the virtual machine is interacting with physical resources, even though the virtual machine is only interacting with the appearance of the physical resources (e.g., virtual resources). Examples of physical resources include processing capabilities, memory, disk space, network bandwidth, media drives, etc.

[0106] Without departing from the essential characteristics of the present invention, the present invention may be embodied in other specific forms. The described embodiments are to be considered in all respects only as illustrative and not restrictive. Thus, the scope of the present invention is indicated by the appended claims rather than the foregoing description. All changes that fall within the meaning and scope of the equivalents of the claims are included in its scope. When an element is introduced in the appended claims, the articles “a,” “an,” “the,” and “said” are intended to mean that there is one or more of the element. The terms “comprising,” “including,” and “having” are intended to be inclusive and mean that there may be additional elements other than the listed elements. Unless otherwise stated, the terms “set,” “superset,” and “subset” are intended to exclude the empty set, and thus a “set” is defined as a non-empty set, a “superset” is defined as a non-empty superset, and a “subset” is defined as a non-empty subset. Unless otherwise stated, the term “subset” excludes its entire superset (i.e., the superset includes at least one item not included in the subset). Unless otherwise stated, a “superset” may include at least one additional element, and a “subset” may exclude at least one element.

Claims

1. A computer system (101), the computer system including a processor (103) for enforcing attestation of a read-only protected memory during an attestation validity period, the computer system further including: A hardware storage device (105) storing computer-executable instructions executable by the processor to cause the computer system to at least: Identify (128) a change in the read-only memory protection ROMP state for a software component (115) loaded at the computer system; Determine (129) that an attestation validity period of an attestation report (305) has not expired, the attestation report including one or more attested attributes (308), the one or more attested attributes including one or more ROMP-attested attributes for a read-only protected memory (116) assigned to the software component; Determine (129) that at least one ROMP-attested attribute for the software component is no longer valid due to the change in the ROMP state for the software component; And Based on the at least one ROMP-attested attribute for the software component no longer being valid, initiate (130) a remediation action to prevent interaction of the software component with a dependent computer system (121).

2. The computer system according to claim 1, wherein the remediation action includes pausing one or more processes corresponding to the software component.

3. The computer system according to claim 2, the computer-executable instructions further being executable by the processor to cause the computer system to resume the one or more processes after expiration of the validity period.

4. The computer system according to claim 1, wherein the remediation action includes terminating one or more processes corresponding to the software component.

5. The computer system according to claim 1, wherein the remediation action includes blocking one or more communications from the software component.

6. The computer system according to claim 5, the computer-executable instructions further being executable by the processor to cause the computer system to allow communications by the software component after expiration of the validity period.

7. The computer system according to any of the preceding claims, wherein the remediation action includes initiating acquisition of a new attestation report.

8. The computer system according to any one of claims 1 to 6, wherein the remediation action includes notifying the dependent computer system.

9. A method implemented at a computer system, the computer system including a processor for enforcing attestation of a read-only protected memory during an attestation validity period, the method including: Identify (128) a change in the read-only memory protection ROMP state for a software component (115) loaded at the computer system; Determine (129) that the validity period of the proof report (305) has not expired, the proof report including one or more proven attributes (308), the one or more proven attributes including one or more ROMP-proven attributes for a read-only protected memory (116) assigned to the software component; Determine (129) that at least one ROMP-proven attribute for the software component is no longer valid due to the change in the ROMP state for the software component; And Based on the at least one ROMP-proven attribute for the software component being no longer valid, initiate (130) a remedial action to prevent the software component from interacting with the dependent party computer system (121).

10. The method according to claim 9, wherein the remedial action includes suspending one or more processes corresponding to the software component.

11. The method according to claim 10, further comprising resuming the one or more processes after the expiration of the validity period.

12. The method according to claim 9, wherein the remedial action includes terminating one or more processes corresponding to the software component.

13. The method according to claim 9, wherein the remedial action includes blocking one or more communications from the software component.

14. The method according to any one of the preceding claims, wherein the remedial action includes initiating the acquisition of a new proof report.

15. The method according to any one of claims 9 to 13, wherein the remedial action includes notifying the dependent party computer system.

Images