Issuer-Free Oblivious Transfer with Access Control Revisited

Contents lists available atScienceDirect

Information Processing Letters

www.elsevier.com/locate/ipl

Issuer-free oblivious transfer with access control revisited

Alfredo Rial

UniversityofLuxembourg,Luxembourg

a r t i c l e i n f o a b s t r a c t

Articlehistory:

Received16March2016

Receivedinrevisedform21May2017 Accepted22May2017

Availableonline26May2017 CommunicatedbyL.Viganò

Keywords:

Cryptography Oblivioustransfer Accesscontrol Idealfunctionality

Oblivioustransferwithaccesscontrol (OTAC)isanextensionofoblivioustransferwhere eachmessageisassociatedwithanaccesscontrolpolicy.A receivercanobtainamessage onlyifherattributessatisfytheaccesscontrolpolicyforthatmessage.Inmostschemes, thereceiver’sattributesarecertifiedbyanissuer.Recently,twoIssuer-FreeOTACprotocols havebeenproposed.WeshowthatthesecuritydefinitionforIssuer-FreeOTACfulfilledby thoseschemesposesaproblem.Namely,thesenderisnotabletoattestwhetherareceiver possessesaclaimedattribute.Becauseofthisproblem,inbothIssuer-FreeOTACprotocols, anymaliciousreceivercanobtainanymessage fromthe sender,regardlessoftheaccess control policyassociatedwiththe message.Toaddressthisproblem, weproposeanew securitydefinition for Issuer-FreeOTAC. Ourdefinition requiresthe receivertoprove in zero-knowledgetothesenderthatherattributesfulfillsomepredicates.Ourdefinitionis suitableforsettingswithmultipleissuersbecauseitallowsthedesignofOTACprotocols where the receiver, when accessing a record, can hide the identity of the issuer that certifiedherattributes.

©^{2017ElsevierB.V.Allrightsreserved.}

1. Introduction

Oblivioustransfer (OT) [1]isa two-party protocol be- tweenasenderandareceiver.Thesenderreceivesasinput N messages

(

m₁

, . . . ,

m_N

)

,whilethereceivergetsK selec- tion values

( σ

1

, . . . , σ

K

)

. As output, the receiver gets the messages

(

mσ1

, . . . ,

mσK

)

.Sendersecurityrequiresthatthe receivergetsnoinformationontheothermessages,while receiver privacy requires that the sender does not learn anyinformationon

( σ

1

, . . . , σ

K

)

.

Oblivioustransferwithaccesscontrol(OTAC)[2]allows the senderto control accessto themessages. The sender receivesasinput

(

m1

,

P1

, . . . ,

mN

,

PN

)

,where

(P

1

, . . . ,

PN

)

are accesscontrolpolicies foreach ofthe messages.Each receiverpossessesa setofattributesA^{andisabletoob-} tainthemessagem_ionlyifA^satisfiesPi.

OTAC schemes involve three types of parties: the sender,whopossessesadatabase

(

m1

,

P1

, . . . ,

mN

,

PN

)

;the

E-mailaddress:alfredo.rial@uni.lu.

issuer,whocertifiesthereceivers’ attributesA^andissues credentialsto receivers; the receivers, who first get their attributescertifiedbytheissuerandsubsequentlyemploy theissuedcredentialstoaccessthesender’sdatabase.

Receiverprivacyrequiresthatthesenderdoesnotlearn anyinformationonthemessagesthereceiverobtainsoron the receiver’s attributes. Sender privacy requires that the receiverdoesnotlearnanyinformationon messagesthat were notrequested oron messageswhose accesscontrol policy is not fulfilled by the receiver’s attributes. Addi- tionally,in some schemes, the accesscontrol policies are hiddenfromthereceivers[3],whileinotherschemesthey arepublic [2,4].Wedescribe indetailthesecurity defini- tionforOTACwithpublicpoliciesinSection2.

Recently, Guleria and Dutta propose Issuer-Free OTAC withpublicpolicies [5,6].InIssuer-Free OTAC, therole of the issueris performedby the sender. In this paper, we showthatthesecuritydefinitionforissuer-freeOTACin[5, 6] poses a problem. In a nutshell, thesecurity definition forOTAC with public policies proposed by Camenisch et al.[2]allowstheissuertolearnthereceiver’sidentityand http://dx.doi.org/10.1016/j.ipl.2017.05.006

