DE102021206609A1 - Secure environment, controller and system comprising these entities - Google Patents

Abstract

A secure environment device for a system has a first interface connectable to a host entity, a second interface connectable to a control entity, and an information store configured to store objects. The secure environment device includes a first status store configured to store first status information related to a status of the system, the first status information being received from the host entity. The secure environment device includes a second status memory configured to store second status information related to the status of the system, the second status information being received from the controller. The secure environment device is configured to provide an object from the information store to the host entity or to the control device based on the second status information.

Description

The present disclosure relates to a secure environment device for a system, a controller for a system, and a system including a secure environment device and a controller. The present disclosure further relates to a secure environment with out-of-band management, and more particularly to a trusted environment with out-of-band management of trusted platform states.

in a secure system, a host can verify the integrity of the system using a secure environment using Root-of-Trust for Storage (RTS), Root-of-Trust for Measurement (RTM), and Root-of-Trust for Reporting (RTR). Based on measurements using RTM, a report using RTR can be generated, which can lead to retrieval of a key or data object to be used in the system using RTS.

There is a need to securely measure, store and report a status of the system.

Thus, one object is to provide a solution for securely measuring, storing and reporting a status of the system.

According to an embodiment, a secure environment device for a system has a first interface connectable to a host entity and a second interface connectable to a control device, for example a trusted environment. The secure environment device includes at least one object and a status store configured to store status information related to a status of the system, the status information being received from the control device. The secure environment is configured to release the object based on the status information.

According to one embodiment, a controller for a system is configured to examine a status of the system to generate status information. The controller has an interface connectable to a secure environment of the system, wherein the controller is configured to store the status information in a memory of the secure environment.

Further embodiments are defined in the dependent claims.

• 1a ein schematisches Blockdiagramm einer Sichere-Umgebung-Vorrichtung gemäß einem Ausführungsbeispiel;
• 1b ein schematisches Blockdiagramm einer Sichere-Umgebung-Vorrichtung gemäß einem Ausführungsbeispiel mit zumindest zwei Statusspeichereinheiten;
• 2 ist ein schematisches Blockdiagramm einer Steuervorrichtung gemäß einem Ausführungsbeispiel;
• 3 ein schematisches Blockdiagramm eines Systems gemäß einem Ausführungsbeispiel;
• 4 ein schematisches Blockdiagramm eines Systems gemäß einem Ausführungsbeispiel, in dem die Sichere-Umgebung-Vorrichtung Statusinformationen von der Host-Entität und von der Steuervorrichtung empfangen kann; und
• 5 ein schematisches Blockdiagramm eines Systems gemäß einem Ausführungsbeispiel, in dem die Steuervorrichtung mit einer zusätzlichen Komponente verbunden ist.

Advantageous exemplary embodiments of the present disclosure are explained in more detail below with reference to the attached drawings. Show it:

• 1a 12 is a schematic block diagram of a secure environment device according to an embodiment;
• 1b 12 shows a schematic block diagram of a secure environment device according to an embodiment with at least two state storage units;
• 2 12 is a schematic block diagram of a control device according to an embodiment;
• 3 12 is a schematic block diagram of a system according to an embodiment;
• 4 12 is a schematic block diagram of a system according to an embodiment in which the secure environment device can receive status information from the host entity and from the control device; and
• 5 12 is a schematic block diagram of a system according to an embodiment, in which the control device is connected to an additional component.

The same or equivalent elements or elements with the same or equivalent functionality are denoted in the following description with the same or equivalent reference numbers, even if they appear in different figures.

In the following description, numerous details are set forth in order to provide a more thorough explanation of exemplary embodiments of the present disclosure. However, it will be appreciated by those skilled in the art that embodiments of the present disclosure may be practiced without these specific details. In other instances, well-known structures and devices are shown in block diagram form rather than in detail in order to obscure example embodiments of the present disclosure. Furthermore, features of the different embodiments described hereinafter may be combined with each other unless specifically noted otherwise.

1a 1 shows a schematic block diagram of a secure environment device 10 ₁ according to an embodiment. The secure environment device 10 can be used for a data system, a computer system, or a secure system. A secure environment can be viewed as a system that implements the controlled storage and use of information. in case of computing data loss, the secure environment can protect specific data, such as personal and/or confidential data. The secure environment device can use cryptography as a means of protecting information.

The secure environment device 10 ₁ has a first interface 12 connectable to a host entity. For example, interface 12 may provide access to a wired or wireless connection, such as a bus or the like.

The secure environment device 10 ₁ has an interface 14 which can be connected to a control device, for example a trusted environment. Interface 14 may use the same or different access technology than interface 12. Interfaces 12 and 14 are implemented to connect to different devices, for example the host entity and the controller.

Secure environment device 10 ₁ includes one or more objects represented by object 18 . For example, the secure environment includes an information store 16 configured to store one or more objects 18, for example information or an item of data, such as a key or other type of data. That is, according to examples, the object may be information type or key type. Alternatively, the object 18 may include or be another component that is protected from access. For example, the object 18 may include at least a portion of data storage, such as non-volatile data storage. That is, the object 18 can be of a structure type, eg memory. The secure environment may include a plurality of objects that are of the same or different types.

The secure environment device 10 ₁ has a status store 26 configured to store status information 28 relating to a status of the system to which the secure environment device may be connected during operation. The status information 28 can be received by the control device, which is connected via the interface 14 .

The secure environment device 10 ₁ can be configured to provide a flexible interface-specific access control (AC) mechanism based on the interface 14. That is, the control device can be granted access while restricting access for other entities is.

The secure environment device 10 ₁ may provide access control to the object 18, specifically a plurality of accessible objects. Access can be controlled based on the status information 28, e.g. granted or denied. Access can be granted to the controller and/or the host entity.

The secure environment device 10 ₁ may be configured to store the state information 28 in the state store 26 independently of the host entity.

