PRESENTACIÓN Y ANALISIS DE LOS RESULTADOS

T3_{AB Model. Unlike the authority transparency model in [190] that builds on the secure logging system}

for attribute-based encryption (ABE) cryptosystem, T3_{AB uses the Ethereum blockchain, and to keep}

consistency, we adopt the similar concepts/notions of the authority transparency model but it considers different scenarios including FE-based applications and blockchain-based public ledger infrastructure.

Unlike ABE-based applications, in FE-based applications, there is no need to define complex attribute identities in the functional encryption scheme, and hence, we update the related concepts with consideration of the simplified identities and smart contracts.

Suppose that each entity ein T3AB is issued or self-generates an identity-based public and private key pair hpke,skei. Besides, the key service occurs between entity Cactor and authority A, where each entity has already owned its public and private key pair. For instance, let hpkactor,skactori and hpkTPA,skTPAi

represent the public/private key pairs of the actor and the TPA, respectively. Here, we first present the notion ofpublic parameter audit obligation and key service audit obligation, and then the formal definition ofT3_ABmodel.

Definition 2(Public Parameter Audit Obligation (PPAO)). A PPAOOppofeis a map structure as follows:

Oe

pp :=H(eid) :heid,pke,Sigske(eid,pke)i, (6.1)

where eid represents the descriptive identifier of e, H(·) is the hash function, pke denotes the public key

binding of entity e, and Sig_ske is the signature using ske.

a pair of key service snapshots

O_ksCactor,A:=H(Cidactor,Aid, r) :hSreq,Srespi, (6.2)

where each snapshot is a 4-tuple as follows:

Sreq :=H(Cidactor,Aid, r) :hr, f, tCactor,Sig_sk

actor(r, f, tCactor)i, (6.3)

Sresp:=H(Cidactor,Aid, r) :hr,Sigma, tA,SigskTPA(r,Sigma, tA)i, (6.4) such that

Sreq.H(Cidactor,Aid, r) =Sresp.H(Cidactor,Aid, r) (6.5)

Sresp.tA− Sreq.tCactor>0 (6.6)

Sreq.tA− Sresp.tCactor< δ_t (6.7)

whereris the nonce selected by the key service requester,tis the timestamp of key service processed by each entity,f denotes the request content such as function related vector, Sigmarepresents the proof-of-work that TPA has issued the key,δtis the threshold of timestamp difference indicating the expected time of processing

of the key service request by the TPA.

Remark. In particular, theOppis anidentity-to-public-keybinding with the issuer’s signature, whileO_ksCactor,A is the proof-of-key-service. In theOC_ksactor,A, for simplicity, to provide theproof-of-work of issuing the func- tional private key skf for the function related materialsf, let Sigmabe H(skf).

Based on the notion ofpublic parameter audit obligationandkey service audit obligation, we present the formalT3_{AB model as follows:}

Definition 4 (T3AB Model). Let A,B and C denote the third party authority, blockchain, and actor, respectively, which are parties involved in the interactive protocols. LetC.actorandC.monitor represent the roles of the actor and monitor that execute the functional and monitoring modules, respectively. We define T3_{ABmodel Mas a set of five interactive protocols:}

MA_O,B,C = (GenO,LogOpp,LogOks,Inspect), (6.8)

and each protocol is defined as follows:

(SOpp, SOks)←Run(1 λ_,Gen

O,{A,C.actor}) (6.9)

(bA, ε)←Run(1λ,LogOpp,{A,B},(SOpp, ε)) (6.10) (bA, bC, ε)←Run(1λ,LogOks,{A,C.actor,B},(Oks.SA,Oks.SC, ε)) (6.11)

(bB, ε)←Run(1λ,Inspect,{B,C.monitor},(ε, ε)) (6.12)

Lemma 4. If the hash function is collision-resistant and the signature scheme is unforgeable, then T3AB model comprises a secure transparency framework.

Remark. Note that the formal definition of ourT3AB model is inherited from the authority transparency

model [190] with needed changes considering the underlying Ethereum blockchain infrastructure. Specifically, in the authority transparency model, thegossipprotocol essentially ensures the consistency of distributed logs without being tampered by an adversary, while thecheck protocol guarantees that the submitted obligations are recorded by the logging system. As T3_{AB adopts the Ethereum blockchain as the underlying public}

