Monitoring secure execution of programs

Abstract

In a computer system in which multiple programs are executed concurrently in respective isolated execution environments, the temperature or power usage of one or more portions of the computer system are monitored. Upon it being determined that there is excessive heat generation or power usage according to an excessive use criterion (e.g. the sensed heat and / or power containers have exceeded a threshold energy), the operation of one or more of the isolated execution environments is modified (e.g. suspended or terminated) leaving other of the isolated execution environments still operating.

Description

[0001] Monitoring secure execution of programs

[0002] Field

[0003] The present invention relates to a method and device for secure execution of computer programs. The device may be a Hardware Security Module for example.

[0004] Background

[0005] A Hardware Security Module (HSM) is a device that securely stores and manages cryptographic keys, and performs a set of cryptographic algorithms. In some applications, it can be desirable to allow a user of the HSM to perform user-defined algorithms. In this way, a user is able to run a custom program that uses their cryptographic keys on the HSM. However, enabling a user to run a custom program on the HSM could compromise the security or operation of the HSM, and the information stored on the HSM. There is a continuing need to improve the security of such devices.

[0006] Summary of the Invention

[0007] In general terms, the present disclosure proposes that in a computer system in which multiple programs are executed concurrently in respective isolated execution environments, the temperature and / or power usage of one or more portions of the computer system are monitored, and, upon it being determined that there is excessive heat generation or power usage according to at least one excessive use criterion (e.g. that a sensed temperature and / or power usage have exceeded a threshold energy), the operation of one or more of the isolated execution environments is modified leaving other of the isolated execution environments still operating.

[0008] This has an advantage that temperature or power limitations may be met, while reducing unnecessary disruption to the isolated execution environments.

[0009] Brief Description of the Figures

[0010] Devices and methods in accordance with non-limiting embodiments will now be described with reference to the accompanying figures in which:

[0011] Fig. 1 is a schematic illustration of an exemplary Hardware Security Module (HSM) device; Fig. 2A is an illustration of the structure of the HSM;

[0012] Fig. 2B shows a container-based virtualization stack of the HSM device according to a comparative example;

[0013] Fig. 2C shows a process performed by the HSM device according to a comparative example to initiate an isolated execution environment;

[0014] Fig. 3A is a method carried out in the a system which is an example of the present disclosure;

[0015] Fig. 3B are further optional steps which may be performed after the steps illustrated in Fig. 3A;

[0016] Fig. 4 shows an assignment of permitted energy / power usage limited to differing containers in a possible implementation of the method of Fig. 3A;

[0017] Fig. 5 shows the logical structure of a system to implement the implementation of Fig. 4;

[0018] Fig. 6 shows a first way of performing a step of the method of Fig. 3A in the case of the implementation of Fig. 4;

[0019] Fig. 7 shows a second way of performing a step of the method of Fig. 3A in the case of the implementation of Fig. 4;

[0020] Fig. 8 is an illustration of the structure of the HSM in another system which is an example of the present disclosure;

[0021] Fig. 9 shows a container-based virtualization stack in the example system of Fig. 8;

[0022] Fig. 10 illustrates a method performed by the example system of Fig. 8;

[0023] Fig. 11A illustrates schematically the operation of a first possible isolated environment initialization process performed by the example system of Fig. 8; Fig. 11 B illustrates schematically the operation of a second possible isolated environment initialization process performed by the example system of Fig. 8;

[0024] Fig. 12 illustrates schematically associations between multiple users and multiple certificates in the example system of Fig. 8;

[0025] Fig. 13 illustrates two certificates associated with one of the users in the example system of Fig. 8;

[0026] Fig 14A illustrates a method of constructing a certificate for use in the example system of Fig. 8;

[0027] Fig. 14B illustrates a method of associating a user with a certificate in the example system of Fig. 8;

[0028] Fig. 15 illustrates a method of receiving a request to execute a program and implementing the request in the example system of Fig. 3;

[0029] Fig. 16 illustrates a first way of implementing a selection step of the method of Fig. 15;

[0030] Fig. 17 illustrates a second way of implementing a selection step of the method of Fig. 15; and

[0031] Fig. 18 illustrates a further method performed by the example system of Fig. 8.

[0032] The same reference numerals are used to designate corresponding elements in the illustrations of the comparative example and the example of the disclosure.

[0033] Detailed Description

[0034] A Hardware Security Module (HSM) is a device that securely stores and manages cryptographic keys, and performs a set of cryptographic algorithms. In some applications, it can be desirable to allow a user of the HSM to perform user-defined algorithms. In this way, a user is able to run a custom program that uses their cryptographic keys on the HSM. However, enabling a user to run a custom program on the HSM could compromise the security or operation of the HSM, and the information stored on the HSM.

[0035] Mitigating against such security issues can be important in a multi-tenant environment for example, where the HSM stores the cryptographic keys for multiple different users, who may not necessarily consent to their keys being shared with the other users.

[0036] In order to mitigate against such security issues, the user-defined program is executed in an isolated environment. For example, a container is used to execute and isolate a user-defined program.

[0037] The containers may be initialised with a standard configuration setting. For example, the configuration settings may be based on a whitelist provided by a trusted party, for example the manufacturer of the HSM. The whitelist may specify one or more of: the system calls that are considered safe for use by a user, the available devices that are considered safe for use by a user, the operating system capabilities that are considered “safe”. However, using a standard whitelist of configuration settings can result in a user- defined program being executed in a container that allows more functionality than the program needs in order to run. This can compromise the security or operation of the HSM, and the information stored on the HSM.

[0038] Fig. 1 shows a schematic illustration of a Hardware Security Module (HSM) device 11 in accordance with an example. The HSM 11 comprises a processing unit 103, a nonvolatile memory 105 and working memory comprising Random Access Memory (RAM) 109.

[0039] In this example, the processing unit 103 is a Central Processing Unit (CPU) 103, however in other examples, the processing unit may comprise a field programmable gate array (FPGA) or an application specific integrated circuit (ASIC) for example, or a combination of multiple types of processing components.

[0040] The non-volatile memory 105 may include any form of non-volatile device memory such as flash, optical disks or magnetic hard drives for example. The non-volatile memory 105 may be physically secure and may be resistant to tamper by a third party, for example by the inclusion of physical security such as a membrane that covers the entire device, that cannot be removed without destroying the underlying physical hardware. The CPU 103 is in wired bi-directional communication with non-volatile memory 105 and the RAM 109. Computer program code is stored in the non-volatile memory 105. When executed, a program is represented as a software product, or process, in the working memory. The processor 103 comprises logic circuitry that responds to and processes instructions in program code located in the working memory. The working memory comprises the RAM 109.

[0041] The below description refers to “HSM firmware” (or “main application”), which is a program comprising a set of computer instructions. The HSM firmware comprises machine code stored in the non-volatile memory 105 on the HSM 11. Also stored in the non-volatile memory 105 on the HSM 11 are any components necessary to execute the HSM firmware, including runtime system files. When executed, a copy of the main application machine code is loaded in the working memory. A "main application process” is the instance of the HSM firmware that is being executed, comprising the machine code in the working memory.

[0042] The HSM firmware comprises computer instructions embodying a set of one or more cryptographic algorithms. For example, the HSM firmware comprises computer instructions embodying one or more of the following cryptographic algorithms: cryptographic key generation; key derivation; encryption; decryption; and digital signature algorithms. The HSM firmware can be embedded in the non-volatile memory 105 of the Hardware Security Module 11 when the HSM 11 is manufactured by a trusted party, or can be provided by the trusted party as a whole or in part after manufacture. For instance, the HSM firmware can be introduced by the trusted party as a computer program product, which may be in the form of a download. Alternatively, modifications to existing HSM firmware can be made by the trusted party by an update or plug-in.

[0043] The HSM 11 runs an operating system, for example a Linux operating system. The operating system comprises system software that manages the hardware and software resources of the HSM 11 , and acts as an intermediary between the HSM firmware and the HSM hardware.

[0044] In use, the HSM device 11 may be located within a larger system. In this case, the HSM 11 is communicatively coupled to a computer or a server device in the larger system (for example) through interface 107, which comprises a communication link to the computer or server device. For example, the HSM 11 can be implemented in the form of a PCI express card directly plugged into the computer or server device, or the HSM device 11 can be communicatively connected to the computer or server device by a USB connection. In use, the HSM device 11 receives user requests through interface 107.

[0045] In one example, the HSM 11 is located in a user system. In this case, the user system has a dedicated local HSM 11 device. The HSM 11 is directly coupled to a client (user) computing device 117 (controlled by the user) through interface 107, for example the HSM device 11 can be a PCI express card directly plugged into the computing device 117 or can be communicatively connected to the client computing device 117 by a USB connection. The client computing device 117 may be a server or an end-user computing device for example.

[0046] In a different example, the HSM 11 is located in a host system (not shown) which is separate to the client computing device 117. The host system may be a service provider system for example. In this case, the client computer 117 communicates with a computer or server device in the host system. The HSM device 11 is directly coupled to the computer or server device in the host system through interface 107. For example, the HSM device 11 can be a PCI express card directly plugged into the computer or server device in the host system, or the HSM device 11 can be communicatively connected to the computer or server device by a USB connection. The client computing device 117 is thus communicatively coupled to the HSM device 11 through a computer or server device present in the host system (which is not shown in Fig. 1). Communication between the user computing device 117 and the host computer or server device (not shown in Fig. 1) may be performed via an Internet connection for example.

[0047] The non-volatile memory 105 stores one or more cryptographic keys associated with a user. The one or more cryptographic application keys are associated with the user for use with the cryptographic algorithms embodied in the HSM firmware. The application key(s) may be securely stored outside of the HSM device 11 using a master key. For example, the application key(s) may be encrypted using Advanced Encryption Standard (AES) encryption (for example) using the master key stored in the HSM device. The encrypted application key(s) can then be transmitted to a separate external device for storage. The master key however is stored on the HSM device 11 .

[0048] The application keys associated with the user are used to perform one or more cryptographic algorithms embodied in the HSM firmware. When a user request to perform an algorithm is received at the HSM 11 , the relevant application key or keys are retrieved by the HSM 11 , decrypted using the master key, and loaded into the RAM 109 space of the HSM firmware process. They may then be used by the HSM 11 to perform one or more cryptographic algorithms, including performing various encryption and decryption algorithms, and performing digital signature algorithms.

[0049] The HSM device 11 further comprises a Board Support Processor 113. Board Support Processor 113 is configured to communicate with a plurality of on-board sensors, monitoring the operation of the main CPU and the other hardware components of the Hardware Security Module 11 .

[0050] The sensors may include, but are not limited to, temperature sensor(s) 114 and / or power sensor(s) 115 such as voltage sensors and / or current sensors. Each of the temperature sensors 114 and / or power sensors 115 may relate to a specific portion of the HSM 11. For example, the output of a certain one of the temperature sensor(s) 114 may indicate the temperature of one or more corresponding devices of the HSM 11 (e.g. the CPU 103) or a certain location on the circuit board of the HSM. Similarly, the output of a certain one of the power sensor(s) 115 may characterize the power consumed by a corresponding one or more of the other devices of the HSM 11 .

[0051] The HSM device 11 further comprises a power reset device 116, configured for control by any one or more of the CPU 103, the crypto co-processor 111 or by a device external to the HSM 11 (e.g. using commands transmitted to the power reset device 116 via the interface 117).

[0052] The HSM further comprises a random number generator component 104, such as a quantum entropy source.

