Method for a virtual computing unit to access a hardware security unit in a computing unit

Abstract

The invention relates to a method for a virtual computing unit (1110) to access a hardware security unit (1300), wherein a first execution environment (1100) and a second execution environment (1200) are implemented in a computing unit (1000), wherein applications having a first security level can be executed in the first execution environment (1100), and wherein applications having a second security level, which is higher than the first security level, can be executed in the second execution environment (1200), wherein a plurality of virtual computing units (1110) are implemented in the first execution environment (1100), wherein applications (1111) having the first security level can be executed in each of these virtual computing units (1110), wherein the computing unit (1000) has a hardware security unit (1300), wherein the hardware security unit (1300) is configured to execute security applications, wherein the method comprises the following steps: sending an access request from an application (1111) of a requesting virtual computing unit (1110) for access to the hardware security unit (1300); determining identification information relating to the requesting virtual computing unit (1110) by means of an identification determination unit (1230) in the second execution environment (1200); transmitting the access request together with the determined identification information to the hardware security unit (1300) by means of a transmission unit (1250); carrying out the access in the hardware security unit (1300) depending on the determined identification information in such a way that the access takes place in accordance with an access scope specified for the requesting virtual computing unit (1110).

Description

[0001] Description

[0002] Method for a virtual computing unit to access a hardware security unit in a computing unit

[0003] The present invention relates to a method for accessing a hardware security unit via a virtual computing unit, as well as a computing unit and a computer program for carrying out this method.

[0004] Background of the invention

[0005] A computing unit, such as a control unit or microcontroller of a (motor) vehicle, can implement a multitude of virtual computing units or virtual machines, each of which represents an encapsulation of a computer system with an operating system and application software. A higher-level control or monitoring unit, such as a "hypervisor" or a "virtual machine monitor," can be provided to execute and control the individual virtual machines.

[0006] Furthermore, the computing unit can include a hardware security unit or a so-called hardware security module (HSM), which is isolated from the processing unit's processor unit by special hardware mechanisms. Security applications such as cryptographic operations can be executed by such a hardware security module.

[0007] Access from individual virtual machines to the hardware security module, e.g., for data encryption, can often only be enabled with considerable effort. For example, this may require complex modifications to the hypervisor.

[0008] Disclosure of the invention

[0009] According to the invention, a method for accessing a hardware security unit from a virtual computing unit, as well as a computing unit and a computer program for carrying out this method, are proposed, comprising the features of the independent claims. Advantageous embodiments are the subject of the dependent claims and the following description.

[0010] When the terms "secure" or "security" are used in this context, they should be understood in the sense of information technology security or information security, which is referred to as "security" in English, as opposed to functional security or operational security, which is referred to as "safety" in English. The terms "secure" or "security" in this context are therefore to be understood specifically as information technology access protection, ensuring that data or information cannot be accessed without authorization.

[0011] The computing unit implements a first execution environment and a second execution environment, for example, in a processor unit of the computing unit. In the first execution environment, applications or processes can be executed with a first (information technology or information security) security level. In the second execution environment, applications or processes can be executed with a second security level, which is higher than the first security level. The first execution environment can, in particular, be a regular, non-secure execution environment in which regular application software can be executed. The second execution environment can, in particular, be designed as a secure execution environment, which can be monitored, for example, by a higher-level monitoring unit or security monitoring unit ("Secure Monitor"). The second execution environment can expediently be a so-called...A trusted execution environment (TEE) may be provided. Such a TEE can utilize a dedicated secure area of ​​the processor unit as a secondary execution environment, referred to as the "Secure World." In contrast, the primary, regular execution environment of the processor unit can be called the "Normal World." Access to this secure area can be controlled via special, protected system calls. The TEE can be established, for example, through a special hardware mechanism of the processor unit and, in particular, through peripheral components, thereby strongly isolating the code executed within the TEE environment from other applications.

