Patent Description:
In a cloud computing environment, users may make use of remote computer systems within the cloud computing environment to carry out processing tasks on their behalf. Users may therefore provide the computer systems within the cloud computing environment with code to be executed and data to be processed. If a user cannot confidently determine the current configuration of the remote computer systems that they are interacting with, they may be dissuaded from using the cloud computing environment to process code and/or data, especially if that code and/or data is sensitive.

A Trusted Execution Environment (TEE), is a secure area of a processor which guarantees that code and data within the secure area is protected with respect to confidentiality and integrity. Two technologies which provide instantiations of a TEE are Trusted Platform Modules (TPMs) and enclaves.

Trusted Platform Modules (TPMs) are security modules which may be used as part of a computer system to ensure that the computer system is in an expected configuration when it is started up. A TPM securely stores measurements of the code modules that are executed by the computer system whilst it is starting up (which is commonly referred to as booting or the boot process or procedure). These measurements can be used to verify that the correct (i.e. untampered with) code modules were executed by the computer system as part of its boot process. However, a TPM only allows users to verify that the boot process was completed successfully (i.e. that the expected code modules were all executed): it does not allow a user to verify that the current configuration of a computer system is as expected as it does not provide any information about processes that have been executed by the operating system or runtime environment after the boot has been completed.

Another technology which enables a user to partially verify the state of a computing system is the use of enclaves. As an example, an enclave may be created using Microsoft® Virtual Secure Mode (VSM). Alternatively, Intel® processors may include Software Guard Extensions (SGX) instructions which allow a secure enclave to be created. However, other mechanisms for creating enclaves can be used, such as AMD® Secure Encrypted Virtualization (SEV). The code and data for a particular process may be stored and/or processed within an enclave. Data and processing within the enclave is protected from other processes that may be being executed within the computer system, helping to ensure its confidentiality and integrity. Enclaves typically provide an enclave quoting mechanism which enables a user to verify that a process is actually operating inside a valid enclave and also the state of the enclave (e.g. the actual process that is within the enclave). However, whilst these quoting mechanisms enable a user to verify the execution environment of a process within an enclave, it does not provide any verification as to the overall configuration of the computer system (i.e. including any processes that are running outside of the enclave). Furthermore, the computing environment that is provided to a process executing within an enclave is typically relatively limited since it does not have access to higher performance hardware such as graphical processing units (GPUs), networks and so on.

<CIT> discloses a system which is adapted to: record at least one measurement of a virtual trusted execution environment and generate a secret sealed to a state of this measurement; create, using the virtual trusted execution environment, an isolated environment including a secure enclave and an application, the virtual trusted execution environment to protect the isolated environment; receive, in the application, a first measurement quote associated with the virtual trusted execution environment and a second measurement quote associated with the secure enclave; and communicate quote information regarding the first and second measurement quotes to a remote attestation service to enable the remote attestation service to verify the virtual trusted execution environment and the secure enclave and responsive to the verification the secret is to be provided to the virtual trusted execution environment and the isolated environment.

The embodiments described below are not limited to implementations which solve any or all of the disadvantages of known computer systems.

The following presents a simplified summary of the disclosure in order to provide a basic understanding to the reader. This summary is not intended to identify key features or essential features of the claimed subject matter nor is it intended to be used to limit the scope of the claimed subject matter. Its sole purpose is to present a selection of concepts disclosed herein in a simplified form as a prelude to the more detailed description that is presented later.

In various examples, there is a computer-implemented method for providing packages for processing on a computer system. The method creates a secure connection to an enclave and retrieves a quote to verify that the enclave is genuine and that it contains a predetermined process. The predetermined process is configured to create an enclave for itself and determine that an initial state of the computer system is equivalent to a predetermined state based on a quote retrieved from a security module. The predetermined process is further configured to receive a package to be processed by the computer system and cause the processor to process the package outside of the enclave. In response to verifying the enclave, the method provides a package to be processed by the computer system.

The detailed description provided below in connection with the appended drawings is intended as a description of the present examples and is not intended to represent the only forms in which the present examples are constructed or utilized. The description sets forth the functions of the example and the sequence of operations for constructing and operating the example. However, the same or equivalent functions and sequences may be accomplished by different examples.

In an example there is a system comprising: a processor; and a security module arranged to store data representing measurements of each of a plurality of code modules which are to be executed by the processor as part of a boot process for the system; wherein, the system is configured to cause the processor to execute an initial process after completion of the boot process, the initial process being operable to: create an enclave for the initial process, wherein a state of the enclave is remotely verifiable and processing performed by the initial process is performed from within the enclave; retrieve a quote from the security module, the quote comprising a representation of the measurements of the plurality of code modules executed by the processor during the boot process; determine that an initial state of the system is equivalent to a predetermined state based on the retrieved quote; and receive a package comprising code or data or both to be processed by the system; and cause the processor to process the package outside of the enclave.

In another example there is a computer-implemented method for providing packages for processing on a computer system, the method comprising: creating a secure connection to an enclave on the computer system; requesting an enclave quote from the enclave; verifying, using the enclave quote, that the enclave is a genuine enclave and that the process running in the enclave is a predetermined process which is configured to determine that the initial state of the computer system is equivalent to a predetermined state, the predetermined state comprising the predetermined process being executed as an initial process after completion of a boot process for the computer system, and receive one or more packages for processing and cause the one or more packages to be processed outside of the enclave; and in response to verifying that the enclave is a genuine enclave and the process running in the enclave is the predetermined process: provide a package comprising code or data or both to be processed by the computer system using the secure connection.

By verifying that the enclave is a genuine enclave and that the process running in the enclave is a predetermined process which is configured to determine whether the initial state of the computer system is equivalent to a predetermined state, the method can indirectly determine that only trusted modules have been loaded as part of the boot process. In other words, by verifying the behavior of the process to which it is connected conforms to a predetermined (or expected) process, the method can indirectly verify the boot-state of the computer system. This is because the method can verify that the process will check that the initial state of the computer system corresponds to the predetermined state.

