Patent Description:
Network equipment and functions performed on such network equipment are increasingly delivered as (micro-)services that are implemented by software that runs on a generic hardware or virtualized hardware platform, using standard platform technologies.

So-called trusted execution environments, such as enclaves, offer the possibility to have services running in hardware owned by the licensee without the licensee being able to extract data from a trusted execution environment when the trusted execution environment is running or when the trusted execution environment is not running and saved for later restart.

But whereas in hardware based platforms there are mechanisms that enable control and/or limitation of the number of instances of a certain program to execute on the platform, any number of instances of an trusted execution environment comprising a (micro-)service might be started on the platform. Only practical limitations, such as memory size limitations, limit the number of concurrent instances of one and the same trusted execution environment.

Thus, since the trusted execution environments generally are started from the operating system which is under control of the licensee, the licensee is enabled to start multiple instances of one and the same trusted execution environment. Even if there is no direct way to make changes to the trusted execution environment state directly from the outside the trusted execution environment, the licensee may gain benefit from starting an additional instance of a trusted execution environment.

Hence, there is still a need for improved handling of instances of a trusted execution environment.

<CIT> relates to feature licensing in a secure processing environment.

<CIT> relates to trusted execution environment virtual machine cloning.

An object of embodiments herein is to provide efficient handling of instances of a trusted execution environment, that, for example, enables control of how many instances of the trusted execution environment are allowed to be running.

According to a first aspect there is presented a method for handling instances of a trusted execution environment on an execution platform. The trusted execution environment is associated with a secure cryptoprocessor. The secure cryptoprocessor holds a register. The trusted execution environment is configured to read from and write to the register at a given index i. The method is performed by the trusted execution environment. The method comprises checking, upon start of a new instance of the trusted execution environment, status of the register at the given index i, and wherein, when the register at the given index i has its status set to "undefined", an internal status value is set to a first value, and else, when a value is read from the register at the given index i, the internal status value is set to a second value based on the read value. The method comprises writing the internal status value to the register at the given index i. The method comprises running the new instance. The method comprises, whilst running the new instance, reading a current value from the register at the given index i. The method comprises enabling the new instance to keep running only when the current value equals the internal status value.

According to a second aspect there is presented a trusted execution environment for handling instances of the trusted execution environment on an execution platform. The trusted execution environment is associated with a secure cryptoprocessor. The secure cryptoprocessor holds a register. The trusted execution environment is configured to read from and write to the register at a given index i. The trusted execution environment comprises processing circuitry. The processing circuitry is configured to cause the trusted execution environment to check, upon start of a new instance of the trusted execution environment, status of the register at the given index i, and wherein, when the register at the given index i has its status set to "undefined", an internal status value is set to a first value, and else, when a value is read from the register at the given index i, the internal status value is set to a second value based on the read value. The processing circuitry is configured to cause the trusted execution environment to write the internal status value to the register at the given index i. The processing circuitry is configured to cause the trusted execution environment to run the new instance. The processing circuitry is configured to cause the trusted execution environment to, whilst the new instance is run, read a current value from the register at the given index i. The processing circuitry is configured to cause the trusted execution environment to enable the new instance to keep running only when the current value equals the internal status value.

According to a third aspect there is presented a computer program for handling instances of a trusted execution environment on an execution platform, the computer program comprising computer program code which, when run on the trusted execution environment, causes the trusted execution environment to perform a method according to the first aspect.

According to a fourth aspect there is presented a computer program product comprising a computer program according to the fourth aspect and a computer readable storage medium on which the computer program is stored. The computer readable storage medium could be a non-transitory computer readable storage medium.

Advantageously this provides efficient handling of instances of the trusted execution environment.

Advantageously this enables running of only one single instance of the trusted execution environment at a time.

