Secure computing environment using blockchain

Abstract

A computer-implemented method of using a computing environment of a computing resource, wherein a blockchain comprises a first blockchain transaction comprising an encryption key, and wherein the method comprises: obtaining the encryption key from the first blockchain transaction; using the encryption key to encrypt data; arranging for a second blockchain transaction to be submitted to one or more nodes of a blockchain network, wherein the second blockchain transaction comprises a commitment of the encrypted data; and supplying the encrypted data to the computing resource for use by the computing environment.

Description

[0001] SECURE COMPUTING ENVIRONMENT USING BLOCKCHAIN

[0002] TECHNICAL FIELD

[0003] The present disclosure relates to methods for establishing and using secure computing environments using a blockchain.

[0004] BACKGROUND

[0005] Enclaves allow users to securely work on their confidential data by isolating sensitive code and data from the rest of the system. Depending on the specific situation and trusted computing base (TCB), enclaves can prevent unauthorized access from the host operating system, the hypervisor, or other applications. Different enclaves running in the same environment can work independently on targeted tasks, exposing sensitive data only to authorized parties. Enclaves can communicate with each other on sensitive data without exposing the data to unauthorized observers.

[0006] A virtual machine (VM) is the virtualization or emulation of a computer operating system (OS). VMs are based on computer architectures and provide the functionality of a physical computer. Their implementations may involve specialized hardware, software, or a combination of the two. System VMs (also called full virtualization VMs) are isolated systems that run and exist on the same machine. They provide a substitute for a real machine and the functionality needed to execute entire operating systems. System VMs are managed by a hypervisor, a combination of computer software, firmware and hardware that coordinates them. It is possible to have lightweight versions of VM that are not managed by the hypervisor, but from the operating system. These VMs only emulate a real machine rather than create a substitute.

[0007] Computers provide different levels of access to resources. This hierarchical structure is arranged from most privileged (most trusted, with lower numbers) to least privileged (least trusted, with higher numbers), and is called A protection ring. Traditionally, the operating system (OS) in kernel mode had the highest privileges. However, to accommodate the introduction of virtual machines (VM) the creation of additional rings was required. A description of the different rings can be found in the Appendix (section 4). The trusted computing base (TCB) is the set of trusted hardware and software in a computing system that provides a secure environment for operations. Being trusted does not mean being trustworthy (bugs are possible inside a TCB), but that it is trusted to execute instructions faithfully. The TCB is meant to distinguish two subsets in the computing base, the one that is supposedly trustworthy and the one that is known to be untrustworthy and against which the system presents layers of defences.

[0008] Bugs and vulnerabilities in the TCB can be critical for security, for this reason, ideally, the TCB should be as limited as possible. Business models (such as usage of cloud computing) and security requirements determines what is included in a TCB. Examples of TCB may be as limited as an application that runs in an isolated region of the processor.

[0009] In some situations, not even all the hardware level in a machine is trusted. For instance, the communication between processor and main memory may not be considered secure (it is susceptible to cheap eavesdropping attacks).

[0010] The fundamental hardware component that is considered secure is the processor. The idea being that while it is theoretically possible to falsify processors, this process has such high economic cost that it is essentially economically infeasible.

[0011] A trusted execution environment (TEE) is a secure area of a main processor highly separated from everything else that provides minimal TCB. In other words, the TEE is isolated from the host operating system and other applications running on the system. The code and the data loaded in the TEE are guaranteed to maintain high integrity and confidentiality standards. Unauthorized entities from outside the TEE cannot alter the data stored in it nor the code executed there.

[0012] The main challenge the TEE faces is that while the environment is secure, information on its internal state is dispersed all over the system, including untrusted software and hardware. To overcome this, data are written in memory in encrypted form. The decryption key is stored inside the core of the TEE and is not accessible from the outside. Integrity of the data is ensured using cryptographic hashes: whenever data is saved, the hash is securely stored; this prevents the TEE from using manipulated data.

[0013] SUMMARY

[0014] According to one aspect disclosed herein, there is provided a computer-implemented method of using a computing environment of a computing resource, wherein a blockchain comprises a first blockchain transaction comprising an encryption key, and wherein the method comprises: obtaining the encryption key from the first blockchain transaction; using the encryption key to encrypt data; arranging for a second blockchain transaction to be submitted to one or more nodes of a blockchain network, wherein the second blockchain transaction comprises a commitment of the encrypted data; and supplying the encrypted data to the computing resource for use by the computing environment.

[0015] According to another aspect disclosed herein, there is provided a computer-implemented method of operating a computing environment of a computing resource, wherein a blockchain comprises a first blockchain transaction comprising an encryption key, wherein the computing resource has stored thereon a decryption key corresponding to the encryption key, and wherein the method comprises: receiving encrypted data as an input from a user of the computing resource; obtaining, from a second blockchain transaction, a commitment of the encrypted data; generating a candidate commitment of the encrypted data, verifying that the candidate commitment corresponds to the obtained commitment; and decrypting the encrypted data using the decryption key when the candidate commitment of the encrypted data corresponds to the obtained commitment.

[0016] Some embodiments of the present disclosure provide techniques to initialize secure enclaves that accepts (e.g. loads, runs, executes, stores, etc.) only authorized / approved data (e.g. files, applications, operating system, virtual machines, etc.). Data deployed on an enclave is loaded in encrypted form, with decryption possible only by the chosen device at the hardware level. Blockchain transactions provide integrity of the imported data. This is as an additional security layer that relies only on the hardware (e.g. processor) being trusted. When data is deployed in the enclave, data access control is achieved by combining hardware-level and blockchain-based techniques. Data may be encrypted twice: first using keys owned by the user, and then using keys controlled by the device (e.g. processor). Userside data access control may be implemented using blockchain transactions for the decryption process.

[0017] Some embodiments provide for the creation of secure enclaves in machine that run a trusted operating system or hypervisor.

[0018] Some embodiments of the present disclosure provide for the secure retrieval and distribution of a virtual machine, whereby the integrity of the virtual machine can be guaranteed by making use of a blockchain. Some embodiments provide for the establishment of secure communication channels for transferring data between enclaves.

[0019] BRIEF DESCRIPTION OF THE DRAWINGS

[0020] To assist understanding of embodiments of the present disclosure and to show how such embodiments may be put into effect, reference is made, by way of example only, to the accompanying drawings in which:

[0021] Figure 1 is a schematic block diagram of a system for implementing a blockchain,

[0022] Figure 2 schematically illustrates some examples of transactions which may be recorded in a blockchain,

[0023] Figure 3 is a sequence diagram showing an example interaction between actors under an asymmetric scheme for initializing a secure enclave,

[0024] Figure 4 is a sequence diagram showing an example interaction between actors under a symmetric scheme for initializing a secure enclave,

[0025] Figure 5 schematically illustrates an overview of the importing of data to a virtual machine, Figure 6 also schematically illustrates an overview of the importing of data to a virtual machine, and

[0026] Figure 7 is a sequence diagram showing an example interaction between enclaves for secure communication between said enclaves.

[0027] DETAILED DESCRIPTION OF EMBODIMENTS

[0028] 1. SECURE COMPUTING

[0029] Some embodiments of the present disclosure make use of a blockchain 150 to ensure the integrity and security of a virtual machine. The blockchain 150 may also be used to distribute and retrieve (e.g. download) the virtual machine. A first party (e.g. Alice 103a) is configured to obtain (e.g. create or receive) a virtual machine, i.e. a virtualization or emulation of a computer system. The virtual machine (i.e. the code, software or files representing the virtual machine) may include an operating system, one or more applications (e.g. an image processing application, a word processing application, an encryption application) running on the virtual machine, and / or one or more data files (e.g. documents, images, videos, etc.). The virtual machine may also include an encryption key or keys for encrypting data to be exported from the virtual machine, and / or a decryption key or keys for decrypting data imported to (e.g. downloaded to) the virtual machine.

[0030] Alice 103a generates a hash value based on at least the virtual machine. That is, Alice 103a inputs the representation of the virtual machine into a hash function, such as SHA256, to generate the hash value. The hash value may also be based on additional information, such as a secret value, a nonce value, an identifier of Alice 103a, an identifier of an intended recipient of the virtual machine (e.g. Bob 103b), etc.

[0031] Alice 103a generates a first blockchain transaction that contains the hash value. The transaction may also include a link / reference to a storage location where the virtual machine can be retrieved from, e.g. a web page, a cloud storage location, etc. The storage location may be publicly accessible or private. For the latter, the storage location may have a layer of access control, such as password protection. The link may be, for example, a URL. The virtual machine may be provided to the recipient directly, e.g. on a computer-readable storage medium such as a USB stick.

[0032] The virtual machine may be stored and / or provided in encrypted form. That is, Alice 103a may encrypt the virtual machine before storing the encrypted version at the storage location. In some examples, the hash value may be generated based on the encrypted version of the virtual machine, rather that the plaintext value. In these examples, the intended recipient of the virtual machine requires the corresponding decryption key. As a specific example, the encryption key may be a public key and the intended recipient may have the corresponding private key. Or, the encryption key may be a (symmetric) encryption key which is securely communicated to the intended recipient.

[0033] Alice 103a is configured to submit the first blockchain transaction to the blockchain network 106, or to an intermediary for transmission to the blockchain network 106.

