Policy-based object attestation

Abstract

This disclosure relates to policy-based attestation of objects. In some examples, an electronic device accesses policy information that specifies identifiers of objects to be attested in the electronic device. The electronic device monitors the objects to detect access to any of the objects. Based on receiving an indication of access to a first object of the objects, the electronic device measures the first object to produce an object measurement value and records the object measurement value in a secure processor. The electronic device obtains, from the secure processor, a representation of the object measurement value of the first object and sends the representation to an attestation server. The electronic device receives, from the attestation server, an attestation result for the first object.

Description

Background Technology

[0001] Electronic devices can operate in computing environments such as an organization's workplace, data center, cloud environment, home, or any other type of computing environment. Electronic devices may be vulnerable to attacks. Attached Figure Description

[0002] Some embodiments of this disclosure are described with reference to the following figures.

[0003] Figure 1 It is a block diagram based on some examples of the layout of electronic devices and server systems.

[0004] Figure 2 This is a flowchart of the process of collecting reference metrics based on some examples.

[0005] Figure 3 It is a flowchart of the proof process in the operational phase based on some examples.

[0006] Figure 4 It is a block diagram of a storage medium with machine-readable instructions based on some examples of storage.

[0007] Figure 5 It is a block diagram based on some example electronic devices.

[0008] Figure 6 It is a flowchart based on some examples.

[0009] In all the accompanying drawings, the same reference numerals refer to similar but not necessarily identical elements. The drawings are not necessarily drawn to scale, and the size of some parts may be enlarged to illustrate the examples more clearly. Furthermore, the drawings provide examples and / or embodiments consistent with the specification; however, the specification is not limited to the examples and / or embodiments provided in the drawings. Detailed Implementation

[0010] When an electronic device initially boots, a boot-time proof can be performed to ensure the integrity of the device's components, such as firmware, the operating system (OS) kernel, and specific files (like configuration files containing configuration data or other files containing other information). The set of components that are proven during the boot-time proof of an electronic device is fixed. For example, the various parts of the boot firmware, firmware configuration data and other static data, and the OS kernel are proven in a fixed order during boot.

[0011] After the OS kernel boots, it may be impossible to further prove certain components while the electronic device is running. Examples of components not proven at runtime include configuration files and / or interpreted files containing interpreted program code. Configuration files contain configuration data that defines the configuration of the electronic device. The interpreted program code in interpreted files includes program code that can be executed directly without first compiling it. For example, an interpreter can be provided to process the interpreted program code to be executed. Configuration files are an example type of static file that contains information that manages the operation of the electronic device. Runtime proof may also not be performed against other types of static files.

[0012] Unproven components during operation can be compromised by attackers or damaged due to misbehavior of programs or electronic components. For example, a corrupted configuration file may cause misconfiguration in electronic devices. A corrupted interpreter file may lead to malicious or erroneous execution of program code. These corrupted components can introduce security risks and errors into electronic devices.

[0013] According to some embodiments of this disclosure, a runtime proof monitor is invoked within an electronic device to support the proof of objects during the operation of the electronic device. The runtime proof monitor can access policy information specifying the identifier of the object to be proven in the electronic device. Examples of objects may include configuration objects or other static objects containing information managing the operation of the electronic device. Objects may also include interpretive objects containing interpretable program code. The runtime proof monitor can measure the objects and record the resulting metric values ​​in a security processor. The runtime proof monitor can monitor the objects to detect access to any object within the objects, and in response to receiving an indication of access to a first object within the objects, the runtime proof monitor can obtain a metric value for the first object from the security processor. A representation of the obtained metric value is sent from the electronic device to a verifier, which may be part of a proof server accessible via a network by the electronic device. The electronic device receives the proof result for the first object from the verifier.

[0014] Techniques or mechanisms according to some examples of this disclosure can improve computer functionality or related technologies by proving objects at runtime, preventing compromised objects from posing security risks or causing errors in electronic devices. In some cases, objects may be compromised by an attacker (e.g., malware, a human, or another attacker). In other cases, objects may be compromised due to damage caused by program or electronic component malfunctions. In some examples, a compromised configuration object may cause misconfiguration of an electronic device, potentially rendering the device unusable or allowing an attacker to steal information or launch attacks on the computing environment. A compromised interpretable object can allow unauthorized modification of program code within the interpretable object, enabling an attacker to perform malicious actions. The ability to prove objects at runtime can detect such attacks.

[0015] The "runtime" state of an electronic device can refer to the state of the device after the boot process has been completed. The boot process includes initializing the electronic device using boot code (e.g., boot firmware) and then loading the OS kernel into the device.

[0016] An “object” can refer to a file, table, database, or any other container of information. An object’s “identifier” can refer to the object’s name (for example, where the name can be part of a path in a file system), a Uniform Resource Locator (URL), or any other type of identifying information that distinguishes the object from another object.

[0017] Figure 1 This is a block diagram of an example arrangement including electronic device 102 and server system 104, the server system including a proof server 106 that interacts with a proof agent 108 in electronic device 102 to perform proofs on objects in electronic device 102. Server system 104 may include one or more computers. Although Figure 1 Only one electronic device 102 is shown, but in a further example, the proof server 106 in the server system 104 can prove multiple electronic devices.