That is, host entity 12 may have access to store status information 28 . Compared to the host device, the control device can store the status information 28 in the status memory 26 . Status information 28 may relate to one or more of these components.

1b 10 shows a schematic block diagram of a secure environment device 10 ₂ according to an embodiment. Some specific details are described in connection with the secure environment device 10 ₂ , where the secure environment device 10 ₂ is based on a secure environment device 10 ₁ and has additional functionality in relation to an additional state memory, ie in comparison to the secure environment device 10 ₁ points the secure environment device 10 ₂ has a first status storage unit 22 and a second status storage unit as the status storage 26 of the secure environment device 10 ₁ .

The secure environment device 10 ₂ has the first interface 12 connectable to a host entity. The secure environment device 10 ₂ has the second interface 14 connectable to a control device, for example a trusted environment.

As secure environment device 10 ₁ , secure environment device 10 ₂ includes one or more objects represented by object 18 . For example, the secure environment includes an information store 16 configured to store one or more objects 18, for example information or an item of data, such as a key or other type of data. That is, the object 18 can be information type or key type. Alternatively, the object 18 may include or be another component that is protected from access. For example, the object 18 may include at least a portion of data storage, such as non-volatile data storage. That is, the object 18 can be of a structure type, eg storage. The secure environment may include a plurality of objects that are of the same or different types.

The secure environment device 10 ₂ has a first status memory or storage unit 22 configured to store first status information 24 relating to a status of the system to which the secure environment device is connected during operation can. The first status information 24 can be received from the host entity connected via the first interface 12 and/or from the control device connected via the second interface 14 .

Similarly, the secure environment device 10 ₂ has a second status memory or a second status storage unit as the status memory 26 configured to store the status information described in connection with the secure environment device 10 ₁ as the second status information 28 , which relate to the status of the system. The second status information 28 may be received by the controller, which may be connected to the secure environment device 10 ₂ via the second interface 14 .

That is, the host entity 12 may have access to the status information 24 storage. Compared to the host device, the control device can store the first status information 24 in the first status memory 22 and/or the second status information 28 in the second status memory 26 . Host entity access to the second state memory 26 may be limited or prevented, while controller access to the first state memory 22 may be enabled. The first status information 24 and the second status information 28 can relate to the same system, with the system being able to have a plurality of components. Status information 24 and/or 28 may relate to one or more of these components, such that status information 24 and status information 28 may indicate the same or different information, although pertaining to the same system.

According to embodiments, the first status information can relate to a hardware status, a firmware status, a software status of one or more components of the system, for example. The second status information 28 can, for example, relate to a hardware status, a firmware status and/or a software status of one or more components that are the same or different components compared to the first status information 24 .

The secure environment device 10 ₂ is configured to release an object, such as the object 18 , stored in the information store 16 . Releasing the object may allow one or more operations based on the object 18. For example, the object 18 can be enabled for read access and/or write access if the object is of the memory type, for example. Alternatively or additionally, the enablement may refer to an enablement for use that allows the object to be used, for example for a signing operation or the like, when the object 18 is of the key type, although these examples are not intended to limit the embodiments to such operations.

The object 18 can be released for the host entity and/or for the control device based on the second status information. For example, the status information to that effect can be evaluated whether they have a predefined value and based on this the data object 18 can be released or not. For example, the second status information 28 can indicate a specific hardware version and/or software version of one or more components of the system. For example, the data object 18 can only be provided in a case where there is a correct or expected or predefined version of the component in the system. This makes it possible to prevent the object 18 from being released in an incorrect system. Alternatively or additionally, several or a plurality of objects can be part of the secure environment. A specific object or a specific set of objects thereof can be released, where the released object or objects can match the stored second status information 28, while other objects are not released based on a mismatch with other predefined values. This means that the object to be released can be selected based on the second status information 28, for example based on a hardware version, firmware version and/or a software version of one or more components of the system.

The secure environment device 10 ₂ may be configured to store the second state information 28 in the second state store 26 independently of the host entity. According to an exemplary embodiment, the control device can be granted access to the first status memory 22 so that the control device can store the first status information 24 in the first status memory 22 . According to one embodiment, both accesses to the first status memory 22 and the second status memory 26 can be independent of one another, at least with regard to write access and optionally also to read access. According to one embodiment, the host entity may be granted read access to the second state memory 26, ie read the second state information 28, while the secure environment device 10 ₂ may be configured to not allow the host entity write access to the second state information 28 to grant. This may allow the host entity to rely on results determined by the controller device while at the same time securing manipulation of the second status information 28 by the host device. This can enable access control to the second status memory 24 .

According to embodiments, the control device can expand or read status information 28 in or from the second status memory 26 . It is possible that the control device also expands and/or reads the first status information 24 of the first status memory 22 . However, the host entity may expand the first state information 24 of the first state store 22 while having no or limited access to the second state store 26, e.g. the host may be restricted to expand the status information 28 and/or read the same. In other words, even if the host entity can extend the first status information 24, this is not a security problem because the extension operation has the specific property that it always includes the previous status information and thereby cannot write/overwrite the previous status directly.

According to one embodiment, the secure environment device 10 ₂ may provide root-of-trust-for-storage (RTS) and root-of-trust-for-reporting (RTR) functionality for the system.

According to one embodiment, the secure environment device 10 ₂ may be configured to release an object, such as the object 18, only when the second status information 28 is equal to the second predefined status information. For example, a respective object, for example a key, is only released when a correct status, such as a hardware status, a software status and/or a firmware status is determined and/or an object corresponding to the determined status corresponds is selected to be released from a set of objects.

According to an embodiment, the secure environment device 10 ₂ may be configured to release an object only when the first status information 24 is equal to the predefined status information, for example to implement an access control based on the first status information 24 . Optionally, an additional verification can check whether the second status information 28 is also equal to the second predefined status information, i.e. implementing a further access control based on the second status information 28. In other words, according to an embodiment, the release of an object can only be based on the first status information 24 based.