[0053] In some examples, the HSM device 11 may further comprise a crypto co-processor 111. The crypto-coprocessor 111 may perform various standard cryptographic functions in hardware, for example various encryption and decryption algorithms, and digital signature algorithms. In other examples, this functionality is integrated in the main processing unit 103. For example, the main processing unit 103 may comprise a system on a chip FPGA (SoC FPGA), where the various standard cryptographic functions are implemented in hardware in the programmable logic.

[0054] Various other components may be included which are not shown in Fig. 1.

[0055] Although a HSM device is described here, the invention is not limited to such, and the below described methods may be implemented on various devices used for performing cryptographic algorithms and / or storing cryptographic keys. For example, a software emulator running on a general purpose computing device or server may enable the computing device or server to behave like a HSM device. In this case, a computer program running in the computer device or server emulates a HSM device, and the below described methods are implemented on the computer device or server in this environment.

[0056] As discussed above, the HSM firmware comprises computer instructions embodying a set of one or more cryptographic algorithms. However, a user may wish to perform an algorithm for which computer program code is not provided in the HSM firmware on the HSM device 11. In light of this, there is provided functionality to receive and execute a user-defined program at the HSM 11 , as will be described in more detail below.

[0057] The user-defined program may be specified in a form that can be executed by the CPU 103 (e.g. in machine code). In other examples, the user-defined program is provided to the HSM 11 in an intermediate form, and is then converted by the HSM 11 into a form that can be executed by the CPU 103. Enabling user-defined code to be executed on the HSM provides flexibility, and allows a user to execute custom algorithms on the HSMs that make use of their cryptographic keys.

[0058] However, allowing a user to unconditionally execute arbitrary user-defined code on a Hardware Security Module (HSM) 11 may compromise the operation and security of the HSM 11 . The user code is therefore executed in an isolated environment on the HSM device 11 . For example, the HSM 11 uses containers to execute user code. A container is an example of an isolated environment. Using the container to execute the code isolates the user-defined code from the rest of the HSM runtime environment. A container is an executable unit of software in which application code is packed along with its libraries and dependencies. Containers take advantage of a form of Operating System (OS) virtualization in which features of the OS are leveraged to isolate processes. The containers may be referred to as OS-level containers because they are managed by the OS.

[0059] Isolating the user-defined program from the rest of the run-time environment creates a consistent environment for executing user-defined programs and limits exposure to rest of the HSM runtime environment. Executing the user-defined code in a container thus provides a sandbox in which the execution environment can be controlled and isolated from the HSM firmware. This mitigates against a user accidentally or deliberately introducing a security vulnerability to the HSM.

[0060] As discussed above, in an example the HSM 11 runs the Linux operating system. The Linux operating system may support the use of Linux containers (e.g. Linux LXC containers, and / or Linux LXD containers). Where Linux containers are used, Linux container technology provides the ability to control the operation of the container, e.g. by limiting the operations that can be performed by the container. The configuration of a container can be controlled to limit the operations that can be performed by code being executed in the container. The configuration associated with each Linux container is defined in a configuration file. For example, the container can be configured in such a way that it limits the system calls to the Operating System (OS) that can be made by the code executed in the container. Linux has over 300 system calls. Allowing a user defined program to access all 300 system calls could give rise to a security vulnerability. To this end, the system calls that can be made by programs executing in a container may be limited to a “whitelist” of system calls - this may be around 100 system calls for example. These are the system calls that are considered to be “safe” by a trusted party, for example a system administrator. Restricting the number of system calls reduces the attack surface, i.e. the potential ways in which the security of the HSM can be compromised. The available system calls can be limited using a seccomp profile, which specifies the allowed system calls. The seccomp profile is used to configure a seccomp filter when the container executing the user-defined program is initialised. The container can additionally or alternatively be configured in such a way that it limits the devices (e.g. storage devices) that can be accessed by the code executed in the container for example.

[0061] By controlling the configuration of the containers used to execute user code, even if the user-defined code contains malicious elements, the effect it could have on the security of the HSM (in particular the security of the information, such as cryptographic keys, stored on the HSM) is limited. For example, if the user-defined code has been compromised by a malicious third party, without knowledge of the user, the security issues caused by running the code on the HSM are limited by isolating the user code in the isolated environment (the container in this example).

[0062] This can be particularly important in a multi-tenant environment where the HSM 11 has access to (e.g. stores) cryptographic keys associated with other users. In this case, without sufficient controls in place, a user-defined program from a first user of the HSM 11 could be used to compromise the cryptographic keys of another user.

[0063] Fig. 2A shows a logical diagram of a Hardware Security Module 11 according to a comparative example. In particular, Fig. 2A shows an illustration of various software processes being executed by the HSM 11 . The HSM 11 may be a HSM 11 such as described in relation to Fig. 1 for example.

[0064] As discussed above, a container 203 is a virtual runtime environment that runs on top of an operating system (OS) kernel. The container 203 isolates one or more running processes running in the container 203 from the rest of the system. The container 203 is an example of an isolated environment.

[0065] In this example, a file 201 corresponding to the container 203 is provided by the user in a request transmitted to the HSM 11 . This file may also be referred to as the container image 201 or the container repository. Once received, the container image 201 is stored in the non-volatile memory 105 of the HSM 11. When run, the container image 201 becomes the container 203. The container image 201 comprises program code corresponding to the programs to be run in the container. In one example, once created, the container image 201 is immutable (i.e. such that it cannot be changed). The container image 201 further comprises all libraries, supporting files and programs, and any language interpreter required to run these programs on the HSM 11 . This means that when the container 203 is running, the programs may run without requiring access to files outside the container 203.

[0066] The launcher service 210 comprises a set of program instructions that, when executed, store the received container image 201 in the non-volatile memory 105 in response to receiving a command to start the container 203, and initiate and run the container 203 by sending an instruction to the container engine 202 to initiate a container 203 according to the container image 201 and a configuration file 207. The container configuration file 207 may be a Ixc.conf file for example.

[0067] The client device 117 communicates with the launcher service 210 through a first secure channel. When a request comprising a container image 201 is received from the client device 117 through the first secure channel, the launcher service 210 stores the received container image 201 in non-volatile memory 105, then transmits an instruction to a container engine 202 to extract the container image 201 in the non-volatile memory 105, initialize a container according to the container image 201 and a container configuration specified in a configuration file 207.

[0068] The configuration file 207 may be a default configuration file stored on the HSM 11 or may be generated by the launcher service 210 in response to the request in the manner described in more detail below. The launcher service 210 takes the configuration file 207 and a request to initiate a container from the user, and instructs the container engine 202 to start a container. The configuration file 207 and container image 201 are provided to the container engine 202 by the launcher service 210. A container for executing the user-defined program is thus initialised based on a container image 201 and a configuration file 207. The container configuration file 207 defines, amongst other things, the capabilities of the container, the devices that are accessible to the container, and a seccomp filter that controls the system calls that can be made by programs executing in the container.

[0069] The container engine 202 is configured to initiate the container 203 in response to a request from the launcher service 210. The container engine 202 processes the configuration settings provided in the configuration file 207 and sends this information to the OS kernel to set up the container. The container engine 202 makes one or more API calls to the Operating System (OS) kernel. The OS kernel implements the isolation of the container 203, and enforces the part of the non-volatile memory 105 and network connections available to the container 203. The OS kernel, together with the memory management unit within the CPU 103, allocates part of the RAM 109 to the container, and prevents writing to other parts of the RAM 109. In this way, the container isolation is implemented by the OS kernel, using hardware components such as the memory management unit. Consequently a container is an OS-level virtualisation tool. Once running, a container 203 is a set of one or more processes that are isolated from the rest of the system. Example implementations of the container engine 202 include Linux LXC and LXD.

[0070] The configuration settings specified in the configuration file 207 are implemented by and enforced by the OS kernel. The OS kernel is configured to process requests from the container 203 (e.g. system calls) and action these requests depending on the configuration settings of the container (e.g. whether a specific system call is enabled for the container). The configuration settings of the container are maintained whilst the container is running, and can only be modified by an authorised user, as described below. Once running, communication between the client device 117 and the container 203 may be performed via a firewall, and a virtual private network or third secure channel 206 configured by the launcher service 210. The third secure channel may be configured by the user. The HSM 11 also executes a main application process (HSM firmware) 204. The HSM firmware has been described previously, and comprises computer program code for managing, generating and manipulating cryptographic keys. For example, the main application process includes one or more of: predefined algorithms for generating cryptographic keys, code for loading a cryptographic key onto the HSM 11 , code for retrieving a cryptographic key stored on the HSM 11 etc. The firmware 204 may include a root certification authority (CA) certificate, which is accessed when the firmware is used. The HSM firmware 204 is configured to access security world data 205 stored in the non-volatile memory 105 of the HSM 11. Security world data 205 includes cryptographic keys associated with a user. Communication between the client device 117 and the HSM firmware 204 is performed via a second secure channel. In this example, the second secure channel is implemented using the secure shell (SSH) protocol.

[0071] The HSM firmware 204 may communicate with the container 203, to provide data (e.g. security world data 205) for use by the user processes executed within the container 203. For example, the HSM firmware 204 communicates with the container 203 via an internal network port of the container 203. In an example, the container 203 is used to perform a user-defined algorithm that uses a cryptographic key associated with the user.

[0072] The HSM main application code defining the HSM firmware 204 is provided by a trusted party. For example, the main application code can be embedded in the non-volatile memory when the HSM 11 is manufactured, or can be provided by the trusted party by an update or plug-in. However, a user may wish to perform a function that is not provided in the HSM firmware. In the example of Fig. 2A, the container 203 is provided for executing a user-defined program. This allows a user access to increased functionality, whilst limiting exposure of the HSM 11. In particular, since the user-defined program is executed in the container 203, the runtime environment of the user-defined program is isolated from the HSM firmware 204 which has access to the security world data 205, thereby improving security.

[0073] Fig. 2B shows a container-based virtualisation stack according to an example. In particular, Fig. 2B shows an Operating System kernel 302 running on the HSM hardware 301 (e.g. as depicted in Fig. 1). The OS kernel 302 runs the container engine 202, the launcher service 210, and the main application 204 (HSM firmware) as separate processes. In the examples described below, the Operating System (OS) is a Linux Operating system.

[0074] The container engine 202 runs the container 203. The container 203 comprises the user process(es) and the supporting files for these processes. In the example of Fig. 2B, the runtime environment of the container 203 is isolated from the runtime environment of the HSM firmware 204. Various known container engines may be used. Examples of container engines include Docker, Linux LXC and Linux LXD.

