Securing blockchain-based timed data release against adversarial attacks¹

3.2.1.Mixed adversarial environment

We consider three different types of peer accounts,22 namely honest peers, rational peers, and malicious peers, existing in the Ethereum account network. Specifically, every honest peer always participates in timed-release service protocols with absolutely honest actions. This type of peer never performs any malicious actions.

Every rational peer acts with economic rationality. Such a type of peer is driven by self-interest and only chooses to violate timed-release service protocol when doing so allows to earn a higher profit. Every malicious peer always maliciously launches attacks and deviates arbitrarily from the prescribed timed-release service in an attempt to violate security.

To concretely capture such a mixed adversarial environment, we assume that there always exists a malicious adversary M holding an EOA as well as a global view of our protocol to aggressively break normal operations of our timed-release service. Such an adversary may adopt two potential approaches to corrupt heterogeneous peers. One is bribery [23], where the rational peers are the chief victims. The other one is malicious peer injection, where M intentionally creates a set of peer accounts acting as the malicious peers and controls them to register themselves with the timed-release smart contract, SC, at any time. Once such malicious peers are selected as participants for a timed-release service, potential attacks will occur. In the above cases, successful bribery or injection happens with monetary cost that is charged from M. Henceforth, we assume that M is upper-bounded by finite budget in terms of cryptocurrency. We formally define the attacks next.

3.2.2.Post-facto attacks

Fig. 2.

Post-facto attack examples.

We consider two concrete post-facto attacks in our framework. One is drop attack, which aims at destroying the data before the prescribed release time and results in a failing data release at the prescribed release time. Such an attack may be launched by M who controls one or more injected malicious peers engaging in the timed-release service. For example, in Case 1 of Fig. 2a, M controls the injected malicious peer P4 to drop the data D,33 and after Tr, D will be missing. In addition, M also can adopt bribery to corrupt rational peers. As an example, in Case 2, in another service, M could let the rational peer P2 drop D by bribing P2 through off-chain interactions to make P2 earn more profit. As a consequence, after Tr, nothing will be released.

The other form of attack is the release-ahead attack. A successful release-ahead attack results in a premature release of the data D. It can be launched by M by corrupting a fraction of peers engaging in the timed-release service to get the data before the prescribed release time and disclose it. For example, in Fig. 2b Case 1, M may control P4 and bribe P3 to successfully launch a release-ahead attack. Specifically, we note that in our protocol, the data D will be encrypted using the public keys of P1, P4, and P3. If M wants to pre-release D, he/she must control P4 to acquire the encrypted data and bribe P3 to get the private key of P3 to decrypt the encrypted data and pre-release at that time point which is earlier than Tr. Additionally, by adopting bribery, in Case 2, M must bribe P2 and P3 to successfully launch the release-ahead attack.

5.1.1.Peer registration

Our basic protocols start peer registration protocol that aims at making any peer in the network get an opportunity to engage in our timed data release service. We detail our design as follows:

5.1.2.Service setup

Before initializing a new timed-release service, the sender Si and recipient Ri first negotiate through off-chain connections to achieve an agreement for a new timed-release service. The agreement consists of the following configurations of the incoming timed release service: a prescribed release time Tri and minimum deposit needed. After negotiating, the responsible sender Si makes provision for the incoming service with SC by means of the Service Setup protocol. The logic behind the Service Setup in our protocol is similar to one presented in [23]. The novel feature that differentiates our protocol from the one in [23] is the newly designed reputation-aware peer recruitment policy which we describe next.

(i)Reputation-aware Peer Recruitment: For a specific timed-release service request reqi, the sender Si first interacts with SC to retrieve the available peer windows. S then locally constructs an Interval Tree [15], namely WITree, to store such windows. Then, Si will make a decision to select a number of peers such that the set union of the working windows of such peers must cover [Tsi,Tri]. The set of selected peers forms a routing-like path to store the data and perform the data hand-off between each peer. In parallel, the sender Si is also concerned with the performance of data protection provided by such a set of peers. The protection can be specifically represented as follows: given a set of selected peers, what is the likelihood that the data is prevented from drop attack as well as release-ahead attack?

