An Accountable Decryption System Based on Privacy-Preserving Smart Contracts

. Accountability is a fundamental after-the-fact approach to detect and punish illegal actions during the execution of a warrant for accessing users’ sensitive data. To achieve accountability in a security protocol, a trusted authority is required, denoted as judge , to faithfully cooperate with the rest of the entities in the system. However, malicious judges or uncooperative protocol participants may void the accountability mechanism in practice, for example by fabricating fake evidence or by refusing to provide any evidence at all. To provide remediation to these issues, in this paper we propose Fialka , a novel accountable de-cryption system based on privacy-preserving smart contracts (PPSC). The neutrality that is inherent to a secure blockchain platform is inherited by PPSC which are then used in our approach as an accountable key manager as well as a transparent judge. To the best of our knowledge, we present the ﬁrst PPSC-based accountable decryption system to increase the transparency of warrant execution with formal deﬁnitions and proofs. Furthermore, we provide and evaluate a prototype implementation using the PPSC-enabled platform Oasis Devnet, which additionally demonstrates the feasibility of Fialka.


Introduction
Accountable cryptographic protocol is increasingly crucial in sensitive personal data protection. We focus on the following scenario. Law enforcement or intelligence agencies may demand access to personal encrypted data held by service providers, and sometimes even require access to the communication metadata that is closely related to sensitive information of individuals. In most cases, a granted warrant is needed from a legal authority. However, data owners have no way to know when and how law enforcement collects and accesses their sensitive data. In particular, abuses of granted warrant of decryption may easily happen since the overseers cannot verify whether the practical investigation activities match the scope permitted in the document. Therefore, accountability mechanisms is a critical after-the-fact remediation technique to deter investigators, since it provides an instant evidence to detect malicious or deviant behaviors, which increases the transparency of warrant execution.
However, achieving accountability is tricky, and requires additional roles involved. The investigators cannot autonomously convince others of the accountability of their actions. They need to resort to one or more neutral trusted parties, usually named judge(s), to audit their actions. More specifically, an accountability mechanism requires each investigator to generate evidence on their warrant execution. This evidence is then examined by the judge to detect dishonest behaviors or declare the examined participant compliant. This approach relies heavily on faithful cooperation of the judge and the investigator, as a malicious judge or dishonest investigator may undermine the accountability mechanism. If the investigator rejects to cooperate with the judge in order to provide the required evidence, or if the judge themselves examine fake evidence or apply the wrong examination procedure, outsides cannot audit investigators' decryption actions. In this paper, we generalise the above example as a standard case, in which an investigator obtains an order from a court, and his access of users' data needs to be audited by the judge. The discussed challenges lead to the following research question: Is it possible to design an accountability mechanism guaranteeing that (1) the judge honestly checks the evidence; (2) the investigator does not refuse to provide the evidence trail of their actions?
Based on the previous discussion, the answer would intuitively be "NO". Firstly, it is difficult to guarantee that a judge will always be secure and reliable. Even if the judge claims to be neutral, she faces the threat of being attacked or provided with misleading evidence. Once the judge is compromised, the accountability mechanism fails as it cannot be applied. Undoubtedly, multiple judges may mitigate such concerns, but the judge collusion issue cannot be effortlessly overcome. Secondly, asking the investigator to neutrally create a piece of honest evidence also confronts difficulties. The isolated local execution environment makes it potentially easy and profitable for the investigator to generate fake evidence while incurring a low risk of being detected. Several proposals [3,9] employed a certain trusted hardware to aid the evidence generation. Intuitively, physical hardware is more secure and reliable since the evidence logic and its measurement are hardcoded in non-volatile storage. However, the risk of compromised hardware still exists [17].
Blockchain-based smart contracts [26,27] have been used in [4,14,23] as a building block to implement the judge. Roughly speaking, a smart contract is composed of a set of protocols to be automatically executed in a distributed network, which naturally guarantees the neutrality and behaviour of the judge thus obtained. However, the input/output data of the smart contract is transparent to the public, which limits its usage in some scenarios. For instance, private key-dependent protocols such as decryption are executed in an isolated local environment. A transparent smart contract cannot prevent the investigator from producing fake evidence if it does not have access to the secret key material. But in the latter case, the secrecy of the private key material would be compromised. Privacy-preserving smart contracts (PPSC) [6,13,16,25,29] inherit the security, availability and neutrality benefits of smart contracts while additionally protecting the privacy of the contract data. It naturally could act as a high-level cryptographic primitive to aid in the evidence generation involving local protocol executions. For example, PPSC could be used to implement a private key manager to make decryption accountable.
In this paper, we propose Fialka, a novel transaction-triggering accountability framework using PPSC to make investigators accountable for executing decryption calls. Our framework prevents the decryption queries evidence from being maliciously generated (e.g. hidden) while guaranteeing the authenticity of the evidence. More precisely, Fialka combines PPSC with an IND-CCA secure public key encryption (PKE) scheme [15] at the protocol level to construct an accountability mechanism. PPSC cryptographically hides a secret random number used as an additional decryption key, where external investigators have to interact with PPSC for the execution of decryption warrant. The secret key will be extracted by invoking the decryption-related smart contract, which consequently generates a transaction-based evidence as an on-chain record. After that, another smart contract plays the role of the judge who transparently checks the transaction to decide whether the decryption is legal in a specific setting. The accountability is thereby achieved. Additionally, our framework inherits the benefit of high availability from the underlying blockchain protocol. This further improves reliability of the PPSC-based judge. Our contributions are summarized here: -We propose an accountable decryption system called Fialka that combines the techniques of PPSC and PKE. -We formally define our system and provide a security analysis of its accountability properties, namely fairness and completeness. -We provide a prototype implementation based on the PPSC platform Oasis Devnet [1,8], and evaluate its running time and gas cost.
The rest of our paper is structured as follows. Some related studies are discussed in Section 2. Definitions and building blocks are detailed in Section 3. In Section 4, we present the formal model with its property definitions. In Section 5, we provide the design of Fialka. Both the proof and security analysis are presented in Section 6. Implementations and evaluations are discussed in Section 7 and Section 8. Finally, Section 9 presents summaries and future work.