[0018] The "proof" of an object includes measuring the object to verify its integrity, i.e., that the object has not been modified in an unintended manner, such as due to unauthorized modification by an attacker or due to malfunction in electronic device 102. The proof server 106 includes machine-readable instructions executed by the processing resources of server system 104, and the proof agent 108 may include machine-readable instructions executed by the processing resources of electronic device 102.

[0019] In some examples, the proof agent 108 and the proof server 106 operate according to a proof protocol. In some examples, the proof protocol may be an open-source protocol. In other examples, the proof protocol may be a standardized protocol as described in a standard specification.

[0020] An example of an open-source proof protocol is the Keylime protocol, provided by the Cloud Native Computing Foundation (CNCF). The Keylime protocol supports remote bootstrapping proofs and runtime integrity measurement systems. Other examples of open-source proof protocols include the VERAISON project (VERificAtion of atteStatiON, proof verification) and Runtime and Boot-Time Host Integrity (HIRS).

[0021] Other examples of proof techniques may include any one or a combination of the following: a Trusted Proof Protocol (TAP) based on an information model provided by the Trusted Computing Group (TCG); or a standardized remote proof protocol.

[0022] Electronic device 102 is coupled to server system 104 via network 110. Network 110 may include a public network such as the Internet, or alternatively, network 110 may include a local area network (LAN), a wide area network (WAN), or any other type of network.

[0023] Electronic device 102 includes boot code 112 and OS 114 that can be executed by the processing resources of electronic device 102. Boot code 112 may include Basic Input / Output System (BIOS) code or Universal Extensible Firmware Interface (UEFI) code that initializes electronic device 102 during the boot process of electronic device 102. OS 114 may include LINUX OS, WINDOWS OS, MAC OS, or any other type of OS.

[0024] The proof agent 108 includes a runtime proof plugin 116, and the proof server 106 includes a runtime verification plugin 118. A "plugin" is a program code component (including machine-readable instructions) that adds specific functionality to an existing program, where the existing program does not already possess the specific functionality added by the plugin. The functionality added by the plugin can be added without modifying the underlying existing program.

[0025] Therefore, in Figure 1 In the example, runtime proof plugin 116 adds functionality to proof agent 108, and runtime verification plugin 118 adds functionality to proof server 106. Runtime proof plugin 116 and runtime verification plugin 118 add functionality to allow proof agent 108 and proof server 106 to perform runtime proofs on objects in electronic device 102.

[0026] In the example, the proof agent 108 and proof server 106 can operate according to the Keylime protocol. A version of the Keylime protocol may not support runtime proofs of objects in electronic devices. Runtime proof plugin 116 and runtime verification plugin 118 can add runtime proof functionality to the Keylime proof agent and proof server.

[0027] In other examples, according to some implementations of this disclosure, the proof agent 108 and the proof server 106 may be configured to support runtime proof of objects, rather than using plugins.

[0028] In some examples of this disclosure, electronic device 102 includes a runtime proof monitor 120 that measures objects to support proofs of those objects during runtime of electronic device 102. In these examples, the runtime proof monitor 120 (including machine-readable instructions) can execute in the user space of electronic device 102. This user space is different from the kernel space in which the kernel of OS 114 executes.

[0029] The runtime verification monitor 120 has access to storage medium 122 and memory 124. Storage medium 122 can be a persistent storage medium, which can be implemented using one or more storage devices (such as disk-based storage devices, solid-state drives, or other types of storage devices). Memory 124 can be implemented using one or more memory devices.

[0030] according to Figure 1 For example, the objects to be proven at runtime include configuration file 126 containing configuration data and interpreted file 128 containing interpreted program code. Although Figure 1 Two specific files are shown, but in other examples, metrics provided by runtime proof monitor 120 can be used to prove alternative or additional objects. Runtime proof monitor 120 extends the chain of trust to objects that would not normally be proven at runtime, such as configuration file 126 and explanatory file 128.

[0031] Memory 124 stores a runtime proof strategy 130, which specifies the identifier (e.g., name, URL, etc.) of the object to be proven at runtime on electronic device 102 (including configuration file 126 and interpretive file 128). The runtime proof strategy can use the identifier to determine the storage location (in storage medium 122) of the object to be proven. For example, if the object's name is part of a path in a file system, the path and name can be used to access the object. As another example, a URL can indicate the storage location of the object.

[0032] Runtime proof monitor 120 parses runtime proof strategy 130 to generate a runtime object list 132 of objects to be proven. "List" can refer to a data structure that includes one or more elements (such as identifiers of objects to be proven).

[0033] Based on the runtime object list 132, the runtime proof monitor 120 measures the objects to be proven (including configuration file 126 and interpretive file 128). The resulting metrics from measuring the objects to be proven can be recorded in the registers of a security processor (e.g., the Platform Configuration Register (PCR) of a Trusted Platform Module (TPM) 140). The TPM 140 can perform various hardware-based security functions in the electronic device 102. In other examples, the TPM 140 can be implemented in software, such as as a virtual TPM (which is an example of a virtual security processor). In addition to supporting encryption functions, the TPM 140 also acts as a root of trust. The security functions of the TPM 140 can include the management and generation of keys and certificates. For example, the TPM 140 can generate cryptographic keys used in secure operations, where the cryptographic keys can include public-private key pairs, which include a public key and an associated private key.