[0075] As has been described previously, the container 203 is associated with a configuration file 207, which is stored separately to the container image 201 in this example. The configuration file 207 defines one or more of: 1) how the network is virtualized in the container (e.g. which of the host's network interfaces are accessible to the runtime environment of the container); 2) a system call filter (e.g. which controls the system calls that can be made by a program executing in the container); 3) the Linux Capabilities available to the program executing in the container (e.g. controlling whether access is provided to specific kernel resources that were previously unavailable to unprivileged processes); and 4) the hardware devices mounted in the OS file system that can be accessed (e.g. for read or write) by the programs executing in the container 203. The system may support multiple substantially-identical containers concurrently, each processing different requests associated with different container images 201 .

[0076] A simplified schematic form of Fig. 1 is shown in Fig. 2C. Upon a user transmitting to the HSM a request to execute a program, the launcher service 210 initiates the container 203 based on the configuration file 207. The container 203 executes the program while communicating with the container engine 202 and the HSM firmware 204.

[0077] One approach is to initialize all containers for running user-defined code according to a default whitelist of system calls, devices, and capabilities, which is the same for all initialised containers. The whitelist corresponds to a default configuration file stored on the HSM. For example, the whitelist contains the system calls, devices and capabilities that are deemed to be “safe” by a system administrator.

[0078] However, this whitelist may be too permissive for a user’s specific use case. For example, although the number of system calls that can be made may be reduced to around 100 in the default whitelist, even this reduced set of 100 system calls may be too permissive for some use cases.

[0079] Although only a single container is shown in Fig. 2B, it is known for an HSM 11 to run multiple containers concurrently on the HSM hardware 311 . For example, before a given container has finished executing the programs within it, one or more other requests may be received to execute a program, and in response the HSM 11 may initiate a new container in respect of the programs in the new request(s) before the previously8 initiated containers have finished executing their corresponding program(s). The new container is launched in the manner described above, and runs on the container engine in the same way as the container described, in parallel with the existing containers.

[0080] More generally, there may be any number of concurrently running containers.

[0081] To protect the hardware of the HSM device, there are limits set on the powerconsumption of the HSM and the temperature of the HSM. During the operations of the HSM 11 measurements are taken at intervals using the temperature sensor(s) 114 and / or the power sensor(s) 115, and compared to corresponding limit(s). At intervals and / or in response to a warning transmitted from the board support processor 113, the HSM 11 (e.g. the HSM firmware 204) is arranged to compare the output of the temperature sensor(s) 114 and / or that of the power sensor(s) 115 with the limit(s), and determine whether a temperature value and / or power consumption value obtained from a temperature sensor 114 and / or power sensor 115 is greater than one or more thresholds associated with the limit.

[0082] In response to determining that the temperature / power consumption is greater than a first threshold, the HSM firmware 204 may initially issue a warning (e.g. to an administrator). In response to determining that the temperature / power consumption is greater than a second threshold, or greater than the first threshold for longer than a certain time, the HSM firmware 204 may (e.g. temporarily) shut down operation of the HSM 11 until the temperature / power is lower than the first or second threshold. Thus, the container(s) which are currently running on the HSM 11 are interrupted, that is terminated or else suspended until a criterion is met, e.g. until the temperature in the HSM 11 returns to below the threshold.

[0083] Although currently many applications of HSMs are in environments where the problems of excessive use of resources are relatively rare, future HSMs may be systems in which constraints on system resources are tighter, e.g. mobile, battery-powered HSMs, so shutting down the HSM 11 will be a more significant problem.

[0084] A first aspect of the disclosure is computer-implemented method comprising:

[0085] (i) receiving, by a computer system, from one or more users one more requests to execute one or more programs (e.g. from each of multiple users, a respective request to execute a respective program);

[0086] (ii) initializing, by the computer system, a plurality of isolated execution environments;

[0087] (iii) executing, by the computer system, the one or more programs concurrently in the isolated execution environments;

[0088] (iv) obtaining at least one temperature or power usage measurement characterizing the temperature or power usage of at least a portion of the computer system;

[0089] (iv) determining whether at least one excessive use criterion is met, the at least one excessive use criterion being based on the at least one temperature or power usage measurement; and

[0090] (v) if said determination is positive (i.e. it was determined in step (iv) that at least one of the one or more excessive use criteria was met), modifying the operation of at least one of the isolated execution environments without interrupting (suspending or terminating) the operation of all the isolated execution environments. If the determination is not positive, no modification to the operation of the isolated execution environments may be made.

[0091] This may allow the temperature limit(s) and / or power limit(s) to be met, at least more nearly, while reducing unnecessary disruption to the isolated execution environments.

[0092] This provides a finer grade of management. It allows the set of isolated execution environments (e.g. containers) to be designed to operate closer to the maximum operational power and thermal limits, e.g. without risking all the isolated execution environments being suspended or terminated and without an excessive risk of the safety thresholds of the HSM hardware being exceeded. This advantage would be particularly useful in the case of an HSM which is battery-powered, e.g. one which does not utilize a power source in addition to a battery included in the HSM (e.g. within a housing of the HSM). In principle, all the isolated execution environments may be modified, e.g. by reducing a configurable parameter (e.g. a permitted power usage limit) of each.

[0093] Alternatively, at least one of the isolated execution environments may be selected, and the selected at least one isolated execution environment may be modified, e.g. without modifying a configurable parameter of the other isolated execution environment(s). Thus, the operation of the isolated execution environment(s) other than the selected at least one isolated execution environment, may not be modified due to the positive determination, apart from no longer being subject to the same extent to any ill-effects caused by the excessive use.

[0094] For example, this makes it possible to arrange that high priority processing conducted by some isolated execution environment(s) is not unnecessarily interrupted by excessive use of resources by (perhaps less important) other isolated execution environment(s).

[0095] The at least one excessive use criterion may be to compare the one temperature or power usage measurement to a threshold (limit). It may be performed repeatedly at first intervals (e.g. at intervals of at least a second, at least 30 seconds, of at least once a minute) with the subsequent modification of the selected at least one of the isolated execution environments only being performed if the determination is positive.

[0096] The modifying the operation of a selected at least one of the isolated execution environments may comprise at least one of:

[0097] (i) changing a configurable parameter of a selected isolated execution environment (e.g. throttling operations (e.g. reducing the number of operations per second) of the selected some or all of the selected execution environments without suspending them; some or all of the selected execution environments may be associated with a corresponding dataset (e.g. a log) stored in the HSM which includes data indicating an allowable range for the configurable parameter, e.g. contains a warning that a certain configurable parameter cannot be varied so as to reduce the number of operating per second below an allowable threshold which may be indicative of how time- critical the corresponding isolated execution environment is);

[0098] (ii) suspending a selected isolated execution environment (i.e. interrupting the operation of the selected execution environment temporarily (that is, retaining the possibility to restart it), or terminating the operation of the selected execution environment); or

[0099] (iii) changing a portion of the computer system in which the program of a selected isolated execution environment is executed This may include changing the portion of the CPU 103 (or in a system with multiple CPUs, the number of CPUs), processing cycles, and / or portions of the RAM 109, etc. which are used to execute the selected isolated execution environment. This may require restarting the selected isolated execution environment.

[0100] In some cases, the modification of the isolated execution environments may be performed in an iterative fashion. For example, following a first modification of at least one isolated execution environment as described above, at least one further temperature or power usage measurement characterizing the temperature or power usage of at least a portion of the computer system may be collected (e.g. a second interval after the first modification), to determine whether the excessive usage criterion is still met. If it is, a further modification may be made to one or more of the isolation execution environments. Again, this is preferably performed without interrupting (suspending or terminating) the operation of all the isolated execution environments.

[0101] For example, if the first modification was of one of types (i) or (iii) above, (i.e. it may have reduced the expected power generation of the at least one selected isolated execution environment, at least in a certain portion of the computer system, but did not suspend it completely), the further modification may comprise a further modification to the same at least one selected isolated execution environment, which may again be of any of types (i), (ii) or (iii) described above.

[0102] Alternatively or additionally, the further modification may comprise a modification, of any of types (i), (ii) or (iii), performed to another one or more of the isolated execution environments.

[0103] The pair of steps of making temperature and / or power usage measurements and, upon at least one excessive use criterion being found to be met, modifying selected one(s) of the isolated execution environments, may be carried out at intervals (e.g. at intervals of at least a second, or at least 10 seconds), until no excessive use criterion is met. The method may then terminate, e.g. until it is initiated again by another step (e.g. at the first interval after the termination) of obtaining at least one temperature or power usage measurement characterizing the temperature or power usage of at least a portion of the computer system, and a step of determining that at least one of the excessive use criteria is met.

[0104] The at least one excessive use criterion may include at least one criterion that at least one of the temperature measurement(s) is above a temperature threshold associated with a temperature limit. For example, temperature measurements may be made at multiple locations in the computer system, and the excessive use criterion may be determined to be met if any of the measurements is above a corresponding temperature threshold (which need not be the same in all the locations).

[0105] Alternatively or additionally, the at least one excessive use criterion may include at least one criterion that a power usage (e.g. a total usage by all the isolated execution environments or a total usage by any proper subset of the isolated execution environments; or a power usage by any portion of the HSM) is above a power usage threshold. For example, the power usage of each isolated execution environment may be determined individually, and there may be an excessive use criterion for each isolated execution environment, e.g. that the power usage by the isolated execution environment exceeds a threshold which is a permitted power usage limit for that environment. Alternatively or additionally, the power usage of any portion(s) (e.g. any device) of the HSM may be determined individually, and there may be an excessive use criterion for each portion of the HSM, e.g. that the power usage by the portion exceeds a threshold which is a permitted power usage limit for that environment.

[0106] It will be assumed in this document that the threshold(s) are equal to the corresponding limit(s), but optionally they may be slightly above or below the limits to provide a certain tolerance or a margin-of-error. Also, it is assumed below that any one of at least one excessive use criterion is either met or not met, and, as described, if it is not met corrective action is taken. However, optionally there may be multiple thresholds for each of the measured parameters, with different corrective action being taken for different thresholds being exceeded. The determined power usage for individual isolated execution environments (or other proper subsets of the isolated execution environments running on the computer system) may be used also to select the isolated execution environments which are modified. For example, the at least one selected isolated execution environment may be selected as the one(s) of the selected isolation execution environments for which the determined power usage exceeds a corresponding permitted power usage limit by the highest amount.

[0107] Other ways of selecting the at least one isolated execution environment to modify exist. One is to select the at least one selected isolated execution environment as the one(s) of the selected isolation execution environments for which the permitted power usage limit is highest. Note that this method of selection can be used even when the power usage of individual isolated execution environments has not been determined.

[0108] Another way of selecting the at least one isolated execution environment may be unrelated to the temperature or power usage measurements. For example, each of the isolated execution environments may be associated with a corresponding priority level (e.g. as characterized by a stored priority value), and the at least one selected isolated execution environment may be selected as the isolated execution environment(s) for which the priority level is least.

[0109] The methods of selecting isolated execution environments may be combined, so that the selection takes into account any one or more of the priority levels, permitted power usage limits and / or the determined actual current power usages.

[0110] As noted, different ones of the isolated execution environments may be associated with different permitted power usage limits and / or priority levels. These may be set in any way, e.g. based on the identity of the use who transmitted the request. This information may be included in the request, e.g. as a token identifying the user. Thus, for example, a user may organize with an administrator (e.g. by a process including making a payment to the administrator or an organization associated with an administrator) that isolated execution environments which will be initiated based on requests that user sends for a program to be executed will be given a higher permitted power usage and / or priority level, e.g. for a specified number of requests to execute a program, than the isolated execution environments which are initiated based on requests which at least one other user sends for a program to be executed.

[0111] Conveniently, the power usage and / or priority levels of the execution environments may be set as part of a certificate which the computer system selects from a database of certificates, upon a user transmitting to the computer system a request to execute a program. The certificate is configuration information which defines an isolated execution environment, with different ones of the certificates being different configuration information, which may include the permitted power usage limit and / or priority level, and may include much more information. Thus, the configuration of an isolated execution environment can be tailored by the selection of one of the certificates, e.g. so that an isolated execution environment can be different for ones of the users and / or for requests of different types. This provides a convenient way of controlling selective access to the HSM, and optionally to other resources via the HSM.

[0112] In one option, one or more of the certificates stored in the certificate database may be associated with corresponding ones of a plurality of users (i.e. there is a mapping between certificates and users), and the selected certificate is selected as a certificate associated with the user from whom the request was received. Thus, requests from different users may conveniently be processed using differently configured isolated execution environments. The mapping may be defined by association data (e.g. stored in the certificate database). Note that under the mapping, a given one of the users may be associated with multiple ones of the certificates (as described below) and a given one of the certificates may be associated with multiple ones of the users.

[0113] For example, different users may be trusted to different respective levels. A user who can be trusted (e.g. not to provide program requests which present security risks) may be associated with certificate(s) which give the corresponding isolated execution environment greater freedom than the certificate(s) of another user.

[0114] In another example, different users may be associated with different professional roles (e.g. within an organization). A user who typically performs tasks which require greater access to the resources of the HSM may have certificate(s) which give the corresponding isolated execution environment greater freedom than the certificate(s) of a user who requires more limited access to the resources of the HSM. Optionally, associations between users and certificates made, e.g. by an administrator of the system updating the association data, in response to a payment, e.g. a payment to an owner of the HSM by the user (or an organization with which the user is associated). Thus, the associations may at least in part reflect the sums which the users have paid.

[0115] In general terms, the certificates may define access to any resources of the computer system itself, or at any devices outside the computer system. In this way, the resources / devices may be shared between multiple users, according to proportions defined by the certificates associated with each of the user. Each user may be associated with a different corresponding isolated execution environment which is initialized, following a request from that user, based on a certificate associated with that user and extracted from the certificate database. The multiple isolated execution environments may run on the computer system in parallel, i.e. with operations of different ones of the execution environments being performed substantially simultaneously by a processor of the computer system which is capable of parallel processing, or with operations of the multiple isolated execution environments being interleaved.

[0116] For example, a certificate may indicate that the isolated execution environment may use a CPU (or other processor device) of the computer system but with an operation rate limit, e.g. specifying that the number of operations performed by the processor device in a given time (“unit time”) has an upper limit. Alternatively or additionally, it may specify a memory usage limit for a memory of the computer system and / or of a memory device external to the computer system.

[0117] The limit(s) may be fixed, or may be conditional. For example, they may depend upon whether other isolated execution environments are currently running on the computer system. For example, each certificate may be associated with a CPU usage priority value, and, at any given time, the operation rate limit for each isolated execution environment may be a function of the CPU priority values of all the isolated execution environments which have been initiated and have not yet been deactivated. In another example, each certificate may be associated with a memory usage priority value, and, at any given time, the memory usage limit for each isolated execution environment may be a function of the memory usage priority values of all the isolated execution environments which have been initiated and have not yet been deactivated. The certificate may alternatively or additionally specify permitted system calls and / or permitted device calls which the isolated execution environment is permitted to make, to access functionality of the computer system or external device(s).

[0118] For example, the configuration information of each certificate may specify whether a hardware implementation of at least one of an encryption algorithm, a key exchange protocol and a signature algorithm can be accessed.

[0119] Alternatively or additionally, the configuration information of each certificate may specify whether a software implementation of at least one of an encryption algorithm, a key exchange protocol and a signature algorithm can be accessed.

[0120] Typically, the request to execute the program defines one or more requirements for the operation. For example, it may define explicitly any one or more of a CPU usage limit (i.e. a maximum number of operations per unit time the program must be able to access), memory usage limit (i.e. a maximum amount of memory to which the program must have access), and / or system / device calls which must be available. Alternatively, these may be implicit from the program (e.g. the program may include certain device calls or include routines which will generate data of a certain size to be stored).

[0121] Optionally, e.g. before initializing the execution environment, the computer system may include a compatibility determination process for determining whether at least one requirement defined by the request is compatible with the certificate(s) in the certificate database associated with the user from whom the request was received. This option is particularly valuable in cases in which the operation of the isolated execution environment during the execution of the program is not monitored (see below). If the determination is negative, an error resolution process may be initiated, e.g. an error message may be transmitted to the user. In the case of a user associated with multiple certificates, the compatibility determination process may determine if any of those certificates is compatible with the at least one requirement, and only perform the error resolution process if none of the certificates is compatible with the at least one requirement. Optionally, the compatibility determination process may not be performed, e.g. it may initially be assumed that the requirements of the request are compatible with the certificate(s) associated with the user, at least until monitoring of the isolated execution environment shows that this is not the case. As noted, optionally one or more of the users may be associated with multiple ones of the certificates, specifying different respective configuration information. Upon receiving a request from a user associated with multiple certificates, a certificate is selected from the multiple certificates associated with the user (e.g. from among one or more certificates associated with the user which are determined to be compatible with at least one requirement defined by the request). The isolated execution environment is then initiated based on the selected certificate.

[0122] The selection of the certificate may be at least partly based on the request itself (e.g. so that the certificate selected is the one which is most appropriate to one or more requirements defined by the request). For example, the certificate may be selected (e.g. from among the certificates associated with the user who transmitted the request and which were determined to be compatible with at least one requirement defined by the request) as a configuration which, according to a certain selection criterion, is best suited to execute the program. For example, it may be selected as the certificate which exceeds a requirement defined by the request by the smallest amount.

[0123] Alternatively, the certificate may be specified explicitly by the request (e.g. by including a certificate index number labelling the certificate in the certificate database), or may be selected according to a predefined certificate preference of the user. For example, the user may define an order for the certificates, and the certificate may be selected as the first certificate in that order, e.g. the first certificate which is compatible with the at least one requirement defined by the request.

[0124] The operation of the initiated isolated execution environment to execute the program may be monitored. Upon determining that system resources employed by an isolated execution environment exceeds at least one threshold (e.g. one of the limits discussed above defined by the configuration file / certificate, or a slightly higher or lower value), the computer system may interrupt the execution of the program to ensure that the execution of the program meets the limits defined by the extracted certificate.

[0125] Optionally, the computer system may be operative to modify the certificate database. For example, the computer system may be operative to add / remove a certificate to the certificate database. For example, upon a user purchasing the right to use the computer system (e.g. for a certain time) within certain limits, the association data may be modified to associate a certificate defining those limits with the user. Conversely, upon a user losing the right to use the computer system (e.g. upon a certain time period expiring), the association between the certificate and the user may be removed.

[0126] In another example, the computer system may be operative to modify a certificate stored in the certificate database, e.g. upon receiving an instruction from an administrator to do so. In the case of a certificate which has already been extracted and used to initialize an isolated execution environment which has not yet terminated, upon the extracted certificate being modified the isolated execution environment may be modified correspondingly. This provides a convenient way for an existing isolated execution environment to be modified.

[0127] According to another aspect, there is provided a carrier medium comprising computer readable code configured to cause a computer to perform any of the above methods.

[0128] According to another aspect, there is provided a non-transitory computer readable storage medium comprising program instructions stored thereon that are executable by a computer processor to perform any of the above described methods. The methods are computer-implemented methods. Since some methods in accordance with embodiments can be implemented by software, some embodiments encompass computer code provided to a general purpose computer on any suitable carrier medium. The carrier medium can comprise any storage medium such as a floppy disk, a CD ROM, a magnetic device or a programmable memory device, or any transient medium such as any signal e.g. an electrical, optical or microwave signal. The carrier medium may comprise a non- transitory computer readable storage medium. According to a further aspect, there is provided a carrier medium comprising computer readable code configured to cause a computer to perform any of the above described methods.

[0129] According to another aspect, there is provided a device, comprising one or more processors configured to: obtain configuration information for an isolated execution environment; obtain a program; initialise an isolated execution environment based on the configuration information; and execute the program in the isolated execution environment.

[0130] In one example, the device is a hardware security module (HSM). For example, the device may be a hardware security module device as illustrated by Fig. 1 and have the logical structure as illustrated in Fig. 2A. Fig. 3 shows a method 300 which an HSM may perform according to an example of the present disclosure. In a first step 301 , the HSM receives, from one or more users, multiple requests to execute one or more programs in the manner described above. For example, a single user may transmit to the HSM 11 multiple requests. Each request is that a respective program is executed by the HSM 11 . Alternatively, multiple users may each transmit one or more corresponding requests, where again each request is that a respective program is executed by the HSM 11. As explained above, the request comprises a container image 201. Once received, the container image 201 is stored (e.g. by the launcher service 210) in the working memory of the HSM 11 . The container image 201 comprises program code corresponding to the programs to be run in the container. The container image 201 further comprises all libraries, supporting files and programs, and any language interpreter required to run these programs on the HSM 11 .

[0131] In step 302, the computer system initializes a plurality of isolated execution environments based on the multiple requests. Each isolated execution environment may be for executing the program(s) stipulated in one or more of the requests. In an example discussed extensively below (e.g. in relation to Fig. 9), there may be a container for each program. Alternatively, in other cases, a given container may be initiated as described above in relation to Fig. 2B, and there may be multiple programs (e.g. for different corresponding users) within a single containers.

[0132] For each container, the initialization is carried out by the process described above. For each request the launcher service 210 initiates (launches) and runs a container 203 by sending an instruction to the container engine 202 to initiate a container 203 according to the corresponding container image(s) 201 of the program(s) the container is to execute, and the configuration file 207.

[0133] In step 303, the HSM executes the programs by running them within the corresponding container 203, in the manner described above. When the program in the container 203 is running, the program may run without requiring access to files outside the container 203.

[0134] In step 304, the computer system is arranged to make measurement(s) of a temperature of at least one corresponding portion of the computer system and / or a power usage by one or more corresponding portions of the computer. In one example of measuring a temperature, respective temperature measurements may be made for multiple locations within the computer system. In one example of measuring power, the collective power due to all the isolated execution environments may be measured, and / or the individual power usage of each isolated execution environment, and / or the individual power usage of corresponding portions of the HSM 11 .

[0135] For example, step 304 may be carried out by the board support processor 113 using the temperature sensor(s) 114 and / or the power sensor(s) 115. Alternative or additionally, a measurement of power usage may be made by the CPU 103, e.g. by analysing the operations it is instructed to perform.

[0136] In step 305, it is determined whether the measured temperature(s) and / or power usage(s) meet at least one criterion for excessive use of the resources of the computer system.

[0137] For example, the measured temperature(s) may be compared with thresholds associated with temperature limit(s), e.g. a single temperature limit for all locations or respective temperature limits for different locations, and for each location there may be an excessive use criterion that the corresponding temperature measurement is above the (corresponding) temperature limit.

[0138] In another example, the measured power usage(s) may be compared with thresholds associated with permitted power usage limit(s) (i.e. energy usage limit(s)). For example, there may be a single permitted power usage limit for all of the containers collectively, and one of excessive use criteria may be that the collective power usage of all the containers is above a first permitted power usage limit. Alternatively or additionally, an individual permitted power usage limit may be defined for each of the containers (or, more generally, for each of a number of proper subsets of the containers), and there may be an excessive use criterion which, for each permitted power usage limit, is whether the measured power used by the corresponding container (or the subset of containers collectively) is above the corresponding permitted power usage limit. More sophisticated excessive use criteria may optionally be defined, e.g. one which compare a function of multiple temperature measurements and / or power usage measurements, with a threshold.

[0139] Fig. 3A is drawn on the assumption that it is determined it in step 305 that one or more of the excessive use criteria is met (if it were not met, the method 300 would terminate after step 305; it may be performed again after a certain time (the first interval) has passed). Accordingly, in step 306 a modification is made to one or more of the isolated execution environments. However, in contrast to the modification described above for the comparative example, in the step 306 one or more of the isolated execution environments are modified without interrupting the operation (i.e. suspending or terminating) all the isolated executing environments.

[0140] In principle, modifications may be made to the operation of all the currently-active isolated execution environments, such as by throttling down (reducing the number operations per second) all the execution environments are permitted to instruct the main processor 103 to perform, e.g. when requesting that the firmware performs cryptooperations.

[0141] More typically, however, one of the currently-active isolated execution is selected, and a modification is made to the selected isolated execution environment(s) only; without modifying the other execution environments. Thus, the operation of some of the isolated execution environments (e.g. at least the ones which were not selected) is permitted to continue, albeit perhaps in different conditions (e.g. at a slower rate), rather than being interrupted (permanently or temporarily). Specific ways of doing this are explained below with reference to Figs. 6 and 7.

[0142] Optionally, the method 300 may further include the steps 307-310 shown in Fig. 3B.

[0143] In step 307 the method waits for a certain time (the second interval), which may be a few seconds or a few minutes.

[0144] In step 308 the computer system is arranged to make an additional measurement of a temperature at least one portion of the computer system and / or measure power usage in one or more portions of the computer, in the same manner as in step 304, and it is determined whether at least one of the at least one excessive use criteria which were determined to be met in step 305, is still met. If not, in step 309 the method 300 finishes. Method 300 may be carried out again after the first interval.

[0145] Otherwise, in step 310 there is another step of modifying the operation of at least one of the isolated execution environments without interrupting the operation of all the isolated execution environments. Again, this may in principle be a modification to all the isolated execution environments, e.g. reducing the number of operations which each of the current isolated execution environments are permitted to cause the main processor 103 or another device of the computer system to execute. However, alternatively it may be a step of selecting one or more of the still-active isolated execution environments, and modifying them, e.g. without modifying the still-active isolated execution environments which were not selected.

[0146] The method then returns to step 307. Thus, modifications to one or more of the stillactive isolated execution environments are made successively until the excessive use criterion is no longer met.

[0147] As mentioned above, step 306 and optional step 310 may in one alternative comprise selecting one or more of the still active isolated execution environments. We now turn to possible methods for performing steps 306 and 310, including selecting which of the isolated execution environments (e.g. containers) are selected for modification.

[0148] As shown in Fig. 4, the HSM 11 may support an assignment to each of the containers of a different corresponding value of a permitted power usage limit (an energy usage limit). As shown “container 1” is assigned a “high” value for the permitted power usage limit, “container 2” is assigned a lower “medium” value for the permitted power usage limit, and “container 3” is assigned a “low” value for the permitted power usage limit.

[0149] Alternatively or additionally, the HSM 11 may support an assignment to each of the container of an associated priority value defining a priority (priority level) of the container.

[0150] Fig. 5 shows the logical structure of an HSM 11 according to an example in which each of the containers a different value for a permitted power usage limit or priority level. This can also be an HSM 11 with the physical structure shown in Fig. 1. Unlike the logical structure of Fig. 2A, however, an HSM 11 with the logical structure of Fig. 5 comprises a further database 208 which contains, for each of the still-active containers, a corresponding value for the permitted power usage limit or priority.

[0151] A permitted power usage limit or priority may be assigned to a container when the container is initiated. The permitted power usage limit or priority for the container may be stored in the database 208.

[0152] For example, the permitted power usage limit or priority may be specified by data included in the request to execute a program. For example, a user who is aware that a program he or she wants to execute entails a high power generation may include in the request data stipulating that the container is to have a high permitted power usage limit. Also, a user may consider that it is essential that a program he or she wants to execute is executed without interruption, and may include a high priority value in the request, to indicate to the HSM firmware that other containers are to be selected for modification in preference.

[0153] Alternatively, the HSM firmware 204 may process the container image 201 received with the request to execute a program, and determine from that a permitted power usage limit from that required to execute the program, e.g. due to a time constraint specified in the request for completing executing the program.

[0154] In another alternative, the permitted power usage limit may depend, at least partly, on the still-active containers which presently exist, e.g. on the number of such containers and / or upon the permitted power usage limits of those containers. For example, upon receiving a new request to execute a program, the HSM firmware 204 may estimate how much more power the new container would need to generate for an excessive use criterion to be met, and assign to the new container a permitted power usage limit which is lower than this amount of power generation.

[0155] In another alternatively, the HSM firmware 204, upon receiving a request to execute a program, may use the interface 107 to send a query to an external system to specify an associated permitted power usage limit or priority, and base the permitted power usage limit or priority of the container for the program on the response to that query received over the interface 107.

[0156] Fig. 6 shows a first method 600 of implementing step 306 of method 300 shown in Fig. 3A, or step 310 shown in Fig. 3B, in the case that containers are associated with corresponding permitted power usage limits or priorities. ity module (HSM) which is a further example of the present disclosure is shown. This is a similar logical structure to the one shown in Fig. 2A. However, the HSM 11 with the logical structure of Fig. 3 further contains a database 208 which includes a permitted power usage limit and / or a priority level for each of a plurality of isolated execution environments initiated within the HSM.

[0157] Upon a request from a user to execute a program being received by the HSM 11 in the manner described above, the HSM 11 initiates a corresponding isolated execution environment as explained above, within which the program is implemented. In addition, the HSM 11 assigns a permitted power usage limit and / or a priority to the container, and stores that permitted power level and / or priority level in the database 208. This may be done is several ways. Firstly, the request to execute a program may specify the permitted power usage limit and / or priority associated with the request, which may be specified by the user. For example, a user who considers that a request which he or she is about to submit has high (or alternatively low) importance or urgency, may correspondingly include high (or alternatively low) value(s) for the permitted power usage limit and / or the priority within the request for the program to be executed.

[0158] Alternatively, the HSM 11 may, upon receiving the request, read in it data identifying a user (e.g. a token). The HSM 11 may communicate, e.g. over the interface 107, with an external database, by sending it a message which identifies the user who sent the request (e.g. a message including the token), and receiving in return value(s) for the power usage limit and / or priority. Fig. 8, explained below, show a further method by which a permitted power usage limit and / or priority may be assigned to a container, e.g. based on the identity of the user who sent the HSM 11 the request to execute the program.

[0159] As explained above with reference to Fig. 2B, the HSM may initiate a container including multiple (e.g. two) programs. In this case, the container may be assigned the permitted power usage limit and / or priority which is highest out of the permitted power usage limit and / or priority for each of the programs. Alternatively, the HSM may form containers including programs having the same permitted power usage limit and / or priority is the same, and the container is assigned that power usage limit and / or priority.

[0160] Fig. 6 shows a first method 600 of carrying out step 306 of the method 300 shown in Fig. 3A, or step 310 shown in Fig. 3B. The method 600 is explained assuming that each container has been assigned a permitted power usage limit (energy usage limit). It does not take into account any priorities assigned to containers.

[0161] In step 601 , the HSM 11 ranks the containers which are executing at that time (i.e. those containers which have been initiated, but which have not yet finished executing their respective program(s)) by their respective permitted power usage limits.

[0162] In step 602, the HSM 11 terminates one or more container(s) which, according to the ranking, have the highest permitted power usage limit. Note that this method does not require a measurement of actual power used, which may be difficult in some HSMs due to the security systems of the HSM which prevent detailed information about the operation of a container from being collected. In a variation of the method 600, in step 601 the HSM 11 ranks the containers which are executing at that time by their respective priority values. In step 602, the HSM 11 terminates one or more container(s) which, according to the ranking, have the lowest priority.

[0163] In a further variation of the method 600, the method may take into account both permitted power usage limit and priority. For example, in step 601 the HSM 11 may rank the containers by a weighted sum of their permitted power usage limit and a corresponding priority value for each container which is high when the priority of the container is low. In step 602, the HSM 11 terminates the container(s) which have the highest value(s) for this weighted sum.

[0164] Fig. 7 shows a second method 700 of carrying out step 306 of the method 300 shown in Fig. 3A, or step 310 shown in Fig. 3B. The method 700 is explained assuming that each container has been assigned a permitted power usage limit (energy usage limit). It does not take into account any priorities assigned to containers.

[0165] In step 701 , the HSM 11 calculates (that is, estimates) a current power use value for each of the containers which are executing at that time (i.e. those containers which have been initiated, but which have not yet finished executing their respective program(s)). The current power use value may measure the amount of energy the container is using in unit time (i.e. the power the container is using). To take into account the possibility that the power use value varies over time, the current power use value of each container may be averaged over a certain period of time. The current power use value is calculated by a process which does not undermine the isolation of the containers. For example, it may comprise measuring a number of operations which the container instructs the CPU 103 to carry out in unit time.

[0166] Step 701 may be carried out using diagnostic information of a kind already known in HSMs. For example, diagnostic information for a given container may have the form below:

[0167]

[0168] The estimation may take into account the number of memory operations instructed by the container as well as the number of CPU operations, since memory operations also relate to the generation of power. More generally, step 701 may include adding respective power usage estimates for any (or all) the devices employed by the container, since different operations in general cause different amounts of heat generation.

[0169] In step 702, the HSM 11 compares the current power use value obtained for each container in step 701 to the corresponding permitted power usage limit for that container, and subtracts the permitted power usage limit from the current power use value to obtain a value indicating the amount by which each container is exceeding the corresponding permitted power usage limit.

[0170] In step 703, the HSM ranks the containers by the amounts obtained in step 702, i.e. by how much their power usages exceed their respective permitted power usage limits.

[0171] In step 704, the HSM terminates the container for which the current power use value exceeds the corresponding permitted power usage limit by the largest amount.

[0172] Compared with method 600, method 700 has the advantage that if a container uses excessive power (e.g. due to a programming error in one of the program(s) it executes, or because it was created by a malevolent party), that container will be terminated even if the permitted power usage limit for that container is low compared to the other containers being executed.

[0173] Further variations of the methods 600 and 700 may take into account one or more locations in the HSM associated with the excessive temperature(s) and / or power usage(s) detected in step 305, as indicated by the at least one excessive use criterion. For example, if an excessive use criterion has been met because excessive use (e.g. excessive temperature) was detected in one or more specific devices of the HSM (e.g. a certain CPU core or an integrated circuit which performs a certain function in hardware), in step 306 (as implemented by a variation of methods 600 or 700) a container which makes use of those specific devices is terminated. For example, the ranking in step 601 , or the calculation in step 701 , may omit containers which are not configured to use the one or more specific devices.

[0174] Turning to Fig. 8, the logical structure of a hardware security module (HSM) which is a further example of the present disclosure is shown. This HSM, like the one of Fig. 3, may have the physical structure shown in in Fig. 1. The logical structure is similar to the one shown in Fig. 2A, except that it includes a HSM certificate database 209 storing multiple certificates associated with corresponding ones of a plurality of users. The certificate database 209 may further store association data defining an association (mapping) between users and certificates, as described below with reference to Fig. 12. The certificate database 209 may be stored in the non-volatile memory 105 in Fig. 1.

[0175] Each certificate in the certificate database may be associated with a signature dataset generated from the certificate using a key. The signature dataset may be checked when the certificate is downloaded into the certificate database 208, i.e. a check is performed that the signature dataset meets a validity criterion. The validity criterion may comprise a requirement that the signature dataset was generated from the associated certificate using the key. The signature dataset may further specify a validity period, and the validity criterion may include a check that the validity period has not yet expired.

[0176] As described below, upon receiving a request from a user to execute a program, one of the certificates can be selected and extracted by the launcher service 210. Optionally, the launcher service 210 may check the signature dataset associated with the extracted certificate (i.e. according to the validity criterion). This check may include checking that the associated validity period has not expired. If the check is not successful, the launcher service may generate an error message, and the process may terminate.

[0177] If the check is successful (or if there is no check), the launcher service 210 forms one of the configuration files 207 from the extracted certificate, to initiate a container. The permitted power usage and / or priority of the container(s) can thus be specified by the corresponding container. The virtualization stack for the HSM with the logical structure of Fig. 8 is shown in Fig. 9. Instead of the single container 203 of Fig. 2B, in the HSM 11 of Fig. 3 the visualization stack shows two containers 203a, 203b associated with two respective users (“user 1” and “user 2”). Although just two containers 203a, 203b for just two corresponding users are shown, there may be any number of containers corresponding to different users. In the case of a user who causes multiple requests to be transmitted to the HSM to execute programs, the requests may generate multiple containers which exist concurrently, e.g. according to corresponding ones of the certificates (e.g. the same certificate for all the containers, or different certificates for different ones of the containers).

[0178] The containers 203a, 203c exist concurrently (i.e. a period is shown after both containers 203a, 203b have been initiated and before either is terminated (deactivated or deleted)). Each container 203a, 203b contains a corresponding program (“user code 1” and “user code 2”) and supporting files for the program. Each of the containers 203a, 203b is initiated based on a corresponding configuration file / certificate, which may be a certificate associated with the corresponding user. The configuration files / certificates for different users may be different or the same.

[0179] As in Fig. 2B, the Operating System kernel 302 of Fig. 9 runs on the HSM hardware 301. The OS kernel 302 runs the container engine 202, the launcher service 210, and the HSM main application 204 (HSM firmware) as separate processes. In the examples described below, the Operating System (OS) is a Linux Operating system. The container engine 202 runs the containers 203a, 203b. The runtime environment of the containers 203a, 203 are isolated from each other and from the runtime environment of the HSM firmware 204, e.g. such that data cannot pass between them. Various known container engines may be used. Examples of container engines include Docker, Linux LXC and Linux LXD.

[0180] Returning to Fig. 8, a request from a first user (e.g. user 1) to the HSM 11 to execute a program comprises a container image 201. Once received, the container image 201 is stored (e.g. by the launcher service 210) in the non-volatile memory 105 of the HSM 11 . The container image 201 comprises program code corresponding to the programs to be run in the container. The container image 201 further comprises all libraries, supporting files and programs, and any language interpreter required to run these programs on the HSM 11. In response to the request, the launcher service 210 selects a certificate from the certificate database 209 and extracts it. For example, the launcher service 210 may select the certificate (e.g. associated with of the first user according to the association data), as a certificate associated with the first user. The launcher service 210 stores the certificate as a configuration file 207a. Optionally, the launcher service may perform the check described above using an associated signature dataset; if so, it is assumed here that the check is met. The launcher service 210 initiates (launches) and runs a container 203a by sending an instruction to the container engine 202 to initiate a container 203a according to the container image 201 and a configuration file 207a. When the container 203a is running, the programs may run without requiring access to files outside the container 203a.

[0181] The same process is conducted when a second user (say user 2) transmits a request to the HSM 11 to execute a program. In this case, the launcher service 210 extracts a certificate (e.g. associated with the second user according to the association data), and stores it as a configuration file 207b. The launcher service 210 initiates (launches) and runs a container 203b by sending an instruction to the container engine 202 to initiate a container 203a according to the container image 201 and a configuration file 207b.

[0182] The configuration files 207a, 207b define one or more of: 1 ) how the network is virtualized in the corresponding container 203a, 203b (e.g. which of the host's network interfaces are accessible to the runtime environment of the container); 2) a system call filter (e.g. which controls the system calls that can be made by a program executing in the container); 3) the Linux Capabilities available to the program executing in the container (e.g. controlling whether access is provided to specific kernel resources that were previously unavailable to unprivileged processes); and 4) the hardware devices (e.g. a quantum entropy source for random number generation) mounted in the OS file system that can be accessed (e.g. for read or write) by the programs executing in the container 203a, 203b.

[0183] Fig. 10 shows a method performed by a system comprising a HSM 11 and a client device 117 according to the example of the disclosure. The client device 117 corresponds to a user of the HSM device 11 . Here we assume that it is user 1 , but the process would be equivalent for a different user. The client devices for other user(s) of the HSM device 11 are not shown. As has been described previously, the client device 11 may be a computing device such as a desktop or laptop computer, or mobile device for example. As described previously, the HSM 11 may be directly coupled to the client computing device 117. Alternatively, the HSM 11 is located in a host system which is separate to the client computing device 117 and communication performed through the host system. The HSM 11 may be a HSM as has been described in relation to Fig. 1 and Fig. 8 for example.

[0184] In step 1501 , the client 117 the client 117 transmits a request to the HSM 11 to execute a program. The request comprises a container image. In an alternative example, the request comprises a reference (e.g. an address in memory or a file name) associated with a container image stored on the HSM 11 .

[0185] In either case, the container image comprises a user-defined program. The container image further comprises all libraries, supporting files and programs, and any language interpreter required to run these programs on the HSM 11 . The user therefore provides a container image including the user’s program, any required files, and any binaries that that user’s program depends on. The container image comprising the user-defined program may be provided from the client device 117 to the HSM 11 using various mechanisms. For example, EP3952202 - A DEVICE AND A METHOD FOR PERFORMING A CRYPTOGRAPHIC ALGORITHM, the entire contents of which are incorporated by reference herein, describes an example method of providing computer program code embodying a desired algorithm in an input data packet.

[0186] The request may be communicated between the client 117 and the HSM 11 over a secure channel to mitigate against tampering (e.g. by encrypting the desired container configuration at the client 117 in a way that can be decrypted by the HSM 11). In an example, the first secure channel uses the SSH protocol.

[0187] In step 1502, the launcher service 210 of the HSM 11 selects a certificate from a certificate database and extracts it. In one option, the HSM firmware 204 identifies user 1 from the request, and the launcher service 210 extracts from the certificate database a certificate associated with user 1. This process is described in more detail below, including a case in which there are multiple certificates associated with user 1. Optionally, the launcher service may perform the check described above using an associated signature dataset. It is assumed here that the check is met; if not, the method terminates. The certificate is container information which specifies a desired container configuration. The container information is stored as a configuration file 207a. In an example the information indicating the desired container configuration comprises one or more of: 1) devices of the HSM 11 that are to be made accessible to the container, 2) capabilities of the container (e.g., an indication of the root privileges available to a process executing in the container), 3) an indication of the system calls that are to be supported by the container (e.g. the OS system calls that can be made by the process in the container and actioned by the kernel), and / or 4) whether the container is to have internet connectivity.