Related work
The smart contract-based accountability approach has been studied comprehensively recently. Xu et al. [28] proposed a remotely decentralized data auditing scheme for network storage service, where accountability is achieved by involving smart contract as a third-party auditor to notarize the integrity of outsourced data. Azaria et al. proposed MedRec [4], in which an Ethereum [27] smart contract is used as a meta-data agent to manage the permission of data usage, making patients' choices accountable. Neisse et al. [23] proposed a blockchainbased framework for data accountability and provenance tracking. However, a pure smart contract does not provide a complete accountable protocol, since it cannot guarantee the authenticity of the input (i.e. the submitted evidence). In other words, even if the smart contract is neutral and trustful, a client may provide fake evidence to the smart contract without being detected.
Several solutions have been proposed to ensure the authenticity of the submitted evidence. Among them, equipping entities with secure hardware devices [3,24,17] is an attractive approach. Alder et al. [3] employed Intel SGX [10] to produce a verifiable measurement of the resource usage in each function invocation. Luo et al. [21] applied the Intel SGX with blockchain to a data sharing scheme, where the decryption process also relied on the confidentiality of secure hardware devices. The hardware-based approach is intuitively reliable and robust, since trusted hardware devices cannot change the evidence generation rules once loaded. However, the security cannot be guaranteed when adversaries successfully attack the hardware. The approach using multiple hardware may mitigate such security concerns to a certain extent. Unfortunately, the efficiency issue and incentives issue cannot be easily overcome. Another promising approach is directly employing the protocol execution result as the evidence, such as using the ciphertext and the private key as evidence. A typical example is accountable identity-based encryption [11,12,19], where a judge can decide whether a PKG is malicious by showing cryptographic proofs that contain the decryption key. However, such an approach lacks practicality.
Privacy-preserving smart contract (PPSC) is a special contract that aims to make the contract state private. The techniques on PPSC have been studied extensively in the recent years. Enigma [29] provided a decentralized confidential computation platform by employing multi-party computation. Hawk [16], Zether [6] and Zkay [25] realized privacy-preserving smart contract by heavily relying on zero-knowledge proofs. Ekiden [8] and Microsoft Coco framework [22] employed Intel SGX to achieve confidential smart contracts. Essentially, PPSC is a decentralized confidential computing technology, which inherits the benefit of transparent execution from a smart contract while additionally protecting the privacy of contract data. Our accountable system leverages the main benefits of PPSC. The transparent execution of smart contracts ensures the judge honestly checks the evidence, and the trigger mechanism of contract execution enforces investigators to invoke PPSC through transactions, which ensures investigators neutrally provide the evidence.