Additionally, because the predetermined state of the computer system is one in which the predetermined process is loaded as an initial process, the method can indirectly verify that the predetermined process is being run as an initial process on the computer system. Because the method is able to verify that the initial process is loaded as an initial process, the method can also determine whether the post-boot environment of the computer system can be trusted. This is because it can be determined whether the initial process conforms to a predetermined process which operates to load packages in a way which is acceptable. In some examples, the package that is provided the system further comprises a policy indicating whether another package is permitted to be processed on the same system as the package and the initial process on the system is further operable to: store the policy within the enclave; receive one or more subsequent packages comprising code or data or both; and, for each subsequent package: determine whether that subsequent package is permitted to be processed on the same system as packages previously processed by the system based, at least in part, on whether policies already stored within the enclave permit the subsequent package to be processed on the same system; and if the subsequent package is permitted to be processed by the system, cause the processor to process the subsequent package outside of the enclave. This means that packages can be provided to the system together with a policy and that the provider of a package can trust that the system will not process any packages which are not permitted by the policy provided with the package. This is because the provider can determine that the process that it provides the package to is a predetermined process which will operate in this manner to prevent any other packages being processed which contradict the provided policy.

Although the present examples are described and illustrated herein as being implemented in a computer system, the system described is provided as an example and not a limitation. As those skilled in the art will appreciate, the present examples are suitable for application in a variety of different types of computer systems.

<FIG> is a schematic diagram of a host machine <NUM> (or computer system) at the end of its boot process. The host machine comprises a trusted platform module (TPM) <NUM> and a plurality of code modules <NUM>, <NUM>, <NUM>, <NUM> and <NUM> which have been executed by a processor of the host machine during its boot process.

The TPM <NUM> comprises a plurality of Platform Configuration Registers (PCRs) <NUM>, which are used to securely store and report security relevant metrics. These registers are of a suitable size for storing a digest which is generated by a hashing algorithm. They are zeroed when the host machine <NUM> starts and cannot be directly written to. Instead, the TPM <NUM> allows these PCRs <NUM> to be extended with new values. In particular, the TPM <NUM> extends a particular PCR with a new value by combining the new value with the existing value of the PCR being extended, hashing the combined data and then storing the digest of the combined data that is produced by the hash as the new value of the PCR. As a result of this extension mechanism, the PCRs <NUM> of the TPM <NUM> are able to securely store security relevant metrics or measurements for the host machine <NUM>.

One use of the TPM <NUM> is to keep track of the state of the host machine <NUM> through its boot process. A boot process (or procedure or start-up procedure) for a computer system, such as host machine <NUM>, is an automatic process which brings a computer system from a powered off state into a state where an operating system or runtime environment is running on the computer system which enables a user to run programs on the computer system. Once an operating system or runtime environment is successfully running, the boot process is considered to be complete. In order to get an operating system or runtime environment up and running on a computer system, it is typically necessary for the boot process to execute a sequence of one or more different code (or software) modules, such as the plurality of code modules <NUM>, <NUM>, <NUM>, <NUM> and <NUM>. The boot process also occurs on restart of the computer system.

The TPM <NUM> keeps track of the host machine <NUM> through its boot process by using the PCRs <NUM> of the TPM <NUM> to securely record (or store) measurements, such as hashes or signatures, of the code modules <NUM>, <NUM>, <NUM>, <NUM> and <NUM> which are executed by the host machine <NUM> during the boot process. The state of the computer system is verifiable following the boot process by checking that the PCRs <NUM> contain the expected values. If different or additional or fewer code modules from those that are expected were to be executed during the boot process, it is highly unlikely that the PCRs would contain the correct values. Therefore, if the PCRs <NUM> contain the expected values there is a very reliable indication that the expected code modules (and only the expected code modules) have been executed during the boot process.

To allow a user of the host machine <NUM> to check that the PCRs <NUM> contain the expected value, the TPM <NUM> provides a quoting mechanism which provides, on request, a TPM quote which includes a representation of the measurements of the plurality of code modules which were executed by the processor of the host machine <NUM> as stored in the PCRs <NUM>. In examples, the TPM <NUM> quote is used to check that the PCRs <NUM> contain the expected value and that the boot process of the host machine was completed successfully (i.e. with the expected code modules being executed). However, whilst the TPM <NUM> allows users to verify that the boot process was completed successfully, it does not provide any information about the configuration of the host machine after the boot has been completed. In particular, once an operating system or runtime environment has been started, code modules (or packages) are executed without being monitored by the TPM <NUM>.

A typical boot process for a modern computer system involves multiple code modules <NUM>, <NUM>, <NUM>, <NUM>, <NUM> being loaded in sequence. Generally (though not necessarily), each code module is increasingly complex and provides additional functionality from the previously execute code modules to allow the next code module to be loaded, until sufficient functionality has been provided to enable the operating system or runtime environment to be loaded.

The boot process starts with a first code module <NUM>. The first code module <NUM> that is executed as part of the boot process is typically much smaller in size and complexity compared to an operating system or runtime that will eventually be loaded. The first code module <NUM> is typically loaded from a read-only memory, although, in some cases, other means of storing the first code module are used instead. As illustrated in <FIG>, the first code module <NUM> may be a Basic Input/Output System (BIOS) code module. However, in some cases, other code modules are loaded as the first module <NUM> instead, such as a Unified Extensible Firmware Interface (UEFI) code module. Alternatively, a Power-On Self-Test (POST) (or other hardware integrity checking) module is the first code module <NUM> in the boot process with the BIOS being loaded as a subsequent boot module. However, POST modules may more typically be considered to occur pre-boot since in some cases they are carried out by hardware before any code modules are loaded. The first code module <NUM> typically provides a fundamental functionality, such as enabling access to hard drives to allow subsequent code modules <NUM>, <NUM>, <NUM>, <NUM> to be loaded and executed to complete the boot process.

As part of the boot procedure, a measurement is made of the first code module <NUM>. For example, a hash of the binary image which makes up the first code module <NUM> is used as a measurement. This measurement is then stored in the TPM <NUM> by extending one of the PCRs <NUM>. This measurement is performed before, after or during the execution of the first code module <NUM> as long as it is performed before the next measurement is stored in the TPM (since the extension operation of the TPM <NUM> for writing to the PCRs <NUM> is non-commutative).

