{'fraction_non_alphanumeric': 0.03498652829058976, 'fraction_numerical': 0.005907594052489772, 'mean_word_length': 4.529242992716839, 'pattern_counts': {'":': 0, '<': 0, '<?xml version=': 0, '>': 0, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 2, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
QEnclave -- A practical solution for secure quantum cloud computing

We introduce a secure hardware device named a QEnclave that can secure the remote execution of quantum operations while only using classical controls. This device extends to quantum computing the classical concept of a secure enclave which isolates a computation from its environment to provide privacy and tamper-resistance. Remarkably, our QEnclave only performs single-qubit rotations, but can nevertheless be used to secure an arbitrary quantum computation even if the qubit source is controlled by an adversary. More precisely, attaching a QEnclave to a quantum computer, a remote client controlling the QEnclave can securely delegate its computation to the server solely using classical communication. We investigate the security of our QEnclave by modeling it as an ideal functionality named Remote State Rotation. We show that this resource, similar to previously introduced functionality of remote state preparation, allows blind delegated quantum computing with perfect security. Our proof relies on standard tools from delegated quantum computing. Working in the Abstract Cryptography framework, we show a construction of remote state preparation from remote state rotation preserving the security. An immediate consequence is the weakening of the requirements for blind delegated computation. While previous delegated protocols were relying on a client that can either generate or measure quantum states, we show that this same functionality can be achieved with a client that only transforms quantum states without generating or measuring them.


Introduction
Quantum computing is an emerging field of computation technology that promises to produce faster algorithms for solving computational problems [52,2]. Many government agencies and large companies like Google, IBM and Amazon are putting efforts on building arXiv:2109.02952v3 [quant-ph] 21 Sep 2021 a programmable quantum device that can outperform existing classical computers [6,33]. Some of them have already managed to develop small-scale quantum computers and provide cloud services allowing users to delegate their quantum computations [4,20,32,54].
Although this form of delegated quantum computation (DQC) services are very useful in practice, for education and research for example, running algorithms on untrusted quantum hardware raises important privacy issues. A major challenge of DQC is to ensure the privacy of the client's computation who doesn't have any quantum computation capability. In this paper, we address this issue by introducing a new quantum hardware assumption, namely quantum trusted execution environment (Quantum TEE) and showing how it can be used to implement privacy-preserving DQC, even with fully classical client.
In the classical world, a Trusted Execution Environment (TEE) is a secure area that executes code in an isolated environment and prevents malicious access from the rest of the device. The standardization was initially proposed by Global Platform to ensure the protection of stored application and data [27]. In practice, a TEE is designed to isolate the trusted execution of software layer from the untrusted area, also called rich execution environment (REE). It is based on a combination of hardware architecture and cryptographic protection. It allows to control the flow of information between applications in multiple environments with different root-of-trust. In more advanced scenarios, TEEs have been used for blockchain [36], privacy-preserving machine learning [30,43], or cloud services [10,51].
The goal of delegated computation is to allow a computationally bounded client to assign some computation to a computationally powerful but untrusted server while maintaining the privacy of data. This is relevant especially in the case of high performance computing in the cloud. A similar question arises with universal quantum computers becoming available in the near future. Even though we have recently been witnessing spectacular developments, it is expected that scalable quantum computers will remain hard to build and expensive for a long time. It is very likely that they will only be accessible remotely, exactly like supercomputers are nowadays. In this context, DQC enables a client with limited quantum capabilities to delegate a computation to a quantum server while maintaining the correctness and privacy of the computation.
The first efficient universal protocol for secure (blind) delegated quantum computation was introduced in [13] see recent reviews for other similar protocols [23,25]. However, these protocols all assume a quantum channel between the client and the server, which for some quantum hardware platform such as superconducting or cold atom qubits, might prove to be impractical at least in near future. For this reason, the construction of efficient, private and secure DQC protocol using only classical communication will be extremely important. Given the impossibility result on achieving informationally secure delegated computing using only classical communication [1] other assumption has to be considered. Recent breakthroughs based on post-quantum secure trapdoor one-way functions, paved the way for developing entirely new approaches towards fully-classical client protocols for emerging quantum servers [38,39,17]. Nevertheless, the challenge for these protocols is the huge server overhead. This is due to the fact that one has to ensure the quantum circuit implementing the required masking protocol based on the learning with error (LWE) encryption [48] remains unhackable both classically and quantumly. That leads to current proposals that require order of 1000 server qubits for masking a single gate of the target client computation.
In our work we explore a new approach based on hardware security assumption to derive practical secure DQC protocol with fully classical client setting. We explore the modular approach introduced in [21] that defines the Remote State Preparation (RSP) as the main building blocks for DQC protocol. It worth noting that in [26] an RSP protocol was also proposed using a classical channel between client and server but assuming a new resource called Measurement Buffer, which externalize a quantum state measurement from the server side. However, such a resource can not be realized classically as it was proven in [7]. Indeed it is known that it is impossible to construct a composable secure RSP protocol using only a classical channel between the client and the server without any hardware assumption, which confirms our approach to be the only way forward to construct an efficient DQC protocol with a classical client from the RSP module. One could also take a different approach to define a hardware security module that implement securely the measurement buffer (on the server side) and then use the protocol introduced in [26]. However there are two fall-backs for such protocol. First, it is desired that the hardware assumption should be as simple as possible and as we discuss later securing the measuring device leads to an unnecessary complicated architecture. A more severe issues however is that, as mentioned before due to the usage of an LWE-based encryption, the protocol of [26] requires a huge overhead on the server side.
With these constraints in mind, we introduce our Quantum TEE, called QEnclave, as a practical way to make DQC secure with a classical client. Remarkably only one call to our simple hardware module is enough to create one remote blind qubit. Up to our knowledge this is the first time that a realistic construction for a quantum trusted execution environment has been proposed. Our QEnclave only transforms single qubit states without generating or measuring them. Nevertheless, it can be composed with the universal blind quantum computing protocol of [13] to achieve secure DQC with perfect blindness (assuming minimal hardware assumption) whiles using only classical communication between the client and the server with optimal server overhead. Surprisingly, the blindness of the protocol holds even if the server controls the qubit source.
The contributions of our work are twofold. The first one is the introduction of a new ideal functionality named Remote State Rotation (RSR). The only operation performed by this functionality is to rotate a quantum state with arbitrary angles chosen uniformly at random from a fixed set. In practice, RSR reduces the client's quantum technology requirements compare to previously proposed RSP resources usually requiring the client generating or measuring quantum states. This makes this functionality of independent interest for the study of practical quantum cryptographic protocols, specially that we show how to build RSP from RSR in the Abstract Cryptography framework [41]. In combination with previous results on the security of RSP, it implies that a classical client, using RSR, can achieve DQC with perfect blindness solely relying on classical communication even if the source that generates the state is compromised. However our protocol as it stands does not admit verifiability, and we leave it as an open question whether RSR could also provide verifiable DQC without adding any extra assumptions.
Our second contribution consists in a proposal to build our QEnclave using a standard classical TEE, together with a protection of the flow between TEE and the quantum apparatus which implements the single-qubit rotations. While such a protection might appear like a strong assumption, it is in practice similar to the requirements for standard classical hardware security modules. For example, the FIPS-140 requirements for cryptographic modules grade the security depending on the guarantees they provide against tampering the hardware. For completeness, we also give a concrete practical classical protocol for the establishment of a post-quantum secure channel between the client and the TEE. Since the TEE is assumed to guarantee the secure processing of the classical secret decryption, it overall leads to a proposed implementation of a blind DQC protocol using a TEE in our QEnclave.
The rest of the paper is organized as follows: in Section 2, we recall the basic concepts and notations used in our work; in Section 3, we introduce the functionalities for RSP used in our construction and discuss their composable security in the abstract cryptography framework; in Section 4, we propose a new ideal functionality that models the QEnclave called remote sate rotation, show how to use it to build a blind DQC protocol and prove the security of the construction; in section 5, we propose a complete specification of the QEnclave based on the use of a classical TEE, with a protocol to construct a blind DQC protocol with QEnclave. Finally we conclude our paper with a discussion in Section 6. In particular, we discuss how our QEnclave could lead to a verifiable UBQC protocol [24], and other potential applications of our QEnclave.

Trusted Execution Environment
A TEE is a tamper-resistant processing environment that runs on a kernel [49] separated from its environment, named the rich execution environment (REE). It guarantees the authenticity of the executed code, the integrity of the run-time states, and the confidentiality of its code and data. It can also provide remote attestations of its trustworthiness to third parties. A TEE should resist against all software attacks as well as physical attacks performed on the main memory of the system. On the one hand, the OS and most of the applications are executed in the REE and as such might be easily tampered by virus, trojans, malware, tools of rooting/reflashing, keystrokes logging, etc. On the other hand, running applications in the TEE is less efficient than on the REE.
There are many ways to implement a TEE in practice [28]. The smartcards we use daily are a prototype of TEE with the smartcard itself being the trusted area while the peripherals (e.g., POS terminal) do not need to be trusted [35]. Smartcards are completely isolated, providing high levels of trust, but are also very limited due to their size. A second type of familiar TEE is the trusted platform module (TPM) [29]. A TPM is a co-processor specialized for cryptograhic tasks, including key generation, encryption, decryption, etc. The trusted components should include isolated engines for cryptography (e.g., SHA-1 engine, RSA engine, HMAC engine, etc.) and a random number generator. In addition, a TPM includes an isolated execution engine, platform configuration registers and persistent memory for identification.
Apart from smartcards and TPMs, there exists another type of TEE that consists in the design of processors with different execution environments and allowing intercommunication among environments with flow control (Figure 1). Intel SGX, for example, allows users to instantiate a secure enclave to protect an application [34]. The code from outside the enclave cannot alter the application inside the enclave, even if executed with high privileges. Intel SGX also includes security measures such as remote attestation, crypto-based memory protection, sealing, etc. Another example is ARM TrustZone, which is implemented in most ARM processors nowadays. The system bus with ARM TrustZone uses an extended protected NS bit to distinguish the instructions of the trusted area from the untrusted area [5]. ARM TrustedZone can also protect specific peripherals by hiding them from unstruted applications.
We introduce a feature that is important for our discussion: remote attestation. Remote attestation is a mechanism that allows proving the TEE integrity of a prover to a verifier. It provides an attestation signed by the TEE manufacturer. For instance, consider a client (verifier) aiming to delegate some application to the TEE of the server (prover). The client can challenge the server to provide him with an attestation signed specifically by the TEE manufacturer and allowing the establishment of an authenticated channel between the client and the TEE, before running a trusted application. The identity and hash of the TEE is a proof of integrity, signed with a hard-coded built-in private key [50]. The proof sent back by the server allows the client to verify the authenticity of the attestation message. Once the attestation is verified, the trusted application runs securely inside the TEE. It also allows anonymous attestation, where a user can verifies an attestation is generated by a valid enclave without identifying which one. The remote attested execution schemes are given in previous works [9,44] to capture the properties of enclave-like secure We exploit the abstraction of anonymous attested execution (See Functionality 1) as introduced in [44] to formalize cryptographically the secure processors. G att is parameterized by a signature scheme Σ and a register reg that captures all parties P that equip with a secure enclave. For the activation points of G att , the starred ones are reentrant activation points, otherwise it can be only executed once. In registry stage, the secure processor enables a distribution of manufacturer public key of key pair (mpk, msk) to P upon query. For enclave operations, the activation point install denotes a new installation of enclave application with a program prog from P, it generates an identifier eid to P for identifying the enclave instance; the activation point resume enables the execution of prog upon the input inp by G att . G att then signs the output outp to be attested with msk using Σ. The attestation σ is returned to P for verification.

Quantum Tools
We introduce the basic concepts required here. Interested readers can refer to standard textbooks on this topic [42]. In quantum computation, a quantum bit or (qubit) is a quantum system that is the analogue of a classical bit. It lives in a two-dimensional Hilbert space H. In particular, the qubits of the computational basis of H are denoted: More generally, the state of an arbitrary qubit is described as |ψ = α |0 + β |1 where |α| 2 +|β| 2 = 1. An alternative basis called the Hadamard basis consists in the following qubits: We will in particular make use of the transform Z(θ) that maps |± to |± θ = 1 A quantum state can also be described by its density matrix ρ = |ψ ψ|. Density matrices also capture mixed states of the form ρ = Σ s p s |ψ s ψ s | where p s is a probability over pure states |ψ s ψ s |.
For multiple qubit systems, two states |v and |w in two Hilbert spaces V and W with dimension n and m can be assembled as |v ⊗ |w , or simply |vw , which lives in V ⊗ W , a n · m dimensional Hilbert space. A quantum system |u is called separable if it can be written |v ⊗ |w . A multiple qubit system that is not separable is entangled. For example, |φ = 1 In particular, if B = {|u , |v } is a basis of qubit states, then the measurement defined by the operators {|u u| , |v v|} is usually referred to as a projection onto basis B. The transformation of a quantum state can be described by a unitary operator U . These transforms preserve the norm of a vector and hence map a quantum state onto another quantum state.
We use letters X/Y /Z to denote some particular unitary operators called Pauli operators. For single-qubit, the Pauli operators, as well as identity I, are given in the following matrices: The other operators relevant here are the Hadamard (H) gate, which maps the computational basis to the Hadamard basis, and the control-U (CU ) gates, which uses two qubits as input: a control qubit and target qubit. It operates U on the target qubit when the control qubit is set to |1 .
Finally, we give a very brief introduction to a model of quantum computation called measurement-based quantum computation (MBQC), originally proposed by Raussendorf and Briegel [46,47,12]. The DQC protocols discussed in our work are well described in the MBQC computation model. In this model, a computation is described by a series of commands involving single-qubits or two qubits: preparations of single-qubits in the state |+ ; entanglements of two qubits with the CZ operator; measurements on singlequbits with basis |+ θ and |− θ with measurement results (signals) 0 and 1 respectively, corrections on single-qubits with operators X, Z depending on signals [19].
The entangled state used for computation in MBQC is called a graph state. An MBQC computation is a sequence of commands on a graph state that includes a subset of input qubits and output qubits. In the family of graph state, cluster states introduced in [47] and brickwork states introduced in [13] are proved to be universal for MBQC.

Abstract Cryptography
The Abstract cryptography (AC, also called Constructive Cryptography) framework was introduced in [41] by Maurer and Renner for getting composable security properties. Compared to UC framework [15,16] that is built in bottom-up approach, AC framework is formalized with top-down approach, where it considers the highest level of abstraction first, then the lower levels to instantiate particular objects of protocol. UC can be realized by instantiating the abstraction of AC framework. However, it is not our goal to compare different approaches in this paper, but to show the idea behind composable security. Both these frameworks provide a method to establish the comparison of similarity between different functionalities, and further define the composable security of these functionalities.
In AC framework, the functionality is called a resource. A resource has some interfaces I corresponding to the parties that the resource interacts with. Since we focus on two-party communication between the client and the server as our protocol, our resources have two interfaces I = {A, B} corresponding to the client and the server.
A protocol π = {π i } i∈I is a set of converters indexed by I. A converter has two interfaces -an inside interface and an outside interface, where the inside interface is connected to the resource and the outside interface is connected to the outside world. Intuitively, a dishonest party in a protocol has more access to the functionalities of a resource than an honest one. We denote by ⊥ a filter used to enforce the honest behaviour of a party. In this case, the functionalities accessed by the party are so-called the filtered functionalities.
An important concept of the AC framework is the distinguisher (D), which measures the distance between two resources. For instance, consider a resource R and a protocol π A , π B , and denote π A Rπ B their composition. We say that two resources R, S are ε-closed, or R ≈ ε S if there is no distinguisher D that can distinguish between R and S with advantage greater that ε. If ε is negligible, we say that we can construct S from R with the protocol π A , π B . Furthermore, if the resource S is secure, we say that the resource R securely constructs S. The following definition formally defines this. [41]) Given two resource R and S, we say that a protocol π = {π A , π B } constructs S from R within ε if two following properties are satisfied:

Definition 1. (See
• Correctness: • Security: if there exists a converter, where it is called a simulator σ such that We denote this:

Delegated Quantum Computing
In a client-server delegated quantum computation (DQC) protocol, a client with limited computational power asks a server to run a quantum computation, whose result is then returned to the client. There exist two types of DQC protocols. The first ones are prepareand-send protocols, in which the client prepares a certain numbers of quantum states and send them to the server. The second class is receive-and-measurement protocols [31], where the client receives single-qubits from the server and measures them. When delegating its computation, a client expects some security guarantees. The first one is blindness, which means that the server does not learn anything about the computation, input and output. The second one is verifiability, which means that a client can verify the correctness of the the result returned by the server.

Ideal Functionalities of DQC
The following definition from [22] specifies an ideal resource for two-party delegated quantum computing with blindness. Figure 2(a)) For a given unitary U, the ideal resource for DQC S blind provides both correctness and blindness. It takes an input ψ A at the client's interface, and on the server's interface, a filtered control bit c (set by default to 0) and a pair that consists in a state ψ B and a description of a CPTP map E 1 . It outputs the allowed leak ψ A at the server's interface. If c = 0, it outputs the correct result U(ψ A ) at the client's interface; otherwise it outputs the server's choice, E(ψ AB )

Definition 2. (See
The blindness means there is at most ψ A of information leaked to the server during the interactions. The other property of DQC that we are interested in is verifiability. This means that if a dishonest server returns an incorrect result, the probability that the client accepts it is negligible. The following definition formalizes the definition of verifiable DQC. Figure 2(b)) For a given unitary U, the ideal resource DQC resource S blind verif provides correctness, blindness and verifiability. It takes an input ψ A at the client's interface, and a filtered control bits c (set by default to 0) at the server's interface. It outputs the allowed leak ψ A at the server's interface. If c = 0, it simply outputs U(ψ A ) at the client's interface. If c = 1, it outputs an error message at the client's interface. Figure 2: DQC ideal resources with blindness (a) and DQC ideal resources with both blindness and verifiability (b)

Universal Blind Quantum Computation
Universal delegated quantum computation (UBQC), originally introduced in [13], is a quantum computation model whose operations can easily be described in the MBQC model. At the start of a UBQC protocol, the client produces a sequence of single-qubit states of the form |+ θ with θ chosen uniformly at random from {0, π 4 , . . . 7π 4 }. Here and throughout this paper, we use {Z π 4 } to denote this set of angles. After receiving N such qubits from the client through a quantum channel, the server entangles them to build a brickwork state.
The computational stage is interactive, and uses only classical communication. During this stage, the client continuously sends the measurement angle for each qubit to the server, who returns the measurement result to the client. The client then computes the following measurement angle. At the end of the computation, the server returns the quantum outputs to the client. Dunjko, Fitzsimons, Portmann and Renner [22] showed the security of a UBQC protocol providing perfect blindness in the AC framework.
For completeness, we provide a general description of UBQC in Protocol 1. More details can be found in [13].

Client's preparation:
(a) The client prepares a unitary map U described as a pattern on a brickwork state. G n×m .

Server's preparation:
(a) The server creates n qubits in the |+ state to use as the final output layer.
(b) The server creates an entangled state using both the qubits received from the client and the output layer qubits by applying ctrl-Z gates between the qubits in order to create a brickwork state G n×m+1 .

Interactions and Measurement:
For each column x = 1, . . . , m For each row y = 1, . . . , n (a) The client computes the updated measurement angle φ x,y , which depends on previous measurement outcomes reported by the server, and some random choices r x,y made by the client to hide the measurement angles.
(c) The client sends δ x,y to the server, who performs a measurement in the basis { + δx,y , − δx,y }.

Remote State Preparation for DQC
In this section, we review the works on ideal functionalities RSP and their security in the AC framework. Using remote state preparation (RSP) as an ideal functionality allows to replace the quantum channel between a client and a server by a classical one.

Remote State Preparation for Blindness
The UBQC protocol introduced above requires the server to get a number of states of the form |+ θ + θ |. These states are then entangled to construct a brickwork state. Dunjko and Kashefi [21] have introduced the concept of weak correlations, which is a necessary and sufficient condition on the set of states sent by the client to obtain the blindness of the protocol. The following theorem formally introduces this notion.

Theorem 1. (See [21]) The UBQC protocol (Protocol 1) with classical input and computation of size N , where the client's preparation stage is replaced by the preparation of N states of the form σ
is blind if and only if the following conditions hold: 1. ρ θ is a normalized quantum state, for all θ, 3. |Θ| is the size of the set Θ, typically 8.
The ideal resource random RSP for blindness is specified as follows. If the server is honest, the functionality outputs |+ θ + θ | to the server. If not, it takes as input from the server the classical description of a quantum state [ρ θ ] and outputs the corresponding quantum state ρ θ to the server. In both cases, the client receives the classical angle θ. This is formalized in the following definition, and depicted in Figure 3(a)) Definition 4. The ideal resource random remote state preparation for blindness, denoted RSP B , has two interfaces, A to the client and B to the server. The resource chooses an angle of rotation θ uniformly at random from the set Z π 4 . There is a filtered functionality at interface B and a classical bit c. If c = 0, the server is honest and the resource outputs a state |+ θ + θ | on B. If c = 1, the ideal functionality takes as input the set {(θ, [ρ θ ])} θ from the server.
If the states provided by the server do not satisfy the conditions from Theorem 1, RSP B ignores the input and waits for a new valid set. Once the set is received, the functionality outputs ρ θ at B. In both case, RSP B outputs the angle θ at the client's interface.
Dunjko and Kashefi also introduced another resource that is better suited for our purpose. It is a variant of RSP B which allows more operations for a dishonest server. This resources is depicted in Figure 3(b)).