[0034] A second party (e.g. Bob 103b) is configured to obtain the first blockchain transaction, e.g. from a blockchain node 104. Bob 103b may extract and use the link / reference to obtain (e.g. download) the virtual machine or the encrypted version thereof. Alternatively, Bob 103b may obtain the virtual machine directly from Alice 103a or from an alternative source without having to use the link / reference. Bob 103b verifies that the (encrypted) virtual machine hashes to the hash value stored in the first blockchain transaction. That is, Bob 103b inputs the (encrypted) virtual machine to a hash function and verifies that the resulting hash value matches the hash value stored in the first blockchain transaction. If so, Bob 103b loads and uses the virtual machine. Bob 103b may first decrypt the virtual machine if it is stored in encrypted form. E.g. Bob 103b may use his private key to decrypt the virtual machine, or a decryption key received from Alice 103a.

[0035] Verifying that the virtual machine hashes to the hash value ensures that Bob 103b only runs the exact copy of the virtual machine that was created by Alice 103a. This ensures that the virtual machine obtained by Bob 103b has not been tampered with or otherwise corrupted, thus maintaining the security of the computing resource on which Bob 103b executes the virtual machine. Alice 103a may generate a second blockchain transaction that references the first blockchain transaction. The second blockchain transaction may include a hash value generated based on an updated version of the virtual machine, and a link / reference to the updated virtual machine. As before, the hash value may be based on an encrypted version of the updated virtual machine. Similarly, Alice 103a may store the encrypted version at the storage location. Alice 103a submits the second blockchain transaction to the blockchain network 106. Alice 103a may update the virtual machine by updating the operating system, one or more of the applications, and / or one or more of the files stored on the virtual machine. In some examples, Alice 103a may update (e.g. add or remove) one or more of the encryption and / or decryption keys stored on the virtual machine.

[0036] In some examples, the hash value and link / reference may be stored in an output of the first blockchain transaction. The output may be locked to a public key of which Alice 103a controls the corresponding private key. The second blockchain transaction may comprise an input that refences the output of the first blockchain transaction and includes a signature generated using Alice's private key. The output of the first blockchain transaction may require the input of the second blockchain transaction to contain multiple (e.g. a threshold number) of signatures. For instance, the output may be a multi-signature output. This means that multiple parties are required to collaborate to update the virtual machine. In some examples, the output of the second blockchain transaction (containing the updated hash value and link / reference to the updated machine) may be locked to a different threshold of public keys. The output of the first blockchain transaction may be locked to a public key of which multiple parties have respective shares of the private key. The multiple parties may be required to generate a threshold signature in order to unlock the output.

[0037] Bob 103b may export data from his virtual machine to a second, different virtual machine, e.g. a virtual machine operated by a different party on a different computing resource, or a different virtual machine operated by Bob 103b on a different computing resource or even the same computing resource. Each virtual machine may be a separate workspace, e.g. used by employees of a company. The blockchain 150 may comprise a third blockchain transaction that includes a public key associated with the second virtual machine. Bob 103b may use the public key to encrypt data stored on the first virtual machine, and then send the encrypted data to the second virtual machine. If both virtual machines are operating on the same computing resource, sending the encrypted data may involve storing the encrypted data on a processor of the computing resource accessible by both virtual machines.

[0038] Bob 103b may sign the encrypted data before sending it to the second virtual machine. Bob 103b may sign the encrypted data using a private key corresponding to a public key stored in the first blockchain transaction.

[0039] Similarly, Bob 103b may receive encrypted data from the second virtual machine which has been encrypted using a public key associated with the first virtual machine, e.g. the public key stored in the first blockchain transaction.

[0040] The above-described methods for securely communicating between virtual machines may be used for virtual machines that have been obtained in any way, and not just having been downloaded using a link / reference in a blockchain transaction, as described above.

[0041] The following embodiments may be used separately from or in combination with the embodiments described above. These embodiments enable the initialisation and use of a secure computing environment (also referred to as a secure enclave) using the blockchain 150.

[0042] A computing resource (e.g. a desktop computer, laptop, tablet, etc.) has stored thereon a computing environment, e.g. a virtual machine, such as a virtual machine downloaded according to the embodiments described above. The computing resource may take any suitable form, such as the computing equipment 102 described below.

[0043] The computing resource also has stored thereon a decryption key. The decryption key may be stored on a processor of the computing resource. The decryption key may be stored on the processor by a trusted party, e.g. the processor manufacturer. An encryption key corresponding to the decryption key may be stored in a blockchain transaction on the blockchain 150. The blockchain transaction may be created by a manufacturer of the computing resource and / or the processor of the computing resource.

[0044] Rather than being stored as a key per se, the computing resource may comprise hardware (e.g. a circuit) that corresponds to the key, i.e. the hardware performs the decryption. For example, multiplication by 2 is bitwise shift. Say that the decryption is done by multiplying by two, instead of saving 2 as the key, there may be a circuit that performs a bitwise shift.

[0045] When using the secure computing environment, a user (e.g. Alice 103a) obtains the encryption key from the blockchain transaction, and uses the encryption key to encrypt data to be used by the secure computing environment. The data may include an operating system to be used by the secure computing environment, and / or one or more applications to be ran on the secure computing environment, and / or one or more files to be loaded by the secure computing environment.

[0046] Alice 103a submits a blockchain transaction to the blockchain 150 that contains a commitment (e.g. a hash) of the encrypted data, and supplies (e.g. sends, inputs, etc.) the encrypted data to the computing resource for use by the secure computing environment. The commitment may be based on additional data, such as a salt.

[0047] In some examples, the computing resource may have stored thereon the blockchain transaction containing the encryption key, or a reference thereto (e.g. a transaction identifier). Alice 103a may use a verification proof (e.g. Merkle proof), which may also be stored on the computing resource, to verify that the transaction is stored on the blockchain 150. Alice 103a may obtain the encryption key from the blockchain transaction stored on the computing resource, or by using the stored reference to the blockchain transaction.

[0048] The transaction containing the encryption key may be locked to a trusted party's public key, e.g. a manufacturer and / or seller of the computing resource. Alice 103a may verify that the blockchain 150 contains a transaction that is signed by the trusted party and references the transaction containing the encryption key, and only use the encryption key to encrypt data if it does. The transaction and / or a reference (e.g. transaction identifier) may be stored on the computing resource. Alice 103a may use a verification proof (e.g. Merkle proof), which may also be stored on the computing resource, to verify that the transaction is stored on the blockchain 150.

[0049] The computing resource is configured to receive the encrypted data as an input and generate a candidate commitment (e.g. a hash) of the encrypted data. If the candidate commitment matches the commitment found in the blockchain transaction submitted by Alice 103a to the blockchain network 106, the computing resource (e.g. the processor) decrypts the data using the decryption key. The computing resource may load the data, e.g. run the operating system and / or files, and / or load the files. This may involve initialising the secure computing environment.

[0050] The above embodiments use an asymmetric encryption scheme to securely supply and load data on and by a secure computing environment. The following embodiments may use a symmetric encryption scheme instead.

[0051] In these embodiments, a trusted party (e.g. the processor manufacturer) has access to an encryption key, and a corresponding decryption key is stored on the processor. As mentioned, a symmetric encryption scheme may be used, in which case the encryption key is the same as the decryption key. The trusted party may submit a transaction to the blockchain that contains a commitment (e.g. a hash) of the encryption key.

[0052] The trusted party receives a request to encrypt data. The trusted party uses the encryption key to encrypt the data, and sends the encrypted data to the computing resource. The trusted party submits a transaction to the blockchain that contains a commitment (e.g. a hash or double-hash of the encrypted data). The transaction may also contain a challenge (e.g. a hash puzzle) based on the data, a commitment of the data, or the encrypted data. The challenge may be based on additional information, e.g. a secret value stored on the computing resource, or an identifier linked to the user (e.g. Alice 103a). The computing resource, e.g. the secure computing environment of the computing resource, obtains the encrypted data and the blockchain transaction. The computing resource generates a candidate commitment based on the received encrypted data and verifies that the commitment of the encrypted data stored in the blockchain transaction matches. If so, the computing resource decrypts the encrypted data using the stored decryption key. The computing resource may load the data, e.g. run the operating system and / or files, and / or load the files. This may involve initialising the secure computing environment. The computing resource may generate a transaction that includes a solution to the challenge.

[0053] The transaction containing the commitment of the encryption key may be locked to a trusted party's public key, e.g. a manufacturer and / or seller of the computing resource. Alice 103a may verify that the blockchain 150 contains a transaction that is signed by the trusted party and references the transaction containing the encryption key, and only use the encryption key to encrypt data if it does. The transaction and / or a reference (e.g. transaction identifier) may be stored on the computing resource. Alice 103a may use a verification proof (e.g. Merkle proof), which may also be stored on the computing resource, to verify that the transaction is stored on the blockchain 150.

[0054] The examples described above involves transactions being generated and submitted to the blockchain network 106 by the same party. However this just one example. More generally one party may generate the transaction and another party may submit the transaction to the blockchain network 106. Put another way, a party may arrange for a transaction to be submitted to the blockchain network 106. Arranging for a transaction to be submitted to a blockchain network may comprise any one or more of: generating the transaction and transmitting the transaction to one or more blockchain nodes 104 of the network 106; receiving the transaction and transmitting the transaction to one or more blockchain nodes 104 of the network 106; instructing a node 104 to form the transaction and transmit the transaction to one or more other nodes 104 or record the transaction on the blockchain 150; or instructing a computing device (other than a node 104) to form the transaction and transmit the transaction to one or more nodes 104 of the network 106. The skilled person will appreciate that any suitable method may be used. BLOCKCHAIN-BASED DATA ENCLAVES

[0055] An enclave is an isolated working environment. The security requirements of an enclave depend on the available TCB. This section explains how the blockchain can be used to create enclaves in accordance with the embodiments described above. Different blockchain-based enclave techniques are described based on different possibilities for the TCB.

[0056] • Minimal TCB - only the application the user wants to run, and part of the processor (and its associated memory) are considered secure. This TCB is suitable for running trusted application on untrusted machines.