[0012] In the first execution environment, several virtual computing units or virtual machines are implemented, with applications or processes at the first, low security level executable in each of these virtual computing units. The virtual computing units are each designed as an encapsulation of a computer system, specifically comprising an operating system and application software of the respective encapsulated computer system. A higher-level control or monitoring unit, specifically a so-called "hypervisor" or a "virtual machine monitor," is provided for the execution and control of the individual virtual computing units. This monitoring unit can, in particular, provide an abstraction layer for the hardware of the computing unit.

[0013] The computing unit also includes a hardware security unit (HSM) configured to execute security applications. The HSM is physically separated from the processor unit, specifically through hardware or special hardware mechanisms, and is logically isolated from it. In particular, the HSM is designed as a hardware security module. The applications executable by the processor unit in the first and second execution environments can be regular application software, whereas the security application executable by the HSM can include cryptographic operations, such as data encryption.The hardware security unit makes it possible, in particular, to outsource and execute such cryptographic operations in a secure runtime environment, especially in a subsystem that can be separated from the main system of the computing unit by a hardware shield.

[0014] The present invention provides a means of enabling secure access by a respective application of a respective virtual computing unit to the hardware security unit, in particular without the individual virtual computing units influencing each other and in particular without requiring any changes to the hypervisor.

[0015] For this purpose, an access request is sent from a respective application of a requesting virtual computing unit to the hardware security unit. An identification unit in the second execution environment determines identification information or an identification feature relating to the respective requesting virtual computing unit. This identification information allows the requesting virtual computing unit to be uniquely identified. The identification unit can be implemented as a software unit or as an identification application running in the second execution environment. For example, the identification unit can be implemented as arbitration logic in the secure execution environment.For example, the access request sent by the respective application can be transmitted to the host system via the operating system of the respective virtual processing unit, the hypervisor monitoring the virtual processing units, and the secure monitor of the secure execution environment. From the host system, the access request can be transmitted, for example, via the secure monitor of the secure execution environment to the identification unit. The access request, along with the specified identification information, is then transmitted by a transmission unit within the secure execution environment to the hardware security unit. This transmission unit can also be implemented as a software unit, specifically as a transmission application running within the secure execution environment.For example, the transmission unit may have an interface application or a software interface in the secure execution environment for communication with the hardware security unit, or may be designed as such an interface.

[0016] In the hardware security unit, access is executed based on specific identification information in such a way that access is restricted to a scope of access defined or permitted for the respective requesting virtual computing unit. This means, for example, that access is restricted to data or information defined or permitted by the access scope for the respective requesting virtual computing unit. This access scope is defined, in particular, as an access context or process context ("Process Context," "Task Context"). Such an access scope or process context specifies, in particular, how the respective access or process may proceed, e.g., which data or memory addresses may be accessed, which status or state may be changed, etc.

[0017] In particular, a corresponding access scope is individually defined for each virtual processing unit. Each virtual processing unit can therefore only access the hardware security unit within a specifically defined framework or context. Based on the identification information, it is advantageously possible to clearly trace which virtual processing unit sent the respective access request and to ensure that each virtual processing unit can only access the hardware security unit within its individually defined access scope. In this way, it is advantageously possible to prevent one virtual processing unit from modifying data, information, or the state of a process context of another virtual processing unit.

[0018] Traditionally, virtual machine applications can access a hardware security module (HSM) directly via security mechanisms or special applications in a TEE environment, without considering the identity of the virtual machines or the scope of access granted to them. However, such traditional solutions are often neither efficient nor secure. For example, traditional solutions may employ software implementations of the HSM with a lower security level, such as implementing safety-critical functions in software rather than directly in hardware.Furthermore, extensions to the HSM may be implemented that require close interaction with the hypervisor and significant modifications to the hypervisor, potentially violating the hypervisor's design principles and necessitating extensive hypervisor adjustments. When the HSM is shared, access to it by multiple virtual machines or client applications can be scheduled by a privileged component, such as the hypervisor or a privileged domain. However, this can allow the state of the HSM to be manipulated by one virtual machine, potentially altering its state relative to another. This can compromise the isolation and confidentiality of the virtual machines. Additionally, scheduling conflicts within the HSM may arise, potentially preventing real-time requirements from being met.