Once the first code module <NUM> has been executed, the boot process of the host machine <NUM> illustrated in <FIG> proceeds to load and execute a GRUB boot loader as a second code module <NUM>. GRUB serves to provide functionality to understand file systems which is not typically provided by the BIOS. This is usually needed to load the later more complex modules (as well as the ultimate operating system or execution environment) which are normally stored within a file system and cannot therefore be accessed by the BIOS code module <NUM>. The file system support provided by GRUB is relatively limited compared to later modules, serving simply to allow the later modules to be loaded and executed. Of course, in other examples, different code modules may be loaded as the second code module <NUM>, including, for example, Microsoft's BOOTMGR or the LILO bootloader for Linux. The second code module <NUM> is measured in a similar manner the first code module <NUM> and the measurement is stored in the TPM <NUM> by extending one of the PCRs <NUM>.

Once the second code module <NUM> has been executed, the boot process of the host machine <NUM> illustrated in <FIG> proceeds to load and execute a Trusted Boot (tboot) module as a third code module <NUM>. This code module forms part of a secure boot process by verifying a digital signature of a kernel which is to be loaded as a subsequent code module in the boot process. The third code module <NUM> is measured in a similar manner to the first and second code modules <NUM> and <NUM> and the measurement is stored in the TPM <NUM> by extending one of the PCRs <NUM>.

Once the third code module <NUM> has been executed, the boot process of the host machine <NUM> illustrated in <FIG> proceeds to load and execute a Kernel module as a fourth code module <NUM>. This module provides wide ranging functionality for allowing processes to run on the host machine <NUM> including, for example, interacting with and managing various different types of memories and interfaces that are present, as well as various peripheral devices. As such, the Kernel module provides functionality to facilitate other processes to run. The fourth code module <NUM> is measured in a similar manner to the preceding code modules <NUM>, <NUM> and <NUM> and the measurement is stored in the TPM <NUM> by extending one of the PCRs <NUM>.

Once the fourth code module <NUM> has been executed, the boot process of the host machine <NUM> illustrated in <FIG> proceeds to load and execute an Initial Ramdisk (initrd) module as a fifth code module <NUM>. This module is used to enable more advanced file systems (such as those on a RAID volume, encrypted partitions or file systems which similar require other special preparations in order to be mounted). The fifth code module <NUM> is measured in a similar manner to the preceding code modules <NUM>, <NUM>, <NUM> and <NUM> and the measurement is stored in the TPM <NUM> by extending one of the PCRs <NUM>.

Whilst the boot process discussed above in relation to the host machine <NUM> illustrated in <FIG> comprises five code modules <NUM>, <NUM>, <NUM>, <NUM> and <NUM>, it will be appreciated that a different (either greater or fewer) number of modules may be used. Indeed, in some embodiments, the boot process may comprise a single code module. This may be more suitable, for example, in embedded systems where basic functionality is provided. Furthermore, although specific code modules have been discussed above in relation to the boot process for the host machine <NUM> illustrated in <FIG>, it will be appreciated that other code modules may be used instead. In other words, the code modules comprised in the boot process for other examples differ in terms of the number of code modules, the type of code modules, or both. Similarly, although the host machine <NUM> illustrated in <FIG> makes use of a TPM <NUM> as a security module to store the measurements of the code modules <NUM>, <NUM>, <NUM>, <NUM> and <NUM> that are executed as part of the boot process for the host machine <NUM>, it will be appreciated that a different type of security module which provides secure storage and quoting of these measurements is used in some examples.

<FIG> is a flow diagram of a method <NUM> for execution as an initial process on the host machine <NUM> illustrated in <FIG>. The initial process is so-called because it is the first process to be run after completion of the boot process for the host machine <NUM>. The method <NUM> is started <NUM> when the boot process for the host machine <NUM> has been completed. That is to say, execution of the method <NUM> is begun once the final code module <NUM> that forms part of the boot process has been executed. Hence, the method <NUM> is run as an initial process after the boot process has been completed. Therefore, the execution of the method <NUM> as an initial process is caused by one of the code modules executed during the boot process. This method <NUM> is now discussed in conjunction with <FIG> which is a schematic diagram of the host machine <NUM> illustrated in <FIG> with the method <NUM> running as an initial process.

At an operation <NUM>, the method <NUM> creates an enclave <NUM> for the initial process. For example, the processor of the host machine <NUM> supports SGX instructions and the initial process comprises code which issues SGX instructions to the processor to create an enclave <NUM> for the initial process. However, other ways of creating an enclave <NUM> for the initial process are used in some examples. By operating within the enclave <NUM>, the data and code for the initial process are protected from other processes which are operating on the host machine <NUM> outside the enclave. This means that other processes operating on the host machine <NUM> cannot tamper with or otherwise alter the code and data for the initial process. Therefore, by operating within an enclave, the correct operation of the initial process is assured. The current state of the enclave <NUM> is remotely verifiable. For example, the enclave provides an enclave quoting mechanism which enables a user (either local or remote to the system) to request a quote which may be used to verify that the process that they are communicating with is operating inside a valid enclave, as well as the state of the enclave <NUM> itself. Therefore, using this quoting mechanism, a user is able to test that the initial process is the initial process that they were expecting to communicate with (e.g. rather than a tampered version or emulation of the initial process) and that the initial process is operating inside of an enclave. However, it will be appreciated that other mechanisms for allowing the current state of the enclave <NUM> to be verified are used in some examples.

At an operation <NUM>, the method <NUM> requests a quote <NUM> from the TPM <NUM>. The quote <NUM> (referred to as a TPM quote where the security module is a TPM <NUM> or a security module quote where it is not), includes a representation of the measurements of the plurality of code modules which were executed by the processor of the host machine <NUM> during its boot process. Where the security module is a TPM <NUM>, the quote <NUM> is signed to provide an assurance that the quote that is received was actually generated by the TPM <NUM>. Similar assurances are also provided by other types of security module in some examples. Therefore, when the quote <NUM> is received, the method <NUM> is able to verify that the quote <NUM> was actually issued by the TPM <NUM>.