The interface 14 makes it possible to provide a flexible interface-specific access control (AC) mechanism, such as a secure channel (Secure Channel) for modifying the status information. This AC can be specific to modifying the status information 28. Additional AC or AC implemented as an alternative relate to access to objects or other information.

The secure environment device 10 ₂ may include or be a Trusted Platform Module (TPM) device.

2 shows a schematic block diagram of a control device 20 according to an embodiment. The control device 20 may be implemented to be part of a system, for example a similar system compared to the secure environment device 10 ₂ . The controller 20 is configured to measure or determine a status of the system to generate status information 32, which may be, for example, the status information 28 stored in the secure environment device 10 ₂ . While measuring status may relate more to examining the status of software or firmware, determining may relate more to examining hardware components, while one term is not exclusive of the other.

The status can relate to one or more components of the system. The components examined may include the control device 20 itself and/or other components.

The control device 20 has an interface 34 which can be connected to a secure environment device 10 ₂ of the system. That is, interface 34 may match interface 14. According to an embodiment, the control device 20 is configured to store, ie create, ie expand existing status information in a memory of the secure environment device 10 ₂ . For example, status information 32 may represent an actual status and status information 28 may represent information obtained based thereon. For example, existing status information can be expanded by using actual status information 32 .

die anzeigt, dass neue Statusinformationen 28, angezeigt als Status_Neu, basierend auf einem Digest-Algorithmus erhalten werden, z. B. einer Hash-Operation basierend auf einem existierenden alten Status Status_ALT, die zusammen mit einem bestimmten gemessenen Status Status_Gemessen einer Verkettung unterzogen wird, Statusinformationen 32.Augmenting state information may refer to augmenting existing state information using an augment operation, such as "with an augment operation defined as follows: $${\text{status}}_{\text{New}}=\text{digest}-\text{algorithm}\left({\text{status}}_{\text{Old}}\Vert {\text{status}}_{\text{Measured}}\right)$$

indicating that new status information 28, indicated as Status _New , is obtained based on a digest algorithm, e.g. B. a hash operation based on an existing old status Status _ALT , which is concatenated together with a certain measured status Status _Measured , status information 32.

In other words, the _Measured status can be provided as status information 32 to the secure environment device and the _New status can be calculated as described in the secure environment, resulting in status information 28 .

Although embodiments do not prevent the status information 32 from being stored directly, some embodiments relate to a controller 20 determining or measuring the status 32 and sending or providing it to the secure environment. The secure environment may perform an internal augmentation operation, which may result in status information 28.

To generate the status information 32, the control device 20 can evaluate a status of at least one component 36 of the system in order to obtain the measured status. Such components may be, for example, volatile and/or non-volatile memory, a processing unit, other types of hardware, software, and/or firmware. The control device 20 can generate the status information 32 directly via a connection 38 to the component 36, but can also use access to a measurement infrastructure that measures the status for the control device 20 as an alternative or in addition.

That is, connection 36 may be a direct connection or an indirect connection to component 36 and/or additional components.

According to one embodiment, the controller 20 has a root-of-trust-for-measurement (RTM) functionality for the system.

According to one embodiment, the controller 20 may be configured to repeatedly determine the status information 32 and store the status information, e.g. B. the second status information 28 in the memory of the secure environment device, e.g. B. the second status memory 26 to expand and / or reset. According to one embodiment, the reset operation can be triggered via the second interface 14 . According to some embodiments, the second interface 14 may be the only interface to trigger the reset operation.

3 12 shows a schematic block diagram of a system 30 according to an embodiment. The system 30 includes the secure environment device 10 ₂ and the controller 20 connected to the secure environment device via a connection between the second interface 14 of the secure environment device 10 ₂ and the interface 34 of the controller 20 is. The status information 32 provided by the controller 20 may correspond to the second status information 28 associated with 1 have been described.

The system 30 further includes a host device 42, which may include, for example, a processing unit such as a central processing unit (CPU) or the like. The host entity 42 is coupled to the secure environment device 10 ₂ via the first interface 12 and is configured to determine the first state information 24 and store it in the first state store 22 based on granted access thereto.

The secure environment device 10 ₂ may release the object 18 to the host entity 42 upon request and based on the first status information 24, the second status information 28, or a combination thereof and/or may release the object 18 to the controller 20 Release request and based on the first status information 24, the second status information 28 or a combination thereof. As described, in one embodiment, objects are shared with controller 20 only when the objects are not shared with host entity 42 . In such an embodiment, instead of the host entity 42, the controller 20 may request the objects.

According to one embodiment, both host entity 42 and controller 20 may request release of objects. For example, the question of whether and/or which object is to be released for the host entity 42 can be based on the first status information 24 and/or the second status information 28 . For example, if mach relies on the second status information 28 when providing an object to the host entity 42, exploitation can be made of the fact that the control device 20 is regarded as a secure device. However, there is an additional benefit of relying on the status information 32 provided by the controller 20 . The host entity 42 can perform a boot operation or can be kept in the reset state, for example via the controller or another entity. During such instances, regular operation of the host entity 42 may be disrupted or not yet provisioned. However, during such times, controller 20 may be operational and provide beneficial system 30 status information. That is, the controller 20 may be configured to determine and store the first status information 24 and/or the second status information 28/32 prior to a boot procedure of the system 30 controlled by the host entity 42. This does not prevent the generation of the second status information 28/32 after such a boot procedure. Alternatively or additionally, the first and/or second status information may be determined and stored while the system is performing a power management procedure, such as a sleep mode or a hibernation mode. Alternatively or additionally, the first and/or second status information may be determined and stored based on a policy of the controller, which may result in each appropriate time instance being identified, for example by the policy.

As described, the first status information 24 and the second status information 28 can relate to the same component or different components of the system and/or a same or different set of components, with each set having at least one component, with the different sets having a same or have different numbers of components.

