, TCHES, LaTeX]Cryptocurrency, Payment, Trusted Execution Environments (TEEs), Offline Delegation

Blockchain-based cryptocurrencies, facilitating the convenience of payment by providing a decentralized online solution, have not been widely adopted so far due to slow confirmation of transactions. Offline delegation offers an efficient way to exchange coins. However, in such an approach, the coins that have been delegated confront the risk of being spent twice since the delegator's behaviour cannot be restricted easily on account of the absence of effective supervision. Even if a third party can be regarded as a judge between the delegator and delegatee to secure transactions, she still faces the threat of being compromised or providing misleading assure. Moreover, the approach equipped with a third party contradicts the real intention of decentralized cryptocurrency systems. In this paper, we propose DelegaCoin, an offline delegatable cryptocurrency system to mitigate such an issue. We exploit trusted execution environments (TEEs) as decentralized “virtual agents” to prevent malicious delegation. In DelegaCoin, an owner can delegate his coins through offline-transactions without interacting with the blockchain network. A formal model and analysis, prototype implementation and further evaluation demonstrate that our scheme is provably secure and practically feasible.

§ INTRODUCTION

The interest in decentralized cryptocurrencies has grown rapidly in recent years. Bitcoin [3], as the first and most famous system, has attracted massive attention. Subsequently, a handful of cryptocurrencies, such as Ethereum [4], Namecoin [5] and Litecoin [6], were proposed. Blockchain-based cryptocurrencies significantly facilitate the convenience of payment by providing a decentralized online solution for customers. However, merely online processing of transactions confronts the problem of low performance and high congestion. Offline delegation provides an alternative way to mitigate the issue by enabling users to exchange the coin without having to connect to an online blockchain platform [7]. Unfortunately, decentralized offline delegation still confronts risks caused by unreliable participants. The misbehaviours may easily happen due to the absence of effective supervision. To be specific, let us start from a real scenario: imagine that Bob, the son of Alex, a wild teenager, wants some digital currency (e.g., BTC) to buy a film ticket. According to current decentralized cryptocurrency payment technologies [3][4], Alex has two delegation approaches: (1) Coin-transfer. Alex asks for Bob's BTC address, and then transfers a specific amount of coins to Bob's address. In such a scenario, Bob can only spend received coins from Alex. (2) Ownership-transfer. Alex directly gives his own private key to Bob. Then, Bob can freely spend the coins using such a private key. In this situation, Bob obtains all coins that are saved in Alex's address.

We observe that both approaches suffer drawbacks. For the first approach, coin-transfer requires a global consensus of the blockchain, which makes it time-consuming [8]. For example, a confirmed transaction in the Bitcoin [3] takes around one hour (6 blocks), making the coin-transfer lose the essential property of real-time. For the other approach, ownership-transfer highly relies on the honesty of the delegatee. The promise between the delegator and delegatee depends on their trust or relationship. But it is weak and unreliable. The delegatee may spend all coins in the address for other purposes. Back to the example, Alex's original intention is to give Bob 200 $\mu BTC$ to buy a film ticket, but Bob may spend all coins to purchase his favorite toys. That means Alex loses control of the rest of coins. These two types of approaches represent most of the mainstream schemes ever aiming to achieve a secure delegation, but neither of them provide a satisfactory solution. This leads to the following research problem:

arc=1mm, auto outer arc,
Is it possible to build a secure offline peer-to-peer delegatable system for decentralized cryptocurrencies?

The answer would intuitively be “NO”. Without interacting with the online blockchain network, the coins that have been used confront the risk of being spent twice after another successful delegation. This is because a delegation is only witnessed by the owner and delegatee, where no authoritative third parties perform final confirmation. The pending status leaves a window for attacks in which a malicious coin owner could spend this delegated transaction before the delegatee uses it. Even if a third party can be introduced as a judge between the delegator (owner) and delegatee to secure transactions, she faces the threat of being compromised or provided with misleading assure. Furthermore, the approach equipped with a third party contradicts the real intention of decentralized cryptocurrency systems.

In this paper, we propose DelegaCoin, an offline delegatable electronic cash system. The trusted execution environments (TEEs) are utilized to play the role of virtual agent. TEEs prevent malicious delegation of the coins (e.g. double-delegation on the same coins). As shown in Figure.<ref>, the proposed scheme allows the owner to delegate her coins without interacting with the blockchain or any trusted third parties. The owner is able to directly delegate specific amounts of coins to others by sending them through a secure channel. This delegation can only be executed once under the supervision of delegation policy inside TEEs. In a nutshell, this paper makes the following contributions.

- We propose an offline delegatable payment solution, called DelegaCoin. It employs the trusted execution environments (TEEs) as the decentralized virtual agents to prevent the malicious owner from delegating the same coins multiple times.

- We formally define our protocols and provide a security analysis. Designing a provably secure system from TEEs is a non-trivial task that lays the foundation for many upper-layer applications. The formal analysis indicates that our system is secure.

- We implement the system with Intel’s Software Guard Extensions (SGX) and conduct a series of experiments including the time cost for each function and the used disk space under different configurations. The evaluations demonstrate that our system is feasible and practical.

Paper Structure. Section <ref> gives the background and related studies. Section <ref> provides the preliminaries and building blocks. Section <ref> outlines the general construction of our scheme. Section <ref> presents a formal model for our protocols.  Section <ref> provides the corresponding security analysis. Section <ref> and Section <ref> show our implementation and evaluation, respectively. Section <ref> concludes our work. Appendix A provides an overview of protocol workflow, Appendix B shows the resources availability and Appendix C presents featured notations in this paper.

§ RELATED WORK

Decentralized Cryptocurrency System.
Blockchain-based cryptocurrencies facilitate the convenience of payment by providing a decentralized online solution for customers. Bitcoin [3] was the first and most popular decentralized cryptocurrency. Litecoin [6] modified the PoW by using the Script algorithm and shortened the block confirmation time. Namecoin [5] was the first hard fork of Bitcoin to record and transfer arbitrary names (keys) securely. Ethereum [4] extended Bitcoin by enabling state-transited transactions. Zcash [9] provides a privacy-preserving payment solution by utilizing zero-knowledge proofs. CryptoNote-style schemes [10], instead, enhance the privacy by adopting ring-signatures. However, slow confirmation of transactions retards their wide adoption from developers and users. Current cryptocurrencies, with ten to hundreds of TPS [3, 11], cannot rival established payment systems such as Visa or PayPal that process thousands. Thus, various methods have been proposed for better throughput. The scaling techniques can be categorized in two ways: (i) On-chain solutions that aim to create highly efficient blockchain protocols, either by reconstructing structures [12], connecting chains [13] or via sharding the blockchain [14]. However, on-chain solutions are typically not applicable to existing blockchain systems (require a hard fork). (b) Off-chain (layer 2) solutions that regard the blockchain merely as an underlying mechanism and process transactions offline  [7]. Off-chain solutions generally operate independently on top of the consensus layer of blockchain systems, not changing their original designs. In this paper, we explore the second avenue.

TEEs and Intel SGX.
The Trusted Execution Environments (TEEs) provide a secure environment for executing code to ensure the confidentiality and integrity of code and logic [15]. State-of-the-art implementations include Intel Software Guard Extensions (SGX) [16], ARM TrustZone [17], AMD memory encryption [18], Keystone  [19], etc. Besides, many other applications like BITE [20], Tesseract [21], Ekiden [22] and Fialka [23] propose their TEEs-empowered schemes, but they still miss the focus of offline delegation. In this paper, we utilize SGX [16] to construct the system. SGX is one of TEEs representatives, and offers a set of instructions embedded in central processing units (CPUs). These instructions are used for building and maintaining CPUs' security areas. To be specific, SGX allows to create private regions (a.k.a. enclave) of memory to protect the inside contents. The following features are highlighted in this technique: (1) Attestation. Attestation mechanisms are used to prove to a validator that the enclave has been correctly instantiated, and used to establish a secure, authenticated connection to transfer sensitive data. The attestation guarantees the secret (private key) to be provisioned to the enclave only after a successful substantiation. (2) Runtime Isolation. Processes inside the enclave are protectively isolated from the software running outside. Specifically, the enclave prevents higher privilege processes and outside operating system codes from falsifying inside executions of loaded codes. (3) Sealing identity technique. SGX offers a seal sealing identity technique, where the enclave data is allowed to store in untrusted disk space. The private sealing key comes from the same platform key, which enables data sharing across different enclaves.

Payment Delegation. The payment delegation plays a crucial role in e-commercial activities, and it has been comprehensively studied for decades. Several widely adopted approaches are such that using credit cards (Visa, Mastercard, etc.), using reimbursement, using third-party platforms (like PayPal [24], AliPay [25]). These schemes allow users to delegate their cash spending capability to their own devices or other users. However, these delegation mechanisms heavily rely on a centralized party that needs a fairly great amount of trust. Decentralized cryptocurrencies, like Bitcoin [3] and Ethereum [4], remove the role of trusted third parties, making the payment reliable and guaranteed by distributed blockchain nodes. However, such payment is time-consuming since the online transactions need to get confirmed by the majority of participated nodes. The delegation provides the decentralized cryptocurrency with an efficient payment approach to delegate the coin owner's spending capability. The cryptocurrency delegation using SGX was first explored in [26], where they only focused on the credential delegation in the fair exchange. Teechan [27] provided a full-duplex payment channel framework that employs TEEs, in which the parties can pay each other without interacting with the blockchain in a bounded time. However, Teechan requires a complex setup: the parties must commit a multisig transaction before the channel started. In contrast, our scheme is simple and more practical.

§ PRELIMINARIES AND DEFINITIONS

We make use of the following notions, definitions and assumptions to construct our scheme. Details are shown as follows.

§.§ Notions

Let $\mathsf{\lambda}$ denote a security parameter, $\mathsf{negl(\lambda)}$ represent a negligible function and $\mathcal{A}$ refer to an adversary. $\mathsf{b_{\star}}$ and $\mathsf{c_{\star}}$ are wildcard characters, representing the balance and the encrypted balance, respectively. A full notion list is provided in Appendix <ref>.

§.§ Crypto Primitive Definitions

Semantically Secure Encryption. A semantically secure encryption $\mathsf{SE}$ consists of a triple of algorithms $\mathsf{(KGen, Enc, Dec)}$ defined as follows.

- $\mathsf{SE.KGen}(1^\lambda)$ The algorithm takes as input security parameter $1^{\lambda}$ and generates a private key $\sk$ from the
key space $\mathcal{M}$.

- $\mathsf{SE.Enc(\sk, msg)}$ The algorithm takes as input a private key $\sk$ and a message $\mathsf{msg} \in \mathcal{M}$, and outputs a ciphertext $\mathsf{ct}$.

- $\mathsf{SE.Dec(\sk,ct)}$ The algorithm takes as input a verification key $\sk$, a message $\mathsf{ct}$, and outputs $\mathsf{msg}$.

Correctness. A semantically secure encryption scheme $\mathsf{SE}$ is correct if for all $\mathsf{msg} \in \mathcal{M}$,

\begin{align*}
\Pr\big[\mathsf{SE.Dec(\sk,(SE.Enc(\sk,msg))) \neq msg}  \big| \mathsf{\sk \gets SE.KGen(1^\lambda)}\big] \leq \mathsf{negl(\lambda)},
\end{align*}

where $ \mathsf{negl(\lambda)}$ is a negligible function and the probability is taken over the random coins of the algorithms $\mathsf{SE.Enc}$ and $\mathsf{SE.Dec}$.

[IND-CPA security of $\mathsf{SE}$]
A semantically secure encryption scheme $\mathsf{SE}$ achieves Indistinguishability under Chosen-Plaintext Attack(IND-CPA) if
all PPT adversaries, there exists a negligible function $\mathsf{negl(\lambda)}$ such that