[0188] In step 1503, the launcher system 210 initializes a container 203a that is configured according to desired container configuration obtained in step 502.

[0189] In step 1504, HSM 11 executes the program in the container image within the container 203a.

[0190] Fig. 11 A is a schematic illustration of a first manner of operation of an HSM 11 with the logical structure of Fig. 8. Upon a user transmitting to the HSM 11 a request to execute a program, the launcher service 210 accesses a certificate database 209 and extracts a certificate from the certificate database 209. Optionally, the launcher service may perform the check described above using an associated signature dataset. It is assumed here that the check is met; if not, the method terminates. The extracted certificate forms a configuration file. In the case that the request is from user 1 , the configuration file is configuration file 207a. The launcher service 210 initiates the corresponding container 203a based on the configuration file 207a. The container 203a executes the program while communicating with the container engine 202 and the HSM firmware 204. The communication with the HSM firmware may use an API defined by the HSM firmware.

[0191] Fig. 11 B is a schematic illustration of a second manner operation of an HSM with the logical structure of Fig. 8. This differs only by how the container 203a communicates with the HSM firmware. Specifically, in the operation shown in Fig. 11 B the container 203a is provided with a proxy (proxy server) 1101 , an item of software which filters communications between the container 203s and other applications running on the operating system 302. In particular, the proxy server 1101 can be arranged to communicate with a process 602 executed by the HSM firmware 204. Communications between the container engine 202 and the container 203a can be via the proxy 1101 and the process 1102. The process 602 may be a “daemon”, a program executing as a background process. Turning to Fig. 12, associations are shown between a plurality of users 1201 , 1202, 1203 and a plurality of certificates 1204 stored in the certificate database 209. In this example, the certificate database stores four certificates, labelled by certificate index numbers 1 to 4. The user 1201 is associated with the certificates labelled 1 and 2. The user 1202 is associated with a single certificate, which is the one labelled 3. The user 1203 is associated with certificates labelled 4 and 1. Note that both users 1201 and 1203 are associated with the certificate labelled 1.