Preliminaries
Let λ be the security parameter, and negl(λ) be a negligible function. The challenger and adversary are represented as C and A, respectively. We use the nota-tion to denote the game in security deduction, adv to represent the advantage that the adversary holds, and the notation "≈" to show these two games are computationally indistinguishable. The message space is denoted as M.

Privacy-Preserving Smart Contract
Smart contract was first proposed by Nick Szabo [26] and further developed by Ethereum [27] in the blockchain system. A blockchain-based smart contract consists of two mutually interacting components: contract state and operational code [27]. The contract state covers the input and output of the operational code, while operational code specifies operations/commands to store or transfer the contract state. The intuitive target for a privacy-preserving smart contract is to make the contract state private. However, purely protecting the privacy of the state against the public is not sufficient, especially when multiple entities are involved in one contract to finish complex cryptographic tasks. The state in a contract is required to reach a new consensus view after the execution of operational codes, in which this rule is followed by PPSC projects such as Zether [6], Ekiden [8] and Oasis Devnet [1]. Thus, we capture two main PPSC principles: P.1 the contract state should be protected against the public; P.2 the authorized entities should see the same private data view.
PPSC-based Accountability. The initial contract state and the operational code will reach consensus after the successful deployment. After that, two approaches can trigger the execution of the operational code: the internal schedule code and the external message call. The first approach allows the operational code to execute periodically. However, it cannot complete a complex task due to massive gas consumption [27]. Thus, to trigger the execution, an external message call with sufficient gas is crucial. PPSC inherits the state triggering mechanism from smart contracts, namely, the state-changing is based on external message call. For example, Oasis Devnet [1] requires an external caller to firstly build a secure channel with the TEE-protected smart contract, and then the transition of the private state is accomplished through this channel when a transaction call is provided. Origo Network [2] reveals the private input to an off-line executor and then allows the executor to provide a ZKP-proof transaction for online state transferring. Zether [6] funds the Zether tokens (ZTH) by sending some Ethereum [27] tokens (ETH) and converts ZTH back to ETH by sending a ZK-proof transaction. In summary, a transaction is required to trigger the execution and obtain the state from PPSC. Therefore, by tracing the sender who sends the transaction, the auditor implicates the wrongdoing of the contract caller. Based on the above analysis, we give a formal definition of PPSC.
Definition 1 ( P P SC) A Privacy-Preserving Smart Contract (PPSC) is a private state machine built on top of a blockchain system and can be modeled by 5-tuple (S, S , T , s, B) and a transition function f : S ⊗ T B − → S , where S represents a set of private state with the initial state s, S is the new state set after the specified operations, T means the publicly visible transactions that can trigger the execution of a contract, and B represents the blockchain oracle which provides the execution environment.
The deployment is triggered by a transaction Tx, where Tx ∈ T . It takes the binary code < bytecode > as input, and outputs the private state s. The contract is compiled into < opcode > and < reqcode >, where < opcode > specifies the operation set to be executed and < reqcode > defines the conditions depending on which the operation of < opcode > can be conducted.
-Transfer < input > ⊗ S ⊗ Tx B − → S : By sending a transaction Tx with the input < input >, the current private state S is transited to the new private state S under the blockchain oracle B. The new state S returns only when Tx satisfies the condition defined in < reqcode >, i.e., Tx ∈ < reqcode >.
-Access S ⊗ Tx B − → S: By sending a query transaction Tx through the blockchain oracle B, the private state returns only when Tx satisfies the condition predefined in < reqcode >, i.e., Tx ∈ < reqcode >.
Based on the above syntax, we provide four PPSC security properties: stateprivacy, state-consistency, transaction-transparency and transaction-unforgeability. The state-privacy guarantees that the state is protected against the public (Principle P.1). Only the caller who satisfies the predefined conditions can learn the state. Meanwhile, the state-consistency ensures that a smart contract shares the same data view after operational code is executed (Principle P.2). The transaction-transparency ensures that transactions triggering the execution of PPSC can be freely queried, while the transaction-unforgeability guarantees the transactions (as evidence) are reliable and authentic without being forged or cheated. PPSC is secure when these four security properties are all satisfied.
Definition 2 PPSC achieves state-privacy, if for all PPT adversaries A, there exists a negligible function negl(λ) such that adv privacy A,ppsc (λ) < negl(λ), where adv privacy A,ppsc (λ) is the advantage that A successfully obtains the private state without satisfying the condition predefined in < reqcode >.
Definition 3 PPSC achieves state-consistency, if for all PPT adversaries A, there exists a negligible function negl(λ) such that adv cons A,ppsc (λ) < negl(λ), where adv cons A,ppsc (λ) is the advantage that A obtains a valid state S through the algorithm Transfer in which s does not belong to the state set S, i.e., s / ∈ S.
Definition 4 PPSC achieves transaction-transparency, if for all PPT adversaries A, there exists a negligible function negl(λ) such that adv tran A,ppsc (λ) < negl(λ), where adv tran A,ppsc (λ) is the advantage that A successfully obtains a transaction Tx through calling the algorithm Transfer with the condition Tx / ∈ T .
Definition 5 PPSC achieves transaction-unforgeability, if for all PPT adversaries A, there exists a negligible function negl(λ) such that adv unforg A,ppsc (λ) < negl(λ), where adv unforg A,ppsc (λ) is the advantage that A successfully forges a transaction Tx and obtains the state through Tx .