ledger infrastructure, there is no need to run the gossip and check protocols because these logging-related functions are the implicit feature in the Ethereum smart contract.

Design of BT3AB

SC . The T3AB smart contract is a critical component in our framework. To support the goal of T3_{AB framework,B}T3AB

SC includes various types of modules: administrative module, access control

module, obligation module, inspection module, andincentive module. Each module is presented as follows:

Administrative module allows the role of administrator to deploy the smart contract into the Ethereum network. The module also includes functions such as opening and locking the enrollment, allowing the participants to drop out.

Access control module supports a basic role based access control mechanism that allows the account (a.k.a, the participating entities) have permission to call role-related functions. InBT3AB

SC , we define four types of roles: theTPA, theactors of data owner, theactors of data user, themonitors and theadministrator (i.e., the smart contract owner). Obviously, the administrative entity who deploys the smart contract becomes the smart contract owner. The ownership can be transferred to a new account if necessary. Besides, it is also possible to relinquish this administrative privilege, which is a common pattern after an initial stage when there is a decentralized administration requirement. After the deployment, each entity needs to register its role by calling the corresponding function before they can use the ordinary features of the smart contract.

Obligation module works on recording the audit obligation into the public ledger. Regarding the entity registration, it also publishes its identity-to-public-key binding to the Ethereum blockchain, as illustrated above. Note that the identity of the entity is the unique public address (i.e., 42 hex string characters without case-sensitivity) of the blockchain account, which is derived from the entity’s private key. With regards to the key service audit obligation procedure, the key service requestor (i.e., data owner) can call the corresponding function that includes role verification with a randomly generated request identifier, the key-related request parameters, and the corresponding signature. The function then automatically analyzes the key-related request parameters via executing theInference Prevention Module (IPM). Note thatBT3AB

SC has already integrated the IPM module that is previously integrated in the TPA entity as illustrated in Chapter 3, Chapter 4, and Chapter 5.2. Upon receiving the key service request with the request identifier, the TPA first checks the verification result of IPM. If the request passes the verification, the TPA will issue the functional private key and then publish a response snapshot to fulfill the key service obligation.

TPA’s fulfill its key service obligation or not. Besides, it also allows to check the publishedidentity-to-public- key binding. Beside the inspection module that can prevent potential misbehaviors, we have introduced the access control mechanism to prevent partial misbehaviors and malicious behaviors as each entity only will be allowed to call corresponding functions with limited privilege.

Incentive module in the BT3_AB

SC includes several functions to achieve the incentive mechanism, as depicted in Figure 6.3. The incentive mechanism is based on payment features of the Ethereum network, where the token can be exchanged to real concurrency. As illustrated in Figure 6.3, we design several functions as ‘public payable’, which indicates that the smart contract is able to receive the transaction value (e.g., the Ether) when the function is successfully called and executed.

In general,mdata users need to equally pay for the cost of calling registration function for themselves as well asndata owners and the TPA. Each data user also needs to pay for the cost of callingrequest obligation record function and also the cost of calling response obligation record function by the TPA. Additionally, there exists a mechanism to punish the misbehaviors and malicious activities by adishonest TPA and data users. To achieve that, the data users and the TPA first need to register and pay the cost by themselves. The data owners equally make a deposit for all the entities’ registration cost after the enrollment phase. Then, the data users and the TPA can call the disposable reward function to withdraw the registration cost. Besides, we make the TPA and data owners make a guarantee deposit after the registration phase. The monitors can register and pay the cost by themselves, and then calls the inspection function to check the suspicious behaviors. If monitors find the malicious behaviors, they will acquire the reward from the fine to the corresponding entity (i.e., the guarantee deposit of the entity). Without the guarantee deposit, the corresponding entity is not allowed to operate in the system. Additionally, we discuss the quantitative analysis of the cost of each entity inBT3AB

SC in Section 6.3.

T3_{AB Procedures. As depicted in Figure 6.2, we illustrate the four phases of theT}3_{ABframework with}

specific procedures in a typical FE-based application scenario. Note that the dashed arrows represent the functional procedures of a typical FE-based application, while the solid arrows denote procedures of the

T3_{AB framework. In our design, each entity in the FE-based application can also play the role of the}

auditor and monitor in the T3AB framework, and we also allow additional monitors to help inspect the misbehaviors and malicious behaviors.

Here, we present the specific procedures of each phase in theT3_{ABframework as follows:}