Definition 5.
The ideal resource measurement-based remote blind state preparation (M RSP B ) has two interfaces A and B. The resource chooses an angle of rotation θ uniformly at random from the set Z π 4 . There is a filtered functionality at interface B and a classical bit c. If c = 0, the server is honest and the resource outputs a state |+ θ + θ | on B. If c = 1, the ideal functionality takes as input the descriptions of eight positive operators {Π θ }, such that for all θ in Z π 4 , Π θ + Π θ+π = I. In addition, it accepts an arbitrary quantum state ρ of the same dimension as the operator Π θ .
If the server's input does not satisfy the properties of Theorem 1, M RSP B ignores it and waits for a new valid set. Once a valid input is received, M RSP B applies the measurement Π θ , Π θ+π corresponding to the chosen angle θ to ρ. Finally, M RSP B outputs the measurement result θ , whose value is either θ or θ + π, at the client's interface and the post-measurement state ρ θ at the server's interface. The connection between these two ideal resources follows from the construction of M RSP B from RSP B , which preservers both correctness and security. Consider a trivial protocol π = (π A , π B ) in which π A does nothing and π B fixes the classical bit to c = 0. Following the conditions of Definition 1, it was shown that: The inputs and outputs of these two ideal resources are trivially equivalent in the honest case, which implies the correctness. To prove the security, the authors provided a simulator σ B and showed that the outputs of A and B are the same actions for π A RSP B and M RSP B σ B . Moreover, the authors show that RSP B and M RSP B can be used for UBQC. This leads to a perfect blind DQC without a quantum channel between the client and the server. In this context, perfect blindness means that the protocol leaks nothing more than what is strictly required (such as, for example, the size of the computation). The formal definition can be found in [21].
The following theorem formalizes this argument for M RSP B . Theorem 2. [21] The UBQC protocol in which the client has access to the ideal functionality M RSP B rather than to a quantum channel and a random generator of the |+ θ states, exactly constructs DQC with perfect blindness.