[0192] The associations are defined by “association data” stored in a mapping table. The mapping table may be stored in the certificate database 209. The association data shows, for each of the users, which of the certificates 1204 each of the users is associated with. Thus, upon consulting the mapping table, the HSM 11 (e.g. the HSM firmware 204) can determine which certificate(s) are associated with a given user. For example, the HSM can determine that the user 1203 is associated with the certificates labelled 1 and 4.

[0193] The mapping table may further contain information which is used, upon a request being received from a user to execute a program, to select one of multiple certificates associated with the user. That is, the mapping table may indicate a predefined certificate preference of the user. For example, the mapping table may define an order for the certificates for a given user such that, when a request is received from that user, one of the certificates associated with that user can be selected as the certificate which is first in the order, and which optionally meets at least one additional criterion. As discussed below, the additional criterion may be that the certificate is compatible with at least one requirement defined by the request.

[0194] In principle a user who is not associated with any of the certificates may be submit a request to execute a program. The certificate database 209 may store at least one default certificate for such a user. One of the default certificate(s) is selected when such a user submits a request to execute a program.

[0195] Fig. 13 shows a portion of Fig. 12 in more detail, and in particular shows the configuration information for the two certificates 1204a, 1204b (the ones with certificate index numbers 1 and 2) associated with user 1201. The certificate 1204a contains configuration information which defines an isolated execution environment which is allowed to access hardware accelerated operations of the HSM (i.e. operations which are implemented on the HSM 11 in hardware rather than software). Furthermore, the configuration information for the certificate 1204 has relatively high (i.e. higher than the certificate 1204b) values for one or more limits, including a CPU usage limit, a RAM usage limit and / or a permitted power usage limit. Instead of or in addition to the permitted power usage limit, the certificate 1204b may include a priority value indicating the priority of a container initiated based on the configuration information of the certificate. The priority of certificate 1204a is shown in Fig. 13 as being high.