[0034] In TPM 140, the PCR is a storage location used to store the measurement result (e.g., hash value) of a specific value, such as information in electronic device 102 (e.g., an object to be proven, including configuration file 126 and explanatory file 128). In the example, the runtime proof monitor 120 can apply a cryptographic hash function, such as a secure hash algorithm (SHA) function, to the information to produce a hash value that can be extended to the PCR. The measurement agent extends the PCR by performing an extension operation that computes a cryptographic hash of the combination of the current value of the PCR and the new hash value.

[0035] The PCR setup for TPM 140 is located in PCR libraries 142A, 142B, and 142C. Although Figure 1 Three PCR libraries are shown, but in different examples, the number of PCR libraries may vary in the TPM 140. A PCR library may include a collection of PCRs.

[0036] In the following discussion, it is assumed that the metrics of configuration file 126 and interpretive file 128 are extended to PCR library 142A. More generally, the metrics of the object to be proved can be extended to one or more PCR libraries 142. For example, if TPM140 supports multiple cryptographic hash algorithms to compute hash values, different PCR libraries can be used to record hash values ​​generated using the corresponding different cryptographic hash algorithms.

[0037] In addition to extending the metrics of configuration file 126 and interpretive file 128 to the PCR library 142A, runtime proof monitor 120 also adds the metrics of configuration file 126 and interpretive file 128 to log file 144. Log file 144 (or any other log data structure) is stored in memory 124 by runtime proof monitor 120. Each entry in log file 144 may include an identifier of an object and its corresponding metric.

[0038] Furthermore, the runtime proof monitor 120 also measures the runtime proof policy 130, extends the measure of runtime proof policy 130 to PCR library 142A (or another PCR library), and adds the measure of runtime proof policy 130 to log file 144. The entry for runtime proof policy 130 in log file 144 includes the identifier of runtime proof policy 130 and the measure of runtime proof policy 130.

[0039] TPM 140 includes a secure storage 146 for storing key information. For example, the secure storage 146 of the TPM can store private keys for cryptographic device identities, such as device identity (DevID) certificates. A DevID certificate could be an initial DevID (IDevID) certificate 148 installed in electronic device 102 during its manufacture. Another example of a cryptographic device identity is a local DevID (LDevID) certificate. DevID is further explained in the IEEE 802.1AR secure device identity standard. In some examples, the IDevID or LDevID certificate can be stored in storage 124 of electronic device 102. In other examples, the certificate is not stored in electronic device 102 but can be part of a certificate inventory available to server system 104.

[0040] A certificate (also known as a digital certificate) is information (e.g., a file or another object) used to verify the authenticity of an entity, such as a user, program, or device. A certificate can be an X.509 certificate. A certificate may include information about the entity (e.g., a user, program, or device) and is issued by a trusted third party (e.g., a Certificate Authority (CA)).

[0041] In some examples, the secure memory 146 of the TPM can further store an initial authentication key (IAK) 150. The TPM 140 can create additional authentication keys (AKs), such as AK 152, that can be stored in the secure memory 146. AK 152 can be used to sign data on the TPM 140 to authenticate the electronic device 102.

[0042] although Figure 1The document shows specific examples of certificates and keys, but in other examples, the TPM's secure storage 146 can store other types of certificates and / or keys.

[0043] Electronic device 102 further includes an integrity measurement engine 164, which can be used to verify the integrity of specific components (such as runtime proof monitor 120, or any other component of electronic device 102). In this example, integrity measurement engine 164 can be based on an Integrity Measurement Architecture (IMA) provided by the Linux OS. In other examples, other types of integrity measurement engines can be used in conjunction with other types of OS. Integrity measurement engine 164 can perform measurements on runtime proof monitor 120.

[0044] Electronic device 102 further includes a notification agent 166 (including machine-readable instructions) that can notify runtime proof monitor 120 of any access (e.g., read or write) to objects in runtime object list 132. Based on this notification from notification agent 166 when an object in runtime object list 132 is accessed, runtime proof monitor 120 can perform further metrics on the accessed object (e.g., configuration file 126 or interpretive file 128) to initiate runtime proof of the accessed object using proof server 106. Runtime proof monitor 120 extends the further metrics to PCR library 142A and adds the further metrics to log file 144.

[0045] The verification server 106 includes a registrar 160 to which the verification agent 108 can register. After the verification agent 108 has registered with the registrar 160, the verification agent 108 can perform the verification process using the verifier 162 in the verification server 106. The registrar 160, verifier 162, and runtime verification plugin 118 include machine-readable instructions that are part of the verification server 106.