We formally quantify such likelihood with two distinct attack resilience metrics, namely drop attack resilience and release-ahead attack resilience respectively. With the help of our uncertainty-aware reputation measure Rep(·), given a peer recruitment scheme E that consists of l selected peers, we formally define such metrics as follows:

Such a definition reflects that, to successfully launch the drop attack, the malicious adversary M must control at least one peer involved in the scheme E. Then, for the release-ahead attack resilience, we have

In the above definition, by directly following the adversarial setting of [20,21,23], we only consider that the adversary M intends to pre-release the data at the start time. Since the scheme E is protected with the Onion Routing [32] scheme, an adversary must control all peers to prematurely release the data at the start time. We discuss this later in the Service Enforcement protocol.

Our peer recruitment for the timed-release service consists of multiple rounds. In each round of selection, the sender will take a time point as the input. By retrieving all the available registered peers whose working window covers the input time point in terms of WITree, the sender will pick the one having the highest reputation score as the responsible peer for the current round. Then, the start time of the selected peer and the hand-off time zone will be taken as the input of the next round selection. In particular, two conditions will end the recruitment. When the WITree finds that no available peers are in a selection round or when the start time of the selected peer is earlier than Ts.

Fig. 4.

Peer recruitment example.

We illustrate our design approach using an example in Fig. 4a. In the example, there are totally 8 peers P1–P9 who have already registered with SC as well as available within [Ts,Tr]. The numerical value associated with each peer represents the current reputation measure, which is publicly known. The different numerical measures associated with the peers indicate their historical behaviors when they engaged in timed-release requests in the past. The blue color represents rational peers, the red color represents the malicious peers, and the green color represents the honest peers. Th denotes a predefined hand-off timezone. The sender S first takes Tr+Th as the input of the first-round selection. There are totally 3 peers, P6, P7, and P8, who are available at this time point. Then, S picks the highest reputation one, P7, whose reputation is Rep(P7)=0.6, as one of the peer candidates. Then, S performs the second-round selection, which takes Ts(P7)+Th, where Ts(P7) represents the start time of the working window of P7, as the input time point. The working windows of two peers, P6 and P9, cover such a time point. The one holding a higher reputation P9, Rep(P5)=0.1, is selected. Followed by the third-round selection, P4 is selected. Finally, the last-round selection picks P2 as well as checks that the start time of P2 is prior to the start time of the timed-release service, Ts, which ends the reputation-aware recruitment procedure. The order of peers, P2→P4→P9→P7, jointly take charge of the incoming timed-release service. We denote this scheme as E1.

(ii) Resilience Analysis: We provide a concrete example to show the resilience analysis of our proposed reputation-aware peer recruitment policy as well as the time-aware recruitment proposed in [23] as the baseline for comparison. To analyze its resilience, we take the release-ahead attack resilience as an example. The release-ahead attack resilience of E1 from our proposed reputation-aware peer recruitment is derived from FrE1=1−(1−0.2)·(1−0.3)·(1−0.1)·(1−0.6)=0.7984.

For the reputation-unaware recruitment in Fig. 4b, in each round of selection, only the peer who has the longest working time is selected. The peers P2→P4→P6 take charge of the service. We denote this scheme as E2. The release-ahead attack resilience is FrE2=1−(1−0.2)·(1−0.3)·(1−0.05)=0.468. Compared with our reputation-aware recruitment, FrE2 shows significant degradation. By following a similar procedure, one can easily verify that the same results hold for Fd. After providing all information mentioned above, the service is ready to go.

5.1.3.Service enforcement

After completing Service Setup, a timed-release service moves into execution. Service Enforcement takes charge of monitoring the correctness and timeliness of the executions after the data is released into the blockchain network. Moreover, with the help of the Service Enforcement protocol, SC can abort the service in time if any misbehavior is detected. We adopt the basic procedures of the Service Enforcement protocol described in [23]. We describe it next.