Limitations of RSP with only Classical Channel
While RSP B and M RSP B remove the need for a quantum communication channel between the client and the server, we have not discussed how these resources can be implemented. A fully-classical blind DQC protocol could be obtained for example by implementing one of the two resources with a classical communication channel. This idea was investigated by [7], who introduced the following definition.

Definition 6.
An ideal resource S is said to be ε-classical-realizable if it is realizable from a classical channel C, i.e. if there exists a protocol π = (π A , π B ) between two parties interacting classically such that: In order to prove the composable security of ε-classical-realizable RSP, we need to show that no unbounded adversary can learn information on θ by accessing only the right interface B. Unfortunately, the authors show that there is no describable remote state preparation protocol with composable security. In this context, describable means extracting a classical approximate description of a quantum state [ρ] by accessing the state ρ on the interface B. Since a protocol using only classical communication is obviously describable, it follows that there is no classical-realizable RSP with composable security. This in turn implies that UBQC with classical-realizable RSP cannot be composable secure.
As a result, it is necessary to make additional assumptions to remove the quantum interaction between the client and the server. While [7] considers additional computational assumption to bound the adversary's power, we take a different approach, introducing additional hardware assumptions, such as tamper-proof quantum operations, in order to get a secure DQC protocol with blindness using only classical communication.