<FIG> illustrates an execution platform <NUM> according to an embodiment. The execution platform <NUM> comprises a secure cryptoprocessor <NUM> and a trusted execution environment <NUM>. As will be further disclosed below, the secure cryptoprocessor <NUM> has a memory that holds a register <NUM>. According to an embodiment the secure cryptoprocessor <NUM> has a volatile storage, and the register <NUM> is kept at the volatile storage. This enables the content of the register to be rendered "undefined" upon rebooting or power down of the secure cryptoprocessor <NUM>. The register <NUM> might further have a non-volatile part for holding register status information.

There could be different examples of trusted execution environments <NUM>. According to an embodiment the trusted execution environment <NUM> is a base enclave (E0) of an enclave environment <NUM>. The term enclave as used herein could be regarded as short for hardware-mediated execution enclave. The enclave environment <NUM> might comprise several enclaves. Only a single enclave, denoted base enclave (E0), in the enclave environment might then be enabled to communicate with the secure cryptoprocessor <NUM>. There could be different examples of secure cryptoprocessor <NUM>. According to an embodiment the secure cryptoprocessor <NUM> is a trusted platform module (TPM).

The trusted execution environment <NUM> might generally be defined as an area of process space and memory within a system environment, such as an execution platform <NUM>, within a computer host which delivers confidentiality and integrity of instructions and data associated with that enclave. This trusted execution environment <NUM> is protected from eavesdropping, replay and alteration attacks as the programs within the enclave are executed. A trusted execution environment <NUM> is considered capable of executing processes, and executable code can be loaded into it. Various capabilities may be provided by such a trusted execution environment, but at minimum, the following might be enabled: the ability for executable software to be loaded into the trusted execution environment <NUM>, the ability for the host to attest to the integrity of the executable code prior to execution, and the ability to load data into the trusted execution environment <NUM>. The ability to execute software within the trusted execution environment <NUM> without other processes on the computer host being able to inspect, alter or replay the instructions or associated data. Note that these protections are not just against unprivileged processes, but also against the secure cryptoprocessor <NUM> and hypervisor processes which may be running at an escalated privilege level.

In general terms, secure cryptoprocessor <NUM> might be defined as a hardware cryptographic module that is enabled to securely store sensitive data and perform various cryptographic operations. Authentication (a process to prove the identity attribute of an entity, i.e. the secure cryptoprocessor <NUM> acting as the integrity reporting entity) and attestation (a process that enables the software integrity state to be reported and verified in order to determine its trustworthiness) are some steps that might be performed to ensure trusted computing. A secure cryptoprocessor <NUM> can authenticate itself using the credentials stored in shielded memory and provide integrity measurements reports to prove that software is trustworthy. The nature of the secure cryptoprocessor's <NUM> shielded memory ensures that information may be stored and protected from external software attacks. A variety of applications storing data and secrets protected by a secure cryptoprocessor <NUM> can be developed. These applications make it much harder to access information on a computing platform without proper authorization. If the software configuration of a platform has changed as a result of unauthorized activities, access to such data and secrets can be denied. Various secure cryptoprocessor specifications exist. Secure cryptoprocessors <NUM> can provide a hardware root of trust on a hosting service platform, and can be leveraged for operations such as measured boot and attestation.

Assume a secure cryptoprocessor <NUM> having a register, where the register at a given index i can hold a value "X". When the secure cryptoprocessor <NUM> is operational, the register is kept in the volatile storage of the secure cryptoprocessor <NUM>, such as in the RAM of the secure cryptoprocessor <NUM>, meaning that its contents is lost when power goes down or when a reboot occurs. After a reboot the value of the register becomes "undefined", but the allocation of the register and attached properties survive the power cycles of the platform, including the power cycle of the secure cryptoprocessor <NUM>.

Assume further that the trusted execution environment <NUM> has the capability to recognize when the value of the register at the given index i is "undefined" or "defined", and in the latter case the trusted execution environment <NUM> can read the current value "X" of the register at the given index i.