0020-0190/©^{2017ElsevierB.V.Allrightsreserved.}

thereceiver’s attributesinordertoattestwhetherthere- ceiverindeedpossessesthoseattributes.Incontrast,inthe security definitionin[5,6],to protectreceiverprivacy,the sender learns neither the receiver’s identity nor the re- ceiver’s attributes, andthus is not ableto attest whether thereceiverpossessestheclaimedattributes.

Thishasseriousimplicationsonthesecurityofthepro- tocols proposed in [5,6]. In those protocols, the sender always proceeds as if the receiver did possess those at- tributes without performing any check. This allows any maliciousreceivertobeissuedanyattribute,whichallows this receiver to obtain anymessage from the sender, re- gardless of the access control policy associated with the message. Consequently, the protocols in [5,6] do not en- forceanyformofaccesscontrol.

We propose a new security definition for Issuer-Free OTAC. Ourdefinitionallowsthereceivertoprove inzero- knowledge to the sender that her attributes fulfill some predicates.Theconcretepredicateswilldependonthein- formationthesenderneedsinordertoattestthereceiver’s attributes. Inthe typicalsetting whereattributesneed to be certifiedbyanissuer,weshowthat ournewfunction- alityisusefultohandlemultipleissuers.

2. Oblivioustransferwithaccesscontrol

Camenisch et al. [2] propose an ideal functionality FOTAC for oblivious transfer with access control (OTAC).

In this section, we recall that idealfunctionality. The in- teraction betweenFOTAC,thesender E^{,the issuer}I^{, and} the receivers R1

, . . . ,

RM takes place through the inter- faces initdb, issue and transfer. The sender E ^{possesses a} list ofmessages

(

m1

, . . . ,

mN

)

.Thesemessages areassoci- ated withthe accesscontrol policies

(

P1

, . . . ,

PN

)

. Anac- cesscontrol policydescribestheattributesthatareceiver must possessinorderto beallowed toobtaina message.

The attributesthatareceiverpossessesarecertifiedby I^. FOTAC maintainsan initiallyemptysetAm

(

m∈ [¹

,

M])^for eachofthereceiversRm.

FunctionalityFOTAC

1. On input

(

initdb

,

m₁

,

P1

, . . . ,

m_N

,

PN

)

from E^, FOTAC stores

(

m1

,

P1

, . . . ,

mN

,

PN

)

.

2. On input

(

issue

,

a

)

from Rm, FOTAC sends

(

issue

,

Rm

,

a

)

to I. I sends back a bit b. If b=^1, FOTAC adds the attribute a to Am and sends b to Rm, else FOTAC simply sends b to Rm.

3. Oninput

(

transfer

, σ )

fromRm,FOTAC proceeds as follows. If

(

m1

,

P1

, . . . ,

mN

,

PN

)

is stored, FOTAC sendstransfertoE.E sendsbackabitb.

Ifb=^{1 andtheattributeset}Amfulfillsthepol- icyPσ,FOTAC sendsthemessagemσ toRm.If b=^{0 or if}

(

m1

,

P1

, . . . ,

mN

,

PN

)

is not stored, FOTAC sends⊥^toRm.

Asdescribed in[2],FOTAC guaranteesthefollowingse- curityproperties:

Receiver Privacy. Whena receiverRm obtainsa message mσ, the sender E ^{learns neither} Rm nor

σ

, i.e., in the transfer phase, the receiver remains anonymous andthe sender does not learn the messagethat the receiver obtains. The sender only learns that an un- knownreceiver gets a messagewhoseaccesscontrol policyisfulfilledbythereceiver’sattributes.

Sender Security. Acorrupt receiver cannot obtaina mes- sagewhoseaccesscontrolpolicyisnotfulfilledbythe receiver’s attributes. Colluding receivers are not able tosharetheir attributes, i.e.,a groupofcolluding re- ceivers isnot ableto getaccessto amessage whose accesscontrol policy isnot fulfilledby theattributes ofa particular receiverin thegroup. If acorrupt re- ceivercolludeswiththeissuer, thenthereceiver can obtainonerecordateachtransferphase.

3. Issuer-freeoblivioustransferwithaccesscontrolin [5, 6]