At an operation <NUM>, the method <NUM> determines whether an initial state of the system (or system state) is equivalent to a predetermined state based on the retrieved quote <NUM>. The initial state of the system refers to the state that the system is in immediately following the completion of the boot process (i.e. at the point that the initial process is started). Of course, it will be appreciated that the quote <NUM> itself may not be retrieved immediately following the completion of the boot process. However, the contents of the quote <NUM> are representative of the state of the system upon completion of the boot process. The method <NUM> uses the representation of the measurements of the plurality of code modules to check that the correct code modules were executed during the host machine's boot process. If the correct code modules were executed, the representation of the measurements of those code modules contained in the quote <NUM> match predetermined value(s) associated with the predetermined state. However, if different or additional (or fewer) code modules were executed, the representation of the measurements of the code modules contained in the quote <NUM> is highly unlikely to match the predetermined value(s). Therefore, if the representation of the measurements of those code modules contained in the quote <NUM> match the predetermined value(s), the method <NUM> determines that the initial state matches the predetermined state. By verifying that the initial state of the system is equivalent to a predetermined state, the method can verify that only trusted (i.e. predetermined) components were executed during the boot process.

The predetermined state of the host machine <NUM> is only likely reached if the code modules which are expected by the initial process have been executed during the boot process. As discussed above, the execution of the method <NUM> as an initial process on the host machine <NUM> is caused by one of the code modules which is executed during the boot process. Therefore, the execution of the method <NUM> as an initial process on the machine (as opposed to a subsequent process) is guaranteed because it is implicit in the boot process that the boot process launches the method <NUM> as the initial process. In other words, if the boot process were modified to cause some other process to be executed as the initial process, the representation of the measurements contained in the quote <NUM> would not match the predetermined value(s) associated with the predetermined state.

If the initial system state of the host machine <NUM> is not equivalent to the predetermined state (as determined based on the quote retrieved from the TPM <NUM>), the method <NUM> acts to prevent packages from being received or processed by the initial process. As an example, the method <NUM> terminates the initial process, in which case the method <NUM> proceeds to end at an operation <NUM>. However, other ways of preventing packages from being received or processed by the initial process are used in some cases. The method <NUM> takes other optional actions if the initial system state does not match the predetermined state, such as issuing notifications to an administrator or causing a reset of the software on the machine.

In addition to using the quote <NUM> to determine whether the initial state of the host machine <NUM> matches the predetermined state, the method <NUM> stores the quote <NUM> inside the enclave <NUM> for future use. By storing the quote <NUM> inside the enclave <NUM>, it is inaccessible by any other processes operating on the host machine <NUM>. Of course, the method <NUM> need not store the quote <NUM> if it will not be needed for future use.

As part of operation <NUM>, the method <NUM>, optionally, sets an owner password for the TPM <NUM>. This password is stored in the TPM <NUM> sealed to the current state of the machine (i.e. to the initial state of the machine following a successful correct boot process). This means that the password can only be retrieved when the PCRs <NUM> contain the correct measurements which correspond to the initial state. Therefore, on subsequent reboots of the host machine <NUM>, the initial process is able to access the TPM owner password from the TPM <NUM>. This TPM owner password is used in order to be permitted to carry out various functions on the TPM <NUM>, such as extending the PCRs <NUM> or requesting quotes.

At an operation <NUM>, the method <NUM> instructs the TPM <NUM> to store arbitrary data <NUM> as one or more additional measurements. The arbitrary data <NUM> is randomly (or pseudo-randomly) generated data or is predetermined. The TPM <NUM> stores the arbitrary data <NUM> by extending the values stored in the relevant PCRs <NUM>. Therefore, the values stored in the PCRs <NUM> of the TPM <NUM> are different from those which were present immediately following completion of the boot process. This means that any subsequently retrieved quote from the TPM <NUM> will contain a different representation of the measurements from that contained in the quote <NUM> retrieved in operation <NUM>. This prevents an additional version of the method <NUM> from being run in another process which is executed subsequent to the initial process because the quote <NUM> which would be retrieved by the method <NUM> running in another process would not contain a representation of the measurements which corresponds to the predetermined state (which would otherwise correspond to the predetermined state if the boot process had caused the method <NUM> to also be run in an initial process). As illustrated in <FIG>, following completion of this operation, the values stored in the PCRs <NUM> of the TPM <NUM> are different from those following the boot of host machine <NUM> as shown in <FIG>. This also means that, where the TPM owner password has been stored in the TPM <NUM> sealed to the initial state of the host machine <NUM> in operation <NUM>, the owner password is no longer be retrievable by any other process (since the PCRs <NUM> no longer contain the correct measurements which correspond to the initial state). This helps prevent other processes from attempting to mimic the initial process, since only the initial process is able to obtain the owner password from the TPM <NUM>.

To verify that the measurements stored in the PCRs <NUM> of the TPM <NUM> no longer match the predetermined state of the host machine <NUM>, the method <NUM>, at an optional operation <NUM>, retrieves a second quote from the TPM <NUM>. The second quote includes a representation of the measurements that are stored in the TPM <NUM> following the storage of the arbitrary data <NUM> as one or more additional measurements.

Having retrieved the second quote at the optional operation <NUM>, the method <NUM>, at an optional operation <NUM>, determines whether the measurements represented in the second quote are the same as the measurements represented in the quote that was originally retrieved at operation <NUM>. If the measurements are the same between the two quotes, the method returns to operation <NUM> to store additional arbitrary data as one or more additional measurements and checks whether a quote retrieved after storing the additional arbitrary data matches the original quote retrieved at operation <NUM>. The method <NUM> repeats these operations until the two quotes are different. Alternatively, the method <NUM> ceases its processing if the two quotes match. This serves to prevent the method <NUM> from receiving or processing packages in the subsequent operations of the method <NUM> if the quotes remain the same.