[0019] In contrast, the invention provides a means for virtual computing units to access the hardware security module in an information technology-secure manner, in particular without influencing each other or affecting the states of the hardware security module with respect to other virtual computing units. For this purpose, the identification information is determined in the secure execution environment, and the access scopes of the individual virtual computing units are monitored and implemented according to the determined identification information.In this way, the logic of the hardware security unit (HSU) can be migrated to the second execution environment for use in a virtualized environment, and the HSU software can be extended such that the various virtual computing units can be reliably identified through interaction between the HSU and the second execution environment. The functionality of the HSU can be realized, in particular, through a combination of software running in the HSU and software running in the second execution environment. In particular, a high level of security can thus be achieved without modifying or adapting the hypervisor. The invention offers high compatibility with commercially available hypervisor solutions, especially those qualified for the automotive industry.This allows for a high degree of compatibility with the requirements of the automotive industry, e.g. a turnkey solution can be provided without requiring a high level of integration and / or adaptation effort.

[0020] For conventional access from virtual processing units to a hardware security module, a so-called Trusted Platform Module (TPM) can also be used. Such a TPM module can be provided as a hardware security module with special integrated functions and application programming interfaces (APIs). However, unlike hardware security modules specifically designed for the automotive sector, these TPM modules are primarily designed for standard PCs and usually represent external components of the main CPU. These components can be connected via an SPI or USB interface, for example, and are not permanently integrated into an application controller, as is typically the case in the automotive sector with a system-on-a-chip (SoC) concept.The additional serial connection on the printed circuit board (PCB) that connects the TPM module to the CPU package can create additional security risks and potential attack vectors, which may be undesirable in the automotive sector. A conventional TPM module is therefore generally unsuitable for use in the automotive industry. In contrast, the present invention is particularly well-suited for use in the automotive sector. For example, the processing unit can be configured as a control unit, a microcontroller, or a system-on-a-chip platform in a (motor) vehicle. In particular, the processing unit can be used to control vehicle functions, e.g., in the context of engine control, driver assistance functions, etc.

[0021] According to one embodiment, sets of scope information are predefined, with each set of scope information defining a specific access scope for a particular virtual computing unit identified by specific identification information. After determining the identification information, the respective access scope defined for each requesting virtual computing unit is read in, depending on the determined identification information and the sets of scope information. In particular, a set of scope information is predefined for each of the virtual computing units. For example, the individual sets of scope information can be determined before the computing unit is first commissioned, e.g., during a manufacturing or configuration phase.In particular, during this configuration phase, the expected number of virtual computing units can be linked to different contexts of the hardware security unit.

[0022] According to one embodiment, the sets of scope information are monitored by the hardware security device, in particular by a first or HSM-side scope management unit or context management unit within the hardware security device ("HSM Context Manager"). Specifically, according to this embodiment, all sets of scope information are managed, controlled, and protected by the hardware security device itself. In this way, paravirtualization of the hardware security device can be enabled.

[0023] According to one embodiment, the hardware security unit itself, in particular the first scope management unit, reads the access scope specified for each requesting virtual computing unit. Specifically, upon receiving the access request, the first scope management unit reads the access scope specified for the respective requesting virtual computing unit together with the identification information from the sets of scope information.

[0024] According to one embodiment, the sets of scope information are stored in an internal storage unit within the hardware security device itself, particularly in flash memory, e.g., in DFIash memory. Specifically, only the hardware security device can access this internal storage unit. Access to and manipulation of the information stored in the internal storage unit, e.g., by a malicious virtual machine, a malicious TEE environment, or another software component, is specifically not possible. Advantageously, the sets of scope information are protected by a cryptographic key, so that only the hardware security device can access and encrypt the scope information. This key is, in particular, under the complete control of the hardware security device and is advantageously inaccessible outside the hardware security device.This effectively prevents physical attacks, for example, if a debugger is connected to the JTAG controller ("Joint Test Action Group", JTAG) and an attempt is made to extract the contents of the internal storage unit.