We recall the idealfunctionalityFIOTAC for issuer-free OTACproposed byGuleria andDutta[5,6].The difference between FIOTAC andthe functionalityFOTAC described in Section2isintheissuingphase.Therefore,weonlyrecall theissueinterfaceofFIOTAC.

FunctionalityFIOTAC:interfaceissue

2. Oninput

(

issue

,

a

)

fromRm,FIOTAC sendsissue toE^.E ^{sendsbackabitb inresponsetoissue.}

Ifb=^1,FIOTAC addstheattribute ato Am and sendsb toRm,elseFIOTAC doesnothing.

Ascanbe seen,inFIOTAC,incontrasttoFOTAC,theis- suer isnot present andthe issuing phase isexecuted by thesender E ^{andby thereceiver}Rm.Additionally, while inFOTACtheissuerreceivestheidentityofthereceiverRm andtheattribute a,in FIOTAC thesender receives neither Rmnora.

Thelatterdifferencecreatesaproblem.Inarealproto- colthat realizesFOTAC,theissuercan receivetheidentity ofthereceiverRmandtheattributea.Basedonthatinfor- mation,theissuerisabletoattestwhetherRm possesses the attribute a, and, inthat case, theissuer issuesa cre- dentialonthatattributetoRm.However, inanyrealpro- tocol that realizes FIOTAC, the sender cannot receive any information on Rm ora whatsoever. (The reasonis that, intheidealprotocol, thesenderdoesnotreceive thatin- formation.) In that case, how is the sender supposed to decidewhetherthereceiverpossessesthatattribute?This hasserious implicationson thesecurityofthereal world protocols that realize FIOTAC proposed in [5,6]. In those protocols,thesenderdoesnotreceiveanyinformationon theattributesoronthe identityofthe receiverintheis- suingphase, andinfact thesender alwaysproceedsasif thereceiverdidpossessthoseattributeswithoutperform- ing any check. This allows any malicious receiver to be

issued anyattribute, which allows thisreceiver to obtain anymessagefromthesender.Consequently,therealworld protocols in[5,6] donot enforceany formofaccesscon- trol.

4. Newidealfunctionalityforissuer-freeOTAC

A trivial way to solve the problem in the functional- ity FIOTAC for Issuer-Free OTACproposed by Guleria and Dutta[5,6] wouldbe tomodify theissuingphase sothat FIOTACsendstothesendertheidentityRmofthereceiver andtheattribute a. However,thiswouldweakenthepri- vacypropertiesofFIOTAC incomparisontoFOTAC,sincein FOTAC the senderdoesnot learn those values.The issuer doeslearnthosevalues,butitisgenerallyconsideredthat receivers are willing toput moretrust ina credential is- suerthaninasender.

Therefore,weproposeanewfunctionalitythatbalances receiverprivacy andsendersecurity. Ourfunctionalityal- lowsthereceivertoprove inzero-knowledgesomestate- ments aboutthereceiver’sattributes. Tothisend, we pa- rameterizedthe functionalityFIOTAC witha relationR. In the issuing phase,the receiver sends to the functionality F_IOTAC^{R an attribute a, a witness wit andan instance ins.}

F_IOTAC^R verifiesthat

(

^a

,

wit

,

ins

)

∈^{R.(Theattributeaisin-} cludedinthewitnessfortherelationR.)Iftheverification succeeds,F_IOTAC^{R sends theinstanceins tothesender. We} formallydescribetheissuingphaseofFIOTAC^R below.

FunctionalityF_IOTAC^{R :interfaceissue}

2. On input

(

issue

,

a

,

wit

,

ins

)

from Rm, F_IOTAC^R aborts if

(

^a

,

wit

,

ins

)

∈

/

^{R. Else,} F_IOTAC^R sends

(

issue

,

ins

)

toE^.E ^{sendsback abitb.Ifb}=^1, F_IOTAC^{R addstheattribute a to}Am andsendsb toRm,elseF_IOTAC^R simplysendsbtoRm.

In anyreal world protocolthat realizes F_IOTAC^R ,in the issuing phase, the sender can learn the fact that the re- ceiver’sattributesfulfilltherelationRwithrespecttothe instanceins.Thisallowsthedesignofrealworldprotocols wherethereceivercan provetothe senderstatementsin zero-knowledge about her attributes, so that the sender can certify that the receiver possesses those attributes basedon theproven statements.The concretestatements that the receiver must prove depend on the information thesenderneedsinordertoattestthereceiver’sattributes.