Decision Linear Assumption
Decision Linear Assumption [5,15] is based on the Linear Problem. Due to limitation of space, we skip a full definition and refer to Appendix A for details.

System Overview
Our system consists of four entities (see Fig 1.a): common users (sender/receiver), investigator, key management smart contract (PPSC-KM), and auditor smart contract (PPSC-AD). PPSC-KM is used to manage investigators' decryption keys. PPSC-AD is employed as a "judge" to decide whether the event of the investigator's decryption is conducted under the court-issued order. A detailed workflow is shown as follows. The sender encrypts messages with a random number, which is hidden in PPSC-KM, and then it sends the encrypted message to the receiver. The receiver decrypts the ciphertext as normal. Meanwhile, the investigator who obtained a court-issued order decrypts the ciphertext by fetching the random number from PPSC-KM. When a query is sent to PPSC-KM, the actions will be recorded through a transaction as the evidence. Next, PPSC-AD will check the evidence to report malicious decryption. In our protocol, PPSC-KM and PPSC-AD are, respectively, abbreviated as c km and c ad for simplicity. Formally, we provide the general construction as follows. Setup (pms, c km , c ad ) ← Setup(1 λ , codes). The algorithm takes as input a security parameter λ and binary codes codes, and returns public parameters pms and two contracts c km , c ad .
Key Generation (pk, sk, tk) ← KeyGen(pms). The algorithm takes as input pms, and returns receiver's key pair (pk, sk), and a secret tag key tk.
Registration s B ← − Register(tk,P ). The algorithm takes as input a master key tk and accountability policiesP , and returns an initial state s ∈ S. The tk and policiesP are added to c km and c ad , respectively.
Encryption ct ← Encrypt(tk, pk, m). This algorithm takes as input tk, pk, and a message m, and then returns a ciphertext ct.
Decryption m ← Decrypt(sk, ct). The algorithm takes as input sk, ct, and returns m ∈ M. r 1 , s, ct). This algorithm takes as input a random number r, r 1 , and s (including tk) calls the algorithm Transfer described in Section 3.1, and returns m ∈ M.
Inspection true/false B ← − Inspect(Tx,P ). This algorithm takes as inputP and Tx, and returns the inspection result. The result true indicates that the authorized decryption is legitimately executed under the warrant, and vice versa.
The procedure of Decryption represents normal decryption run by offline users, whereas Warrant Decryption is run by the investigators who are forced to leave evidence each time of decryption. Meanwhile, the access control conditions in c km and the accountability policies in c ad are set as the same. We notice that the logic of Warrant Decryption might be confusing: the c km has defined the access control conditions for investigators. Is the accountability necessary for investigators' decryption? We clarify that access control and accountability in our system play different roles. The access control condition in c km is similar to an order issued by the court, which describes the actions that an investigator should do but not yet, whereas the accountability policies in c ad are responsible for checking the actions an investigator has done (e.g., whether an investigator has executed the decryption under a warrant). We define malicious decryption as: the investigator's decryption does not match the actions permitted in the issued orders.