[0025] Alternatively or additionally, according to one embodiment, the sets of scope information are stored in an external storage unit outside the hardware security unit, e.g., in external flash memory. In particular, the external storage unit is still fully controlled and protected by the hardware security unit. Advantageously, the external storage unit, or at least the sets of scope information stored therein, are encrypted using a key that only the hardware security unit can access. When using such an external storage unit, it may be more difficult to protect the sets of scope information compared to the internal storage unit, since the external storage unit may not be physically separable from the normal storage unit or the normal flash memory of the processing unit.Therefore, it may be particularly useful to separate the external storage unit of the hardware security unit and the normal storage unit of the computing unit through the hardware architecture of the storage unit, e.g. by using a memory protection unit (MPU), a memory management unit (MMU), or other hardware mechanisms.

[0026] If the scope information is manipulated, for example, through normal API calls to the hardware security device (HSD), such as deleting or adding a cryptographic key, or saving sensitive log data, the HSD should appropriately update the scope information and store it in background storage. This storage of the information in the internal or external storage unit can be triggered autonomously by the HSD or by an external task, such as within the TEE environment. Which of these options is used may depend on the storage or flash technology employed, or on whether the HSD has its own storage or flash driver and can access the storage unit autonomously, or whether it requires a flash driver external to the HSD.

[0027] According to one embodiment, the sets of scope information are managed in the second execution environment, in particular by a second, or TEE-side, scope management unit or context management unit in the second execution environment. This second scope management unit can, in particular, be designed as a software unit or as a scope management application running in the second execution environment. In this case, all sets of scope information are not managed, controlled, and protected by the hardware security unit itself, but by a corresponding mechanism in the secure execution environment, in particular in the TEE environment. In this way, contextual virtualization can be enabled. Advantageously, the second execution environment can, in this case, exert greater control over the processing by the hardware security unit.In particular, this approach allows for greater flexibility and reduced configuration requirements for the hardware security unit. Specifically, it enables the easy addition of extra virtual computing units.

[0028] According to one embodiment, the access scope specified for each requesting virtual computing unit is read in the second execution environment, in particular by the second scope management unit. If the hardware security unit does not manage the scope information itself, this TEE-side scope management unit expediently reads the access scope specified for each requesting virtual computing unit in the second execution environment upon receiving the access request, depending on the specific identification information from the sets of scope information.

[0029] According to one embodiment, the access request is transmitted to the hardware security device (HSD) along with the specified identification information and the read access scope. If the HSD does not manage the scope information itself, the second execution environment expediently not only transmits the identification information of the respective requesting virtual computing unit to the HSD, but also provides the correct access scope within which the access is permitted.

[0030] According to one embodiment, the transmitted access scope is stored or retained in the hardware security device (HSM) at least for the duration of the access, in particular in a corresponding scope unit or an active context unit ("HSM Active Context") within the HSM. If the HSM does not manage the scope information itself, only the current, active context is retained within the HSM. All scope information associated with a specific virtual processing unit of the first execution environment is expediently passed from the second execution environment to the HSM so that the HSM can work with this structure.

[0031] According to one embodiment, the sets of scope information are each encrypted using a key stored in the hardware security device. This key is, in particular, under the complete control of the hardware security device and is expediently inaccessible outside of it. Unauthorized manipulation of the scope information can thus be prevented.

[0032] According to one embodiment, the sets of scope information each comprise a key type of key by which the respective scope information is encrypted, a memory address at which a key is stored that the respective virtual computing unit can access, a status or status information regarding a status of the hardware security unit that the respective virtual computing unit can access, and / or data or information about data of the hardware security unit that the respective virtual computing unit can access.

[0033] For example, a given set of scope information ("HSM_Context_i") for a virtual computing unit "i" can be composed according to the following structure (1):

[0034] (1) HSM_Context_i = enc_K{ Key Store | HSM Status | HSM Data}