\begin{align*}
\big| \Pr\big[ \mathsf{G_{\adv, SE}^{IND-CPA}(\lambda)} = 1\big] - \frac{1}{2} \big| \leq \mathsf{negl(\lambda)},
\end{align*}

where $\mathsf{G_{\adv, SE}^{IND-CPA}(\lambda)}$ is defined as follows:

$\mathsf{G_{\adv, SE}^{IND-CPA}(\lambda)}$
$← 𝖲𝖤.𝖪𝖦𝖾𝗇(1^λ);

𝖻 $← {0,1}

𝗆_0,𝗆_1 𝒜^𝖲𝖤(·)

𝖼^⋆ 𝖲𝖤.𝖤𝗇𝖼(,𝗆_𝖻)

𝖻^' ^𝖲𝖤(·)(𝖼^⋆)

𝖻 = 𝖻^'

Signature Scheme. A signature scheme $\mathsf{S}$ consists of the following algorithms.

- $\mathsf{S.KeyGen}(1^\lambda)$ The algorithm takes as input security parameter $1^{\lambda}$ and generates a private signing key $\sk$ and a public verification key $\vk$.

- $\mathsf{S.Sign(\sk, msg)}$ The algorithm takes as input a signing key $\sk$ and a message $\mathsf{msg} \in \mathcal{M}$, and outputs a signature $\mathsf{\sigma}$.

- $\mathsf{S.Verify(\vk,\sigma,msg)}$ The algorithm takes as input a verification key $\vk$,
a signature $\mathsf{\sigma}$ and a message $\mathsf{msg} \in \mathcal{M}$, and outputs $1$ or $0$.

Correctness. A signature scheme $\mathsf{S}$ is correct if for all $\mathsf{msg} \in \mathcal{M}$,

\begin{align*}
\Pr\big[\mathsf{S.Verify(\vk,(S.Sign(\sk, msg)),msg)} \neq 1 \big| \mathsf{(\vk,\sk) \gets S.KeyGen(1^\lambda)}\big] \leq \mathsf{negl(\lambda)},
\end{align*}

where $ \mathsf{negl(\lambda)}$ is a negligible function and the probability is taken over the random coins of the algorithms $\mathsf{S.Sign}$ and $\mathsf{S.Verify}$.