When the register is allocated in the secure cryptoprocessor <NUM> during a bootstrapping and/or migration process, then the trusted execution environment <NUM> in some aspects is configured to internally generate a random authorization key, denoted K, which is then attached to the security properties of the register at the given index i in the secure cryptoprocessor <NUM>. Alternatively, the secure cryptoprocessor <NUM> might be configured to internally generate the authorization key K and then share it with the trusted execution environment <NUM> in a secure manner. This is one wayThese are two ways to guarantee that only the correct trusted execution environment <NUM> can read and write to the register at the given index i.

In case of TPM <NUM> (i.e., TPM revision version <NUM>), the bootstrapping process implies that the trusted execution environment <NUM> should allocate space in a memory holding the register at the given index i with the following flags:
Setting the TPMA_NV_ORDERLY flag implies that a non-volatile part of the memory will be written to only if a normal shutdown process is performed in secure cryptoprocessor <NUM>, and it will not be written to when the register at the given index i is actually written or in case execution of the secure cryptoprocessor <NUM> crashes. This prevents wear-out of the memory holding the register.

Setting the TPMA_NV_CLEAR_STCLEAR flag makes the register at the given index i be set to "undefined" after the secure cryptoprocessor <NUM> is rebooted, which means that even in normal shutdown there will be no writes to the register at all, but rather a volatile status flag will be flushed to "undefined" state.

Setting the TPMA_NV_AUTHREAD flag or TPMA_NV_AUTHWRITE flag dictates that the register may be written to or be read from only when the authorization key K is known to the writing entity, such as the trusted execution environment <NUM>, using an HMAC SESSION. This prevents other unauthorized entities to modify the register at the given index i or even to read its content.

Setting the TPMA_NV_POLICYREAD flag or the TPMA_NV_POLICYWRITE flag makes it possible to use a POLICY SESSION, where, if the AuthPolicy type is added, requires the user to know the authorization key K. However, other policy branches may be added for, e.g., an acute situation that may allow a third party entity to assist externally predefined situations.

The above mentioned flags are examples of register status information that might be held in the non-volatile part of the register <NUM>.

Allocation of the memory space for the register at the given index i requires the knowledge of the owner authorization of the secure cryptoprocessor <NUM>, and this authorization is assumed to be known to the trusted execution environment <NUM> (and, optionally, known to the public usage of the secure cryptoprocessor <NUM>). In other aspects the entity that performs a remote bootstrapping may know the owner authorization and may thus perform the allocation of the memory space remotely, using the trusted execution environment <NUM> as a communication proxy to the secure cryptoprocessor <NUM>.

When allocating the memory space for the register at the given index i the authorization key K and (optionally) the policy digest are attached to the register at the given index i. Those properties are thereby persistent and can survive power cycles of the secure cryptoprocessor <NUM>.

With the above flags (ORDERLY and STCLEAR), the allocated memory space in the secure cryptoprocessor <NUM> will never be written, and becomes "undefined" after the reboot of the secure cryptoprocessor <NUM>.

The authorization key K might be checked in an HMAC or POLICY session by the secure cryptoprocessor <NUM> when memory space is written to or being read from. However, checking whether the content of the register at the given index i is "defined" or "undefined" might not require the knowledge of the authorization key K. Therefore, an additional check of the authorization key K can be made when the content of the register at the given index i is updated. In other aspects a check of the authorization key K is mandatory when updating the content of the register at the given index i.

The failure to read from or write to the memory space could imply that (i) the trusted execution environment <NUM> is trying to use a wrong authorization key K (i.e., wrong trusted execution environment <NUM>), that (ii) the secure cryptoprocessor <NUM> does not know the private portion of the encryption key corresponding to the public portion of the encryption key (such as a Storage Root Key) that is known to the trusted execution environment <NUM> and used for derivation of a secure session key (i.e., wrong secure cryptoprocessor <NUM>), that (iii) the memory space as been redefined by another entity (i.e., memory space security settings are re-defined), that (iv) the memory space was removed by another entity (e.g. during a Denial of Service attack), or that (v) bootstrapping of the secure cryptoprocessor <NUM> has not been performed.