At an operation <NUM>, the method <NUM> waits to receive a package comprising code or data or both to be processed by the system. When a package is received, the method <NUM> proceeds to an operation <NUM>. Periodically, while waiting for a package to be received, the method <NUM>, at an operation <NUM>, determines whether the initial process should terminate. This termination of the initial process is, for example, a result of a shutdown or reboot signal being issued for the host machine <NUM>. If it is determined that the initial process is to terminate, the method <NUM> proceeds to end at an operation <NUM>. However, if it is not determined that the initial process should terminate, the method <NUM> continues to wait for a package to be received for processing.

At an operation <NUM>, once a package has been received, the method <NUM> causes the processor to process the package. This operation will be discussed in more detail below in conjunction with <FIG>, <FIG>, <FIG>, <FIG> and <FIG>.

<FIG> is a flow diagram of a method <NUM> for providing packages for processing to the host machine illustrated in <FIG>. This method <NUM> will be discussed in conjunction with <FIG> which is a schematic diagram of the host machine of <FIG> being verified by a remote user.

At an operation <NUM>, the method <NUM> starts a package provision method <NUM> by creating a secure connection <NUM> to the enclave <NUM> on the host machine <NUM>. For example, the method <NUM> creates a TLS connection to the enclaved initial process. The TLS connection uses a self-signed certificate, which is later verified in a subsequent operation. This avoids the need for certificate provisioning.

At an operation <NUM>, the method <NUM> requests a quote <NUM> from the enclave <NUM>. The quote <NUM> is referred to as an enclave quote or, where the enclave <NUM> is created using SGX instructions supported by a processor, as an SGX quote. The quote <NUM> enables the enclave and its contents to be verified.

At an operation <NUM>, the method <NUM> uses the quote <NUM> to verify that the enclave <NUM> is a genuine enclave and that the process running in the enclave is a predetermined process which is executed as an initial process on the host machine <NUM>. The verification of the enclave as being a genuine enclave means that the enclave was created by a trusted system, such as by a process in response to an SGX instruction, and that the integrity and confidentiality of the contents of the enclave will therefore be protected by the trusted system. If the initial process is being run outside of an enclave, or within a simulated enclave that is created by a non-trusted system (and which may not provide the required guarantees for the integrity and confidentiality of the contents of the enclave), the enclave will not be verified as a genuine enclave. It will be appreciated that there are numerous different techniques which can be used to verify an enclave. In some examples, verifying that the enclave is a genuine enclave comprises providing the quote (or part of the quote) to an enclave attestation service <NUM> to verify that the quote was produced by a genuine enclave. For example, where the enclave <NUM> is an SGX enclave, the enclave attestation service <NUM> may be an Intel® SGX enclave attestation service. The attestation service <NUM> checks the quote to verify that the quote has been signed by a known key which has been provisioned to processors for creating enclaves. The attestation service <NUM> provides an indication that the quote originates from a genuine enclave if the quote has been signed by a known key. Otherwise, in other examples, this check is performed by the method <NUM> itself.

At an operation <NUM>, the method <NUM> provides a package to the host machine <NUM> for processing. This is the last operation of the package provision method <NUM>.

<FIG> is a schematic diagram of the host machine <NUM> of <FIG> being provided with a package <NUM> for processing, as occurs at operation <NUM> of the method <NUM> for providing a package for processing at the host machine <NUM>. The package <NUM> comprises code or data or both <NUM> for processing by the host machine <NUM>. For the purposes of this description, code may be considered to be instructions which cause the processor to carry out particular actions, whilst data may be values upon which those actions operate. That is to say, the code in a package is directly executed by the host machine <NUM> whilst data in the package is made available to be accessed by executing instructions. In some examples, processing a package comprising data involves storing the data such that it is available to processes executing on the computer system. Meanwhile, in some examples, processing a package comprising code involves executing the instructions using the processor of the host machine <NUM>. In some examples, the data comprises configuration data which affects the manner in which the code operates. In some examples, the data comprises one or more sets of values, each set of values containing representations of a respective qualitative or quantitative variable. In such examples, the code may comprise instructions for processing the sets of values to provide analysis of the respective qualitative or quantitative variables.

Optionally, the package comprises a policy <NUM>. This policy <NUM> is called a trust policy because it indicates whether another package is permitted to be processed on the same host machine <NUM> as the package <NUM> (i.e. whether another package is permitted to coexist with the package <NUM> on the host machine <NUM>). For example, the policy <NUM> includes a hash for each of the other packages that the remote user <NUM> providing the package <NUM> will permit to be processed on the same host machine <NUM> as the package <NUM>. The policy <NUM> also or alternatively includes public keys of package providers which the remote user <NUM> trusts. Therefore, any packages which are signed by a private key which corresponds to one of the public keys is permitted to be processed on the same host machine <NUM> as the package <NUM>. The policy <NUM> also specifies other conditions which permit or prevent other packages being processed on the same host machine <NUM> as the package <NUM>. These conditions are based on the current state or other environmental factors of the host machine <NUM>. In some examples, packages which comprise code are only permitted by a policy which contains a hash for that specific package, whereas packages which only consist of data to be processed (for example by code provided with a previous package) are permitted by a policy <NUM> which contains either a hash of the package or a public key which corresponds to a private key which has been used to sign the packages. In other words, in some examples, a package which is signed by a private key corresponding to one of the one or more public keys included in the policy <NUM> is only permitted to be processed on the host machine <NUM> if the signed package does not comprise any code.

Where no policy <NUM> is provided with the package <NUM>, the host machine <NUM> either takes a permissive view or a restrictive view as to other packages that are permitted to be processed on the same system. For example, the host machine <NUM> takes a permissive view in the absence of a policy <NUM> for a package <NUM> as meaning that any other packages are permitted to coexist with the package <NUM>. Alternatively, the host machine <NUM> takes a restrictive view in the absence of a policy <NUM> for package <NUM> as meaning that no other packages are permitted to coexist with the package <NUM>. Following this restrictive approach results in the host machine <NUM> being "single use" in the case where no policies are specified because no other packages are permitted to be processed on the host machine <NUM> after the package <NUM> is processed.

Having received the package <NUM>, the method <NUM> running as the initial process on the host machine <NUM> proceeds to process the package <NUM> at operation <NUM>. This is now discussed in more detail in conjunction with <FIG> which is a flow diagram of operation <NUM> of method <NUM> showing the sub-operations for processing the package in more detail.