[0035] Here, "enc_K" refers to the encryption of the data with the key "K" using a specific encryption algorithm. For example, symmetric encryption algorithms can be used, which also provide authentication, such as AES-GCM, to ensure the authenticity of the data. "K" can be a key that is stored only within the hardware security device (HSD) and to which only the HSD has access. This could be, for example, a key injected by the silicon manufacturer, a key derived from this key using a key derivation function (KDF), or a key generated within the HSD during its configuration or initialization. "Key Store" specifically refers to the key storage location where the keys relevant to the virtual computing unit are stored.Depending on the key storage structure, this can include multiple symmetric and asymmetric cryptographic keys. "HSM Status" can refer to information about the hardware security device (HSM) pertaining to a specific virtual processing unit (VPU), such as whether the HSM is in update mode or factory mode. "HSM Data" can refer to data used to implement a secure protocol or monotonic counter. Typical operations on HSM context information include encryption, decryption, hashing, signing, and verification. The HSM can, for example, provide standard interfaces for operating on HSM data. The individual sets of context information can also be extended with alternative or additional data fields and elements.

[0036] According to one embodiment, a message or notification is transmitted from the transmission unit to the hardware security unit to transmit the access request. This message can include session information regarding a session between the hardware security unit and the respective virtual computing unit. Alternatively or additionally, the message can include process information regarding a process or a command to trigger the process to be executed during the respective access. Alternatively or additionally, the message can include specific identification information. Alternatively or additionally, the message can include key information regarding a key to be used during the respective access.Alternatively or additionally, the message can include data information regarding data to be accessed during the respective access and, in particular, data to be encrypted during the respective access. Alternatively or additionally, the message can include address information regarding a storage address to be accessed during the respective access and at which storage address, in particular, data or the encrypted data are to be stored during the respective access.

[0037] For example, an application programming interface (API) of the hardware security device can be extended with identity information so that the second execution environment can direct the hardware security device to requests from the correct sourcing ID. For example, the message transmitted from the delivery unit to the hardware security device can be an API command. An API command "HSM_Encrypt" might, for example, have the following structure (2):

[0038] (2) HSM_Encrypt: API_Session | Command | VMID | Encryption Key ID | Data to be encrypted | Pointer receiving buffer

[0039] "API_Session" refers to a specific session, as the second execution environment itself can have multiple sessions open with the hardware security device for a given virtual processing unit. "Command" can be a specific command to trigger a particular service, such as an encryption service. "MID" denotes the identification information of the virtual processing unit. "Encryption Key ID" denotes an encryption key ID. This encryption key ID can be a reference to a key stored in a key store of the hardware security device for encrypting specific data. "Data to be encrypted" denotes the data to be encrypted or a pointer to a shared data structure whose data is to be encrypted. However, instead of a pointer, the data can also be transmitted in its entirety.A "pointer receiving buffer" is a pointer receiving buffer that can refer to a common data structure in which the hardware security unit is to store the encrypted data.

[0040] A computing unit according to the invention, e.g., a control unit of a motor vehicle, is configured, particularly in terms of its programming, to carry out a method according to the invention. Implementing a method according to the invention in the form of a computer program or computer program product with program code for carrying out all method steps is also advantageous, as this incurs particularly low costs, especially if an executing control unit is also used for other tasks and is therefore already available. Finally, a machine-readable storage medium is provided with a computer program stored on it as described above. Suitable storage media or data carriers for providing the computer program are, in particular, magnetic, optical, and electrical storage media, such as hard drives, flash memory, EEPROMs, DVDs, etc. Downloading a program via computer networks (Internet, intranet, etc.) is also possible.Such a download can be done via a wired or wireless connection (e.g., via a WLAN network, a 3G, 4G, 5G or 6G connection, etc.).

[0041] Further advantages and embodiments of the invention will become apparent from the description and the accompanying drawing.

[0042] The invention is schematically illustrated in the drawing using exemplary embodiments and is described below with reference to the drawing.

[0043] Brief description of the drawings