4 12 shows a schematic block diagram of a system 40 according to an embodiment. The system 40 includes the host entity 42, which is, for example, a CPU. Furthermore, component 36 may be implemented as an external non-volatile memory component of system 40 .

In this embodiment, component 36 can be accessed by both host entity 42 and controller 20 forming a trusted environment, eg, as an embedded controller. The host entity 42 may have a data connection 44 with the component 36 and may be adapted to perform at least one read operation 46 on the non-volatile memory component. The data connection 44 can be a direct connection or an indirect connection. An indirect connection may include the host entity 42 not having a direct physical connection to the component 36 but having indirect access, eg via the controller.

Furthermore, the host entity 42 may be configured to designate the first status information 24 as a storage status and may store such information indicated as status _H , ie status information designated by the host. The host entity may add such information to the first state store 22 during a respective operation 48 . However, such a measurement may be optional based on implementing the controller 20 with the capability for such measurements.

The secure environment device 10 ₂ may perform access control (AC) 52 on objects stored in the information store 16 and may provide objects from the information store 16 via the first interface or host interface 12 . This allows the host entity 42 to use the provided object 54.

As a further operation of the system 40, the controller 20 may perform a validity check 56 of the component 36, for example in a case where the host entity 42 is reset. That is, it can examine the component 36 for the same or different properties compared to the memory status 24 . The respective second status information 28/32 can be expanded into the second status memory 26 or the first status memory 22. State memories 22 and 26 may implement independent memories, such as Integrity Protected Registers (IPR). In order to provide the respective status information, the same can be triggered via a request from the secure environment device 10 ₂ and/or can be provided regularly or irregularly, e.g. B. triggered by the control device 20.

The secure environment device 10 ₂ may perform another access control operation 28 on the same or different information storage 16 objects based on the second status information 28/32 contained in 4 are displayed as status _TE .

The second interface 14 can be used to request the control device 20 to provide the second status information 28/32 and/or to receive this status information.

The secure environment device 10 ₂ may be augmented with additional status information, the second status information 28 and a separate interface 14, which may also be referred to as an out-of-band responder interface. The additional interface may allow access control (AC) of objects such as keys depending on status 24 (status _H ) and/or status 28 (status _TE ). The out-of-band responder interface may provide a flexible interface-specific access control (AC) mechanism, such as a secure channel, for Secure Environment (SE) services that modify _H and/or _TE status. That is, as compared to the host entity 42, another entity may have access to secured storage via the interface 14 to store status information.

A control interface 14 may be arranged between the trusted environment 20 and the secure environment device 10 ₂ to use SE services to update or extend status _TE securely. The host entity can be a known host entity and can read the memory state with a read operation 46 and can use standardized SE services to update the memory state to the _H state and use key objects via the host interface 12 . The system 40 can thus provide a trusted environment solution to securely release (independent of the host) objects/keys in a secure environment, which can then be used via the host entity and/or the controller.

A known secure environment may include or be a discrete standardized TPM, with a general object (key) store, state _H , and a host interface to enforce access control (AC) of objects/keys dependent on state _H. In a known system, a trusted environment can validate that the platform state information is non-volatile gen storage component are correct. According to embodiments, such information is then stored in a state memory of the secure environment device 10 ₂ . In such a known system only the host entity can release objects/keys in the secure environment as a function of the platform state, which can then be used via the host entity. Embodiments provide a solution for a trusted environment to securely release objects/keys in the secure environment independent of the host entity, where the objects/keys may be used by the host entity.

In a known structure, a secure environment can itself determine a status _SE , eg of the component evaluated by the host entity, and can have a separate non-volatile memory (NVM) master interface to enable the secure environment itself to update (“enable”) the storage status _SE to enforce access control (AC) of objects (keys) depending on status _H and/or status _SE . Although this can enforce the secure environment which itself (possibly independent of the host entity) can release objects (keys) in the secure environment which can then be used via the host, this solution does not work for existing trusted environments to objects to the secure environment, which can then be used via the host entity.

As described, the status information 28 provided by the controller 20 may relate to the same component or different components of the system as compared to the status information 24 provided by the host entity.

5 12 shows a schematic block diagram of a system 50 that extends the system 40. FIG. For example, the secure environment device 10 ₂ may include a TPM chip. Controller 20 may be implemented as an embedded controller and/or host entity 42 may include a CPU, while external component 36 ₁ may include NOR flash memory operated to store system firmware. That is, the NVM memory component 36 ₁ may include an SPI NOR flash storing system firmware/BIOS, eg, for the host entity 42. The component 36 ₁ may be read by the host entity 42, but may, for example be connected to the control device 20 via the data connection 44 ₁ . However, the host entity 42 may determine the first status information 24 as a memory status of the component 36 ₁ via the indirect connection using, for example, a direct or indirect data connection 62 to the controller 20, e.g. B. an eSPI connection.

The controller 20 can be controlled by another data link 44 ₂ , e.g. an SPI connection, to another component 36 ₂ of the system 50 . Component 36 ₂ may include SPI NOR flash memory operable compared to component 36 ₁ to store different firmware indicated as EC (embedded controller) firmware used to operate the controller 20. That is, the control device 20 can be equipped with a separate dedicated, e.g. B. private SPI NOR flash that stores the embedded controller firmware. The component 36 ₂ can be evaluated according to the first status information 24 and/or the second status information 28/32. 5 shows the control device to be configured to expand the first status information 24 in the first status memory 22.

For example, the operation of the system 50 may have a first phase, e.g., a setup/provisioning phase, and a second phase, e.g. B. a platform boot phase. The first phase can be performed before the second phase, but is not necessarily the first phase. The second phase can be performed after the first phase, allowing but not requiring intermediate phases.

A. Setup/Deployment Phase