The embodiments disclosed herein relate to mechanisms for handling instances of the trusted execution environment <NUM> on an execution platform <NUM>. In order to obtain such mechanisms there is provided a trusted execution environment <NUM>, a method performed by the trusted execution environment <NUM>, a computer program product comprising code, for example in the form of a computer program, that when run on a trusted execution environment <NUM>, causes the trusted execution environment <NUM> to perform the method.

<FIG> is a flowchart illustrating embodiments of methods for handling instances of the trusted execution environment <NUM> on an execution platform <NUM>. The methods are performed by the trusted execution environment <NUM>. The methods are advantageously provided as computer programs <NUM>.

The trusted execution environment <NUM> is associated with a secure cryptoprocessor <NUM>. The secure cryptoprocessor <NUM> holds a register <NUM>. The trusted execution environment <NUM> is configured to read from and write to the register <NUM> at a given index i. Parallel reference is made to <FIG> illustrating the interaction between the trusted execution environment <NUM> and the secure cryptoprocessor <NUM>. It is in the illustrative examples of <FIG> illustrated that the register <NUM> has a state and that the trusted execution environment <NUM> holds an authorization key K that is checked by an access check module at the secure cryptoprocessor <NUM> in order for the trusted execution environment <NUM> to be able to read from and write to the register <NUM> at the given index i.

When a new instance of the trusted execution environment <NUM> is started, the trusted execution environment <NUM> checks the status of the register <NUM> at the given index i. Hence, the trusted execution environment <NUM> is configured to perform step S102:
S102: The trusted execution environment <NUM> checks, upon start of a new instance of the trusted execution environment <NUM>, status of the register <NUM> at the given index i. When the register <NUM> at the given index i has its status set to "undefined", an internal status value (denoted "v") is set to a first value. Else, when a value (denoted "X") is read from the register <NUM> at the given index i (and thus the register <NUM> at the given index i has its status set to "defined"), the internal status value is set to a second value, where the second value is based on the read value. The internal value might be kept in the trusted execution environment <NUM>. For example the first value might be <NUM> and thus v is set to v=<NUM> when the register <NUM> at the given index i has its status set to "undefined".

The trusted execution environment <NUM> then writes to the register <NUM> at the given index i the value v. Hence, the trusted execution environment <NUM> is configured to perform step S104:
S104: The trusted execution environment <NUM> writes the internal status value to the register <NUM> at the given index i. That is, X is set to X=v.

The instance of the trusted execution environment <NUM> is then run. Particularly, the trusted execution environment <NUM> is configured to perform step S106:
S106: The trusted execution environment <NUM> runs the new instance.

The trusted execution environment <NUM> then, whilst running the new instance, occasionally reads a current value from the register <NUM> at the given index i. Hence, the trusted execution environment <NUM> is configured to perform step S108:
S108: The trusted execution environment <NUM>, whilst running the new instance, reads a current value from the register <NUM> at the given index i.

It is then checked by the trusted execution environment <NUM> that the current value as read in step S108 is identical to the value that was written to the same register <NUM> at the same given index i in step S104. Particularly, the trusted execution environment <NUM> is configured to perform step S110:
S110: The trusted execution environment <NUM> enables the new instance to keep running only when the current value equals the internal status value.

Thus, if the read current value is not the same as the written value then any further operation of the trusted execution environment <NUM> is stopped or blocked.

Thereby, only the latest started instance of the trusted execution environment <NUM> will survive and execute; the execution of all previous instances will eventually stop. In case the trusted execution environment <NUM> crashes then starting a new instance will be permitted without a need to reboot the whole execution platform <NUM>. In case the execution platform <NUM> crashes then all instances of the trusted execution environment <NUM> will be terminated and the register <NUM> of the secure cryptoprocessor <NUM> becomes "undefined".

Embodiments relating to further details of handling instances of the trusted execution environment <NUM> on an execution platform <NUM> as performed by the trusted execution environment <NUM> will now be disclosed.