Phase I: entity initialization: For each entityewith roleeroleand identifiereidin the framework, it generates a public and private key pairhpke,skei. Then, entity eregisters its role erole toBT

3_AB

SC , and publish itsid-

to-public-key binding heid,pkeiwith its signature Sigske(eid,pke) toB T3AB SC .

Phase II: FE initialization. The TPAAsetups the FE cryptosystem with the master public key and master private key pairhmpkFE,mskFEi. Using the master keys, the TPA generates and sends the common public key pkFEcom for all entities (i.e., data owners and data users) in the FE-based application. Then, the TPA publishes the bindinghAid,pkFEcomiwith its signature Sigsk_A(Aid,pk

FE

com) toBT 3_AB SC .

Figure 6.2: Illustration of the four phases ofT3_{AB framework in a FE-based application scenario}

Phase III: secure data publishing. For each data owner Cowner

i , it first selects a nonce r as the key service identifier. Then Cowner

i requests the entity-specific public key pk

FE

Cowner

i from the TPA with r. Meanwhile, Cowner

i also sends a request key service snapshotS

Ciowner req toBT 3_AB SC as follows: SCiowner req =hr,0, tCowner i ,SigskCowner i ( r,0, tCowner i )i. (6.13)

Then, the TPA generates pkFECowner i for C

owner

i using its master keys, and also publishes a corresponding response key service snapshotSA

resptoBT 3_AB

SC to fulfill its key service audit obligationO

Cowner i ,A

ks with mapping key H(Cowner

i,id ,Aid, r) as follows: SA resp=hr,H(pk FE Cowner i ), tA,SigskA(r,H(pk FE Cowner i ), tA)i. (6.14)

Each data owner then uses pkFEeowner

i to encrypt its data as {EncpkFEeowner i

(xi)}i∈[n]. Finally, the data owner

publishes a receipt for the received pkFEeowner i .

Phase IV: secure data computation. Suppose that a data userCuser

j who has a vectoryyyj= (y1, ..., yn)jwould apply inner-product functionality over the encrypted data {Enc(x1), ...,Enc(xn)}. Cjuser also select a key service identifier r0 first, and then requests the functional private key skFE

y

yyj to the TPA with the vectoryyyj andr0. At the same time,Cuser

j also sends the request key service snapshotS

Cuser j req toBT 3_AB SC as follows: SC user j req =hr0, yyyj, tCuser j ,SigskCuserj ( r0,0, tCuser j )i. (6.15)

Unlike the approaches proposed in [191, 189] that deploy the inference prevention module (IPM) into the TPA, we propose to deploy IPM in the smart contract as the TPA is not fully trusted in theT3ABframework. Thus, the TPA needs to queryBT3AB

skyFEyyj forC

user

j using its master keys, and then publishes a corresponding response key service snapshotSrespA

toBT3AB

SC to fulfill its key service audit obligationO

Cuser j ,A

ks with mapping key H(C

user j ,A, r0) as follows: SrespA =hr0,H(sk FE y y yj ), tA,SigskA(r 0_,H(skFE yyyj ), tA)i. (6.16) Otherwise, the TPA legally refuses the key service and also publishes key service snapshot indicating that it has legally refuse the key service. SA,refuse

resp with refusing symbol⊥to BT

3_AB

SC to fulfill its key service audit obligation as follows: SA,refuse resp =hr0,H(⊥, yyyj), tA,Sigsk_A(r0,H(sk FE y yyj ), tA)i. (6.17) With the received skFE

y y

y , data user can compute the inner-product ofhxxx, yyyiby decryting as follows: hxxx, yyyji= DecskFE y y yj({EncpkFECowner i (xi)}i∈[n]). (6.18)

Finally, the data owner publishes a receipt for the received skFE

y y y .

Remark. To avoid redundant description, we do not present the roles ofauditor andmonitor in the above- discussed procedures. In particular, as illustrated in Figure 6.2, the data users, data owners and the TPA

also play the role of auditor that checks whether the audit obligations are recorded into the blochchain permanently. In our design, thedata ownersalso play the role of a monitor to check the suspicious obligations caused by misbehaviors and malicious behaviors from the TPA and adversarialdata users. For instance, as illustrated in [191, 189], an adversarial data user may infer the private vectorxxxby manipulating a vector to request the functional private key. The monitor can inspect Oe_ksuser,eTPA to find adversary’s suspicious behaviors.