[0196] The certificate 1204b contains configuration information which defines an isolated execution environment which is not allowed to access hardware accelerated operations of the HSM, but is allowed to access software-implemented algorithms performed by the HSM firmware 204. Furthermore, the configuration information for the certificate 1204 has relatively low (i.e. lower than the certificate 1204a) values for one or more limits, including a CPU usage limit, a RAM usage limit and / or a permitted power usage limit. Instead of or in addition to the power usage limit, the certificate 1204b may include a priority value indicating the priority of a container initiated based on the configuration information, and in Fig. 13 the priority for certificate 1204b is shown as being low.

[0197] Fig. 14A shows a method of defining a certificate 1204. The method may be performed by a supplier of the HSM 11 , or by an owner or administrator of the HSM 11 . It may be performed in the HSM 11 by transmitting commands to the HSM 11 (e.g. through the interface 107) but may alternatively be performed using a separate computer system, for example one having a graphical user interface and data entry devices. The method comprises performing one or more of step 1401 , step 1402, step 1403, and / or step 1404 in any order; and then performing step 1405 and optionally step 1406.

[0198] As discussed above, in an example the container configuration information comprises one or more of: 1) devices of the HSM that are to be accessible to the programs executing in the container; 2) the Linux capabilities that are accessible to programs executing in the container; 3) the system calls that can be made by programs executing in the container and / or 4) whether the programs executing in the container have internet access.

[0199] In step 1401 , the method comprises defining (e.g. by manual data input) the system calls that are to be made available to the processes (e.g. the user-defined program) running in a container defined by the certificate. A system call is a programmatic way in which a computer program requests a service from the kernel of the operating system. All computer programs that use computer resources use system calls. System calls are used for process creation, process management, memory management, networking, device I / O handling etc. Linux system calls include: fork(), exit(), exec(), open(), read(), write(), close() etc.