We denote Ei={Pk}k∈[1,l] as the selected peers from the reputation-aware recruitment policy from Si, and Si generates an onion by encrypting the original data with the public keys of the peers in Ei and transfer it to P1 to initialize the Service Enforcement protocol. Without loss of generality, under the scope of the timed-release service, we capture the action space of each peer with A={cs,ws,tr,vr,rp}, where cs represents that Pk verifies the received certification from the Pk−1. The certification is used to detect drop attacks. ws indicates that Pk builds private channel using the Whisper Key protocol [23] with the subsequent peer Pk+1 to transfer the onion, and tr represents that Pk transfers the onion to Pk+1, vr aims at verifying the on-time results of cs and ws, and rp captures the possible misbehavior actions. In order to detect misbehavior in time, we bound the major actions within A with corresponding deadlines, which enables our protocol to be aborted timely if any misbehavior is detected. Concretely, we associate each peer with a series of pre-determined hard deadlines. For example, for the peer Pk∈Ei, before T1, Pk must perform cs. Then, Pk must perform vr for the verification of cs, and perform ws before T2. The verification of ws, and the delivery of the onion to the subsequent peer Pk+1 must be executed before T3. Such deadlines follow the ordering: T1<T2<T3. In particular, if Pk+1 does not receive the corresponding onion from Pk, he/she must report the issue (rp) before performing cs, otherwise, if a failed submission of the certification is detected from Pk+1, Pk+1 will be judged as launching the drop attack. Our Misbehavior Detection protocol is similar to the one described in [23]. Corresponding to the results from the verification mentioned above, we denote the finite state space of each Pk∈Ei as Bki={INIT,VF,WS,TR,FAIL}. It is described as follows: all peers within Ei start with the INIT state when engaged in reqi. For Pk, if he/she passes the verification for cs, then the state of Pk will be updated to VF from INIT. Then, if Pk passes the verification for ws, the state will be updated to WS from VF. If Pk+1 does not report any misbehavior of Pk, the state of Pk will be updated to TR from VF. If any previous verification fails or a drop report is emitted, the state of Pk will be moved to FAIL and the current service will be aborted. If all peers in Ei honestly follow the protocol, Ri will get the original data and close the current service by following Service Summary which is described next.

We stress that the above procedures work under the assumption that malicious peers only launch the drop attack or the release-ahead attack. In fact, there may be other scenarios that impact the evaluation results, such as bad reputation evaluations on Pk, launched by Pk+1. Such scenarios, however, are out of the scope of this paper. It will be an interesting extension to our protocol, and we will leave this part as our potential future works.

5.1.4.Service summary

There are two scenarios that trigger Service Summary:(1) A timed-release service is successfully finished. Under this scenario, Ri is responsible for the final evaluations of each peer as well as updating the on-chain reputation. (2) A timed-release service is aborted at a time point before the prescribed release time Tri. We adopt a remuneration policy similar to one described in [23] for the incentive refund. For the behavior evaluation as well as for updating the reputation, SC follows the rules to perform evaluations: SC checks the state of each peer within Ei. If the final state of a peer is TR, the binary assessment for the peer is FL, and if the final state of a peer is FAIL, the assessment is DV. Otherwise, if a peer has INIT state, SC does not perform any evaluations. Finally, the reputation measure of each peer in Ei will be updated using by following equation (8).

Taking into consideration the entire protocol, we would like to underscore the underlying philosophy of our design. In contrast to aiming to achieve immunity to any misbehavior, our focus lies in safeguarding the service by offering satisfactory service quality in terms of attack resilience. While the reputation measure, a key pillar in our design, cannot completely prevent misbehavior, it works in conjunction with peer recruitment to provide senders with valuable guidance regarding the service’s attack resilience. For example, if a sender anticipates a 95% drop attack resilience for their service, but the recruitment policy can only guarantee 75%, the sender may opt to decline the service and thereby reduce the risk of data loss during its execution. Conversely, without the support of the reputation measure, in an environment plagued by malicious adversaries, senders are compelled to adhere to the recruitment scheme, which may involve these adversaries. Unfortunately, this significantly increases the likelihood of failures in timed data release services.