At a sub-operation <NUM>, operation <NUM> determines whether there are any policies stored within the enclave <NUM> on the host machine <NUM> which would prevent the received package <NUM> from being processed by the host machine <NUM>. These policies are policies of previous packages which have already been received by the host machine <NUM> in previous iterations of operation <NUM>. Additionally or alternatively, the policies are preloaded and stored in the enclave <NUM> by the initial process itself. For example, the initial process is configured to preload a trusted public key for a package provider which is permitted to process packages on the host machine <NUM>. In any case, where there are already policies stored within the enclave <NUM> on the host machine <NUM>, operation <NUM> checks these stored policies to determine whether the received package <NUM> is permitted to be processed on the host machine <NUM>. If no policies are stored within the enclave <NUM> on the host machine <NUM>, the package is permitted to be processed on the host machine <NUM>.

The host machine <NUM> adopts a restrictive or a permissive approach towards its consideration of the overall policy of the host machine <NUM> represented by the stored policies. Following a restrictive approach, the host machine <NUM> requires a package to be explicitly permitted by all policies stored in the enclave <NUM>. This approach ultimately results in a narrowing of the packages which are permitted on the host machine <NUM> as each policy narrows (or, at best, has no effect on) the overall policy for the machine (i.e. the composite of all the policies stored in the enclave <NUM>). However, following a permissive approach, the host machine <NUM> only requires a single policy to permit the package <NUM> for it to be allowed to be proceed on the host machine <NUM>. This approach allows for the overall policy of the machine <NUM> to be expanded beyond the policy of a first package, thereby allowing greater flexibility. However, this approach also reduces the security for package providers, since there is less strict control over the other packages which are permitted to be processed on the same host machine <NUM>.

Sub-operation <NUM> is optional and, in some examples, the host machine <NUM> does not explicitly attempt to determine whether a received package is permitted by referring to stored policies. For example, the host machine <NUM> is a "single use" system, in which case the first package to be received is permitted while any subsequently received packages are not permitted. As a further example, a separate authentication and authorization system is used to restrict access to the host machine <NUM> to a specific user or group of users. In this case, the host machine <NUM> accepts any packages which are received, so long as the user is authenticated and authorized to provide packages to the host machine <NUM>. However, the use of policies associated with packages that are provided for processing by the host machine <NUM> helps provide greater transparency and control over the processing that is performed by the host machine <NUM> for remote users.

If there are no policies stored within the enclave <NUM> on the host machine <NUM> which prevent the received package <NUM> from being processed by the host machine <NUM> (i.e. the received package <NUM> is permitted to coexist with the packages already on the host machine <NUM>), the operation <NUM> proceeds to a sub-operation <NUM>. Otherwise, the operation <NUM> proceeds to a sub-operation <NUM> which is described in more detail later.

At sub-operation <NUM>, the operation <NUM> determines whether a policy associated with the received package <NUM> itself permits the package <NUM> to be processed alongside any other packages which have been received and processed by the host machine <NUM>. As described above, in some examples, the received package <NUM> does not comprise a policy <NUM>, in which case sub-operation <NUM> is optional and processing proceeds straight to sub-operation <NUM>. However, where a policy <NUM> is provided with the received package <NUM>, the operation <NUM> checks, for each of the packages that have been previously processed by the host machine <NUM>, whether that package is permitted to be processed on the same system as the received package <NUM> according to the policy <NUM> of the received package <NUM>. Accordingly, the operation <NUM> carries out a two-part check as to whether a package <NUM> is permitted on the host machine <NUM>. The first check carried out at sub-operation <NUM> based on the composite policy of all policies received previously, and the second check carried out at sub-operation <NUM> based on the policy <NUM> provided with the package <NUM> itself. In this manner, the operation <NUM> can prevent packages which are permitted to coexist with each other from being processed on the host machine <NUM>.

If it is determined at either sub-operation <NUM> or sub-operation <NUM> that the received package <NUM> cannot be processed by the host machine <NUM> due to a policy conflict, operation <NUM> proceeds to a sub-operation <NUM> in which the package <NUM> is rejected. The rejection of the package ends the operation <NUM>. In some examples, operation <NUM> sends a response <NUM> to the remote user <NUM> to notify them that their package <NUM> has been rejected (and has not therefore been processed). In some examples, the response includes details as to why the package <NUM> was not processed. For example, the response identifies the policy which prevented the package <NUM> from being processed.

At a sub-operation <NUM>, the operation <NUM> stores the policy <NUM> associated with the received package <NUM> in the enclave. The policy <NUM> is then used in future iterations of operation <NUM> when subsequent packages are received to prevent or permit the subsequent packages from being provided to and processed by the host system <NUM>. By storing the policy <NUM> in the enclave its integrity and confidentiality from other processes executing on the host machine <NUM> is assured. This means that the policies stored in the enclave cannot be tampered with by any other process on the machine (such as, for example, code provided for processing with a subsequent package). As mentioned above, in some examples, the received package <NUM> might not comprise a policy <NUM>. In this case, sub-operation <NUM> is optional, in which case processing proceeds directly to a sub-operation <NUM>.

At a sub-operation <NUM>, the operation <NUM> causes the processor to process the package <NUM> independently from the initial process outside of the enclave <NUM>. By processing the package <NUM> independently from the initial process outside of the enclave <NUM>, the package <NUM> is not limited by the relatively restrictive execution environment that is provided by the enclave <NUM>. This means that the package <NUM> is able to take full (or at least greater) advantage of the execution environment provided by the host machine <NUM>. At the same time, by processing the package <NUM> independently from the initial process outside of the enclave <NUM>, the initial process and its data (such as any stored policies) are protected from any processing performed by the package <NUM>. This means that processing of packages on the system cannot alter the behavior of the initial process. After causing the processor of the host machine <NUM> to process the package <NUM>, operation <NUM> finishes and method <NUM> (shown in <FIG>) returns to operation <NUM> to either wait for a further package or terminate the initial process.