[0046] Based on some examples in this disclosure, the proof agent 108 can use the key stored in the TPM 140 without having to regenerate the key. For example, the Keylime protocol specifies that the key should be regenerated at runtime before the registration process can be performed using the Keylime proof server. For example, the regenerated key is based on a specified template provided by the IDevID / IAK specification. In contrast, the key stored in the TPM can have a custom template that differs from the specified template.

[0047] In some examples disclosed herein, it is demonstrated that Agent 108 can be configured to support the use of keys from TPM 140 (or any other type of security processor) without having to regenerate keys. Keys in TPM 140 include the key for IDevID certificate 148, IAK 150, and AK 152. Regenerating keys is a resource-intensive and time-consuming process.

[0048] The key stored in the TPM's secure memory 146 can also be protected using a password (such as a hexadecimal password) or another credential. The authentication agent 108 is configured to support access to the key from the TPM's secure memory 146 using such a password (or another credential).

[0049] Therefore, the verification agent 108 can collect the IDevID and IAK keys by using TPM handles (which are addresses identifying locations in TPM 140), instead of regenerating the keys; these TPM handles point to the key's storage location. The verification agent 108 can issue a cipher (or another credential) to access this key at the corresponding TPM handle. The verification agent 108 can then use the IDevID to perform registration with the registrar 160 in the verification server 106.

[0050] The following description is for reference. Figure 1 and Figure 2 Both. Figure 2 This is a flowchart of a reference metric collection process 200 for collecting reference metrics. For example, the reference metric collection process 200 may be performed by a reference metric program executed within or outside the electronic device 102. The reference metric collection process 200 may be performed at an initial stage during manufacturing or at different times when the electronic device 102 is in a safe position or safe state.

[0051] The reference metric procedure measures the runtime proof monitor 120 (at 202) to produce a reference proof monitor metric value, for example, by applying a cryptographic hash function to the hash value produced by the runtime proof monitor 120.

[0052] The reference metric procedure measures runtime proof policy 130 (at 204) to produce a reference policy metric (e.g., hash value) for runtime proof policy 130. The reference metric procedure further measures the object to be proven (including configuration file 126 and interpretive file 128) (at 206) to produce a reference object metric (e.g., hash value) for the object.

[0053] The reference metric program provides reference metric values ​​(including reference proof monitor metric values, reference policy metric values, and reference object metric values) to server system 104 (at 208). Server system 104 stores the reference metric values ​​(represented as 170) in memory 172 of server system 104.

[0054] The following description is for reference. Figure 1 and Figure 3 Both. Figure 3 It is a flowchart involving the integrity measurement engine 164, the runtime proof monitor 120, the proof agent 108, and the proof server 106. Figure 3 The process is performed during the operation phase of the electronic device 102. The operation phase is performed during the operation of the electronic device 102 after delivery to the customer site or to another site where the electronic device 102 is to be operated as intended.

[0055] When electronic device 102 is first powered on or rebooted, it is started by boot code 112. Boot code 112 loads OS 114. After OS 114 is loaded, electronic device 102 enters the runtime state.

[0056] Before invoking the runtime proof monitor 120, the integrity measurement engine 164 measures the runtime proof monitor 120 (at 302) to produce a monitor metric value, which is added to the integrity measurement engine 164's log file (not shown). The integrity measurement engine 164's log file may differ from log file 144. The log file containing the monitor metric value is provided to the proof server to verify that the runtime proof monitor 120 has not been compromised (whether intentionally compromised by an attacker or accidentally compromised due to a malfunction of electronic device 102). For example, the integrity measurement engine 164 may apply a cryptographic hash function to the runtime proof monitor 120 to obtain a hash value, which is added to the integrity measurement engine 164's log file and provided to the proof server 106. Alternatively, the integrity measurement engine 164 may compare the obtained hash value with a reference hash value to ensure that the runtime proof monitor 120 has not been modified in an unauthorized manner.

[0057] Runtime verification monitor 120 is invoked, for example, by OS 114 (at 304). Runtime verification monitor 120 discovers TPM 140 and initiates (at 306) a communication session with TPM 140, which can be done by initiating a TPM context to interact with TPM 140. The TPM context is an object containing the connection configuration for communicating with TPM 140. The TPM context also contains information about the contents of TPM 140. For example, runtime verification monitor 120 can discover TPM 140 by accessing configuration information stored in electronic device 102.

[0058] In some examples, the runtime proof monitor 120 can discover the set of cryptographic hash algorithms used by the TPM 140 based on information in the TPM context. In such examples, the runtime proof monitor 120 can apply the hash function of the cryptographic hash algorithm to the selected information (including the object to be proven identified by the runtime object list 132) to record it in the corresponding TPM library. However, in the following discussion, for the sake of simplicity, references will be made to using only one cryptographic hash algorithm to measure the object to be proven.

[0059] Runtime proof monitor 120 measures (at 308) runtime proof policy 130 to produce a policy measure value for runtime proof policy 130. This measurement may include applying a cryptographic hash function to runtime proof policy 130 to produce a policy hash value. Runtime proof monitor 120 extends (at 310) the policy hash value to PCR library 142A and appends (at 312) the policy hash value to log file 144. The policy hash value of runtime proof policy 130 is provided to proof server 106 to check that runtime proof policy 130 has not been violated.