[0044] Figure 1 schematically shows an embodiment of a computing unit according to the invention, which is configured to carry out an embodiment of a method according to the invention.

[0045] Figure 2 schematically shows an embodiment of a computing unit according to the invention, which is configured to carry out an embodiment of a method according to the invention.

[0046] Embodiment(s) of the invention Figure 1 schematically shows an embodiment of a computing unit 1000 according to the invention, which can be designed, for example, as a system-on-a-chip platform (SoC platform) in a (motor) vehicle.

[0047] The SoC platform 1000 features a host system 1001, which includes a processor unit, one or more memory units, and several peripheral devices. This host system 1001 implements a first, regular, non-secure execution environment 1100 and a second, secure execution environment 1200. Applications or processes with a first, low security level can be executed in the first, regular execution environment 1100. Applications or processes with a second, high security level can be executed in the second, secure execution environment 1200.

[0048] The second execution environment, 1200, is implemented as a so-called Trusted Execution Environment (TEE) in the host system 1001. The TEE environment 1200 can utilize a dedicated secure world within the processor unit. In contrast, the first, regular execution environment, 1100, can be referred to as the "Normal World."

[0049] In the regular execution environment 1100 and the secure execution environment 1200, various privilege levels 1010, 1011, 1012, and 1013, so-called "Exception Levels" (EL), can be provided, according to which applications can be executed. For example, privilege level 1010 represents the lowest level (ELO). Privilege level 1011 represents, for example, the second-lowest level (EL1). 1012 represents, for example, the second-highest privilege level (EL2). 1013 represents, for example, the highest privilege level (EL3). The higher the level in which a respective application is executed, the more privileges the application receives on the underlying hardware. In the TEE environment 1200, the applications include a higher-level security monitoring unit 1210 ("Secure Monitor"), a secure or secure application, and a secure application.a trusted operating system 1220, an identification determination unit 1230 ("Arbitration Logic"), a security service unit 1240 ("Security Service") and a transmission unit 1250 are executed, wherein the transmission unit 1250 may, for example, include an interface or be configured as an interface.

[0050] In the regular execution environment 1100, a large number of virtual computing units or virtual machines 1110 are implemented, with applications 1111 and an operating system 1112 running in each of these virtual machines 1110. A higher-level control or monitoring unit 1113, e.g., a so-called "hypervisor," is provided for controlling and monitoring the individual virtual machines 1110.

[0051] The SoC platform 1000 also features a hardware security unit or hardware security module (HSM) 1300, which is physically separated from the host system 1001 by hardware mechanisms. The HSM 1300 is configured to execute security applications, such as cryptographic operations. For example, the HSM 1300 can include its own processor, a crypto accelerator, and a true random number generator.

[0052] The HSM 1300 runs middleware 1310, which can include, for example, a trust anchor with cryptographic functions and protocols, and a scheduling function. Furthermore, the HSM 1300 features a communication interface 1320 ("HSM Host Interface"), a context management unit 1330 ("HSM Context Manager"), a security services unit 1340 ("HSM Security Services"), and a cryptographic key storage unit 1350 ("HSM Key Storage").

[0053] The SoC platform 1000 is configured to carry out an embodiment of a method according to the invention, enabling the applications 1111 of the individual virtual machines 1110 to access the HSM 1300. For this purpose, each application 1111 of a requesting virtual machine 1110 sends an access request to the HSM. The transmission of corresponding access requests from individual applications 1111 of the virtual machines 1110 via individual elements of the SoC platform 1000 to the HSM 1300 is indicated by lines 1400 in Figure 1.

[0054] The respective access request is transmitted by the respective application 1111 via the operating system 1112 of the respective virtual machine 1100, via the hypervisor 1113, and via the security monitoring unit 1210 to the host system 1001. From the host system 1001, the respective access request is transmitted via the security monitoring unit 1210 and via the operating system 1220 of the TEE environment 1220 to the identification determination unit 1230.