<FIG> is a schematic diagram of the host machine <NUM> illustrated by <FIG> processing the package <NUM>. In particular, following the operation of sub-operation <NUM> of operation <NUM>, the policy <NUM> has been stored in the enclave <NUM>. Meanwhile, following the operation of sub-operation <NUM> of operation <NUM>, the code or data or both <NUM> of the package <NUM> is being processed independently from the initial process and outside of the enclave <NUM>.

<FIG> is a schematic diagram of the host machine <NUM> illustrated by <FIG> being provided with a subsequent package <NUM> for processing. A remote user <NUM> follows the same method <NUM> as discussed above in relation to <FIG> to provide the package <NUM>. Specifically, the remote user <NUM> creates a secure connection <NUM> to the host machine <NUM> and, after verifying that the secure enclave is a genuine enclave and is running the expected initial process (i.e. the predetermined initial process that the remote user <NUM> is expecting), provides a package <NUM> for processing by the host machine <NUM>. The remote user <NUM> providing the subsequent package <NUM> is the same remote user <NUM> that provided a previous package <NUM> or is a different user. Where the remote user <NUM> is the same user <NUM> that provided a previous package <NUM>, the secure connection <NUM> is, in some cases, the same connection <NUM> that was used to provide the previous package <NUM>. Of course, in other cases, the secure connection <NUM> is a different connection, even where the remote user <NUM> is the same user <NUM> that provided a previous package <NUM>.

The processing of the subsequent package <NUM> is discussed further in conjunction with <FIG> which is a schematic diagram of the host machine <NUM> of <FIG> processing the subsequent package. As discussed above, the subsequent package <NUM> comprises code or data or both <NUM> and, optionally, includes a policy <NUM>. When the subsequent package <NUM> is received the method <NUM> running as the initial process on the host machine <NUM> proceeds to process the package at operation <NUM>.

At sub-operation <NUM>, operation <NUM> checks that the subsequent package <NUM> is permitted to be processed on the same host machine <NUM> as the previous package <NUM> based, at least in part, on the policy <NUM> for the previous package <NUM> which was previously received and stored in the enclave <NUM>. In other words, operation <NUM> checks the policy <NUM> to determine whether it indicates that the subsequent package <NUM> is permitted by the policy <NUM> (for example, by comparing a hash of the subsequent package <NUM> with hashes included in the policy <NUM>). Since, in this example, the policy <NUM> for the previous package <NUM> permits the subsequent package <NUM> to coexist on the same host machine <NUM>, the operation <NUM> proceeds to sub-operation <NUM>. However, if the policy <NUM> for the previous package <NUM> did not permit the subsequent package <NUM> to coexist on the same host machine <NUM>, operation <NUM> proceeds to reject the subsequent package by proceeding to sub-operation <NUM>.

At sub-operation <NUM>, operation <NUM> checks that the subsequent package <NUM> is permitted to be processed on the same host machine <NUM> as the previous package <NUM> based, at least in part, on the policy <NUM> for the subsequent package <NUM>. In other words, operation <NUM> checks the policy <NUM> for the subsequent package <NUM> to determine whether it indicates that the previous package <NUM> is permitted by the policy <NUM> (for example, by comparing a hash of the previous package <NUM> with hashes included in the policy <NUM>). Since, in this example, the policy <NUM> for the subsequent package <NUM> permits the subsequent package <NUM> to coexist on the same host machine <NUM> as the previous package <NUM>, the operation <NUM> proceeds to sub-operation <NUM>. However, if the policy <NUM> for the subsequent package <NUM> did not permit the subsequent package <NUM> to coexist on the same host machine <NUM> as the previous package <NUM>, operation <NUM> would proceed to reject the subsequent package by proceeding to sub-operation <NUM>.

At sub-operation <NUM>, operation <NUM> stores the policy <NUM> associated with the subsequent package <NUM> in the enclave <NUM> together with any previously received policies (e.g. policy <NUM>). This means that both of the policies <NUM> and <NUM> are considered when determining whether to process any further packages. The operation <NUM> then proceeds to sub-operation <NUM>.

At sub-operation <NUM>, operation <NUM> causes the processor of the host machine <NUM> to process the subsequent package <NUM> independently from the initial process outside of the enclave <NUM>. This means that both packages <NUM> and <NUM> are processed together on the host machine <NUM> outside of the enclave. As an example, the original package <NUM> comprises data, whilst the subsequent package <NUM> comprises code for carrying out an analysis of that data. Further packages may be received from numerous different parties to add additional data and/or code to be processed on the host machine <NUM> (provided that any specified policies have been satisfied). In some examples, the host machine <NUM> also processes packages which are loaded automatically by the initial process (i.e. which are loaded without having been received from a remote user). These automatically loaded packages serve to provide functionality which may be utilized by packages which are received from remote users.

Even though the remote user <NUM> and <NUM> does not necessarily know what other packages have already been received and processed by the host machine <NUM> or what packages might be subsequently received and processed, the remote user <NUM> and <NUM> is able to verify the initial process that is running method <NUM> in the enclave <NUM> is an expected initial process (i.e. it is equivalent to a predetermined process which the user <NUM> and <NUM> is expecting to run as the initial process on the host machine <NUM>) which operates in a manner which is known to the user <NUM> and <NUM>. Therefore, the user <NUM> and <NUM> is assured that the initial process will verify that the initial state of the host system <NUM> matches a predetermined state to ensure that only trusted components were executed during the boot process. The user <NUM> and <NUM> is also assured that the initial process will operate method <NUM> on the host machine <NUM> to prevent their package from being processed if it is incompatible with (i.e. not allowed to coexist with) the packages already processed by the host machine <NUM>. Similarly, the user <NUM> and <NUM> is assured that the initial process will operate method <NUM> on the host machine <NUM> to prevent further packages being processed by the machine which are incompatible with the user's package <NUM> and <NUM> as specified by the policy <NUM> and <NUM> provided with the package <NUM> and <NUM>.