[0057] • Vertically extended TCB - the OS or the hypervisor are included in the TCB. This TCB is suitable for running untrusted applications on trusted machines.

[0058] • Horizontally extended TCB - the TCB is the same as the minimal TCB, but multiple trusted enclaves are deployed, communication between these enclaves may be allowed through secure channels.

[0059] 1.1 Minimal TCB

[0060] The only components included in the minimal TCB are the application the user wants to run and some parts of the processor of the machine. The following actors are involved in the process described in this section.

[0061] • Alice - the machine user

[0062] • Blueberry - the machine producer

[0063] • Carl - the machine owner

[0064] • Dentium - the processor

[0065] • Entel - the processor manufacturer

[0066] • Fnuth - VM developer

[0067] Note that one or more parties may be the same.

[0068] Alice may be a user that is working on an untrusted machine created by the company Blueberry, the machine has a processor, Dentium, created from the manufacturer Entel, and she needs to create an enclave to run a VM developed by Fnuth. 1.1.1 VM Creation

[0069] The VM is created (ideally in a trusted environment) by Fnuth. Fnuth may choose a key G to encrypt the VM or part of it. The VM may be a system VM, and may include the OS, one or more critical applications that it has to run, and the required support files Fk(the support files may contain keys to encrypt files exported from the VM).

[0070] • G: the key used by Fnuth to encrypt the data. The encryption scheme depends on Fnuth's choice, and it can be symmetric or asymmetric. Deploying the VM with these two different encryption schemes results in some differences in the enclave protocol. For this reason, the two cases are discussed in detail below.

[0071] • Fka file stored in the VM and controlled by Fnuth. The file contains keys used to verify the signature of data that tries to interact with the VM. It also contains the key used to encrypt any data that leave the VM. In both situations, the keys are secret keys if the encryption scheme is symmetric, while the keys are public keys if the scheme is asymmetric.

[0072] While VMs may be lightweight applications, their size often surpasses 20GB. Thus, in some cases, the VM is not stored directly on chain. The VM transaction is a blockchain transaction that stores a download link to the VM and a proof of existence of the VM. The VM that can be downloaded from the download link in clear or encrypted (with key G) form. The proof of existence of the VM is used to verify that the downloaded file coincides with the intended VM.

[0073] If it is published in encrypted form, only parties that know the key G can use it. If it is published in clear form, and there exist files containing classified information, those files may be encrypted using G. It may still be possible to use the VM with limited functionalities.

[0074] The VM creation is summarized as follows.

[0075] 1. Fnuth creates a VM and stored related files Fkin the VM.

[0076] 2. Fnuth encrypts the VM using the key G (this step is optional). 3. Fnuth generates a hash of the virtual machine (in encrypted or plain form).

[0077] 4. Fnuth distributes the VM to authorized parties.

[0078] 5. Fnuth publishes the VM transaction TXIDVMto the blockchain.

[0079] The VM developer, Fnuth, creates and publishes the VM transaction TXIDVM(see Table 1) for providing proof of existence of the VM. The VM transaction may be an m-of-n transaction that saves the hash (or any other fingerprint) of the VM, and a download link as the data payload, e.g. using OP_RETURN. The value of n and m is decided by Fnuth. The structure of the transaction TXIDVMis summarized below, HVMdenotes the hash of the VM and LVMthe download link.

[0080] Table 1. An example of VM transaction.

[0081] The VM can be updated by creating a new VM transaction that spends the output of TXIDVMand includes the updated hash value and a new download link. Updating the VM may include one or more of the following operations.

[0082] 1. Updating the software, this includes any modification to the initial VM (e.g., installing new software, updating the OS, saving states after some usage of the VM).

[0083] 2. Adding new cryptographic keys to the set Fk,

[0084] 3. Adding or removing authorized parties (i.e., changing ri) or changing the threshold limit (i.e., changing m).

[0085] Some of the authorized parties could become malicious or their private keys can become inaccessible (e.g., a fired employee). This can introduce vulnerabilities in the proposed solutions. To reduce such vulnerabilities, a threshold signature may be used to create a shared private key that replaces the m-of-n multisig in TXIDVM.

[0086] 1.1.2 Enclave declaration

[0087] It is assumed that the processor is trusted and secure. When the processor interacts with other actors, it can encrypt and decrypt data using a predetermined key D1. The encryption scheme for the key can be asymmetric or symmetric. This section discusses how to declare the enclave using these two types of schemes below. When deploying a VM on an untrusted machine, it is important to ensure that it runs only on secure hardware. The reason the processor is trusted even on untrusted machines is that it is economically infeasible to manipulate the processors.

[0088] 1.1.2.1 Asymmetric scheme

[0089] Under this scheme, is an asymmetric private key, and the corresponding public key is P . If the processor Dentium supports additional asymmetric encryption key besides £>1;then any of them can be used. Figure 3 shows an overview of the interaction between actors.

[0090] 1. When the processor manufacturer Entel sells the processor Dentium to the company Blueberry, it publishes a transaction TXIDCpon the blockchain (see Table 2 below). This is a P2PKH transaction to Blueberry that stores (e.g. after an OP_RETURN) the public key P .

[0091] 2. When a machine containing the Dentium processor is sold by Blueberry to Carl, the company Blueberry creates a transaction TXIDCMthat spends the output of TXIDCp(see Table 3 below).

[0092] 3. Some of the information on the transactions TXIDCMand TXIDCpis saved on the machine. The information may be the transaction ID, or the entire transaction, or the transaction and its Merkle proof. This information allows any machine user to check the security of the machine before deploying anything on the machine.

[0093] 4. When Alice wants to deploy data securely on the machine, she checks TXIDCMand retrieves the public key P to encrypt the data. 5. Alice creates a dust transaction TXIDTD, which includes the hash value of the encrypted data H DE) as a data payload, e.g. after OP_RETURN (see Table 4 below). Note that the H DE) may be replaced by double hash of the encrypted data, or a salted hash H salt\ \DE), or any other types of cryptographic commitment to the data. The transaction TXIDTDis used in the enclave initialization and in the attestation step, since only the processor knows the associated private key, meaning only the process can decrypt the data. processor transaction machine transaction data transaction

[0094] 1.1.2.2 Symmetric Scheme If a symmetric scheme is used, data would be encrypted and decrypted using the same key D1. The enclave declaration proceeds similarly as described in the previous case, with the following differences:

[0095] • The transaction TXIDCpcontains only the hash of the key D1.

[0096] • Data encryption must be carried by Entel, since they are the only ones knowing the key D1.

[0097] Figure 4 shows an overview of the interaction between actors. The enclave declaration process can be summarized as follows.

[0098] 1. Alice sends the data to Entel, together with information on the machine she wants to use.

[0099] 2. Entel uses the data to sets up a unique challenge that only Dentium can solve. The challenge depends on the data Alice sent. The challenge may involve a hash of the data, e.g. the challenge may be hash puzzle based on the data. The challenge should preferably be unique to avoid replay attacks, this can be achieved by linking it to Alice's information. In this way, if another party (say Bob) uses the same data on the same machine, Dentium will not disclose information on Alice's challenge.

[0100] 3. Entel publishes a dust transaction that can be unlocked by solving that challenge (see Table 5 below). Whilst a double hash of the encrypted data is shown, a single hash may be used instead. More generally any type of commitment may be used. Table 5: A data transaction

[0101] The solution in the symmetric scheme may be not efficient as machine users need to communicate with Entel for data encryption. However, this can be automated in various ways. Additionally, this solution offers a beneficial business model for processor manufacturers or any third parties that can be trusted for data encryption. Machine users need to pay them for each request of data encryption or decryption.

[0102] 1.1.3 Setting up the enclave

[0103] The enclave set up is summarized in the following steps.

[0104] 1. The VM is provided in encrypted form to the untrusted machine.

[0105] 2. The enclave is initialized and deployed on the untrusted system.

[0106] 3. The attestation step ensures the enclave is running in a secure environment.

[0107] 4. The processor decrypts the VM.

[0108] 5. The VM securely runs in the enclave.

[0109] Alice may run a trusted VM on the untrusted machine. The VM can be downloaded using the link on the TXIDVMon the untrusted machine or can be provided using hardware support. The VM may have been first (optionally) encrypted by the creator of the VM Fnuth and then (necessarily) using the encryption scheme supported by the processor Dentium of the untrusted machine. That is, the processor encrypted VM is loaded on the untrusted machine.

[0110] Alice (or an application on her behalf) requests the untrusted machine to set up the enclave. The enclave may be an isolated environment that runs only using the processor Dentium (or an isolated part of the processor Alice trusts). The processor encrypted VM is then loaded into the enclave.

[0111] Enclave initialization relies on the processor to ensure the enclave is set up properly. If the untrusted machine tries to act maliciously, setting up a false enclave to deceive Alice, this false enclave does not have access to the processor's private key, thus the data will never be decrypted. If the untrusted machine tries to load additional malicious files in the enclave, this will be noticed during the attestation step.

[0112] An attestation step is performed to ensure that only the correct data Alice intended are stored and will run in the enclave. Alice provides the transaction TXIDTDfor checking data integrity. The trusted processor computes the hash value of the data that Alice loaded and matches it with the hash in TXIDTD. Note that when creating the hash of the loaded data, the transaction TXIDTDis not included. If the hash matches, the processor spends TXIDTDto prove that the data is correct and can be securely deployed in the enclave. If the hashes do not match, the processor will not run the data in the enclave. That is, the processor does not spend TXIDTDand does not decrypt any deployed files, not even the VM.

