Implementation and Setup

TheT3_{ABmodel does not rely on the specific FE-based applications, and hence for generality, we only}

present the evaluation on a pure T3_{AB model with the simulated audit obligations where the key-related}

components are generated by the FE-based application in an off-line manner.

Implemented Smart Contract. We implemented the smart contracts in Solidity programming lan- guage using a Truffle 1 _{framework - a development environment, testing framework and asset pipeline for}

blockchains using the Ethereum Virtual Machine (EVM). Figure 6.3 presents simplifiedT3_{ABsmart contract}

interfaces. T3ABmainly includes four types of functions as follows:

• Access Control Modifiers. Themodifier can be used to change the behavior of functions in a declarative way. In our implementation, we use the modifier to automatically check the privilege of each account that is defined in the role-based access control (RBAC) module prior to executing the function. We employ the Ownable and AccessControl smart contract 2 _{from OpenZeppelin as the base of our access control}

mechanism. To be specific, we define various access control modifiers in which the basic RBAC functions are integrated to satisfy our access control requirement. Except for the registration related functions, other functions are restricted by these modifiers.

• Administrative and Incentive Functions. We define several administrative functions such as‘enrollLock()’,

‘enrollOpen()’,‘dropout()’that allows the administrator to control the enrollment status. InT3AB, each 1_{https://www.trufflesuite.com/}

1 pragma solidity ^0.6.0; 2 pragma experimental ABIEncoderV2; 3 import"./Ownable.sol"; 4 import"./AccessControl.sol";

5 contract T3AB is Ownable, AccessControl { 6 // access control related modifiers

7 bytes32publicconstant AUTHORITY_ROLE=keccak256("AUTHORITY_ROLE");

8 bytes32publicconstant ACTOR_DATA_OWNER_ROLE=keccak256("ACTOR_DATA_OWNER_ROLE"); 9 bytes32publicconstant ACTOR_DATA_USER_ROLE=keccak256("ACTOR_DATA_USER_ROLE"); 10 bytes32publicconstant MONITOR_ROLE=keccak256("MONITOR_ROLE");

11 modifier onlyAuthority() 12 modifier onlyDataOwner() 13 modifier onlyDataUser() 14 modifier onlyActor() 15 modifier onlyMonitor() 16 modifier onlyDeposit() 17 modifier onlyWithdrawRegisterCost() 18 // administrative and intensive

19 functionenrollLock()publiconlyOwner 20 functionenrollOpen()publiconlyOwner

21 functiondepositeGuarantee()publicpayable onlyDeposit 22 functionrewardRegisterCost()publiconlyWithdrawRegisterCost 23 functionrewardDeploymentCost()publiconlyOwner

24 function_checkGuaranteeDeposit(address account)privatereturns(bool) 25 function_inferencePreventionModule(uint[l] memory y)privatereturns(bool) 26 functiondropout()public

27 // Registration

28 functionregisterAuthority(bytes memory pk, signature memory sign)publicpayable 29 functionregisterActorDataOwner(bytes memory pk, signature memory sign)public

30 functionregisterActorDataUser(bytes memory pk, signature memory sign)public

31 functionregisterMonitor(bytes memory pk, signature memory sign)public

32 // Obligation

33 functionrecordKSPKReq(bytes32 id, uint pkReqSymbol, uint reqTime, signature memory sign)publiconlyDataOwner 34 functionrecordKSPKResp(bytes32 id, bytes32 pkHash, uint respTime, signature memory sign)publiconlyAuthority

35 functionrecordKSSKReq(bytes32 id, uint[l] memory y, uint reqTime, signature memory sign)publicpayable onlyDataUser returns(bool) 36 functionrecordKSSKResp(bytes32 id, bytes32 skHash, uint respTime, signature memory sign)publiconlyAuthority

37 functionrecordKSConfirm(address tpa, bytes32 id, bytes32 keyHash, uint confirmTime, 38 signature memory signRecpt, signature memory sign)publiconlyActor 39 // Inspection

40 functioninspectObligationKS(bytes32 id)publiconlyMonitor returns(bool)

41 functioninspectObligationPP(address addr, bytes memory pk, signature memory sign)publiconlyMonitor returns(bool)

42 }

1

Figure 6.3: Overview of the smart contract interfaces. Note that the parameter ‘signature’ is our defined customizedstruct that are not presented here. Such a feature is provide inABIEncoderV2.

entity can register if and only if the enrollment is set as open by the administrator. After the enrollment is locked, the deposit operations are opened to the related entities. Besides, T3_{AB also inherits the}

administrative functions such as ‘transferOwnership(newOwner)’, ‘renounceOwnership()’ that are not presented in Figure 6.3. These two functions allow transferring the ownership of the contract and leave the contract without owner, respectively. Furthermore, we also defined several withdraw and deposit functions that help to establish the base of the incentive and penalty mechanism.

• Registration Functions. The registration functions mainly focus on the initialization phases of theT3_AB

model (i.e., Phases I and II, as illustrated in Section 6.1.3), where each entity is allowed to register a role, and publish its identity-to-public-key binding in the blockchain.

Table 6.1: Gas cost and test time of selected functions in various test case scenarios

Test Cases Functions Gas Cost Test Time Description

Administrative

deployment 4125603 183ms deploy the smart contract enrollOpen 44126 42ms open the enrollment enrollLock 14531 46ms lock the enrollment

dropout 28293 178ms allow to drop out and withdraw the balance Incentive

depositGuarantee 28083 48ms deposit the guarantee

rewardRegisterCost 52949 43ms reward the registration cost for non-payable entity rewardDeploymentCost 51584 41ms reward the deployment for the administrator Registeration

registerAuthority 38276 80ms register the role of third-party authority registerActorDataOwner 38335 71ms register the role of data owner

registerActorDataUser 36555 70ms register the role of data user registerMonitor 36521 72ms register the role of monitor Obligation

recordKSSKReq 43173 96ms publish the key service request snapshot recordKSSKResp 84211 55ms publish the key service response snapshot recordKSConfirm 43402 49ms confirm the receipt of the key service obligation Inspection inspectObligationKS 24511 41ms inspect the key service audit obligation

inspectObligationPP 37482 46ms check the correct of the public parameter

• Obligation Functions. The obligation functions address the core features of theT3_{AB model. As illus-}

trated in Section 6.1.3 Phases III and IV, we use a three-phase commitment approach to achieve the obligation features. To be specific, ‘recordKSPKReq’, ‘recordKSSKReq’ allows the actors to publish the key service request snapshot, while‘recordKSPKResp’, ‘recordKSSKResp’ allows the TPA to record cor- responding key service response snapshot. Then, ‘recordKSPKResp’ function allows us to confirm the receipt of the key service.

• Inspection Functions. The inspection functions address the monitoring task for the recorded audit obliga- tion as discussed in Section 6.1.3. To be specific,‘inspectObligationKS’ function allows to automatically inspect the completeness of the key service obligations, while‘inspectObligationPP’ function permits the monitor to verify the published identity-to-public-key binding. Regarding the incentive design, if the dishonest behavior is detected, the corresponding entity will be fined a fixed number of ether as the incentive reward for the monitor.

Experimental Setup. Our experiments are performed on a Macbook Pro platform with 2.3GHz 8-Core Intel Core i9 processors and 32GB DDR4 memory. Besides, we use the Ethereum official test network - Rinkeby as the experimental environment to deploy our implemented smart contract. Furthermore, we write severalJavaScript test-cases using the automated testing framework ofTruffle that is built on Mocha3 _and

provides a cleanroom environment.

Specifically, for demonstration, we use five Ethereum accounts to simulate various entities in T3_AB,

namely, the role of the administrator, the TPA, the data owner, the data user and the monitor. With regards to various scenarios, we write corresponding test-cases to evaluate the performance (i.e., the gas cost and the time cost) such as the administrative scenario, registration scenario, obligation scenario, etc..