[0060] Runtime proof monitor 120 parses runtime proof policy 130 to obtain (at 314) a runtime object list 132 of objects to be proven at runtime. Runtime proof monitor 120 uses notification agent 166 to establish monitoring of the objects identified by runtime object list 132. In some examples, notification agent 166 may include the inotify subsystem of the Linux OS. Runtime proof monitor 120 provides a reference to runtime object list 132 to notification agent 166, which monitors the objects identified by runtime object list 132 to detect any access to the objects. In alternative examples, runtime proof monitor 120 may monitor access to any object identified by runtime object list 132 on its own, instead of using a separate notification agent 166.

[0061] In response to the detection of access to an object identified by runtime object list 132, notification agent 166 sends a notification to runtime proof monitor 120. Upon receiving (at 316) this notification, runtime proof monitor 120 measures (at 318) the accessed object to obtain an object metric value (e.g., an object hash value). Runtime proof monitor 120 expands (at 320) the object hash value into PCR library 142A and appends (at 322) the object hash value to log file 144.

[0062] Note that if multiple objects are accessed, the runtime proof monitor 120 measures multiple objects to obtain corresponding object metric values ​​(e.g., object hash values), which are then extended to the PCR library 142A and added to the log file 144. In an alternative example, the runtime proof monitor 120 may also measure unaccessed objects while measuring (multiple) accessed objects, and the object metric values ​​(e.g., object hash values) of the unaccessed objects are also extended to the PCR library 142A and added to the log file 144.

[0063] The following discussion assumes that a single object hash value of only one accessed object is extended to PCR library 142A and added to log file 144. If multiple object hash values ​​are extended to PCR library 142A and added to log file 144, a similar technique can be applied.

[0064] Next, the runtime proof monitor 120 provides the proof agent 108 (at 324) with instructions (e.g., a message, command, information element, or any other indicator) to perform a proof, in this example, for an object being accessed (e.g., one or both of configuration file 126 and interpretive file 128). The proof agent 108 uses the TPM PCR read command to obtain proof data based on the policy hash and object hash from the PCR library 142A (at 326). The TPM PCR read command reads the current PCR values ​​contained in the PCR library 142A.

[0065] The runtime proof plugin 116 of proof agent 108 obtains (at 328) log file 144. In some examples, proof agent 108 (e.g., Keylime proof agent) may not be able to obtain log file 144 for performing runtime proofs. In such examples, runtime proof plugin 116 can add the functionality to obtain log file 144 for runtime proofs. Note that runtime proof plugin 116 can also select the PCR libraries(s) that proof agent 108 will access during runtime proofs. In other examples, runtime proof plugin 116 can be omitted, and proof agent 108 can obtain both log file 144 and proof data from PCR library 142A.

[0066] The proof agent 108 sends proof data and log file 144 (at 330) to the proof server 106. The proof data may be included in a signed PCR reference (signed using the private key of AK 152) from the proof agent 108 to the proof server 106. The signed PCR reference may be pushed to the proof server 106 by the proof agent 108, or alternatively, the signed PCR reference may be sent by the proof agent 108 in response to a PCR reference request from the proof server 106.

[0067] In some examples, verifier 162 of proof server 106 (e.g., a Keylime proof server) can perform proofs on certain components of electronic device 102, such as boot code, boot information, and other components. However, verifier 162 may not be configured to perform runtime proofs on objects identified by runtime object list 132. Instead, runtime verification plugin 118 can perform runtime proofs on objects identified by runtime object list 132. In other examples, runtime proofs can be performed by verifier 162.

[0068] Runtime verification plugin 118 determines (at 332) the integrity of the accessed object based on the received proof data and log file 144. Runtime verification plugin 118 uses the public key of AK 152 to verify the signed PCR reference. If the PCR reference is valid, in some examples, runtime verification plugin 118 can perform PCR replay based on the hash value contained in log file 144. Log file 144 contains the following hash values: a policy hash value and an object hash value (of the accessed object). Performing PCR replay based on log file 144 involves simulating a PCR expansion operation using the hash value in log file 144 to obtain a PCR value. The obtained PCR value is compared with the PCR value contained in the proof data received from proof agent 108. If the obtained PCR value matches the PCR value contained in the proof data, the integrity of log file 144 is confirmed. If the integrity of log file 144 is confirmed, the runtime verification plugin 118 further compares the policy hash value in log file 144 with the reference policy hash value and the object hash value in log file 144 with the corresponding reference object hash value. The reference policy hash value and the reference object hash value are part of the reference metric 170 stored in the memory 172 of server system 104. If the policy hash value and the object hash value in log file 144 match the reference policy hash value and the reference object hash value, respectively, the runtime verifies the integrity of policy 130 and the accessed object, and the verification is successful. If the policy hash value or the object hash value in log file 144 does not match the corresponding reference policy hash value or the reference object hash value, the runtime verifies that policy 130 or the accessed object has been corrupted, and the verification fails.