InSection4.1,wedescribetheuseofF_IOTAC^{R inthetypical} casewhereattributesneedtobecertifiedbyanissuer.

4.1. ApplicationsofthenewidealfunctionalityF_IOTAC^R

A protocol that realizes FOTAC involves the sender E^, the issuer I^{, and the receivers} R ^{and consists of three} phases:initdb,issue,andtransfer.Intheinitdbphase,E en- cryptsthe messagesandpublishesanencrypteddatabase where each messageis associated with anaccesscontrol

policy.Inthe issuephase, Rsends some attributesto I, I^{certifiesthat} R^{indeedpossessesthose}attributes,signs R^{’sattributesby using} I^{’ssecret keyand sendsthe sig-} naturetoR^{.Inthetransferphase,}R^{choosesthemessage} thatshewantstoobtainandprovesinzero-knowledgeto E ^{thatshepossessesasignaturefrom}I^{onattributesthat} satisfytheaccesscontrolpolicyassociatedwiththatmes- sage.AfterE ^{verifiesthis}zero-knowledgeproof,E ^helpsR todecryptthemessage(withoutlearningthemessagethat Rdecrypts).

Thereasonwhyalltheexisting OTACschemes(except theissuer-free ones by Guleria andDutta) includean is- suer is the following. Receivers need to prove that their attributesfulfill the access control policy associated with amessage.Thisrequiresthat some partycertifies R^{’s at-} tributes.Inpracticalapplications,thatpartyneedstolearn R^{’sattribute valuesinorder tocertifythem. Thisstepis} unavoidablebecause,withoutlearningtheattributevalues (e.g.,age,nationality,address,. . . )claimedbyR^,verifying their truthfulnessis not possible.Forprivacy reasons,re- ceiversmaybeunwillingtorevealtheirattributestoE^.To solve this problem, OTAC schemes include a third party, the issuer, that is only in charge of certifying receiver’s attributesandto whomreceiver’s accept todisclosetheir attributes.In practice,I ^{wouldbean authority suchasa} municipalityorthepolice.

Theissuer-freeOTACschemes byGuleriaandDuttado notworkbecauseattributecertificationdoesnottakeplace andthusreceivers can claimanyattribute they wish and obtainanymessage.Therefore,sinceintypicalsettingsis- suers are necessary, the reason why we propose a new functionalityFIOTAC^R isnottoeliminate theneedofan is- suer.Instead,thenewfunctionalityallowsthecreationof OTACprotocolsformultipleissuers.

Consider a setting where E ^{only trusts one issuer to} certifyR^’sattributes.Inthiscase,usingthenewfunction- alityF_IOTAC^{R is}cumbersome.Thereasonisthattherelation Rthat parameterizes the functionalitywouldrequirethat R ^{proves in} zero-knowledge possession of a credential fromtheissuertrustedby E.Therefore,ina protocolthat realizesF_IOTAC^{R ,}R^{wouldfirstgethisattributescertifiedby} I^{togetacredentialfrom}I^,thenR^{wouldproveinzero-} knowledge possession of the credential to E^{, and finally} E wouldgive yetasecond credentialthat signsthesame attributesto R^. Consequently,in settings whereE ^trusts only one issuer, the new functionality F_IOTAC^{R should not} be used. Instead, the existing functionality FOTAC should beused.

However, the new functionality FIOTAC^R is appealing whenE^{trustsmorethanoneissuer.Thissettingcannotbe} handledby the existing functionality FOTAC. Additionally, modifying thefunctionality andthe corresponding proto- colstoincludemorethanoneissuerisnotstraightforward.

Theproblemisthefollowing.Considerasettingwithtwo issuersI1 andI2,wheresome accesscontrolpoliciesre- quirethat attributesbe certifiedby I1 andothers by I2. Inthatcase,whenRprovesinzero-knowledgepossession ofhercredential,despitethefactthattheattributevalues arenotrevealedtoE^,E ^{learnstheidentityoftheissuerof}