6.2.1.Problem statement & analysis

Our timed data release service path finding problem is described as follows: Given a timed data release temporal graph GTDR, a pair of vertex S and R in GTDR, and a prescribed service interval [Ts,Tr], can we find a temporal path from S to R with the maximal drop attack resilience or maximal release-ahead attack resilience?

We address this problem by showing the existence of an optimal substructure described as follows:

With such a property in hand, we propose a greedy algorithm for determining the service path.

6.2.2.An efficient algorithm

We design an efficient one-pass algorithm to derive the timed data release service path. We follow the convention in [42] to represent GTDR in an edge stream manner, in which we sort ei∈GTDR in a non-decreasing order of ti. In Algorithm 1, per execution, we aim at deriving a timed data release service path that maximizes either wr or wd.

Algorithm 1:

Timed data release service path finding

We take wr as an example to illustrate our algorithm. Prior to scanning the edge stream, we first initialize several key attributes for every Pi. Specifically, we adopt t[Pi] to denote the time that a path arrives at Pi, w[Pi] to denote the weight wr of that path, and prev[Pi] to denote a predecessor of Pi that is used for retrieving peers on that path (line 4). Totally, we denote R[Pi] to record every entry of (w[Pi],prev[Pi],t[Pi]). Our algorithm only accepts the edge satisfying our service time interval [Ts,Tr] (line 8). At the heart of our algorithm, our greedy strategy (line 16) retrieves all the temporal paths that arrive at Pk before the start time, ti, of the current edge and finds the one with the maximal wir, followed by updating Pm’s weight and corresponding attributes (lines 19–20). In the comment line above line 26, we update W[Pm] to let W[Pm] record the maximal value. When the algorithm scans the final edge, where Pm=R, the algorithm will terminate and give us the maximal release-ahead resilience, stored in W[R] (line 33). To retrieve the peers on that path, starting from prev[R], we can recursively find predecessors.

Note that this proposed approach will be adopted by the sender before the start time of a service, which means that the entire procedure does not incur any on-chain operations that are expensive computationally.

Fig. 6.

An working example of temporal graph-based design.

Comparisons: We provide an example in Fig. 6c to show our design rationale as well as the benefits of our proposed temporal graph-based design. In Fig. 6a, given the public peer working window distribution, we adopt the basic reputation-aware recruitment in Section 5.1.2 to get a routing path S→P1→P2→P3→R that shows Fr=0.95.

Then, for our temporal graph-based recruitment, in Fig. 6b, based on Algorithm 1, we can retrieve a timed data release service path from GTDR with the maximal release-ahead attack resilience, namely TP={S,P1,P4,P5,P2,P3,R}. For simplicity, we skip to label duration λi here. Given the attached wir (highlighted in blue) for each edge, we can get the maximal wr=−2ln(0.5∗0.1∗0.1∗0.2∗0.5) in GTDR. Then, for this scheme, we have Fr′=1−0.5∗0.1∗0.1∗0.2∗0.5=0.9995, which is higher than Fr=0.95. For the drop attack resilience, following the similar procedure, one can easily verify such a benefit.

7.1.1.Synthetic dataset

To the best of our knowledge, there is no existing public data set that reflects our application settings completely. We thus decide to synthesize a data set by closely following the settings of [23]. Detailed description on our synthetic data is elaborated as follows:

Synthetic Dataset: The default number of registered peers in the simulation is set to 1000. In the simulator, we first randomly select 5 registered peers as the honest peers. Then, given a malicious peer percentage, we randomly select malicious peers based on that percentage. The remaining peers are all rational peers. For each peer, the duration of his/her working window is drawn from a normal distribution with the mean of 50 hours and 5-hour standard deviation. Also, we consider that the generated peers follow a duty cycle-aware working fashion [9], in which the total working period of each peer is separate for two different cycles. One is online cycle that is represented by the generated working window associated with such a peer, the other is offline cycle that represents the offline time of such a peer. In general, we use a scalar value τ to represent the fraction of the online cycle. For example, for a peer with a generated 10-hour online cycle (working window), given that τ=50%, he/she will next have a 10-hour offline cycle. Totally, his/her working period is 20 hours. Based on τ, we synthesize two different peer profile with different duty-cycle characterizations. One peer data set has the setting of τ=80% for all generated peers, namely type 1 peer profile, D1 for short. The other has the setting of τ=40% for all generated peers, namely type 2 peer profile, D2 for short. For our temporal graph data, based on D1 and D2, we follow a similar procedure shown in Figs 6b, 6c. Specifically, if two peers’ working window overlap, we treat them contactable and assign a corresponding start time. The temporal graph data is transformed to the edge representation.

7.1.2.Experimental settings

Metrics: To quantify the attack-resilient performance of our design, we study two attack-resilient metrics, release-ahead attack resilience (Fr) and drop attack resilience (Fd).

Comparisons: In our evaluations, we consider three different groups of protocols:

Protocol Configurations: Following the assumptions in Section 3.2, in our simulated protocol, the malicious peers in the registered pool deviate from the protocol completely, and the honest peers follow the protocol entirely. The rational peers only launch attack based on the bribery value from the malicious adversaries. The penalty factor ξ=10.

Fig. 7.

Fr evaluations under different malicious peer percentage.

Fig. 8.

Fd evaluations under different malicious peer percentage.

7.1.3.Evaluation results

Global Experimental Evaluation Settings: For each evaluation, our simulator generates 500 requests for the evaluation, where 70% of them are training requests, and 30% of them are validation requests. We calculate the average resilience as the result of each peer malicious percentage setting. Each experiment is executed 10 times and the average resilience is obtained.

(1) Effectiveness under Different Malicious Peer Percentage

This suite of experiments demonstrates effectiveness of our proposed reputation-aware peer recruitment policy (RS1 and RS5) as well as the optimum of our proposed temporal graph-based ones (TGRSR/TGRSD) under various percentage of malicious peers. To offer a fine-grained analysis, we split our experiments into two sub-groups to observe resultant Fr and Fd. We first show the results yield by the first sub-group observing Fr. In Fig. 7a, we can observe that with 100 peers with τ=0.8, TGRSR always offers the highest release-ahead attack resilience than all other ones under different malicious peer percentage. The results for RS1 and RS5, though are less effective compared to TGRSR, they can provide in some sense good resilience against release-ahead attack. The remaining ones, NRS1 and NRS5 show the worst resilience among all. Next, in Fig. 7b, we make τ=0.4. TGRSR still offers the best resilience among all under different malicious peer percentage. Compared with TGRSR, RS1 and RS5 show a significant resilience degradation. NRS1 and NRS5 always offer the worst resilience among all. When comparing the results in Fig. 7a and Fig. 7b, we find that RS1/RS5 and NRS1/NRS5 show a significant variations in Fr when we vary τ to redistribute time windows. This validates our observations in Section 5.1.2 that these two sets of techniques are highly respective of the pre-determined |Th|, which is sensitive to the variations of τ. Finally, in Figs 7c, 7d, we show evaluations under a larger scale with 1000 registered peers. The results show a similar observations as the ones reported from Figs 7a, 7b. In summary, under different malicious percentage settings, in face of the release-ahead attack, TGRSR effectively protects against such an attack. RS1 and RS5, with their non-deterministic performance, lie at the second position. Such observations remain invariant when meeting different τ and the scale of the peers.

In the second sub-group, we investigate Fd. First, in Fig. 8a, TGRSD always realizes the highest drop attack resilience under various malicious peer percentage. RS1 and RS5 lie at the second position which, in regards to Fd, is less effective compared to TFRSD while significantly surpassing NRS1 and NRS5. When we make τ=0.4 with 100 peers, the observations remain almost invariant. By horizontally comparing Fig. 7b with Fig. 7a, the changes in τ renders a significant variation in Fd, which, again, is attributed to the pre-determined |Th| sensitive to the time window distribution. In Figs 8c, 8d, we increase the number of peers. The corresponding observations are similar as the ones mentioned in Figs 8a, 8b. Therefore, under different malicious percentage settings, when meeting the drop attack, TGRSD is the best performer. RS1 and RS5 lie at the next position. These observations are similar with different τ and different number of peers.