[0069] The proof server 106 sends information indicating the proof result (at 334) to the proof agent 108. If the proof is successful, the proof agent 108 can allow the electronic device 102 to continue operating. However, if the proof fails, the proof agent 108 can disable the electronic device 102. For example, the proof agent 108 can send an indication of proof failure to the management controller, OS 114, or another component in the electronic device 102 to disable the electronic device 102, such as by turning off the electronic device 102, cutting off the power to the electronic device 102, or disabling the software or firmware in the electronic device 102. The electronic device 102 can also be isolated from the network 110 to prevent communication between the electronic device 102 and other devices. Isolation can be achieved by disabling the network interface of the electronic device 102 or by notifying other devices that the electronic device 102 has been compromised.

[0070] Figure 4This is a block diagram of a non-transitory machine-readable or computer-readable storage medium 400 that stores machine-readable instructions that, when executed, enable electronic devices to perform various tasks.

[0071] Machine-readable instructions include runtime policy access instructions 402, which are used to access policy information specifying the identifier of an object to be proved in an electronic device. For example, the policy information could be... Figure 1 The runtime proof strategy 130. For example, the identifier may include the name, URL, or other form of identification information of the specific object to be proven at runtime.

[0072] Machine-readable instructions include object monitoring instructions 404, which are used to monitor objects to detect access to any objects within the objects. Monitoring can be performed by... Figure 1 Notification agent 166 or by Figure 1 The runtime proof monitor 120 executes.

[0073] The machine-readable instructions include accessed object measurement instructions 406, which are used to measure a first object based on an instruction received to access a first object among the objects, to generate an object measurement value, and to record the object measurement value in a security processor. For example, the security processor may include a TPM, and recording the object measurement value includes using the object measurement value to extend the PCR (one or more PCRs) of the TPM. In a further example, measurements of multiple objects may be performed to generate multiple object measurement values, which are recorded in the security processor (e.g., extended to PCRs).

[0074] Machine-readable instructions include object metric representation acquisition and transmission instructions 408, which are used to obtain a representation of the object metric value of a first object from the security processor and transmit that representation to the authentication server. For example, the representation of the object metric value may be included in a signed PCR reference.

[0075] The machine-readable instructions include proof result receiving instructions 410, which are used to receive proof results for the first object from the proof server. The proof server can be executed in a server system separate from electronic devices.

[0076] In some examples, the machine-readable instructions used to access policy information, monitor objects, measure a first object, obtain a representation of the object's measurement value, and send that representation to the verification server reside in the user space of the electronic device. For example, these machine-readable instructions could be... Figure 1 The runtime proof is part of monitor 120.

[0077] In some examples, monitoring an object, measuring a first object, obtaining a representation of the object's measurement value, and sending that representation to a verification server are performed during the runtime of the electronic device.

[0078] In some examples, access policy information, monitoring objects, measuring the first object, and obtaining a representation of the object's measurement value are performed by a runtime verification monitor invoked in response to the boot of the electronic device.

[0079] In some examples, runtime demonstrations show that the monitor can discover security processors and establish communication sessions with them.

