Fine-Grained and Controllably Redactable Blockchain with Harmful Data Forced Removal

Notoriously, immutability is one of the most striking properties of blockchains. As the data contained in blockchains may be compelled to redact for personal and legal reasons, immutability needs to be skillfully broken. In most existing redactable blockchains, fine-grained redaction and effective deletion of harmful data are mutually exclusive. To close the gap, we propose a fine-grained and controllably redactable blockchain with harmful data forced removal. In the scheme, the originator of the transaction has fine-grained control over who can perform the redaction and which portions of the transaction can be redacted. (e redaction transaction is performed after collecting enough votes from miners. All users can provide the index of the block containing the harmful data to receive rewards, which are borne by the malicious user who initially posted the data. Miners can forcibly remove the harmful data based on the index.(emalicious user will be blacklisted if the reward is not paid within a period of time, and any transaction about such user will not be performed later. In addition, the scheme supports the redaction of additional data and unexpended transaction output (UTXO) simultaneously. We demonstrate that the scheme is secure and feasible via formal security analysis and proof-of-concept implementation.


Introduction
e first application of blockchains is Bitcoin [1,2], which has revolutionized the financial industry. Ever since, hundreds of such cryptocurrencies rise which do not rely on a central trusted authority. e applications of blockchains go far beyond their use in cryptocurrencies [3][4][5][6]. Recently, blockchains have entered numerous domains of applications, such as supply chains, digital twins, insurance, healthcare, or energy. In brief, a blockchain is a decentralized, distributed, potentially public, and immutable log of objects.
Blockchains can be of different types. ey can be public as Bitcoin or Ethereum, where the consensus protocol is executed between many pseudonymous participants. Here, the blockchain can be read and written by everyone. Such public blockchains can also be viewed as permissionless because everyone can join the system, participate in the consensus protocol, and establish smart contracts. Blockchains, however, can also be private (also called enterprise or permissioned blockchains) such as Hyperledger, Ethereum Enterprise, Ripple, or Quorum. Here, all the participants and their (digital) identities are known to one or more trusted organizations. Actors have write and read permissions. Such private blockchains can thus be viewed as permissioned because they restrict the actors who can contribute to the consensus on the system state to validate the block transactions. Once an object (such as a block or a transaction) is included in the blockchain (be it private or public), it is persisted and cannot be altered ever again. While immutability is a crucial property of the blockchain, it is often desirable to allow breaking the immutability for personal and legal reasons. e debate about the immutability of the blockchain becomes more acute due to the adoption of the General Data Protection Regulation (GDPR) by the European Union (EU). Several provisions of the GDPR are essentially incompatible with the immutable blockchains. In particular, the GDPR imposes that the data have the right to be forgotten, while blockchains such as Bitcoin and Ethereum do not allow to remove any data [7]. In addition, by using the immutability of a blockchain, malicious users can broadcast illegal or harmful data, such as (child) pornography and violence information around the world by spending a small fee. e data will be permanently stored and cannot be modified after they are stable on the chain. It is an enormous challenge for law enforcement agencies such as Interpol [8,9]. One idea is to "filter" all incoming data to check for malicious content before inserting the data into the chain. However, the recent work of Matzutt et al. [10] showed that the above idea is not feasible. Hence, how to skillfully break the immutability of blockchains is an important and urgent problem to be solved.
To solve the above problem, Ateniese et al. [11] first introduced the concept of redactable blockchain and proposed an elegant solution based on chameleon hash functions [12]. e solution addresses the redaction problem of blockchains at the block level, which is coarse grained. e redactable blockchain should meet the following two properties: (1) the originator of a transaction can specify a fine-grained access control policy about who can modify the transaction and which portions of the transaction can be redacted; (2) the harmful information contained in the previous block can be removed. Unfortunately, there is no redactable blockchain that meets both requirements.
In this paper, we explored how to effectively realize the fine-grained redactable blockchain. Our thought for realizing fine-grained redaction and effective deletion of harmful data simultaneously is shown in Figure 1. In order to support fine-grained access control, a promising way is to adopt the policy-based chameleon hash function (PCH) [13], which allows the originator of a transaction to specify a fine-grained access control policy about who can modify the transaction. However, it may incur the following issue by adopting the PCH. e malicious originator of the transaction may design an access policy that only allows him/her to modify the transaction to store undeletable harmful information in a blockchain. is does not satisfy the second property. To solve the above problem, we try to combine the technology proposed in [14]. e technology allows all users to create removal transactions by spending some transaction fees. Miners then vote on the transaction, and the harmful information is removed if enough votes are collected within a period of time. Obviously, this does not motivate users to actively remove harmful information from the chain because the user is not only rewarded for doing so but also needs to spend transaction fees. In order to motivate users, in this paper, the users create removal transactions without spending transaction fees. If the transaction passes the verification, the originator will obtain the reward paid by the malicious user who posted the harmful information. In addition, this technique only supports the deletion of additional information in the block and needs to store some "old state," that is, the hash value of the original transaction.
In practice, the redactable blockchains should meet the following three properties: (1) the originator of a transaction can specify a fine-grained access control policy about who can modify the transaction and which portions of the transaction can be redacted; (2) the harmful information contained in the previous block can be removed; (3) the data type that can be redacted is various. In order to support the redaction of various data types, we adopt the idea of the scheme in [15]. In this paper, the blockchain protocol not only supports removing additional information of the block but also redacting UTXO in the transaction. In order to reduce the storage space, we try to adopt a policy-based sanitizable signature [16]. However, in this way, the number of blocks of the signed data cannot be changed, and the set of inadmissible blocks needs to be stored. To solve this problem, we propose an improved policy-based sanitizable signature which allows that the number of blocks of the message m can be changed.

Contributions.
In this paper, we first explore how to effectively realize the fine-grained redaction of blockchains while removing the harmful data. We then propose a finegrained and controllably redactable blockchain protocol with harmful data forced removal. In a nutshell, the contribution of this paper can be summarized as follows: (i) We propose a fine-grained and controllably redactable blockchain protocol with harmful data forced removal. Our scheme not only supports the usual redaction of transactions but also the forced removal of harmful information in the blockchain. e originator of the transaction can specify a finegrained access control structure about who can redact the transaction and which portions of the transaction can be redacted. Authorized users may spend transaction fees to initiate a redaction transaction to redact the above transaction. Any user can initiate a transaction that contains the index of the block included harmful information without spending transaction fees. If the block does contain the harmful information, the miner who creates the new block can forcibly delete the harmful information.
us, the harmful data can be removed; even the malicious users specify an access control that only they can modify the data. e user who provided the index of the block can receive the reward which is borne by the malicious user who initially posted the data. e malicious user will be blacklisted if the rewards are not paid within a period of time, and any transaction about the user will not be performed later. Furthermore, the scheme supports not only the redaction of additional data but also UTXO, i.e., unspent transaction outputs.
(ii) We present an improved policy-based sanitizable signature scheme, which is based on the scheme in [16]. In our scheme, the number of blocks of the signed data can be changed, and the set of inadmissible blocks does not need to be stored. Users who satisfy the access control policy can modify the portions of the signed data that are allowed to be modified. e authorized users can generate the valid signatures for the modified data without interacting with the original signer. e data owner does not need to collect the identities of the candidate authorized users in advance as the proxy signature schemes would require. (iii) We demonstrate that the proposed scheme is secure and feasible via formal security analysis and proofof-concept implementation. Specifically, we implement a full-fledged blockchain system, which achieves all the basic functionalities of Ethereum Enterprise. Separately, the blockchain system, including a subset of Ethereum Enterprise's script language, allows the authorized user to redact the transaction and the miner to delete the harmful data. We evaluate the performance of the blockchain system for chain validation in different scenarios. e results show that the redactable blockchain protocol produces only an insignificant (no more than 3.8%) overhead compared to the immutable blockchain.

Related Work.
e concept of sanitizable signature was introduced by Ateniese et al. [17]. A sanitizable signature scheme allows a sanitizer to update the signed data without interacting with the original signer. In order to ensure the security of the scheme, two necessary security requirements are defined in their scheme: (1) unforgeability, that is, only authorized sanitizers can generate the new valid signatures for the updated data; (2) transparency, that is, the updated data and their signatures are indistinguishable from the original information and corresponding signatures.
Unfortunately, they did not give a complete definition of the sanitizable signature nor did they provide the formal security analysis. Brzuska et al. [18,19] provided the formal definition of sanitizable signatures and gave the formalized definition of the basic security requirements. ey introduced five formal security requirements, unforgeability, immutability, privacy, transparency, and accountability, and analyzed the relationships between these security requirements. Canard et al. [20] proposed a generic construction of the trapdoor sanitizable signature. In this scheme, the sanitizer can generate the valid signature for the updated data after receiving the trapdoor key from the original signer. Using an accountable chameleon hash, Lai et al. [21] proposed an accountable trapdoor sanitizable signature. However, neither of the above two schemes gives the concrete construction of the sanitizable signature. After that, many concrete sanitizable signature schemes were proposed [22][23][24]. All of the above sanitizable schemes are not suitable for blockchain rewriting since none of the aforementioned schemes support fine-grained control over candidate sanitizers.
Attribute-based encryption schemes can provide finegrained access control [25][26][27]. In order to provide finegrained access control, some attribute-based sanitizable signature schemes are proposed [16,[28][29][30]. e scheme in [28] did not give the specific construct of the attribute-based sanitizable signature. e scheme in [29] did not support the expressive access structure. e scheme in [30] only provided an all-or-nothing solution for data modification. e number of blocks of the signed data cannot be changed, and the set of inadmissible blocks needs to be stored in [16]. In a real environment of blockchain rewriting, the number of blocks of the transaction may be changed, and the set of inadmissible blocks does not need to be contained in its signature. erefore, in this paper, we improve the policybased sanitizable signature scheme [16] and propose an Constructing a redactable blockchain that meets the following three properties: (1) The originator of a transaction can specify a fine-grained access control policy about who can modify the transaction and which portions of the transaction can be redacted (2) The harmful information contained in the previous block can be removed (3) The data type that can be redacted is various

Goal
(1) Adopt the policy-based chameleon hash function (PCH) [13] Does not satisfy the second property (3) The users create removal transactions without spending transaction fees and will obtain the reward paid by the malicious user (2) Try to combine the technology proposed in [14] Does not motivate users to actively remove harmful information (4) Adopt the idea of the scheme in [15] Does not support the redaction of various data types (5) Adopt the policy-based sanitizable signature [16] Needs to store some "old state" (6) Achieve the goal Security and Communication Networks improved policy-based sanitizable signature. In this paper, the number of blocks of the signed data can be changed, and the set of inadmissible blocks does not need to be stored. Furthermore, we present a fine-grained and controllably redactable blockchain protocol with harmful data forced removal based on the improved policy-based sanitizable signature scheme.

Organization.
e rest of this paper is organized as follows. In Section 2, we briefly review the preliminaries required in this paper. e system model and design goals are given in Section 3. In Section 4, we introduce the proposed improved policy-based sanitizable signature scheme. We describe the proposed blockchain protocol in Section 5. In Section 6, we introduce the security analysis of the proposed protocol. We evaluate the performance of the proposed protocol in Section 7. Finally, we come to the conclusion in Section 8.

Notions.
We list the notations used in our scheme in Table 1.

Access Structure. A collection
{ } is an access structure on U, where U denotes attributes' universe. If a set is contained in A, it is the authorized set. Otherwise, it is an unauthorized set. A collection A is monotone if C ∈ A for ∀B, C ∈ A and B⊆C.

Public Key Encryption.
A public key encryption scheme Π consists of the following five algorithms: (i) PPGen Π (1 κ ): this algorithm takes the security parameter κ as the input and outputs the public parameters PP Π . (ii) KGen Π (PP Π ): this algorithm takes the public parameters PP Π as the input and outputs the public and private key (pk Π , sk Π ). (iii) Enc Π (pk Π , m): this algorithm takes the public key pk Π and the message m as the input and outputs a ciphertext c. (iv) Dec Π (sk Π , c): this algorithm takes the private key sk Π and the ciphertext c as the input and outputs the message m. (v) KVrf Π (sk Π , pk Π ): this algorithm takes the public and private key (pk Π , sk Π ) as the input and outputs 1 if sk Π belongs to pk Π . Otherwise, it outputs 0.
e detailed definition of correctness and security of the public key encryption (PKE) is given in [16]. In this paper, we require correctness and IND-CCA2 security for PKE. [16] if for any probabilistic polynomial-time (PPT) adversary A, there exists a negligible function ] such that e corresponding experiment is depicted in Figure 2.

Digital Signature.
A digital signature scheme Σ consists of the following four algorithms: (i) PPGen Σ (1 κ ): this algorithm takes the security parameter κ as the input and outputs the public parameters PP Σ . (ii) KGen Σ (PP Σ ): this algorithm takes the public parameters PP Σ as the input and outputs signer's public and private key (pk Σ , sk Σ ). (iii) Sign Σ (sk Σ , m): this algorithm takes the private key sk Σ and the message m as the input and outputs the signature σ. (iv) Verf Σ (pk Σ , m, σ): this algorithm takes the public key pk Σ , the message m, and the signature σ as the input and outputs 1 if σ is valid. Otherwise, it outputs 0.
e formal security definition of the digital signature is given in [16]. In this paper, we require correctness and existential unforgeability (eUNF-CMA) for the digital signature.
e corresponding experiment is depicted in Figure 3.

Noninteractive Zero-Knowledge Proof (NIZK). Let
where L is a NP-language with associated witness relation R. A noninteractive proof system Ω for the language L consists of the following three algorithms: (i) PPGen Ω (1 κ ): this algorithm takes the security parameter κ as the input and outputs the common reference string (CRS) crs Ω . (ii) Prove Ω (crs Ω , x, ω): this algorithm takes CRS crs Ω , the statement x, and the corresponding witness ω as the input and outputs the proof π. (iii) Verify Ω (crs Ω , x, π): this algorithm takes CRS crs Ω , the statement x, and the proof π as the input and outputs 1 if π is valid. Otherwise, it outputs 0. e security of the noninteractive zero-knowledge proof (NIZK) is given in [16]. In this paper, we require completeness for NIZK. In addition to completeness, we require two standard security notions for zero-knowledge proofs of knowledge: zero knowledge and simulation-sound extractability. We define them analogous to the definitions given in [16]. Informally speaking, zero knowledge says that the receiver of the proof π does not learn anything except the validity of the statement. Definition 3. (completeness). A noninteractive proof system is called complete if for all k ∈ N, crs Ω ← r PPGen(1 k ), x ∈ L, ω such that R(x, ω) � 1, π← r Prove Ω (crs Ω , x, ω), it holds that Verify Ω (crs Ω , x, π).

Policy-Based Chameleon Hashes.
A policy-based chameleon hash (PCH) allows the user, who owns attributes' set that satisfied the access structure, to compute a hash collision [13]. Specifically, a PCH contains the following six PPT algorithms: (i) PPGen PCH (1 κ ): this is the public parameters' generation algorithm. It takes the security parameter κ as the input and outputs the public parameters PP PCH . (ii) MKeyGen PCH (PP PCH ): this is the master key generation algorithm. It takes the public parameter PP PCH as the input and outputs the master key pair (sk PCH , pk PCH ). (iii) KGen PCH (sk PCH , S): this is the user's secret key generation algorithm. It takes the master secret key sk PCH and the set of attributes S⊆U as the input and outputs the user's secret key sk S . (iv) Hash PCH (pk PCH , A, m): this is the hash algorithm. It takes the master public key pk PCH , the access structure A ∈ 2 U \ ∅ { }, and the message m as the input and outputs the hash value h and the randomness r.
(v) Verify PCH (pk PCH , m, h, r): this is the verification algorithm. It takes the master public key pk PCH , the message m, the hash value h, and the randomness r as the input and outputs a bit b � 1 if h and r are valid. Otherwise, b � 0. (vi) Adapt PCH (pk PCH , sk S , m, m ′ , h, r): this is the adaption algorithm. It takes the public key pk PCH , the user's secret key sk S , the message m, the modified message m ′ , the hash value h, and some randomness r as the input and outputs a new randomness r ′ .
e detailed definition of correctness and security of the policy-based chameleon hash is given in [13].

Policy-Based Sanitizable Signature.
A policy-based sanitizable signature (P3S) allows the user, who owns attributes' set that satisfied the access structure, to modify the data and generate the valid signatures for the modified data [16]. Specifically, a P3S contains the following ten PPT algorithms: (i) ParGen P3S (1 λ ): this is the public parameters' generation algorithm. It takes the security parameter λ as the input and outputs the public parameters PP P3S . (ii) Setup P3S (PP P3S ): this is the master key generation algorithm. It takes the public parameters PP P3S as the input and outputs the master key pair (sk P3S , pk P3S ).  (vi) AddSan P3S (sk P3S , pk san P3S , S): this is the secret sanitizing key generation algorithm. It takes the master secret key sk P3S , the sanitizer's public key pk san P3S , and the set of attributes S as the input and outputs the secret sanitizing key sk S for the sanitizer.
(vii) Verify P3S (pk P3S , pk sig P3S , σ, m): this is the verification algorithm. It takes the master public key pk P3S , the signer's public key pk sig P3S , the signature σ, and the corresponding message m as the input and outputs this is the new signature generation algorithm. It takes the master public key pk P3S , the signer's public key pk sig P3S , the sanitizer's secret key sk san P3S , the secret sanitizing key sk S , the signature σ, the corresponding message m, and the description of modification M as the input and outputs the new signature σ ′ for the modified message m ′ . (ix) Proof P3S (pk P3S , sk sig P3S , σ, m): this is the proof generation algorithm. It takes the master public key pk P3S , the signer's secret key sk sig P3S , the signature σ, and the corresponding message m as the input and outputs the proof π P3S . (x) Judge P3S (PP P3S , pk P3S , pk sig P3S , σ, m, π P3S ): this is the proof verification algorithm. It takes the public parameter PP P3S , the master public key pk P3S , the signer's public key pk sig P3S , the signature σ, the corresponding message m, and the proof π P3S as the input and outputs a bit b � 1 if the proof π P3S is valid. Otherwise, b � 0. e detailed definition of correctness and security of the policy-based sanitizable signature is given in [16].

Blockchain Protocol.
Let Γ denote an immutable blockchain protocol such as Ethereum Enterprise. e nodes in the blockchain protocol obtain their local chain C based on a common genesis block. e nodes in the blockchain protocol collect transactions in the whole blockchain ecosystem and then package these transactions into a new block. e chain becomes longer as nodes agree on a new block. Nodes can access the blockchain protocol through the following interfaces. (iv) Γ · broadcast(x): takes the transaction x as the input and broadcasts it to all nodes in the blockchain ecosystem. Figure 4, the system model of the proposed redactable blockchain protocol consists of four entities: the trusted authority (TA), the miners, the users, and the authorized users. Note that the model in this paper is similar to the model in [13]. It is more applicable to permissioned blockchains, such as Hyperledger, Ethereum Enterprise, Ripple, and Quorum.

System Model. As shown in
(i) Trusted authority (TA): trusted authority (TA) is fully honest and responsible for generating the signing private key for users who posted the redactable transaction, issuing the attributes and attributes' key for authorized users, and sending keys to miners.
(ii) Miners: miners are fully honest and have powerful computing resources. ey are responsible for packaging transactions in the network to generate the new block and removing harmful information from the previous blocks.
(iii) Users: users may be malicious. ey can post the usual transaction or the transaction containing the index of the block which includes harmful information to the network. Users get finegrained control over which users can redact their usual transaction and which portions of the transaction can be redacted. e malicious users may specify an access structure that only allows themselves and their conspirators to redact the transaction.
(iv) Authorized users: the authorized users are semihonest in the sense that they can modify the portions of the transaction that are allowed to be modified and generate the new valid signatures for the updated data that are indistinguishable from the signatures that the originator generated for the original transaction.

Design Goals.
In order to realize a "healthy" blockchain protocol, the proposed fine-grained and controllably redactable blockchain with harmful data forced removal should satisfy the following properties: (i) Controlled redaction: only authorized users can redact the portions of the transaction that are allowed to be redacted. (ii) Accountability: the authorized user who redacts the transaction can be tracked. (iii) Correctness: correctness ensures that the redacted blockchain is "healthy." Specifically, a "healthy" blockchain should meet the following characteristics: (a) Chain growth: let C 1 and C 2 denote two chains possessed by two honest users at rounds r 1 and r 2 , respectively. en, len(C 2 ) − len(C 1 ) ≥ τ· (r 2 − r 1 ), where τ is the speed coefficient and r 2 > r 1 . (b) Chain quality: generally speaking, the chain quality says that the ratio of adversarial blocks in any segment of a chain held by an honest party is no more than a fraction 0 < μ ≤ 1, where μ is the fraction of resources controlled by the adversary. (c) Editable common prefix: the usual common prefix says that if C 1 and C 2 are two chains possessed by two honest users at rounds r 1 and r 2 , for r 2 > r 1 , C 1 is a prefix of C 2 . It can be formally denoted as C k 1 ≤ C 2 , where C k 1 is the chain obtained by removing the last k blocks from C 1 , k ∈ N is the common prefix parameter. Note that the proposed editable blockchain inherently does not satisfy the common prefix. Suppose the voting phase for the redaction transaction T * i is still on at round r 1 . At round r 2 , the voting phase is complete, and T * i replaces T i , i.e., the redacted block B * i replaces B i . In C k 1 , the i-th block is B i instead of B * i as in C 2 . us, C k 1 is not the common prefix of C 1 and C 2 . We extend this definition. e chains C 1 and C 2 satisfy one of the following: e voting phase is complete, and

reat Model
Definition 4. (controlled redaction). Controlled redaction ensures that only authorized users can redact the portions of the transaction that are allowed to be redacted. In order to formally describe the controlled redaction, we introduce a game between the challenger C and the adversary A � (A 1 , A 2 ). Here, we consider two adversaries. One of the adversaries is the adversary A 1 , who does not possess the attributes' set which satisfies the access control policy. Another is the adversary A 2 , who tries to redact the inadmissible portions of the transaction. In order to show how A 1 and A 2 attack the redactable blockchain protocol, we introduce the game between the challenger C and adversaries A 1 and A 2 , respectively. Firstly, we describe the game between the challenger C and the adversary A 1 . Trusted authority (group manager) is viewed as a challenger C, and the unauthorized user is viewed as an adversary A 1 . is game includes the following phases: (i) Setup phase: the challenger C runs the ParGen P3S and Setup P3S algorithm to generate the public parameters PP P3S and the master private/public key pair (sk P3S , pk P3S ). en, C holds the master private key sk P3S locally. Finally, C sends the master public key pk P3S and the public parameters PP P3S to the adversary A 1 . (ii) Query phase: (a) KGenSan P3S queries: the adversary A 1 queries sanitizer's private/public key pair for the public parameters PP P3S . C runs KGenSan P3S algorithm and returns the private/public key pair (x 2 , y 2 ) to A 1 . (b) Sign queries: the adversary A 1 queries the signature for the master public key pk P3S , the signature for the transaction m, the set of admissible blocks A, and the access structure A. C runs KGenSig P3S to generate the signing key and then runs Sign algorithm to produce the   (iii) Challenge phase: the adversary A 1 adaptively chooses the authorized user's attributes' set S (A(S) � 0). en, A 1 runs Sanitize P3S algorithm to generate the challenged signature σ * for the challenged transaction m * . Finally, the adversary A 1 sends (S, m * , σ * ) to C. (iv) Verify phase: the adversary A 1 performs polynomial queries as in the query phase. Consider the adversary A 1 has made L queries, and let i�1 denote the set of information obtained through these queries. C runs Verify P3S (pk P3S , pk Sig P3S , A, A, m * , σ * ) algorithm and outputs a bit b 0 .
We say that the adversary A 1 wins if b 1 � 1. In the above game, we want to show that the adversary A 1 , who does not possess the attributes' set S such that A(S) � 0, should not generate the new valid witness for the transaction. e adversary's goal is to correctly generate the valid signature σ ′ for the transaction m * . We set the advantage of a polynomial-time adversary A 1 in this game to be Pr[b 1 � 1]. We say the proposed scheme satisfies the unforgeability of the signature if for any polynomial-time adversary A 1 , Pr[b 1 � 1] < (1/poly(n)) for sufficiently large n, where poly stands for a polynomial function. en, we describe the game between the challenger C and the adversary A 2 . Trusted authority (group manager) is viewed as a challenger C, and the authorized user is viewed as an adversary A 2 . is game includes the following phases: (i) Setup phase: the challenger C runs the ParGen P3S and Setup P3S algorithm to generate the public parameters PP P3S and the master private/public key pair (sk P3S , pk P3S ). en, C holds the master private key sk P3S locally. Finally, C sends the master public key pk P3S and the public parameters PP P3S to the adversary A 2 .
(ii) Query phase: (a) KGenSan P3S queries: the adversary A 2 queries sanitizer's private/public key pair for the public parameters PP P3S . C runs KGenSan P3S algorithm and returns the private/public key pair (x 2 , y 2 ) to A 2 . (b) Sign queries: the adversary A 2 queries the signature for the master public key pk P3S , the signature for the message m, the set of admissible blocks F, and the access structure A. C runs KGenSig P3S to generate the signing key and then runs Sign algorithm to produce the signature σ. Finally, C returns the signature σ to A 2 . (c) AddSan P3S queries: the adversary A 2 queries the sanitizer's attribute key for sk P3S , pk San P3S , and the attributes' set S such that A(S) � 1. C runs AddSan P3S algorithm and returns the sanitizer's attribute key sk S ←(σ sk S , sk S ′ ) to A 2 . (d) Verify P3S queries: the adversary A 2 queries the verification result for pk P3S , pk Sig P3S , σ, and m. C runs Verify P3S algorithm and returns the result to A 2 . (e) Sanitize P3S queries: the adversary A 2 queries the sanitizable signature for pk P3S , pk Sig P3S , sk San P3S , sk S , m, σ, and m ′ . C runs Sanitize P3S algorithm and returns the new signature σ ′ to A 2 . (f ) Proof P3S queries: the adversary A 2 queries (π P3S , pk) for pk P3S , sk Sig P3S , σ, and m. C runs Proof P3S algorithm and returns (π P3S , pk) to A 2 . (g) Judge P3S queries: the adversary A 2 queries the judge result for pk P3S , sk Sig P3S , σ, and m. C runs Judge P3S algorithm and returns the result to A 2 .
(iii) Challenge phase: the adversary A 2 adaptively chooses the authorized user's attributes' set S (A(S) � 1). en, A 2 runs Sanitize P3S algorithm to generate the challenged signature σ * for the challenged message m * which does not contain all inadmissible blocks. Finally, the adversary A 2 sends (S, m * , σ * ) to C.
(iv) Verify phase: the adversary A 2 performs polynomial queries as in the query phase. Consider the adversary A 2 has made L queries, and let i�1 denote the set of information obtained through these queries. C runs Verify P3S (pk P3S , pk We say that the adversary A 2 wins if b 1 � 1. In the above game, we want to show that the adversary A 2 , who redacts the inadmissible blocks, should not generate the new valid signature. e adversary's goal is to correctly generate the valid signature σ ′ for the message m * . We set the advantage of a polynomial-time adversary A 2 in this game to be Pr[b 1 � 1]. We say the proposed scheme satisfies controlled redaction if for any polynomial-time adversary A 2 , Pr[b 1 � 1] < (1/poly(n)) for sufficiently large n, where poly stands for a polynomial function.
Definition 5. (accountability). We say that the proposed fine-grained and controllably redactable blockchain with harmful data forced removal satisfies accountability if TA can extract signer's identity from any valid transaction's signature with nonnegligible probability.

The Improved Policy-Based
Sanitizable Signature

An Overview.
e workflow of the proposed blockchain protocol can be described as follows. Firstly, users can generate a local chain C based on the common genesis block genesis and initialize the redaction transaction list R, the removal transaction list D, the penalty payment transaction list P, and the blacklist L to be empty. After that, users run Γ · updateChain to obtain the longest chain in the blockchain network. When the user wants to redact the previous transaction, he/she first broadcasts a redaction transaction by spending some transaction fees. e transaction will be added to the list R if it is valid. e miners vote on the transaction. e transaction can be executed if enough votes are collected within a period of time as shown in Figure 5. When a user finds harmful information contained in a block, he/she creates a removal transaction containing the index of the block without spending transaction fees. Miners create Security and Communication Networks new blocks that contain at least one transaction in D and one in P if they are not empty. e miner removes the harmful information from the block according to the provided index. Meanwhile, the miner generates a penalty payment transaction added to P as shown in Figure 6. e transaction will be removed from list P after the penalty is paid by the malicious user. If the malicious user fails to pay the penalty within a period of time, he/she will be added to the blacklist L. After that, all transactions relating to the malicious user will never be performed.

Description of the Proposed Protocol.
e proposed blockchain protocol runs in a sequence of rounds r and consists of the following six algorithms (Figures 7-10): (i) Initialization: get the local chain C←genesis, where genesis denotes a common genesis block. Set round r←1, and initialize empty lists R, D, P, and L.
(ii) Chain update: at the beginning of each round r, users run C ′ , ⊥ ←Γ · updateChain to get the longest chain C ′ in the blockchain network. (iii) Propose a redaction: the user proposes a redaction of the transaction T A by spending some transaction fees.
(a) Firstly, the user creates a redaction transaction redact T using the new transaction T * A as shown in Figure 7. In this process, the improved policy sanitizable signature is used to generate the witness for the transaction. We can see from Figure 7 that the hash values h for T A and (T * A ) are the same. erefore, the hash value of this block will not be changed after redacting the transaction. (b) en, he/she runs Γ · broadcast(T * A ) to broadcast the redacted transaction to the blockchain network. (c) Finally, miners add the transaction rdact T to the list R if the data τ 2 are UTXO. Otherwise, the transaction is discarded.
(iv) Propose a removal of harmful information when the user finds that the transaction T D , contained in the block with the index I, has the harmful information.
(a) Firstly, as shown in Figure 8, the user creates a removal transaction remove T, which does not cost transaction fee and contains the block's index I and the transaction T D . (b) en, he/she broadcasts the transaction remove T.  (c) e transaction remove T will be added to the list D if the block I does contain the harmful information. Meanwhile, the penalty payment transaction T P will be created and added to the list P. As shown in Figure 9, the transaction T P contains the amount of the penalty pen and the address ad of the malicious user who posts the harmful information. e transaction T P will be removed from the list P after the malicious user pays the penalty.
(v) Redacting the chain: (a) For the candidate transaction T A in the list R, the miner substitutes it with the new transaction T * A if the voting process on it has been completed and enough votes v ≥ ρ have been collected within a period of time t. e transaction T A is discarded if the votes v < ρ within a period of time t. If the voting on T A is still in progress, nothing will be done. Here, ρ denotes the threshold of votes and can be specified by consensus among all users in the blockchain network. (b) For the candidate transaction T D in the list D, the miner removes the harmful information from T D which is contained in the block with the index I. (c) For the candidate transaction T P in the list P, the miner first verifies whether the malicious user pays the penalty within a period of time t 1 .
If the malicious user pays the penalty, the transaction is removed from P. If the malicious user does not pay the penalty within a specified period of time, the user is added to the blacklist L, and the transaction T P is removed from the list P.
(vi) Creating a new block: the miner collects all transactions from the network for the r − th round and builds a new block B which meets the following conditions: (a) It contains at least one transaction in D and one in P if they are not empty. (b) It contains a vote H(T A ) on the candidate transaction in the list R if the voting on T A is still in process and the miner is willing to endorse. (c) All transactions contained in it comply with the usual transaction rules in the Ethereum Enterprise blockchain, and the validation process is shown in Figure 10.
Finally, if all blocks contained in the local chain C satisfy Γ · validateBlock(B) � 1 and Γ · validateChain(C) � 1, the miner extends the local chain C←C‖B and broadcasts the extended chain to the blockchain network.

Security Analysis
In this section, we analyze the security of the fine-grained and controllably redactable blockchain protocol with harmful data forced removal in terms of correctness, controlled redaction, and accountability. Theorem 1 (correctness). The correctness of a blockchain consists of the following three aspects: (1) Chain growth: if the based immutable blockchain protocol Γ satisfies chain growth, the extended editable blockchain protocol Γ ′ also satisfies chain growth. (2) Chain quality: if the based immutable blockchain protocol Γ satisfies chain quality, the extended editable blockchain protocol Γ ′ also satisfies chain growth for any ρ > μ. Here, ρ denotes the ratio of blocks containing the votes of the redacted transaction within a period of time.

(3) Common prefix: if the based immutable blockchain
protocol Γ satisfies the common prefix, the extended editable blockchain protocol Γ ′ also satisfies the common prefix. Proof.
(1) Chain growth: we note that the redaction in Γ ′ cannot reduce the length of the chain C by removing a block from the chain. us, the redact operations have no effect on the length of the chain. In conclusion, Γ ′ satisfies chain growth if Γ satisfies chain growth. (2) Chain quality: suppose the adversary A posts a malicious redaction transaction T * i for the previous transaction T i . A mines at most μ ratio of blocks in the voting phase because the adversary only has μ computational power. us, T * i cannot be performed due to ρ > μ. In conclusion, only the honest redaction transaction T * i can be performed and added to the chain.
(3) Common prefix: if the chain C 2 is not redacted, Γ ′ runs as the immutable blockchain Γ. us, Γ ′ satisfies the common prefix. If the chain C 2 is redacted and the redacted block B * i replaces B i in C 2 , the voting phase for the block B * i is completed, and enough votes are received. In conclusion, the extended editable blockchain protocol Γ ′ also satisfies the common prefix. □ Theorem 2 (controlled redaction). In the proposed scheme, for each PPT adversary A, it is computationally infeasible to generate a valid signature for the redacted transaction.
Proof. To prove this theorem, we consider two types of adversaries. One of the adversaries is the adversary A 1 who does not possess the attributes' set which satisfies the access control policy. Another is the adversary A 2 , who tries to redact the inadmissible portions of the transaction. In order to show how A 1 and A 2 attack the redactable blockchain protocol, we introduce the two games between the challenger C and adversaries A 1 and A 2 , respectively. Firstly, we define a game between the challenger C and the adversary A 1 .
Game 1: in Game 1, both the challenger C and the adversary A 1 perform as defined in the security definition.
(i) Setup phase: the adversary A 1 does as in the " reat Model." (ii) Query phase: the adversary A 1 does as in the " reat Model." (iii) Challenge phase: the adversary A 1 adaptively chooses the authorized user's attributes' set S (A(S) � 0). en, A 1 runs Sanitize P3S algorithm to generate the challenged signature σ * for the challenged transaction m * . Finally, the adversary A 1 sends (S, m * , σ * ) to C. (iv) Verify phase: the adversary A 1 performs polynomial queries as in the query phase. Consider the adversary A 1 has made L queries, and let i�1 denote the set of information obtained through these queries. C runs Verify P3S (pk P3S , pk Sig P3S , A, A, m * , σ * ) algorithm and outputs a bit b 0 . If b 0 � 1, C checks whether there exists an i ∈ [|Q|], σ * ) such that A(S) � 0. If there is such an i, the challenger C outputs b 1 � 1. Otherwise, C outputs b 1 � 0.
Suppose b 1 � 1, that is, the adversary A 1 wins, we can say that the adversary A 1 breaks the security of the policy-based sanitizable signature because the adversary's goal is to correctly generate the valid signature σ ′ for the transaction m * . According to the security of the policy-based sanitizable signature (unforgeability), the probability of each adversary, who does not possess the attributes' set S such that A(S) � 0, is negligible. en, we define a game between the challenger C and the adversary A 2 .
Game 2: in Game 2, both the challenger C and the adversary A 2 perform as defined in the security definition.
(i) Setup phase: the adversary A 2 does as in the " reat Model." (ii) Query phase: the adversary A 2 does as the adversary A 2 in the query phase. (iii) Challenge phase: the adversary A 2 adaptively chooses the authorized user's attributes' set S (A(S) � 1). en, A 2 runs Sanitize P3S algorithm to generate the challenged signature σ * for the challenged message m * which does not contain all inadmissible blocks. Finally, the adversary A 2 sends (S, m * , σ * ) to C. (iv) Verify phase: the adversary A 2 performs polynomial queries as in the query phase. Consider the adversary A 2 has made L queries, and let i�1 denote the set of information obtained through these queries. C runs Verify P3S (pk P3S , pk Sig P3S , A, A, m * , σ * ) algorithm and outputs a bit b 0 . If b 0 � 1, C checks whether there exists an i ∈ [|Q|], m * which does not contain all inadmissible blocks. If there is such an i, the challenger C outputs b 1 � 1. Otherwise, C outputs b 1 � 0.
Suppose b 1 � 1, that is, the adversary A 2 wins, we can say that the adversary A 2 breaks the security of the policy-based sanitizable signature because the adversary's goal is to correctly generate the valid signature σ ′ for the transaction m * . According to the security of the policy-based sanitizable signature (immutability), the probability of each adversary, who redacts the inadmissible blocks, is negligible.
In conclusion, the proposed blockchain protocol achieves controlled redaction. In other words, only authorized users can redact the admissible portions of the transaction T i . □ Theorem 3 (accountability). In the proposed blockchain protocol, trusted authority (group manager) can extract the identity of the originator of the transaction or the authorized user from any valid witness with nonnegligible probability.
Proof. We prove accountability by a sequence of games.
(i) Game 0: as Game 0 in [16]. (ii) Game 1: as Game 0, but we replace crs Ω with the one generated by (crs Ω , τ)←SIM 1 (1 κ ), i.e., the simulator SIM 1 takes the security parameter 1 κ as the input and then outputs (crs Ω , τ). Finally, the challenger C keeps the trapdoor τ and starts simulating all proofs. (iii) Assume towards contradiction that the adversary behaves differently. We can then build an adversary B which breaks the zero-knowledge property of the underlying proof system. e reduction works as follows. Our adversary B receives crs Ω from its own challenger and embeds it into PP P3S and generates all other values honestly. All proofs are then generated using the oracle provided and embedded honestly. en, whatever A outputs is also output by B. |Pr[S 0 ] − Pr[S 1 ]| is negligible, where Pr[S X ] denotes the advantage of the adversary in Game X.
Note that this also means that all proofs are now simulated, even though they still prove valid statements. (iv) Game 2: as Game 1, but we replace crs Ω with the one generated by (crs Ω , τ, ξ)←ξ 1 (1 κ ), i.e., the simulator ξ 1 takes the security parameter 1 κ as the input and then outputs (crs Ω , τ, ξ). Finally, the challenger C keeps the trapdoors τ and ξ. Let E 2 be the event that A can distinguish this replacement with nonnegligible probability. Moreover, note that, by definition, crs Ω is exactly distributed as in the prior hop.
(v) As we only keep one additional value, i.e., ξ, this is only an internal change. |Pr[S 1 ] − Pr[S 2 ]| is negligible. (vi) Game 3: as Game 2, but we abort if the adversary outputs valid (pk * , m * , σ * ) for which we cannot (as the holder of sk Sig P3S ) calculate pk which makes Judge P3S (pk * , pk Sig P3S , pk, π P3S , σ * , m * ) output 0. Let this event be E 3 . If E 3 occurs, we have a bogus proof π contained in σ * as it proves a false statement. us, B proceeds as in the prior game (doing everything honestly, but using simulated proofs and simulated crs Ω ) and can simply return the statement claimed to be proven by π and π itself. |Pr[S 2 ] − Pr[S 3 ]| is negligible. In conclusion, the proposed blockchain protocol achieves accountability.

Performance
In this section, we first give functionality comparison among our redactable blockchain protocol and several related redactable blockchain protocols [11,[13][14][15]. en, we analyze the computational burden of our redactable blockchain protocol through several experiments.

Functionality Comparison.
We give functionality comparison among our scheme and the related schemes [11,[13][14][15]. As shown in Table 2, our scheme is the only one that satisfies all of the following properties: fine-grained access control, controllable edit, accountability, and supporting the redaction of both additional information and UTXO. e schemes in [11,14] cannot support fine-grained access control. e scheme in [13] cannot effectively support harmful data deletion. All of these related redactable blockchain protocols cannot support controllable edit, accountability, and the editing of both additional information and UTXO.

Proof-of-Concept Implementation.
To evaluate the practicality of the proposed blockchain protocol, we implement a full-fledged blockchain system in Python 3.5.3, which is carried out on a desktop with an Intel Core (TM) i5-4300 CPU @ 2.13 GHz and 8.0 GB RAM. e blockchain system can achieve all the basic functionalities of Ethereum Enterprise. Separately, the blockchain system, including a subset of Ethereum Enterprise's script language, allows the authorized user to redact the transaction and the miner to delete the harmful data. We rely on the PoW consensus mechanism as Ethereum Enterprise does.
We evaluate the performance of the blockchain system for chain validation in different scenarios. In order to measure the cost time of chain validation, we validate chains containing different number of blocks and redaction transactions. A new chain is created and validated 50 times in each experiment, and the cost time of chain validation is the arithmetic mean of the run time of all runs. Each chain consists of up to 50,000 blocks, which approximate a one-year snapshot of the Ethereum Enterprise. Each block includes 1000 transactions (Figures 11-14).

(i) Overhead Compared to the Immutable Blockchain.
In order to evaluate the overhead of the redactable blockchain protocol with no redactions performed compared to the immutable blockchain, in the series of experiments, the length of chains ranges from 10,000 to 50,000 blocks. As shown in Figure 11, the redactable blockchain protocol has only a more tiny overhead than the immutable blockchain. With the increase of the length of the chain, the overhead is smaller. e reason is that the only extra step of the redactable blockchain is to check if any votes are contained in the new block. e run time of this step is negligible compared to the time of chain validating when the length of the chain is larger enough.
(ii) Overhead by the Number of Redactions. In order to evaluate the overhead of the redactable blockchain protocol with the increasing number of redactions compared to the redactable blockchain with no redaction, in the series of experiments, the number of redactions ranges from 1000 to 5000. As shown in Figure 12, the overhead is linear in the number of redactions because we need to collect the votes for the redaction in the voting phase.
(iii) Overhead by the Number of Removals. In order to evaluate the overhead of the redactable blockchain protocol with the increasing number of removals compared to the redactable blockchain with no removal, in the series of experiments, the number of removals ranges from 1000 to 5000. As shown in Figure 13, the overhead is linear in the number of removals because the miner generating the new block needs to remove the harmful information from the previous block.
(iv) Overhead by the Voting Parameter ρ. In order to evaluate the overhead of the redactable blockchain protocol with different voting periods, in the series of experiments, we set that the number of redactions is 1000, and the threshold ratio of the votes is ρ ≥ (1/2). As shown in Figure 14, the overhead is small and is most linear in the voting period.

Conclusions
In this paper, we proposed a fine-grained and controllably redactable blockchain with harmful data forced removal. Our scheme not only supports the usual redaction of transactions but also the forced removal of harmful information in the blockchain. e originator of the transaction Table 2: Comparison of functionality among our redactable blockchain protocol and related protocols.
Protocols Fine-grained access control Controllable edit Harmful data deletion Accountability Data type [11] × × √ × Additional information [13] √ × × × Additional information [14] × could specify a fine-grained access control structure about who could redact the transaction and which portions of the transaction could be redacted. Any user could initiate a transaction that contains the index of the block which included harmful information without spending transaction fees. If the harmful information is contained in a block, it was forced to be deleted by the miner who created the new block. e user who provided the index of the block could receive the reward which was borne by the malicious user. e malicious user would be blacklisted if rewards were not paid within a period of time, and any transaction about the user would not be performed later. Furthermore, the scheme supported not only the redaction of additional data but also UTXO. Finally, we demonstrated that the scheme was secure and feasible via formal security analysis and proof-of-concept implementation.
Note that the proposed fine-grained and controllably redactable blockchain protocol with harmful data forced removal is suitable for permissioned blockchains, such as Hyperledger, Ethereum Enterprise, Ripple, and Quorum.
ere is another type of blockchain called permissionless blockchain, such as Bitcoin and Ethereum. Constructing the redactable permissionless blockchain protocol is a challenge and an interesting open problem. In our future work, we will also focus on designing more sophisticated solutions to the redactable permissionless blockchain protocol.

A. Security Definition of the Improved Policy-Based Sanitizable Signature
In the following, we give the security definition of the improved policy-based sanitizable signature. Due to the limited space, we select several security aspects to highlight, and the rest of the security aspects can be seen in [16]. Definition 6. (unforgeability). In order to formally describe the unforgeability of the signature, we introduce a game between the challenger C and the adversary A to show how the adversary A is against the unforgeability of the signature. Trusted authority (group manager) is viewed as a challenger C, and the unauthorized user is viewed as an adversary A in our security definition. is game includes the following phases: (i) Setup phase: firstly, the challenger C runs the ParGen P3S and Setup P3S algorithm to generate the public parameters PP P3S and the master private/ public key pair (sk P3S , pk P3S ). en, C holds the master private key sk P3S locally. Finally, C sends the master public key pk P3S and the public parameters PP P3S to the adversary A.
(ii) Query phase: (a) KGenSan P3S queries: the adversary A queries sanitizer's private/public key pair for the public parameters PP P3S . C runs KGenSan P3S algorithm and returns the private/public key pair (x 2 , y 2 ) to A.
(b) Sign queries: the adversary A queries the signature for the master public key pk P3S , the signature for the message m, the set of admissible blocks A, and the access structure A. C runs KGenSig P3S to generate the signing key and then runs Sign algorithm to produce the signature σ. Finally, C returns the signature σ to A. (c) AddSan P3S queries: the adversary A queries the sanitizer's attribute key for sk P3S , pk San P3S , and the attributes' set S such that A(S) � 0. C runs AddSan P3S algorithm and returns the sanitizer's attribute key sk S ←(σ sk S , sk S ′ ) to A. (iii) Challenge phase: the adversary A adaptively chooses the authorized user's attributes' set S (A(S) � 0). en, A runs Sanitize P3S algorithm to generate the challenged signature σ * for the challenged message m * . Finally, the adversary A sends (S, m * , σ * ) to C. (iv) Verify phase: the adversary A performs polynomial queries as in the query phase. Consider the adversary A has made L queries, and let i�1 denote the set of information obtained through these queries. C runs Verify P3S (pk P3S , pk Sig P3S , A, A, m * , σ * ) algorithm and outputs a bit b 0 . If b 0 � 1, C checks whether there exists an i ∈ [|Q|], σ * such that A(S) � 0. If there is such an i, the challenger C outputs b 1 � 1. Otherwise, C outputs b 1 � 0.
We say that the adversary A wins if b 1 � 1. In the above game, we want to show that the adversary A, who does not possess the attributes' set S such that A(S) � 0, should not generate the new valid signature. e adversary's goal is to correctly generate the valid signature σ ′ for the message m * . We set the advantage of a polynomial-time adversary A in this game to be Pr[b 1 � 1]. We say the proposed scheme satisfies the unforgeability of the signature if for any polynomial-time adversary A, Pr[b 1 � 1] < (1/poly(n)) for sufficiently large n, where poly stands for a polynomial function.
Definition 7. (immutability). In order to formally describe the immutability of the signed data, we introduce a game between the challenger C and the adversary F to show how the adversary F is against the immutability of the signed data. Trusted authority (group manager) is viewed as a challenger C, and the authorized sanitizer is viewed as an adversary F in our security definition. is game includes the following phases: (i) Setup phase: firstly, the challenger C runs the ParGen P3S and Setup P3S algorithm to generate the public parameters PP P3S and the master private/ public key pair (sk P3S , pk P3S ). en, C holds the master private key sk P3S locally. Finally, C sends the master public key pk P3S and the public parameters PP P3S to the adversary F.
(ii) Query phase: (a) KGenSan P3S queries: the adversary F queries sanitizer's private/public key pair for the public parameters PP P3S . C runs KGenSan P3S algorithm and returns the private/public key pair (x 2 , y 2 ) to F. (b) Sign queries: the adversary F queries the signature for the master public key pk P3S , the signature for the message m, the set of admissible blocks F, and the access structure A. C runs KGenSig P3S to generate the signing key and then runs Sign algorithm to produce the signature σ. Finally, C returns the signature σ to F. (c) AddSan P3S queries: the adversary F queries the sanitizer's attribute key for sk P3S , pk San P3S , and the attributes' set S such that A(S) � 1. C runs AddSan P3S algorithm and returns the sanitizer's attribute key sk S ←(σ sk S , sk S ′ ) to F. (d) Verify P3S queries: the adversary F queries the verification result for pk P3S , pk Sig P3S , σ, and m. C runs Verify P3S algorithm and returns the result to F. (e) Sanitize P3S queries: the adversary F queries the sanitizable signature for pk P3S , pk Sig P3S , sk San P3S , sk S , m, σ, and m ′ . C runs Sanitize P3S algorithm and returns the new signature σ ′ to F. (f ) Proof P3S queries: the adversary F queries (π P3S , pk) for pk P3S , sk Sig P3S , σ, and m. C runs Proof P3S algorithm and returns (π P3S , pk) to F. (g) Judge P3S queries: the adversary F queries the judge result for pk P3S , sk Sig P3S , σ, and m. C runs Judge P3S algorithm and returns the result to F.
(iii) Challenge phase: the adversary F adaptively chooses the authorized user's attributes' set S (A(S) � 1). en, F runs Sanitize P3S algorithm to generate the challenged signature σ * for the challenged message m * which does not contain all inadmissible blocks. Finally, the adversary F sends (S, m * , σ * ) to C.
(iv) Verify phase: the adversary F performs polynomial queries as in the query phase. Consider the adversary F has made L queries, and let i�1 denote the set of information obtained through these queries. C runs Verify P3S (pk P3S , pk Sig P3S , A, A, m * , σ * ) algorithm and outputs a bit b 0 . If b 0 � 1, C checks whether there exists an i ∈ [|Q|], m * which does not contain all inadmissible blocks. If there is such an i, the challenger C outputs b 1 � 1. Otherwise, C outputs b 1 � 0.
We say that the adversary F wins if b 1 � 1. In the above game, we want to show that the adversary F, who redacts the inadmissible blocks, should not generate the new valid signature. e adversary's goal is to correctly generate the valid signature σ ′ for the message m * . We set the advantage of a polynomial-time adversary F in this game to be Pr[b 1 � 1]. We say the proposed scheme satisfies the unforgeability of the signature if for any polynomial-time adversary F, Pr[b 1 � 1] < (1/poly(n)) for sufficiently large n, where poly stands for a polynomial function.
Definition 8. (traceability). We say an improved policybased sanitizable signature supports traceability if the trusted authority (group manager) can extract signer's identity from any valid signature with nonnegligible probability.

B. Security Analysis of the Improved Policy-Based Sanitizable Signature
In this section, we analyze the security of the improved policy-based sanitizable signature in terms of unforgeability, immutability, and traceability. Theorem 4 (unforgeability). Any PPT adversaries can forge a policy-based sanitizable signature for some message with negligible probability.
Proof. To prove unforgeability, we use a sequence of games: (i) Game 0: as Game 0 in [16]. (ii) Game 1: as Game 0, but we replace crs Ω with the one generated by (crs Ω , τ)←SIM 1 (1 κ ), i.e., the simulator SIM 1 takes the security parameter 1 κ as the input and then outputs (crs Ω , τ). Finally, the challenger C keeps the trapdoor τ and starts simulating all proofs. Assume towards contradiction that the adversary behaves differently. We can then build an adversary B which breaks the zero-knowledge property of the underlying proof system. e reduction works as follows. Our adversary B receives crs Ω from its own challenger and embeds it into PP P3S and generates all other values honestly. All proofs are then generated using the oracle provided and embedded honestly. en, whatever A outputs is also output by B. |Pr[S 0 ] − Pr[S 1 ]| is negligible. Note that this also means that all proofs are now simulated, even though they still prove valid statements. (iii) Game 2: as Game 1, but we replace crs Ω with the one generated by (crs Ω , τ, ξ)←ξ 1 (1 κ ), i.e., the simulator ξ 1 takes the security parameter 1 κ as the input and then outputs (crs Ω , τ, ξ). Finally, the challenger C keeps the trapdoors τ and ξ. Let E 2 be the event that A can distinguish this replacement with nonnegligible probability. Moreover, note that, by definition, crs Ω is exactly distributed as in the prior hop.
As we only keep one additional value, i.e., ξ, this is only an internal change. |Pr[S 1 ] − Pr[S 2 ]| is negligible. (iv) Game 3: as Game 2, but we abort if the adversary was able to generate a signature σ * m on a string never generated by the signing oracle. Let this event be E 3 . Assume, towards contradiction, that event E 3 occurs. We can then construct an adversary B which breaks the unforgeability of the underlying signature scheme, namely, B receives pk of the signature scheme. is is embedded in pk Σ ′ , while all other values are generated as in Game 2. All oracles are simulated honestly, but Sign P3S ′ . e only change is, however, that the generation of each σ m is outsourced to the signature generation oracle. en, whenever E 3 occurs, B can return ((pk P3S , pk Sig P3S , A, H(i‖m !A ), h, A), σ * m ). ese values can easily be compiled using A's output, i.e., (m * , σ * ). Note that this already includes that the adversary cannot temper with A. |Pr[S 2 ] − Pr[S 3 ]| is negligible.
(v) Game 4: as Game 3, but we abort if the adversary was able to generate (m * , σ * ) for which m * should not have been derivable. Let this event be E 4 . Assume, towards contradiction, that event E 4 occurs. We can then construct an adversary B which breaks the strong insider collision resistance of the used PCH, namely, B receives pk PCH of the PCH. is is embedded in pk P3S , while all other values are generated as in Game 3. e GetSan oracle is simulated honestly. Calls to the Sign P3S ′ oracle are done honestly, but the hash is generated using the Hash PCH ′ oracle. Calls to the AddSan P3S ′ oracle are simulated as follows. If a key for a simulated sanitizer (obtained by a call to the GetSan oracle) is to be generated, it is rerouted to KGen PCH ″ . If the adversary wants to get a key for itself, it is rerouted to the KGen PCH ′ oracle, and the answer is embedded honestly in the response. Sanitization requests are performed honestly (but simulated proofs), with the exception that adaptions for simulated sanitizers are done using the Adapt pch ′ oracle. So far, the distributions are equal. en, whenever the adversary outputs (m * , σ * ) such that the winning conditions are fulfilled, our reduction B can return (m * , r * , m ′ * , r ′ * , h * ). e values can be compiled from (m * , σ * ) and the transcript from the signing oracle (note that we already excluded that the adversary can temper with the hash h). |Pr[S 3 ] − Pr[S 4 ]| is negligible.
(vi) Game 5: as Game 4, but we abort if the adversary was able to generate (m * , σ * ) but has never made a call AddSan P3S ′ . Let this event be E 5 .
Assume, towards contradiction, that event E 5 occurs. We can then construct an adversary B which breaks the unforgeability of used Σ or the one-wayness of the used oneway function f, namely, B receives pk Σ of Σ and f, and f(x) � y from its own challenger. is is embedded in pk P3S (and, of course, the public parameters), while all other values are generated as in Game 4. y is embedded in pk Sig P3S . For signing, the proofs are already simulated, and thus, x is not required to be known. For each call to AddSan P3S for keys for which the adversary knows the corresponding secret keys, B calls its signature oracle to obtain such a key. For simulated sanitizers, those signatures do not need to be obtained as the proofs are already simulated. en, whenever the adversary outputs (m * , σ * ), B extracts values (x 1 , x 2 , sk Π , σ ′ ). If f(x 1 ) � y, B can return x 1 to break the one-wayness of f. In the other case, B can return ((f(x 2 ), pk P3S ), σ ′ ) as its own forgery attempt for Σ. If extraction fails or a wrong statement was proven, SSE does not hold. A reduction is straightforward. |Pr[S 4 ] − Pr[S 5 ]| is negligible. Now, the adversary can no longer win the unforgeability game; this game is computationally indistinguishable from the original game, which concludes the proof. □ Theorem 5 (immutability). For each PPT adversary, the advantage of generating valid signatures for altered immutable parts is negligible.
Proof. To prove immutability, we use a sequence of games: (i) Game 0: as Game 0 in [16]. (ii) Game 1: as Game 0, and we abort if the adversary outputs (pk * , m * , σ * ) such that the winning conditions are met. Let this event be E 1 .
Assume, towards contradiction, that event E 1 occurs. We can then build an adversary B which breaks the unforgeability of the used signature scheme, namely, we know that A (which also contains the length of the message and all nonmodifiable blocks along with their location), along with pk PCH , is signed. As, however, by definition, the message m * must be different from any derivable message, A w.r.t. pk PCH was never signed in this regard.
Constructing a reduction B is now straightforward. Our reduction B receives the public key pk Σ ′ (along with the public parameters) from its own challenger. is public key is embedded as pk Σ ′ . All other values are generated honestly. If a signature σ m is to be generated, B asks its own oracle to generate that signature, embedding it into the response A receives. At some point, A returns (pk * , m * , σ * ). e forgery can be extracted as described above. |Pr[S 0 ] − Pr[S 1 ]| is negligible. We stress that, by construction, a sanitizer always exists. Now, the adversary can no longer win the immutability game; this game is computationally indistinguishable from the original game, which concludes the proof. □ Theorem 6 (traceability). Trusted authority (group manager) can extract the identity of the originator of the