[0113] If the enclave passes the attestation step, the processor encrypted VM can be decrypted by the processor using the key D1. In case the untrusted machine declared a fake or incorrect transaction TXIDCMor someone manipulated it (e.g., changing the processor), it will not be possible to decrypt the VM.

[0114] If the VM is also encrypted by Fnuth, it will be decrypted. The decryption key can be either provided by Alice or be part of the data already descripted. Now the VM can run safely on the enclave. The processor instantiates some cache that will be accessed only by the VM. This enables the VM to clear all the data it uses from the cache of the processor Dentium when it stops working.

[0115] 1.1.4 Exporting data from the enclave

[0116] In general, enclaves may work relying only on the processor cache and never export data to the outside. However, there may be situations where data need to be saved in the local memory or in some form of cloud storage. The stored data cannot be accessible outside the TCB; thus, they need to be saved in encrypted form. Additional steps can be taken to ensure data integrity, e.g., signing or hashing the encrypted data. If the data needs to be saved locally on the machine, encryption can be achieved at hardware or software level. At the hardware level, data are encrypted using the encryption key saved in the cache of the processor Dentium. At the software level, data are encrypted using algorithms and keys implemented in the VM. A combination of the two may be used when multiple enclaves run on the same processor. This protects data from eavesdropping enclaves.

[0117] Data can be encrypted to ensure data integrity, but the encrypted data is still possible to be tampered with when leaving the enclave. That is, the tampered data could still be exploited by attackers to create vulnerability and deduce information. To overcome this, data leaving the enclave can be either hashed or signed. The two approaches can both be used. Depending on the intended use case, one can be preferrable to the other. For instance, a signature may be more efficient when storing data often and accessing them unfrequently, while a hash would be more practical when large amounts of data are stored occasionally.

[0118] Another approach may be to start any sequence of data with a chosen human readable message and then encrypt the data. The likelihood of tampered data being humanly readable is negligible.

[0119] 1.1.5 Importing data to the enclave

[0120] If any type of data is imported to the VM, the enclave may verify the origin of the data and data integrity before processing it. Indeed, tampered data can be a security liability even when the decrypted data are meaningless. VM updates are an example of data imported in an enclave.

[0121] VM updates can modify the internal structure of the VM and create fatal vulnerabilities. For this reason, it is important to check data integrity when importing such type of data to the enclave. As mentioned above, updates may be published on the blockchain by spending the VM transaction and creating a new VM transaction with the updated VM. This ensures that the updates come from certified parties. The details are described in Figure 5. For consistency, we still use data as the updated VM and the notation of DEas the / ^-encrypted updated VM. 1. The VM is running on an enclave in a machine. An authorized party updates the VM and publishes a VM update transaction TXIDyM. Alice obtains the updated VM from TXID'VM, and the encryption key P from TXIDCp.

[0122] 2. Alice encrypts the updated VM using P and publishes a new TXIDTDto include the hash of the P -encrypted updated VM ( .e.,DE).

[0123] 3. Alice imports DEand TXIDTDto VM where the enclave is running.

[0124] 4. The VM accesses TXIDTDto obtain H DE).

[0125] 5. The VM goes through the attestation step by verifying the hash value (or signature if the updated VM is signed by Alice).

[0126] 6. The VM publishes a new transaction spending TXIDTDto prove that the updated VM is correct.

[0127] 7. The VM decrypts the updated VM.

[0128] 8. The updated version substitutes the old one. The VM can be re-deployed or updated on the fly. In both cases, the entire VM or some applications may need to restart.

[0129] 1.2 Vertically extended TCB

[0130] This subsection focuses on how the security requirements can be relaxed if the OS or the hypervisor are included in the TCB. Despite the types of virtual machines that OS and hypervisor can run are fundamentally different, these two cases are essentially identical for our purposes. The OS / hypervisor can be considered as a guarantor to the security of the enclave with respect to third parties. In the literature, to distinguish hypervisors from OS- level programs that simulates a hypervisor, a convention has been introduced to call Type 1 hypervisor a real hypervisor, and a type 2 hypervisor an OS-level application that has the same functions of a hypervisor. The main difference between the two is that they act at different levels of the protection ring, more specifically, type 1 hypervisors protect full VM from eavesdropping OSs, while type 2 hypervisors protect simulated VM from harmful software running on the same system. In this section, no distinction is made between enclave solutions for OS or hypervisor, because to some extent, the hypervisor can be considered as OS. 1.2.1 Type 1 hypervisor

[0131] If the TCB includes a type 1 hypervisor that run the VMs in the machine, then the hypervisor provides isolation of the various VMs. This means that they all run in separate enclaves and the hypervisor ensures that no application running on the machine can be eavesdropping. Encryption of the data and data integrity need to be checked, as attackers may attempt hardware level hacks, that the hypervisor cannot prevent. For this reason, the solution for this case is not different from the solution for minimal TCB, but there is no need to pass through the processor, as the hypervisor can already grant trustworthiness to the entire process. Software level encryption can be achieved if it is supported by the hypervisor.

[0132] 1.2.2 Type 2 hypervisor

[0133] If the TCB includes the host OS that is running a type 2 hypervisor, the hypervisor provides security to the VM. However, data and applications in the trusted OS cannot be trusted. The hypervisor is trusted to protect the enclave form malicious programs that may run in the host OS (e.g., malware). Beside this difference, the fundamental steps of this solution repeat the solutions already mentioned above. Data integrity for data imported in the enclave is provided by signing or hashing the data. Instead of using keys provided by the VM or by the processor, Alice can provide the key (e.g.,PKAin Figure 6) herself. The trusted host OS can ensure that the keys are stored securely, and that no other applications can access them.

[0134] 1.3 Horizontally extended TCB: secure communication channels

[0135] VMs can be deployed in different secure enclaves for different purposes such as email, social media or image storage. These VMs are securely running applications independently, but they can interact and share data with each other. For example, sending an email that needs to include an image stored in another enclave. Thus, this subsection describes how to allow for multiple VMs to securely communicate on an untrusted machine, and how to establish secure communication channels between these VMs operating on different enclaves. It is possible to use unsecure channels, but this means that data circulating in these channels may be more vulnerable to eavesdropping or manipulation.

[0136] Generating secure communication channels between enclaves require some form of support from the processor. Indeed, since VMs operate only inside the enclave, either the processor or the user is required to support the communication. More specifically, if the processor is supporting the communication, it is required that VMs can express their intention to start a communication channel and the processor can mediate the process (e.g., moving data and providing them to other VMs). If communication support is provided by the OS or the hypervisor, the communication channel should be considered unsecure even through the interaction between VMs still occurs.

[0137] Communication channels can be established by sharing cache. However, this is essentially just merging the two enclaves in one. Data should be communicated in encrypted forms using public or private encryption keys. The rest of the section assumes all the VMs have already been initialized using the procedure described above. Data may not need to be saved in the main memory to be transferred between enclaves. However, if this happens, data need to be encrypted using the processor encryption key before being stored in the main memory. This additional step ensures that the receiving VM is also running on a secure enclave, and so the data are not going to be decrypted outside of the TCB.

[0138] Precautions need to be taken when data are entering into the receiving enclave. The public encryption keys of a VM can be shared, for instance, by enriching the transaction TXIDVMwith this additional information. The linked decryption key is known only by a group of individuals. The decryption key is saved in the file Fk. When a VM deployed in the enclave wants to send data to another VM deployed in a different enclave on the same machine, it retrieves the public encryption key from TXIDVMand uses it to encrypt the data. The details are described in Figure 7.

[0139] Encryption and decryption can happen using keys provided by Alice. This may require her to take direct action (e.g., insert a password) to allow VM communication. Beside this additional step, everything can proceed as in the previous case, without any modification. The main difference between the two approaches is that the former requires some decryption keys to be saved in the VMs. Since the keys are retrieved from a transaction on the blockchain, she must add the keys herself and create the VM creation transactions TXIDVM(for the VMs containing the keys she wants to use). The latter only requires the VM to accept an encryption-decryption key pair provided by the user. Since the former does not require additional interaction with the untrusted machine, it can be considered a safer solution.

[0140] A hybrid situation may be used, where a combination of the other described situations coexists. This means to have some secure communication channels with an application running outside the enclave. This requires support from the OS / hypervisor to ensure security of the communication and data integrity. Essentially, the hypervisor creates a secure space where the application running outside of the enclave can run safely and generate a secure communication channel between the enclave and the secure space dedicated to the application.

[0141] 2. EXAMPLE SYSTEM OVERVIEW

[0142] A blockchain refers to a form of distributed data structure, wherein a duplicate copy of the blockchain is maintained at each of a plurality of nodes in a distributed peer-to-peer (P2P) network (referred to below as a "blockchain network") and widely publicised. The blockchain comprises a chain of blocks of data, wherein each block comprises one or more transactions. Each transaction, other than so-called "coinbase transactions", points back to a preceding transaction in a sequence which may span one or more blocks going back to one or more coinbase transactions. Coinbase transactions are discussed further below.

[0143] Transactions that are submitted to the blockchain network are included in new blocks. New blocks are created by a process often referred to as "mining", which involves each of a plurality of the nodes competing to perform "proof-of-work", i.e. solving a cryptographic puzzle based on a representation of a defined set of ordered and validated pending transactions waiting to be included in a new block of the blockchain. It should be noted that the blockchain may be pruned at some nodes, and the publication of blocks can be achieved through the publication of mere block headers.

[0144] The transactions in the blockchain may be used for one or more of the following purposes: to convey a digital asset (i.e. a number of digital tokens), to order a set of entries in a virtualised ledger or registry, to receive and process timestamp entries, and / or to timeorder index pointers. A blockchain can also be exploited in order to layer additional functionality on top of the blockchain. For example, blockchain protocols may allow for storage of additional user data or indexes to data in a transaction. There is no pre-specified limit to the maximum data capacity that can be stored within a single transaction, and therefore increasingly more complex data can be incorporated. For instance this may be used to store an electronic document in the blockchain, or audio or video data.