[0080] In some examples, the integrity measurement engine in electronic devices (e.g., Figure 1 (164) can be used to measure the runtime proof monitor to verify that the runtime proof monitor has not been compromised.

[0081] In some examples, the runtime proof monitor can measure the policy information to obtain a policy metric value for the policy information, and the electronic device can send a representation of the policy metric value of the policy information to the proof server to verify that the policy information has not been corrupted.

[0082] In some examples, the electronic device can create a log that includes object metrics of a first object, and the electronic device can send the log with the representation of the object metrics to the proof server.

[0083] In some examples, the proof of the first object by the proof server includes performing a PCR replay using the logs and comparing the object metric in the log file with the reference object metric.

[0084] In some examples, the representation of the object's metric is sent by a proof agent in the electronic device to a proof server, where the proof agent and the proof server operate according to an open-source proof protocol.

[0085] In some examples, the open-source proof protocol is the Keylime protocol.

[0086] In some examples, the proof agent can register with a registrar that operates under an open-source proof protocol using a device identity certificate (e.g., IDevID). The registrar can be part of a proof server.

[0087] Figure 5 This is a block diagram of electronic device 500. Figure 1 Electronic device 102 is an example of electronic device 500.

[0088] Electronic device 500 includes a security processor 502 with memory 504. The security processor 502 may include a TPM, and the memory 504 may include a PCR of the TPM.

[0089] Electronic device 500 includes hardware processor 506 (or multiple hardware processors). The hardware processor may include a microprocessor, the core of a multi-core microprocessor, a microcontroller, a programmable integrated circuit, a programmable gate array, or another hardware processing circuit.

[0090] Electronic device 500 includes storage medium 508 storing machine-readable instructions that can be executed on hardware processor 506 to perform various tasks. The machine-readable instructions executable on the hardware processor can refer to instructions that can be executed on a single hardware processor or instructions that can be executed on multiple hardware processors.

[0091] The machine-readable instructions in storage medium 508 include runtime policy access instructions 510, which are used to access policy information specifying the identifier of the object to be validated at runtime. For example, the policy information could be... Figure 1 Runtime proof strategy 130.

[0092] The machine-readable instructions in storage medium 508 include object monitoring instructions 512, which are used to monitor objects to detect access to any object within the objects. Access may include read access or write access.

[0093] The machine-readable instructions in storage medium 508 include accessed object measurement instructions 514, which are used to measure a first object based on a received instruction to access the first object in the object, to generate a measurement value, and to record the measurement value in memory 504 of security processor 502. Recording the measurement value may include, for example, using the measurement value to extend the PCR of TPM.

[0094] The machine-readable instructions in storage medium 508 include proof data generation instructions 516, which are used to generate proof data including information based on the metric value of the first object. The proof data can be obtained by performing a PCR read of the TPM.

[0095] The machine-readable instructions in storage medium 508 include proof data sending instructions 518, which are used to send proof data to a proof server. For example, the proof data may be included in a PCR reference.

[0096] The machine-readable instructions in storage medium 508 include proof result receiving instructions 520, which are used to receive proof results based on proof data from the proof server. The proof results may be based on: verifying PCR references, log-based PCR replay, and comparing metrics in the log with reference metrics performed by the proof server.

[0097] Figure 6 This is a flowchart of process 600 based on some examples of this disclosure. Process 600 may be, for example, in... Figure 1 It is executed in the electronic device 102, for example, during the initial phase of the electronic device 102.

[0098] Process 600 includes policy information for accessing (at 602) the identifier of a specified object within the electronic device. The policy information identifies the object to be verified at runtime.

[0099] Process 600 includes measuring the policy information (at 604) to produce a policy metric value. For example, a cryptographic hash function can be applied to the policy information to generate a policy hash value.

[0100] Process 600 includes recording the policy metric value (at 606) in the security processor's memory and adding the policy metric value to the log. For example, Figure 1 The runtime proof monitor 120 can use policy metrics to extend the PCR of TPM.

[0101] Process 600 includes measuring the object identified by the policy information (at 608) to produce an object metric value. For example, a cryptographic hash function can be applied to the object to generate an object hash value. In some examples, the metric for the object may be a metric for the object accessed during runtime.

[0102] Process 600 includes recording the object metric (at 610) in the security processor's memory and adding the object metric to the log. For example, Figure 1 The runtime proof monitor 120 can use object metrics to extend the PCR of TPM.

[0103] This log, along with the recorded policy metrics and object metrics, is used by the proof server to prove the object.

[0104] As used herein, "processing resources" may include one or more hardware processors. Examples of electronic devices may include any one or a combination of the following: desktop computer, laptop computer, tablet computer, server computer, vehicle, home appliance, or any other type of electronic device.

[0105] Examples of storage devices include any one or a combination of the following: disk-based storage devices, solid-state drives, or any other type of storage device. Examples of memory devices include any one or a combination of the following: dynamic or static random access memory (DRAM or SRAM) devices, erasable programmable read-only memory (EPROM) devices, electrically erasable programmable read-only memory (EEPROM) devices, or flash memory devices.

[0106] Figure 2 , Figure 3 and Figure 6 It is a flowchart of a process that includes tasks performed in the described order. In other examples, the tasks of any process may be performed in a different order, some tasks may be omitted, and other tasks may be added.

[0107] As used herein, "engine" can refer to one or more hardware processing circuits, which may include any or a combination of a microprocessor, a core of a multi-core microprocessor, a microcontroller, a programmable integrated circuit, a programmable gate array, or other hardware processing circuits. Alternatively, "engine" can refer to a combination of one or more hardware processing circuits and machine-readable instructions (software and / or firmware) executable on one or more hardware processing circuits.

[0108] Storage media (e.g., Figure 4 400 or Figure 5 508) may include any one or a combination of the following: semiconductor storage devices, such as dynamic or static random access memory (DRAM or SRAM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory; disks, such as fixed disks, floppy disks, and removable disks; another magnetic medium, including magnetic tape; optical media, such as optical discs (CDs) or digital video discs (DVDs); or other types of storage devices. Note that the instructions discussed above may be provided on a single computer-readable or machine-readable storage medium, or alternatively, on multiple computer-readable or machine-readable storage media distributed across a large system having potentially multiple nodes. Such one or more computer-readable or machine-readable storage media are considered part of an article (or article of manufacture). An article or article of manufacture may refer to any single or multiple manufactured components. One or more storage media may be located in a machine that executes the machine-readable instructions, or at a remote site where the machine-readable instructions can be downloaded from a remote site via a network for execution.

[0109] In this disclosure, unless the context clearly indicates otherwise, the terms “a,” “an,” or “the” are intended to include the plural form as well. Similarly, when used in this disclosure, the terms “includes / including / comprises / comprising” or “have / having” indicate the presence of the said element but do not preclude the presence or addition of other elements.

[0110] In the foregoing description, numerous details have been set forth to facilitate understanding of the subject matter disclosed herein. However, embodiments may be practiced without some of these details. Other embodiments may include modifications and variations of the details discussed above. The appended claims are intended to cover such modifications and variations.

Claims

1. A non-transitory machine-readable storage medium, comprising instructions that, when executed, cause an electronic device to perform the following operations: Access policy information, which specifies the identifier of the object to be verified in the electronic device; Monitor the object to detect access to any object within the object; Based on the received instruction to access a first object among the objects, the first object is measured to generate an object metric value and the object metric value is recorded in the security processor; The security processor obtains a representation of the object metric value of the first object and sends the representation to the proof server; as well as Receive the proof result for the first object from the proof server.

2. The non-transitory machine-readable storage medium as described in claim 1, wherein, The instructions for accessing the policy information, monitoring the object, measuring the first object, obtaining the object measurement value of the first object, and sending the representation to the proof server are located in the user space of the electronic device.

3. The non-transitory machine-readable storage medium as described in claim 1, wherein, The identifier of the object to be proved, specified in the strategy information, includes the name of the object.

4. The non-transitory machine-readable storage medium as described in claim 1, wherein, The monitoring of the object, the measurement of the first object, the acquisition of the representation of the object measurement value of the first object, and the sending of the representation to the verification server are performed during the operation of the electronic device.

5. The non-transitory machine-readable storage medium as described in claim 1, wherein, The representation of accessing the policy information, monitoring the object, measuring the first object, and obtaining the object metric value of the first object is performed by a runtime verification monitor invoked in response to the boot of the electronic device.

6. The non-transitory machine-readable storage medium as described in claim 5, wherein, When executed, the instruction causes the electronic device to perform the following operations: The security processor was discovered by the runtime verification monitor; and The runtime verifies that the monitor establishes a communication session with the security processor.

7. The non-transitory machine-readable storage medium as described in claim 5, wherein, When executed, the instruction causes the electronic device to perform the following operations: The integrity metric engine is used to measure the runtime proof monitor to verify that the runtime proof monitor has not been compromised.

8. The non-transitory machine-readable storage medium of claim 7, wherein, When executed, the instruction causes the electronic device to perform the following operations: The runtime verification monitor measures the policy information to obtain a policy measurement value for the policy information; as well as The representation of the policy metric value of the policy information is sent to the proof server to verify that the policy information has not been corrupted.

9. The non-transitory machine-readable storage medium as claimed in claim 1, wherein, Recording the object metric of the first object includes using the object metric to expand the platform configuration register (PCR) of the security processor.

10. The non-transitory machine-readable storage medium as described in claim 9, wherein, The representation of the object metric of the first object sent to the proof server includes a signed PCR reference, the signed PCR reference containing a PCR value based on the object metric of the first object.

11. The non-transitory machine-readable storage medium of claim 10, wherein, The PCR value is further based on a strategy metric value generated by measuring the strategy information.

12. The non-transitory machine-readable storage medium of claim 1, wherein, When executed, the instruction causes the electronic device to perform the following operations: Create a log that includes the object metric of the first object; and The log representing the object metric of the first object is sent to the proof server.

13. The non-transitory machine-readable storage medium of claim 12, wherein, The proof of the first object by the proof server includes replaying using the Log Execution Platform Configuration Register (PCR) and comparing the object metric in the log with a reference object metric.

14. The non-transitory machine-readable storage medium as claimed in claim 1, wherein, The representation of the object metric of the first object is sent to the proof server by the proof agent in the electronic device, wherein the proof agent and the proof server operate according to an open-source proof protocol.

15. The non-transitory machine-readable storage medium of claim 14, wherein, The open-source proof protocol is the Keylime protocol.

16. The non-transitory machine-readable storage medium of claim 14, wherein, When executed, the instruction causes the electronic device to perform the following operations: The authentication agent uses the device identity certificate to register with the registrar that operates according to the open-source authentication protocol.

17. An electronic device comprising: Security processor; Hardware processor; as well as A non-transitory storage medium for storing instructions that can be executed on the hardware processor to perform the following operations: Access policy information, which specifies the identifier of the object to be verified at runtime; Monitor the object to detect access to any object within the object; Based on the received instruction to access a first object among the objects, the first object is metrically measured to generate a metric value and the metric value is recorded in the memory of the security processor; Generate proof data that includes information based on the metric value of the first object; Send the proof data to the proof server; as well as Receive the proof result based on the proof data from the proof server.

18. The electronic device of claim 17, wherein, The security processor includes a Trusted Platform Module (TPM), the memory of the security processor includes a Platform Configuration Register (PCR), and recording the metric of the first object includes using the metric to expand the PCR.

19. A method comprising: Access policy information in an electronic device, the policy information specifying the identifier of the object to be verified at runtime; The electronic device measures the policy information to generate a policy measurement value; The electronic device records the policy metric value in the memory of the security processor and adds the policy metric value to the log; The electronic device measures the object identified by the policy information to generate an object measurement value; The electronic device records the object metric value in the memory of the security processor and adds the object metric value to the log. The logs, along with the records of the policy metrics and the object metrics, are used to verify the object.

20. The method of claim 19, wherein, The security processor includes a trusted platform module, and the memory of the security processor includes a platform configuration register (PCR). Recording the strategy metric includes using the strategy metric to expand the PCR, and Recording the object metric includes using the object metric to expand the PCR.

Images