Security Definitions
Our Fialka system is denoted by Π, and above algorithms are abbreviated as: Set, Gen, Reg, Enc, Dec, WDec, and Insp, respectively. We assume an investigator has already obtained a warrant from a court, and his access to users' plaintext needs to be audited by the judge. Inspired by [18], the investigator should obtain fair treatment, neither being framed for the legitimate investigation nor being escaped from the punishment for wrongdoings. We captures two properties w.r.t accountability: fairness and completeness.
Fairness. This property prevents the judge from framing honest investigators. An honest investigator should follow the pre-defined policies and return true. We consider the adversary A who imitates an honest investigator, and then maliciously executes the warrant/order attempting to frame him.
Definition 6 (Fairness) Fialka satisfies fairness, if for all PPT adversaries A, there exists a negligible function negl(λ) such that adv fair A,Π (λ) < negl(λ) where adv fair A,Π (λ) is the advantage of A wins the game fair defined as, -Initialization . The system configures the parameters pms = ⊥, and creates c km and c ad by running the algorithm Set. Then, C generates the secret key tk by running the algorithm Gen. Next, C registers the tk and decryption policiesP to the c km and c ad , respectively. -Actions . At each round, the adversary A and the challenger C execute the following algorithms. (1) A generates the key pair (sk a , pk a ) by running the algorithm Gen.
(2) C inputs the public key pk a , message m, a random numbers r and a secret key tk, and then obtains the ciphertext ct by running the algorithm Enc. Completeness. This property guarantees that the judge always punishes the users who misbehave. To define completeness, we consider an adversary A aims to evade the responsibility of illegally executing the authorized decryption.

Concrete Instantiation
In this section, we present an instantiation of Fialka based on Kiltz's PKE protocol [15] and the Oasis Devnet [1,8]. Kiltz's PKE is an efficient and IND-CCA secure scheme with a tight security reduction, while Oasis Devnet is an SGXbacked PPSC platform with a rigorous security proof under the Universal Composability (UC) framework [7]. In this instance, PPSC-KM manages a secrete random number as the investigator's decryption key and its access permission through the SGX enclave, and the PPSC-AD audits the transactions, and then reports the investigator's malicious decryption. Specifically, a decryption key using for investigation is loaded in PPSC-KM and hidden in an enclave, which forces the outside investigator to fetch it, and further leaves the transactionbased evidence that will be audited by PPSC-AD. Note that SGX-based PPSC is an example by hiding the secret key inside the hardware, and other approaches can also achieve the same goal, such as cryptographically hiding secret key by ZKP. Our framework is compatible with various aforementioned PPSC technologies [6,13,16,25,29]. Importantly, our construction can easily be extended to other accountable PKE protocols without significant modifications.
Setup (pms, c km , c ad ) ← Setup(1 λ , codes). The algorithm takes as input a security parameter λ, and returns public parameters including the multiplicative cyclic group G with prime order p. Then, it chooses two collision resistant hash functions H 1 : {0, 1} → Z p and H 2 : G × G → Z p . Next, it takes as input contract binary codes, and calls the algorithm Deploy (defined in Section 3.1), and finally returns two contracts c km and c ad .
Key Generation (pk, sk, tk) ← KeyGen(pms). The algorithm is run by the sender and receiver. The receiver runs the algorithm to generate her key pair (pk, sk), and the sender runs the algorithm to obtain a secret tag key tk.
Registration s B ← − Register(tk,P ): The algorithm is run by the sender. It takes as input tk and policiesP , and outputs contract initial state s. In particular, the tag key tk is registered into c km . The policiesP are added to c ad by the means of external message calls (see Section 3.1). The privacy of tk and s are protected by the SGX enclave. More details can be found in our implementation.
Encryption ct ← Encrypt(tk, pk, m). This algorithm is run by the sender. It takes as input tk, pk, and a message m, returns a ciphertext ct. pk = (G, p, g 1 , g 2 , z, u 1 , u 2 ); r 1 , r ← − Z p ; Decryption m ← Decrypt(sk, ct). This algorithm is run by the receiver. It takes as input the receiver's secret key sk, the ciphertext ct, and returns m ∈ M. P arse ct as(C 1 , C 2 , D 1 , D 2 , E, V ); r 1 , s, ct). This algorithm is run by the investigator. It takes as input r, r 1 and the private state s (including tk), and then calls the Transfer algorithm to execute the function r 2 ← H 1 (tk|r) in an isolated environment provided by the SGX. This calling progress is represented in the form of a transaction Tx. P arse ct as(C 1 , C 2 , D 1 , D 2 , E, V ); r 2 , Tx ← Transfer(s, r); Inspection true/false B ← − Inspect(Tx,P ). This algorithm is run by c ad . It takes as inputP and Tx, and returns inspection result. The true indicates the warrant decryption satisfying the policies, and vice versa.
Here, the correctness of our construction is easy to check as we have Note that the random numbers s 1 and s 2 are used for implicitly testing if the ciphertext is consistent with tag τ [15]. We see that K = z r1+r2 = g x1r1+x1r2 Then, we observe that K = K = K . Thus, both the receiver and investigator can obtain the message m by