1. During the first phase, in a first step, the secure environment device 10 ₂ may provide a generic object/key store for use, eg, a TPM key store, eg, the information store 16 . During a particular life cycle or provisioning process, provisioning software running on the host entity 42 may cause the host entity to define and/or create an object, such as a TPM key object, via the TPM SPI host interface 12 /provided to connect its usage via the access control 52 to a specific acknowledged platform state expected in the PCR _TE and/or PCR _H , e.g. predefined status information.

B. Platform Boot Phase

• • eine statische Messung der Systemfirmware, die in der Komponente 36₁ gespeichert ist, z. B. über einen Zugriff auf den SPI-NOR-Flash 36₁ in der Bootphase
• • optional eine statische Messung der eigenen eingebetteten Steuerfirmware, die in der Komponente 36₂ gespeichert ist
• • optional Authentifizierungsmessungen von Komponentenfirmware über ein Protokoll über einen I2C-Bus (nicht gezeigt) und/oder andere Messungen, um Messergebnisse zu erhalten.

1. During the second phase, the host entity 42 can be kept in the reset state in a first step. When host entity 42 is maintained in the reset state, controller 20 may perform/recover one or more of the following:

• • a static measurement of the system firmware stored in component 36 ₁ , e.g. B. via access to the SPI NOR Flash 36 ₁ in the boot phase
• • optionally a static measurement of own embedded control firmware stored in component 36 ₂
• • optionally, component firmware authentication measurements via protocol over an I2C bus (not shown) and/or other measurements to obtain measurement results.

2. During the second phase, in a second step, the controller 20 may initiate communication on the TPM out-of-band I2C interface, i.e. using the second interface 14. For example, the controller 20 may operate according to a protocol such as the Global Platform Secure Channel Protocol 03 (GP SCP03).

3. During the second phase, the control device 20 can, in a third step, expand the measurement result/the measurement status from step 1 into the first status memory 22 and/or the second status memory 26, which, for example, has one or more platform configuration registers PCR, to include the second status information 28 (Status _TE ) representing the status _TE of the TPM. The access control mechanism at the TPM out-of-band interface 14 can be referred to as a flexible locale representing, for example, the cryptographic secure channel GP SCP03 over I2C between the secure environment device 10 ₂ and the control device 20 used to access the platform configuration register 26 (PCR _TE ).

4. During the second phase, in a fourth step, the controller 20 may release the host entity 42 from the reset state and begin booting.

5. During the second phase, in a fifth step, eg caused by respective software, the host entity 42 can only use the TPM key object key _TE , which is generated in step 1 at the deployment phase, to sign or decrypt data , via the TPM SPI host interface 12 if the reported platform state in the PCR _TE and/or PCR _H of step 3 satisfies the access control of a specific recognized platform state defined during the provisioning phase.

Embodiments allow a manufacturer of a system, e.g. B. a PC platform that can also provide the controller to have a high degree of control over the use of TPM objects on the host entity 42, i.e., host CPU and/or host software as a function of the platform health, regardless of the CPU manufacturer.

In other words, according to this embodiment, the secure environment device may be or include a TPM chip that includes RTS and RTR functionality, and the OoB entity is a platform RoT chip that includes RTM functionality includes or exhibits such.

• • statische Messungen von Systemfirmware über Zugriff auf die SPI-NV-Speicherkomponente beim Booten
• • authentifizierte Messungen der Komponentenfirmware durch ein Protokoll über einen I1C-Bus
• • statische Messung der eigenen Plattform-RoT-Firmware

1. While the main CPU/SoC is kept in the reset state, the RTM performs/recovers the following

• • Static measurements of system firmware via access to the SPI-NV memory component at boot
• • Authenticated component firmware measurements through a protocol over an I1C bus
• • static measurement of own platform RoT firmware

2. The RTM uses the TPM out-of-band interface, such as an I2C bus, to extend the measurement result/status into a Protected Integrity (IPR) register that is part of the Root-of-Trust for Storage (RTS ) is. An access control mechanism at the TPM out-of-band interface called flexible locality that provides a cryptographically secure channel over I2C between the TPM and Platform RoT is used to control access to the IPR(s). The main CPU/SoC is released from the reset state and starts booting.

3. The RTS provides a common object/key store for use, such as a TPM key store, and allows host software via the TPM host interface to define flexible access control for keys, such as use of an identity key to specify measurements stored in the IPR provided over the TPM out-of-band interface.

As an alternative, the platform RoT can use the TPM key store via the TPM OoB interface completely independently of the main CPU/SoC. It can encryptly define flexible access control, such as usage tied to specific metrics or to the flexible locality secure channel of the OoB interface.

4. RTR can sign measurement results stored in the IPR. These signed measurements provided by the TPM out-of-band interface can then be retrieved via the TPM host interface.

As an alternative, the signed measurements could be provided to the management infrastructure via a separate channel, such as a baseband management controller, if supported across the platform independent of the main CPU/SoC. In this case, the measurements are provided via the platform RoT's TPM out-of-band interface, which is connected to, for example, a baseband management controller.

Example embodiments enable the use of a standardized security-certified secure element, such as a TPM. More specifically, it provides a general TPMT store that allows host software to define (and use) access controls for TPM/NVM objects in a standardized way, based on static or dynamic measurement processes, completely independent of the main CPU of a full platform firmware. Embodiments allow the platform Root of Trust (RoT) to access a common TPM key store completely independent of the main CPU (SoC, System on a Chip).