[0200] In step 1402, the method comprises defining the Linus capabilities of processes accessible to programs executing in the container (e.g. by manual data). For example, the administrator can manually type the desired capabilities into a file containing the container configuration information. This may include setting one or more limits, including a CPU usage limit, a RAM usage limit and / or a permitted power usage limit. Instead of or in addition to the permitted power usage limit, step 1402 may include defining a priority value. Note that the permitted power usage limit may be set individually, or it may be implicit, i.e. a function of other limits set in step 1402, e.g. the CPU usage limit and / or the RAM usage limit.

[0201] In step 1403, the method comprises defining the devices of the HSM that are to be accessible to the container (e.g. by manual user input).

[0202] In step 1404, the method comprises defining the internet connectivity status of programs executing in the container. In an example the internet connectivity status comprises an indication of whether or not internet connection is permitted (e.g. Internet connection = yes / no). In this example, the supplier / administrator / owner has a binary option “internet connectivity: on / off”, where the latter specifies that program is run “offline” - in this case no network connectivity features are available.

[0203] Steps 1401 , 1402, 1403, and 1404 are shown in parallel in Fig. 14A, and these steps may be performed independently of each other. However, as has been described previously, the steps may overlap. Furthermore, in some examples, one or more of steps 1401 , 1402, 1403 and 1404 are performed without all of steps 1401 , 1402, 1403 and 1404 being performed. In this case, the steps performed will determine the extent to which the configuration of the container on the HSM is controlled. For example, in the case where only step 1401 is performed, then the container functionality would only be limited (further than a default configuration) in terms of the system calls that can be made by the program executing in the container.

[0204] After performing one or more of steps 1401 , 1402, 1403 and 1404, the method proceeds to step 1405. Step 1405 comprises generating container configuration information. In this example, step 405. Step 1405 comprises generating a file comprising a representation comprising the system calls, the capabilities, the devices, and / or the internet connectivity status (depending on which of steps 1401 - 1404 are performed). In an example generating the desired container configuration information comprises combining one or more of: the system calls defined in step 501 , the capabilities defined in step 1402, the devices defined in step 1403, and / or the internet connectivity status defined in step 1404 into a single list.

[0205] In step 1406, the configuration information is provided to the certificate database 209 as a certificate. For example, if the steps 1401-1405 are performed using a computer system external to the HSM 11 the configuration information may be transmitted to the certificate database 209 via the interface 107 and the HSM firmware 204. Note that in embodiments in which steps 1401-1405 are performed using the HSM 11 itself (e.g. defining the new certificate in the non-volatile memory 105) no separate step of transferring the configuration to the certificate database may be needed; that is, steps 1401-1405 may define the certificate within the certificate database 209.

[0206] Step 1406 typically comprises providing the certificate with a certificate index number which may be used to reference the certificate.

[0207] The process of Fig. 14A may be performed multiple times, to define multiple certificates within the HSM 11. For example, steps 1401-1405 may be performed using an external computer system to define multiple certificates, and then step 1406 may be performed for each of the certificates to upload it into the certificate database 209. Optionally, the method of Fig. 14A may be performed again later (e.g. after the HSM 11 has already executed some programs the process shown in Fig. 8) to increase the number of certificates in the certificate database 209.

[0208] Fig. 14B shows the steps of a method for defining the association information. This step may be performed after the method of Fig. 14A, though in principle it may be performed before it.

[0209] In a first step 1451 an administrator receives a request to associate a user with at least one of the certificates of the certificate database 209. This request may identify the certificate(s) with which the user wishes to become associated, e.g. using the corresponding certificate index number(s). The user may be an individual or organization which is not currently associated with one of the certificates (a “new user”) and wishes to become associated with one or more of the certificates, or a user who is already associated with one or more of the certificates (an “existing user”) and wishes to become associated with one or more certificates. In either case the new / existing user is typically aware (at least to some extent) of the capabilities of the certificate with which it requests to be associated. The request to associate the user with the certificate(s) may optionally include or reference a payment the new / existing user makes to the administrator or another organization.

[0210] Following a check that the new / existing user meets one or more conditions (e.g. relating to the identity of the new / existing user, and / or the payment being adequate), in step 1452 the administrator may determine to associate the new / existing user with the certificate specified in the request to associate the user with at least one of the certificates. The administrator does this by transmitting into the HSM 11 a command to modify the association information stored in the certificate database to associate the new / existing user with the certificate(s) requested.

[0211] Fig. 15 shows a process performed by the HSM using the certificates and the association data. That is, it shows the process of Fig. 10 from the point of view of the HSM 11 of the processes of Fig. 5. The method may be performed by a HSM 11 as has been described previously for example with reference to Fig. 1 and Fig. 8. The HSM 11 stores program code (e.g. in non-transitory memory) that implements the steps 1501-1505 of Fig. 15 - for example, the method of Fig. 10 is performed by the HSM firmware 204 and the launcher service 210.

[0212] In step 1501 of the method of Fig. 15, the method comprises receiving from a client device 117 (i.e. from a user) a request to execute a user-defined program. The request comprises the container image comprising the user-defined program and further comprises all libraries, supporting files and programs, and any language interpreter required to run these programs on the HSM 11. It further identifies the user who transmitted the request. It may do this by including a user token (e.g. an encrypted token) which the HSM 11 may compare to a database of user tokens.

[0213] In step 1502, upon receiving the request, the HSM 11 selects one of the certificates. Specific methods for conducting this step are explained below with reference to Figs 10 and 11. In step 1503 the selected certificate is extracted from the certificate database 209 and passed to the launcher service 210.

[0214] In step 1504 a container is initialized, by the container engine 202 under the control of the launcher server 210, according to the container configuration information of the selected certificate extracted in step 1503.

[0215] Initializing the container comprises the launcher service 210 generating a container configuration file that includes the system calls, devices and / or capabilities specified in the selected certificate. Without loss of generality, we assume that the user is the “user 1”, so that the container is denoted 203a (as in Fig. 8 and Fig. 9) and the configuration file is denoted 207a. In an example, the generated container configuration file 207a comprises only the system calls, devices and / or capabilities specified in the container configuration information defined by the selected certificate (optionally as well as other configuration information). Generating a container configuration file 207a may comprise modifying a template container configuration file for example. The template container configuration file may be a default container configuration file. The launcher service 210 may store the configuration file 207a, e.g. in the working memory.

[0216] For example, the launcher service 210 may generate a seccomp profile that specifies the allowed system calls. The launcher service 210 includes the seccomp profile in the container configuration file 207a. This may involve modifying an LXC container configuration file to use the generated seccomp profile. The LXC container configuration file may also be modified to also only allow the enabled devices specified in the custom configuration information. For example, this may involve using cgroups - a Linux kernel feature. The LXC container configuration file may also be modified to according to the requested network configuration information.

[0217] The configuration file 207a is then provided to the container engine 202 (e.g. the container engine 202 is instructed by the launcher server 210 to read the configuration file 207a from the working memory). The syscalls, capabilities, devices and network availability are managed by the LXC container engine, where the LXC container engine calls the right functions from the OS kernel 302 to set the container up. For example, the container engine 202 generates a seccomp filter according to the seccomp profile in the configuration file 207a. Once initialised according to the configuration, in step 1505 the user program is executed in the container with the allowed syscalls, capabilities and devices, e.g. in a conventional manner. This is based on the container image 201 for the corresponding program.

[0218] The execution of the program may be monitored to ensure that it is according to requirements defined by the selected certificate. For example, if the number of CPU operations (e.g. per unit time) or memory usage is determined to exceed a threshold defined by the certificate, the execution of the program may be terminated, and an error message sent to the client device 117.

[0219] It will be understood that defining the container according to one of the certificates 1204 increases the system security. For example, restricting the system calls that can be made by a user-defined program within the container to be one of the certificates 1204 reduces the attack surface with which a user-defined program can attack the kernel and exploit the data (e.g. cryptographic keys) and the operation of the HSM 11. In particular, the attack surface is reduced when the container configuration is restricted to only those system calls that are required by a user-defined program because the number of permitted system calls is reduced and the ability of a malicious party to launch an attack on the kernel from within the container (e.g. by replacing the user-defined program with a malicious program) is mitigated since the container will only allow system calls that are used by the user-defined program.

[0220] Fig. 16 shows a first way of implementing step 1502 the method of Fig. 10. In an example the method of Fig. 16 is implemented by a HSM 11 , e.g. as shown in Fig. 1 and Fig. 8.

[0221] In step 1601 the method comprises identifying, using the association information stored in the certificate database, one or more certificates stored in the certificate database 209 associated with the user who transmitted the request. In the case of user who is not associated with any certificates, at least one default certificate may be selected.

[0222] If multiple certificates in the certificate database 209 are associated with the user who transmitted the request (or if, in the case of a user who is not associated with any certificates, there are multiple default certificates), the method of Fig. 16 comprises a step 1602 of selecting one of those certificates. There are several ways this could be done.

[0223] In one option, the selection may be based on at least one requirement defined by the request for the program to be executed. For example, the request many specify a certain maximum number of transactions per second is performed (e.g. by the CPU 103, or by another device). For example, the request may define a CPU usage limit. This may be defined explicitly in the request or be implicit from properties of the program. A certificate may be selected which specifies a CPU usage limit which is greater than the CPU usage limit specified by the request by the least amount (i.e. the selected certificate may be selected such that the CPU usage limit specified by the selected certificate minus the CPU usage limit specified by the request, is positive but as small as possible). In this way, a container is chosen which gives the least risk of an unacceptable amount of CPU being used, either by the user-defined code malfunctioning or if the user-defined code has been compromised by a malicious third party. If the request does not specify a CPU usage limit then a certificate may be selected which also does not, or which has a high CPU usage limit.

[0224] Although this example is based on selecting a certificate based on CPU usage limits, in variations the selection may be based on a memory usage limit, or a combination of multiple usage limits.

[0225] Alternatively, the selection in step 1602 could be done based on data (e.g. included in the mapping table or included in the request) indicating a predefined certificate preference of the user. This may indicate an order for the certificates. Step 1602 may then include selecting the certificates as the first certificate in the preferred order defined by the data, out of the certificates identified in step 1601.

[0226] Note that in a variation, step 1601 could be omitted, and step 1602 could be performed in respect of all the certificates in the certificate database 209. In this variation the association data would be not be needed and the mapping shown in Fig. 12 would not exist. This would still have the advantage that the most appropriate certificate for the job is selected, potentially leading to greater efficiency (e.g. by selecting a container configuration which has sufficient flexibility to implement the request) while not having unnecessary flexibility (leading to a greater security risk). However, it would mean that that selected certificate is not generally associated with the user who transmitted the request, so the selection of container capabilities according to which user transmitted the request would not be present.

[0227] Fig. 17 shows an alternative way of implementing step 1502 of the method of Fig. 15. Steps 1701 and 1704 correspond to, and are identical to, steps 1601 and 1602 of the method of Fig. 11 respectively. However, the method of Fig. 17 contains additional steps 1702 and 1703.

[0228] In step 1702 the method comprises a compatibility determination process for determining whether any of the certificate(s) determined in step 1701 to be associated with the user who transmitted the request for the program to be executed is compatible with at least one requirement defined by the request. For example, the configuration file may be examined to determine whether 1) the devices of the HSM that are required to be accessible to the program; 2) the Linux capabilities that are required to be accessible to the program; 3) the system calls that are required to be available to the program and / or 4) the program requires internet access. These requirement(s) are compared with the certificates determined in step 1602, to see if any matches.

