Perfomance Analysis of A Bidirectional Private Policy Matching Protocol Basedon Additively Homomorphic Encryption Systems

Hirofumi Yamaki

School of Information EnvironmentTokyo Denki University

Inzai, Chiba, JapanEmail: yamakih@dendai.ac.jp

Fumihiro Mori, Momoko Aoyama

Graduate School of Information ScienceNagoya University

Nagoya, Aichi, JapanEmail: {mori, aoyama}@net.itc.nagoya-u.ac.jp

Abstract—Automated Trust Negotiation (ATN) is a mecha-nism to establish mutual trust between service providers andusers in an open network environment like the Internet. Inthis paper, we propose Bidirectional Private Policy Matchingbased on Additively Homomorphic Encryption Systems(BPPM/AHES) as an ATN negotiation protocol where uni-directional private policy matching based on additively ho-momorphic encryption systems is repeated. In this protocol,there is no disclosure of credentials before the negotiationsucceeds. Because there is no unnecessary disclosure of poli-cies except for policies which can be inferred the negotiationoutcome, the amount of the unnecessary disclosure of policiesdecreases compared to existing protocols.

Keywords-trust, Automated Trust Negotiation (ATN), ad-ditively homomorphic encryption, private policy matching

I. INTRODUCTION

In an open network environment like the Internet, ser-

vice users and providers are unknown to each other. Before

using or providing services, the users will determine

whether the providers are trustworthy, and the providers

also wish to restrict their services only to trustworthy

users. In this case, it is not easy for the users and the

providers to negotiate for establishing mutual trust, be-

cause both of them want to disclose their own information

only to the trust parties. Thus, the negotiations may fail

unless they communicate successfully. Also, since the

number of services has become enormous, it is very costly

to establish mutual trust every time they encounter. To

tackle this issue, Automated Trust Negotiation (ATN) [1]

has been proposed to establish mutual trust between

strangers. ATN is a process to automatically obtain the

sequence to exchange credentials without violating dis-

closure policies that each party has. In existing ATN

protocols [1], there is some problem such as unnecessary

disclosure of credentials or that of policies before the

negotiation succeeds.

In this paper, we propose Bidirectional Private Policy

Matching based on Additively Homomorphic Encryption

Systems (BPPM/AHES) as an ATN negotiation protocol,

where private policy matching based on additively homo-

morphic encryption systems is repeated.This paper is organized as follows. In Section 2, we

explain the techniques which our proposal is based on,

such as ATN, homomorphic encryption and private pol-

icy matching. In Section 3, we explain the protocol of

BPPM/AHES, as well as an example of negotiation. In

Section 4, we describe the property of BPPM/AHES from

the view point of security and performance. Finally, we

present a conclusion in Section 5.

II. ATN USING ADDITIVELY HOMOMORPHIC

ENCRYPTION SYSTEMS

A. Automated Trust Negotiation

We consider a situation where a user is trying to use a

service, where we have two parties, a service user and a

service provider. We refer them as a client and a serverrespectively in this paper. Both of them have their own

digital credentials and policies. Credentials are digital

data that contain such information as identifiers, names,

contacts, affiliations, etc., and that are certified by trusted

third parties. Policies are rules that define the condition on

which the client and the server disclose their credentials

to the counterpart. The server also has service-governing

policies (SGP’s) which gives on what condition the client

is allowed to use the service. We use the same notation

presented in [2] to describe these policies. We denote the

service by R, credentials of the client by C1, . . . , Cnc ,

credentials of the server by S1, . . . , Sns , where nc and

ns are the numbers of credentials possessed by the client

and the server respectively. The policy for disclosing the

client’s credential C is denoted by C ← FC(S1, . . . , Sns),where FC(S1, . . . , Sns) is a Boolean expression with

the server’s credentials S1, . . . , Sns . Similarly, SGP is

denoted by R ← FS(C1, . . . , Cnc). The policy for dis-

closing the server’s credential S is denoted by S ←FS(C1, . . . , Cnc), where FS(C1, . . . , Cnc) is a Boolean

expression with the client’s credentials C1, . . . , Cnc . The

policy of credential C will be satisfied, if the logi-

cal expression FC(S1, . . . , Sns) evaluates to true, after

substituting propositional symbols of already disclosed

credentials by the other party with true in the logical

expression FC(S1, . . . , Sns). If the policy of credential Cis satisfied, it can be disclosed to the other party. Table I

is an example of policies.

If credential C can be disclosed without any credentials

from the other party, such a policy is denoted by C ←true, and C is called an unprotected credential. On the

other hand, if credential C cannot be disclosed under any

circumstances, such a policy is denoted by C ← false.

If SGP is satisfied as the result of negotiation, the service

becomes available to the client.

2013 International Conference on Signal-Image Technology & Internet-Based Systems

978-1-4799-3211-5/13 $31.00 © 2013 IEEE

DOI 10.1109/SITIS.2013.111

679

Table IEXAMPLE OF POLICIES

client’s policies server’s policiesC1 ← true R← (C3 ∧ C4) ∨ C6

C2 ← true S1 ← trueC3 ← S1 ∧ S2 S2 ← (C1 ∧ C2) ∨ C3

C4 ← S3 ∨ S4 S3 ← C3 ∨ C4

C5 ← S2 ∨ S3 S4 ← C4

C6 ← false S5 ← C1 ∧ C5

The aim to perform ATN is to automatically obtain

the sequence to exchange credentials without violating

the policies in order to establish mutual trust between the

client and the server. Various protocols and strategies have

been proposed to achieve this [3], [1], [4], [2]. Below, we

briefly describe two basic strategies presented in [1], i.e.,

Eager Strategy and Parsimonious Strategy.

1) Eager Strategy: In Eager Strategy [1], the client and

the server in turns exchange all the currently unlocked cre-

dentials. As credentials are exchanged in the negotiation,

more credentials become unlocked. The negotiation suc-

ceeds when SGP is satisfied by the credentials disclosed

by the client, and fails when the client terminates the

negotiation because either of the negotiating parties has

no credential to newly disclose.

The negotiation process of Eager Strategy is very sim-

ple, and none of the server’s and the client’s policies

is directly disclosed. The weakness of Eager Strategy

is in that credentials are disclosed regardless of their

contribution to the success of the negotiation, i.e., some of

them may be unnecessarily disclosed. They are disclosed

even if the negotiation fails.

2) Parsimonious Strategy: Eager Strategy is an ap-

proach to disclose all the credentials that can be disclosed,

and no party sends requests for credentials to the other.

In contrast, in Parsimonious Strategy [1], each party first

repeats sending requests for credentials to the counterpart,

and discloses their credentials only after finding the se-

quence to exchange them for satisfying SGP. There is no

disclosure of unnecessary credentials, but the existence

of some policies that are not related to the sequence to

exchange credential may be known to the counterpart.

Most of protocols in the studies of ATN are extensions

of Parsimonious Strategy, and suffers from the same

weakness.

B. Private Policy Matching

Our goal is to create a new protocol that discloses

neither credentials nor policies that do not contribute to

the successful trust negotiation. In this section, we explain

private policy matching [5] which is used in the process

of BPPM/AHES.

1) The ElGamal Cryptosystem: The private policy

matching method is based on the ElGamal Cryptosys-

tem [6]. To describe its properties, we first define addi-

tively homomorphic encryption.

Definition 1 (Additively Homomorphic): Given an en-

cryption function E, a public key p with corresponding

secret key s, and a message m, we denote the encryption

of m with the public key p by Ep(m). An encryption func-

tion E is called additively homomorphic if the following

formula is satisfied for all message m1 and m2.

Ep(m1)Ep(m2) = Ep(m1 +m2)

Additively homomorphic encryption has the following

properties.

E(m)c = E(cm)

E(m)E(0) = E(m)

The ElGamal cryptosystem is a public key encryption

which depends on the difficulty of discrete logarithm

problem (LDP). Its definition is given as follows.

Definition 2 (ElGamal Cryptosystem): Let G = 〈g〉denote a finite cyclic (multiplicative) group of prime order

q. The public key of ElGamal cryptosystem is an element

h ∈ G and the encryption of a message m ∈ Zq is given

by the pair (a, b) = (gr, hrgm) where r ∈r Zq . The

secret key s is given by s = logg h. Given the private

key s, decryption of the ciphertext (a, b) = (gr, gmhr)is performed by first calculating b/as = gm, and then

solving for m ∈ Zq .

When the encryption of two messages m1, m2 ∈ Zq are

given by the pairs (gr1 , hr1gm1), (gr2 , hr2gm2), the mul-

tiplication of two ciphertexts is (gr1+r2 , hr1+r2gm1+m2).The ElGamal cryptosystem is additively homomorphic,

since

(gr1+r2 , hr1+r2gm1+m2) is the encryption of a message

m1 +m2 ∈ Zq .

2) Private Policy Matching Based on the ElGamalCryptosystem: Kursawe et al. [5] proposed private policy

matching based on the ElGamal cryptosystem. It is a

process to find out whether a match exists between the

credentials that a client can disclose and those requested

by a server. Below, we define the preference of a client as

the credentials that the client may disclose in order to get

access to certain service, and the preference of a server

are defined as the credentials that the server requests from

a client before granting access to the service. A set of

credentials is called a matching policy if it satisfies both

preferences. The formal definitions are given as follows.

Definition 3: Let C be a set of credentials and let Sbe a totally ordered set of scores with least element 0. In

this paper, we limit to the case S = {0, 1} for simplicity.

Preferences over the set of credentials C are described by

functions that assign to each set of credentials C ⊆ Ca score s ∈ S . The client’s preferences are defined as a

function f : 2C → S.

f(C) =

{1 if the client may disclose C0 otherwise

The server’s preferences are described as a function g :2C → S .

g(C) =

{1 if the server requests C0 otherwise

680

A matching function M : 2C × S × S → S assigns a

matching score to a set C ⊆ C based on C as follows.

M(C, f(C), g(C)) =

{1 f(C) = g(C) = 10 otherwise

In private policy matching, both of the parties know

whether matching policies exist and what they are, but

they cannot acquire any additional knowledge about the

preference of the counterpart.

The client’s preference function f is a monotonically

decreasing Boolean function, which means that, if f(A) =1 and B ⊆ A, then f(B) = 1. Likewise, the server’s

preference function g is usually monotonically increasing

Boolean function, which means that, if g(A) = 1 and

B ⊇ A, then g(B) = 1. Based on these facts, we define

generating subsets as follows.

Definition 4 (Generating Subsets): Let h : 2C →{0, 1} be a monotonically increasing Boolean function. We

say that H = {H1, . . . , Ha} ⊆ 2C is a set of generating

subsets for h iff for all C ⊆ Ch(C) = 1 ⇐⇒ ∃ i ∈ {1, . . . , a} : Hi ⊆ C

Since f is a monotonically decreasing function, ¬fis a monotonically increasing function that is described

through its set of generating subsets F = {F1, . . . , Fa}.Essentially, the sets F1, . . . , Fa are the minimal sets of

credentials that the client does not want to disclose to-

gether. Similarly, the function g is described through its

set of generating subsets G = {G1, . . . , Gb}, where the

sets G1, . . . , Gb are the minimal sets of credentials that

the server request from the client before granting access

to the service.

By using the notation of generating subsets, finding a

match is equivalent to finding a set of credentials C ⊆ C,

such that

• ∀Fi ∈ F : Fi � C, and

• ∃Gj ∈ G : Gj ⊆ C.

If a match exists, the matching policy is one of the server’s

generating subsets. Thus, the condition for the matching

policy C is represented more compactly as follows.

Gj ∈ G s.t. ∀Fi ∈ F : Fi � Gj (1)

Private policy matching which finds a matching policy

that satisfies in the formula (1) is performed as follows.

1) The client and the server share a distributed private

key by previously running a distributed key genera-

tion protocol [7]. They encrypt the strings describing

their generating subsets bit-by-bit under the same

public key.

2) They calculate a matching policy that satisfies the

formula (1) using the additively homomorphic prop-

erties of the cryptosystem.

3) Finally, they decrypt the two values obtained as the

output of the calculations, i.e., a matching policy

M and a bit e indicating whether a matching policy

exists (e = 1) or not (e = 0), with a threshold

decryption protocol [8].

Table IIEXAMPLE OF THE CLIENT’S NEGOTIATION TABLE

client’s policy DF MP

C1 ← true 0 trueC2 ← true 0 trueC3 ← S1 ∧ S2 0C4 ← S3 ∨ S4 0C5 ← S2 ∨ S3 0C6 ← false 0

Table IIIEXAMPLE OF THE SERVER’S NEGOTIATION TABLE

server’s policy DF MP

R ← (C3 ∧ C4) ∨ C6

S1 ← true 0 trueS2 ← (C1 ∧ C2) ∨ C3 0S3 ← C3 ∨ C4 0S4 ← C4 0S5 ← C1 ∧ C5 0

After this, they know whether a matching policy exists,

and what the matching policy is.

This protocol enables us to derive a minimal set of

credentials for the client to disclose, when only the server

has policies and the client’s credentials are unprotected.

In the following section, we extend this to be applied in

such bidirectional scenarious as in ATN, where both of

the server and the client have policies.

III. BIDIRECTIONAL PRIVATE POLICY

MATCHING

Our new protocol is derived by repeating private policy

matching described in the previous section. Below, we call

the original private policy matching as the server-sidepolicy matching, where the server’s policies are tested

against the client’s credentials. On the other hand, we call

the opposite where the client’s policies are examined as

the client-side policy matching. By repeating the server-

side and the client-side policy matchings alternately, the

information exchange needed in ATN is achieved. We call

our new protocol as Bidirectional Private Policy Matching

based on Additively Homomorphic Encryption Systems

(BPPM/AHES).

A. Negotiation Tables

This protocol takes the policies of the client and the

server as its input, and outputs the sequence to exchange

credentials. The process fails when no sequence is feasible.

Both the client and the server maintain negotiation tablesas exemplified in Tables II and III. These tables are

updated through the negotiation process.

A negotiation table has three columns, Policy, DF

and MP. DF and MP stand for disclosing flag (DF)

and matching policy (MP) respectively. A value in DF

means whether the credential is disclosed (DF= 1) or

not (DF= 0) in the negotiation process. The values in

DF are initialized to 0, which means that all credentials

are not disclosed before the negotiation. MP is for storing

encrypted matching policies found in the negotiation. For a

681

Figure 1. Policy Negotiation

policy the right-hand side of which is true, its MP column

is initialized to “unprotected.”

B. Protocol

The BPPM/AHES protocol consists of two stages,

policy negotiation and credential exchange. Below, we

explain each of them.

1) Policy Negotiation: In policy negotiation, the client

and the server repeat the server-side and the client-side

policy matchings alternately until they know that there is

a sequence to exchange credentials which satisfies SGP

or until the negotiation fails. If there is such a sequence,

they move to credential exchange. If there is not, the

negotiation process is terminated. The flowchart of policy

negotiation is depicted in Figure 1.

(1) First, the client requests a service to the server.

(2) The server which received a service request

sends a message that indicates the start of the

server-side policy matching.

(3) In the server-side policy matching, the client

and the server determine if there is any server’s

policy which gets satisfied by credentials which

can be disclosed by the client. Before the server-

side policy matching, if the value in DF of the

credential that can be disclosed at that time by

the client is 0, it is set to 1. The server-side

policy matching is performed as described in

Section II-B2. The server-side policy matchings

are performed in parallel for each of the server’s

policies. If a matching policy exists, the server

sets the policy of the credential to true, and

writes the matching policy in the column of MP

of the credential.

(4) After the server-side policy matching, the server

determines if SGP is satisfied. This is equivalent

to determining if there is a sequence to exchange

credentials which satisfies SGP.

(5) If SGP is satisfied, which means that the nego-

tiation succeeds, the negotiating party move to

credential exchange described in the next section.

(6) If SGP is not satisfied, the server determines if

there is any unprotected credential whose DF is

0. This is equivalent to determining if there is

any credential which can be disclosed newly.

(7) If there is a credential which can be disclosed

newly, the server sends a message that indicates

the start of the client-side policy matching to the

client.

(8) If there is no credential which can be disclosed

newly, the server sends a message that indicates

the end of the negotiation to the client. The

negotiation fails and is terminated.

(9) In the client-side policy matching, the client and

the server determine if there is any client’s policy

which gets satisfied by credentials which can

be disclosed by the server. Before the client-

side policy matching, if the value in DF of the

credential that can be disclosed at that time by

the server is 0, it is set to 1. The client-side

policy matching is performed as described in

Section II-B2. The client-side policy matchings

are performed in parallel for each of the client’s

policies. If a matching policy exists, the client

sets the policy of the credential to true, and

writes the matching policy in the column of MP

of the credential.

(10) After the client-side policy matching, the client

determines if there is any unprotected credential

whose DF is 0. This is equivalent to determining

if there is any credential which can be disclosed

newly.

(11) If there is a credential which can be disclosed

newly, the client sends a message that indicates

the start of the server-side policy matching to the

server.

(12) If there is no credential which can be disclosed

newly, the client sends a message that indicates

the end of the negotiation to the server. The

negotiation fails and is terminated.

2) Credential Exchange: After policy negotiation, the

client and the server first find the sequence to exchange

credentials and then exchange credentials according to it.

The flowchart of credential exchange is given in Figure 2.

(1) The server generates a request for credentials

which must be disclosed by the client, for the

server to satisfy the client’s request for the

server’s credentials or service. A request for cre-

dentials is generated by matching policies stored

in the columns of MP in the negotiation table.

The matching policies are decrypted by the client

and the server if needed to generate a request

for credentials. First of credential exchange, the

client and the server decrypt the column of MP of

the service R together, and the server generates

a request for credentials.

682

Figure 2. Credential Exchange

(2) The server sends it to the client.

(3) The client determines whether the request from

the server is satisfied by the client’s unprotected

credentials.

(4) If the request from the server is satisfied by the

client’s unprotected credentials, move to (11).

(5) If the request from the server is not satisfied by

the client’s unprotected credentials, move to (6).

(6) The client generates a request for credentials

which must be disclosed by the server, for the

client to satisfy the server’s request for the

client’s credentials.

(7) The client sends it to the server.

(8) The server determines whether the request from

the client is satisfied by the server’s unprotected

credentials.

(9) If the request from the client is satisfied by the

server’s unprotected credentials, move to (11).

(10) If the request from the client is not satisfied by

the server’s unprotected credentials, move to (1).

(11) The client and the server find the sequence

to exchange credentials by reversing previous

requests for credentials and exchange credentials

according to it.

(12) When SGP is satisfied by the credentials which is

disclosed last, the negotiation finishes in success.

C. Example of the Negotiation

In this section, we explain an example of negotiation in

BPPM/AHES by showing the changes of the negotiation

tables using the policies given in Table I. The negotiation

tables of the client and the server after the first server-side

and client-side policy matchings are shown in Table IV

and V.

At the first server-side policy matching, since the client

can disclose the credentials C1 and C2, the values in DF of

credentials C1 and C2 in Table IV are set to 1. When the

Table IVTHE NEGOTIATION TABLE OF THE CLIENT AFTER THE FIRST

SERVER-SIDE AND CLIENT-SIDE POLICY MATCHINGS

client’s policy DF MP

C1 ← true 1 trueC2 ← true 1 trueC3 ← S1 ∧ S2 true 0 EC3

C4 ← S3 ∨ S4 0C5 ← S2 ∨ S3 true 0 EC5

C6 ← false 0

Table VTHE NEGOTIATION TABLE OF THE SERVER AFTER THE FIRST

SERVER-SIDE AND CLIENT-SIDE POLICY MATCHINGS

server’s policy DF MP

R ← (C3 ∧ C4) ∨ C6

S1 ← true 1 trueS2 ← (C1 ∧ C2) ∨ C3 true 1 ES2

S3 ← C3 ∨ C4 0S4 ← C4 0S5 ← C1 ∧ C5 0

first server-side policy matching is performed, the server

knows that there is a matching policy that satisfied the

policy of server’s credential S2. The server sets the policy

of the credential S2 to true, and writes a matching policy

ES2 in the column of MP of the credential S2. After the

first server-side policy matching, the server determines if

SGP is satisfied and if there is any unprotected credential

whose value in DF is 0. Since SGP is not satisfied, and

there are credentials S1 and S2 as such values, the server

sends a message that indicates the start of the first client-

side policy matching to the client. After receiving it, the

client starts the first client-side policy matching with the

server.

At the first client-side policy matching, since the server

can disclose the credentials S1 and S2, the values in DF of

credentials S1 and S2 in Table V are set to 1. When the

first client-side policy matching is performed, the client

know that there are matching policies that satisfied the

policy of client’s credentials C3 and C5 respectively. The

client sets the policies of the credentials C3 and C5 to

true, and writes matching policies EC3and EC5

in the

columns of MP of the credentials C3 and C5 respectively.

After the first client-side policy matching, the client deter-

mines if there is any unprotected credential whose value

in DF is 0. Since there are credentials C3 and C5 as such

values, the client sends a message that indicates the start of

the second server-side policy matching to the server. After

receiving it, the server starts the second server-side policy

matching with the client. Similarly, the second server-side

and client-side policy matchings is performed.

The negotiation tables of the client and the server after

the third server-side policy matching are given in Table VI

and VII.

At the third server-side policy matching, since the client

can disclose the credential C4, the value in DF of the

credential C4 in Table VI is set to 1. When the third

server-side policy matching is performed, the server know

683

Table VITHE NEGOTIATION TABLE OF THE CLIENT AFTER THIRD

SERVER-SIDE POLICY MATCHING

client’s policy DF MP

C1 ← true 1 trueC2 ← true 1 trueC3 ← S1 ∧ S2 true 1 EC3

C4 ← S3 ∨ S4 true 1 EC4

C5 ← S2 ∨ S3 true 1 EC5

C6 ← false 0

Table VIITHE NEGOTIATION TABLE OF THE SERVER AFTER THIRD

SERVER-SIDE POLICY MATCHING

server’s policy DF MP

R ← (C3 ∧ C4) ∨ C6 true ER

S1 ← true 1 trueS2 ← (C1 ∧ C2) ∨ C3 true 1 ES2

S3 ← C3 ∨ C4 true 1 ES3

S4 ← C4 true 0 ES4

S5 ← C1 ∧ C5 true 1 ES5

that there are matching policies that satisfied SGP and the

policy of server’s credential S4 respectively. The server

sets SGP and the policies of the credential S4 to true,

and writes matching policies ER and ES2 in the columns

of MP of the service R and the credential S4 respectively.

After the third server-side policy matching, the server

determines if SGP is satisfied. Since SGP is satisfied in

this case, they move to credential exchange.

In credential exchange, the server first decrypts ER

cooperating with the client, and obtains ER = {C3, C4}.After that, the server generates a request for credentials

C3 ∧ C4, and sends it to the client. Since the request

from the server is not satisfied by the client’s unprotected

credentials, the client decrypts EC3 and EC4 cooperating

with the server, and obtains EC3 = {S1, S2} and EC4 ={S3} respectively. Then, the client generates a request for

credentials S1 ∧ S2 ∧ S3, and sends it to the server. Since

the request from the client is not satisfied by the server’s

unprotected credentials, the server decrypts ES2 and ES3

cooperating with the client, and obtains ES2 = {C1, C2}and ES3 = {C3} respectively. Then, the server generates

a request for credentials C1 ∧C2 ∧C3, and sends it to the

client. Since the request from the server is not satisfied by

the client’s unprotected credentials, the client generates

a request for credentials S1 ∧ S2, and sends it to the

server. Since the request from the client is not satisfied by

the server’s unprotected credentials, the server generates a

request for credentials C1 ∧C2, and sends it to the client.

The client terminates a request for credentials because the

server’s request for credentials C1 ∧C2 is satisfied by the

client’s unprotected credentials. The client and the server

find the sequence to exchange credentials C1, C2 → S1,

S2 → C1, C2, C3 → S1, S2, S3 → C3, C4 → R by

reversing previous requests for credentials and exchange

credentials according to it. When SGP is satisfied by the

exchanged credentials, the negotiation finishes in success.

Table VIIICOMPARISON OF ATN PROTOCOLS

���������ProtocolCriteria Disclose Disclose

Credentials Policies

Eager Strategy Yes NoParsimonious Strategy No YesBPPM/AHES No No

IV. DISCUSSIONS

In this section, we describe the property of

BPPM/AHES from the view point of security and

performance.

A. Unnecessary Disclosure of Policies

First, we discuss about unnecessary disclosure of poli-

cies in BPPM/AHES. In policy negotiation, there is no

unnecessary disclosure of policies before the negotiation

succeeds, because the computation is performed by using

additively homomorphic properties of the cryptosystem,

and because the matching policies are not decrypted in

policy negotiation.

In credential exchange, there is no unnecessary dis-

closure of policies except for policies which can be

inferred from the sequence to exchange credentials. When

BPPM/AHES is performed over the policies of the client

and the server shown in Table I, the sequence to exchange

credentials is :C1, C2 → S1, S2 → C1, C2, C3 → S1,

S2, S3 → C3, C4 → R. In this example, such policies as

R← C3∧C4, C1 ← true and C2 ← true can be inferred.

These policies are disclosed, in contract, policies about

such credentials as S4 and C5, which are not exchanged

cannot be known.

In Table VIII, we compare three ATN protocols in terms

of the disclosure of credentials and policies before the

negotiation succeeds.

In Eager Strategy, since the client and the server ne-

gotiate by directly disclosing credentials, credentials are

disclosed no matter whether the negotiation succeeds, but

there is no unnecessary disclosure of policies. Since Parsi-

monious Strategy is a strategy where each party discloses

credentials only after finding the sequence to exchange

credentials for satisfying SGP, there is no disclosure of

credentials. But, the existence of some policies about

credentials that are not exchanged may be known to the

counterpart. As we have explained, there is no disclosure

of credentials and policies in BPPM/AHES before the

negotiation succeeds.

BPPM/AHES and Parsimonious Strategy have very

similar procedure for finding the sequence to exchange

credentials, but only the condition used to generate a re-

quest for credentials is different. In Parsimonious Strategy,

we use the policy of credential to generate the request for

credentials. On the other hand, we use a matching policy

(MP) registered in the negotiation table in BPPM/AHES.

The matching policy is a sufficient condition of the policy,

and, by using it, the client and the server can find the

sequence to exchange credentials which turns out that the

negotiation succeeds in the last of policy negotiation. In

684

Parsimonious Strategy, if the policies include OR (∨), un-

necessary disclosure of policies may occur in the process

of the request for credentials, and thus more policies may

be known than in BPPM/AHES. Otherwise, BPPM/AHES

and Parsimonious Strategy give the same security in terms

of inferred policies.

B. Communication and Memory Complexity ofBPPM/AHES

Below, we analyze the performance of BPPM/AHES

in terms of its communication cost and memory con-

sumption. We denote the maximum number of generating

subsets in the client’s policies by mc, and that in the

server’s policies by ms. The communication complexity

is given by the following theorem.

Theorem 1: Communication complexity of

BPPM/AHES is O(min(nc, ns)(mc+ms+log2(msnc)+log2(mcns))).

Proof: As described in [5], communication complex-

ity of server-side policy matching is O(ms+log2(msnc)),and communication complexity of client-side policy

matching is

O(mc + log2(mcns)). The number of server-side policy

matchings in BPPM/AHES is at most min(nc, ns) +1, and the number of client-side policy matchings

in BPPM/AHES is at most min(nc, ns). Two mes-

sages is required to decrypt a bit e indicating whether

a matching policy exists in each policy matching.

Thus, communication complexity of policy negotiation

is (ms + log2(msnc)) × (min(nc, ns) + 1) + (mc +log2(mcns))×min(nc, ns) + 2× (2min(nc, ns) + 1) =O(min(nc, ns)(ms + log2(msnc) +mc + log2(mcns))).In credential exchange, the number of messages for

decryption is 4min(nc, ns) + 2, and the number of

messages to exchange credentials is 2min(nc, ns) + 1.

Therefore, communication complexity of BPPM/AHES is

O(min(nc, ns)(mc +ms + log2(msnc) + log2(mcns))).

And, memory complexity is given as follows.

Theorem 2: Client side memory complexity of

BPPM/AHES is O(n2c + n2

s + ncns(mc + ms)).Server side memory complexity of BPPM/AHES is

O(n2c + n2

s + ncns(mc +ms)).Proof: Consider the client side first. As described

in [9], the memory complexity of adjacency-list represen-

tation of client’s policies is O(mc(nc + ns)). Memory

complexity of storing disclosing flags and matching poli-