There may be different ways to base the second value on the read value. For example, the second value could be a function of the read value, where the function specifies that the second value is equal to the read value as added by a constant, as subtracted by a constant, or be selected according to any specified ordered sequence of values. According to an embodiment the second value equals the read value increased by one unit.

In some aspects the interval value is kept in a volatile storage of the trusted execution environment <NUM> and will thus only live during the lifetime of the instance and will never be loaded from outside the trusted execution environment <NUM>. Hence, according to an embodiment the internal status value is reset upon start of the new instance.

There could be different ways for the trusted execution environment <NUM> to act if the status of the register <NUM> at the given index i is "defined" and the trusted execution environment <NUM> fails to read any value from the register <NUM> at the given index i in step S102. In some aspects any further operation by the instance of the trusted execution environment <NUM> is stopped or blocked. That is, according to an embodiment the new instance is prevented from keep running when not being authorized to read the value from the register (<NUM>) at the given index i.

There could be different ways for the trusted execution environment <NUM> to act if writing to the register <NUM> at the given index i in step S104 fails. In some aspects any further operation by the instance of the trusted execution environment <NUM> is stopped or blocked. That is, according to an embodiment the new instance is prevented from keep running when unable to write the second value to the register (<NUM>) at the given index i.

There could be different ways for the trusted execution environment <NUM> to be configured with regards to when, or how often, in time to read the current value from the register <NUM> at the given index i in step S108. In some aspects the trusted execution environment <NUM> is configured to read the current value timely (for example, once every minute, once every <NUM> seconds, etc.), or before specific functionality is called by a host application run on the trusted execution environment <NUM> or by a user of the trusted execution environment <NUM>. That is, according to an embodiment when the current value is read is either time-driven or event-driven.

There could be different ways for the trusted execution environment <NUM> to act if the trusted execution environment <NUM> fails to read any value from the register <NUM> at the given index i in step S108. In some aspects any further operation by the instance of the trusted execution environment <NUM> is stopped or blocked. That is, according to an embodiment the new instance is prevented from keep running when not being authorized to read the current value from the register <NUM> at the given index i.

As disclosed above, in some aspects the trusted execution environment <NUM> has access to an authorization key K. According to an embodiment, reading from and writing to the register <NUM> at the given index i is then only possible upon the authorization key K being checked by the secure cryptoprocessor <NUM>. As will be further disclosed below, the authorization key K might be checked in an HMAC session or a POLICY session. The authorization key K might be random-valued and generated internally by the trusted execution environment <NUM>.

In some aspects a secure session is created between the trusted execution environment <NUM> and the secure cryptoprocessor <NUM> so that information can be shared between them with integrity protection and privacy protection. Thus, according to an embodiment a secure session is established between the trusted execution environment <NUM> and the secure cryptoprocessor <NUM> in conjunction with starting the new instance of the trusted execution environment <NUM>.

In some aspects it is assumed that after bootstrapping (see below) the trusted execution environment <NUM> knows a public key associated with the secure cryptoprocessor <NUM> for which the secure cryptoprocessor <NUM> holds the corresponding private key. Hence, according to an embodiment the trusted execution environment <NUM> is provided information about the given index i during bootstrapping of the trusted execution environment <NUM>. A secure session can then be established, e.g. by using a random salt value, generated on the trusted execution environment side and encrypted by the public key of the secure cryptoprocessor <NUM>, such that only the correct secure cryptoprocessor <NUM> can decrypt the salt and derive the session key to, which is to be used during the secure session, out of it.

In some aspects, while deriving the session key both the trusted execution environment <NUM> and the secure cryptoprocessor <NUM> may use randomly generated nonces. In this way the trusted execution environment <NUM> and the secure cryptoprocessor <NUM> can mitigate replay attacks as well.

The above way to establish the secure session ensures that the trusted execution environment <NUM> is communicating with the correct secure cryptoprocessor <NUM>.