[0229] If it is determined in step 1702 that none of the certificate(s) associated with the user from whom the request was received is compatible with the requirement(s) of the request, in step 1703 an error resolution process is performed. For example, the HSM 11 may transmit an error message to the client system 117, informing the client 117 that the request to execute the program is unsuccessful. The method of Fig. 17 may then end (i.e. the program is not executed). In this case the user may take action, e.g. by modifying the program or by transmitting a request to an administrator for the user to become associated with another certificate (e.g. one which places fewer constraints on the isolated execution environment it defines). Alternatively, the error resolution process 1704 may comprise modifying the configuration file to be compatible with one of the constraints. For example, if the requirement is that the program is permitted to control the CPU 103 to perform a certain number of operations in unit time, and that requirement exceeds CPU usage limit(s) specified by the certificate(s) identified in step 1701 , the configuration file may be modified so that the program can be run, but more slowly. In this case, the method of Fig. 17 may be performed again, and the second time the method may advance to step 1704 (that is, if multiple certificates were determined to be compatible in step 1702, determining which certificate is most appropriate for the job) using the modified configuration file. Note that in the case that step 1704 is performed by reference to requirement(s) of the program, as explained above with reference to step 1602, the requirements used in step 1704 may be different from those used in step 1702, e.g. fewer requirements may be used in step 1704 than in step 1702.

[0230] As explained above, although it is preferable for users to be associated with certificates as shown in Fig. 12, this is not essential. In this case, the methods of Figs. 16 and 17 may omit steps 1601 and 1701 respectively. That is, steps 1602 and 1702-1704 can be performed for all certificates in the certificate database 209.

[0231] Fig. 18 shows a method of dynamically updating a container configuration according to an example.

[0232] In step 1801 a certificate stored in the certificate database 209 is modified. This may be done because a vulnerability of container configurations according to the certificate has been identified. In some cases it may become apparent that one or more configuration settings (e.g. system calls, devices, capabilities etc.) that was once considered safe and therefore included in one of the certificates 1204, is no longer safe, for example, due to a recently identified vulnerability (e.g. a zero-day attack).

[0233] The modification may be done, for example, by an administrator or supplier of the HSM 11 transmitting a replacement version of the certificate to the certificate database 209 via the interface 107 and the HSM firmware 209. Alternatively, the administrator / supplier may transmit instructions (e.g. via the interface 107) to the HSM firmware to modify a certificate in the certificate database 209.

[0234] Alternatively or additionally, step 1801 may include modifying one or more limits defined by the certificate, including a CPU usage limit, a RAM usage limit and / or a power usage limit, and / or modifying a priority value defined by the certificate.

[0235] In step 1802 it is determined by the HSM 11 whether any container (isolated execution environment) has already been launched based on the certificate before it was modified, and is still in existence (i.e. the program executing in the container has not yet terminated). The launch of the container may have happened days, months or years before step 1801 was performed.

[0236] In step 1803, the configuration of the isolated execution environment for any containers identified in steps 1802 is modified.

[0237] In a first approach, modifying the current configuration of the container comprises identifying the configuration parameter to be changed and then updating the configuration of the container instance. For example, this may involve using the "ixc config device remove" command to remove a device which was once permitted by the certificate, but now is no longer permitted. In a second approach, the container instance is paused, the configuration of the container is updated and the container operation is then resumed. In another example the state of the processes in the container is saved, the container is then stopped, and a new container is generated with the saved state and the updated configuration settings.

[0238] In some cases, the act of changing the configuration of the container to remove the access to the vulnerable configuration may mean that, at some point, the user-defined program being executed in the container will make an attempt to access the vulnerable resource (e.g. by attempting to access the vulnerable device, or by attempting to use the vulnerable system call). In this case, the container will block such a request and an error will be generated, preventing a user-defined program from potentially exploiting a resource that is known to be vulnerable.

[0239] Alternatively, upon determining that the already-initialised container has a configuration that allows access to the vulnerable parameter (e.g. allows access to the vulnerable device or allows the vulnerable system call to be made), and upon determining that the desired container configuration was based on the program being executed in the container, then the container is stopped and removed. In this case, the program being executed in the container is no longer suitable for being executed on the HSM (because it requires access to a vulnerable command / device) and so the container and the program executing in the container is stopped, instead of waiting for an error as in the example above.

[0240] The method of Fig. 18 reduces the attack surface available to a user-defined program and enables a more secure HSM 11.

[0241] In the examples above, reference is made to a user-defined program, however any program that is intended to be run in the container can be used in the methods described herein, whether or not it is defined by the user that wants to run it on the HSM 11 .

[0242] In the description above, the techniques are described in relation to a HSM 11 running a Linux Operating System (OS). However, the same techniques can be applied to other Operating Systems.

[0243] In the examples above reference is made to a container. As discussed above, a container is a standalone unit of software that packages up code and all its dependencies so the application runs quickly and reliably from one computing environment to another. A container is an example of a sandboxed environment or an isolated environment for execution of a program. Other examples of isolated environments may be used however, for example a virtual machine.

[0244] The above described methods include customized restriction of container-based applications, or applications based in other isolated environments. There may be instances where assurance that a user-defined program is being executed in accordance with a regulatory or compliance regime is required. By providing custom configuration settings, a user may have assurance that the program is being executed in accordance with a regulatory requirement. There may be instances where this list is not appropriate however, especially where there are different tenants on the HSM that are operating under different regulatory requirements. By allowing restriction of the configuration of a container based on its use case, for example the regulatory regime it is operating under and the system calls used by the program it is executing, compliance with regulatory requirements may be provided and the attack surface reduced in a scalable way.

[0245] In the above described methods, the container is customized according to its use requirements: the launcher service initialises the container according to a configuration file defined by a selected certificate, and the user-defined program is executed within the container. This may provide a secure implementation, with a reduced attack surface, i.e. a reduced opportunity to exploit a vulnerability of the HSM, while executing user code. The policy can also be reconfigured to respond to new threats. The method provides the ability to launch customised containers that restrict the system calls, network devices or capabilities of the container. A user can therefore ensure that the program is being executed in accordance with a regulatory requirement. This reduces the attack surface that a malicious user-defined program could exploit, for example.

[0246] Even removing a single kernel system call may provide improved security. For example, profiling the user-defined program may indicate that it does not use a first system call. The container is therefore initialised with a seccomp profile that does not include the first system call. If the program is compromised, an attacker may include functionality in the program that calls the first system call. If executed, this functionality may cause a catastrophic failure to the entire HSM. Reducing the container configuration to remove the first system call thus avoids a full compromise of the HSM, and may result in a more contained compromise of just the user’s program for example. The container is a possible source of attacks against the HSM - for example, an attacker might compromise the container to then extract sensitive data, e.g. keys, from the HSM. By controlling the configuration settings of the container, the HSM may be protected from the container. The methods provide a safe secure execution environment (SEE) using a trusted platform, for example a HSM. In particular, the SEE is isolated from impacting the security functionality of the HSM's trusted computing base. However, the application still benefits from operating within the hardened environment of the HSM.

[0247] It will be understood that the invention is not limited to the embodiments described above and various modifications and improvements can be made without departing from the concepts described herein. Except where mutually exclusive, any of the features may be employed separately or in combination with any other features and the disclosure extends to and includes all combinations and sub-combinations of one or more features described herein.

Claims

CLAIMS:

1. A computer-implemented method comprising: receiving, by a computer system, from one or more users one more requests to execute one or more programs; initializing, by the computer system, a plurality of isolated execution environments; executing, by the computer system, the one or more programs concurrently in the isolated execution environments; obtaining at least one temperature or power usage measurement characterizing the temperature or power usage of at least a portion of the computer system; determining whether at least one excessive use criterion is met, the at least one excessive use criterion being based on the at least one temperature or power usage measurement; and if said determination is positive, modifying the operation of at least one of the isolated execution environments without interrupting the operation of all the isolated execution environments.

2. The method of claim 1 in which modifying the operation of at least one of the isolated execution environments comprises at least one of: changing a configurable parameter of a selected isolated execution environment; suspending a selected isolated execution environment; or changing a portion of the computer system in which the program of a selected isolated execution environment is executed.

3. The method of claim 1 or claim 2 further comprising, after said modifying the operation of at least one of the isolated execution environments, at least once performing the steps of: obtaining at least one further temperature or power usage measurement characterizing the temperature or power usage of at least a portion of the computer system; further determining that the at least one excessive use criterion based on the at least one further temperature or power usage measurement is met; andbased on said further determining, again modifying the operation of at least one of the isolated execution environments without interrupting the operation of all the isolated execution environments.

4. The method of any preceding claim in which determining that the at least one excessive use criterion is met comprises determining that at least one of the temperature or power usage measurements exceeds a corresponding threshold.

5. The method of any preceding claim in which said modifying the operation of at least one of the isolated execution environment comprises selecting at least one of the isolated execution environments and modifying the selected at least one the isolated execution environments.

6. The method of claim 5 in which the at least one temperature or power usage measurement comprises corresponding power usages of each of the isolated execution environments, and the at least one selected isolated execution environment is selected at least partly based on the power usages of the isolated execution environments.

7. The method of claim 5 or claim 6, in which each of the isolated execution environments is associated with a corresponding permitted power usage limit, and the at least one selected isolated execution environment is selected at least partly based on the permitted power usage limits of the isolated execution environments.

8. The method of claim 7 in which the at least one selected isolated execution environment is selected as the one of the selected isolation execution environments for which the permitted power usage limits is highest.

9. The method of claim 7, when dependent upon claim 5, in which in which the at least one selected isolated execution environment is selected as the one of the selected isolation execution environments for which power usage exceeds the corresponding permitted power usage limit by the highest amount.

10. The method of any of claims 7 to 9, in which the permitted power usage limit is different for different ones of the isolated execution environments.

11. The method of any preceding claim, further comprising, upon receiving the requests for a program to be executed, the computer system, for each request: selecting a certificate from a certificate database which stores a plurality of certificates, each certificate being configuration information for defining an isolated execution environment and different ones of the certificates specifying different permitted power usages; and extracting the selected certificate; the initializing of each isolated execution environment being performed based on the configuration information of the extracted certificate.

12. The method of claim 11 , wherein the configuration information of each of the certificates specifies at least one of: a CPU operation rate limit, a memory usage limit, permitted system calls, a permitted power usage limit, a priority value, or permitted device calls.

13. The method of claim 12 in which at least one of the permitted power usage limit or priority value for each isolated execution environment is dependent upon the identity of the user who sent the corresponding request for a program to be executed.

14. The method of claim 13, in which the user is associated with a plurality of certificates, and said extracting a certificate associated with the user from the certificate database comprises selecting the certificate from among the plurality of certificates.

15. The method of claim 14 in which, selecting the certificate comprises selecting a certificate based on at least one requirement defined by the request.

16. A carrier medium comprising computer readable code configured to cause a computer system to perform the method of any preceding claim.

17. A device, comprising one or more processors configured to: receive from one or more users one more requests to execute one or more programs; initialize a plurality of isolated execution environments; execute the one or more programs concurrently in the isolated execution environments;obtain at least one temperature or power usage measurement characterizing the temperature or power usage of at least a portion of the computer system; determine that at least one excessive use criterion is met, the excessive use criterion being based on the at least one temperature or power usage measurement; and based on said determining, modify the operation of at least one of the isolated execution environments without interrupting the operation of all the isolated execution environments.

18. The device of claim 17, in which the device is a hardware security module device.

Images