1. 1. Root-of-Trust for Measurement (RTM) kann die anfängliche Integritätsmessung der Firmware durchführen. Der Messprozess kann bei dem Plattformrücksetz/bootprozess (der eine statische RTM) darstellt, statisch sein oder während einer Plattformlauftime dynamisch sein, ohne die Notwendigkeit, die Plattform neu zu booten (was eine D-RTM darstellt).
2. 2. Die RTM kann das Messergebnis/den Messstatus in ein Register mit geschützter Integrität (IPR) erweitern, das Teil der Root-of-Trust for Storage (RTS) ist.
3. 3. Root-of-Trust for Storage kann Integritäts und Vertrauenswürdigkeitsspeicher für Daten bereitstellen. Für das TPM enthält es einen allgemeinen Objekt/Schlüsselspeicher für vertraulich geschützte Objekte, wie zum Beispiel kryptographische Schlüssel. Dies ermöglicht der externen Host-Software, Schlüssel zur erzeugen und zu verwenden, und flexible Zugriffssteuerrichtlinien für Schlüssel auf einen definierten gemessenen Plattformstatus zu definieren.

Embodiments may use one or more of RTM, RTS, and RTR.

1. 1. Root of Trust for Measurement (RTM) can perform the initial integrity measurement of the firmware. The measurement process can be static at the platform reset/boot process (representing a static RTM) or dynamic during platform runtime without the need to reboot the platform (representing a D-RTM).
2. 2. The RTM can extend the measurement result/status into a Protected Integrity (IPR) register that is part of the Root-of-Trust for Storage (RTS).
3. 3. Root-of-Trust for Storage can provide integrity and trust storage for data. For the TPM, it contains a common object/key store for sensitive protected objects such as cryptographic keys. This allows the external host software to generate and use keys, and define flexible key access control policies on a defined metered platform state.

Root-of-Trust for Reporting (RTR) can reliably provide authenticity and non-repudiation services for the purpose of confirming the origin and integrity of platform characteristics/status.

Therefore, it is possible to securely measure, store, and report the hardware, software, and/or firmware characteristics/status of a trusted computing platform that has booted and is running on the platform. This may allow a verifier, such as a remote server, to verify the current hardware/firmware/software status of the platform. Furthermore, embodiments may solve the problem of providing access control for local objects, such as cryptographic keys, to an authorized firmware/software state of the platform.

• Aspekt 1. Eine Sichere-Umgebung-Vorrichtung (10) für ein System, wobei die Sichere-Umgebung-Vorrichtung folgende Merkmale aufweist:
  • eine erste Schnittstelle (12), die mit einer Host-Entität (42) verbindbar ist;
  • eine zweite Schnittstelle (14), die mit einer Steuervorrichtung (20) verbindbar ist;
  • zumindest ein Objekt (18);
  • einen Statusspeicher (26), der konfiguriert ist zum Speichern von Statusinformationen (28, 32), die sich auf den Status des Systems beziehen, wobei die Statusinformationen (28, 32) von einer Steuervorrichtung (20) empfangen werden;
  • wobei die Sichere-Umgebung-Vorrichtung konfiguriert ist zum Freigeben eines Objekts (18) für einen Zugriff basierend auf den Statusinformationen (28, 32).
• Aspekt 2. Die Sichere-Umgebung-Vorrichtung gemäß Aspekt 1, wobei der Statusspeicher eine erste Statusspeichereinheit (22) und eine zweite Statusspeichereinheit (26) aufweist, wobei die Statusinformationen zweite Statusinformationen (28) sind; wobei die Sichere-Umgebung-Vorrichtung konfiguriert ist zum Speichern erster Statusinformationen (24), die sich auf einen Status des Systems beziehen, wobei die ersten Statusinformationen (24) von der Host-Entität (42) empfangen werden; und wobei die Sichere-Umgebung-Vorrichtung konfiguriert ist zum Speichern der zweiten Statusinformationen (28), die von der Steuervorrichtung (20) empfangen werden.
• Aspekt 3. Die Sichere-Umgebung-Vorrichtung gemäß Aspekt 1 oder 2, die konfiguriert ist zum Speichern der Statusinformationen (28, 32) in den Statusspeicher (26), unabhängig von der Host-Entität (42).
• Aspekt 4. Die Sichere-Umgebung-Vorrichtung gemäß einem der vorherigen Aspekte, die konfiguriert ist, es der Host-Entität (42) zu ermöglichen, die zweiten Statusinformationen (28, 32) zu nutzen, während der Host-Entität (42) kein Schreibzugriff auf die zweiten Statusinformationen (28, 32) gewährt wird.
• Aspekt 5. Die Sichere-Umgebung-Vorrichtung gemäß einem der vorhergehenden Aspekte, die eine Root-of-Trust-for-Storage- und eine Root-of-Trust-for-Reporting-Funktionalität für das System aufweist.
• Aspekt 6. Die Sichere-Umgebung-Vorrichtung gemäß einem der vorhergehenden Aspekte, die konfiguriert ist, um ein Objekt (18) nur freizugeben, wenn die zweiten Statusinformationen (28, 32) gleich zweiten vordefinierten Statusinformationen sind.
• Aspekt 7. Die Sichere-Umgebung-Vorrichtung gemäß einem der vorhergehenden Aspekte, die konfiguriert ist, ein Objekt (18) nur freizugeben, wenn:
  • die ersten Statusinformationen (24) gleich ersten vordefinierten Statusinformationen sind; und
  • die zweiten Statusinformationen (28, 32) gleich zweiten vordefinierten Statusinformationen sind.