In some aspects it is assumed that after bootstrapping the trusted execution environment <NUM> also knows a secret (as defined by the authorization key K) that enables the trusted execution environment <NUM> to access certain registers of the secure cryptoprocessor <NUM> (such as the register at the given index i).

An illustrative example for establishing the secure session in case of using TPM <NUM> will now be provided.

Step <NUM>: The trusted execution environment <NUM> has access to the correct public portion of the Storage Root Key (SRK) of the correct secure cryptoprocessor <NUM>.

Step <NUM>: The trusted execution environment <NUM> obtains initial connectivity to the secure cryptoprocessor <NUM>. The initial connectivity is provided by, e.g., a host OS, a host application, BIOS, or by other means.

Step <NUM>: The trusted execution environment <NUM> starts a new SESSION where the proof of possession of the secure cryptoprocessor <NUM> is inherited as will be disclosed next.

The trusted execution environment <NUM> generates a random salt and encrypts it by using the public portion of key in the secure cryptoprocessor <NUM> (e.g. the SRK). Thereby only the correct secure cryptoprocessor <NUM> is enabled to decrypt the salt and then derive the SESSION key. In this way the trusted execution environment <NUM> and the secure cryptoprocessor <NUM> establish a secure session where the trusted execution environment <NUM> is ensured to communicate with the correct secure cryptoprocessor <NUM>, albeit via an untrusted channel.

The secure session depends on nonces from the trusted execution environment <NUM> and the secure cryptoprocessor <NUM>. These nonces are randomly and independently selected by the trusted execution environment <NUM> and the secure cryptoprocessor <NUM>. This prevents a replay attack.

The secure session can be either a HMAC session or a POLICY session (in terms of TPM <NUM>).

In case an HMAC session or POLICY session is requested by the trusted execution environment <NUM>, the trusted execution environment <NUM> uses the pre-defined authorization key K when access resources of the secure cryptoprocessor <NUM> (e.g. NVRAM area), thus enabling mutual checks between the secure cryptoprocessor <NUM> and the trusted execution environment <NUM>.

In case a POLICY session is requested by the trusted execution environment <NUM>, then an External Authority might be configured to restore/repair the secure session.

Step <NUM>: The trusted execution environment <NUM> and the secure cryptoprocessor <NUM> each derives the SESSION key on their sides. The subsequent traffic between the secure session during the secure session is then encrypted with the SESSION key.

Step <NUM>: The secure session is closed after the trusted execution environment <NUM> completes the needed TPM commands.

In case an HMAC session is ongoing the trusted execution environment <NUM> can perform a number of TPM commands using the same session instance.

In case a POLICY session is ongoing the trusted execution environment <NUM> closes the secure session after the policy has been used for a single TPM command.

If using a platform where the trusted execution environment <NUM> can have direct integrity and privacy protected communication with the secure cryptoprocessor <NUM>, no proof of possession of the secure cryptoprocessor <NUM> is needed and then the SRK does not need to be used. Instead the communication is automatically secured through the platform architecture. HMAC or POLICY types of sessions can still be used by the trusted execution environment <NUM> to proof its knowledge of the authorization key K in order for the trusted execution environment <NUM> to be authorized to perform actions on a resource (such as memory space) of a certain secure cryptoprocessor <NUM>.

The trusted execution environment <NUM> might have a local secure storage in a form of an encrypted file that can only be decrypted by that trusted execution environment <NUM>. Intel SGX provides an operation called for "sealing" and any data may be sealed to that certain trusted execution environment <NUM>. If there is no local storage then a remote entity may provide the decryption key for the unseal operation.