[0145] In an "output-based" model (sometimes referred to as a UTXO-based model), the data structure of a given transaction comprises one or more inputs and one or more outputs. Any spendable output comprises an element specifying an amount of the digital asset that is derivable from the proceeding sequence of transactions. The spendable output is sometimes referred to as a UTXO ("unspent transaction output"). The output may further comprise a locking script specifying a condition for the future redemption of the output. A locking script is a predicate defining the conditions necessary to validate and transfer digital tokens or assets. Each input of a transaction (other than a coinbase transaction) comprises a pointer (i.e. a reference) to such an output in a preceding transaction, and may further comprise an unlocking script for unlocking the locking script of the pointed-to output. So consider a pair of transactions, call them a first and a second transaction (or "target" transaction). The first transaction comprises at least one output specifying an amount of the digital asset, and comprising a locking script defining one or more conditions of unlocking the output. The second, target transaction comprises at least one input, comprising a pointer to the output of the first transaction, and an unlocking script for unlocking the output of the first transaction.

[0146] In such a model, when the second, target transaction is sent to the blockchain network to be propagated and recorded in the blockchain, one of the criteria for validity applied at each node will be that the unlocking script meets all of the one or more conditions defined in the locking script of the first transaction. Another will be that the output of the first transaction has not already been redeemed by another, earlier valid transaction. Any node that finds the target transaction invalid according to any of these conditions will not propagate it (as a valid transaction, but possibly to register an invalid transaction) nor include it in a new block to be recorded in the blockchain. An alternative type of transaction model is an account-based model. In this case each transaction does not define the amount to be transferred by referring back to the UTXO of a preceding transaction in a sequence of past transactions, but rather by reference to an absolute account balance. The current state of all accounts is stored by the nodes separate to the blockchain and is updated constantly.

[0147] Figure 1 shows an example system 100 for implementing a blockchain 150. The system 100 may comprise a packet-switched network 101, typically a wide-area internetwork such as the Internet. The packet-switched network 101 comprises a plurality of blockchain nodes 104 (often referred to as "miners") that may be arranged to form a peer-to-peer (P2P) network 106 within the packet-switched network 101. Whilst not illustrated, the blockchain nodes 104 may be arranged as a near-complete graph. Each blockchain node 104 is therefore highly connected to other blockchain nodes 104.

[0148] Each blockchain node 104 comprises computer equipment of a peer, with different ones of the nodes 104 belonging to different peers. Each blockchain node 104 comprises processing apparatus comprising one or more processors, e.g. one or more central processing units (CPUs), accelerator processors, application specific processors and / or field programmable gate arrays (FPGAs), and other equipment such as application specific integrated circuits (ASICs). Each node also comprises memory, i.e. computer-readable storage in the form of a non-transitory computer-readable medium or media. The memory may comprise one or more memory units employing one or more memory media, e.g. a magnetic medium such as a hard disk; an electronic medium such as a solid-state drive (SSD), flash memory or EEPROM; and / or an optical medium such as an optical disk drive.

[0149] The blockchain 150 comprises a chain of blocks of data 151, wherein a respective copy of the blockchain 150 is maintained at each of a plurality of blockchain nodes 104 in the distributed or blockchain network 106. As mentioned above, maintaining a copy of the blockchain 150 does not necessarily mean storing the blockchain 150 in full. Instead, the blockchain 150 may be pruned of data so long as each blockchain node 150 stores the block header (discussed below) of each block 151. Each block 151 in the chain comprises one or more transactions 152, wherein a transaction in this context refers to a kind of data T1 structure. The nature of the data structure will depend on the type of transaction protocol used as part of a transaction model or scheme. A given blockchain will use one particular transaction protocol throughout.

[0150] A blockchain node 104 may be configured to forward transactions 152 to other blockchain nodes 104, and thereby cause transactions 152 to be propagated throughout the network 106. A blockchain node 104 may be configured to create blocks 151 and to store a respective copy of the same blockchain 150 in their respective memory. A blockchain node 104 may also maintain an ordered set (or "pool") 154 of transactions 152 waiting to be incorporated into blocks 151. The ordered pool 154 is often referred to as a "mempool". This term herein is not intended to limit to any particular blockchain, protocol or model. It refers to the ordered set of transactions which a node 104 has accepted as valid and for which the node 104 is obliged not to accept any other transactions attempting to spend the same output.

[0151] In a given present transaction 152j, the (or each) input comprises a pointer referencing the output of a preceding transaction 152i in the sequence of transactions, specifying that this output is to be redeemed or "spent" in the present transaction 152j. Spending or redeeming does not necessarily imply transfer of a financial asset, though that is certainly one common application. More generally spending could be described as consuming the output, or assigning it to one or more outputs in another, onward transaction. In general, the preceding transaction could be any transaction in the ordered set 154 or any block 151. The preceding transaction 152i need not necessarily exist at the time the present transaction 152j is created or even sent to the network 106, though the preceding transaction 152i will need to exist and be validated in order for the present transaction to be valid. Hence "preceding" herein refers to a predecessor in a logical sequence linked by pointers, not necessarily the time of creation or sending in a temporal sequence, and hence it does not necessarily exclude that the transactions 152i, 152j be created or sent out-of-order (see discussion below on orphan transactions). The preceding transaction 152i could equally be called the antecedent or predecessor transaction. Due to the resources involved in transaction validation and publication, typically at least each of the blockchain nodes 104 takes the form of a server comprising one or more physical server units, or even whole a data centre. However in principle any given blockchain node 104 could take the form of a user terminal or a group of user terminals networked together.

[0152] The memory of each blockchain node 104 stores software configured to run on the processing apparatus of the blockchain node 104 in order to perform its respective role or roles and handle transactions 152 in accordance with the blockchain node protocol. It will be understood that any action attributed herein to a blockchain node 104 may be performed by the software run on the processing apparatus of the respective computer equipment. The node software may be implemented in one or more applications at the application layer, or a lower layer such as the operating system layer or a protocol layer, or any combination of these.

[0153] Any given blockchain node may be configured to perform one or more of the following operations: validating transactions, storing transactions, propagating transactions to other peers, performing consensus (e.g. proof-of-work) / mining operations. In some examples, each type of operation is performed by a different node 104. That is, nodes may specialise in particular operation. For example, a nodes 104 may focus on transaction validation and propagation, or on block mining. In some examples, a blockchain node 104 may perform more than one of these operations in parallel. Any reference to a blockchain node 104 may refer to an entity that is configured to perform at least one of these operations.

[0154] Also connected to the network 101 is the computer equipment 102 of each of a plurality of parties 103 in the role of consuming users. These users may interact with the blockchain network 106 but do not participate in validating transactions or constructing blocks. Some of these users or agents 103 may act as senders and recipients in transactions. Other users may interact with the blockchain 150 without necessarily acting as senders or recipients. For instance, some parties may act as storage entities that store a copy of the blockchain 150 (e.g. having obtained a copy of the blockchain from a blockchain node 104). Some or all of the parties 103 may be connected as part of a different network, e.g. a network overlaid on top of the blockchain network 106. Users of the blockchain network (often referred to as "clients") may be said to be part of a system that includes the blockchain network 106; however, these users are not blockchain nodes 104 as they do not perform the roles required of the blockchain nodes. Instead, each party 103 may interact with the blockchain network 106 and thereby utilize the blockchain 150 by connecting to (i.e. communicating with) a blockchain node 106. Two parties 103 and their respective equipment 102 are shown for illustrative purposes: a first party 103a and his / her respective computer equipment 102a, and a second party 103b and his / her respective computer equipment 102b. It will be understood that many more such parties 103 and their respective computer equipment 102 may be present and participating in the system 100, but for convenience they are not illustrated. Each party 103 may be an individual or an organization. Purely by way of illustration the first party 103a is referred to herein as Alice and the second party 103b is referred to as Bob, but it will be appreciated that this is not limiting and any reference herein to Alice or Bob may be replaced with "first party" and "second "party" respectively.

[0155] The computer equipment 102 of each party 103 comprises respective processing apparatus comprising one or more processors, e.g. one or more CPUs, GPUs, other accelerator processors, application specific processors, and / or FPGAs. The computer equipment 102 of each party 103 further comprises memory, i.e. computer-readable storage in the form of a non-transitory computer-readable medium or media. This memory may comprise one or more memory units employing one or more memory media, e.g. a magnetic medium such as hard disk; an electronic medium such as an SSD, flash memory or EEPROM; and / or an optical medium such as an optical disc drive. The memory on the computer equipment 102 of each party 103 stores software comprising a respective instance of at least one client application 105 arranged to run on the processing apparatus. It will be understood that any action attributed herein to a given party 103 may be performed using the software run on the processing apparatus of the respective computer equipment 102. The computer equipment 102 of each party 103 comprises at least one user terminal, e.g. a desktop or laptop computer, a tablet, a smartphone, or a wearable device such as a smartwatch. The computer equipment 102 of a given party 103 may also comprise one or more other networked resources, such as cloud computing resources accessed via the user terminal.

[0156] The client application 105 may be initially provided to the computer equipment 102 of any given party 103 on suitable computer-readable storage medium or media, e.g. downloaded from a server, or provided on a removable storage device such as a removable SSD, flash memory key, removable EEPROM, removable magnetic disk drive, magnetic floppy disk or tape, optical disk such as a CD or DVD ROM, or a removable optical drive, etc.