• Aspekt 8. Die Sichere-Umgebung-Vorrichtung gemäß einem der vorhergehenden Aspekte, die ein Trusted-Platform-Module-Bauelement aufweist.
• Aspekt 9. Die Sichere-Umgebung-Vorrichtung gemäß einem der vorhergehenden Aspekte, wobei die Sichere-Umgebung-Vorrichtung konfiguriert ist für einen flexiblen schnittstellenspezifischen Zugriffssteuerung(AC)-Mechanismus, der auf der Schnittstelle (14) basiert.
• Aspekt 10. Eine Steuervorrichtung für ein System, wobei die Steuervorrichtung (20) konfiguriert ist zum Untersuchen eines Status des Systems zum Erzeugen von Statusinformationen (32); wobei die Steuervorrichtung (20) eine Schnittstelle aufweist, die mit einer Sichere-Umgebung-Vorrichtung (10) des Systems verbindbar ist; wobei die Steuervorrichtung (20) konfiguriert ist zum Speichern der Statusinformationen (32) in einem Speicher der Sichere-Umgebung-Vorrichtung.
• Aspekt 11. Die Steuervorrichtung gemäß Aspekt 10, wobei die Steuervorrichtung (20) eine Root-of-Trust-for-Measurement-Funktionalität für das System aufweist.
• Aspekt 12. Die Steuervorrichtung gemäß Aspekt 10 oder 11, die konfiguriert ist zum Untersuchen eines Status der Steuervorrichtung zum Bestimmen zumindest eines Teils des Status des Systems.
• Aspekt 13. Die Steuervorrichtung gemäß einem der Aspekte 10 bis 12, wobei die Steuervorrichtung (20) konfiguriert ist zum wiederholten Bestimmen der Statusinformationen (32) und zum Erweitern und/oder Zurücksetzen der gespeicherten Statusinformationen in dem Speicher der sicheren Umgebung.
• Aspekt 14. Die Steuervorrichtung gemäß einem der Aspekte 10 bis 13, wobei die Steuervorrichtung (20) konfiguriert ist zum Bestimmen der Statusinformationen (32) basierend auf zumindest einer von einer Software-Version von zumindest einer Komponente des Systems, einer Firmware-Version von zumindest einer Komponente des Systems und einer Hardware-Version von zumindest einer Komponente des Systems.
• Aspekt 15. System, das folgende Merkmale aufweist:
  • eine Sichere-Umgebung-Vorrichtung (10) gemäß einem der Aspekte 1 bis 9;
  • eine Steuervorrichtung (20) gemäß einem der Aspekte 10 bis 14, die über die zweite Schnittstelle (14) mit der Sichere-Umgebung-Vorrichtung (10) verbunden ist; und
  • eine Host-Entität (42), die über die erste Schnittstelle (12) mit der Sichere-Umgebung-Vorrichtung verbunden ist;
  • wobei die Steuervorrichtung (20) konfiguriert ist zum Untersuchen eines Status des Systems zum Erzeugen der Statusinformationen (24, 28, 32) und zum Speichern der Statusinformationen (28, 32) in der Sichere-Umgebung-Vorrichtung.
• Aspekt 16. Das System gemäß Aspekt 15, bei dem die Steuervorrichtung (20) konfiguriert ist zum Bestimmen und Speichern der ersten Statusinformationen (24) oder der zweiten Statusinformationen (28, 32) vor einer Bootprozedur oder während einer Leistungsverwaltungsprozedur des Systems, gesteuert durch die Host-Entität (42) oder basierend auf einer Richtlinie der Steuervorrichtung (20).

Some aspects described herein can be expressed as follows:

• Aspect 1. A secure environment device (10) for a system, the secure environment device having the following features:
  • a first interface (12) connectable to a host entity (42);
  • a second interface (14) which can be connected to a control device (20);
  • at least one object (18);
  • a status memory (26) configured to store status information (28, 32) related to the status of the system, the status information (28, 32) being received from a controller (20);
  • wherein the secure environment device is configured to enable an object (18) for access based on the status information (28, 32).
• Aspect 2. The secure environment apparatus according to aspect 1, wherein the status storage comprises a first status storage unit (22) and a second status storage unit (26), the status information being second status information (28); wherein the secure environment device is configured to store first status information (24) related to a status of the system, the first status information (24) being received from the host entity (42); and wherein the secure environment device is configured to store the second status information (28) received from the control device (20).
• Aspect 3. The secure environment device according to aspect 1 or 2, configured to store the state information (28, 32) in the state memory (26) independently of the host entity (42).
• Aspect 4. The secure environment apparatus of any preceding aspect, configured to allow the host entity (42) to utilize the second status information (28, 32) while the host entity (42) does not Write access to the second status information (28, 32) is granted.
• Aspect 5. The secure environment apparatus according to any preceding aspect, having root of trust for storage and root of trust for reporting functionality for the system.
• Aspect 6. The secure environment apparatus of any preceding aspect, configured to release an object (18) only if the second status information (28, 32) equals second predefined status information.
• Aspect 7. The secure environment device according to any of the preceding aspects, configured to release an object (18) only if:
  • the first status information (24) equals first predefined status information; and
  • the second status information (28, 32) equals second predefined status information.
• Aspect 8. The secure environment apparatus of any preceding aspect, comprising a Trusted Platform Module device.
• Aspect 9. The secure environment device according to any of the preceding aspects, wherein the secure environment device is configured for a flexible interface specific access control (AC) mechanism based on the interface (14).
• Aspect 10. A controller for a system, the controller (20) being configured to examine a status of the system to generate status information (32); the control device (20) having an interface connectable to a secure environment device (10) of the system; wherein the control device (20) is configured to store the status information (32) in a memory of the secure environment device.
• Aspect 11. The controller of aspect 10, wherein the controller (20) has root-of-trust-for-measurement functionality for the system.
• Aspect 12. The controller according to aspect 10 or 11, configured to examine a status of the controller to determine at least a part of the status of the system.
• Aspect 13. The controller according to any one of aspects 10 to 12, wherein the controller (20) is configured to repeatedly determine the status information (32) and to expand and/or reset the stored status information in the secure environment memory.
• Aspect 14. The controller according to any one of aspects 10 to 13, wherein the controller (20) is configured to determine the status information (32) based on at least one of a software version of at least one component of the system, a firmware version of at least a component of the system and a hardware version of at least one component of the system.
• Aspect 15. A system having the following characteristics:
  • a secure environment device (10) according to any one of aspects 1 to 9;
  • a controller (20) according to any one of aspects 10 to 14 connected to the secure environment device (10) via the second interface (14); and
  • a host entity (42) connected to the secure environment device via the first interface (12);
  • wherein the control device (20) is configured to examine a status of the system for generating the status information (24, 28, 32) and for storing the status information (28, 32) in the secure environment device.