[0055] The identification determination unit 1230 determines identification information regarding the respective requesting virtual machine 1110, by which the respective requesting virtual machine 1110 can be uniquely identified among the multitude of virtual machines. The respective access request, together with the determined identification information, is transmitted via the security service unit 1240 to the transmission unit 1250.

[0056] The transmission unit 1250 transmits the respective access request, along with the specific identification information, to the HSM 1300. For example, the transmission unit 1250 can create an API message or API command containing the access request and the identification information for this purpose. This message can be transmitted from the transmission unit 1250 to the HSM 1300 via the operating system 1220 of the TEE environment 1200 and via the host system 1001. For example, this message can be generated according to the structure (2) described above.

[0057] In the HSM 1300, the received message is forwarded via the middleware 1310 and the communication interface 1320 to the scope management unit 1330. Depending on the identification information, the scope management unit 1330 reads an access scope that is predefined for the requesting virtual machine 1110 identified by the transmitted identification information. This access scope represents an access context or process context ("Process Context," "Task Context") that specifies how the respective access to the HSM may proceed, e.g., which data or memory addresses may be accessed, which status or state may be changed, etc. From the scope management unit 1330, the access request is forwarded via the security service unit 1340, the storage unit 1350 for cryptographic keys, and the middleware 1310.The HSM 1300 then executes each access according to the read access scope.

[0058] By determining the identification information and implementing the respective access according to the specified access scope, it is possible for the individual virtual machines 1100 to access the HSM 1300 securely without influencing each other and without requiring any changes to the hypervisor 1113.

[0059] A multitude of sets of scope information are specified, each set of scope information defining a specific access scope for a respective virtual machine 1110 identified by its respective identification information. For example, each set of scope information can be specified according to the structure (1) explained above.

[0060] According to the embodiment of the invention shown in Figure 1, these sets of scope information are managed by the HSM 1300 itself. For example, the sets of scope information can be stored in an internal memory unit within the HSM 1300 or in an external memory unit outside the HSM 1300. The sets of scope information are encrypted using a key that is stored in the HSM 1300 and which only the HSM 1300 can access. However, it is also conceivable that the sets of scope information are managed not by the HSM 1300, but in the TEE environment 1200, as will be explained below with reference to Figure 2.

[0061] Figure 2 shows a SoC platform according to an embodiment of the invention corresponding to Figure 1 and is designated 2000. Identical or equivalent elements of the SoC platform 2000 shown in Figure 2 are designated with a reference numeral increased by the value "1000" compared to the SoC platform 1000 from Figure 1 and are not explained again to avoid repetition.

[0062] The HSM 2300 of the SoC platform 2000 shown in Figure 2 does not have a scope management unit 1330, unlike the HSM 1300 of the SoC platform 1000 shown in Figure 1, because the HSM 2300 does not manage the sets of scope information itself. Instead, a scope management unit 2260 is provided in the TEE environment 2200 to manage the sets of scope information. After an access request is sent, the identification determination unit 2230 first determines the identification information of the requesting virtual machine 2110. Based on this identification information and the scope information sets, the scope management unit 2260 determines the access scope for the requesting virtual machine 2110. The transmission unit 2250 then transmits the access request, along with the identification information and the determined access scope, to the HSM 2300.According to this design, the HSM 2300 has a scope unit 2360 in which the transmitted access scope is stored at least for the duration of the access.

[0063] By managing the scope information in the TEE 2200 environment according to this configuration, the TEE 2200 environment can exert greater control over the HSM 2300, enabling additional flexibility and reduced configuration requirements for the HSM 2300. Furthermore, additional virtual machines can be easily added in this way.

Claims