QEnclave as an Ideal Functionality: Remote State Rotation
In this section, we introduce an alternative to RSP named remote state rotation (RSR), and analyze its composable security in the AC framework. Compared to the other ideal functionalities, RSR is even weaker. While RSP generates quantum states by itself, RSR only allows rotations of single-qubit states generated by the server. Figure 4) The ideal resource named remote state rotation for blindness (RSR B ) has two interfaces A and B. After receiving a single-qubit state ρ in from interface B, it performs a rotation Z(θ) with θ chosen uniformly at random from the set Z π 4 . It then outputs (ρ out ) at the server's interface and the angle θ at the client's interface. Similar to RSP B and M RSP B , this functionality fully removes any quantum capability for the client. In particular, using RSR B removes the assumption for a quantum communication channel between the client and the server.

Definition 7. (See
We further define a two party protocol π = (π A , π B ) to prepare quantum states with RSR B in which π A only receives the angle θ from the interface A of RSR B , and π B takes as input a classical bit c and a quantum state from the server.
If c = 0, the server is honest and π B accepts |+ +| as input from the server. If c = 1, the dishonest server prepares an arbitrary quantum state ρ = Ω(|+ +| ⊗ ρ aux )Ω † . Here, Ω is an arbitrary unitary that represents the server's deviation on the quantum source and ρ aux is an auxiliary state chosen by the server.
After tracing out the auxiliary state of ρ, we get ρ in , the input to RSR B which is a single-qubit chosen by the dishonest server. In particular, this state can be entangled with the server's auxiliary system.
We show a construction of DQC with RSR B that achieves perfect blindness in two steps. First, In Lemma 1, we prove that the outcome of RSR B satisfies the conditions for blindness of Theorem 1. Then, in Theorems 3 and 4, we show the security of DQC with blindness obtained from RSR B .

Lemma 1.
For any quantum states ρ in as used as input of RSR B , the outcome system of the client and the server σ AB satisfies the conditions of weak correlation of UBQC.
Proof. For simplicity, we first assume that ρ in is not entangled with the server's auxiliary system. Without loss of generality, we get ρ in = |α| 2 |0 0| + αβ * |0 1| + α * β |1 0| + |β| 2 |1 1|. In this case, the output of RSR B ρ θ is For any θ in the set Z π 4 , we thus have Since this is independent of θ, the state satisfies the weak correlation conditions. In the general case, ρ in can be entangled with the server's auxiliary system. we where |ψ 0 and |ψ 1 are states of the server's auxiliary system.
After the rotation of RSR B on the first subsystem, we get the following entangled state: For any θ in the set Z π 4 , we have Since the result ρ θ + ρ θ+π is again, independent of θ, the joint state of the client and the server also satisfy the weak correlation conditions for any state σ AB .
We now prove the security of RSR B with the UBQC protocol. We prove it by showing that the resource M RSP B introduced in Definition 5 can be constructed from RSR B . Since M RSP B can be composed with a UBQC protocol to get DQC with perfect blindness, so does RSR B Theorem 3. The protocol π = (π A , π B ) introduced above with ideal resource RSR B constructs the ideal resource M RSP B .
Proof. We show that both the correctness and the security condition are satisfied. More precisely, proving the security amounts to showing that a distinguisher cannot distinguish M RSP B from the protocol. This translates into the following equations, for a simulator σ B and the protocol π = (π A , π B ) with RSR B . and For the correctness, when the server is honest, the ideal resources RSR B and M RSP B both output an angle θ at interface A and its corresponding quantum state |+ θ + θ | at interface B. Equation 11 is thus immediately satisfied.
For the security, we introduce the simulator σ B , defined as follows. It accepts and sends c = 1 to M RSP B , as well as a set of projectors {Π θ }, where Π θ = |+ −θ + −θ |. After receiving a quantum system ρ from the server, the simulator takes the input ρ in of the same dimension as {Π θ }, and generates a qubit |0 . A CNOT gate is applied to these two qubits, where ρ in is used as the control qubit (|φ 1 ) and |0 the target bit (|φ 2 ). This gives the simulator state (ρ σ B = |φ 12 φ 12 |). Finally, σ B " sends the first qubit |φ 1 back as the outcome state to the server, whereas the second qubit, |φ 2 , is sent to the resource M RSP B .
We show that the outcome is similar to the expression obtained in Lemma 1. Again, consider first the case where ρ in is not entangled with the server's auxiliary system. We then obtain the following expression for φ 12 after the operation of M RSP B : We obtain the outcome of simulator by tracing out the second quantum subsystem.
The outcome quantum state is exactly the same as result as the outcome of RSR B in Eq. (7). Since a similar calculation holds for the projector Π θ+π , the outcome joint state of the client and the server of M RSP B is exactly the same as RSR B . Consider now an arbitrary entangled state α |0 |ψ 0 + β |1 |ψ 1 . The simulator σ B takes the first single-qubit subsystem as control qubit, and performs the same operation as in the previous case. After the operation of M RSP B , we have: Then, after tracing out the second qubit, we obtain: Again, The output quantum state is exactly equals to ρ θ specified in Eq. (9). In consequence, the resource RSR B is perfectly indistinguishable with the resource M RSP B , that is, Equations 11 and 12 are satisfied with = 0.
Finally, combining the fact that we can perfectly construct M RSP B from RSR B with Theorem 2, we obtain the following result.

Specification of the QEnclave
In this section, we give a complete specification of the QEnclave, based on the use of a secure processor. The QEnclave implements the ideal functionality RSR, and uses the enclave and its hardware assumption to ensure the security of the construction. Moreover, it communicates with the client classically and returns a quantum state to the server, as shown in Figure 5. For convenience, we assume that the client can choose the input angles uniformly at random, rather than letting the QEnclave choose them (as in RSR B ). This transformation does not change the security since in our setup, both the client and QEnclave are expected to be honest.

Figure 5: Specification of QEnclave
To start with, we demonstrate how attested execution functionality G att securely constructs outsourcing computation protocol under composition. By considering a simple 2-party outsourcing computation F outsrc [C, S] with target function y = f (x), where the client C outsources f and x with encoding and finally obtains the output y while the server S or any other adversary only knows the size of inputs and outputs (|f + x| ,|y|) during the computation process. A G att -hybrid protocol Prot outsrc (Protocol 3) is given in [44] and proven to UC-realized F outsrc when C is honest and S is a static adversary (See Appendix A). The probabilistic polynomial time indistinguishability of ideal-world and real-world executions is reduced to the Decisional Diffie-Hellman (DDH) assumption for secure key exchange [40] and authenticated encryption. The indistinguishability is also equivalent under AC framework without instantiating a DDH-based secure key exchange protocol but a random secret key shared between C and G att . Furthermore, since the composable security of RSR, the construction of QEnclave with secure processor's functionality G att is theoretically feasible.
In practice, a quantum-safe digital signature scheme [3,14] is necessary for the remote attestation scheme since we assume that the quantum server is potentially malicious. Meanwhile, more practical remote attestation schemes provide post-quantum security [37].
The confidentiality consists in hiding the rotation angles chosen by the client. The requirement of using a quantum-safe encryption makes symmetric schemes more appropriate than asymmetric ones for this task. Apart from a key exchange protocol based on DDH, there are also other key encapsulation mechanism (KEM) schemes [8,11,53] theoretically feasible to share a secret key between the client and the QEnclave.
Once the secure channel is established between the client and QEnclave, the client can send the encrypted rotation angles to the QEnclave. QEnclave decrypts them and encodes the initial quantum state from the external source using the classical angles chosen by the client. At this stage, we assume that the trusted area which includes the secure processor also includes the quantum apparatus and protects the interactions between the two from external eavesdropping. This leads to a remote state preparation protocol for delegated quantum computation with blindness using the QEnclave and classical communication between the client and the server. We summarize all the Steps in Protocol 2.
Protocol 2 QEnclave-based RSP Protocol for Blindness with prog rsr G att -enabled QEnclave Program prog rsr : On input ("keyex", g a ) : let b ∈ Z p , store sk := (g a ) b ; return (g a , g b ) On input* ("compute", ct): let (f, x) := AE.Dec sk (ct) assert decryption success, ct not seen before let θ 0 . . . θ n := f (x) and return ct out := AE.Enc sk (θ 0 . . . θ n ), while θ 0 . . . θ n is applied to quantum states from external quantum source: On receive ("keyex", g a ) from C: let eid := G att .install(sid, prog rsr ) let ((g a , g b ), σ) := G att .resume(eid, ("keyex", g a )) and send (eid, g b , σ) to C On receive* ("compute", ct) from C: let (ct out , σ) := G att .resume(eid, ("compute", ct) and send ct out to C Client C: On initialize: let a ∈ Z p ,mpk := G att .getpk() send ("keyex", g a ) to S, await (eid, g b , σ) from S assert Σ.Vf mpk ((sid, eid, Prot rsr , (g a , g b )), σ) let sk := (g b ) a On receive* ("compute", f, x): let ct := AE.Enc sk (f, x) and send ("compute", ct) to S, await ct out let y := AE.Dec sk (ct out ) and assert decryption success and ct out not seen before output y Notice that this protocol assumes a reliable quantum apparatus inside the trusted area of QEnclave for transforming the incoming quantum state. Moreover, we assume that the communication between the secure processor and the quantum apparatus remains hidden to the server. While this assumption may seem strong, the idea of sealing hardware components into a tamper-proof box is already well spread in the world of hardware security. In particular, the FIPS-140 certification for Hardware Security Modules (HSM) includes criteria for physical tamper-evidence (level 2 certification), physical tamper-resistance (level 3) or even robustness against environmental attacks (level 4).
While our proposal of QEnclave implements the RSR ideal functionality, we have left aside a number of potential attacks that stem from the physical realization. Implicitly, we assume that QEnclave is fabricated correctly by a certified manufacturer, which ensures that an adversary cannot subvert the device before it was installed on the server. Besides, we also exclude some hardware-dependent attacks in our work e.g., specific side-channel attacks on specific enclave products. Finally, we have not yet considered the possibility of counterfeiting the QEnclave.

Conclusion and Discussion
We introduced a new functionality called Remote State Rotation, that can be used to achieve secure delegated quantum computing in a practical way compatible with currently available quantum hardware platform in the cloud. Moreover, we have proposed a realistic hardware assumption of trustworthy quantum operations with classical secrets to circumvent the impossibility results of [1,7] of implementing a composable RSR with classical channel only. Our proposed ideal functionality with simple rotations lowers the minimal requirement on the operations of the client while keeping minimal overhead on the server side too. Finally, we gave a full specification of QEnclave that implements the RSR functionality using a secure processor to control the quantum apparatus required for the blindness of delegated quantum computation.
Beside privacy, another desirable property of delegated quantum computing is verifiability. In general, a DQC protocol is verifiable if the client can verify the result from the server (See Definition 3). A verifiable universal blind quantum computing protocol was proposed in [24] where the client could inserts in the target computation a set of trap qubits that are isolated from the computation. This construction ensures that the measurement results of trap qubits is always deterministic and can be used as a test of the correctness of the entire computation as they are known only by the client.
Adapting the same approach for RSR is not trivial as a malicious server controlling the source, is now enabled to perform correlated attack before and after the call to RSR. Hence the proof technique from [24] does not directly apply. In principle, such deviations can be chosen to affect certain types of computation qubits but leave trap qubits unchanged, then change the execution of the protocol but remain unnoticed by the client at the same time, which means the protocol is not verifiable. However there exist many other approaches to verifiability such as the ones based on self-testing that might prove more suitable for RSR. We leave this question open for the future work. It is worth mentioning that one could trivially add a trusted measurement device or a trusted source to the construction of the QEnclave to remove the possibility of such correlated attack implementing directly the RSP resource instead. This will define directly an efficient classical client verifiable delegated computing protocol with extended hardware assumption addressing the current challenge of demonstrating certifiable quantum supremacy. However we believe keeping the QEnclave construction as simple as possible is a more interesting option to be explored.
Finally one can explore usability of QEnclave for any quantum protocols that can be implemented through RSR. In particular, we think it can be relevant to use it to for a practical implementation of semi-quantum money schemes [45] that unlike standard quantum money protocol [55] considers that the bank mints the quantum states used as banknotes on the user's side and verifies their validity using only classical interactions. This matches our definition of remote state preparation, once the problem of verifiability is also addressed. Then using an QEnclave, a bank might be able to authenticate the banknote by remotely performing quantum operations but using only classical communication.

A G att -hybrid Protocol with prog outsrc
In this section, we review the composable security proof while using G att as hardware assumption to construct a outsourcing protocol 3 as real world execution in compared with the ideal functionality F outsrc . In the protocol, the server equips with a secure processor with G att functionality and the enclave program prog outsrc running within it. G att -enabled Program prog outsrc : On input ("keyex", g a ) : let b ∈ Z p , store sk := (g a ) b ; return (g a , g b ) On input* ("compute", ct): let (f, x) := AE.Dec sk (ct) assert decryption success, ct not seen before let y := f (x) and return ct out := AE.Enc sk (y) Server S: On receive ("keyex", g a ) from C: let eid := G att .install(sid, prog outsrc ) let ((g a , g b ), σ) := G att .resume(eid, ("keyex", g a )) and send (eid, g b , σ) to C On receive* ("compute", ct) from C: let (ct out , σ) := G att .resume(eid, ("compute", ct) and send ct out to C Client C: On initialize: let a ∈ Z p ,mpk := G att .getpk() send ("keyex", g a ) to S, await (eid, g b , σ) from S assert Σ.Vf mpk ((sid, eid, Prot outsrc , (g a , g b )), σ) let sk := (g b ) a On receive* ("compute", f, x) from environment Z: let ct := AE.Enc sk (f, x) and send ("compute", ct) to S, await ct out let y := AE.Dec sk (ct out ) and assert decryption success and ct out not seen before output y Theorem 5 (Secure outsourcing from G att [44]). Assume that the signature scheme Σ is existentially unforgeable under chosen message attacks, the Decisional Diffie-Hellman assumption holds in the algebraic group adopted, the authenticated encryption scheme AE is perfectly correct and satisfies the standard notions of INT-CTXT and semantic security. Then, the G att -hybrid protocol Prot outsrc UC-realizes F outsrc when the client C is honest, and the server is a static, malicious adversary.
Proof. For the case that both C and S are honest is trivial since all communication between C and S is assumed to occur over secure channel; For the case of honest client and corrupted server, an ideal world simulator Sim that makes no probabilistic polynomial time indistinguishability of ideal-world and real-world executions can be described as follows: • The simulator Sim forwards any communication between G att and adversary (the corrupted S) or between C and S.
• Sim starts by emulating the setup of a secure channel between C and G att . Sim sends ("keyex", g a ) to S for a randomly chosen a.
• Then, Sim waits to receive ct out from S. If ct out was not the result of a previous G att .resume(eid, ("compute", ct) call but ct out successfully decrypts under sk, the simulator aborts outputting authenc-failure. Otherwise, Sim allows F outsrc to deliver y to C in the ideal world.
The indistinguishability of the ideal world and real world execution can be proven within multiple steps of hybrids: