privacy-aware proof-carrying authorization

6
Position Paper: Privacy-Aware Proof-Carrying Authorization Matteo Maffei Saarland University maff[email protected] Kim Pecina Saarland University [email protected] Abstract Proof-carrying authorization (PCA) is one of the most pop- ular approaches for the enforcement of access control poli- cies. In a nutshell, the idea is to formalize a policy as a set of logical rules and to let the requester construct a formal proof showing that she has permissions to access the desired resource according to the provider’s policy. This policy may depend on logical formulas that are assumed by other prin- cipals in the system. The validity of these formulas is wit- nessed by digital signatures. The usage of digital signatures, however, has a serious drawback, i.e., sensitive data are leaked to the verifier, which severely limits the applicability of PCA. In this paper, we introduce the notion of privacy-aware proof-carrying autho- rization, an extension of PCA based on a powerful combi- nation of digital signatures and zero-knowledge proofs of knowledge of such signatures. The former are used to wit- ness the validity of logical formulas, the latter to selectively hide sensitive data. Our framework supports a variety of pri- vacy properties, such as data secrecy and user anonymity. We conducted an experimental evaluation to demonstrate the feasibility of our approach. Categories and Subject Descriptors C.2.0 [General]: Se- curity and protection; F.3.1 [Semantics of Programming Languages]: Specification techniques General Terms Design, Security, Verification Keywords Proof-carrying authorization, Zero-knowledge 1. Introduction Access control is a central ingredient in virtually any secu- rity infrastructure. The fundamental idea is to define a secu- rity policy ruling the operations on sensitive resources and Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. PLAS’11 June 5, 2011, San Jose, California, USA. Copyright c 2011 ACM 978-1-4503-0830-4/11/06. . . $10.00 to let a reference monitor filter access requests in a way that an operation is allowed only if the requester has sufficient permissions according to the security policy. Depending on the complexity of the security policies, the task of the refer- ence monitor may be very hard: exploring the whole security policy and inferring whether or not the requester has indeed sufficient permissions to perform a certain operation may be computationally expensive and algorithmically non-trivial. Fortunately, the same task is much easier for the requester, who is typically aware of the security policy and knows why she should be granted access to the desired resource. This key insight is at the basis of the concept of proof-carrying authorization (PCA) [3]. The central idea is to formalize the security policy as a set of logical rules and let the requester construct a formal proof, corresponding to a logical deriva- tion tree, showing that she has permissions to access the de- sired resource according to the security policy. The proof is sent along with the access request to the reference monitor, which has just to check the correctness of the proof. This task is typically straightforward and computationally inex- pensive (actually, linear in the size of the proof). The security policy enforced by a reference monitor may of course depend on permissions granted by other entities in the system. For instance, consider the following access control rule: x. isDoctor(x)= mayReadRecord(x, Alice ) (1) This rule says that every doctor may read the record of patient Alice . The security policy states that the predicate isDoctor is controlled by the hospital administration, as for- malized below: x. Admin says isDoctor(x)= isDoctor(x) (2) In order to read the record of patient Alice , the Doctor has to prove to the reference monitor that the predicate Admin says isDoctor(Doctor ) holds true. In PCA, predi- cates of this form are witnessed by digital signatures, which are part of the proof sent by the requester. In our exam- ple, the Doctor must be in possession of a digital sig- nature issued by the Admin on (the bit-string encoding of) the predicate isDoctor(vk Doctor ), which we write as sign(isDoctor(vk Doctor )) sk Admin . Notice that we assume a

Upload: uni-saarland

Post on 04-Feb-2023

1 views

Category:

Documents


0 download

TRANSCRIPT

Position Paper:Privacy-Aware Proof-Carrying Authorization

Matteo MaffeiSaarland University

[email protected]

Kim PecinaSaarland University

[email protected]

AbstractProof-carrying authorization (PCA) is one of the most pop-ular approaches for the enforcement of access control poli-cies. In a nutshell, the idea is to formalize a policy as a setof logical rules and to let the requester construct a formalproof showing that she has permissions to access the desiredresource according to the provider’s policy. This policy maydepend on logical formulas that are assumed by other prin-cipals in the system. The validity of these formulas is wit-nessed by digital signatures.

The usage of digital signatures, however, has a seriousdrawback, i.e., sensitive data are leaked to the verifier, whichseverely limits the applicability of PCA. In this paper, weintroduce the notion of privacy-aware proof-carrying autho-rization, an extension of PCA based on a powerful combi-nation of digital signatures and zero-knowledge proofs ofknowledge of such signatures. The former are used to wit-ness the validity of logical formulas, the latter to selectivelyhide sensitive data. Our framework supports a variety of pri-vacy properties, such as data secrecy and user anonymity.We conducted an experimental evaluation to demonstrate thefeasibility of our approach.

Categories and Subject Descriptors C.2.0 [General]: Se-curity and protection; F.3.1 [Semantics of ProgrammingLanguages]: Specification techniques

General Terms Design, Security, Verification

Keywords Proof-carrying authorization, Zero-knowledge

1. IntroductionAccess control is a central ingredient in virtually any secu-rity infrastructure. The fundamental idea is to define a secu-rity policy ruling the operations on sensitive resources and

Permission to make digital or hard copies of all or part of this work for personal orclassroom use is granted without fee provided that copies are not made or distributedfor profit or commercial advantage and that copies bear this notice and the full citationon the first page. To copy otherwise, to republish, to post on servers or to redistributeto lists, requires prior specific permission and/or a fee.PLAS’11 June 5, 2011, San Jose, California, USA.Copyright c© 2011 ACM 978-1-4503-0830-4/11/06. . . $10.00

to let a reference monitor filter access requests in a way thatan operation is allowed only if the requester has sufficientpermissions according to the security policy. Depending onthe complexity of the security policies, the task of the refer-ence monitor may be very hard: exploring the whole securitypolicy and inferring whether or not the requester has indeedsufficient permissions to perform a certain operation may becomputationally expensive and algorithmically non-trivial.Fortunately, the same task is much easier for the requester,who is typically aware of the security policy and knows whyshe should be granted access to the desired resource. Thiskey insight is at the basis of the concept of proof-carryingauthorization (PCA) [3]. The central idea is to formalize thesecurity policy as a set of logical rules and let the requesterconstruct a formal proof, corresponding to a logical deriva-tion tree, showing that she has permissions to access the de-sired resource according to the security policy. The proof issent along with the access request to the reference monitor,which has just to check the correctness of the proof. Thistask is typically straightforward and computationally inex-pensive (actually, linear in the size of the proof).

The security policy enforced by a reference monitor mayof course depend on permissions granted by other entitiesin the system. For instance, consider the following accesscontrol rule:

∀x. isDoctor(x) =⇒ mayReadRecord(x,Alice) (1)

This rule says that every doctor may read the record ofpatient Alice . The security policy states that the predicateisDoctor is controlled by the hospital administration, as for-malized below:

∀x. Admin says isDoctor(x) =⇒ isDoctor(x) (2)

In order to read the record of patient Alice , the Doctorhas to prove to the reference monitor that the predicateAdmin says isDoctor(Doctor) holds true. In PCA, predi-cates of this form are witnessed by digital signatures, whichare part of the proof sent by the requester. In our exam-ple, the Doctor must be in possession of a digital sig-nature issued by the Admin on (the bit-string encodingof) the predicate isDoctor(vkDoctor ), which we write assign(isDoctor(vkDoctor ))skAdmin

. Notice that we assume a

public-key infrastructure mapping principal identities to ver-ification keys.

PCA is successfully deployed in the context of Web ap-plications [7], mobile devices [8], file systems [13, 15],and distributed programming [4, 18]. Despite its eleganceand effectiveness, however, PCA suffers from a seriouslimitation: disclosing signatures to the reference monitormay lead to undesirable privacy violations. For instance,let us extend the previous example as follows: suppose thata company has a policy stating that employees are justi-fied to be out of the office if they have to go to the hos-pital for a visit on the same day. After each visit, doc-tors give their patients a signature to witness the predicateDoctor says visit(patient , date, results), where the fieldresults includes diagnosis, prescription, and other, possiblysensitive, data. The policy of the company comprises the fol-lowing rules:

∀x, y.∃z. visit(x, y, z) =⇒ OkOff(x, y) (3)∀d, x, y, z. isDoctor(d) ∧ d says visit(x, y, z)

=⇒ visit(x, y, z)(4)

Since the company should not be interested in the sensibledata of her employees, the third argument of the visit predi-cate is existentially quantified in rule (3). Rule (4) says thatthe predicate visit is controlled by doctors. The company ad-ditionally adopts rule (2) to deal with the predicate isDoctor.

This simple security policy cannot be faithfully im-plemented using a traditional proof-carrying authoriza-tion infrastructure. The reason is that the predicateDoctor says visit(patient , date, results) is witnessed by thesignature sign(visit(patient , date, results))skDoctor

, whichwould reveal the sensitive data results to the company. Onecould imagine that such a confidentiality problem can be eas-ily solved by encrypting results with the company’s publickey. Such a solution, however, is tailored to this specific ex-ample and does not scale to larger, open-ended, applications:the doctor does not know in general how the patient is goingto use the signature, who the possible verifiers are, and whatdata they are allowed to learn.

Contributions. In this paper, we provide a general solutionto reconcile authorization and privacy using zero-knowledgeproofs.1 In particular, we put forward the notion of privacy-aware proof-carrying authorization, an extension of PCA inwhich the issuer releases signatures to witness logical for-mulas, as in the traditional PCA framework, and the proveruses zero-knowledge proofs of knowledge of such signaturesto witness weakened variants of such formulas, in which thesensitive arguments are existentially quantified. The unique

1 A zero-knowledge proof combines two seemingly contradictory proper-ties. First, it is a proof of a statement that cannot be forged. Second, azero-knowledge proof does not reveal any information besides the bare factthat the statement is valid [16]. A non-interactive zero-knowledge proof isa zero-knowledge protocol consisting of one message sent by the prover tothe verifier. A zero-knowledge proof of knowledge additionally ensures thatthe prover knows the witnesses to the given statement.

properties of zero-knowledge proofs ensure the verifier thatthese predicates hold true, without learning the sensitive datathat the prover wishes to keep secret. Our framework offerssupport not only for the secrecy of sensitive data but also foruser anonymity.

Zero-knowledge proof schemes are known to be highlyinefficient in general. We deploy, however, a state-of-the-artnon-interactive proof system for bilinear groups developedby Groth and Sahai [17], which allows us to efficiently dealwith a rich class of logical formulas and existential quantifi-cation modalities. We conducted an experimental evaluationto demonstrate the feasibility of our approach.

Related Work. The seminal works by Abadi et al. [1, 19] onaccess control in distributed systems paved the way for thedevelopment of a number of authorization logics and lan-guages [4, 9, 13–15, 18]. In the literature, there is a clear un-derstanding that logical formulas based on a says modalitycan be implemented in a distributed setting via digital sig-natures but none of these works tackled the problem of en-suring the privacy of data employed in authorization proofs.A noticeable exception is AuraConf [22], a confidentialityextension of the Aura [18] programming language based onpublic-key encryption and a monadic constructor. In Aura-Conf, the programmer has to specify the intended recipientof each data and the compiler is in charge of encrypting suchdata with the appropriate public key. In our approach, theprogrammer does not have to know in advance all the in-tended usages and recipients of the digital signatures issuedin the protocol run. In fact, principals can use received signa-tures to construct arbitrary authorization proofs, using zero-knowledge proofs to selectively hide sensitive data.

Digital signatures and zero-knowledge proofs proved tobe salient tools to achieve fine-grained anonymity propertiesin a number of applications, such as trusted computing [12],digital credentials [10], trust protocols [5, 20], and socialnetworks [6]. None of these works, however, establishes aconnection between authorization logics and cryptographicconstructions.

Outline. The remainder of this paper is organized as follows.We give an intuitive overview of our framework in Section 2.Section 3 describes the standard PCA logic and our privacyextension. The cryptographic realization is detailed in Sec-tion 4. We present the results of our experimental evaluationin Section 5. Finally, Section 6 concludes and gives direc-tions for future work.

2. OverviewThis section introduces the logical components and the cryp-tographic schemes underlying the notion of privacy-awareproof-carrying authorization. Let us consider the examplediscussed in Section 1. The patient’s goal is to let thecompany derive the formula OkOff(patient , date). The pa-tient knows the company’s policy, which allows for deriv-ing OkOff(patient , date) given ∃z. visit(patient , date, z)

by applying rule (3). Since the only way for the companyto derive ∃z. visit(patient , date, z) is to apply rule (4),the patient has to prove the formula isDoctor(Doctor) ∧∃z. Doctor says visit(patient , date, z). Since the predicateisDoctor is controlled by the Admin , the patient has actuallyto prove the following formula:

Admin says isDoctor(Doctor) ∧∃z. Doctor says visit(patient , date, z)

(5)

The patient has two signatures at her disposal, namely,sign(isDoctor(vkDoctor ))skAdmin

by the Admin andsign(visit(patient , date, results))skDoctor by the Doctor .The former can be forwarded to the company to witness thefirst part of the conjunction in rule (5). The latter cannotbe forwarded because of the presence of the sensitiveinformation contained in results . The key insight is thatthe patient does not need to reveal results to the company,since the third argument of the visit predicate is existentiallyquantified in the company’s policy. Our idea is to let thepatient create a proof of the following statement:

∃αs, αr. ver(αs, vkDoctor , visit(patient , date, αr)) (6)

Here and throughout this paper, we use Greek letters todenote the existentially quantified witnesses of the zero-knowledge proofs, i.e., those data that make the state-ment valid and are not revealed to the verifier. This state-ment says that there exist αs (the signature) and αr(the results) such that αs is a signature on the predi-cate visit(patient , date, αr) and this signature can be suc-cessfully verified with the verification key vkDoctor of theDoctor . Since we use zero-knowledge proofs of knowl-edge, the above statement actually means that the proverknows the signature and the results. Upon reception andverification of this proof, the company can safely derivethe logical formula (5), which in turn allows for derivingOkOff(Alice, date), as previously described.

This zero-knowledge proof effectively protects the sen-sitive information contained in the signature issued by thedoctor. This is not, however, the only sensitive informationthat the patient might want to protect: for instance, shouldthe doctor be an oncologist, the patient would certainly liketo keep the doctor’s identity secret. This introduces a furthercomplication, since the patient has to keep both signaturessecret. The idea is to let the employee prove the followingformula, obtained from formula (5) by existentially quanti-fying the doctor’s identity:

∃d, z. Admin says isDoctor(d) ∧d says visit(patient , date, z)

(7)

In particular, the employee has to produce a proof of thefollowing statement:

∃αs1, αs2, αd, αr. ver(αs1, vkAdmin , isDoctor(αd))∧ver(αs2, αd, visit(patient , date, αr))

(8)

SIGNEDΓ ` digital signature(s,A, F )

Γ ` A says F

NAME-IF

A says F

NAME-IMP-EA says F A says F → G

A says G

Table 1. says modality.

where αs1, αs2 denote the two signatures, αd the doctor’sverification key, and αr the results. This proof demon-strates that there exists a doctor that visited patient ina certain date , without revealing anything else. In par-ticular, this proof preserves the anonymity of the doctor.Upon reception and verification of this proof, the companycan safely derive the formula (7), which suffices to deriveOkOff(Alice, date).

3. LogicIn this section we first give an overview of PCA [3] and laterintroduce our extension.

3.1 Proof-Carrying AuthorizationPCA builds on standard higher-order logic and exhibits as adistinctive feature a “says” modality, which is used to con-fine beliefs to specific principals. This modality is definedby the rules in Table 1. Inference rules are parameterizedby an environment Γ, which may contain the formulas com-posing the security policy as well as formulas of the formdigital signature(s,A, F ), witnessing the knowledge of asignature s on F produced by A. SIGNED establishes thebinding between signatures and logical formulas: if the envi-ronment Γ contains the predicate digital signature(s,A, F ),then Γ entails A says F . The remaining rules characterizethe fundamental properties of the says modality.

3.2 Privacy-aware extension

S := ver(us, uA, F ) | S1 ∧ S2 | ∃x. S

[S] =

uA says F if S := ver(us, uA, F )[S1] ∧ [S2] if S := S1 ∧ S2

∃x. [S′] if S := ∃x. S′

ZERO-KNOWLEDGEΓ ` ZKProof(S)

Γ ` [S]

Table 2. The zero-knowledge deduction rule.

We extend PCA by accompanying digital signatures withzero-knowledge proofs of knowledge. The latter are used toshow the knowledge of digital signatures, selectively hiding

sensitive information. For the sake of simplicity, we focuson a restricted class of zero-knowledge statements, definedby the grammar in Table 2. Here and throughout this paper,we let u range over variables and constants. A statement Smay be (i) a predicate of the form ver(us, uk, F ), meaningthat us is a signature on F that can be verified with the keyuk, (ii) the logical conjunction of two statements, or (iii) astatement preceded by an existential quantification.

The rule ZERO-KNOWLEDGE in Table 2 establishes thebinding between zero-knowledge proofs and logical formu-las: if the environment Γ contains the predicate ZKProof(S),then Γ entails [S]. The function [S] returns the logical for-mula corresponding to the zero-knowledge statement S,by simply replacing each ver(us, uA, F ) predicate withuA says F . For instance, [Se] = Fe, where Se is the zero-knowledge statement in (8) and Fe is the formula in (7).

4. Cryptographic PrimitivesWe now describe all cryptographic primitives necessary toassemble the aforementioned zero-knowledge proofs. Theusage of bilinear maps makes these primitives particularlyefficient.

Bilinear map. A bilinear map e maps elements from G1 ×G2 into the target group GT and is bilinear. More precisely,the following equation holds for all values G,H, x, and y:

e(x · G, y · H) = e(G, y · H)x = e(x · G,H)y = e(G,H)xy

Here and throughout this paper, we use the convention thatcalligraphic uppercase letters denote elliptic curve elements,while lowercase letters denote elements in a finite groupZn for some n. All cryptographically relevant bilinear mapsoperate on elliptic curves.

Digital signature scheme. We use the digital signaturescheme that was recently proposed by Abe et al. [2]. Thedistinguishing characteristic of this signature scheme is thatverification keys reside in the message space, i.e., it is pos-sible to sign verification keys without relying on auxiliaryencodings (e.g., hashing). This property is particularly im-portant to combine digital signatures with zero-knowledgeproofs, since the aforementioned encodings are hard to dealwith in zero-knowledge and make the proofs highly ineffi-cient.

The message space is the set of all Diffie-Hellman tuplesDH = {(i · G, i · H) | i ∈ Zq} where the curve elements Gand H are globally fixed generators of G1 and G2, respec-tively, and q is a globally fixed large prime. A signature keysk = s consists of a secret exponent s and a verification keyvk = (X ,Y) = (s · G, s · H). We write x ∈R S to say that xis chosen uniformly at random from the set S.

On input of a message (M,N ) = (m · G,m · H) and thepublic parameters pp = (F ,K, T ), one chooses c, r ∈R Zq

Pairing product equations:

n∏i=1

e(Ai,Yi) ·m∏i=1

e(Xi,Bi) ·m∏i=1

n∏j=1

e(Xi,Yj)γij = tT

Multi-scalar multiplication equations in G1:

n∑i=1

yiAi +

m∑i=1

biXi +

m∑i=1

n∑j=1

γijyjXi = T2

Multi-scalar multiplication equations in G2:

n∑i=1

aiYi +

m∑i=1

xiBi +

m∑i=1

n∑j=1

γijxiYj = T2

Table 3. Provable equations using the Groth-Sahai proofscheme.

and the signature is the tuple sig = (A, C,D,R,S), where

A :=1

s+ c· (K + r · T +M) C := c · F

D := c · H R := r · G S := r · H

One checks whether the following equalities hold in orderto verify the signature (A, C,D,R,S) on message (M,N )

e(A,Y +D) = e(K +M,H) · e(T ,S)

e(C,H) = e(F ,D) e(R,H) = e(G,S)

This digital signature scheme is strongly unforgeableagainst chosen-message attacks, which is the standard no-tion of security for digital signature schemes. We remarkthat this signature scheme can be extended to vectors of mes-sages with only a small constant overhead per additional el-ement. We exploit this property to sign logical formulas, byencoding logical predicates and their arguments into vectorsof messages.Example. Let us consider our running example.In order to issue Alice’s note, the Doctor en-codes the predicate visit(Alice, date, results) as~m = (visit,Alice, date, results) and embeds ~m intothe message space of the signature scheme by computing(M,N ) = (~m · G, ~m · H). The Doctor can then computethe signature according to the given rules.This signature scheme allows for very efficient zero-knowledge proofs when used in combination with the Groth-Sahai proof scheme, as described below.

Commitments. Intuitively, a commitment is the digitalequivalent of a message inside a sealed envelope that lies ontop of a table: the message creator cannot change the contentof the message and principals around the table cannot lookinside the envelope until it is opened.

Commitments are an essential building block for zero-knowledge proofs. Intuitively, a zero-knowledge proofscheme shows properties of committed values without open-ing the commitments: for instance, given three commitmentsc1, c2, c3, it is possible to prove that the multiplication of thevalues committed in c1 and c2 yields the value committed inc3. The prover can open some of the commitments to selec-tively reveal information to the verifier. In fact, the Groth-Sahai proof system, defined below, uses commitments thatbehave exactly like the committed values with respect to thegroup operations and the bilinear map (i.e., the result of anoperation on two commitments c1 and c2 is a commitmentc3 to the result of the same operation applied to the valuescommitted in c1 and c2).

Groth-Sahai zero-knowledge proof system. The Groth-Sahai zero-knowledge proof system [17] is a very flexibleand general scheme that is based on the previously describedcryptographic primitives. It captures so-called multi-scalarmultiplication equations in both G1 and G2, and pairingproduct equations.2 The equations are depicted in Table 3.Groth-Sahai proofs are proofs of knowledge, i.e., intuitively,they show that the prover is in possession of the witnessesused in the proof.

In order to create a proof for a signature (A, C,D,R,S)on (M,N ), the prover has to show that the verificationequation holds as well as all intermediate steps used to de-rive that equation. More precisely, she has to show the pair-ing product equations dictated by the signature verificationequations. In the following, we write CA to denote the com-mitment to A.

e(CA, CY)e(CA, CD) = e(CK, CH)e(CM, CH)e(CT , CS)

e(CC , CH) = e(CF , CD)

e(CR, CH) = e(CG , CS)

In order to reveal some of the committed values, the proverhas simply to forward the opening information to the verifier.

Example. Let us consider the zero-knowledge proof of thestatement (6). Alice proves the verification equation for thesignature issued by the Doctor , as described before. Finally,Alice opens the commitments to the information revealed bythe statement: in particular, she opens the commitments onthe Admin’s verification key, on the visit predicate, and onthe values patient and date .

The proof for the logical conjunction of two statementsis easily obtained by concatenating the two single proofs.If the statements of the two proofs share some values (e.g.,the statement is of the form ∃x. S1(x) ∧ S2(x)), then theprover has to use the same commitment in the two proofs. Ingeneral, all values that are proven equal within a single proofor across different proofs must use the same commitment.

2 The Groth-Sahai proofs also support quadratic equations in GT . As we donot need them in our setting, they are omitted here.

Example. To compute the zero-knowledge proof of the state-ment (8), Alice uses the same commitment on the Doctor ’sverification key in the two conjuncts. In order to reveal theinformation that is not existentially quantified in the state-ment, Alice opens all commitments except for the ones onthe two signatures, on the Doctor ’s verification key, and onthe examination results .

The resulting proofs are non-interactive zero-knowledgeproofs of knowledge. In particular, they consist only of asingle message that is sent from the prover to the verifier andthus correspond to our notion of zero-knowledge proof: anobject that can be transmitted and be verified by the verifieralone without any further interaction.

5. Experimental EvaluationWe conducted an experimental evaluation to demonstrate thepracticality of our framework. The implementation is writtenin C/C++ and uses the PBC library [21] by Ben Lynn andthe experiments were measured on a standard notebook witha 2.53 GHz dual-core processor and 4 GB of RAM. Theresults are given in Figure 1.

Discussion. As illustrated in Figure 1, the generation of aproof of a statement of the form ∃x. A says p(x) takes ap-proximately 18 seconds and the verification takes roughly 20seconds for an 80 bit security parameter. The correspondingproof size is moderate with around 85 kB. The computa-tion time and the proof size grow linearly in the size of theproven statement. Consequently, a proof for the statementfrom equation (7) takes around 54 seconds to generate, 59seconds to verify, and uses about 257 kB in size.

Our proof-of-concept implementation does not incorpo-rate any optimization. The operations required by the zero-knowledge proof scheme are mostly independent and canprofit from a multi-threaded implementation, exploiting themulti-core nature of today’s processors. Recently, Blazy etal. proposed a batch verification technique [11] that can di-minish the verification time down to a tenth. We believe thatan implementation exploiting these readily available opti-mizations has the potential to be applicable on a large scale.

6. Conclusion and Future WorkWe believe that ensuring the privacy of sensitive data is cru-cial for the widespread deployment of authorization infras-tructures. In this paper, we have started to tackle this problemby introducing the notion of privacy-aware proof-carryingauthorization, an extension of PCA in which the privacyof sensitive data is ensured by zero-knowledge proofs. Theusage of state-of-the-art cryptographic schemes makes ourframework expressive and efficient.

As a future work, we intend to enhance the expres-siveness of the underlying authorization logic by provid-ing support for arithmetic operations, trust relationships,and pseudonyms. We further plan to automate the creationof zero-knowledge proofs by developing a general-purpose

80 128 2560

20

40

60

80

Security parameter in bits

Proo

fgen

erat

ion

time

ins

80 128 2560

20

40

60

80

100

120

Security parameter in bits

Proo

fver

ifica

tion

time

ins

80 128 2560

50

100

150

200

250

Security parameter in bits

Proo

fsiz

ein

kB

Figure 1. Experimental evaluation of a zero-knowledge proof for a statement of the form ∃x. A says p(x) for various securityparameters.

compiler that produces the cryptographic evidence of the va-lidity of authorization logic formulas. We envision the usageof this compiler as a plug-in for several authorization lan-guages, such as Aura [18] and PCML5 [4]. We finally intendto apply our framework to the automated design of securityprotocols, by developing a high-level declarative languagethat allows designers to focus on the functional and securityproperties of the system, letting our compiler automaticallyprovide the cryptographic realization.

AcknowledgementThis work was partially supported by the initiative for excel-lence and the Emmy Noether program of the German federalgovernment.

References[1] M. Abadi, M. Burrows, B. Lampson, and G. Plotkin. A calcu-

lus for access control in distributed systems. ACM Trans. onProgramming Languages and Systems, 15:706–734, Septem-ber 1993.

[2] M. Abe, G. Fuchsbauer, J. Groth, K. Haralambiev, andM. Ohkubo. Structure-preserving signatures and commit-ments to group elements. In CRYPTO’10, volume 6223 ofLNCS, pages 209–236. Springer, 2010.

[3] A. W. Appel and E. W. Felten. Proof-carrying authentication.In CCS’99, pages 52–62. ACM, 1999.

[4] K. Avijit, A. Datta, and R. Harper. Distributed programmingwith distributed authorization. In TLDI’10, pages 27–38.ACM, 2010.

[5] M. Backes, S. Lorenz, M. Maffei, and K. Pecina. Anonymouswebs of trust. In PETS’10, volume 6205 of LNCS, pages 130–148. Springer, 2010.

[6] M. Backes, M. Maffei, and K. Pecina. A security API fordistributed social networks. In NDSS’11, 2011.

[7] L. Bauer, M. Schneider, E. Felten, and A. Appel. Accesscontrol on the web using proof-carrying authorization. InDISCEX’03, volume 2, pages 117–119, 2003.

[8] L. Bauer, S. Garriss, J. M. Mccune, M. K. Reiter, J. Rouse, andP. Rutenbar. Device-enabled authorization in the grey system.In ISC’05, LNCS, pages 431–445. Springer, 2005.

[9] M. Y. Becker, C. Fournet, and A. D. Gordon. Design andsemantics of a decentralized authorization language. InCSF’07), pages 3–15. IEEE, 2007.

[10] M. Belenkiy, J. Camenisch, M. Chase, M. Kohlweiss,A. Lysyanskaya, and H. Shacham. Randomizable proofs anddelegatable anonymous credentials. In CRYPTO’09, volume5677 of LNCS, pages 108–125. Springer, 2009.

[11] O. Blazy, G. Fuchsbauer, M. Izabachene, A. Jambert, H. Sib-ert, and D. Vergnaud. Batch Groth-Sahai. In ACNS’10, vol-ume 6123 of LNCS, pages 218–235. Springer, 2010.

[12] E. Brickell, J. Camenisch, and L. Chen. Direct anonymousattestation. In CCS’04, pages 132–145. ACM, 2004.

[13] A. Chaudhuri and D. Garg. PCAL: language supportfor proof-carrying authorization systems. In ESORICS’09,LNCS, pages 184–199. Springer, 2009.

[14] J. DeTreville. Binder, a logic-based security language. InS&P’02, pages 105–113. IEEE, 2002.

[15] D. Garg and F. Pfenning. A proof-carrying file system. InS&P’10, pages 349–364. IEEE, 2010.

[16] O. Goldreich, S. Micali, and A. Wigderson. Proofs that yieldnothing but their validity or all languages in NP have zero-knowledge proof systems. JACM, 38(3):690–728, 1991.

[17] J. Groth and A. Sahai. Efficient non-interactive proof systemsfor bilinear groups. In EUROCRYPT’08, volume 4965 ofLNCS, pages 415–432. Springer, 2008.

[18] L. Jia, J. A. Vaughan, K. Mazurak, J. Zhao, L. Zarko, J. Schorr,and S. Zdancewic. Aura: a programming language for au-thorization and audit. ACM SIGPLAN Notices, 43(9):27–38,2008.

[19] B. Lampson, M. Abadi, M. Burrows, and E. Wobber. Au-thentication in distributed systems: theory and practice. ACMTrans. on Computer Systems, 10:265–310, November 1992.

[20] L. Lu, J. Han, Y. Liu, L. Hu, J.-P. Huai, L. Ni, and J. Ma.Pseudo trust: Zero-knowledge authentication in anonymousp2ps. IEEE Trans. on Parallel Distributed Systems, 19(10):1325–1337, 2008. ISSN 1045-9219.

[21] B. Lynn. The pairing-based cryptography library. http:

//crypto.stanford.edu/pbc/.

[22] J. A. Vaughan. A confidentiality extension to the Aura pro-gramming language. In TLDI’11. ACM, 2011.