(2)Effectiveness under Different Duration of Service: In this set of experiments, we aim at learning the effectiveness of our proposed protocol under different duration of service time. Apart from the default 300 hours service time, in this set of experiments, we set a short duration, 100 hours, a moderately long duration 600 hours, and a long duration 1200 hours. We fix the number of registered peers as 1000 and the malicious peer percentage as 35%.

Fig. 9.

Fr evaluations under different timed-release service durations.

Fig. 10.

Fd evaluations under timed-release service durations.

In Figs 9a, 9b, in the evaluation of Fr, under different time duration settings, TGRSR always achieves the highest Fr. Though RS1 and RS5 show a lower Fr in comparison with TGRSR, they significantly outperform NRS1 and NRS5 which struggles to handle the release-ahead attack. Figures 10a, 10b show the evaluations of Fd under different service duration settings. TGRSD always offers the highest Fd. RS1 and RS5 give a lower Fd compared with TGRSD. Both TGRSD as well as RS1 and RS5, compared with NS1 and NS5, show a significant improvement in Fd. In summary, under different service duration, TGRSD always offer the best drop attack resilience and TGRSR achieves the best release-ahead attack resilience.

7.2.1.Smart contract implementation

In this section, we present our prototype implementation. We implement our smart contract in the official programming language Solidity [36]. We deploy our smart contract on Ethereum official test network Rinkeby [33] through the interface, Infura [14]. We use the data from our simulation studies as the input for on-chain validations. We have 7 selected peers in total that take charge of 1200 hour service. The results from Table 1 show the details of our implementations. The implementation of our reputation-aware timed-release protocol consist of five different modules. 1◯Registration: this module provides interfaces for every peer to register with SC as well as to manage their own information. peerRegister is invoked by any peers to register with SC. deposit and withdraw, are invoked by the registered peers to manage the account balance. updatePubKey and updateWindow are invoked by the registered peers to manage the information regarding the timed-release service. 2◯Setup: this module provides interfaces for senders and recipients to perform service provisioning for timed-release requests. senderSign is invoked by senders to register with SC. The second function recipientSign is invoked by the corresponding recipients. The third function setup is invoked by senders to finish the provisioning of a service. 3◯Enforce: this module guarantees the normal executions of a timed-release service. setCertificate is invoked by senders to submit the certification. submitCertificate is invoked by any engaged peers or the recipients to verify the correctness of the certification. setWhisperKey is invoked by the engaged peers or the senders to build private channels. The fourth function verification is invoked by any peers to actively verify the behaviors of each peer. 4◯Detection This module consists of four functions to detect and reward the reporting of behaviors. releaseReport is invoked by any peer to report the evidence of the release-ahead attack, and after verification by SC, releaseReward is invoked by the reporter to receive rewards. dropReport is invoked by any peer to report the drop attack evidences. After the verification, the reporter invokes the function dropReward to get rewards. 5◯Summary The last module consists of two functions. The first one, peerEvaluation, is invoked by the last responsible peer of each service to assess peers’ behaviors, and the second function reputationUpdate is invoked by the same peer to finally update the peers’ reputation measure, which is publicly recorded on-chain.

7.2.2.Monetary cost analysis

From Table 1, we have two significant observations regarding the cost: first, there are four functions incurring relatively higher cost namely peerRegister(229669), senderSign(355534), setup(122682), and peerEvaluation(139363). Specifically, peerRegister is invoked by any peers, senderSign and setup are both invoked by a sender. peerRegister is invoked by the last peer in the routing scheme. We note that those four functions are only invoked once per request and therefore it is an one-time cost. Second, our proposed on-chain reputation mechanisms only incurs a modest gas cost from the summary module where peerEvaluation incurs 139363 and reputationUpdate incurs 48620.