Security Proof
Theorem 1 (Fairness) Assume that the SGX-based PPSC is secure, our construction Fialka satisfies the property of fairness.
Proof Suppose that there exists an adversary A who wins the fairness game fair with a non-negligible advantage. Then, we transform an adversary A against F airness into adversaries against PPSC security. Next, we describe a sequence of games to finish the proof.
Lemma 1 (SGX-based PPSC [8,20]) Our SGX-based platform is a secure instantiation of PPSC whose protocols match the ideal functionality in the UC framework. More details can be found in [8].
Game 0 . This is an unmodified game. Trivially, the winning probability of this game equals the advantage of A against fairness game, namely, adv fair A,Π (λ). Game 1 . In this game, when A calls C, we disallow C to call contract c km . Game 2 . In this game, when A calls C, the transaction-based evidence is not allowed to be given to the c ad . Instead, the evidence is randomly selected for auditing.
Obviously, the winning probability of the game 2 , denoted as adv 2 A,Π (λ), is negligible, since the transaction-based evidence is randomly selected. Next, to find out the differences between these games, we define the following events.

E[a1]
: forging an evidence. The event E[a1] implies that the adversary B 1 forges a valid transaction Tx * without update c km , denoted as ¬Transfer.

E[a2]
: forging an inspection result. The event E[a2] implies that the adversary B 2 forges an inspection result, where the originally "true" in the algorithm Inspect is modified to be "false". Theorem 2 (Completeness) Assume that SGX-based PPSC is secure and Kiltz's full PKE scheme [15] is secure against chosen-ciphertext attacks, Fialka satisfies completeness.
Proof The concrete proof can be found at Appendix B.

Implementation
In this section, we discuss the implementation 1 of our instantiation based on the SGX-based PPSC platform Oasis Devnet [1,8] (version 2.0). Our implementation (see Figure 1.b) has two components: the client-side and the server-side. The client-side is run by the sender, receiver and investigator, while the server-side is run by the PPSC platform. The client-side covers four algorithms: Set, Gen, Enc, Dec. They are implemented by 1000+ lines of Javascript codes in total, containing the packages of client and client-connector. The client implements basic operations executed by end-users at local, while client-connector builds a bridge between the client-side and the server-side. The server-side consists of two pieces of privacy-preserving smart contracts: PPSC-KM and PPSC-AD. PPSC-KM covers the algorithms CGen, Reg and Trans 2 , while PPSC-AD includes the algorithm Insp. Both of them are implemented in Rust. PPSC-KM protects private decryption keys by using the enclave technology from Intel SGX [10], while PPSC-AD determines whether the decryption is legal or not by checking the security policies.
To be specific, after a successful deployment of the contract PPSC-KM and PPSC-AD, the evidence inspection algorithm Insp and the investigator's key generation algorithm (by revoking Trans) as well as their access conditions, will be compiled as the binary codes and replicated to the enclaves [10] in SGXpowered blockchain nodes. Then, an encrypted contract state containing the investigator's key H 1 (tk|r) reaches an agreement across distributed blockchain nodes. After that, to obtain the key from PPSC-KM, two requirements must be fulfilled: (1) a transaction with the input satisfying access conditions should be provided; (2) An encrypted and authenticated channel connected to enclaves should be established (after a successful attestation [1,8,10]). Then, an invoked progress will be executed in the form of a transaction, and remains visible and immutable which could be publicly accessed. Each entity is able to see/witness the progress of obtaining the investigator's key, but no entity except the contract caller, knows the exact output (key) of the smart contract. Subsequently, PPSC-AD audits the transactions through an internal query to detect suspicious activities. Essentially, the privileges of the Trans algorithm are protected and managed in a CPU-level by Intel SGX. Only designated investigators should be allowed to access this secret key. We also notice that our implementation only provides one-off auditing, since it can only trace the records when the first time an investigator extracts the secret key. Our implementation provides a prototype to demonstrate the feasibility.