cies in client’s negotiation table is O(nc) and O(ncns)respectively. The client has to store all sets of generating

subsets for computations. In the server-side policy match-

ing, the size of sets of generating subsets which the client

generates is at most n2c . That of the server generates is at

most ncnsms. In the client-side policy matching, the size

of sets of generating subsets which the client generates

is at most ncnsmc. That of the server generates is at

most n2s. Thus, the total size of the sets of generating

subsets is at most n2c + ncnsms + ncnsmc + n2

s =O(n2

c + n2s + ncns(mc + ms)). In credential exchange,

the client has to store the credentials which disclosed by

the server. Memory need to store them is bounded by

the number of credentials ns. Thus, the total memory

consumption is (mc(nc+cs))+nc+ncns+(n2c+ncnsms+

ncnsmc + n2s) + n2. Therefore, memory complexity of

BPPM/AHES at the client side is O(n2c+n2

s+ncns(mc+ms)). Similarly, memory complexity at the server side is

O(n2c + n2

s + ncns(mc +ms)).

V. CONCLUSION

In this paper, we proposed BPPM/AHES as an ATN

negotiation protocol. We extended private policy matching

proposed in a preceding work, and defined the server-

side policy matching and the client-side policy matching.

In each policy matching, computation is performed using

additively homomorphic properties of the cryptosystem.

The negotiation process proceeds by repeating the server-

side and the client-side policy matchings alternately, until

the sequence to exchange credentials without violating

policies is found. In this protocol, there is no disclosure

of credentials and policies before the negotiation suc-

ceeds. Also, because there is no unnecessary disclosure

of policies except for policies which can be inferred from

the sequence to exchange credentials, the amount of the

unnecessary disclosure of policies in BPPM/AHES is less

than or equal to that in Parsimonious Strategy.

Though this method achieved minimal direct disclosure

of credentials and policies, it is still possible to infer poli-

cies from obtained exchange sequences. This is inevitable

in such approaches as those based on Parsimonious Strat-

egy and BPPM/AHES, where credentials are exchanged

according to the minimal sequence obtained in former

processes. To cope with this, it is important to device a

new technique, where neither of the negotiating parties

does not know the sequence of credential disclosure by,

for example, encrypting the whole process.

REFERENCES

[1] W. Winsborough, K. Seamons, and V. Jones, “Automatedtrust negotiation,” in DARPA Information SurvivabilityConference and Exposition, vol. 1, 2000, pp. 88–102.

[2] T. Yu, X. Ma, and M. Winslett, “PRUNES: an efficient andcomplete strategy for automated trust negotiation over theInternet,” in Proceedings of the 7th ACM conference onComputer and communications security. ACM, 2000, pp.210–219.

[3] K. Nakatsuka and T. Ishida, “Distributed AND/OR Searchfor Automated Trust Negotiation,” Transactions, vol. 47,no. 8, pp. 2454–2463, 2006.

[4] H. Yamaki, M. Fujii, K. Nakatsuka, and T. Ishida, “Adynamic programming approach to automated trust nego-tiation for multiagent systems,” in Rational, Robust, andSecure Negotiation Mechanisms in Multi-Agent Systems,2005. IEEE, 2006, pp. 55–65.

[5] K. Kursawe, G. Neven, and P. Tuyls, “Private policy negoti-ation,” LECTURE NOTES IN COMPUTER SCIENCE, vol.4107, p. 81, 2006.

685

[6] T. ElGamal, “A public key cryptosystem and a signaturescheme based on discrete logarithms,” IEEE transactions oninformation theory, vol. 31, no. 4, pp. 469–472, 1985.

[7] R. Gennaro, S. Jarecki, H. Krawczyk, and T. Rabin, “Securedistributed key generation for discrete-log based cryptosys-tems,” Journal of Cryptology, vol. 20, no. 1, pp. 51–83, 2007.

[8] Y. Desmedt and Y. Frankel, “Threshold cryptosystems,”Lecture Notes in Computer Science, pp. 3–3, 1993.

[9] I. Katugampala, H. Yamaki, and Y. Yamaguchi, “MemoryComplexity of Automated Trust Negotiation Strategies,”Principles of Practice in Multi-Agent Systems, pp. 229–244,2009.

686