[0157] The client application 105 comprises at least a "wallet" function. This has two main functionalities. One of these is to enable the respective party 103 to create, authorise (for example sign) and send transactions 152 to one or more bitcoin nodes 104 to then be propagated throughout the network of blockchain nodes 104 and thereby included in the blockchain 150. The other is to report back to the respective party the amount of the digital asset that he or she currently owns. In an output-based system, this second functionality comprises collating the amounts defined in the outputs of the various 152 transactions scattered throughout the blockchain 150 that belong to the party in question.

[0158] Note: whilst the various client functionality may be described as being integrated into a given client application 105, this is not necessarily limiting and instead any client functionality described herein may instead be implemented in a suite of two or more distinct applications, e.g. interfacing via an API, or one being a plug-in to the other. More generally the client functionality could be implemented at the application layer or a lower layer such as the operating system, or any combination of these. The following will be described in terms of a client application 105 but it will be appreciated that this is not limiting.

[0159] The instance of the client application or software 105 on each computer equipment 102 is operatively coupled to at least one of the blockchain nodes 104 of the network 106. This enables the wallet function of the client 105 to send transactions 152 to the network 106. The client 105 is also able to contact blockchain nodes 104 in order to query the blockchain 150 for any transactions of which the respective party 103 is the recipient (or indeed inspect other parties' transactions in the blockchain 150, since in embodiments the blockchain 150 is a public facility which provides trust in transactions in part through its public visibility). The wallet function on each computer equipment 102 is configured to formulate and send transactions 152 according to a transaction protocol. As set out above, each blockchain node 104 runs software configured to validate transactions 152 according to the blockchain node protocol, and to forward transactions 152 in order to propagate them throughout the blockchain network 106. The transaction protocol and the node protocol correspond to one another, and a given transaction protocol goes with a given node protocol, together implementing a given transaction model. The same transaction protocol is used for all transactions 152 in the blockchain 150. The same node protocol is used by all the nodes 104 in the network 106.

[0160] An alternative type of transaction protocol operated by some blockchain networks may be referred to as an "account-based" protocol, as part of an account-based transaction model. In the account-based case, each transaction does not define the amount to be transferred by referring back to the UTXO of a preceding transaction in a sequence of past transactions, but rather by reference to an absolute account balance. The current state of all accounts is stored, by the nodes of that network, separate to the blockchain and is updated constantly. In such a system, transactions are ordered using a running transaction tally of the account (also called the "position" or "nonce"). This value is signed by the sender as part of their cryptographic signature and is hashed as part of the transaction reference calculation. In addition, an optional data field may also be signed the transaction. This data field may point back to a previous transaction, for example if the previous transaction ID is included in the data field.

[0161] Some account-based transaction models share several similarities with the output-based transaction model described herein. For example, as mentioned above, the data field of an account-based transaction may point back to a previous transaction, which is equivalent to the input of an output-based transaction which references an outpoint a previous transaction. Thus both models enable linking between transactions. As another example, an account-based transaction contains a "recipient" field (in which a receiving address of an account is specified) and a "value" field (in which an amount of digital asset may be specified). Together the recipient and value fields are equivalent to the output of an outputbased transaction which may be used to assign an amount of digital asset to a blockchain address. Similarly, an account-based transaction has a "signature" field which includes a signature for the transaction. The signature is generated using the sender's private key and confirms the sender has authorized this transaction. This is equivalent to an input / unlocking script of an output-based transaction which, typically, includes a signature for the transaction. When both types of transaction are submitted to their respective blockchain networks, the signatures are checked to determine whether the transaction is valid and can be recorded on the blockchain. On an account-based blockchain, a "smart contact" refers to a transaction that contains a script configured to perform one or more actions (e.g. send or "release" a digital asset to a recipient address) in response to one or more inputs (provided by a transaction) meeting one or more conditions defined by the smart contact's script. The smart contract exists as a transaction on the blockchain, and can be called (or triggered) by subsequent transactions. Thus, in some examples, a smart contract may be considered equivalent to a locking script of an output-based transaction, which can be triggered by a subsequent transaction, and checks whether one or more conditions defined by the locking script are met by the input of the subsequent transaction.

[0162] 3. UTXO-BASED MODEL

[0163] Figure 2 illustrates an example transaction protocol. This is an example of a UTXO-based protocol. A transaction 152 (abbreviated "Tx") is the fundamental data structure of the blockchain 150 (each block 151 comprising one or more transactions 152). The following will be described by reference to an output-based or "UTXO" based protocol. However, this is not limiting to all possible embodiments. Note that while the example UTXO-based protocol is described with reference to bitcoin, it may equally be implemented on other example blockchain networks.

[0164] In a UTXO-based model, each transaction ("Tx") 152 comprises a data structure comprising one or more inputs 202, and one or more outputs 203. Each output 203 may comprise an unspent transaction output (UTXO), which can be used as the source for the input 202 of another new transaction (if the UTXO has not already been redeemed). The UTXO includes a value specifying an amount of a digital asset. This represents a set number of tokens on the distributed ledger. The UTXO may also contain the transaction ID of the transaction from which it came, amongst other information. The transaction data structure may also comprise a header 201, which may comprise an indicator of the size of the input field(s) 202 and output field(s) 203. The header 201 may also include an ID of the transaction. In embodiments the transaction ID is the hash of the transaction data (excluding the transaction ID itself) and stored in the header 201 of the raw transaction 152 submitted to the nodes 104.

[0165] Say Alice 103a wishes to create a transaction 152j transferring an amount of the digital asset in question to Bob 103b. In Figure 2 Alice's new transaction 152j is labelled " TxT. It takes an amount of the digital asset that is locked to Alice in the output 203 of a preceding transaction 152i in the sequence, and transfers at least some of this to Bob. The preceding transaction 152i is labelled “Txo" in Figure 2. TAT? and Txi are just arbitrary labels. They do not necessarily mean that Txo is the first transaction in the blockchain 151, nor that Txi is the immediate next transaction in the pool 154. Txi could point back to any preceding (i.e. antecedent) transaction that still has an unspent output 203 locked to Alice.

[0166] The terms "preceding" and "subsequent" as used herein in the context of the sequence of transactions refer to the order of the transactions in the sequence as defined by the transaction pointers specified in the transactions (which transaction points back to which other transaction, and so forth). They could equally be replaced with "predecessor" and "successor", or "antecedent" and "descendant", "parent" and "child", or such like. It does not necessarily imply an order in which they are created, sent to the network 106, or arrive at any given blockchain node 104. Nevertheless, a subsequent transaction (the descendent transaction or "child") which points to a preceding transaction (the antecedent transaction or "parent") will not be validated until and unless the parent transaction is validated. A child that arrives at a blockchain node 104 before its parent is considered an orphan. It may be discarded or buffered for a certain time to wait for the parent, depending on the node protocol and / or node behaviour.

[0167] One of the one or more outputs 203 of the preceding transaction Txo comprises a particular

[0168] UTXO, labelled here UTXOo. Each UTXO comprises a value specifying an amount of the digital asset represented by the UTXO, and a locking script which defines a condition which must be met by an unlocking script in the input 202 of a subsequent transaction in order for the subsequent transaction to be validated, and therefore for the UTXO to be successfully redeemed.

[0169] The locking script (aka scriptPubKey) is a piece of code written in the domain specific language recognized by the node protocol. A particular example of such a language is called "Script" (capital S) which is used by the blockchain network. The locking script specifies what information is required to spend a transaction output 203, for example the requirement of Alice's signature. Locking scripts appear in the outputs of transactions. The unlocking script (aka scriptSig) is a piece of code written the domain specific language that provides the information required to satisfy the locking script criteria. For example, it may contain Bob's signature. Unlocking scripts appear in the input 202 of transactions.

[0170] So in the example illustrated, UTXOo in the output 203 of TAT? comprises a locking script [Checksig PA which requires a signature Sig PA of Alice in order for UTXOo to be redeemed (strictly, in order for a subsequent transaction attempting to redeem UTXOo to be valid). [Checksig PA contains a representation (i.e. a hash) of the public key PA from a publicprivate key pair of Alice. The input 202 of Txi comprises a pointer pointing back to Txi (e.g. by means of its transaction ID, TxIDo, which in embodiments is the hash of the whole transaction Txo). The input 202 of Txi comprises an index identifying UTXOo within Txo, to identify it amongst any other possible outputs of Txo. The input 202 of Txi further comprises an unlocking script <Sig PA> which comprises a cryptographic signature of Alice, created by Alice applying her private key from the key pair to a predefined portion of data (sometimes called the "message" in cryptography). The data (or "message") that needs to be signed by Alice to provide a valid signature may be defined by the locking script, or by the node protocol, or by a combination of these.

[0171] When the new transaction Txi arrives at a blockchain node 104, the node applies the node protocol. This comprises running the locking script and unlocking script together to check whether the unlocking script meets the condition defined in the locking script (where this condition may comprise one or more criteria). Note that the script code is often represented schematically (i.e. not using the exact language). For example, one may use operation codes (opcodes) to represent a particular function. "OP_..." refers to a particular opcode of the Script language. As an example, OP_RETURN is an opcode of the Script language that when preceded by OP_FALSE at the beginning of a locking script creates an unspendable output of a transaction that can store data within the transaction, and thereby record the data immutably in the blockchain 150. E.g. the data could comprise a document which it is desired to store in the blockchain.

[0172] Typically an input of a transaction contains a digital signature corresponding to a public key PA. In embodiments this is based on the ECDSA using the elliptic curve secp256kl. A digital signature signs a particular piece of data. In some embodiments, for a given transaction the signature will sign part of the transaction input, and some or all of the transaction outputs. The particular parts of the outputs it signs depends on the SIGHASH flag. The SIGHASH flag is usually a 4-byte code included at the end of a signature to select which outputs are signed (and thus fixed at the time of signing).

[0173] The locking script is sometimes called "scriptPubKey" referring to the fact that it typically comprises the public key of the party to whom the respective transaction is locked. The unlocking script is sometimes called "scriptSig" referring to the fact that it typically supplies the corresponding signature. However, more generally it is not essential in all applications of a blockchain 150 that the condition for a UTXO to be redeemed comprises authenticating a signature. More generally the scripting language could be used to define any one or more conditions. Hence the more general terms "locking script" and "unlocking script" may be preferred.

[0174] 4. APPENDIX - Levels of the protection rings

[0175] 4.1 App and drivers (Ring 3 to 1)

[0176] The rings with least privileges contain applications and drivers, at various level of access permissions. In many OS, these rings are identified with the user mode of the OS. Rings 1 and 2 are relatively rare in computer architecture. 4.2 Operating system (Ring 0)

[0177] The ring that contains the OS in kernel mode has been for many years the highest privilege ring. Programs that run in Ring 0 could do anything with the system. Higher privileges were introduced to allow the full virtualization of virtual machines.

[0178] 4.3 Hypervisor (Ring -1)

[0179] The hypervisor is a level higher than the OS, but it is essentially just a higher privilege OS. The term is a variant of supervisor (commonly used for the OS), with hyper being meant to be a stronger variant of super. A computer on which a hypervisor runs one or more virtual machines is called a host machine, and each virtual machine is called a guest machine. The hypervisor presents the guest operating systems with a virtual operating platform and manages the execution of the guest operating systems. There are two types of hypervisors. Type 1 hypervisor run directly on the hardware (e.g., processor) without the need for an underlying operating system, while type 2 hypervisors run on top of an existing operating system.

[0180] 4.4 System Management Mode (Ring -2)

[0181] The system management mode guarantees functionality when the hypervisor is compromised, it is used for power and thermal management and when dealing with fatal hardware errors.

[0182] 4.5 Platform security engine (Ring -3)

[0183] The platform security engine is a physical isolated piece of hardware that can power up and down the processor, it may even be network connected and has access to reserved space in memory.

[0184] 5. FURTHER REMARKS

[0185] Other variants or use cases of the disclosed techniques may become apparent to the person skilled in the art once given the disclosure herein. The scope of the disclosure is not limited by the described embodiments but only by the accompanying claims. For instance, some embodiments above have been described in terms of a bitcoin network 106, bitcoin blockchain 150 and bitcoin nodes 104. However it will be appreciated that the bitcoin blockchain is one particular example of a blockchain 150 and the above description may apply generally to any blockchain. That is, the present invention is in by no way limited to the bitcoin blockchain. More generally, any reference above to bitcoin network 106, bitcoin blockchain 150 and bitcoin nodes 104 may be replaced with reference to a blockchain network 106, blockchain 150 and blockchain node 104 respectively. The blockchain, blockchain network and / or blockchain nodes may share some or all of the described properties of the bitcoin blockchain 150, bitcoin network 106 and bitcoin nodes 104 as described above.

[0186] In preferred embodiments of the invention, the blockchain network 106 is the bitcoin network and bitcoin nodes 104 perform at least all of the described functions of creating, publishing, propagating and storing blocks 151 of the blockchain 150. It is not excluded that there may be other network entities (or network elements) that only perform one or some but not all of these functions. That is, a network entity may perform the function of propagating and / or storing blocks without creating and publishing blocks (recall that these entities are not considered nodes of the preferred bitcoin network 106).

[0187] In other embodiments of the invention, the blockchain network 106 may not be the bitcoin network. In these embodiments, it is not excluded that a node may perform at least one or some but not all of the functions of creating, publishing, propagating and storing blocks 151 of the blockchain 150. For instance, on those other blockchain networks a "node" may be used to refer to a network entity that is configured to create and publish blocks 151 but not store and / or propagate those blocks 151 to other nodes.

[0188] Even more generally, any reference to the term "bitcoin node" 104 above may be replaced with the term "network entity" or "network element", wherein such an entity / element is configured to perform some or all of the roles of creating, publishing, propagating and storing blocks. The functions of such a network entity / element may be implemented in hardware in the same way described above with reference to a blockchain node 104. Some embodiments have been described in terms of the blockchain network implementing a proof-of-work consensus mechanism to secure the underlying blockchain. However proof- of-work is just one type of consensus mechanism and in general embodiments may use any type of suitable consensus mechanism such as, for example, proof-of-stake, delegated proof-of-stake, proof-of-capacity, or proof-of-elapsed time. As a particular example, proof- of-stake uses a randomized process to determine which blockchain node 104 is given the opportunity to produce the next block 151. The chosen node is often referred to as a validator. Blockchain nodes can lock up their tokens for a certain time in order to have the chance of becoming a validator. Generally, the node who locks the biggest stake for the longest period of time has the best chance of becoming the next validator.

[0189] It will be appreciated that the above embodiments have been described by way of example only. More generally there may be provided a method, apparatus or program in accordance with any one or more of the following Statements.

[0190] Statement 1. A computer-implemented method of using a computing environment of a computing resource, wherein a blockchain comprises a first blockchain transaction comprising an encryption key, and wherein the method comprises: obtaining the encryption key from the first blockchain transaction; using the encryption key to encrypt data; arranging for a second blockchain transaction to be submitted to one or more nodes of a blockchain network, wherein the second blockchain transaction comprises a commitment of the encrypted data; and supplying the encrypted data to the computing resource for use by the computing environment.

[0191] Statement 2. The method of statement 1, wherein the computing resource comprises the first blockchain transaction and / or a reference thereto, and wherein the method comprises using the first blockchain transaction and / or the reference thereto to obtain the encryption key. Statement 3. The method of statement 1 or statement 2, wherein the first blockchain transaction is locked to a trusted party, and wherein the blockchain comprises a third blockchain transaction that references the first blockchain transaction and is signed by the trusted party, and wherein the method comprises verifying that the blockchain comprises the third blockchain transaction as a condition of using the computing environment.

[0192] Statement 4. The method of statement 3, wherein the computing resource comprises the third blockchain transaction and / or a reference thereto, and wherein the method comprises using the third blockchain transaction and / or the reference thereto to verify that the blockchain comprises the third blockchain transaction.

[0193] Statement 5. The method of any preceding statement, wherein using the computing environment comprises initializing and / or deploying data to the computing environment.

[0194] Statement 6. A computer-implemented method of operating a computing environment of a computing resource, wherein a blockchain comprises a first blockchain transaction comprising an encryption key, wherein the computing resource has stored thereon a decryption key corresponding to the encryption key, and wherein the method comprises: receiving encrypted data as an input from a user of the computing resource; obtaining, from a second blockchain transaction, a commitment of the encrypted data; generating a candidate commitment of the encrypted data, verifying that the candidate commitment corresponds to the obtained commitment; and decrypting the encrypted data using the decryption key when the candidate commitment of the encrypted data corresponds to the obtained commitment.

[0195] Statement 7. The method of statement 6, wherein the computing resource comprises one or more of: the first blockchain transaction, a reference to the first blockchain transaction, and a proof that the first blockchain transaction is stored on the blockchain. Statement 8. The method of statement 6 or statement 7, wherein the first blockchain transaction is locked to a trusted party, and wherein the blockchain comprises a third blockchain transaction that references the first blockchain transaction and is signed by the trusted party, and wherein the computing resource comprises one or more of: the third blockchain transaction, a reference to the third blockchain transaction, and a proof that the third blockchain transaction is stored on the blockchain.

[0196] Statement 9. The method of any preceding statement, wherein the data comprises one or more of: an operating system, one or more applications and one or more files.

[0197] Statement 10. The method of statement 9 when dependent on statement 6, comprising loading and / or executing the data.

[0198] Statement 11. The method of any preceding statement, wherein the computing environment comprises a virtual computing requirement.

[0199] Statement 12. The method of any preceding statement, wherein the decryption key is stored on a processor of the computing resource or implemented by a circuit of the computing resource.

[0200] Statement 13. Computer equipment comprising: memory comprising one or more memory units; and processing apparatus comprising one or more processing units, wherein the memory stores code arranged to run on the processing apparatus, the code being configured so as when on the processing apparatus to perform the method of any of statements 1 to 13.

[0201] Statement 14. A computer program embodied on computer-readable storage and configured so as, when run on one or more processors, to perform the method of any of statements 1 to 13. Statement 15. A computer-implemented method of operating a computing environment of a computing resource, wherein the computing resource has stored thereon a decryption key corresponding to an encryption key, wherein the method comprises: receiving data from a user; using the encryption key to encrypt the data; arranging for a first blockchain transaction to be submitted to one or more nodes of the blockchain network, wherein the first blockchain transaction comprises a commitment of the encrypted data; and supplying the encrypted data to the computing resource and / or the user for use by the computing environment.

[0202] The method may comprise arranging for a first blockchain transaction to be submitted to one or more nodes of a blockchain network, wherein the first blockchain transaction comprises a commitment of an encryption key.

[0203] Statement 16. The method of statement 15, wherein the first blockchain transaction comprises a challenge based on the data.

[0204] Statement 17. The method of statement 16, wherein the computing resource comprises a secret value, and wherein the challenge is based on the secret value.

[0205] Statement 18. The method of statement 16 or statement 17 wherein the challenge is based on an identifier of the user.

[0206] Statement 19. The method of any of statements 15 to 18, comprising storing the decryption key on the computing resource.

[0207] Statement 20. A computer-implemented method of operating a computing environment of a computing resource, wherein the computing resource has stored thereon the decryption key, and wherein the method comprises: receiving encrypted data; obtaining a first blockchain transaction, wherein the first blockchain transaction comprises a commitment of the encrypted data; generating a candidate commitment of the encrypted data; and verifying that the commitment of the encrypted data corresponds to the commitment of the encrypted data; and decrypting the encrypted data using the decryption key when the candidate commitment of the encrypted data corresponds to the commitment of the encrypted data.

[0208] Statement 21. The method of statement 20, wherein the first blockchain transaction is locked to a challenge based on at least a commitment of the data, and wherein the method comprises: determining a solution to the challenge; and submitting a blockchain transaction to one or more blockchain nodes that references the first blockchain transaction and comprises the solution to the challenge.

[0209] Statement 22. The method of statement 21, wherein the computing resource comprises a secret value, wherein the challenge is based on the secret value, and wherein the method comprises using the secret value to solve the challenge.

[0210] Statement 23. The method of statement 21 or statement 55, wherein the challenge is based on an identifier of a user of the computing resource, and wherein the method comprises using the identifier to solve the challenge.

[0211] Statement 24. The method of any of statements 19 to 21, wherein the computing resource comprises one or more of: a second blockchain transaction comprising a commitment of the encryption key, a reference to the second blockchain transaction, and a proof that the second blockchain transaction is stored on the blockchain.

[0212] Statement 25. The method of statement 11, wherein the second blockchain transaction is locked to a trusted party, and wherein the blockchain comprises a third blockchain transaction that references the second blockchain transaction and is signed by a trusted party, and wherein the computing resource comprises one or more of: the third blockchain transaction, a reference to the third blockchain transaction, and a proof that the third blockchain transaction is stored on the blockchain.

[0213] Statement 26. The method of any of statements 15 to 25, wherein the data comprises one or more of: an operating system, one or more applications and one or more files.

[0214] Statement 27. The method of any of statements 15 to 26, wherein the computing environment comprises a virtual computing environment.

[0215] Statement 28. The method of any of statements 15 to 27, wherein the encryption key is stored on a processor of the computing resource or implemented by a circuit of the computing resource.

[0216] Statement 29. Computer equipment comprising: memory comprising one or more memory units; and processing apparatus comprising one or more processing units, wherein the memory stores code arranged to run on the processing apparatus, the code being configured so as when on the processing apparatus to perform the method of any of statements 15 to 28.

[0217] Statement 30. A computer program embodied on computer-readable storage and configured so as, when run on one or more processors, to perform the method of any of statements 15 to 28.

[0218] Statement 31. A computer-implemented method comprising: obtaining a virtual machine, wherein the virtual machine comprises one or more of: an operating system, one or more applications and one or more files; encrypting the virtual machine to generate an encrypted virtual machine; generating a first commitment based on the encrypted virtual machine; arranging for a first blockchain transaction to be submitted to one or more blockchain nodes, wherein the first blockchain transaction comprises the first commitment. Statement 32. The method of statement 31, wherein the virtual machine comprises one or more encryption keys for encrypting data exported from the virtual machine and / or one or more decryption keys for decrypting data imported to the virtual machine.

[0219] Statement 33. The method of statement 31 or statement 32, wherein obtaining the virtual machine comprises creating the virtual machine.

[0220] Statement 34. The method of any of statements 31 to 33, wherein the first blockchain transaction comprises a link and / or reference to a storage resource storing the virtual machine or an encrypted version thereof.

[0221] Statement 35. The method of any of statements 31 to 34, comprising: modifying the virtual machine; generating a second commitment based on the modified virtual machine; and arranging for a second blockchain transaction to be submitted to one or more blockchain nodes, wherein the second blockchain transaction references the first blockchain transaction and comprises the second commitment.

[0222] Statement 36. The method of statement 35, wherein modifying the virtual machine comprises modifying one or more of the operating system, the one or more applications and the one or more files.

[0223] Statement 37. The method of statement 35 or statement 36 when dependent on statement 32, wherein modifying the virtual machine comprises adding and / or removing one or more of the encryption keys and / or one or more of the decryption keys.

[0224] Statement 38. The method of statement 35 or any statement dependent thereon, wherein the first blockchain transaction is locked to at least a threshold number of a first set of one or more public keys, and wherein the second blockchain transaction comprises at least the threshold number of corresponding signatures. Statement 39. The method of statement 38, wherein the second blockchain transaction is locked to a different threshold number of the one or more public keys, or at least a threshold number of a second set of one or more public keys, the first and second sets being non-identical.

[0225] Statement 40. The method of statement 35 or any statement dependent thereon, wherein the first blockchain transaction is locked to a public key corresponding to a shared private key, and wherein the second blockchain transaction comprises a threshold signature corresponding to the shared private key.

[0226] Statement 41. A computer-implemented method of accessing a virtual machine using a blockchain, wherein a blockchain comprises a first blockchain transaction, wherein the first blockchain transaction comprises a first commitment based on a virtual machine, wherein the virtual machine comprises one or more of: an operating system, one or more applications and one or more files, and wherein the method comprises: obtaining the first blockchain transaction; obtaining an encrypted version of the virtual machine; and loading and / or using the virtual machine if the obtained encrypted version of the virtual machine corresponds to the first commitment.

[0227] Statement 42. The method of statement 41, wherein the first blockchain transaction comprises a link and / or reference to a storage resource storing the encrypted version of the virtual machine, and wherein the method comprises using the link and / or the reference to obtain the encrypted version of the virtual machine.

[0228] Statement 43. The method of statement 41 or statement 42, wherein the blockchain comprises a third blockchain transaction, wherein the third blockchain transaction comprises a public key associated with a second virtual machine, and wherein the method comprises: encrypting data using the public key associated with the second virtual machine; and making the encrypted data available to the second virtual machine. Statement 44. The method of statement 43, comprising signing the encrypted data using a private key corresponding to a public key associated with the first virtual machine.

[0229] Statement 45. The method of statement 44, wherein the first blockchain transaction comprises the public key associated with the first virtual machine.

[0230] Statement 46. Computer equipment comprising: memory comprising one or more memory units; and processing apparatus comprising one or more processing units, wherein the memory stores code arranged to run on the processing apparatus, the code being configured so as when on the processing apparatus to perform the method of any of statements 31 to 45.

[0231] Statement 47. A computer program embodied on computer-readable storage and configured so as, when run on one or more processors, to perform the method of any of statements 31 to 46.

Claims

CLAIMS1. A computer-implemented method of providing data for use by a computing environment of a computing resource having a decryption key stored thereon, wherein a blockchain comprises a first blockchain transaction comprising an encryption key corresponding to the decryption key stored on the computing resource, and wherein the method comprises: obtaining the encryption key from the first blockchain transaction; using the encryption key to encrypt data; arranging for a second blockchain transaction to be submitted to one or more nodes of a blockchain network, wherein the second blockchain transaction comprises a commitment of the encrypted data; and supplying the encrypted data to the computing resource for use by the computing environment.

2. The method of claim 1, wherein the computing resource comprises the first blockchain transaction and / or a reference thereto, and wherein the method comprises using the first blockchain transaction and / or the reference thereto to obtain the encryption key.

3. The method of claim 1 or claim 2, wherein the first blockchain transaction is locked to a trusted party, and wherein the blockchain comprises a third blockchain transaction that references the first blockchain transaction and is signed by the trusted party, and wherein the method comprises verifying that the blockchain comprises the third blockchain transaction as a condition of using the computing environment.

4. The method of claim 3, wherein the computing resource comprises the third blockchain transaction and / or a reference thereto, and wherein the method comprises using the third blockchain transaction and / or the reference thereto to verify that the blockchain comprises the third blockchain transaction.

5. The method of any preceding claim, wherein using the computing environment comprises initializing and / or deploying data to the computing environment.

6. A computer-implemented method of operating a computing environment of a computing resource, wherein a blockchain comprises a first blockchain transaction comprising an encryption key, wherein the computing resource has stored thereon a decryption key corresponding to the encryption key, and wherein the method comprises: receiving encrypted data as an input from a user of the computing resource; obtaining, from a second blockchain transaction, a commitment of the encrypted data; generating a candidate commitment of the encrypted data, verifying that the candidate commitment corresponds to the obtained commitment; and decrypting the encrypted data using the decryption key when the candidate commitment of the encrypted data corresponds to the obtained commitment.

7. The method of claim 6, wherein the computing resource comprises one or more of: the first blockchain transaction, a reference to the first blockchain transaction, and a proof that the first blockchain transaction is stored on the blockchain.

8. The method of claim 6 or claim 7, wherein the first blockchain transaction is locked to a trusted party, and wherein the blockchain comprises a third blockchain transaction that references the first blockchain transaction and is signed by the trusted party, and wherein the computing resource comprises one or more of: the third blockchain transaction, a reference to the third blockchain transaction, and a proof that the third blockchain transaction is stored on the blockchain.

9. The method of any preceding claim, wherein the data comprises one or more of: an operating system, one or more applications and one or more files.

10. The method of claim 9 when dependent on claim 6, comprising loading and / or executing the data.

11. The method of any preceding claim, wherein the computing environment comprises a virtual computing requirement.

12. The method of any preceding claim, wherein the decryption key is stored on a processor of the computing resource or implemented by a circuit of the computing resource.

13. Computer equipment comprising: memory comprising one or more memory units; and processing apparatus comprising one or more processing units, wherein the memory stores code arranged to run on the processing apparatus, the code being configured so as when on the processing apparatus to perform the method of any of claims 1 to 13.

14. A computer program embodied on computer-readable storage and configured so as, when run on one or more processors, to perform the method of any of claims 1 to 13.

Images