Particularly, according to an embodiment the trusted execution environment <NUM> has access to encrypted and integrity-protected data, the data representing at least one of: information about the given index i, the authorization key K for reading from and writing to the register <NUM> at the given index i, and a public key of the secure cryptoprocessor <NUM>. The sealed data that the trusted execution environment <NUM> stores might thus comprise any of the following information: (i) the register identifier of the secure cryptoprocessor <NUM> (e.g., the value of the given index i), (ii) the authorization key K, and (iii) the public key of the secure cryptoprocessor <NUM> for establishing the secure session. The latter is only needed in case the channel between trusted execution environment <NUM> and secure cryptoprocessor <NUM> is not trusted. The sealed data might be stored as a sealed blob. When the sealed blob is not found, then a bootstrapping process might be performed, where the above information should be provisioned, derived, or generated in a trustworthy way. Otherwise, the running instance of the trusted execution environment <NUM> instance should freeze its operation or terminate.

In general terms, migration of the trusted execution environment <NUM> to another platform implies that there will be a new secure cryptoprocessor <NUM> at the destination platform. The information in the sealed blob then needs to be re-created, and, therefore, this process may be described as a bootstrapping process, except that the register at the source platform needs to be released and a new register at the destination secure cryptoprocessor <NUM> with, perhaps, a new given index i, will be allocated. That is, according to an embodiment new values of the data are generated upon migration of the trusted execution environment <NUM> to another execution platform <NUM>.

Depending on the scenario, the bootstrapping in general should be performed by a trusted launch authority (TLA) which could be the owner of the trusted execution environment <NUM>, a third-party entity that the trusted execution environment <NUM> owner trusts. Alternatively, the source trusted execution environment <NUM> itself could serve as TLA with respect to the destination trusted execution environment <NUM>.

The TLA might be configured to perform a remote attestation of the destination platform, the destination "empty" trusted execution environment <NUM> and, optionally, attest the public key of the secure cryptoprocessor <NUM> (such as the public portion of SRK in case of TPM), that exists only in that certain secure cryptoprocessor <NUM>.

The TLA might be configured to check the trustworthiness of that public key by using an attestation process, or by verifying the corresponding chain of certificates, or by other means. Afterwards, the TLA delivers the trusted public portion of the key of the secure cryptoprocessor <NUM> to the trusted execution environment <NUM>, which is then used by the trusted execution environment <NUM> to establish a secure channel to the secure cryptoprocessor <NUM>.

The TLA or the trusted execution environment <NUM> might be configured to then establish a secure channel to the secure cryptoprocessor <NUM> in order to perform the remaining parts of bootstrapping actions. The TLA or the trusted execution environment <NUM> might be configured to internally generate the authorization key K, and a new register at the given index is then allocated, where the authorization key K and, optionally, an agreed policy are attached to the given index i. The given index i itself may be a fixed value, or it can be dynamically allocated by the secure cryptoprocessor <NUM>.

The trusted execution environment <NUM> might seal the new data into a file and then perform a normal start procedure as of described above.

Other steps that might be performed during the bootstrapping procedure are left so as to not obscure the present disclosure.

If the SRK is not already created in the secure cryptoprocessor <NUM>, it can be created when needed in an "on-demand" fashion as a primary key with well-defined set of parameters. Also, the SRK may be made persistent in secure cryptoprocessor <NUM> such that it does not have to be created every time a secure channel needs to be established.

When the trusted execution environment <NUM> (or an external entity) receives the SRK public key, its certificate might be checked, to ensure that the SRK public key comes from a trusted secure cryptoprocessor <NUM>. This can be achieved in several ways.

According to a first example, the trusted execution environment <NUM> only knows the constant signing public key of the manufacturer of the secure cryptoprocessor <NUM> and checks the signature of the SRK public key.

According to a second example, the SRK could be verified through quoting/attestation using an endorsement key (EK) or other attestation key from the secure cryptoprocessor <NUM>, whose trustworthiness can be checked by the endorsement, i.e., EK certificate which was signed by the manufacturer of the secure cryptoprocessor <NUM> carrying the public keys of EK.

After the trusted execution environment <NUM> accepted the SRK, and stores the SRK public key, the trusted execution environment <NUM> can thereafter create secure sessions, for start/stop operations as well as to allocate and deallocate the given index i.