[(EUF-CMA security of $\mathsf{S}$]
A signature scheme $\mathsf{S}$ is called Existentially Unforgeable under Chosen Message Attack(EUF-CMA) if all PPT adversaries, there exists a negligible function $\mathsf{negl(\lambda)}$ such that

\begin{align*}
\Pr\big[ \mathsf{G_{\adv, S}^{EUF-CMA}(\lambda)} = 1\big]  \leq \mathsf{negl(\lambda)},
\end{align*}

where $\mathsf{G_{\adv, S}^{EUF-CMA}(\lambda)}$ is defined as follows:

$\mathsf{G_{\adv, S}^{IND-CPA}(\lambda)}$
(, 𝗉𝗄) $← 𝖲.𝖪𝖾𝗒𝖦𝖾𝗇(1^λ);

ℒ 𝖲.𝖲𝗂𝗀𝗇(, 𝗆_{0,…,𝗇});

(𝗆^⋆,σ^⋆) 𝒜^𝒪(sk, ·) (𝗉𝗄)

( 𝖲.𝖵𝖾𝗋𝗂𝖿𝗒(𝗏𝗄,σ^⋆, 𝗆^⋆) = 1) ∧𝗆^⋆ ∉ℒ

Public Key Encryption. A public key encryption scheme $\mathsf{PKE}$ consists of the following algorithms.

- $\mathsf{PKE.KeyGen}(1^\lambda)$ The algorithm takes as input security parameter $1^{\lambda}$ and generates a private signing key $\sk$ and a public verification key $\vk$.

- $\mathsf{PKE.Enc(pk, msg)}$ The algorithm takes as input in a public key $\mathsf{pk}$ and a message $\mathsf{msg} \in \mathcal{M}$, and outputs a ciphertext $\mathsf{ct}$.

- $\mathsf{PKE.Dec(\sk,ct)}$ The algorithm takes as input a secret key $\sk$, a ciphertext $\mathsf{ct}$, and outputs $\mathsf{msg}$ or $\bot$.

Correctness. A public key encryption scheme $\mathsf{PKE}$ is correct if for all $\mathsf{msg} \in \mathcal{M}$,

\begin{align*}
\Pr\big[\mathsf{SE.PKE(\sk,(PKE.Enc(pk,msg))) \neq msg}  \big| \mathsf{(\sk,pk) \gets PKE.KeyGen(1^\lambda)}\big] \leq \mathsf{negl(\lambda)},
\end{align*}

where $ \mathsf{negl(\lambda)}$ is a negligible function and the probability is taken over the random coins of the algorithms $\mathsf{PKE.KeyGen}$ and $\mathsf{PKE.Enc}$.

[(IND-CCA2 security of  $\mathsf{PKE}$]
A PKE scheme $\mathsf{PKE}$ is said to have Indistinguishability Security under Adaptively Chosen Ciphertext Attack(IND-CCA2) if
all PPT adversaries, there exists a negligible function $\mathsf{negl(\lambda)}$ such that

\begin{align*}
\Pr\big[ \mathsf{G_{\adv,PKE}^{IND-CCA2}(\lambda)} = 1\big]  \leq \mathsf{negl(\lambda)},
\end{align*}

where $\mathsf{G_{\adv,PKE}^{IND-CCA2}(\lambda)}$ is defined as follows:

$\mathsf{G_{\adv, PKE}^{IND-CCA2}(\lambda)}$
(, 𝗉𝗄) $← 𝖯𝖪𝖤.𝖪𝖦𝖾𝗇(1^λ);

𝖻 $← {0,1}

𝗆_0,𝗆_1 𝒜^𝖯𝖪𝖤.𝖣𝖾𝖼(,·)

𝖼^⋆ 𝖯𝖪𝖤.𝖤𝗇𝖼(,𝗆_𝖻)

𝖻^' ^𝖯𝖪𝖤.𝖣𝖾𝖼(,·)(𝖼^⋆)

𝖻 = 𝖻^'

§.§ Secure Hardware

In our scheme, parties will have access to TEEs, in which they serve as isolated environments to guarantee the confidentiality and integrity of inside code and data. To capture the secure functionality of TEEs, inspired by [28, 29] we define TEEs as a black-box program that provides some interfaces exposed to users. The abstraction is given as follows. Note that, Due to the scope of usage, we only capture the remote attestation of TEEs and refer to [28] for a full definition.

A secure hardware functionality $\mathsf{HW}$ for a class of probabilistic polynomial time (PPT) programs $\mathcal{P}$ includes the algorithms: $\mathsf{Setup}$, $\mathsf{Load}$, $\mathsf{Run}$, $\mathsf{Run Quote}$, $\mathsf{QuoteVerify}$.

- $\mathsf{HW.Setup(1^\lambda)}:$ The algorithm takes as input a security parameter $\lambda$, and outputs the secret key $\mathsf{sk_{quote}}$ and public parameters $\mathsf{pms}$.

- $\mathsf{HW.Load(pms}, P):$ The algorithm loads a stateful program $P$ into an enclave. It takes as input a program $P \in \mathcal{P}$ and $\mathsf{pms}$, and outputs a new enclave handle $\mathsf{hdl}$.

- $\mathsf{HW.Run(hdl,in)}:$ The algorithm runs enclave. It inputs a handle $\mathsf{hdl}$ that relates to an enclave (running program $P$) and an input $\mathsf{in}$, and outputs execution results $\mathsf{out}$.

- $\mathsf{HW.RunQuote(hdl, in)}:$ The algorithm executes programs in an enclave and generates an attestation quote. It takes as input $\mathsf{hdl}$ and  $\mathsf{in}$, and executes $P$ on $\mathsf{in}$. Then, it outputs $\mathsf{quote = (hdl,tag_P, in, out, \sigma)}$, where $\mathsf{tag_P}$ is a measurement to identify the program running inside an enclave and $\sigma$ is a corresponding signature.

- $\mathsf{HW.QuoteVerify(pms,quote)}:$ The algorithm verifies the quote. It firstly executes $P$ on $\mathsf{in}$ to get $\mathsf{out}$. Then, it takes as input $\mathsf{pms}$, $\mathsf{quote = (hdl,tag_P,in,out,\sigma)}$, and outputs $\mathsf{1}$ if the signature $\sigma$ is correct. Otherwise, it outputs $\mathsf{0}$.

Correctness. The $\mathsf{HW}$ scheme is correct if the following properties hold: For all program $\mathcal{P}$, all input $\mathsf{in}$

* Correctness of $\mathsf{HW.Run}$: for any specific  program $P \in \mathcal{P}$, the output of $\mathsf{HW.Run(hdl,in)}$ is deterministic.

* Correctness of $\mathsf{RunQuote}$ and $\mathsf{QuoteVerify}$:

\begin{align*}
\Pr[\mathsf{QuoteVerify(pms, RunQuote}
(\mathsf{hdl}, \mathsf{in})) \neq 1] \leq \mathsf{negl(\lambda).}\\
\end{align*}

Remote attestation in TEEs provides functionality for verifying the execution and corresponding output of a certain code run inside the enclave by using a signature-based quote. Thus, the remote attestation unforgeability security [28] is defined similarly to the unforgeability of a signature scheme.

[Remote Attestation Unforgeability (RemAttUnf)]
A $\mathsf{HW}$ scheme is RemAttUnf secure if all PPT adversaries, there exists a negligible function $\mathsf{negl(\lambda)}$ such that

\begin{align*}
\Pr\big[ \mathsf{G_{\adv, S}^{RemAttUnf}(\lambda)} = 1\big]  \leq \mathsf{negl(\lambda)},
\end{align*}

where $\mathsf{G_{\adv, HW}^{RemAttUnf}(\lambda)}$ is defined as follows:

$\mathsf{G_{\adv, HW}^{RemAttUnf}(\lambda)}$
𝗉𝗆𝗌 𝖧𝖶.𝖲𝖾𝗍𝗎𝗉(1^λ);

𝗁𝖽𝗅 𝖧𝖶.𝖫𝗈𝖺𝖽 (𝗉𝗆𝗌,P);

𝒬 𝖧𝖶.𝖱𝗎𝗇𝖰𝗎𝗈𝗍𝖾 (𝗁𝖽𝗅, 𝗂𝗇_{0,…,𝗇});

(𝗂𝗇^⋆, 𝗊𝗎𝗈𝗍𝖾^⋆) 𝒜^𝒪(hdl,·) (𝗉𝗆𝗌)

( 𝖧𝖶.𝖰𝗎𝗈𝗍𝖾𝖵𝖾𝗋𝗂𝖿𝗒(𝗉𝗆𝗌, 𝗊𝗎𝗈𝗍𝖾^⋆) = 1) ∧𝗊𝗎𝗈𝗍𝖾^⋆ ∉𝒬

§ DELEGACOIN

In DelegaCoin, three types of entities are involved: coin owner (or delegator) $\mathcal{O}$, coin delegatee $\mathcal{D}$, and blockchain $\mathcal{B}$ (see Figure <ref>). The main idea behind DelegaCoin is to exploit the TEEs as trusted agents between the coin owner and coin delegatee. TEEs are used to maintain delegation policies and ensure faithful executions of the delegation protocol. In particular, TEEs guarantee that the coin owner (either honest or malicious) cannot arbitrarily spend the delegated coins. The workflow is described as follows. Firstly, both $\mathcal{O}$ and $\mathcal{D}$ initialize and run the enclaves, and the owner $\mathcal{O}'s$ enclave generates an address $\mathsf{addr}$ for further transactions with a private key maintained internally. Next, $\mathcal{O}$ deploys delegation policies into the owner $\mathcal{O}'s$ enclave and deposits the coins to the address $\mathsf{addr}$. Then, $\mathcal{O}$ delegates the coins to $\mathcal{D}$ by triggering the execution of delegation inside the enclave. Finally, $\mathcal{D}$ spends delegated transaction to
the blockchain network $\mathcal{B}$. Note that the enclaves in our scheme are decentralized, meaning that each  $\mathcal{O}$ and $\mathcal{D}$ has its own enclave without depending on a centralized agent, which satisfies the requirements of current cryptocurrency systems.

DelegaCoin Workflow

§.§ System Framework

System Setup.  In this phase, the coin owner $\mathcal{O}$ and the delegatee $\mathcal{D}$ initialize their TEEs to provide environments for the operations with respect to the further delegation.

* Negotiation. $\mathsf{pms} \gets \mathsf{ParamGen(1^\lambda)}$: $\mathcal{O}$ agrees with $\mathcal{D}$ for the pre-shared information. Here, $\mathsf{\lambda}$ is a security parameter.

* Enclave Initiation. $\mathsf{hdl}_\mathcal{O},\mathsf{hdl}_\mathcal{D} \gets \mathsf{EncvInit(1^\lambda,pms)}$: $\mathcal{O}$ and $\mathcal{D}$ initialize the enclave E$_{\mathcal{O}}$ and E$_{\mathcal{D}}$ with outputting the enclave handles $\mathsf{hdl}_\mathcal{O}$ and $\mathsf{hdl}_\mathcal{D}$.

* Key Generation.  $\mathsf{(pk_{Tx},sk_{Tx}),(pk_{\mathcal{O}},sk_{\mathcal{O}}), key_{seal}} \gets \mathsf{KeyGen^{TEE}}(\mathsf{hdl_{\mathcal{O}}},1^\lambda)$ and
$\mathsf{(pk_{\mathcal{D}}},\\ \mathsf{sk_{\mathcal{D}}}),(\mathsf{vk_{sign}}, \mathsf{sk_{sign}}), \mathsf{r} \gets \mathsf{KeyGen^{TEE}}(\mathsf{hdl_{\mathcal{D}}},1^\lambda)$: $\mathcal{O}$ and $\mathcal{D}$ run the enclaves E$_{\mathcal{O}}$ and E$_{\mathcal{D}}$ to create their internal keys. Key pair $\mathsf{(pk_{Tx},sk_{Tx})}$ is used for transaction generation. Key pair $(\mathsf{pk_{\mathcal{O}},sk_{\mathcal{O}}})$ and $(\mathsf{pk_{\mathcal{D}},sk_{\mathcal{D}}})$ are used for remote assertion, while $\mathsf{key_{seal}}$ is a sealing key used to export the state to the trusted storage. Key pair $(\mathsf{vk_{sign}}, \mathsf{sk_{sign}})$ is used to identify a specific delegatee, while $\mathsf{r}$ is a private key for transaction encryption.

* Quote Generation.  $\mathsf{ quote \gets QuoGen^{TEE}(\mathsf{sk_{\mathcal{O}}}, \mathsf{vk_{sign}}, pms)}$: $\mathcal{O}$ generate a $\mathsf{quote}$ for requesting an  encrypted symmetric encryption key from $\mathcal{D}$.

* Key Provision.  $\mathsf{ ct_{r} \gets Provision^{TEE}(quote,\mathsf{sk_{sign}}, \mathsf{pk_{\mathcal{O}}}, pms)}$: $\mathcal{O}$ proves to $\mathcal{D}$ that $\textit{E}_{\mathcal{O}}$ has been instantiated with a $\mathsf{quote}$ to request an encrypted symmetric encryption key $\mathsf{ct_{r}}$. The symmetric encryption is used to encrypt the messages inside TEEs.

* Key Extraction.  $\mathsf{ r \gets Extract^{TEE}(\mathsf{sk_{\mathcal{O}}}, ct_{r})}$: $\mathcal{O}$ extracts a symmetric encryption key $\mathsf{r}$ from $\mathsf{ct_{r}}$ using $\mathsf{sk_{\mathcal{O}}}$.

* State Retrieval.  $\mathsf{b_{init} = Dec^{TEE}(key_{seal}, c_{init})}$: Encrypted states are read back by the enclave E$_{\mathcal{O}}$ under $\mathsf{key_{seal}}$, where $\mathsf{b_{init}}$ is the initial balance and $\mathsf{c_{init}}$ is the initial encrypted balance. This step prevents unexpected occasions that may destroy the state in TEEs memory.

Coin Deposit. The enclave E$_{\mathcal{O}}$ generates an address and its corresponding private key $\mathsf{pk_{Tx}}$ for the deposit. Afterwards, $\mathcal{O}$ sends coins to this address in the form of fund deposits.

* Address Creation. $\mathsf{addr} \gets \mathsf{AddrGen^{TEE}}(1^\lambda,\mathsf{pk_{Tx}})$: $\mathcal{O}$ calls E$_{\mathcal{O}}$ to generate a transaction address $\mathsf{addr}$. The private key $\mathsf{sk_{Tx}}$ of $\mathsf{addr}$ is secretly stored inside TEEs and is generated by an internal pseudo-random number.

* Coin Deposit. $\mathsf{ b_{deposit} = Update^{B}(addr,b_{init})}$: $\mathcal{O}$ generates an arbitrary transaction and transfers some coins to $\mathsf{addr}$ as the fund deposits.

Coin Delegation. In this phase, neither $\mathcal{O}$ nor $\mathcal{D}$ interacts with blockchain. $\mathcal{O}$ can instantly complete the coin delegation through offline transactions.

* Balance Update. $\mathsf{b_{update} \gets Update^{TEE}(b_{deposit},b_{Tx})}$:  E$_{\mathcal{O}}$ checks current balance to ensure that it is enough for deduction. Then, E$_{\mathcal{O}}$ updates the balance.

* Signature Generation. $\mathsf{\sigma_{Tx}} \gets \mathsf{TranSign^{TEE}(\mathsf{sk_{Tx}},\mathsf{addr},b_{Tx})}$: E$_{\mathcal{O}}$ generates a valid signature $\mathsf{\sigma_{Tx}}$.

* Transaction Generation. $\mathsf{Tx} \gets \mathsf{TranGen^{TEE}(\mathsf{addr},b_{Tx},\mathsf{\sigma_{Tx}})}$:  E$_{\mathcal{O}}$ generates a transaction $\mathsf{Tx}$ using $\mathsf{\sigma_{Tx}}$.

* Coin Delegation. $\mathsf{ct_{tx}} \gets \mathsf{TranEnc^{TEE}}(\mathsf{r},\mathsf{Tx})$: $\mathcal{O}$ sends encrypted transaction $\mathsf{ct_{tx}}$ to $\mathcal{D}$.

* State Seal. $\mathsf{c_{update} \gets Enc^{TEE}(key_{seal},b_{update})}$: Once completing the delegation, the records $\mathsf{c_{update}}$ are permanently stored outside the enclave. If any abort or halt happens, a re-initiated enclave starts to reload the missing information.

All the algorithms in the step of Coin Delegation must be run as an atomic operation, meaning that either all algorithms finish or none of them finish.
A hardware Root of Trust can guarantee this, and we refer to [16] for more detail.

Coin Spend. $\mathsf{Tx} \gets \mathsf{TranDec^{TEE}(r,\mathsf{ct_{tx}})}$:  $\mathcal{D}$ decrypts $\mathsf{ct_{tx}}$ with $\mathsf{r}$, and then spends $\mathsf{Tx}$ by forwarding it to blockchain network.

Correctness. The DelegaCoin scheme is correct if the following properties hold:
For all $\mathsf{Tx}$, $\mathsf{b_{deposit}}$, $\mathsf{b_{update}}$ and $\mathsf{b_{Tx}}$.

* Correctness of $\mathsf{Update}$:

$$\Pr \left[\mathsf{b_{Tx} \neq (b_{deposit} - b_{update})}\right] \leq \mathsf{negl(\lambda)}.$$

* Correctness of $\mathsf{Seal}$:

$$\Pr[\mathsf{Dec^{TEE}(key_{seal},Enc^{TEE}(key_{seal}, b_{init})) \neq b_{init}}] \leq \mathsf{negl(\lambda)}.$$

* Correctness of $\mathsf{Delegation}$:

\begin{align*}
\Pr[\mathsf{TranDec^{TEE}(r, TranEnc^{TEE}}
(\mathsf{r}, \mathsf{Tx})) \neq \mathsf{Tx}] \leq \mathsf{negl(\lambda).}\\
\end{align*}

§.§ Oracles for Security Definitions

We now define oracles to simulate an honest owner and delegatee for further security definitions and proofs. Each oracle maintains a series of (initially empty) sets $\mathcal{R}_1$, $\mathcal{R}_2$ and $\mathcal{C}$ which will be used later. Here, we use $\mathsf{(instruction; parameter)}$ to denote both the instructions and inputs of oracles.

Honest Owner Oracle $\mathsf{O}^{\mathsf{owner}}:$ This oracle gives the adversary access to honest owners. An adversary $\mathcal{A}$ can obtain newly deletgated transactions or sealed storage with his customized inputs. The oracle provides the following interfaces.

- On input $( \mathsf{signature\; creation}; \mathsf{addr})$, the oracle checks whether a tuple $(\mathsf{addr},\mathsf{\sigma_{Tx}}) \in \mathcal{R}_1$ exists, where $\mathsf{addr}$ is an input of transactions. If successful, the oracle returns $\mathsf{\sigma_{Tx}}$ to $\mathcal{A}$; otherwise, it computes $\mathsf{\sigma_{Tx}} \gets \mathsf{TranSign^{TEE}(\mathsf{sk_{Tx}}, \mathsf{addr},b_{Tx})}$ and adds $(\mathsf{addr},\mathsf{\sigma_{Tx}})$ to $\mathcal{R}_1$, and then returns $\mathsf{\sigma_{Tx}}$ to $\mathcal{A}$.

-  On input $(\mathsf{quote\; generation} ;\mathsf{vk_{sign}})$, the oracle checks if a tuple $(\mathsf{vk_{sign}},\mathsf{quote}) \in \mathcal{R}_2$ exists. If successful, the oracle returns $\mathsf{quote}$ to $\mathcal{A}$. Otherwise, it computes $\mathsf{quote} \gets \mathsf{QuoGen^{TEE}(sk_{\mathcal{O}}, vk_{sign}, pms})$ and adds $(\mathsf{vk_{sign}},\mathsf{quote})$ to $\mathcal{R}_2$, and then returns $\mathsf{quote}$ to $\mathcal{A}$.

Honest Delegatee Oracle $\mathsf{O}^{\mathsf{delegatee}}:$ This oracle gives the adversary access to honest delegatees. The oracle provides the following interfaces.

- On input $(\mathsf{key \;provision} ;\mathsf{quote})$, the oracle checks whether a tuple $(\mathsf{quote},\mathsf{ct_{r}}) \in \mathcal{C}$ exists. If successful, the oracle returns $\mathsf{ct_{r}}$ to $\mathcal{A}$; otherwise, it computes
$\mathsf{ ct_{r}  \gets Provision^{TEE}(quote,sk_{sign}, \mathsf{pk_{\mathcal{O}}}, pms)}$, adds $(\mathsf{quote},\mathsf{ct_{r}})$ to $\mathcal{C}$, and then returns $(\mathsf{quote},\mathsf{ct_{r}})$ to $\mathcal{A}$.

Oracles Interaction Diagram
[name=Real experiment]

DelegaCoin protocol

[name=Adversary $\mathcal{A}$,minheight=3cm,xshift=3cm]

[name=Oracle $\mathsf{O}^{\mathsf{owner}}$,minheight=1.2cm,minwidth=2.3cm]

[name=Oracle $\mathsf{O}^{\mathsf{delegatee}}$,minheight=1.7cm,minwidth=2.3cm]

[name= $\mathsf{HW}$ Oracle ,minheight=4cm,xshift=11.3cm,minwidth=1.7cm]

HW Oracle: This oracle gives the adversary the access to honest hardware.
The oracle provides the interfaces as defined as in <ref>. Note that, to ensure that anything $\mathcal{A}$ sees in the real world can be simulated ideal experiment, we require that an adversary get access to $\mathsf{HW}$ Oracle through $\mathsf{O}^{\mathsf{delegatee}}$ and $\mathsf{O}^{\mathsf{owner}}$ rather than directly interact with $\mathsf{HW}$ Oracle.

§.§ Threat Model and Assumptions

As for involved entities, we assume that $\mathcal{O}$ attempts to delegate some coins to the delegatee. Each party may potentially be malicious. $\mathcal{O}$ may maliciously delegate an exceptional transaction, represented as sending the same transaction to multiple delegatees or spending the delegated transactions before the $\mathcal{D}$ spends them. $\mathcal{D}$ may also attempt to assemble an invalid transaction or double spend the delegated coins. We also assume the blockchain $\mathcal{B}$ is robust and publicly accessible.

With regard to devices, we assume that TEEs are secure, which means that an adversary cannot access the enclave runtime memory and their hardware-related keys (e.g., sealing key or attestation key). In contrast, we do not assume the components outside TEEs are trusted. For example, the adversary may control the operating system or high-level privileged software.

§.§ Security Goals.

DelegaCoin aims to employ TEEs to provide a secure delegatable cryptocurrency system. In brief, TEEs prevent malicious delegation in three aspects: (1) The private key of a delegated transaction and the delegated transaction itself are protected against the public. If an adversary learns any knowledge about the private key or the delegated transaction, she may spend the coin before the delegatee uses it; (2) The delegation executions are correctly executed. In particular, the spendable amount of delegated coins must be less than (or equal to) original coins; (3) The delegation records are securely stored to guarantee consistency considering accidental TEEs failures or malicious TEEs compromises. DelegaCoin is secure if adversaries cannot learn any knowledge about the private key, the delegated transaction, and the sealed storage.

To capture such security properties, we formalize our system through a game inspired by [30]. In our game, a PPT adversary attempts to distinguish between a real-world and a simulated (ideal) world. In the real world, the DelegaCoin algorithms work as defined in the construction. The adversary is allowed to access the transaction-related secret messages created by honest users through oracles as in Definition <ref>. Obviously, the ideal world does not leak any useful information to the adversary. Since we model the additional information explicitly to respond to the adversary, we construct a polynomial-time simulator $\mathcal{S}$ that can fake the additional information corresponding to the real result, but with respect to the fake TEEs. Thus, a universal oracle $\mathcal{U}(\cdot)$ in the ideal world is introduced to simulate the corresponding answers of $\adv$ called in oracles in the real world. We give a formal model as follows, in which these two experiments begin with the same setup assumptions.

DelegaCoin is simulation-secure if for all PPT adversaries $\mathcal{A}$, there exists a stateful PPT simulator $\mathcal{S}$ and a negligible function $ \mathsf{negl(\lambda)}$ such that the probability of that $\mathcal{A}$ distinguishes between $\mathsf{Exp_{\adv,{DelegaCoin}}^{real}(\lambda)}$ and $\mathsf{Exp_{\adv,{DelegaCoin}}^{idea}(\lambda)}$ is negligible, i.e.,

\begin{eqnarray}\nonumber
\left|\mathsf{Pr[Exp_{\adv,{DelegaCoin}}^{real}(\lambda)} = 1 ] - \mathsf{Pr[Exp_{\adv,{DelegaCoin}}^{ideal}(\lambda)} = 1 ] \right|  \leq \mathsf{negl(\lambda)}.
\end{eqnarray}

𝗉𝗆𝗌 𝖯𝖺𝗋𝖺𝗆𝖦𝖾𝗇(1^λ)

𝗁𝖽𝗅_𝒪, 𝗁𝖽𝗅_𝒟 𝖤𝗇𝖼𝗏𝖨𝗇𝗂𝗍(1^λ,𝗉𝗆𝗌)

(𝗉𝗄_𝖳𝗑, 𝗌𝗄_𝖳𝗑), (𝗉𝗄_𝒪, 𝗌𝗄_𝒪), 𝗄𝖾𝗒_𝗌𝖾𝖺𝗅 𝖪𝖾𝗒𝖦𝖾𝗇^𝖳𝖤𝖤(𝗁𝖽𝗅_𝒪,1^λ)

(𝗉𝗄_𝒟,𝗌𝗄_𝒟),  (𝗏𝗄_𝗌𝗂𝗀𝗇, 𝗌𝗄_𝗌𝗂𝗀𝗇), 𝗋 𝖪𝖾𝗒𝖦𝖾𝗇^𝖳𝖤𝖤(𝗁𝖽𝗅_𝒟,1^λ)

𝗊𝗎𝗈𝗍𝖾 𝒜(𝗁𝖽𝗅_𝒪, 𝗏𝗄_𝗌𝗂𝗀𝗇, 𝗉𝗆𝗌)

𝖼𝗍_𝗋 ^𝖯𝗋𝗈𝗏𝗂𝗌𝗂𝗈𝗇^𝖳𝖤𝖤(𝗌𝗄_𝗌𝗂𝗀𝗇)(𝗁𝖽𝗅_𝒟, 𝗊𝗎𝗈𝗍𝖾, 𝗉𝗄_𝒪, 𝗉𝗆𝗌)

𝗋 ^𝖤𝗑𝗍𝗋𝖺𝖼𝗍^𝖳𝖤𝖤(𝗌𝗄_𝒪)(𝗁𝖽𝗅_𝒪, 𝖼𝗍_𝗋)
[dotted]Setup Completed
𝖻_𝗂𝗇𝗂𝗍 = 𝖣𝖾𝖼^𝖳𝖤𝖤(𝗁𝖽𝗅_𝒪,𝗄𝖾𝗒_𝗌𝖾𝖺𝗅, 𝖼_𝗂𝗇𝗂𝗍)

𝖺𝖽𝖽𝗋 𝖠𝖽𝖽𝗋𝖦𝖾𝗇^𝖳𝖤𝖤(1^λ,𝗉𝗄_𝖳𝗑)

𝖻_𝖽𝖾𝗉𝗈𝗌𝗂𝗍 = 𝖴𝗉𝖽𝖺𝗍𝖾^𝖡(𝖺𝖽𝖽𝗋,𝖻_𝗂𝗇𝗂𝗍)

𝖻_𝗎𝗉𝖽𝖺𝗍𝖾 𝖴𝗉𝖽𝖺𝗍𝖾^𝖳𝖤𝖤(𝗁𝖽𝗅_𝒪,𝖻_𝖽𝖾𝗉𝗈𝗌𝗂𝗍,𝖻_𝖳𝗑)

σ_𝖳𝗑 ^𝖳𝗋𝖺𝗇𝖲𝗂𝗀𝗇^𝖳𝖤𝖤(𝗌𝗄_𝖳𝗑)(𝗁𝖽𝗅_𝒪, 𝖺𝖽𝖽𝗋,𝖻_𝖳𝗑)

𝖳𝗑 𝖳𝗋𝖺𝗇𝖦𝖾𝗇^𝖳𝖤𝖤(𝗁𝖽𝗅_𝒪,𝖺𝖽𝖽𝗋,𝖻_𝖳𝗑,σ_𝖳𝗑 )

𝖼𝗍_𝗍𝗑 ^𝖳𝗋𝖺𝗇𝖤𝗇𝖼^𝖳𝖤𝖤(𝗋)(𝗁𝖽𝗅_𝒪, 𝖳𝗑)

𝖼_𝗎𝗉𝖽𝖺𝗍𝖾 = ^𝖤𝗇𝖼^𝖳𝖤𝖤(𝗄𝖾𝗒_𝗌𝖾𝖺𝗅)(𝗁𝖽𝗅_𝒪,𝖻_𝗎𝗉𝖽𝖺𝗍𝖾)
[dotted]Delegation Completed
𝖳𝗑 𝖳𝗋𝖺𝗇𝖣𝖾𝖼^𝖳𝖤𝖤(𝗁𝖽𝗅_𝒟,𝗋,𝖼𝗍_𝗍𝗑)

𝗉𝗆𝗌 𝖯𝖺𝗋𝖺𝗆𝖦𝖾𝗇(1^λ)

𝗁𝖽𝗅_𝒪^⋆, 𝗁𝖽𝗅_𝒟^⋆ 𝒮(1^λ,𝗉𝗆𝗌)

(𝗉𝗄_𝖳𝗑,𝗌𝗄_𝖳𝗑), (𝗉𝗄_𝒪, 𝗌𝗄_𝒪),  𝗄𝖾𝗒_𝗌𝖾𝖺𝗅 𝖪𝖾𝗒𝖦𝖾𝗇^𝖳𝖤𝖤(𝗁𝖽𝗅_𝒪^⋆,1^λ)

(𝗉𝗄_𝒟,𝗌𝗄_𝒟),(𝗏𝗄_𝗌𝗂𝗀𝗇, 𝗌𝗄_𝗌𝗂𝗀𝗇), 𝗋 𝖪𝖾𝗒𝖦𝖾𝗇^𝖳𝖤𝖤(𝗁𝖽𝗅_𝒟^⋆,1^λ)

𝗊𝗎𝗈𝗍𝖾 𝒜(𝗁𝖽𝗅_𝒪^⋆,  𝗏𝗄_𝗌𝗂𝗀𝗇, 𝗉𝗆𝗌)

𝖼𝗍_𝗋 ^𝒮^𝒰(·)(𝗁𝖽𝗅_𝒟^⋆, 𝗊𝗎𝗈𝗍𝖾,  𝗉𝗄_𝒪, 𝗉𝗆𝗌)

𝗋 ^𝒮^𝒰(·)(𝗁𝖽𝗅_𝒪^⋆,  𝖼𝗍_𝗋)
[dotted]Setup Completed
𝖻_𝗂𝗇𝗂𝗍 𝒮(𝗁𝖽𝗅_𝒪,𝗄𝖾𝗒_𝗌𝖾𝖺𝗅, 𝖼_𝗂𝗇𝗂𝗍)

𝖺𝖽𝖽𝗋 𝒮(1^λ,𝗉𝗄_𝖳𝗑)

𝖻_𝖽𝖾𝗉𝗈𝗌𝗂𝗍 = 𝒮(𝖺𝖽𝖽𝗋,𝖻_𝗂𝗇𝗂𝗍)

𝖻_𝗎𝗉𝖽𝖺𝗍𝖾 𝒮(𝗁𝖽𝗅_𝒪^⋆,𝖻_𝖽𝖾𝗉𝗈𝗌𝗂𝗍,1^|𝖻_𝖳𝗑|)

σ_𝖳𝗑 ^𝒮^𝒰(·)(𝗁𝖽𝗅_𝒪^⋆, 𝖺𝖽𝖽𝗋,𝖻_𝖳𝗑)

𝖳𝗑 𝒮(𝗁𝖽𝗅_𝒪^⋆,𝖺𝖽𝖽𝗋, 1^|𝖻_𝖳𝗑|, σ_𝖳𝗑)

𝖼𝗍_𝗍𝗑 ^𝒮^𝒰(·)(𝗁𝖽𝗅_𝒪^⋆, 1^|𝖳𝗑|)

𝖼_𝗎𝗉𝖽𝖺𝗍𝖾 = ^𝒮^𝒰(·)(𝗁𝖽𝗅_𝒪^⋆, 1^|𝖻_𝗎𝗉𝖽𝖺𝗍𝖾|)
[dotted]Delegation Completed
𝖳𝗑 𝒮(𝗁𝖽𝗅_𝒟^⋆,𝗋,𝖼𝗍_𝗍𝗑)

§ FORMAL PROTOCOLS

In this section, we present a formal model of our electronic cash system by utilizing the syntax of the $\mathsf{HW}$ model. In particular, we model the interactions of Intel SGX enclaves as calling to the $\mathsf{HW}$ functionality defined in Definition <ref>. The formal protocols are provide as follows.

The owner enclave program $\mathsf{P_{\mathcal{O}}}$ is defined as follows. The value $\mathsf{tag_{P}}$ is a measurement of the program $\mathsf{P_{\mathcal{O}}}$, and it is hardcoded in the static data of $\mathsf{P_{\mathcal{O}}}$. Let $\mathsf{state}_{\mathcal{O}}$ denote an internal state variable.

* On input (“init setup”, $\mathsf{sid, vk_{sign}}$[We assume that the combination ($\mathsf{sid}$,$\mathsf{vk_{sign}}$), represented as the identity of a delegatee, has already been distributed before the system setup. ]):

- Run $(\mathsf{pk_{\mathcal{O}}}, \mathsf{sk_{\mathcal{O}}}) \gets \mathsf{\mathsf{PKE}.KeyGen}(1^\lambda)$ and $\mathsf{key_{seal}}\footnote{Multiple enclaves from the same signing authority can derive the same key, since seal key is based on the enclave’s certificate-based identity.} \gets \mathsf{\mathsf{SE}.KeyGen}(1^\lambda)$.

- Update $\mathsf{state}$ to $(\mathsf{sk_{\mathcal{O}}, vk_{sign}})$ and output $(\mathsf{pk_{\mathcal{O}}, sid, vk_{sign}})$.

* On input (“complete setup”, $\mathsf{sid, ct_{r}, \sigma_{r}})$:

- Look up the $\mathsf{state}_{\mathcal{O}}$ to obtain the entry $\mathsf{(sk_{\mathcal{O}}, sid, vk_{sign})}$. If no entry
exists for $\mathsf{sid}$, output $\bot$.

- Receive the $(\mathsf{sid, vk_{sign}})$ from $\mathcal{O}$ and check if $\mathsf{vk_{sign}}$ matches with the one in $\mathsf{state}_{\mathcal{O}}$. If not, output $\bot$.

- Verify signature $\mathsf{b \gets \mathsf{\mathsf{S}.Verify}(vk_{sign}, \sigma_{r}, (sid, ct_{r} ))}$.
If $\mathsf{b}$ = 0, output $\bot$.

- Run $\mathsf{r \gets \mathsf{\mathsf{PKE}.dec}(sk_{\mathcal{O}}, ct_{r})}$.

- Add the tuple $(\mathsf{r, sid, vk_{sign}})$ to $\mathsf{state}_{\mathcal{O}}$.

* On input (“state retrieval”, $\mathsf{sid}$):

- Retrieve identity-balance pair ($\mathsf{sid, c_{init}}$) from the sealed storage.

- Run $\mathsf{b_{init} = \mathsf{SE}.Dec(key_{seal},c_{init})}$ and update $\mathsf{state}_{\mathcal{O}}$ to $(\mathsf{sid, b_{init}})$

* On input (“address generation”, $1^\lambda$):

- Run $(\mathsf{sk_{Tx}}, \mathsf{pk_{Tx}}) \gets \mathsf{\mathsf{S}.KeyGen}(1^\lambda)$ and $\mathsf{addr} \gets \mathsf{AddrGen^{TEE}}(1^\lambda,\mathsf{pk_{Tx}})$.

- Update $(\mathsf{sk_{Tx}, addr})$ to $\mathsf{state}_{\mathcal{O}}$  and output $(\mathsf{pk_{Tx}}, \mathsf{addr})$.

* On input (“transaction generation”, $\mathsf{addr}$ ):

- Retrieve the private key $\mathsf{sk_{Tx}}$.

- Run $\mathsf{\sigma_{Tx}} \gets \mathsf{\mathsf{S}.Sign(sk_{Tx},\mathsf{addr},  b_{Tx})}$ and output a signature $\mathsf{\sigma_{Tx}}$.

- Run $\mathsf{Tx} \gets \mathsf{TranGen(\mathsf{addr},  b_{Tx},\mathsf{\sigma_{Tx}}})$ and update $(\mathsf{sid, Tx})$ to $\mathsf{state}_{\mathcal{O}}$.

* On input (“state update”, $\mathsf{addr}$):

- Check $\mathsf{b_{deposit}}$ and $\mathsf{b_{Tx}}$. If $\mathsf{b_{deposit} < b_{Tx}}$, output $\bot$.

- Run $\mathsf{b_{update} \gets Update(b_{deposit},b_{Tx})}$.

* On input (“start delegation”, $\mathsf{addr}$):

- Retrieve the provision private key $\mathsf{r}$ and $\mathsf{Tx}$ from $\mathsf{state}_{\mathcal{O}}$.

- Run $\mathsf{\mathsf{ct_{tx}} \gets \mathsf{SE}.\mathsf{Enc(r,Tx)}}$.

* On input (“state seal”, $\mathsf{addr}$):

- Run $\mathsf{\mathsf{c_{update}} = \mathsf{SE}.Enc(key_{seal},\mathsf{b_{update}})}$ and update $\mathsf{state}_{\mathcal{O}}$ to $(\mathsf{addr, b_{update}})$.

- Store $\mathsf{addr}$ and $\mathsf{c_{update}}$ to sealed storage.

The delegatee enclave program $\mathsf{P_{\mathcal{D}}}$ is defined as follows. The value $\mathsf{tag_{\mathcal{D}}}$ is the measurement of the program $\mathsf{P_{\mathcal{D}}}$, and it is hardcoded in the static data of $\mathsf{P_{\mathcal{D}}}$. Let $\mathsf{state}_\mathcal{D}$ denote an internal state variable. Also, the security parameter $\lambda$ is hardcoded into the program.

* On input (“init setup”, $1^\lambda$):

- Generate a session ID, $\mathsf{sid \gets \{0,1\}^{\lambda}}$.

- Run $(\mathsf{pk_{\mathcal{D}}}, \mathsf{sk_{\mathcal{D}}}) \gets \mathsf{\mathsf{PKE}.KeyGen}(1^\lambda)$, and $(\mathsf{vk_{sign}}, \mathsf{sk_{sign}}) \gets \mathsf{\mathsf{S}.KeyGen}(1^\lambda)$.

- Update $\mathsf{state}_\mathcal{D}$ to $(\mathsf{sk_{\mathcal{D}},sk_{sign}})$ and output $(\mathsf{sid, pk_{\mathcal{D}},vk_{sign}})$.

* On input (“provision”, $\mathsf{quote}, \mathsf{pk_{\mathcal{O}}}, \mathsf{pms}$):

- Parse $\mathsf{quote =(hdl_{\mathcal{O}}, tag_P, in, out, \sigma)}$,  check that $\mathsf{tag_{P}== tag_{\mathcal{O}}}$. If not, output $\bot$.

- Parse $\mathsf{out = (sid, pk_{\mathcal{O}})}$, and run $\mathsf{b \gets HW.QuoteVerify(pms,quote)}$ on $\mathsf{quote}$. If $\mathsf{b} = 0$, output $\bot$.

- Select a random number $\mathsf{r}$ and compute the algorithm
$\mathsf{ct_{r} = \mathsf{PKE}.Enc(pk_{\mathcal{O}},r)}$ and $\mathsf{\sigma_{r} = \mathsf{S}.Sign(sk_{sign}, (sid, ct_{r}))}$ and output $\mathsf{(sid, ct_{r}, \sigma_{r})}$.

* On input (“complete delegation”, $\mathsf{ct_{tx}}$):

- Retrieve $\mathsf{r}$ from $\mathsf{state}_{\mathcal{D}}$.

- Run $\mathsf{\mathsf{Tx} \gets \mathsf{SE}.\mathsf{Dec(r,ct_{tx})}}$.

2em $\mathbf{Setup}.$ The following steps are based on the completed initialization of the programs of the delegator $\mathsf{P_{\mathcal{O}}}$ and delegatee $\mathsf{P_{\mathcal{D}}}$. The delegatee $\mathcal{D}$ runs $\mathsf{hdl_{\mathcal{D}}} \gets \mathsf{HW.Load(pms,P_{\mathcal{D}})}$ and $\mathsf{(\mathsf{vk_{sign}}, pk_{\mathcal{D}}) \gets HW.Run(hdl_{\mathcal{D}}, (\text{``init setup''}, 1^\lambda))}$. Then, $\mathcal{D}$ sends $\mathsf{vk_{sign}}$ to the delegator $\mathcal{O}$. Next, $\mathcal{O}$ runs $\mathsf{hdl}_{\mathcal{O}} \gets \mathsf{HW.Load(pms,P_{\mathcal{O}})}$ to load the handle. Meanwhile, $\mathcal{O}$
calls $\mathsf{quote \gets HW.Run\&Quote(hdl_{\mathcal{O}}, (\text{``init setup''}, \mathsf{sid, vk_{sign}}))}$, and sends a $\mathsf{quote}$ to $\mathcal{D}$. After that, $\mathcal{D}$ calls $\mathsf{(sid, ct_{r}, \sigma_{r})} \gets \mathsf{HW.Run(hdl_{\mathcal{D}}, (\text{``provision''}, \mathsf{quote,pk_{\mathcal{O}}, pms}))}$, and sends $\mathsf{(sid, ct_{r}, \sigma_{r})}$ to $\mathcal{O}$. Last, $\mathcal{O}$
calls $\mathsf{HW.Run(hdl_{\mathcal{O}}, (\text{``complete setup''}, \mathsf{vk_{sign}}))}$. At the end of completing setup, $\mathcal{O}$'s enclave E$_{\mathcal{O}}$ obtains the private key $\mathsf{r}$ used for transaction delegation.

2em $\mathbf{Deposit}$. $\mathcal{O}$
calls $\mathsf{c_{init} \gets HW.Run(hdl_{\mathcal{O}}, (\text{``state retrieval''}, sid))}$. If $\mathsf{c_{init}}$ does not exist or equals to $0$, $\mathcal{O}$ calls
$\mathsf{addr \gets HW.Run(hdl_{\mathcal{O}}, (\text{``address generation''},1^\lambda))}$ to create a new address $\mathsf{addr}$. Then, $\mathcal{O}$ transfers some coins to $\mathsf{addr}$ through a normal blockchain transaction.

2em $\mathbf{Delegation}$. $\mathcal{O}$ firstly parses $\mathsf{hdl_{\mathcal{O}}}$ and
calls E$_{\mathcal{O}}$. Then, E$_{\mathcal{O}}$ retrieves the $\mathsf{addr}$. Afterwards, it calls $\mathsf{b_{update} \gets HW.Run(hdl_{\mathcal{O}}, (\text{``state update''},addr))}$. If the update algorithm returns false or failure, E$_{\mathcal{O}}$ aborts the following operations. Otherwise, it looks up the state to obtain $\mathsf{sk_{Tx}}$, runs $\mathsf{Tx \gets HW.Run(hdl_{\mathcal{O}}, (\text{``transaction generation''}, addr ))}$ and outputs a transaction $\mathsf{Tx}$. After that, the delegator's enclave E$_{\mathcal{O}}$ retrieves $\mathsf{r}$ and runs $\mathsf{ct_{tx} \gets HW.Run(hdl_{\mathcal{O}}, (\text{``start delegation''},addr))}$. Finally, ${\mathcal{O}}$ sends $\mathsf{ct_{tx}}$ to $\mathcal{D}$.

2em $\mathbf{Spend}$. $\mathcal{D}$ parses $\mathsf{hdl_{\mathcal{D}}}$ and runs $\mathsf{Tx \gets HW.Run(hdl_{\mathcal{D}}, (\text{``complete delegation''},\mathsf{ct_{tx}}))}$. After that, $\mathcal{D}$ spends the received transaction $\mathsf{Tx}$ by forwarding it to the blockchain network. Then, a blockchain node firstly parses
$\mathsf{Tx = (addr,pk_{Tx},metadata,\sigma_{Tx})}$ and runs $\mathsf{b} \gets \mathsf{\mathsf{S}.Verify^{B}(pk_{Tx},\sigma_{Tx})}$. If $\mathsf{b} = 0$, output $\bot$. Otherwise, the node broadcasts $\mathsf{Tx}$ to other blockchain nodes.

§ SECURITY ANALYSIS

Assume that $\mathsf{\mathsf{SE}}$ is IND-CPA secure,
$\mathsf{PKE}$ is IND-CCA2 secure, $\mathsf{S}$ holds the EUF-CMA security, and the TEEs are secure as in Definition <ref>, DelegaCoin scheme is simulation-secure.

Inspired by [31, 28], we use a simulation-based paradigm to conduct security analysis, and explain the crux of our security proof as follows. We firstly construct a simulator $\mathcal{S}$ which can simulate the challenge responses in the real world. It provides the adversary $\adv$ with a simulated delegated transaction, a simulated quote and sealed storage. The information that $\adv$ can obtain is merely the instruction code and oracle responses queried by $\adv$ in the real experiment. At a high level, the proof idea is simple: $\mathcal{S}$ encrypts zeros as the challenge message. In the ideal experiment, $\mathcal{S}$ intercepts $\adv$'s queries to user oracle and provides simulated responses. It uses its $\mathcal{U(\cdot)}$ oracle to simulate oracles in the real world and sends the response back to $\adv$ as the simulated oracle output. $\mathcal{U(\cdot)}$ and $\mathcal{S}$'s algorithms are described as follows.

Pre-processing phase. $\mathcal{S}$ simulates the pre-processing phase similar to in the real world. It firstly runs $\mathsf{ParamGen(1^\lambda)}$ and records system parameters $\mathsf{pms}$ that are generated during the process. Then, it calls $\mathsf{EncvInit(1^\lambda,pms)}$ to create the simulated enclave instances.
$\mathcal{S}$ also creates empty lists $\mathcal{R}_1^\star$, $\mathcal{R}_2^\star$, $\mathcal{C}^\star$, $\mathcal{K}^\star$ and $\mathcal{L}^\star$ to be used later.

2em $\mathbf{KeyGen^{\star}(1^\lambda)}$ When $\mathcal{A}$ makes a query to $\mathbf{KeyGen(1^\lambda)}$ oracle, $\mathcal{S}$ responds the same way as in the
real world except that now stores all the public keys queried in a list $\mathcal{K}^{\star}$. That is, $\mathcal{S}$ does the following algorithms.

- Compute and output $(\mathsf{pk_{\mathcal{O}}}, \mathsf{sk_{\mathcal{O}}}),(\mathsf{pk_{Tx}}, \mathsf{sk_{Tx}}) \gets \mathsf{\mathsf{PKE}.KeyGen}(1^\lambda)$.

- Store the keys $(\mathsf{pk_{\mathcal{O}}}, \mathsf{sk_{\mathcal{O}}}),(\mathsf{pk_{Tx}}, \mathsf{sk_{Tx}})$ in the list $\mathcal{K}^{\star}$.

2em $\mathbf{Enc^{\star}(key^\star, 1^{|{msg}^\star|})}$[Here, $\mathbf{msg^{\star}}$ is a wildcard character, representing any messages.] When $\mathcal{A}$ provides the challenge message $\mathsf{{msg}^\star}$ for symmetric encryption, the following algorithm is used by $\mathcal{S}$ to simulate the challenge ciphertext.

- Compute and output $\mathsf{ct^\star \gets \mathsf{SE}.Enc(key^\star, 1^{|{msg}^\star|)}}$.

- Store $\mathsf{ct}^\star$ in the list $\mathcal{L}^{\star}$.

2em $\mathbf{\mathsf{O}^{owner\star}(\mathsf{signature\; creation;addr)}}.$ When $\mathcal{A}$ takes a query to $\mathbf{\mathsf{O}^{owner}}$ oracle, $\mathcal{S}$ responds the same way as in the real world, except that $\mathcal{S}$ now stores all the $\mathsf{addr}$ corresponding to the user's queries in a list $\mathcal{R}_1^\star$. That is, $\mathcal{S}$ does the following algorithms.

-  Call $\mathbf{\mathsf{O}^{owner}}$ oracle with an input $( \mathsf{signature\; creation}; \mathsf{addr})$ and output $\mathsf{\sigma_{Tx}}$.

- Store $(\mathsf{addr, \sigma_{Tx}})$ in the list $\mathcal{R}_1^\star$.

2em $\mathbf{\mathsf{O}^{owner\star}(\mathsf{quote\; generation;vk_{sign})}}.$ When $\mathcal{A}$ takes a query to the $\mathbf{\mathsf{O}^{owner}}$ oracle, $\mathcal{S}$ responds the same way as in the real world, except that $\mathcal{S}$ now stores all the $\mathsf{quote}$ corresponding to the user's queries in a list $\mathcal{R}_2^\star$. That is, $\mathcal{S}$ does the following algorithms.

-  Call the $\mathbf{\mathsf{O}^{owner}}$ oracle with an input $(\mathsf{quote\; generation; vk_{sign}})$ and output $\mathsf{quote}$.

- Store $(\mathsf{vk_{sign}, quote})$ in the list $\mathcal{R}_2^\star$.

2em $\mathbf{\mathsf{O}^{delegatee\star}(\mathsf{key \;provision} ;\mathsf{quote})}.$ When $\mathcal{A}$ takes a query to the $\mathbf{\mathsf{O}^{delegatee}}$ oracle, $\mathcal{S}$ responds the same way as in the real world, except that $\mathcal{S}$ now stores all the $\mathsf{quote}$ corresponding to the user's queries in a list $\mathcal{C}^\star$. That is, $\mathcal{S}$ does the following algorithm.

- Call $\mathbf{\mathsf{O}^{delegatee}}$ oracle with an input $(\mathsf{key \;provision} ;\mathsf{quote})$ and output $\mathsf{ct_{r}}$.

- Store $\mathsf{(quote,ct_{r})}$ in the list $\mathcal{C}^\star$.

For the PPT simulator $\mathcal{S}$, we prove the security by showing that the view of an adversary $\mathcal{A}$ in the real world is computationally indistinguishable from its view in the ideal world. Specifically, we establish a series of Hybrids that $\mathcal{A}$ cannot be distinguished with a non-negligible advantage as follows.

Hybrid 0. $\mathsf{Exp^{real}_{DelegaCoin}(1^\lambda)}$ runs.

Hybrid 1. As in Hybrid 0, except that $\mathbf{KeyGen^{\star}(1^\lambda)}$ run by $\mathcal{S}$ is used to generate secret keys instead of

The proof is straightforward, storing corresponding answers in lists does not affect the view of $\mathcal{A}$. Thus,
$\textit{Hybrid 1}$ is indistinguishable from $\textit{Hybrid 0}$.

Hybrid 2. As in Hybrid 1, except that $\mathcal{S}$ maintains a list $\mathsf{\mathcal{C}^{\star}}$ of all  $\mathsf{quote =(hdl,tag_P,in,out,\sigma)}$ output by $\mathsf{HW.Run\&Quote(hdl_{\mathcal{O}},in)}$. And, when $\mathsf{HW.QuoteVerify(hdl_{\mathcal{D}}, pms,quote)}$ is called, $\mathcal{S}$ outputs $\bot$ if $\mathsf{quote \notin \mathcal{R}_2}$. ($\mathcal{R}_2$ is a quote returned by the real-world oracles that $\adv$ has queried as defined in Section <ref>).

If a fake quote is produced, then the step $\mathsf{HW.QuoteVerify(hdl_{\mathcal{O}}, pms,quote)}$ in the real word would make it output $\bot$. Thus, $\textit{Hybrid 2}$ differs from $\textit{Hybrid 1}$ only when $\mathcal{A}$ can produce a valid $\mathsf{quote}$ without knowing $\mathsf{sk_{\mathcal{O}}}$. Assume that there is an  adversary $\mathcal{A}$ can distinguish between $\textit{Hybrid 2}$ and $\textit{Hybrid 1}$. Obviously, this can be transformed to the ability against Remote Attestation as in Definition <ref>. However, our assumption relies on the fact that the security of Remote Attestation holds. Thuerefore, Hybrid 2 is indistinguishable from Hybrid 1.

Hybrid 3. As in Hybrid 2, except that when the $\mathbf{\mathsf{O}^{delegatee}}$ oracle calls $ \mathsf{HW.Run(hdl_{\mathcal{D}}, }$ $ \mathsf{ (\text{``provision''}, \mathsf{quote,\mathsf{pk_{\mathcal{O}}}, pms}))}$, $\mathcal{S}$ replaces $\mathsf{ct_r}$ as an encryption of zeros $\mathsf{\mathsf{PKE}.Enc(pk_{\mathcal{O}},1^{|r|})}$.

The IND-CCA2 challenger provides the challenge public key $pk_{\mathcal{O}}$, and an adversary $\adv$ provides two messages $\mathsf{r}$ and $1^{|\mathsf{r}|}$, and further, the challenge returns an encryption of $\mathsf{r}$ or an encryption of $1^{|\mathsf{r}|}$, which is represented $\mathsf{ct_{\star}}$.
$\mathcal{S}$ sets $\mathsf{ct_{\star}}$ as the real output $\mathsf{ct_{r}}$. For $\mathsf{ct_r} \in \mathcal{C}$,
$\mathcal{S}$ can use $\mathsf{O}^{\mathsf{delegatee}}$ as it used in the real world. However, For $\mathsf{ct_r} \notin \mathcal{C}$, $\mathcal{S}$ neither has the oracles nor has the $\sk_{\mathcal{O}}$. But, the decryption oracle offered by the IND-CCA2 challenger can be used for any $\mathsf{ct_r} \notin \mathcal{C}$. Under this condition, if $\mathcal{A}$ can still distinguish Hybrid 3 and Hybrid 2, we can forward the answer corresponding to $\mathcal{A}$'s answer to the IND-CCA2 challenger. If $\mathcal{A}$ can
distinguish between these two hybrids with a non-negligible probability, the IND-CCA2 security of $\mathsf{PKE}$ (see Definition <ref>) can
be broken with a non-negligible probability.

Hybrid 4. As in Hybrid 3, except that $\mathcal{S}$ maintains a list $\mathcal{R}_1^\star$ of all transaction signature $\mathsf{\sigma_{Tx}}$ output by $\mathbf{\mathsf{O}^{owner}(\mathsf{signature\; creation; addr})}$ for $\mathsf{addr} \in \mathcal{R}_1$. When  $\mathsf{b} \gets \mathsf{\mathsf{S}.verify^{B}(pk_{Tx},\sigma_{Tx})}$ is called $\mathcal{S}$ outputs $\bot$ if $(\mathsf{addr}, \mathsf{\sigma_{Tx}})$, as components of a $\mathsf{Tx}$, do not belong to $\mathcal{R}_1$. Namely, $\mathsf{(\mathsf{addr}, \mathsf{\sigma_{Tx}}) \notin \mathcal{R}_1}$.

If a transaction is given with an invalid signature, then the step $\mathsf{\mathsf{S}.Verify^{B}( pk_{Tx},\sigma_{Tx})}$ in the real word would make it output $\bot$. Thus, $\textit{Hybrid 4}$ differs from $\textit{Hybrid 3}$ only when $\mathcal{A}$ can produce a valid signature on $\mathsf{addr}$ which has never appeared before in the communication between $\mathcal{A}$ and the oracles. Let $\mathcal{A}$ be an adversary who can distinguish $\textit{Hybrid 4}$ and $\textit{Hybrid 3}$. We use it to break the EUF-CMA [32] security of signature scheme $\mathcal{S}$. We get a verification key $\mathsf{pk_{Tx}}$ and an access to $\mathsf{\mathsf{S}.Sign(sk_{Tx},\cdot)}$ oracle from the EUF-CMA challenger. Whenever $\mathcal{S}$ signs a message using $\mathsf{sk_{Tx}}$, it uses the $\mathsf{\mathsf{S}.Sign(sk_{Tx},\cdot)}$ oracle.  Also, our construction does not need a direct access to $\mathsf{sk_{Tx}}$ sign; it is used only to sign messages for the oracle provided by the challenger. Now, if $\mathcal{A}$ can distinguish two hybrids, the only reason is that $\mathcal{A}$ generates a valid signature $\mathsf{\sigma_{Tx}}$. Then, we can send such signature as forgery to the EUF-CMA [32] challenger.

Hybrid 5. As shown in Hybrid 4, except that when the $\mathbf{\mathsf{O}^{owner}}$ oracle calls the function $\mathsf{HW.Run(hdl_{\mathcal{O}}, (\text{``start delegation''},addr))}$, $\mathcal{S}$ replaces $\mathsf{Enc}$ with $\mathsf{Enc^{\star}}$.

If symmetric encryption scheme $\mathsf{SE}$ is IND-CPA secure, Hybrid 5 is indistinguishable from Hybrid 4.

Whenever $\mathcal{A}$ provides a transaction $\mathsf{Tx}$ of its choice, $\mathcal{S}$ replies with zeros, e.g., $\mathsf{\mathsf{SE}.Enc(1^{|r|})}$, which is shown as follows.

[nr=3,name=𝖧𝗒𝖻𝗋𝗂𝖽 ,arg=(1^n)]

𝖼𝗍_𝗍𝗑 𝖲𝖤.𝖤𝗇𝖼(𝗋,𝖳𝗑)

$\mathsf{\mathsf{ct_{tx}} \gets \mathsf{SE}.\mathsf{Enc(1^{|r|},Tx)}}$

45hint=replace the encryption with zeros, nodestyle=red

Assume that there is an adversary $\mathcal{A}$ that is able
to distinguish the environments of Hybrid 5 and Hybrid 4. Then, we build an adversary $\mathcal{A}^\star$ against IND-CPA secure of $\mathsf{SE}$.  Given a transaction $\mathsf{Tx}$ , if $\mathcal{A}$ distinguishes the encryption
of $\mathsf{r}$ from the encryption of $1^{\mathsf{|r|}}$, we forward the corresponding answer to the IND-CPA challenger.

Hybrid 6. As in Hybrid 5, except that when the $\mathcal{A}$ calls $\mathsf{HW.Run(hdl_{\mathcal{O}}, (\text{``state seal''},addr))}$, $\mathcal{S}$ replaces $\mathsf{Enc}$ with $\mathsf{Enc^{\star}}$.

The Indistinguishability between $\textit{Hybrid 6}$ and $\textit{Hybrid 5}$ can be directly
reduced to the IND-CPA property of $\mathsf{SE}$, which is similar to the lemma <ref>

§ IMPLEMENTATION

We implement a prototype with three types of entities: the owner node, the delegatee node, and the blockchain system. The owner node and the delegatee node are separately running on two computers. The codes of these nodes are both developed in C++ using the $\text{Intel}^\circledR$ SGX SDK 1.6 under the operating system of Ubuntu 20.04.1 LTS. For the blockchain network, we adopt the Bitcoin testnet [33] as our prototype platform. Specifically, we employ SHA-256 as the hash algorithm, and ECDSA [34] with secp256k1 [35] as the initial setting to sign transactions, which is the same with Bitcoin testnet's configuration.

Functionalities. We emphasize two main functionalities in our protocol, including isolated transaction generation and remote attestation. The delegation inside TEEs has full responsibility to govern the behaviours of participants. In particular, TEEs first calls the function $sgx\_create\_enclave$ and $enclave\_init\_ra$ to create and initialize an enclave E$_{\mathcal{O}}$. Then, it derives the transaction key $sk_{Tx}$ under the user's invocation.

Remote Attestation
$\mathsf{request(quote, pms)}$

parse the received $\mathsf{quote}$ into $\mathsf{hdl,tag_P,in,out,\sigma}$

verify the validity of $\mathsf{vk_{sign}}$

run the algorithm  $\mathsf{HW.quoteVerify}$ with an input  $\mathsf{(pms,quote)}$

verify the validity of $\mathsf{quote}$

return the results $\mathsf{b}$ if it passes ($\mathsf{1}$), or not ($\mathsf{0}$)

Next, the system generates a bitcoin address  and a transaction with calling the function
$create\_address\_from\_string$ and $generate\_transaction$ respectively. E$_{\mathcal{O}}$ keeps $sk_{Tx}$ in its global variable storage and signs the transaction with it while calling $generate\_transaction$. The transaction can only be generated inside the enclave without exposing to the public. Afterwards, E$_{\mathcal{O}}$ creates a quote by calling the function $ra\_network\_send\_receive$, and proves to the delegatee that
its enclave has been successfully initialized and is ready for the further delegation.

§ EVALUATION

In this section, we evaluate the system with respect to performance and disk space. To have an accurate and fair test result, we repeat the measure for each operation 500 times and calculate the average.

§.§ Performance

The operations of public key generation and address create cost approximately the same time. This is due to the reason that they are both based on the same type of basic cryptographic primitives. The operations of transaction generation, state seal, and transaction decryption spend more time than the aforementioned operations because they combine more complex cryptographic functions. We also observe that the enclave initiation spends much more time than (transactions) key pair generations. Fortunately, the time used on enclave initiation can be omitted since the enclave each time launches only once (one-time operation). The state update spends the lowest time since most of the recorded messages are overlapped without the changes and only a small portion of data requires an update. The operations of coin deposit and transaction confirmation depend on the configuration of the Bitcoin testnet, varying from 10+ seconds to several minutes. Furthermore, we attach the time costs of the state seal operation under increased transactions in Figure.<ref> (right column). The time consumption grows slowly because a large portion of transactions are processed in batch. Remarkably, it costs less than 25 millisecond to finish all operations of coin delegation, which is significantly lower than the online transaction of Bitcoin testnet. This indicates that our solution is efficient in transaction processing and practical coin delegation.

The average performance of various operations

Phase     Operation     Average Time / ms

2*System setup      Enclave initiation       $ 13.18940 $

Public key generation (Tx)     $ 0.34223 $

Private key generation (Tx)      $0.01119 $

2*Coin deposit     Address creation     $0.00690 $

Coin deposit      $ -$

4*Coin delegation     Transaction generation      $ 0.78565 $

Remote attestation     $19.50990 $

State update     $ 0.00366 $

State seal     $ 5.43957  $

2*Coin spend     Transaction decryption     $ - $

Transaction confirmation      $ - $

§.§ Disk Space

In this part, we provide an evaluation of the disk space of the sealed state. We simulate the situation in DelegaCoin when more delegation transactions join the network. The transaction creation rate is set to be 560 transactions/second. We monitor space usage and the corresponding growth rate. Each transaction occupies approximately 700 KB of storage space. We test eight sets of experiments with an increased number of transactions in the sequence $1, 10, 100, 200, 400, 600, 800, 1000$.  The results, as shown in Figure.<ref> (left column), indicate that the size of the disk usage grows linearly with increased delegation transactions. The reason is straightforward: the disk usage closely relates to the involved transactions that are stored in the list. In our configurations, the transaction generation rate stays fixed. Therefore, the used space is proportional to the increased transactions.

Used disk space and time consuming of state seal

§ CONCLUSION

Decentralized cryptocurrencies such as Bitcoin [3] provide an alternative approach for peer-to-peer payments. However, such payments are time-consuming. In this paper, we provide a secure and practical  TEEs-based offline delegatable cryptocurrency system. TEEs are used as the primitives to establish a secure delegation channel and offer better storage protection of metadata (keys, policy). An owner can delegate the coin through an offline-transaction asynchronously with the blockchain network. A formal analysis, prototype implementation and further evaluation demonstrate that our scheme is provably secure and practically feasible.

Future Work. There is an insurmountable gap between the theoretical case and real application.  Although our scheme is proved to be theoretically secure, a lot of risks still exist in practical scenarios. The countermeasures to reduce these risks will be explored.

Acknowledgments. Rujia Li and Qi Wang were supported by Guangdong Provincial Key Laboratory (Grant No. 2020B121201001).

[1]
Rujia Li, Qin Wang, Xinrui Zhang, Qi Wang, David Galindo, and Yang Xiang.
An offline delegatable cryptocurrency system.
In 2021 IEEE International Conference on Blockchain and
Cryptocurrency (ICBC), pages 1–9. IEEE, 2021.

[2]
Rujia Li et al.
Poster: An offline delegatable cryptocurrency system.
Proceedings of the 28th Annual Network and Distributed System
Security Symposium (NDSS), Poster Session, available on

[3]
Satoshi Nakamoto et al.
Bitcoin: A peer-to-peer electronic cash system.

[4]
Gavin Wood et al.
Ethereum: A secure decentralised generalised transaction ledger.
In Ethereum Project Yellow Paper, 2014.

[5]
Muneeb Ali, Jude Nelson, Ryan Shea, and Michael J Freedman.
Blockstack: A global naming and storage system secured by
In 2016th USENIX Annual Technical Conference (USENIX ATC),
pages 181–194, 2016.

[6]
Jeff Reed.
Litecoin: An introduction to litecoin cryptocurrency and litecoin

[7]
Lewis Gudgeon, Pedro Moreno-Sanchez, Stefanie Roos, Patrick McCorry, and Arthur
Sok: Layer-two blockchain protocols.
In International Conference on Financial Cryptography and Data
Security (FC), pages 201–226. Springer, 2020.

[8]
Aggelos Kiayias and Giorgos Panagiotakos.
Speed-security tradeoffs in blockchain protocols.
IACR Cryptol. ePrint Arch., 2015:1019, 2015.

[9]
Daira Hopwood, Sean Bowe, Taylor Hornby, and Nathan Wilcox.
Zcash protocol specification.
GitHub: San Francisco, CA, USA, 2016.

[10]
Nicolas Van Saberhagen.
Cryptonote v 2.0, 2013.

[11]
Peilin Zheng, Zibin Zheng, Xiapu Luo, Xiangping Chen, and Xuanzhe Liu.
A detailed and real-time performance monitoring framework for
blockchain systems.
In 2018 IEEE/ACM 40th International Conference on Software
Engineering: Software Engineering in Practice Track (ICSE-SEIP), pages
134–143. IEEE, 2018.

[12]
Qin Wang et al.
Sok: Diving into dag-based blockchain systems.
arXiv preprint arXiv:2012.06128, 2020.

[13]
Alexei Zamyatin, Mustafa Al-Bassam, Dionysis Zindros, Eleftherios
Kokoris-Kogias, Pedro Moreno-Sanchez, Aggelos Kiayias, and William J
Sok: communication across distributed ledgers.
Cryptology ePrint Archive, 2019.

[14]
Gang Wang, Zhijie Jerry Shi, Mark Nixon, and Song Han.
Sok: Sharding on blockchain.
In Proceedings of the 1st ACM Conference on Advances in
Financial Technologies (AFT), pages 41–61, 2019.

[15]
Jan-Erik Ekberg, Kari Kostiainen, and N Asokan.
Trusted execution environments on mobile devices.
In Proceedings of the 2013 ACM SIGSAC Conference on Computer and
Communications Security (CCS), pages 1497–1498, 2013.

[16]
Victor Costan and Srinivas Devadas.
Intel sgx explained.
IACR Cryptology ePrint Archive, 2016(086):1–118, 2016.

[17]
Sandro Pinto and Nuno Santos.
Demystifying arm trustzone: A comprehensive survey.
ACM Computing Surveys (CUSR), 51(6):1–36, 2019.

[18]
David Kaplan, Jeremy Powell, and Tom Woller.
Amd memory encryption.
White paper, 2016.

[19]
Dayeol Lee et al.
Keystone: An open framework for architecting trusted execution
In Proceedings of the Fifteenth European Conference on Computer
Systems (EuroSys), pages 1–16, 2020.

[20]
Sinisa Matetic, K. Wüst, M. Schneider, Kari Kostiainen, G. Karame, and
Srdjan Capkun.
Bite: Bitcoin lightweight client privacy using trusted execution.
In IACR Cryptol. ePrint Arch., 2018.

[21]
Iddo Bentov, Yan Ji, Fan Zhang, Lorenz Breidenbach, Philip Daian, and Ari
Tesseract: Real-time cryptocurrency exchange using trusted hardware.
In Proceedings of the 2019 ACM SIGSAC Conference on Computer and
Communications Security (CCS), pages 1521–1538, 2019.

[22]
Raymond Cheng, Fan Zhang, Jernej Kos, Warren He, Nicholas Hynes, Noah Johnson,
Ari Juels, Andrew Miller, and Dawn Song.
Ekiden: A platform for confidentiality-preserving, trustworthy, and
performant smart contracts.
In 2019 IEEE European Symposium on Security and Privacy
(EuroSP), pages 185–200. IEEE, 2019.

[23]
Rujia Li et al.
An accountable decryption system based on privacy-preserving smart
In International Conference on Information Security (ISC),
pages 372–390. Springer, 2020.

[24]
Damon Williams.
Introduction to paypal.
Pro PayPal E-Commerce, pages 1–12, 2007.

[25]
Jie Guo and Harry Bouwman.
An ecosystem view on third party mobile payment providers: a case
study of alipay wallet.
info, 2016.

[26]
Sinisa Matetic, Moritz Schneider, Andrew Miller, Ari Juels, and Srdjan Capkun.
Delegatee: Brokered delegation using trusted execution environments.
In 27th USENIX Security Symposium (USENIX Security), pages
1387–1403, 2018.

[27]
Joshua Lind et al.
Teechain: a secure payment network with asynchronous blockchain
In Proceedings of the 27th ACM Symposium on Operating Systems
Principles (SOSP), pages 63–79, 2019.

[28]
Ben Fisch, Dhinakaran Vinayagamurthy, Dan Boneh, and Sergey Gorbunov.
Iron: functional encryption using intel sgx.
In Proceedings of the 2017 ACM SIGSAC Conference on Computer and
Communications Security (CCS), pages 765–782, 2017.

[29]
Manuel Barbosa, Bernardo Portela, Guillaume Scerri, and Bogdan Warinschi.
Foundations of hardware-based attested computation and application to
In 2016 IEEE European Symposium on Security and Privacy
(EuroSP), pages 245–260. IEEE, 2016.

[30]
David Bernhard, Véronique Cortier, David Galindo, Olivier Pereira, and
Bogdan Warinschi.
SoK: A comprehensive analysis of game-based ballot privacy
In IEEE Symposium on Security and Privacy (SP), pages 499–516.
IEEE, 2015.

[31]
Yehuda Lindell.
How to simulate it–a tutorial on the simulation proof technique.
Tutorials on the Foundations of Cryptography, pages 277–346,

[32]
Shafi Goldwasser, Silvio Micali, and Ronald L Rivest.
A digital signature scheme secure against adaptive chosen-message
SIAM Journal on Computing (SICOMP), 17(2):281–308, 1988.

[33]
Bitcoin testnet.
In https://coinfaucet.eu/en/btc-testnet/, 2020.

[34]
Don Johnson, Alfred Menezes, and Scott Vanstone.
The elliptic curve digital signature algorithm (ecdsa).
International Journal of Information Security, 1(1):36–63,

[35]
SECG SEC.
2: Recommended elliptic curve domain parameters.
Standards for Efficient Cryptography Group, Certicom Corp,

§ APPENDIX A. PROTOCOL WORKFLOW

This part provides an overview of the transaction workflow. It assists to demonstrate the operating mechanism of a TEEs-enabled delegation scheme and its corresponding connections between the blockchain network and users.

TEEs-based Delegation Scheme
Delegator   Delegatee   Blockchain

𝗁𝖽𝗅_𝒟 𝖧𝖶.𝖫𝗈𝖺𝖽(𝗉𝗆𝗌,𝖯_𝒟)

(𝗏𝗄_𝗌𝗂𝗀𝗇, 𝗉𝗄_𝒟) 𝖧𝖶.𝖱𝗎𝗇(𝗁𝖽𝗅_𝒟, 1^λ)

* 𝗏𝗄_𝗌𝗂𝗀𝗇

𝗁𝖽𝗅_𝒪 𝖧𝖶.𝖫𝗈𝖺𝖽(𝗉𝗆𝗌,𝖯_𝒪)

𝗊𝗎𝗈𝗍𝖾 𝖧𝖶.𝖱𝗎𝗇&𝖰𝗎𝗈𝗍𝖾(𝗁𝖽𝗅_𝒪,

𝗌𝗂𝖽, 𝗏𝗄_𝗌𝗂𝗀𝗇)

(𝗌𝗂𝖽, 𝖼𝗍_𝗋, σ_𝗋) 𝖧𝖶.𝖱𝗎𝗇(𝗁𝖽𝗅_𝒟,

𝗊𝗎𝗈𝗍𝖾,𝗉𝗄_𝒪, 𝗉𝗆𝗌)

*(𝗌𝗂𝖽, 𝖼𝗍_𝗋, σ_𝗋)

𝖧𝖶.𝖱𝗎𝗇(𝗁𝖽𝗅_𝒪, 𝗏𝗄_𝗌𝗂𝗀𝗇)

𝖼_𝗂𝗇𝗂𝗍 𝖧𝖶.𝖱𝗎𝗇(𝗁𝖽𝗅_𝒪, 𝗌𝗂𝖽)

𝖺𝖽𝖽𝗋 𝖧𝖶.𝖱𝗎𝗇(𝗁𝖽𝗅_𝒪, 1^λ)

𝖻_𝗎𝗉𝖽𝖺𝗍𝖾 𝖧𝖶.𝖱𝗎𝗇(𝗁𝖽𝗅_𝒪, 𝖺𝖽𝖽𝗋)

𝖳𝗑 𝖧𝖶.𝖱𝗎𝗇(𝗁𝖽𝗅_𝒪, 𝖺𝖽𝖽𝗋)

𝖼𝗍_𝗍𝗑 𝖧𝖶.𝖱𝗎𝗇(𝗁𝖽𝗅_𝒪, 𝖺𝖽𝖽𝗋)

𝖳𝗑 𝖧𝖶.𝖱𝗎𝗇(𝗁𝖽𝗅_𝒟, 𝖼𝗍_𝗍𝗑)

*𝖳𝗑 =

𝖻 𝖲.𝖵𝖾𝗋𝗂𝖿𝗒^𝖡(𝗉𝗄_𝖳𝗑,σ_𝖳𝗑)

The Transaction Flow of Delegation

Blockchainy_t  [dotted]build a secure channel

I_id = ζ_1^1/x_t = z_1^λ/x_t

= y_t^υλ/x_t = g ^υλ = ξ^υ

The identity tracing protocol.

§ APPENDIX B. RESOURCE AVAILABILITY

* Implementation Code: <https://github.com/TEEs-projects/DelegaCoin>

* Test Data: <https://github.com/TEEs-projects/DelegaCoin/tree/main/test_data>

* NDSS Poster Version: <https://www.ndss-symposium.org/wp-content/uploads/NDSS2021posters_paper_14.pdf>

* ICBC Conference Version: <https://icbc2021.ieee-icbc.org/program>

§ APPENDIX C. NOTATIONS

Featured Notations

Symbol         Item                   Functionalities
$\mathcal{O}$      Delegator     also known as coin owner, the person who sends the coins
$\mathcal{D}$      Delegatee       the person who receives the coins
$\mathcal{B}$      Blockchain     an ideal blockchain environment provides all types of basic functions
$\mathsf{Tx}$      Transaction       the transaction in blockchain network
$E_{\mathcal{O}}/E_{\mathcal{D}}$      Enclave       the Delegatee's/Delegator's Intel enclave instance
$\mathsf{TEE}$      TEEs       a real TEEs environment, sometimes used in superscript for indication
$\mathsf{hdl}$     Handle      an intermediate parameter when initiating  TEEs
$\mathsf{quote}$     Quote      a flag to request operations when running TEEs
$\mathsf{pms}$     Parameters       intermediate parameters when running  TEEs
$\mathsf{pk/sk}$     Key pair     the public key and private key to encrypt/decrypt states
$\mathsf{vk/sk_{sign}}$     Key pair     the key pair to identify a specific entity (delegatee)
$\mathsf{key_{seal}}$     Private key      a sealing key used to export the state to the trusted storage
$\mathsf{r}$     Private key      a symmetric encryption key $r$
$\mathsf{ct_{r}}$     Ciphertext     the ciphertext under a symmetric encryption key with $r$ inside TEEs
$\mathsf{b}$     Account balance     the subscript $\mathsf{init/deposit/update}$ means the status in different stages
$\mathsf{c}$       Encrypted balance      the balance that has been encrypted and transferred
$\sigma$     Signature     a valid signature, the subscript indicates its corresponding signer
$\mathsf{HW}$     Hardware      a ideal and secure hardware functionality used in proofs
$\mathcal{P}$     Program space      a program that contains a set of algorithms, instantiated as $P$
$\mathsf{O}$      Oracle      an environment that can provide ideal functionalities
$\mathcal{U}(\cdot)$      Oracle     a universal oracle can provide simulated answers
$\mathcal{S}$     Simulator      an ideal environment that can simulate some behaviours
$\mathcal{A}$     Adversary      an adversary who has some ability to launch attacks
$\mathsf{\lambda}$      Security parameter     a type of parameter to adjust the security level of algorithms
$\mathsf{negl(\lambda)}$      Negligible function     a function to show the negligible differences in security proofs
$\mathsf{Exp}$     Experiment      an experiment that show the game and operations in proofs
$\mathsf{PKE}$     Algorithm      an IND-CCA2 secure public key encryption scheme
$\mathsf{S}$     Algorithm      an existentially unforgeable (EUF-CMA) signature scheme
$\mathsf{SE}$     Algorithm     a IND-CPA secure symmetric encryption scheme

xbar stacked,
legend style=
legend columns=4,
at=(xticklabel cs:0.5),
axis y line*=none,
axis x line*=bottom,
tick label style=font=,
legend style=font=,
label style=font=,
bar width=4mm,
xlabel=Time in ms,
yticklabels=Average, Maximum, Minimum,
area legend,
enlarge y limits=abs=0.625,
[findOptimalPartition,fill=findOptimalPartition] coordinates
(23,0) (30,1) (19,2) ;

[storeClusterComponent,fill=storeClusterComponent] coordinates
(40,0) (55,1) (28,2) ;

[dbscan,fill=dbscan] coordinates
(276,0) (318,1) (232,2) ;

[constructCluster,fill=constructCluster] coordinates
(5,0) (9,1) (3,2) ;

generation,verification, propagation, response

Execution Time (ms) of Different Operations

Remote Ascertain add
$sk_p, M, (S_{N_0}^r, S_{N_1}^{r}, \dots, S_{N_n}^{r})$
i $\leq$ n -1
$sroot = \mathsf{Hash}(S_{N_i}^{r}, S_{N_{i+1}}^{r})$

$root = \mathsf{Hash}(sroot,M)$

$S^{r} = \mathsf{Sign}(sk_p, root)$

i $\leq$ n -1
$P_i = \mathsf{GenProof}(S_{N_i}^{r})$

$PF = PF + P_i$

$P_M,P_B,P_S = \mathsf{Parse}(PF);$
return $P_M,P_B,P_S$;

[System Setup]

[Coin Deposit]

[Coin Delegation]

[Coin Spend]

Testing Results For Functionalities