Claims 1. Method for accessing a virtual computing unit (1110, 2110) to a hardware security unit (1300, 2300), wherein a first execution environment (1100, 2100) and a second execution environment (1200, 2200) are implemented in a computing unit (1000, 2000), wherein applications with a first security level are executable in the first execution environment (1100, 2100) and wherein applications with a second security level, which is higher than the first security level, are executable in the second execution environment (1200, 2200), wherein several virtual computing units (1110, 2110) are implemented in the first execution environment (1100, 2100), wherein applications (1111, 2111) with the first security level are executable in each of these virtual computing units (1110, 2110). wherein the computing unit (1000, 2000) has a hardware security unit (1300, 2300), wherein the hardware security unit (1300, 2300) is configured toto execute security applications, the procedure comprising the following steps: Sending an access request from a respective application (1111, 2111) to a respective requesting virtual computing unit (1110, 2110) for a respective access to the hardware security unit (1300, 2300); Determining identification information regarding the respective requesting virtual computing unit (1110, 2110) by an identification determination unit (1230, 2230) in the second execution environment (1200, 2200); Transmission of the access request together with the specified identification information by a transmission unit (1250, 2250) to the hardware security unit (1300, 2300); Executing the respective access in the hardware security unit (1300, 2300) depending on the specified identification information in such a way that the access is carried out according to an access scope specified for the respective requesting virtual computing unit (1110, 2110).

2. The method according to claim 1, wherein sets of scope information are specified, wherein each set of scope information specifies a respective access scope for a respective virtual computing unit (1110, 2110) identified by respective identification information, further comprising, after determining the identification information: Reading the respective access scope specified for the respective requesting virtual computing unit (1110, 2110) depending on the specific identification information and depending on the sets of scope information.

3. The method of claim 2, further comprising: Managing the sets of scope information by the hardware security unit (1300), in particular by a first scope management unit (1330) in the hardware security unit (1300).

4. Method according to claims 2 and 3, wherein the reading of the respective access scope specified for the respective requesting virtual computing unit (1110) is carried out by the hardware security unit (1300), in particular by the first scope management unit (1330).

5. Method according to claim 3 or 4, wherein the sets of perimeter information are stored in an internal storage unit in the hardware security unit (1300) and / or in an external storage unit outside the hardware security unit (1300).

6. The method of claim 2, further comprising: Managing the sets of scope information in the second execution environment (2200), in particular through a second scope management unit (2260) in the second execution environment (2200).

7. Method according to claim 6, wherein the reading of the respective access scope specified for the respective requesting virtual computing unit (2110) takes place in the second execution environment (2200), in particular by the second scope management unit (2260).

8. The method of claim 7, further comprising: Transmit the access request together with the specified identification information and together with the read access scope to the hardware security unit (2300).

9. The method of claim 8, further comprising: Storing the transmitted access scope in the hardware security unit (2300) at least for the duration of the access, in particular in a scope unit (2360) in the hardware security unit (2300).

10. Method according to any one of claims 2 to 9, wherein the sets of scope information are each encrypted by means of a key which is stored in the hardware security unit (1300, 2300).

11. A method according to any one of claims 2 to 10, wherein the sets of scope information each comprise one or more of the following: a key type of key by which the respective scope information is encrypted; a memory address at which a key is stored which the respective virtual computing unit (1110, 2110) can access; a status of the hardware security unit (1300, 2300) which the respective virtual computing unit (1110, 2110) can access; Data from the hardware security unit (1300, 2300) which the respective virtual computing unit (1110, 2110) can access.

12. Method according to one of the preceding claims, wherein the transmission of the access request by the transmission unit (1250, 2250) to the Hardware security unit (1300, 2300) includes the transmission of a message, wherein this message includes one or more of the following pieces of information: Session information regarding a session between the hardware security unit (1300, 2300) and the respective virtual computing unit (1110, 2110); Process information relating to a process that is to be executed as part of the respective access; the specific identification information; Key information regarding a key to be used in the course of the respective access; Data information regarding data to be accessed during the respective access; Address information relating to a storage address that is to be accessed during the respective access.

13. Computing unit (1000, 2000) configured to perform all process steps of a process according to any of the preceding claims.

14. Computer program that causes a computing unit (1000, 2000) to perform all process steps of a method according to any one of claims 1 to 12 when executed on the computing unit (1000, 2000).

15. Machine-readable storage medium with a computer program stored thereon according to claim 14.

Images