• Aspect 16. The system according to aspect 15, wherein the controller (20) is configured to determine and store the first status information (24) or the second status information (28, 32) prior to a boot procedure or during a power management procedure of the system controlled by the host entity (42) or based on a policy of the controller (20).

Although some aspects have been described in the context of a device, it is understood that these aspects also represent a description of the corresponding method, so that a block or a component of a device is also to be understood as a corresponding method step or as a feature of a method step. Similarly, aspects described in connection with or as a method step also constitute a description of a corresponding block or detail or feature of a corresponding device.

Depending on particular implementation requirements, embodiments of the invention may be implemented in hardware or in software. Implementation can be performed using a digital storage medium such as a floppy disk, DVD, Blu-ray Disc, CD, ROM, PROM, EPROM, EEPROM or FLASH memory, hard disk or other magnetic or optical memory, on which electronically readable control signals are stored, which can interact or interact with a programmable computer system in such a way that the respective method is carried out.

Some embodiments according to the invention include a data carrier having electronically readable control signals capable of interacting with a programmable computer system to perform any of the methods described herein.

In general, embodiments of the present invention can be implemented as a computer program product with a program code, wherein the program code is effective to perform one of the methods when the computer program product runs on a computer. The program code can also be stored on a machine-readable carrier, for example.

Other exemplary embodiments include the computer program for performing one of the methods described herein, the computer program being stored on a machine-readable carrier.

In other words, an exemplary embodiment of the method according to the invention is therefore a computer program that has a program code for performing one of the methods described herein when the computer program runs on a computer.

A further exemplary embodiment of the method according to the invention is therefore a data carrier (or a digital storage medium or a computer-readable medium) on which the computer program for carrying out one of the methods described herein is recorded.

A further exemplary embodiment of the method according to the invention is therefore a data stream or a sequence of signals which the computer program for carrying out one of the herein described method represents or represent. For example, the data stream or sequence of signals may be configured to be transmitted over a data communications link, such as the Internet.

Another embodiment includes a processing device, such as a computer or programmable logic device, configured or adapted to perform any of the methods described herein.

Another embodiment includes a computer on which the computer program for performing one of the methods described herein is installed.

In some embodiments, a programmable logic device (e.g., a field programmable gate array, an FPGA) may be used to perform some or all of the functionality of the methods described herein. In some embodiments, a field programmable gate array may cooperate with a microprocessor to perform any of the methods described herein. In general, the methods are preferably performed by any hardware device.

The embodiments described above are merely illustrative of the principles of the present invention. It is understood that modifications and variations to the arrangements and details described herein will occur to those skilled in the art. Therefore, it is intended that the invention be limited only by the scope of the following claims and not by the specific details presented in the description and explanation of the embodiments herein.

Claims (16)

A secure environment device (10) for a system, the secure environment device having the following features: a first interface (12) connectable to a host entity (42); a second interface (14) which can be connected to a control device (20); at least one object (18); a status memory (26) configured to store status information (28, 32) related to the status of the system, the status information (28, 32) being received from a controller (20); wherein the secure environment device is configured to enable an object (18) for access based on the status information (28, 32). The Secure Environment Device according to claim 1 , in which the status memory has a first status memory unit (22) and a second status memory unit (26), the status information being second status information (28); wherein the secure environment device is configured to store first status information (24) related to a status of the system, the first status information (24) being received from the host entity (42); and wherein the secure environment device is configured to store the second status information (28) received from the control device (20). The Secure Environment Device according to claim 1 or 2 configured to store the state information (28, 32) in the state store (26) independently of the host entity (42). The secure environment apparatus of any preceding claim configured to allow the host entity (42) to utilize the second status information (28, 32) while the host entity (42) does not have write access to the second status information (28, 32) is granted. The secure environment apparatus of any preceding claim having root of trust for storage and root of trust for reporting functionality for the system. The secure environment apparatus of any preceding claim configured to release an object (18) only if the second status information (28, 32) equals second predefined status information. The secure environment apparatus of any preceding claim configured to release an object (18) only if: the first status information (24) equals first predefined status information; and the second status information (28, 32) is equal to second predefined status information. The secure environment apparatus of any preceding claim, comprising a Trusted Platform Module device. The secure environment device of any preceding claim, wherein the secure environment device is configured for a flexible interface specific access control (AC) mechanism based on the interface (14). A controller for a system, the controller (20) being configured to examine a status of the system to generate status information (32); the control device (20) having an interface connectable to a secure environment device (10) of the system; wherein the control device (20) is configured to store the status information (32) in a memory of the secure environment device. The control device according to claim 10 , wherein the control device (20) has a root-of-trust-for-measurement functionality for the system. The control device according to claim 10 or 11 configured to examine a status of the controller to determine at least a portion of the status of the system. The control device according to one of Claims 10 until 12 wherein the control device (20) is configured to repeatedly determine the status information (32) and to expand and/or reset the stored status information in the memory of the secure environment. The control device according to one of Claims 10 until 13 , wherein the control device (20) is configured to determine the status information (32) based on at least one of a software version of at least one component of the system, a firmware version of at least one component of the system and a hardware version of at least one component of the system. System having the following features: a secure environment device (10) according to any one of Claims 1 until 9 ; a control device (20) according to any one of Claims 10 until 14 connected to the secure environment device (10) via the second interface (14); and a host entity (42) connected to the secure environment device via the first interface (12); wherein the control device (20) is configured to examine a status of the system for generating the status information (24, 28, 32) and for storing the status information (28, 32) in the secure environment device. The system according to claim 15 wherein the control device (20) is configured to determine and store the first status information (24) or the second status information (28, 32) before a boot procedure or during a power management procedure of the system, controlled by the host entity (42) or based on a directive of the controller (20).

Images