Evaluation
We first provide the performance evaluation on average CPU-time, representing the consumed time since the operation starts. The evaluation contains all the algorithms, and the testing environment is set as follows. The client-side runs on a Dell precision 3630 Tower with 16GB of RAM and one 3.7GHz six-core i7-8700K processors running Ubuntu 18.04. The server-side runs on a blockchain node, which is provided by Oasis SDK [1,8]. CPU-time. The evaluation results illustrate some critical points. The offline operation Enc is the most time-consuming operation since the encryption covers the seven exponentiations. The offline operation Dec takes approximately half the time of that in encryption because it processes four exponentiations. On the contrary, blockchain-related operations CGen, Reg, Trans and Insp take much less than offline operations, since they do not have group mathematics computation. In particular, the operation Insp is the fastest operation, which indicates the efficiency of our accountability protocol. However, CPU-time is close to testing environment, inefficient to convince that our framework is practical. Therefore, we provide further evaluations on gas cost and latency for real-world scenarios.
Gas cost. The gas cost measures the amount of computational effort that a blockchain takes to execute an algorithm. The gas cost evaluation includes the operations of CGen, Reg, Trans and Insp. The operation CGen costs the most gas among all since the initial configuration of a smart contract has to be loaded. Fortunately, this bottleneck can be ignored, because each contract is created only once and can be reused multiple times. The cost of Reg is relatively high, since the public parameters are needed to store on smart contracts. The cost of Trans and Insp are relatively low due to simple online calculations, which indicates that our accountability protocol is financially feasible 3 . In a real-world setting, different investigators may call the functions in a same PPSC for decryption and auditing simultaneously. To demonstrate the practicability of our system, we simulate a distributed environment by increasing the number of invocations from different investigators. Specifically, we test the gas cost of Trans and of Insp along with a maximum 1000 invocations simultaneously. As shown in Fig.2, the outputs remains relatively stable under the variations, and the average cost of Trans reaches approximately 340k while Insp is about 250k. It matches our intuitive expectation, since the gas cost is theoretically independent with the number of investigators. Based on such results, our accountability framework is practically affordable which could be widely adopted.
Latency. Our latency test covers all the blockchain-related operations including CGen, Reg, Trans and Insp. Among them, CGen is the most time consuming, as the contract codes need to be compiled into the blockchain. The operation Reg also takes a long time because all parameters have to be configured into contracts. In contrast, the operations Trans and Insp are in low latency, due to the fact that they do not have sophisticated on-chain computations. We also provide a simulation by increasing the invocations in a distributed environment. Our simulation includes the most two frequently used functions in PPSC, namely Trans and Insp. As shown in Fig.2, the results turn out that the latency stably increases along with the growing number of invocations. Theoretically, numerous invocations will impose a heavy burden onto the distributed network, which may even cause the network failure or transaction stuck. We set an upper bound of invoking transactions with 1000 users at the peak. The testing results confirm our expectations. Weakness. The average latency of the operation Trans reaches approximately five seconds, which is the primary drawback of our implementation. Frankly speaking, our system, at least built on the current version of Oasis Devnet (version 2.0), cannot compatibly support the applications that require fast decryption, due to the latency constraints. However, it is worth noting that the execution of warrant focuses on finding criminal evidence, which is latency insensitive.

Conclusion
In this paper, we propose Fialka, a novel transaction-triggering accountable decryption system based on the privacy-preserving smart contracts. Our system utilizes PPSC to trace and detect the decryption evidence, which makes warrant execution accountable. To the best of our knowledge, we present the first PPSC-based accountability mechanism with formal definitions and proofs. The security analysis shows that our system holds the accountability properties of fairness and completeness. The implementation based on Oasis Devnet with the detailed evaluation indicates that our system is feasible and applicable. Future Work. Fialka is a composite framework containing PKE and PPSC. The definition and proof of our instantiation are complete and sound. However, SGXbased PPSC and its underlying blockchain are inherently hybrid systems with a sophisticated mechanism, making our assumption inevitably strong. The possibility to weaken the assumption will be further explored.