<FIG> schematically illustrates, in terms of a number of functional units, the components of a trusted execution environment <NUM> according to an embodiment. Processing circuitry <NUM> is provided using any combination of one or more of a suitable central processing unit (CPU), multiprocessor, microcontroller, digital signal processor (DSP), etc., capable of executing software instructions stored in a computer program product <NUM> (as in <FIG>), e.g. in the form of a storage medium <NUM>. The processing circuitry <NUM> may further be provided as at least one application specific integrated circuit (ASIC), or field programmable gate array (FPGA).

Particularly, the processing circuitry <NUM> is configured to cause the trusted execution environment <NUM> to perform a set of operations, or steps, as disclosed above. For example, the storage medium <NUM> may store the set of operations, and the processing circuitry <NUM> may be configured to retrieve the set of operations from the storage medium <NUM> to cause the trusted execution environment <NUM> to perform the set of operations.

Thus the processing circuitry <NUM> is thereby arranged to execute methods as herein disclosed. The trusted execution environment <NUM> may further comprise a communications interface <NUM> at least configured for communications with other entities, nodes, functions, and devices, such as the secure cryptoprocessor <NUM>. As such the communications interface <NUM> may comprise one or more transmitters and receivers, comprising analogue and digital components. The processing circuitry <NUM> controls the general operation of the trusted execution environment <NUM> e.g. by sending data and control signals to the communications interface <NUM> and the storage medium <NUM>, by receiving data and reports from the communications interface <NUM>, and by retrieving data and instructions from the storage medium <NUM>. Other components, as well as the related functionality, of the trusted execution environment <NUM> are omitted in order not to obscure the concepts presented herein.

<FIG> schematically illustrates, in terms of a number of functional modules, the components of a trusted execution environment <NUM> according to an embodiment. The trusted execution environment <NUM> of <FIG> comprises a number of functional modules; a status check module 210a configured to perform step S102, a write module 210b configured to perform step S104, a run module 210c configured to perform step S208, a read module 210d configured to perform step S108, and an enable running module 210e configured to perform step S110. The trusted execution environment <NUM> of <FIG> may further comprise a number of optional functional modules (not shown). In general terms, each functional module 210a-210e may in one embodiment be implemented only in hardware and in another embodiment with the help of software, i.e., the latter embodiment having computer program instructions stored on the storage medium <NUM> which when run on the processing circuitry makes the trusted execution environment <NUM> perform the corresponding steps mentioned above in conjunction with <FIG>. It should also be mentioned that even though the modules correspond to parts of a computer program, they do not need to be separate modules therein, but the way in which they are implemented in software is dependent on the programming language used. Preferably, one or more or all functional modules 210a-210e may be implemented by the processing circuitry <NUM>, possibly in cooperation with the communications interface <NUM> and/or the storage medium <NUM>. The processing circuitry <NUM> may thus be configured to from the storage medium <NUM> fetch instructions as provided by a functional module 210a-210e and to execute these instructions, thereby performing any steps as disclosed herein.

Claim 1:
A method for handling instances of a trusted execution environment (<NUM>) on an execution platform (<NUM>), the trusted execution environment (<NUM>) being associated with a secure cryptoprocessor (<NUM>), wherein the secure cryptoprocessor (<NUM>) holds a register (<NUM>), and wherein the trusted execution environment (<NUM>) is configured to read from and write to the register (<NUM>) at a given index i, the method being performed by the trusted execution environment (<NUM>), the method comprising:
checking (S102), upon start of a new instance of the trusted execution environment (<NUM>), status of the register (<NUM>) at the given index i, and wherein, when the register (<NUM>) at the given index i has its status set to "undefined", an internal status value is set to a first value, and else, when a value is read from the register (<NUM>) at the given index i, the internal status value is set to a second value based on the read value;
writing (S104) the internal status value to the register (<NUM>) at the given index i;
running (S106) the new instance, and whilst doing so:
reading (S108) a current value from the register (<NUM>) at the given index i; and
enabling (S110) the new instance to keep running only when the current value equals the internal status value.