R^(c,Ac,sc,rc,stU,pkI,pkE) E^(skE,pkE,pkI,P) Parsepk_I=(g₁,h₀,h₁,h₂,u,v,w,g_t,h_t,y_I)

ParsepkE=(ˆg1,hˆ0,hˆ1,hˆ2,hˆ3,uˆ,vˆ,wˆ,gˆt,hˆt,yE) Parsest_U=(P,z_U)and pick randomr₁,t,t←Zp ComputeP1← ˆ^hc1hˆ^r₃¹,A¯←^Acu^tandB←^vtut Compute PK₁=^PK{(^zu,c,r₁,I,s_c,r_c,t,t,α, β): P= ˆ^hz0^U ∧ ^P1= ˆ^hc1hˆ^r₃¹ ∧^B=^vtut∧ 1=^B−scvαuβ ∧ e^e(^(¯g^A1^,,^yg^I1⁾)=^e(A¯,g1)^−sce(u,yI)^t· e(u,g1)^αe(h2,g1)^rce(h0,g1)^zUe(h1,g1)^c}

Send(P,P1,PK1,A¯,B) → Verify PK1and parseskE=xE

ParsepkE=(^gˆ1,hˆ0,hˆ1,hˆ2,hˆ3,^uˆ,^vˆ,^wˆ,^gˆt,hˆt,yE) Pick randomr2,s_c←Zp

ComputeA_c←(ˆ^g1PP1hˆ₂^Ihˆ^r₃²)^1/(xE+sc) Setr_c←^r1+^r2 ← ^Send(A_c,s_c,r₂)

Verifye(A_c,gˆ₁^scyE)=^e(ˆg1Phˆ^c₁hˆ^I₂hˆ^r₃^c,ˆg1)

Fig. 1.Construction for functionalityFIOTAC^R : interfaceissue.

the credential. This harmsreceiver privacy becauseit re- veals toE ^{whetherthe messagethat} R^{wishes toobtain} isassociatedwithanaccesscontrolpolicythatrequiresat- tributescertifiedbythatissuer.

Thisproblemcanbesolvedbyusingaprotocolthatre- alizes the new functionality FIOTAC^R . In our example, the relation RrequiresR^{to provein}zero-knowledgeposses- sionofcredentialsfromI1 orI2.Intheissuingphaseofa protocolthatrealizesF_IOTAC^R ,Rproves inzero-knowledge possessionofacredentialfromI1 orI2 toE^,andthenE sendsanewcredentialtoR^{thatsignsthesameattribute} values plus the identity of I1 or I2. The access control policies only accept credentials signed by E ^andinclude I’sidentityasanattribute.Therefore,becauseI’sidentity isnowanattribute,I^{’sidentityisnotrevealedto}E ^when R ^{proves possession ofa credential inorder to obtain a} message.

As a concrete example, we show how to modify the OTAC protocolbyCamenisch etal[2]so thatit can han- dle multiple issuers. At setup, each of the issuers I ^run the protocolISetup described in Figure 2 in [2] inorder to computea privatekey sk_I=^xI andapublickey pk_I=

(

g1

,

h0

,

h1

,

h2

,

u

,

v

,

w

,

gt

,

ht

,

yI

)

tocomputeandverifysig- natures. The sender E alsoruns the protocolin Figure 2 in[2]tocomputeskE andpkE,butpkE consistsofanad- ditionalelementhˆ₃.ThedatabasesetupalgorithmDBSetup inFigure3in[2]remainsunchanged,exceptthat,foreach recordofdataRi,theattributeci1intheaccesscontrollist ACL_i=

(

c_i1

, . . . ,

c_il

)

is theidentity ofan issuer.Areceiver mustgether attributescertifiedbythisissuerinorderto satisfy ACL_i.

The issuingphaseisdividedintotwoparts.First,are- ceiver runs multiple times withone ormore issuers the issuing protocol Issue described in Figure 4 in [2]. As a result of each execution of the issuing protocol, the re- ceiver obtains a signature

(

A_c=

(

g₁P h^c₁h^r₂^c

)

^1/(xI+sc)

,

s_c

,

r_c

)

that signsher secretkey zU (P =^hz₀^{u)andone ofher at-} tributes c. Second, thereceiver gets her attributessigned by the sender. Thisstepcorresponds to therealization of theissueinterfaceofourfunctionalityF_IOTAC^R .Wedescribe the protocol in Fig. 1. A receiver executes this protocol once foreachofthesignaturesissuedbytheissuers.Ina singleexecution,thereceiverinputsasignature

(

A_c

,

s_c

,

r_c

)

and the identity I of the issuer,while the sender inputs

his signingkeypair

(

skE

,

pkE

)

. Asresult, thereceiverob- tainsasignature

(

A_c=

(

g₁Phˆ^c₁hˆ^I₂hˆ^r₃^c

)

^1/(xI+sc)

,

s_c

,

r_c

)

signed bythesenderonhersecretz_U,onherattributec,andon theissueridentityI.

Finally,a receiver andthe sender execute the transfer algorithmTransferdescribedinFigure5in[2].InFigure5 in[2],thereceiverprovesinzero-knowledgetothesender that shepossessesone signature

(

A_c

,

s_c

,

r_c

)

issuedby the issuer foreach of the attributesin ACL_i.We require two modifications.First, insteadofusingsignatures

(

Ac

,

sc

,

rc

)

signed by issuers, the receiver uses signatures

(

A_c

,

s_c

,

r_c

)

signedbythesender.Second,becausenowACL_ialsocon- tainstheidentity oftheissuer,thereceiver,inadditionto provingthattheattributecsignedin

(

A_c

,

s_c

,

r_c

)

equalsone oftheattributes

(

c_i2

, . . . ,

c_il

)

inACL_i,provesalsothat the issueridentitysignedin

(

A_c

,

s_c

,

r_c

)

equalsc_i1.

5. Conclusion

We haveshownthat thesecurity definitionforIssuer- Free OTAC in [5,6] poses a problem. Namely, it does not allowthesendertoattestwhetherareceiverpossessesthe claimedattributes. Intheprotocolsproposed in[5,6],any maliciousreceivercanobtainanymessagefromthesender, regardlessoftheaccesscontrolpolicyassociatedwiththe message. Consequently, the protocols in [5,6] do not en- force anyformofaccesscontrol.Toaddressthisproblem, wehaveproposedanewsecuritydefinitionforIssuer-Free OTAC.Ourdefinitionrequiresthereceivertoproveinzero- knowledge to the sender that her attributes fulfill some predicates.Ourdefinitionissuitableforsettingswithmul- tipleissuersbecauseitallowsthedesignofOTACprotocols wherethereceiver,whenaccessinga record,canhidethe identity of the issuer that certified her attributes. In the table below, we compare the properties of our approach withOTACin[2]andIssuer-FreeOTACin[5,6].

Receiver Privacy

Sender Security

MultipleIssuers Support

OTAC[2] ⊥

Issuer-Free OTAC[5,6]

⊥ ⊥

Ourapproach

References

[1]J.Camenisch,G.Neven,A.Shelat,Simulatableadaptiveoblivioustrans- fer,in:M.Naor(Ed.),EUROCRYPT,in:LectureNotesinComputerSci- ence,vol. 4515,Springer,2007,pp. 573–590.

[2]J. Camenisch, M. Dubovitskaya, G. Neven, Oblivious transfer with access control,in: E.Al-Shaer, S. Jha, A.D. Keromytis(Eds.), ACM ConferenceonComputerand CommunicationsSecurity,ACM,2009, pp. 131–140.

[3]J.Camenisch,M.Dubovitskaya,G.Neven,G.M.Zaverucha,Oblivious transferwithhiddenaccesscontrolpolicies,in:D.Catalano,N.Fazio,

R.Gennaro,A.Nicolosi(Eds.), PublicKeyCryptography, in:Lecture NotesinComputerScience,vol. 6571,Springer,2011,pp. 192–209.

[4]A.Rial,Blindattribute-basedencryptionandoblivioustransferwith fine-grained access control, Des. Codes Cryptogr. 81 (2) (2016) 179–223.

[5]V.Guleria,R.Dutta,Issuer-freeadaptiveoblivioustransferwithaccess policy,in:InformationSecurityandCryptology,ICISC2014,Springer, 2014,pp. 402–418.

[6]V.Guleria,R.Dutta,Universallycomposableissuer-freeadaptiveobliv- ioustransferwithaccesspolicy,Secur.Commun.Netw.8 (18)(2015) 3615–3633.