Although in the above description, the user <NUM> and <NUM> has been described as being remote from the host machine <NUM>, in other examples, at least one of the users <NUM> and <NUM> is local to the host machine <NUM>. The process by which a local user <NUM> provides packages to the host machine <NUM> for processing is the same as for a remote user. That is, the local user verifies that the initial process is the correct initial process and that it is running inside an enclave. The local user provides a package to be processed to the initial process, which proceeds to process the package if all policies stored in the initial processes' enclave and associated with the package itself have been satisfied. In this sense, it will be appreciated that the initial process acts as a kind of gateway, being the only way of providing packages to the host machine <NUM> for processing and controlling which packages are processed based on associated policies, regardless of whether a user is local to or remote from the host machine <NUM>. Where local use of the host machine <NUM> is supported, the initial process provides some more advanced functionality akin to that provided by operating systems to aid the user in providing packages to the initial process on the host-machine for processing. Similarly, although the term user is used, it will be appreciated that, in some examples, the user may be an automated entity.

In some examples, the host machine <NUM> may be provided as computer within a cloud computing environment. One aspect of a cloud computing environment is the provision of on-demand computing resources to users. In particular, in some cases, when using a cloud computing environment a user, is dynamically allocated computing resources. In such cases, the user may not know any previous information about the computing resource (i.e. host machine <NUM>) prior to its allocation to the user. Therefore, the user might not know what processes have already been run or are running on the host machine. However, by providing the host machine <NUM> as a computing resource within the cloud computing environment, the above-described method for providing packages, as illustrated in <FIG>, enables the user to verify that the current state of the host machine <NUM> is acceptable to them (i.e. that it is operating in a predetermined manner based on the operation of the predetermined process starting from a predetermined state). However, it will of course be appreciated that the same method can be used to verify host machines <NUM> outside of a cloud computing environment.

<FIG> illustrates an exemplary computing-based device in which embodiments of a package processing system and computer-implemented method for providing packages for processing are implemented.

Computing-based device <NUM> comprises one or more processors <NUM> which are microprocessors, controllers or any other suitable type of processors for processing computer executable instructions to control the operation of the device in order to operate as the above-described host machine <NUM> or to carry out the method <NUM> for providing packages to the host machine <NUM> for processing. In some examples, for example where a system on a chip architecture is used, the processors <NUM> include one or more fixed function blocks (also referred to as accelerators) which implement a part of the methods of <FIG>, <FIG> and <FIG> in hardware (rather than software or firmware).

The computer executable instructions are provided using any computer-readable media that is accessible by computing based device <NUM>. Computer-readable media includes, for example, computer storage media such as memory <NUM> and communications media. Computer storage media, such as memory <NUM>, includes volatile and non-volatile, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or the like. Computer storage media includes, but is not limited to, random access memory (RAM), read only memory (ROM), erasable programmable read only memory (EPROM), electronic erasable programmable read only memory (EEPROM), flash memory or other memory technology, compact disc read only memory (CD-ROM), digital versatile disks (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transmission medium that is used to store information for access by a computing device. In contrast, communication media embody computer readable instructions, data structures, program modules, or the like in a modulated data signal, such as a carrier wave, or other transport mechanism. As defined herein, computer storage media does not include communication media. Therefore, a computer storage medium should not be interpreted to be a propagating signal per se. Although the computer storage media (memory <NUM>) is shown within the computing-based device <NUM> it will be appreciated that the storage is, in some examples, distributed or located remotely and accessed via a network or other communication link (e.g. using communication interface <NUM>).

The computing-based device <NUM> also comprises an input/output controller <NUM> arranged to output display information to a display device <NUM> which may be separate from or integral to the computing-based device <NUM>. The display information may provide a graphical user interface. The input/output controller <NUM> is also arranged to receive and process input from one or more devices, such as a user input device <NUM> (e.g. a mouse, keyboard, camera, microphone or other sensor). In some examples the user input device <NUM> detects voice input, user gestures or other user actions and provides a natural user interface (NUI). In an embodiment the display device <NUM> also acts as the user input device <NUM> if it is a touch sensitive display device. The input/output controller <NUM> outputs data to devices other than the display device in some examples, e.g. a locally connected printing device (not shown in <FIG>). Of course, in some examples, the computing-based device <NUM> may operate as a headless server, without a permanently connected display device <NUM> or user input device <NUM>. In this configuration, the computing-based device <NUM> may rely on communication interface <NUM> for all input/output.

Alternatively, or in addition, the functionality described herein is performed, at least in part, by one or more hardware logic components. For example, and without limitation, illustrative types of hardware logic components that are optionally used include Field-programmable Gate Arrays (FPGAs), Application-specific Integrated Circuits (ASICs), Application-specific Standard Products (ASSPs), System-on-a-chip systems (SOCs), Complex Programmable Logic Devices (CPLDs), Graphics Processing Units (GPUs).

Claim 1:
A system (<NUM>) comprising:
a processor (<NUM>); and
a security module (<NUM>) arranged to store data representing measurements of each of a plurality of code modules (<NUM>, <NUM>, <NUM>, <NUM>, <NUM>) which are to be executed by the processor (<NUM>) as part of a boot process for the system (<NUM>);
wherein, the system (<NUM>) is configured to cause the processor (<NUM>) to execute an initial process (<NUM>) after completion of the boot process and before any subsequent processes, the initial process (<NUM>) being operable to:
create (<NUM>) an enclave (<NUM>) for the initial process (<NUM>), wherein a state of the enclave (<NUM>) is remotely verifiable and processing performed by the initial process (<NUM>) is performed from within the enclave (<NUM>);
retrieve (<NUM>) a quote (<NUM>) from the security module (<NUM>), the quote (<NUM>) comprising a representation of the measurements of the plurality of code modules (<NUM>, <NUM>, <NUM>, <NUM>, <NUM>) executed by the processor (<NUM>) during the boot process;
determine (<NUM>) that an initial state of the system (<NUM>) is equivalent to a predetermined state based on the retrieved quote (<NUM>), the predetermined state comprising the predetermined process being executed as an initial process (<NUM>) after completion of the boot process and before any subsequent processes for the computer system (<NUM>); and
receive (<NUM>) a package (<NUM>) comprising code or data or both to be processed by the system (<NUM>); and
cause the processor (<NUM>) to process the package (<NUM>) outside of the enclave (<NUM>).