Security enhanced accountable anonymous PKI certificates for mobile e-commerce

Computer Networks 45 (2004) 483–503

www.elsevier.com/locate/comnet

Security enhanced accountable anonymous PKI certificatesfor mobile e-commerce

D. Critchlow *,1, N. Zhang

Department of Computer Science, University of Manchester, Oxford Road, Manchester, Lancastershire M13 9PL, UK

Received 23 May 2003; received in revised form 23 November 2003; accepted 5 February 2004

Available online 10 April 2004

Responsible Editor: G. Schaefer

Abstract

This paper presents enhancements to an anonymous public-key certificate scheme originally intended for anonymous

and fair document exchange. The appropriate use of these certificates may enable a party with access to a mobile phone

and/or laptop computer to conduct multiple mobile e-commerce transactions anonymously yet accountably and

thereby reduce the risk of developing a pseudonymous on-line profile. We propose modifications to the existing scheme

to solve a recognised security flaw. The proof of rightful ownership of the anonymous/real public-key certificate pre-

sented to obtain a (further) anonymous public-key certificate is presently achieved with a single piece of evidence, i.e.

the private key associated with the presented certificate. Should an adversary compromise this key, then the adversary

may obtain anonymous certificates in the rightful owner’s name. Our proposal minimises the risk of an adversary

obtaining anonymous certificates with a compromised private key.

� 2004 Elsevier B.V. All rights reserved.

Keywords: Anonymity; E-commerce; Internet; Privacy; Security

1. Introduction

E-commerce, and in particular on-line shop-

ping, has become an accessible alternative to the

High Street. Some of the reasons for the growth ofon-line shopping are the availability of affordable

home computers and Internet access coupled with

the promoted benefits of discounted goods/services

* Corresponding author. Tel.: +44-161-2756270.

E-mail addresses: [email protected] (D. Critchlow),

[email protected] (N. Zhang).1 The author is a holder of a Departmental Scholarship and

IEE Vodafone Scholarship.

1389-1286/$ - see front matter � 2004 Elsevier B.V. All rights reserv

doi:10.1016/j.comnet.2004.02.010

and the convenience of shopping from home. As

this form of commerce has become more prolific,

so have the associated security problems, the most

notable, via media coverage, being the lack of

security of financial transactions and the loss ofprivacy. Much has been done to minimise the risks

associated with on-line financial transactions with

the application of encrypted links between the

consumer (client) and vendor (server). Many on-

line vendors offer assurances as to the security of

their Internet credit card transaction systems and

offer consumers who are still wary the alternative

of giving their card details over the phone. As aconsequence, consumers are now afforded the

ed.

mail to: [email protected]

484 D. Critchlow, N. Zhang / Computer Networks 45 (2004) 483–503

same sense of security for on-line shopping as they

are for shopping with their credit card on the High

Street. However, whereas the High Street allows

consumers to browse and purchase goods with

anonymity, it is a requirement of on-line shopping

that consumers identify themselves by name andoften home address. Transmitting this sensitive

information over an unregulated network may

leave the consumers’ privacy vulnerable to attacks.

To illustrate these potential threats to privacy

we refer to a simplified mobile e-commerce infra-

structure shown in Fig. 1 that serves as an illus-

tration. There are several notable parties in our

mobile e-commerce model.The User (or consumer), who has access to a

mobile phone (and/or laptop computer), may

connect to the Internet via the Mobile Phone

Network (MPN) and an Internet Service Provider

(ISP). The User may then contact a multiplicity of

Certification Authorities (CAs), numerous vendors

and the User’s bank (providing e-banking facili-

ties). There is also an Adversary (or Attacker),whom we describe as an unauthorised party able to

observe MPN and Internet traffic. Each of these

entities may launch attacks against the User, which

represents a threat to the User’s privacy. In order

for us to understand the type of threats posed by

User

Mobile PhonNetwork

Certificate Authority

CertificaAuthori

Attacker

In

Fig. 1. Mobile e-comme

each entity, we first discuss how information on

wired and wireless networks is vulnerable to at-

tacks and the countermeasures currently applied.

There are three basic attributes of information

that must be protected in order to safeguard Users’

privacy: Confidentiality, Accuracy and Availabil-ity [1]. Each of these attributes is vulnerable to a

particular type of loss:

• Disclosure is the loss of Confidentiality. It indi-

cates that an information source has the poten-

tial to release information to unauthorised

parties. The loss of confidentiality is usually

recognised as the biggest potential risk to pri-vacy.

• Destruction/Corruption is the loss of Accuracy

or Integrity. It indicates that unauthorised

changes have been made to information. Such

changes may be the result of a human error, a

malicious attack, or the underlying system/net-

work unreliability. The loss of integrity is less

often associated with the loss of privacy; it is,nevertheless, a form of intrusion.

• Denial of Service is the loss of Availability. It

is the most visible of the losses. Availability is

considered the most important attribute in ser-

vice-oriented businesses. The loss of availability

Internet

e

te ty

ternet Service Provider

Vendor

E -Bank

rce infrastructure.

D. Critchlow, N. Zhang / Computer Networks 45 (2004) 483–503 485

as a threat to privacy may not be immediately

apparent. Denial of rightful access to informa-

tion and services may be viewed as a form of

intrusion. Furthermore, the loss of a service

that ensures privacy through the protection ofeither confidentiality and/or integrity may then

result directly in the loss of privacy.

Each of these losses may result from particulartypes of attacks. The ETSi technical specification

on UMTS security threats [2] may be referred to

for a detailed list of threats applicable to both

wired and wireless networks. There are five basic

security services already in use designed to secure

private communications. These are Confidential-

ity, Integrity Checking, Authentication, Non-

repudiation and Accountability. We brieflydescribe each in turn:

• Confidentiality provides privacy for messages

and stored data by making the information

non-readable to observers. This is usuallyachieved through the application of symmetric

(or secret) key encryption.

• Integrity checking provides assurance that any

unauthorised alteration of a message can be de-

tected.

• Authentication provides assurance that a party

is indeed who it claims to be.

• Non-repudiation provides protection from asender or receiver of a message falsely denying

that a message was sent or received.

• Accountability provides evidence of an entity’s

actions via an audit trail.

At present, the security services implemented on

the MPN enable secure mobile communications by

providing message, signalling and subscription data

confidentiality, location confidentiality and

authentication [3]. The security services available on

the Internet enable secure private communications

to varying degrees depending on the type ofschemes applied. User privacy encompasses the

confidentiality of a User’s identity and location

(address) as well as the messages sent and received

by the User. It has become common practice for

Users to have a pseudonym for on-line use rather

then their real-world identity, which provides the

User with some identity privacy. A pseudonym

combined with a global style e-mail address, e.g.

hotmail.com, which contains no geographical

information, provides further privacy in that the

User’s on-line identity and location are not easily

linked to their real-world identity and location.However, all on-line connections have an IP ad-

dress, which may be used to identify an individual

machine and its location. A User accessing the In-

ternet via an ISP is assigned a temporary IP address

by the ISP. The ISP has a pool of temporary IP

addresses that belong to the organisation. It assigns

the first available IP address to a User as she logs on

and returns the IP address to the pool when theUser logs off. This system provides the User with

some location privacy since the IP address seen on-

line belongs to the ISP. Message confidentiality is

achieved through the application of encryption.

There are other security benefits associated with

the use of encryption. Symmetric (or secret-

key) encryption provides message confidentiality,

authentication and integrity. Asymmetric (or pub-lic-key) encryption enables entity authentication,

sender non-repudiation and symmetric key agree-

ment or transportation. Both types of encryption

are subject to various cryptanalysis attacks. The

objective of each attack is the same, namely to de-

duce the message or private communication. The

security of the secret key is the corner stone of

encryption schemes. The schemes are renderedineffective by a compromised secret key [4,5]. The

vulnerabilities of each scheme may be reduced by

making the ‘cost’ of the effort (time, money and/or

computational power) required to launch an effec-

tive attack exceed the value of the rewards.

Achieving User privacy is an important security

requirement in e-commerce activities. Referring to

Fig. 1, the MPN operator is aware of the User’sidentity, her home address, present location and

message traffic. However, the relationship between

the User and the MPN operator is a trusted one

where the operator assures the User of her privacy,

i.e. sensitive data is disclosed only to approved

third parties such as a Legal Authority. The MPN

operator also undertakes to protect the User’s

privacy by preventing disclosure of sensitiveinformation to unauthorised parties through the

application of the security services discussed


above, e.g. the prevention of eavesdropping by an

Adversary. The motivation for this privacy pro-

tection is financial. The MPN operator is a com-

mercial organisation motivated by financial gain.

Customer confidentiality is viewed as a means of

business retention and not business generation. Asimilar discussion may also apply to the User’s

ISP, E-Bank and the CAs. On-line Vendors, on the

other hand, view the exploitation of consumer

details as a means of revenue generation. It is a

condition of visiting their web sites that the Users

identify themselves and give their real-world

locations, and in doing so automatically consent to

their details being passed on to third parties, e.g.many web sites sell their client lists. More often,

Vendors use such identifying information to pro-

file Users’ interests in the guise of personalised

shopping, e.g. targeted advertising. Whilst such

activities take place on the High Street in the form

of store loyalty cards, the significant difference is

that joining the store loyalty scheme is not a

condition of shopping at that store. Arguably, on-line shopping is the modern day equivalent of mail

order. For this type of business to operate, it is

necessary to uniquely identify and verify the cre-

dential of each User so that orders may be pro-

gressed, payments collected and goods delivered.

The final entity in our mobile e-commerce infra-

structure is the Adversary, or Attacker, who for

various reasons including criminal intent or plaincuriosity, wishes to observe the User’s on-line

transactions with the intent of gleaning informa-

tion about the User’s identity, location, financial

status and lifestyle. In the real world, individuals

are allowed to go about their lawful business

unimpeded, and this includes shopping on the

High Street with a relatively high degree of pri-

vacy, given that the activity occurs in the publicdomain. Consumers have confidence that their

privacy is protected through the enactment of laws

reinforced by a judicial system that demands par-

ties demonstrate compliance with these laws, e.g.

everyone in the real world is held accountable for

their actions. Such laws are unenforceable on an

unregulated network such as the Internet. Whilst

Vendors have made best efforts to protect sensitivedata such as real-world names, addresses and

credit card details, an Adversary may freely ob-

serve on-line transactions and thus over time de-

velop on-line profiles on those individuals.

The aim of this paper is to present a scheme that

may enable a User with a mobile phone (and/or

laptop) to conduct multiple mobile e-commerce

transactions securely, anonymously and account-ably. The objective of our scheme is to protect the

User’s privacy and reduce the amount of infor-

mation that is used by third parties (vendors and

attackers) to develop on-line profiles whilst, at the

same time, ensuring that the User cannot abuse the

anonymity afforded to them through their use of

this scheme. In detail, Section 2 lists the require-

ments that such a privacy protection scheme mustmeet in order to reduce on-line profiling. Section 3

provides a survey of state-of-the-art proposals in-

tended to provide mobile phone and Internet users

with anonymity. Each proposal is assessed against

the privacy protection requirements listed Section

2. The survey demonstrates the need for more work

in this area. As a prelude to presenting our pro-

posal, Section 4 sets out and explains the formalnotation to be used in the remaining sections. Our

proposed scheme is described both by a narrative

and formal notation in Section 5. In Section 6

we give an analysis of our proposed scheme. We

compare our scheme to the original scheme as de-

scribed in [6] and to the design requirements listed

in Section 2. We give our conclusions in Section 7.

2. Requirements for anonymous PKI certificates

In order to prevent on-line profiling the solutionneeds to fulfil the following design requirements.

Each design requirement is denoted by [DRnum-ber: name] for later reference:

• The scheme should provide anonymity (denoted

as DR1: anonymity) in terms of ‘who’ (real and

on-line identity) and ‘where’ (location). By

denying a vendor or third party such informa-tion, they are unable to differentiate between

individual users. In this way the scheme has ‘un-

linked’ User identity and location from each

other and also from the data (sensitive informa-

tion). By removing any form of identification

(real world, on-line and location) the scheme de-


nies a vendor or third party an identity to which

they may link information.

• The scheme should prevent the building of cus-

tomer profiles (denoted as DR2: customer profil-ing) including pseudonymous profiles byvendors and third parties. A vendor or a third

party may be able to observe communications

from a source that they may be able to identify

as an individual, e.g. if the same pseudonym is

used repeatedly by an individual, then that

pseudonym may be used to build a profile on

as it is an identifiable source. The act of build-

ing a profile involves observing and recordingthe User’s actions, which the User may interpret

as an invasion of her privacy.

• The scheme should provide accountability (de-

noted as DR3: accountability) to prevent mis-

use/abuse of anonymity. By accountability we

mean one of two things depending on the con-

text. The User is accountable for her actions de-

spite using an anonymous certificate. Should theUser abuse her anonymity, her anonymity is re-

voked and her real identity is revealed. A CA is

accountable for its actions via an audit trail,

which provides evidence of its actions. It must

be demonstrable that all involved parties may

be held accountable for their actions in order

to prevent one party denying responsibility by

claiming that the abuse has occurred due tothe intent or neglect of another. For parties to

be held accountable the evidence presented must

have the property of non-repudiation.

• The scheme should provide non-repudiation

(denoted as DR4: non-repudiation) for dispute

resolution. By non-repudiation we mean that a

party cannot deny its action when presented

with the evidence of their actions, i.e. a partycannot claim that the actions were performed

or partly performed by another.

• The scheme should maximally resist the acquisi-

tion of anonymous certificates by unauthorised

parties or attackers (denoted as DR5: authoriseduse). If an unauthorised party acquires an ano-

nymous certificate either by intentional actions

or neglect of an authorised party, the unauthor-ised party may abuse the anonymity service

provided by such certificate. The consequences

of such abuse are threefold. Firstly, the ano-

nymity of the User, in whose name the certifi-

cate was issued, may be revoked. Secondly,

the User may abuse the legitimate certificate

and deny this, e.g. the User may claim that

the ‘abused’ certificate was acquired and usedby another party without the User’s consent

or knowledge. Finally, the unauthorised party

may commit an illegal act safe in the knowledge

that they will not be held accountable for it.

Many of these design requirements are inter-

dependent. Intuitively, in order to achieve DR2:customer profiling, DR1: anonymity must be met;to achieve DR3: accountability, DR4: non-repudi-ation must be met; to achieve DR5: authorised use,both DR3: accountability and DR4: non-repudia-tion must be met. To be credible, the scheme must

meet all of the above stated requirements.

3. Related work

There are a number of proposed schemes de-

signed to provide anonymity through unlinkabil-

ity. Unlinkable credentials (or certificates) are a

means of providing users with anonymity, with

accountability via an audit trail. The work in [7]

presents a scheme for untraceable communications

and untraceable payments with unlinkable cre-dentials. However, the paper indicates that the

potential for a revocation mechanism to be

incorporated exists but remains future work, i.e.

the scheme does not provide accountability and so

does not meet DR3: accountability. A suite of two

protocols [6] for issuing and identity tracing of

anonymous public-key certificates provide ano-

nymity with accountability. A security weaknessmentioned by the authors of [6] is that if a User’s

private key(s) is compromised then an attacker

may obtain anonymous certificates. The User may

then be accountable for the actions and abuses of

the attacker. In this sense, this scheme is weak in

meeting the requirement DR5: authorised use.Another proposed scheme provides non-transfer-

able anonymous multi-show credentials with op-tional anonymity revocation [8], i.e. without a

revocation mechanism this scheme does not meet

DR3: accountability. The scheme claims to be


efficient and practical. However, the authors note

that realising circular encryption (used as a means

to prevent certificate sharing) outside the random

oracle model is a challenging open issue. A further

scheme [9] is similar in nature to [6] and has been

designed specifically for e-commerce. The assur-ance of the anonymous certificates has been

accomplished by making them one-time only. In

order to make the number of certificates held by

the User manageable, ‘used’ (or redeemed) certifi-

cates are exchanged for new anonymous certifi-

cates by the vendor. This scheme places a great

deal of trust in the vendor and by inference does

not comply with DR2: customer profiling. Thereare also a number of schemes that aim to provide

anonymity services for mobile phone users [10–12].

The scheme presented in [10] uses a digital mix

inserted between the Visitor Location Register

(VLR) and the Home Location Register (HLR) of

the mobile phone infrastructure to provide the

User with anonymity in terms of identity and

location. When a User signs on to the network, themobile authentication protocol (challenge and re-

sponse) is performed via the VLR in the usual

manner except: (i) the VLR knows the mobile User

only by his pseudonym; and (ii) the HLR knows

the VLR by an anonymous return address only.

The visited network is authenticated to the User by

the home network through exchange of blind sig-

nature tokens. The disadvantages of the schemeare: (i) the authentication process has been ex-

tended and as a result may not be suitable for use

during base station hand-over; and (ii) the adop-

tion of this scheme would require significant

changes to the mobile phone infrastructure. The

proposal represented in [11] aims to provide the

User with anonymous access using a token-based

scheme. The scheme proposes the introduction ofa new business role, called the Customer Care

Agency (CCA), and a ticket based mechanism for

service access. The most obvious disadvantage of

this scheme is that the CCA is a trusted third party

and therefore represents a single point of failure in

terms of denial of service attacks. Direct Internet

Access (DIA) presented in [12] is another proposed

anonymous access method. It uses a temporarylocation identifier consisting of an IPv6 address

prefix provided by the MPN, with the lower part

of the address formed by a temporary identifier

(pseudonym), chosen by the User. Because the

temporary identifier is not registered with an

authority, the scheme lacks accountability, i.e.

DR3: accountability is not met. The schemes pro-

posed in [11,12] also suffer a further disadvantagein that they each require significant changes to the

mobile phone infrastructure.

Of the schemes surveyed, the anonymous cer-

tificate solution [6] has the greatest potential to be

adapted to generic (mobile) e-commerce transac-

tions. The remainder of the paper will concentrate

on our work improving this particular scheme, i.e.

our extension to the work presented in [6] to en-hance the security of the solution.

4. Notation

The notation to be used throughout this paper

(adopted from [6]) is summarised as follows:

• ðpki;a; ski;aÞ is a pair of public and private keys

for a party Pi certified by a CA Aa. (pka; ska) witha single subscript is a pair of public and private

keys owned by a CA Aa.

• EkðxÞ denotes the cyphertext of a data item xencrypted with a key k. EkðxÞ is generated using

a public-key cryptosystem if the corresponding

decryption key is different from k, and using aconventional (symmetric) cryptosystem other-

wise.

• x; y denotes the concatenation of data items xand y.

• hðxÞ is a one-way hash function with the follow-

ing properties: for any x, it is easy to compute

hðxÞ; given hðxÞ, it is difficult to compute x;and given x, it is difficult to find x0 (x 6¼ x0) suchthat hðxÞ ¼ hðx0Þ.

• Pi ! Pj : m expresses that a party Pi sends a mes-

sage m to another party Pj through normal com-

munication channel.

• Pi !A Pj : m denotes anonymous message trans-

fers between Pi and Pj. It indicates two possible

cases:

(i) Pi sends m to Pj through an anonymouscommunication channel. This means that Piknows Pj’s address/identity, but Pj does not


know Pi’s. If Pi requires Pj to respond to its

message, Pi needs to send to Pj m together

with an anonymous reply address. For exam-

ple, Pi’s address may be jondoe@some-

mail.com and Pj’s address may be Pj @cs.man.ac.uk.

(ii) Pi responds to an anonymous message from

Pj with m using the anonymous reply ad-

dress defined in Pj’s message. This means

that Pj knows Pi’s address/identity, but Pidoes not know Pj’s. In this instance, Pi’saddress may be [email protected] and Pj’saddress may be [email protected] of such anonymous communication

are to be found in [13–17].

Separate notation for each of the above two

cases has not been used since the appropri-

ate case may easily be deduced from the

context of the protocol presentation.

• Ci;b is an anonymous certificate of party Pi is-sued by a CA Ab, denoted as Ci;b ¼ ðAb;Ii;b; pki;b; ei;b; si;bÞ, where si;b (¼ EskbðhðAb; Ii;b;pki;b; ei;bÞÞ) is Ab’s signature, and Ii;b, pki;b and

ei;b are Pi’s pseudonym, public key and certifi-

cate expiration time, respectively. CRi;b is a real-

identity certificate of party Pi issued by a CA

Ab, denoted as CRi;b ¼ ðAb; IRi;b; pki;b; ei;b; si;bÞ,

where si;bð¼ Eskb ðhðAb; IRi;b; pki;b; ei;bÞÞÞ is Ab’s

signature, and IRi;b, pki;b and ei;b are Pi’s real iden-tity, public key and certificate expiration time,

respectively. We assume that every party knows

the public keys of all CAs.

5. Anonymous certificate issuing and real-identity

trace back

In this section we formally present and discuss

the two extended protocols, i.e. certificate issu-

ing and real-identity trace back, to facilitate

more secure accountable anonymous e-commerce

activities. Before that, we first explain our hy-

pothesis on which the modifications to the origi-

nal scheme presented in [6] are based and describe

the implications that our modifications have onthe overall working of the two protocols. Each

protocol is discussed and presented separately for

clarity.

5.1. Hypothesis

In the original scheme [6] it was assumed that

the User Pi may obtain anonymous certificates is-

sued directly or indirectly from a single real-iden-tity certificate. This resulted in Pi having a tree like

structure of certificates with one real-identity cer-

tificate as the root. If Pi had n real-identity certi-

ficates then there would be n corresponding

certificate trees for Pi. As discussed in Section 3,

one of the shortcomings of this scheme is that if an

attacker can compromise a single private key of Pi,he can then obtain anonymous certificates that arelinked to Pi. As a result, the attacker can imper-

sonate Pi and Pi would then be accountable for the

abuses committed by the attacker. In particular,

the compromise of a single key can lead to the

whole certificate graph being compromised. It is

therefore vitally important to have maximum

protection against private key compromise. Based

on this motivation, we propose a modification to[6] whereby the User may obtain an anonymous

certificate with two pieces of evidence, i.e. dem-

onstration of ownership of two private keys. We

hypothesise that it is more difficult for an adver-

sary to subvert a scheme that requires the pre-

sentation of two unique pieces of evidence, as

compared to a scheme that requires the presenta-

tion of just one piece of evidence. This evidencemay be the demonstration of rightful ownership of

the private keys associated with either:

• two real-identity certificates, or

• two anonymous certificates of the same genera-

tion.

It is worth noting that the combination of onereal and one anonymous certificate has not been

listed as permissible evidence. This is because a

real certificate and an anonymous certificate are of

different generations and therefore possess differ-

ent levels of anonymity assurance. The real cer-

tificate has no anonymity assurance since it may be

linked to the real identity of the User. The com-

bination of a real certificate and an anonymouscertificate may be used to obtain a further anon-

ymous child certificate, however, the anonymity

assurance of the anonymous child certificate is no


more than its parent anonymous certificate. A

similar discussion applies to the use of anonymous

certificates of different generations: a combination

of, say, a first generation anonymous certificate

and a third generation anonymous certificate will

produce a fourth generation anonymous certificatewith the anonymity assurance of a second gener-

ation anonymous certificate. Since the benefit to

the User of developing a graph with depth (as

opposed to breadth) is that the anonymous cer-

tificates towards the bottom of the graph posses

more anonymity assurance than those towards the

top (since the anonymous certificates at the bot-

tom of the graph are the most difficult to link tothe User’s identity), it is these certificates that the

User will use most often for anonymous e-com-

merce transactions. Since the development of the

graph is under the User’s sole control to ensure

unlinkability, it is the User’s responsibility to en-

sure that the parent certificates are of the same

generation. This certificate management problem

may be alleviated through the use of a graphicalrepresentation of the User’s certificate graph. Once

the ‘leaf’ certificates have been ‘contaminated with

history’, i.e. have been used for on-line transac-

tions in a similar manner to ‘classical’ PKI certifi-

Ci,a_2R

Ci,a_1R

Ci,b_1

Ci,b_2

Ci,c_1

Ci,c_2

Ci,n_1

Ci,n_2

Aa_1 Aa_2

Fig. 2. Certifica

cates and may be subject to on-line profiling, the

User revokes these certificates and moves up one

generation to use the parent certificates for anon-

ymous e-commerce transactions. The degree of

acceptable ‘contamination’ within a User’s certifi-

cate graph is yet to be quantified and remains opento the User’s perception.

The resulting graph, fully populated, may look

similar to that shown in Fig. 2 below. Note that

only the granted rights of the parent certificates

determine the depth of the graph.

Based on our hypothesis (i.e. it is harder for an

adversary to subvert a scheme that requires the

demonstration of ownership of two private keys ascompared to a scheme that requires the demon-

stration of ownership of just one private key), we

modify and present the certificate issuing and

identity trace back protocols in the following

subsections. We introduce the concept of ‘primary

parental certificate’ and ‘secondary parental cer-

tificate’. A primary parental certificate is used to

determine the granted rights that are inherited bythe child certificate. The secondary parental cer-

tificate is used for authentication only. We discuss

the significance of this difference in Sections 6.1.2

and 6.2.2. The User may decide which of her cer-

Ci,a_3R

Ci,b_3

Ci,c_3

Ci,n_3

Aa_3

te graph.


tificates are to be the primary and secondary

during child certificate issuance.

5.2. Certificate issuing protocol

Our Certificate Issuing Protocol requiring thepresentation of two certificates in order to obtain a

further anonymity certificate is illustrated in Table

1. The protocol items and their definitions are

given in Table 2, and stored items are listed in

Table 3.

We now describe our issuing protocol that

comprises four stages consisting of six transac-

tions. Referring to Table 1, let us assume the UserPi wishes to obtain a new anonymous certificate

Ci;b 1 from CA Ab 1 based on the presentation of

two existing anonymous certificates Ci;a 1 and Ci;a 2

issued by two different CAs Aa 1 and Aa 2, respec-

tively.

• In stage 1, Pi sends Ab 1 via an anonymous com-

munication channel its request which includesthe identities Aa 1 and Aa 2 plus items Xi;a 1

and Xi;a 2, verifiable only by their respective

issuing CAs, the new public key pki;b 1 to be cer-

tified, the seed sei;b 1 used for the (message hash

and) generation of the session symmetrical key

and the session number sni;b 1.

• In stage 2, Ab 1 forwards Xi;a 1 and Xi;a 2 to Aa 1

and Aa 2, , respectively, via an anonymous com-munication channel.

• In stage 3, Aa 1 verifies Xi;a 1 to authenticate Pi’srequest, grants Ab 1 a right for issuing a certifi-

cate to Pi and returns this right to Ab 1. Aa 2 per-

forms a similar task during this stage.

• In stage 4, Ab 1 issues a new anonymous certifi-

cate to Pi based on the granted rights.

Table 1

Issuing protocol

STAGE 1 T1 Pi !A Ab 1

STAGE 2 T2 Ab 1 !A Aa 1

T3 Ab 1 !A Aa 2

STAGE 3 T4 Aa 1 !A Ab 1

T5 Aa 2 !A Ab 1

STAGE 4 T6 Ab 1 !A Pi

Note that Pi is anonymous to Ab 1, and Ab 1 is

anonymous to Aa 1 and Aa 2. Aa 1 and Aa 2 are not

aware of each other’s involvement in the issuing

process.

5.2.1. Issuing protocol in detail

We assume that the User Pi possesses a mini-

mum of three real-identity PKI certificates issued

by three separate CAs: Aa 1, Aa 2 and Aa 3. By

using three separate CAs the User minimises the

possibility of any one (compromised) CA linking

and abusing two real-identity certificates and any

subsequent anonymous child certificates. In order

to ease the communications and processing burdenplaced on a CA, Aj, the number of certificates that

may be obtained by a User, Pi, is controlled

through the imposition of three constants: mlj, mcjand ei;j. mlj specifies the maximum number of

levels (or generations) that may exist using a real-

identity certificate as the root of the certificate

graph. mcj specifies the maximum number of child

certificates that may be issued to Pi using either areal-identity or anonymous certificate as the par-

ent. ei;j specifies the expiration time of a certificate.

mlj and ei;j are passed down to child certificates in

the form of granted rights, and mcj is determined

by each issuing CA. A detailed explanation of mlj,mcj and ei;j may be found in [6]. The following

gives a detailed description of the protocol.

STAGE 1: The User Pi decides a new pair ofpublic and private keys (pki;b 1, ski;b 1) and chooses

two random numbers sni;b 1 and sei;b 1. sni;b 1 is

used as the current session number. sei;b 1 is a se-

cret number (or seed) used to calculate a unique

session key ki;b 1 used for secure communication

between parental and child CAs. Pi then computes

ki;b 1, aui;a 1, aui;a 2, Xi;a 1, Xi;a 2, constructs the

Epkb 1ðAa 1; pki;b 1; sei;b 1; sni;b 1;Xi;a 1;Aa 2;Xi;a 2Þ

Xi;a 1

Xi;a 2

sni;b 1;Eki;b 1ðsrAa 1i;b 1 Þ

sni;b 1;Eki;b 1ðsrAa 2i;b 1 Þ

Ci;b 1

Table 2

Issuing protocol items and definitions

Item Definition

Pi The User

Epkb 1 Cyphertext generated using public key of Ab 1

Ab 1 Name of CA Ab 1

Aa n Name of nth CA at level ‘a’ of the certificate

graph (where 1 < n6 total number of certifi-

cates at that specific level)

pki;b 1 Public key of User Pi to be certified by Ab 1

sei;b 1 Secret number randomly chosen by User Pi,used to generate session key ki;b 1

sni;b 1 Session number randomly chosen by User PiXi;a 1 Epka 1ðIi;a 1; aui;a 1ÞXi;a 2 Epka 2ðIi;a 2; aui;a 2; ID CHECK ONLYÞIi;a 1 User’s ID as known to Aa 1

Ii;a 2 User’s ID as known to Aa 2

aui;a 1 Eski;a 1 (Aa 1, Ii;a 1, sni;b, ki;b 1), User’s authenti-

cation token for Ci;a 1

aui;a 2 Eski;a 2 (Aa 2, Ii;a 2, sni;b, ki;b 1), User’s authenti-

cation token for Ci;a 2

Eski;a 1 Cyphertext generated using User’s secret key

shared with Aa 1

Eski;a 2 Cyphertext generated using User’s secret key

shared with Aa 2

ki;b 1 Session key generated by the User, where

ki;b 1 ¼ hðAb 1, pki;b 1, sei;b 1)

srAa 1i;b 1 Eska 1 (sni;b 1, ki;b 1, grAa 1

i;b 1 ), confirmation that the

granted rights are indeed given by Aa 1

srAa 2i;b 1 Eska 2 (sni;b 1, ki;b 1, grAa 2

i;b 1 ), confirmation that the

granted rights are indeed given by Aa 2

grAa 1i;b 1 Granted right comprising (sti;b 1, lei;b 1) given by

Aa 1 to Ab 1 to issue a certificate

grAa 2i;b 1 Granted right comprising (PASS/FAIL) given

by Aa 2 to Ab 1 to issue a certificate

sti;b 1 Remaining number of allowable certificate levels

within the certificate graph originating from the

parent certificate Ci;a 1, i.e. sti;b 1 ¼ ðsti;a 1 � 1Þ. Ifthe parent certificate is a real-identity certificate,

i.e. CRi;a 1, then sti;b 1 ¼ ðmli;a 1 � 1Þ, where mli;a 1

is the maximum number of allowable levels in a

certificate graph originating from CRi;a 1

lei;b 1 Granted expiration time of certificate Ci;b 1, and

lei;b 1 < lei;a 1

Ci;b 1 Pi’s certificate issued by Ab 1, i.e.

Ci;b 1 ¼ ðAb 1; Ii;b 1; pki;b 1; ei;b 1; si;b 1Þei;b 1 Expiration time of certificate Ci;b 1 chosen by

Ab 1 such that ei;b 1 < lei;b 1

si;b 1 Eskb 1ðhðAb 1; Ii;b 1; pki;b 1; ei;b 1ÞÞ, Ab 1’s signature

on the certificate Ci;b 1 to certify that the

certificate is indeed issued by Ab 1

Table 3

Issuing protocol stored items

For each certificate issued by Ab 1, Ab 1 stores:

Ci;b 1 : sni;b 1, Aa 1, Aa 2, sei;b 1, srAa 1i;b 1 , sr

Aa 2i;b 1 .

If any child certificates are subsequently requested, then:

Ci;c n : sni;c n; ki;c n; lei;c n; aui;c n, where n denotes the nthchild certificate issued by Ab 1.

Note that lei;c n is not generated and stored if the parent

certificate Ci;b 1 is a secondary parental certificate.


message in Transaction T1 and sends it to Ab 1.Xi;a 1, which is encrypted with Aa 1’s public key

pka 1, is to allow only Aa 1 to know Pi’s pseudo-

identity Ii;a 1. Similarly Xi;a 2, encrypted with Aa 2’spublic key pka 2, is to allow only Aa 2 to know Pi’spseudoidentity Ii;a 2. aui;a 1 is the cyphertext gen-

erated with Pi’s secret key ski;a 1 (corresponding to

pki;a 1 and shared with Aa 1) to allow Aa 1 to

authenticate Pi. Similarly, aui;a 2 generated with

Pi’s secret key ski;a 2 (corresponding to pki;a 2) is to

allow Aa 2 to authenticate Pi.It should be emphasised that Xi;a 1 is a secure

way for Ab 1 to acquire from Aa 1 the approval to

certify the public key pki;b 1, and issue the anony-

mous certificate Ci;b 1 without letting Aa 1 know

pki;b 1. A similar reasoning applies to Xi;a 2.

STAGE 2: Ab 1 decrypts Pi’s message with key

skb 1 and verifies that Aa 1 and Aa 2 are both valid

CAs. If this verification fails, Ab 1 terminates the

protocol run and returns the message ‘No Certifi-

cation’ to Pi using the following transaction:

Ab 1 !A Pi: sni;b 1, Eki;b 1(sni;b 1, ‘No certification’).

If the verification is successful, Ab 1 saves all the

items and forwards Xi;a 1 to Aa 1 (in Transaction

T2) and Xi;a 2 to Aa 2 (in transaction T3).

STAGE 3: Upon receipt of T2, Aa 1 performs

the following operations. Aa 1 decrypts Xi;a 1 with

ska 1 and verifies that identity Ii;a 1 has a certificateCi;a 1 issued and held by Aa 1 and Ci;a 1 has not

expired or been revoked. If the verification is

successful, Aa 1 decrypts aui;a 1 in Xi;a 1 with key

pki;a 1 in Ci;a 1 to obtain A0a 1, I

0i;a 1, sni;b 1 and ki;b 1.

Aa 1 then checks that A0a 1 ¼ Aa 1 and I 0i;a 1 ¼ Ii;a 1.

If the result of the check is positive Aa 1 has evi-

dence that suggests the request was indeed origi-

nated by Pi. Aa 1 then performs the followingchecks against the granted right gri;a 1 ¼ ðsti;a 1;lei;a 1Þ in Ci;a 1:

Verification I3.1: Is sti;a 1 > 1? That is, is Aa 1

permitted to grant child certificates for Pi based on

the presentation of Ci;a 1?


Verification I3.2: Is the number of valid (i.e.

unexpired) child certificates already issued by Aa 1

less than mca 1? That is, is Aa 1 permitted to grant

another child certificate to Pi based on the pre-

sentation of Ci;a 1?

If the results of Verification I3.1 and Verifica-tion I3.2 are both positive then Aa 1 chooses a fu-

ture time lei;b 1 < ei;a 1. Ideally, this date, lei;b 1, is

far enough into the future such that the number of

certificates issued by Aa 1 to expire on or after

lei;b 1 is sufficiently large to prevent an attacker

from linking Ci;a 1 and Ci;b 1. If lei;b 1 ¼ ei;a 1 then

it may be possible for an observer to recognise the

same expiration times of different certificates anddeduce that these certificates are in the same

graph. A similar discussion applies to ei;b 1, the

published expiration date of certificate Ci;b 1. Aa 1

then computes: srAa 1i;b 1 ¼ Eska 1ðsni;b 1; ki;b 1; gr Aa 1

i;b 1 Þand generates the message: sni;b 1, Eki;b 1ðsr Aa 1

i;b 1 Þand performs transaction T4 to Ab 1.

If the result of either Verification I3.1 or Veri-

fication I3.2 is negative then the granted right isgri;b 1 ¼ ð0; 0Þ. Aa 1 computes: srAa 1

i;b 1 ¼ Eska 1

ðsni;b 1; ki;b 1; gr Aa 1i;b 1 Þ and generates the message:

sni;b 1, Eki;b 1ðsr Aa 1i;b 1 Þ and performs transaction T4

to Ab 1 in the usual manner.

The session key ki;b 1 is used for the encryption

of srAa 1i;b 1 , i.e. Eki;b 1ðsrAa 1

i;b 1Þ since Aa 1 does not know

the identity of Ab 1. For identity tracing, Aa 1 needs

to store the following if ðsti;a 1 � 1Þ > 0: sni;b 1,ki;b 1, lei;b 1 and aui;a 1.

Similarly, during STAGE 3, Aa 2 performs the

same operations as performed by Aa 1 described

above, but on Xi;a 2 and related items accordingly.

Since Ci;a 2 is presented as secondary evidence

only, Aa 2 does not need to perform the checks

against the granted right gri;a 2 ¼ ðsti;a 2; lei;a 2Þ in

Ci;a 2 as described in Verification I3.1 or Verifica-tion I3.2. For identity tracing, Aa 2 needs to store

the following: sni;b 1, ki;b 1 and aui;a 2. It is worth

noting that it is the User Pi who decides which

certificate is to be presented as the primary or

secondary evidence and therefore processed

accordingly by the relevant CAs.

STAGE 4: Ab 1 decrypts Eki;b 1ðsrAa 1i;b 1Þ and

Eki;b 1ðsrAa 2i;b 1Þ with ki;b 1 and then srAa 1

i;b 1 and srAa 2i;b 1

with pka 1 and pka 2, respectively. Ab 1 checks that

sni;b 1 in srAa 1i;b 1 and srAa 2

i;b 1 are correct, i.e. identical

to sni;b 1 given in Transaction 1 and that ki;b 1 in

srAa 1i;b 1 and srAa 2

i;b 1 are correct, i.e. identical to ki;b 1 ¼hðAb 1; pki;b 1; sei;b 1Þ computed by Ab 1 and that

sti;b 1 in grAa 1i;b 1 is greater than zero (i.e., sti;b 1 > 0)

and grAa 2i;b 1 ¼ ‘PASS’.

If the results are positive, Ab 1 generates a un-ique pseudonym Ii;b 1, chooses an expiration time

ei;b 1 so that ei;b 1 < lei;a 1 and issues the following

certificate to Pi in Transaction T6:

Ci;b 1 ¼ ðAb 1; Ii;b 1; pki;b 1; ei;b 1; si;b 1Þ;

where

si;b 1 ¼ Eskb 1ðhðAb 1; Ii;b 1; pki;b 1; ei;b 1ÞÞ

Ab 1 then stores certificate Ci;b 1 and related items

including any subsequent child certificates, as de-

fined in Table 3.

If the results of any of these checks are negative,

i.e. if sni;b 1 in srAa 1i;b 1 and srAa 2

i;b 1 is not equal to sni;b 1

given in Transaction 1, or if ki;b 1 in srAa 1i;b 1 and

srAa 2i;b 1 is not equal to hðAb 1; pki;b 1; sei;b 1Þ, or if

sti;b 1 ¼ 0, or grAa 2i;b ¼ ‘FAIL’, then Ab 1 returns the

‘No certification’ message to Pi.

5.3. Real-identity tracing

When an abuse of anonymity occurs in associ-

ation with a particular anonymous certificate, say

Pi persistently orders goods or services which Pihas no intention of making payment for, a LegalAuthority (LA) may be called to trace the anon-

ymous certificate back to its corresponding real-

identity certificate. In this way, Pi is held

accountable for his/her actions. We assume that

the LA is a trusted authority and does not reveal

the link between the anonymous certificate and its

corresponding real-identity certificate to any un-

authorised party. In order to hold Pi accountable,it must be demonstrated that at all stages the re-

quired two pieces of evidence were used. An issu-

ing CA now needs to pass back the evidence

associated with each parent certificate to the

appropriate parent CAs or directly to the LA.

5.4. Identity tracing protocol

For instance, assume that an abuse has been

committed in association with certificate Ci;c 2, the

Ci,c_2

Ci,b_1

Ci,b_2

Ci,a_1 R

Ci,a_2 R

Ci,a_3 R

Evidence to LA: Ci,c_2 sei,c_2 sri,c_2

Ab_1 sri,c_2

Ab_2

trace back data: sni,c_2

Evidence to LA: Ci,b_1 sei,b_1 sri,b_1

Aa_1 sri,b_1

Aa_2 aui,c_2

Evidence to LA: Ci,b_2 sei,b_2 sri,b_2

Aa_2 sri,b_2

Aa_3 aui,c_2

Evidence to LA: Ci,a_1

R aui,b_1


R aui,b_2


R aui,b_1 aui,b_2

trace back data: sni,b_1

trace back data: sni,b_2

Fig. 3. Real-identity trace back sequence for Ci;c 2.


complete (or full) trace-back sequence is illustrated

in Fig. 3.

Our Identity Trace Back Protocol associated

to the anonymous certificate issuing protocol

presented in the previous subsection is pre-

sented in Table 4 with items and definitions

listed in Table 5, which is followed by a fulldescription of our Identity Trace Back Proto-

col.

STAGE 1: Once LA has been advised that

abuses of anonymity have occurred in association

Table 4

Trace back protocol

STAGE 1 T1 LA ! Ac 2

STAGE 2 T2 Ac 2 !A Ab 1

T3 Ac 2 !A Ab 2

STAGE 3 T4 Ab 1 !A Aa 1

T5 Ab 1 !A Aa 2

T6 Ab 2 !A Aa 2

T7 Ab 2 !A Aa 3

STAGE 4 T8 Aa 1 ! LA

T9 Aa 2 ! LA

T10 Aa 3 ! LA

STAGE 5 LA examines the evidence that the right

identified in the real-identity certificates

with anonymous certificate Ci;c 2, LA generates

nLA, tLA, sLA, siLA, Epkc 2 (defined in Table 5) and

performs Transaction T1, where sLA is passed on

to all relevant CAs.

STAGE 2: Ac 2 decrypts the message in T1 with

key skc 2 and verifies that CLA represents a legal

authority. Ac 2 then verifies the correctness of thereceived message by performing the following

verifications:

Verification T2.1: Decrypts sLA with pkLA and

retrieves n0LA and t0LA and compares them with the

Epkc 2ðCLA;Ci;c 2; nLA; tLA; sLA; siLAÞEpkb 1ðCLA; nLA; tLA; sLA;sni;c 2; evc 2; chc 2ÞEpkb 2ðCLA; nLA; tLA; sLA; sni;c 2; evc 2; chc 2Þ

Epka 1ðCLA; nLA; tLA; sLA; sni;b 1; evb 1; chb 1ÞEpka 2ðCLA; nLA; tLA; sLA; sni;b 1; evb 1; chb 1ÞEpka 2ðCLA; nLA; tLA; sLA; sni;b 2; evb 2; chb 2ÞEpka 3ðCLA; nLA; tLA; sLA; sni;b 2; evb 2; chb 2Þ

eva 1

eva 2

eva 3

ful holder of the abused anonymity certificate is the individual

Table 5

Trace back protocol items and definitions

Item Definition

nLA Session number chosen by LA

tLA Time stamp

sLA EskLAðnLA; tLAÞ, LA’s signature on its session number and time stamp

siLA EskLAðhðCi;c 2; sLAÞÞ, LA’s secured transaction reference identifier

evc 2 EpkLAðCi;c 2;Eskc 2ðnLA; sei;c 2; srAb 1i;c 2 ; sr

Ab 2i;c 2 ÞÞ, Ac 2’s evidence that Ci;c 2 was issued with the approvals from Ab 1 and Ab 2

chc 2 hðki;c 2;CLA; sLA; sni;c 2; evc 2Þ, Ac 2’s message check sum

ki;c 2 hðAc 2; pki;c 2; sei;c 2Þ, session key derived by Ac 2

evb 1 EpkLAðCi;b 1; evc 2;Eskb 1ðnLA; sei;b 1; srAa 1i;b 1 ; sr

Aa 2i;b 1 ; aui;c 2; hðevc 2ÞÞÞ, Ab 1’s evidence that Ci;b 1 was issued with approval

from Aa 1 and Aa 2 and that Pi requested the child certificate Ci;c 2

chb 1 hðki;b 1;CLA; sLA; sni;b 1; evb 1Þ, Ab 1’s message checksum

ki;b 1 hðAb 1; pki;b 1; sei;b 1Þ, session key derived by Ab 1

evb 2 EpkLAðCi;b 2; evc 2;Eskb 2ðnLA; sei;b 2; srAa 2i;b 2 ; sr

Aa 3i;b 2 ; aui;c 2; hðevc 2ÞÞÞ, Ab 2’s evidence that Ci;b 2 was issued with approval

from Aa 2 and Aa 3 and that Pi requested the child certificate Ci;c 2

chb 2 hðki;b 2;CLA; sLA; sni;b 2; evb 2Þ, Ab 2’s message checksum

ki;b 2 hðAb 2; pki;b 2; sei;b 2Þ, session key derived by Ab 2

eva 1 EpkLAðCRi;a 1; evb 1;Eska 1ðnLA; aui;b 1; hðevb 1ÞÞ, Aa 1’s evidence of Pi’s real identity and that Pi requested the child

certificate Ci;b 1

eva 2 EpkLAðCRi;a 2; evb 1; evb 2;Eska 2ðnLA; aui;b 1; aui;b 2; hðevb 1Þ; hðevb 2ÞÞ, Aa 2’s evidence of Pi’s real identity and that Pi

requested the child certificates Ci;b 1 and Ci;b 2

eva 3 EpkLAðCRi;a 3; evb 2;Eska 3ðnLA; aui;b 2; hðevb 2ÞÞ, Aa 3’s evidence of Pi’s real identity and that Pi requested the child

certificate Ci;b 2


corresponding values in T1, i.e. nLA and tLArespectively.

If Verification T2.1 is positive then the CA has

proof that the message is indeed originated from

LA and it has not been altered. The inclusion of

nLA and tLA also provides protection against mes-

sage replay-attacks or ‘spoofing’. Otherwise, the

protocol terminates with a fail-stop. Given a po-

sitive result, Ac 2 goes on to:Verification T2.2: Decrypts siLA with pkLA and

retrieves hðCi;c 2; sLAÞ, computes a fresh h0ðCi;c 2;sLAÞ and compares h0ðCi;c 2; sLAÞ to hðCi;c 2; sLAÞ.

If Verification T2.2 is positive then the CA has

proof that the message did indeed originate from

LA and it has not been altered. Otherwise, the

protocol terminates with a fail-stop. Given a po-

sitive result, Ac 2 goes on to:Verification T2.3: Check that Ci;c 2 is a certifi-

cate issued by Ac 2.

Given a positive result, Ac 2 retrieves items

sni;c 2, Ab 1, Ab 2, sei;c 2, srAb 1i;c 2 and srAb 2

i;c 2 stored in

association with Ci;c 2 (as illustrated in Table 3),

derives key ki;c 2 ¼ hðAc 2; pki;c 2; sei;c 2Þ, computes

evc 2 and chc 2 (defined in Table 5), generates its

messages to Ab 1 and Ab 2 and perform transac-tions T2 and T3.

It is worth noting that, (1) evc 2 provides LAwith evidence that Ac 2 issued Ci;c 2 upon Pi’s re-

quest and with consent from Ab 1 and Ab 2, where

chc 2 is the message checksum; (2) the message

content to Ab 1 and Ab 2 is exactly the same except

that each message is encrypted with the relevant

CA’s public key pkb n, where n 2 f1; 2g; (3) re-

cipient CAs cannot read evc 2 since it is encrypted

with LA’s public key pkLA.STAGE 3: In this stage, Ab 1 decrypts the mes-

sage from Ac 2 with skb 1 and uses sni;c 2 to find the

related (child) certificate Ci;c 2 and stored items

ki;c 2 and aui;c 2. Ab 1 verifies that CLA represents a

legal authority and then performs Verification

T2.1, generates ch0c 2 ¼ hðk0i;c 2;C0LA; s

0LA; sn

0i;c 2;

ev0c 2Þ, where k0i;c 2 is Ab 1’s own copy and C0LA, s

0LA,

sn0i;c 2 and ev0c 2 are taken from Epka 1. Ifch0c 2 ¼ chc 2, then Ab 1 has proof that Epka 1 is

unmodified. If ch0c 2 6¼ chc 2 then the protocol ter-

minates with a fail-stop. Given a positive result,

Ab 1 retrieves another set of items sni;b 1, Aa 1, Aa 2,

sei;b 1, srAa 1i;b 1 and srAa 2

i;b 1 stored in association with

Ci;b 1; computes ki;b 1, evb 1 and chb 1 (defined in

Table 5), constructs its messages to Ab 1 and Ab 2

and performs transactions T4 and T5 via ananonymous communication channel, respectively.


Note (1) the message contents to Aa 1 and Aa 2

are exactly the same except that each message is

encrypted with the relevant CA’s public key pka n,

where n 2 f1; 2g; (2) neither of the recipient CAs

can read the evidence since it is encrypted with

LA’s public key pkLA; (3) evb 1 includes aui;b 1 andevc 2, where aui;b 1 allows LA to verify the

authenticity of Pi’s request for Ci;b 1, and evc 2 is

the evidence received from Ac 2.

Ab 2 performs similar operations as that by Ab 1

in Stage 3 to form its messages (as defined in Table

4) to Aa 2 and Aa 3 (transactions T6 and T7),

respectively.

STAGE 4: In this stage, Aa 1 decrypts themessagefrom Ab 1 with ska 1 and uses sni;b 1 to find the re-

lated (child) certificate Ci;b 1 and stored item aui;b 1.

Aa 1 verifies thatCLA represents a legal authority and

then performs Verification T2.1; generates ch0b 1 ¼hðk0i;b 1;C

0LA; s

0LA; sn

0i;b 1; ev

0b 1Þ, where k0ib 1 is Aa 1’s

own copy and C0LA, s

0LA, sn

0i;b 1 and ev0b 1 are taken

from T4 and checks that if ch0b 1 ¼ chb 1. If they are

equal, then Ab 1 has proof that Epka 1 is unmodified.Aa 1 then generates its message (defined in Table 4)

to LA, and performs Transaction T8 via a normal

communications channel. If ch0b 1 6¼ chb 1, then the

protocol terminates with a fail-stop. It is worth

noting that the parent certificate CRi;a 1 is a real-

identity certificate and therefore eva 1 does not

contain sei;a 1 or sri;a 1 and so their derivatives ki;a 1

and cha 1 are not generated.Aa 2 performs similar operations as that by Aa 1

above, and performs Transaction T9 via a normal

communications channel. Here, CRi;a 2 is a parent to

bothCi;b 1 andCi;b 2 and so eva 2 contains evb 1, evb 2,

aui;b 2 and aui;b 2. If the messages from Ab 1 and Ab 2

arrive at significantly different times, Aa 2 may send

two separatemessages to LA containing information

pertaining to each child certificate. For example, saythe message from Ab 2 arrives sometime before the

message from Ab 1. Aa 2 generates and sends the

message EpkLAðCRi;a 2, AWAITING_evb 1, evb 2,

Eska 2ðnLA; aui;b 2; hðevb 2ÞÞ to LA in T9a. When the

message from Ab 1 arrives, Aa 2 generates and sends

the message EpkLAðCRi;a 2; evb 1; SENT evb 2; Eska 2

ðnLA; aui;b 1; hðevb 1ÞÞ to LA in T9b.

Aa 3 performs similar operations as Aa 1 above,and performs Transaction T10 via a normal

communications channel.

STAGE 5: Once LA has received the evidence,

eva 1, eva 2 and eva 3, it verifies that each piece of

evidence received is authentic and that each cer-

tificate has been issued correctly. The first step is to

recover the nested evidences as per Evidence

Recovery below. Say, LA chooses to start witheva 1 that is of the form eva 1ðevb 1ðevc 2ÞÞ:

Evidence Recovery for eva 1: LA decrypts eva 1

with key skLA to recover CRi;a 1, evb 1 and

Eska 1ðnLA; aui;a 1; hðevb 1ÞÞ. LA then decrypts

Eska 1ðnLA; aui;a 1; hðevb 1ÞÞ with key pka 1 to re-

cover nLA, aui;b 1 and hðevb 1Þ. LA checks that nLAis identical to the value included in sLA. If positive,LA then generates a hash of ev0b 1, i.e. hðev0b 1Þ andchecks that the freshly generated hash is equal to

the one received. If this is positive, LA then pro-

cesses the next nested evidence, i.e. evb 1.

Evidence Recovery for evb 1 found in eva 1: LA

decrypts evb 1 with key skLA to recover Ci;b 1, evc 2

and Eskb 1ðnLA; sei;b 1; srAa 1i;b 1 ; sr

Aa 2i;b 1 ; aui;c 2; hðevc 2ÞÞ.

LA then decrypts Eskb 1ðnLA; sei;b 1; srAa 1i;b 1 ; sr

Aa 2i;b 1 ;

aui;c 2; hðevc 2ÞÞ with key pkb 1 to recover nLA,sei;b 1, srAa 1

i;b 1 , srAa 2i;b 1 , aui;c 2 and hðevc 2Þ. LA checks

that nLA is identical to the value included in sLA. Ifpositive, LA then generates a hash of ev0c 2, i.e.

hðev0c 2Þ and checks that the freshly generated hash

is equal to the one received. If this is positive, LA

then processes the next nested evidence, i.e. evc 2.

Evidence Recovery for evc 2 found in evb 1: LA

decrypts evc 2 with key skLA to recover Ci;c 2 andEskc 2ðnLA; sei;c 2; srAb 1

i;c 2 ; srAb 2i;c 2 Þ. LA then decrypts

Eskc 2ðnLA; sei;c 2; srAb 1i;c 2 ; sr

Ab 2i;c 2 Þ with key pkc 2 to

recover nLA, sei;c 2, srAb 1i;c 2 and srAb 2

i;c 2 . LA checks

that nLA is identical to the value included in sLA.LA continues this decryption and verification

process in a similar manner to Evidence Recovery

(above) for the nested evidences eva 2ðevb 1ðevc 2Þ;evb 2ðevc 2ÞÞ and eva 3ðevb 2ðevc 2ÞÞ.

If all the verifications are correct, LA then

performs the following on all decrypted evidences.

For brevity, we show only the processing for the

nested evidence eva 1ðevb 1ðevc 2ÞÞ:LA generates and retains k0i;b 1 ¼ hðAb 1; pki;b 1;

sei;b 1Þ using evidence evb 1, then decrypts aui;b 1

(found in eva 1 and also eva 2) with pki;b 1 in Ci;b 1

to obtain Ab 1, Ii;b 1, sni;b 1 and ki;b 1, and checksthat Ab 1, Ii;b 1, sni;b 1 and ki;b 1 in eva 1 are identical

to the corresponding values in eva 2. LA verifies


that both Ab 1 and Ii;b 1 are in Ci;b 1 and that

ki;b 1 ¼ k0i;b 1 (generated by LA). If the results are

all positive, LA has proof that Pi has indeed ap-

plied to Ab 1 for Ci;b 1 using CRi;a 1 and CR

i;a 2.

LA continues the verification of certificate

issuing, i.e. decrypts srAa 1i;b 1 (in evb 1) with pka 1 to

obtain sni;b 1, k00i;b 1 and grAa 1i;b 1 ; decrypts sr

Aa 2i;b 1 (also

in evb 1) with pka 2 to obtain sni;b 1, k00i;b 1 and grAa 2i;b 1 ;

decrypts srAb 1i;c 2 (in evc 2) with pkb 1 to obtain sni;c 2,

k00i;c 2 and grAb 1i;c 2 ; and decrypts srAb 2

i;c 2 (also in evc 2)

with pkb 2 to obtain sni;c 2, k00i;c 2 and grAb 2i;c 2 . LA then

confirms that k00i;b 1 in grAa 1i;b 1 (in evb 1) is identical to

the value in grAa 2i;b 1 (also in evb 1) and k00i;c 2 in grAb 1

i;c 2

(in evc 2) is identical to the value in grAb 2i;c 2 (also in

evc 2). LA verifies that k00i;b 1 (in evb 1)¼ k0i;b 1 (gen-

erated by LA); k00i;c 2 (in evc 2)¼ k0i;c 2 (generated by

LA); sti;b 1 > 0 and ei;b 1 < lei;b 1 in grAa 1i;b 1 ; sti;c 2 >

0 and ei;c 2 < lei;c 2 in grAb 1i;c 2 ; gr

Aa 2i;b 1 ¼ ‘PASS’; and

grAb 2i;c 2 ¼ ‘PASS’.If the verifications for all nested evidences are all

positive then LA has the proof: Aa 1 and Aa 2 both

granted Ab 1 the right for issuing Ci;b 1 since srAa 1i;b 1 is

signed with Aa 1’s private key ska 1 and srAa 2i;b 1 is

signed with Aa 2’s private key ska 2; Aa 2 and Aa 3

both granted Ab 2 the right for issuing Ci;b 2 since

srAa 2i;b 2 is signed with Aa 2’s private key ska 2, and

srAa 3i;b 2 is signed with Aa 3’s private key ska 3; and Ab 1

and Ab 2 both granted Ac 2 the right for issuing Ci;c 2

since srAb 1i;c 2 is signed with Ab 1’s private key skb 1,

and srAb 2i;c 2 is signedwithAb 2’s private key skb 2. That

is, all anonymous certificates were issued correctly

and therefore LA has non-repudiable evidence that

the abused anonymous certificate Ci;c 2 belongs to

the individual whose real identity is shown on real-

identity certificates CRi;a 1 , C

Ri;a 2 and CR

i;a 3.

6. Protocol analysis

We now analyse our Issuing and Trace Back

protocols in terms of enhancements made as

compared to the original work presented in [6],

and we demonstrate that each protocol possesses

the fundamental characteristics of anonymity and

accountability by illustrating that the design

requirements stated in Section 2 have been met.Each protocol analysis is presented separately in

the following two subsections.

6.1. Issuing protocol analysis

6.1.1. Top-level assessment

We note the following general observations

about our protocol as compared to the originalissuing protocol as described in [6]:

• In order to obtain an anonymous certificate the

User must present two pieces of evidence, in this

case, two PKI certificates, and demonstrate pos-

session of the associated private keys. Since two

pieces of evidence are required the User submits

them together in the same transaction.• Since each certificate will have its own granted

right, the User Pi may indicate from which (par-

ent) certificate they prefer the granted right of the

new certificate to be inherited, by placing the pre-

ferred parent certificate first in the list within

Epkb 1. The Xi;a 2 information associated with

the second parent certificate (which simply acts

as additional evidence) is modified to includethe message ‘ID CHECK ONLY’. In this way,

the CA of the secondary parent certificate knows

that it must look up the expiry date and CRL but

notml ormc information for that certificate. The

Xi;a 1 information associated with the primary

parent certificate is unmodified and so the CA

of the primary parent certificate processes the

application as per the original scheme in [6].• The CA of the primary parent certificate returns

the granted rights within srAa 1i;b 1 as before. The

CA of the secondary parent certificate simply

returns a ‘PASS/FAIL’ message within srAa 2i;b 1 .

The issuing CA must receive both the granted

rights and a ‘PASS’ message in order to issue

a certificate. The issuing CA constructs the

new certificate using the granted rights fromthe primary parent certificate. If the issuing

CA does not receive both pieces of information

in the affirmative then the protocol terminates

with a fail-stop and a ‘No certification’ message

is sent to the User.

6.1.2. Assessment of our novel contribution

The concept of using primary and second-ary parent certificates for certificate issuing is a

novel one that results in a simple and efficient

modification to the original scheme. This is best


illustrated by considering the case of using two

parent certificates of the same weighting, i.e. two

primary parent certificates. Both of theses certifi-

cates have not expired, have not been placed on

the CRL, have a ml or st (number of levels or

generations for real or anonymous certificates,respectively) value greater than zero and a mc(number of child certificates) value greater than

zero. The User would check these details before

submitting the application for a new certificate.

Referring to Table 1:

• In T1 the User Pi would construct and send

Epkb 1ðAa 1; pki;b 1; sei;b 1; sni;b 1;Xi;a 1;Aa 2;Xi;a 2Þwith Xi;a 1 and Xi;a 2 as per the original scheme,

i.e. Xi;a 2 would not contain the additional ‘ID_

CHECK_ONLY’ message.

• In T2 and T3 the issuing CA, Ab 1, would for-

ward Xi;a 1 and Xi;a 2 to the relevant parent

CAs, Aa 1 and Aa 2.

• For T4, Aa 1 would construct and send the mes-

sage sni;b 1, Eki;b 1ðsrAa 1i;b 1Þ to the issuing CA, Ab 1,

with grAa 1i;b 1 ¼ ðsti;b 1 > 0; lei;b 1 > 0Þ. At this

stage Aa 1 would need to make a provisional

child certificate allocation to the parent certifi-

cate, Ci;a 1, and store the following items with

a ‘awaiting confirmation’ note, Ci;b 1: sni;b 1,

ki;b 1, lei;b 1, aui;b 1, ‘pending’.

• For T5, Aa 2 would construct and send the mes-

sage sni;b 1, Eki;b 1ðsrAa 2i;b 1Þ to the issuing CA, Ab 1,

with grAa 2i;b 1 ¼ ðsti;b 1 > 0; lei;b 1 > 0Þ. Aa 2 would

also need to make a provisional child certificate

allocation to the parent certificate, Ci;a 2, and

store the following items with a ‘awaiting con-

firmation’ note, Ci;b 1: sni;b 1, ki;b 1, lei;b 1,

aui;b 1, ‘pending’.

• In order to construct and send Ci;b 1 to Pi in T6,

the issuing CA Ab 1 must decide which grantedrights, grAa 1

i;b 1 or grAa 2i;b 1 , the new certificate will in-

herit. Assuming Ab 1 is able to do so using a

selection criterion acceptable to User Pi, Ab 1

then needs to inform both parent CAs, Aa 1

and Aa 2, of this decision so that they may up-

date the provisional child certificate informa-

tion stored in association with the parent

certificate. For example, say Ab 1 selects grAa 2i;b 1 :

• For T7, Ab 1 would then need to construct and

send to Aa 2 a message of the form Epka 2

ðsni;b 1; Eki;b 1ðgrAa 2i;b 1 ; ‘CHILD CERT ISSUED’ÞÞ.

In this way Aa 2 knows that this particular re-

quest for an anonymous certificate resulted in

the issuing of a new child certificate, Ci;b 1, to

be associated with the parent certificate, Ci;a 2,and that the provisional child certificate alloca-

tion information is to be confirmed, i.e. Ci;b 1:

sni;b 1, ki;b 1, lei;b 1, aui;b 1 is now stored.

• For T8, Ab 1 would then need to construct and

send to Aa 1 a message of the form

Epka 1ðsni;b 1;Eki;b 1ðgrAa 1i;b 1 ; ‘NOT USED’ÞÞ. In

this way Aa 1 knows that in this particular re-

quest for an anonymous certificate there is nonew child certificate to be associated with the

parent certificate, Ci;a 1, and that the provisional

child certificate allocation information is to be

removed, i.e. Ci;b 1: sni;b 1, ki;b 1, lei;b 1, aui;b 1,

‘pending’, is now deleted.

The original issuing protocol in [6], using just

one parent certificate (primary only case), has atotal of four transactions. Our extended and

modified issuing protocol presented in Section 5.2,

using a primary and a secondary certificate (pri-

mary/secondary case), has a total of six transac-

tions, an increase of just 50%. The version of the

issuing protocol using two parent certificates of the

same weighting (primary/primary case), discussed

above, has a total of eight transactions, that isdouble or an 100% increase in the number of

transactions compared to the original protocol.

The primary/primary case protocol has further

disadvantages: it requires one parent CA to pro-

cess and store information that later transpires to

be redundant; the decision making process as to

how the User’s certificate graph develops is no

longer with the User; and the source of theEpka nðsni;b 1;Eki;b 1ðgrAa n

i;b 1 ; ‘�’ÞÞmessages, where ‘*’

denotes ‘CHILD CERT ISSUED’ or ‘NOT USED’,is not verifiable, nor may it be. We discuss each

disadvantage in turn:

• Redundant information processing and storing.

In the primary/primary case protocol each par-

ent CA, Aa n, where n 2 f1; 2g, must: look upthe expiration time, ei;a n, of the parent certifi-

cate, Ci;a n; check that Ci;a n has not been placed

on the CRL; derive the granted right


grAa ni;b 1 ¼ ððsti;b 1 ¼ sti;a n � 1Þ; ðlei;b 1 < lei;a nÞÞ;

generate and send sni;b 1, Eki;b 1ðsrAa ni;b 1Þ; store

Ci;b 1 (i.e., sni;b 1, ki;b 1, lei;b 1, aui;b 1), ‘pending’

in association with Ci;a n; and await Ab 1’s con-

firmation message before processing anotherapplication from Pi simply and only because

the decision as to which granted rights, grAa ni;b 1 ,

is to be used has not yet been made. Since only

one granted right may be used, then almost half

of the processing that is performed during this

stage of the protocol is unnecessary. Further-

more, since neither CA knows which of the

granted rights is to be used until they receivethe Epka nðsni;b 1; ki;b 1ðgrAa n

i;b 1 ; ‘�’ÞÞ message,

where ‘*’ denotes ‘CHILD CERT ISSUED’ or

‘NOT USED’, from Ab 1, they must delay pro-

cessing further applications from Pi via another

issuing CA.

• The development of Pi’s certificate graph is no

longer in Pi’s control. In the primary/primary

approach protocol, the decision as to which ofthe granted rights, grAa n

i;b 1 , is to be used, and

hence which certificate is the true parent, is

made by the issuing CA, Ab 1, not the User. This

is because Pi has not indicated which parent cer-

tificate is preferred, nor given a selection crite-

rion. Such criteria may be based on the

number of further generations allowed, sti;b 1,

or the expiration time, lei;b 1, both of whichare made available to Ab 1, via the grant rights,

grAa ni;b 1 . However, Pi may wish to obtain all pos-

sible child certificates from a particular parent

certificate first, but is not able to convey this

to Ab 1. Furthermore, for Ab 1 to offer, say, ‘par-

ent with most child certificates available’ as a

selection criteria, Ab 1 would need to receive

information pertaining to the remaining num-ber of allowable child certificates associated

with a particular parent certificate, and this

information is not made available. If this infor-

mation were made available, then every issuing

CA would have an indication of the structure of

Pi’s certificate graph, which may in turn lead to

a reduction in anonymity assurance. As the

scheme is, the fact that a child certificate is al-lowed is implied by grAa n

i;b 1 6¼ ð0; 0Þ. Ultimately,

for the issuing CA to be able to use a selection

criterion that is equivalent to that used by Pi,

the issuing CA would need to know as much

about Pi’s certificate graph as does Pi.• The source of Epka n(sni;b 1; ki;b 1ðgrAa n

i;b 1 ; ‘�’ÞÞ,where ‘*’ denotes ‘CHILD CERT ISSUED’ or

‘NOT\_USED, cannot be established. We firstexamine the reasons for this and then the secu-

rity implications. Since Ab 1 is anonymous to

the parent CAs, Aa 1 and Aa 2, (and must remain

so in order to prevent either Aa 1 or Aa 2 inferring

a link between Ci;b 1 and Ci;a 1 or Ci;a 2), Ab 1 can-

not sign ðsni;b 1;Eki;b 1ðgrAa ni;b 1 ; ‘�’ÞÞ with its pri-

vate key, skb 1. The security implication is that

this message does not posses the property ofnon-repudiation. Any one of the involved

CAs, Ab 1, Aa 1 or Aa 2 could launch a ‘denial-

of-service’ type attack on Pi by denying Pi therightful issue of further child certificates some-

time in the future. For instance, a compromised

Ab 1 may send the message Epka nðsni;b 1; Eki;b 1

ðgr Aa ni;b 1 ; ‘CHILD CERT ISSUED’ÞÞ to both Aa 1

and Aa 2 when it is Ci;a 1 that is the parent certif-icate. Pi will receive one child certificate from

this request as expected, but according to the re-

cords of Aa 1 and Aa 2, Pi has received a child cer-

tificate from each parent. The denial-of-service

will become apparent when Pi requests the ‘un-

issued’ child certificate of Ci;a 2. A compromised

parent CA may also launch a denial-of-service

attack in a similar manner by substituting the re-ceived Epka nðsni;b 1; ki;b 1ðgrAa n

i;b 1 ; ‘NOT USED’ÞÞwith their self-generated Epka nðsni;b 1; Eki;b 1

ðgrAa ni;b 1 ; ‘CHILD CERT ISSUED’ÞÞ. All invol-

ved parties are able to deny generating and send-

ing the false message.

Our protocol, the primary/secondary case, alle-

viates all these potential problems. By allowing Pito indicate from which parent certificate the gran-

ted rights are to be inherited, i.e. the primary par-

ent, Pi is able to determine how the certificate graph

is developed. Furthermore, since it is known which

is the primary certificate, only the primary parent

CA need look up sti;a n and lei;a n and store the child

certificate information to be associated with the

parent certificate; the issuing CA need not selecta granted right to be used and therefore the need

for the message Epka nðsni;b 1;Eki;b 1ðgrAa ni;b 1 ; ‘�’ÞÞ is

removed.


6.1.3. Assessment against stated design require-

ments

We now analyse our protocol presented in

Table 1 with regard to the design requirements

stated in Section 2. The anonymity of our protocolis established via the following cases. [DRnumber:name] indicates the design requirement satisfied by

each case:

• As sni;b 1 and ki;b 1 are unique to Pi and are

used by the CAs to identify a continuing

transaction, Ab 1 and Aa 1 (or Ab 1 and Aa 2)

are able to link Ci;b 1 to Ci;a 1 (or to Ci;a 2)by collusion. This problem is alleviated by

deepening the depth (increasing the number

of levels) of the certificate graph. As discussed

in [6], the certificates at the bottom of the

graph have the highest assurance of anonym-

ity. It is therefore in Pi’s interest to use a mul-

titude of CAs. In this way, multiple CAs need

to collude in order to make the associationbetween all of Pi’s certificates. DR2: customerprofiling.

• A single compromised CA is unable to link Pi’scertificates to one another or to Pi for the fol-

lowing reasons:

� Pi does not sign its request for a certificate and

the messages between Pi and Ab 1 are con-

ducted via anonymous communication chan-nels, so Ab 1 does not know the identity/

address of Pi. DR1: anonymity.� Messages from Ab 1 to Aa 1 and to Aa 2 are

conducted via anonymous communications

channels and encryption is performed using

the fresh session key ki;b 1, so neither Aa 1

nor Aa 2 know the identity/address of

Ab 1, and are therefore unable to infer alink between Ci;b 1 and Ci;a 1 or Ci;a 2.

DR1: anonymity and DR2: customer profil-ing.

� The granted rights, grAa 1i;b and grAa 2

i;b , do not

contain any information that is in Ci;a 1 or

Ci;a 2, so Ab 1 is unable to link Ci;b 1 to either

Ci;a 1 or Ci;a 2. DR1: anonymity and DR2: cus-tomer profiling.

The accountability of our protocol is estab-

lished via the following cases. [DR number: name]

indicates the design requirement satisfied by each

case:

• Any anonymous certificate can be traced back

to the parent real-identity certificates, but only

by a legal authority who collects verifiable andnon-repudiable evidence in the process (Real-

Identity Tracing is described in Section 5.3).

DR3: accountability and DR4: non-repudiation.• Pi cannot deny requesting a certificate nor claim

that a CA has either falsely issued Pi a certificateor issued a certificate to another party Pj in Pi’sname, nor can a CA deny issuing a certificate

either to Pi or to another party Pj in Pi’s namefor the following reasons:

� aui;a 1 in Xi;a 1 and aui;a 2 in Xi;a 2 are signed

with Pi’s private key ski;a 1 and ski;a 2, respec-

tively, which only Pi has knowledge of.

Should another party Pj wish to obtain a cer-

tificate in Pi’s name, Pj now has to compro-

mise at least two of Pi’s private keys in

order to obtain a certificate. DR5: authoriseduse.

� ki;b 1 in aui;a 1, aui;a 2, srAa 1i;b 1 and srAa 2

i;b1prevents

Ab 1 from modifying pki;b 1 and then passing a

copy of the certificate on to another party Pj.This is because ki;b 1 cannot be forged and

both Aa 1 and Ab 2 are passed a copy of ki;b 1

in aui;a 1 and aui;a 2, respectively, return a

copy of ki;b 1 in srAa 1i;b 1 and srAa 2

i;b 1 , respectively,and store a copy of ki;b 1 and aui;a 1 or ki;b 1

and aui;a 2, respectively. In this way Ab 1’s dis-

honesty can be proven. If Ab 1, Aa 1 and Aa 2

were to collude by, say, substituting

kj;b 1 ¼ hðAb 1, pkj;b 1, sei;b 1Þ for ki;b 1 then no

CA would be able to deny their involvement

with the deceit, unless they deleted all refer-

ences to the Certificate Issuing transactions.In that case, the Real-Identity Tracing process

would stall and LA would be forced to inves-

tigate. DR3: accountability, DR4: non-repudi-ation, and DR5: authorised use.

� grAa 1i;b 1 is encrypted with ska 1, which is Aa 1’s

signature on grAa 1i;b 1 , and grAa 2

i;b 1 is encrypted

with ska 2, which is Aa 2’s signature on

grAa 2i;b 1 , so neither CA can deny granting Ab 1

the right to issue Ci;b 1 to Pi. DR3: accountabil-ity and DR4: non-repudiation.


6.2. Trace back protocol analysis

6.2.1. Top-level assessment

We note the following general observations

about our protocol as compared to the originaltrace back protocol as described in [6]:

• The identity trace back path is no longer a sin-

gle sequential path, rather it is now a branching

sequential path. This has occurred because Pi isrequired to present two certificates from two

separate CAs. In order to hold Pi accountable,the LA must demonstrate that all certificateswere issued to Pi correctly. To achieve this,

LA must verify the entire graph from ‘abused’

certificate back to all real-identity certificates

including branches that produce apparently

redundant information (e.g. CRi;a 2 is a parent

of both Ci;b 1 and Ci;b 2).

• The branching trace back path has resulted in a

number of transaction types being repeated,resulting in an increase in total number of trans-

actions performed. The number of repetitions is

directly related to the number of parental certi-

ficates, n, and may be regarded as an overhead

compared to the original scheme [6]. This is

summarised in Table 6.

6.2.2. Assessment of our novel contribution

The structure of the Trace Back Protocol is a

direct result of using two pieces of evidence in the

Issuing Protocol, i.e. for each anonymous certifi-

cate issued there are now two trace back paths.

The benefits of requiring Pi to present two certifi-

cates and demonstrate possession of the associated

private keys in order to obtain a further child

certificate via our Issuing Protocol have been dis-cussed in Section 6.1. The existence of two trace

back paths in our Trace Back Protocol is of benefit

Table 6

Repeated transactions in trace back protocol

Stage Additional transaction repeats

STAGE 1 None

STAGE 2 ðn� 1ÞSTAGE 3 ðn2 � 1ÞSTAGE 4 ðnÞ

in quickly detecting fraudulent certificate issue by

collusion. For instance, say, Ab 1 issues a child

certificate Ci;b 1 to Pi as requested but substitutes

kj;b 1 ¼ hðAb 1, pkj;b 1, sei;b 1Þ for ki;b 1 and forwards

a forged certificate to another party, Pj. This deceitis easy to detect because kj;b 1 derived from theforged certificate is not identical to ki;b 1 stored by

Ab 1, Aa 1 and Aa 2. If, say Ab 1 and Aa 1 were to

collude by substituting kj;b 1 ¼ hðAb 1, pkj;b 1,

sei;b 1) for ki;b 1 throughout, then during the veri-

fication processes of the original trace back pro-

tocol, presented in [6], this certificate issue would,

on first inspection, appear to be legitimate. How-

ever, the verification processes in our trace backprotocol include the comparison of like-for-like

data, such as aui;b 1, held by both parents in

addition to the verification of ki;b 1, i.e. the collu-

sion is made obvious by the other parent trace

back data. This like-for-like comparison serves to

further assure the counter-fraud property, i.e.

DR5: authorised use, of our protocol.

6.2.3. Assessment against stated design require-

ments

We now analyse our protocol presented in

Table 4 with regard to the design requirements

stated in Section 2. The anonymity of our protocol

is established via the following cases. [DRnumber:name] indicates the design requirements satisfied

by each case:

• All evidences evc 2 through to and including

eva 1, eva 2 and eva 3 are encrypted with LA’s

public key pkLA , so only LA may read the evi-

dence. Furthermore, each message is encrypted

with the public key of the recipient CA and is

sent via an anonymous communication chan-nel. In this way no CA may gain any more

information about Pi’s certificate graph than

Total overhead w.r.t. original scheme

None

ðn� 1ÞEpkb xðCLA; nLA; tLA; sLA; sni;c 1; evc 1; chc 1Þðn2 � 1ÞEpkb xðCLA; nLA; tLA; sLA; sni;b x; evb x; chb xÞðnÞeva x


that which they already possess from the issuing

process, i.e. they have knowledge of the imme-

diate parent and child certificates only. DR1:anonymity and DR2: customer profiling.

• For each ‘abused’ certificate (in our example,Ci;c 2) in the sequence, LA can prove that Pi re-quested Ci;c 2 from Ac 2 using parental certifi-

cates Ci;b 1 and Ci;b 2; that Ac 2 issued Ci;c 2

using granted rights from both Ab 1 and Ab 2

and that Ac 2 issued Ci;c 2 in which the public

key pki;c 2 is correct, and the expiration time

ei;c 2 is correct with respect to the granted right

grAb 1i;c . DR3: accountability, DR4: non-repudia-

tion and DR5: authorised use.

Note that a compromised CA may disrupt the

identity trace back process by either not forward-

ing its evidence to the next CA in the sequence or

by providing incorrect evidence (including deceit

through collaboration). In this case, LA may

perform the sequence stepwise by sending each CAthe message EpkCA(CLA, Ci;CA, nLA , tLA, sLA, siLA)with instructions to send evidence directly to LA.

7. Conclusions

Our extensions to the original scheme (as de-

scribed in [6]) have increased the security of theoriginal scheme by requiring two pieces of evi-

dence (i.e. two certificates and demonstrated pos-

session of associated private keys) to be presented

in order to obtain a further certificate in the most

efficient manner. In this way, the threat of an at-

tacker falsely obtaining an anonymous certificate

by using a compromised private key has been

much reduced. The anonymity and accountabilityproperties of the original scheme (as described in

[6]) have been retained without deterioration. The

use of like-for-like verification of the two parent

certificate trace back data allows easy detection of

fraudulent certificate issue by colluding CAs. In

this way, users of our protocol suite have further

assurance against fraud. Further work includes

investigating the incorporation of partially ano-nymalised payment and delivery of tangible goods

and proposals for anonymous certificate revoca-

tion.

Acknowledgements

The first author gratefully acknowledges the

financial support given by the Department of

Computer Science, University of Manchester, UK,and the award of IEE Vodafone Scholarship.

The authors wish to thank the anonymous ref-

erees for their constructive comments and valuable

suggestions.

References

[1] D.L. Pipkin, Information Security––Protecting the Global

Enterprise, Prentice Hall, Englewood Cliffs, NJ, 2000.

[2] Technical report, Universal Mobile Telecommunications

Systems (UMTS); 3G Security; Security Threats and

Requirements, ETSI at http://www.etsi.org/, 2001.

[3] S. Tabbane, Handbook of Mobile Radio Networks, Artech

House, Boston, MA, 2000.

[4] W. Stallings, Cryptography and Network Security: Princi-

ples and Practice, third ed., Prentice Hall, Englewood

Cliffs, NJ, 1999.

[5] J.C. Graff, Cryptography and E-commerce, Wiley, New

York, 2001.

[6] N. Zhang, Q. Shi, M. Merabti, Anonymous public-key

certificates for anonymous and fair document exchange,

IEEProceedings––Communications 147 (6) (2000) 345–350.

[7] D. Chaum, Untraceable electronic mail, return addresses

and digital pseudonyms, Communications of the ACM 24

(2) (1981) 84–88.

[8] Research report, rz3295(93341), Efficient non-transferable

anonymous multi-show credential system with optional

revocation, J. Camenisch and A. Lysyanska*, IBM Zurich

Research Laboratory and *MIT, 2000.

[9] S.G. Stubblebine, P.F. Syverson, D.M. Goldschlag, Un-

linkable serial transactions: protocols and applications,

ACM Transactions on Information and System Security

2(4) (1999) 354–389.

[10] Q. Shi, B. Askwith, M. Merabti, K. Whiteley, Achieving

user privacy in mobile networks, IEE Proceedings of the

13th Annual Computer Security Applications Conference,

1997, pp. 108–116.

[11] L. Buttyan, J.P. Hubaux, Accountable anonymous access

to services in mobile communications systems, Proceedings

of the 18th IEEE Symposium on reliable Distributed

Systems, 1999, pp. 384–389.

[12] P. Lokela, Wireless Internet access using anonymous access

methods, IEEE 1999 International Workshop on Mobile

Multimedia Communications (MoMuC’99), 1999, pp. 194–

197.

[13] B. Preneel, J. Claessens, J. Vandewalle, Solutions for

anonymous communications on the Internet, Proceedings

of the IEEE 33rd Annual International Carnahan Confer-

ence on Security Technology, 1999, pp. 298–303.

http://www.etsi.org/


[14] P.F. Syverson, M.G. Reed, D.M. Goldschlag, Anonymous

connections and onion routing, IEEE Journal on Selected

Areas in Communications 16 (4) (1998) 482–494.

[15] D. Chaum, Security without identification: transaction

systems to make big brother obsolete, Communications of

the ACM 28 (10) (1985) 1030–1044.

[16] M.K. Reiter, A.D. Rubin, Crowds: anonymity for web

transactions, ACM Transactions on Information and

Systems Security 1 (1) (1998) 66–92.

[17] C. Shields, B.N. Levine, A protocol for anonymous

communication over the Internet, Proceedings of the 7th

ACM Conference on Computer and Communication

Security, 2000, pp. 33–42.

D. Critchlow CEng MIEE is a Ph.D.student at the Department of Com-puter Science, University of Manches-ter, UK. Her research area is userprivacy and accountable anonymityfor mobile e-commerce. She has 9years experience in the radio commu-nications industry. She holds aDepartmental Scholarship from theDepartment of Computer Science,University of Manchester and the IEEVodafone Award.

N. Zhang is a Lecturer at the Depart-ment of Computer Science, Universityof Manchester, UK. She received herPh.D. in Electronic Engineering fromthe University of Kent at Canterbury,UK. Her research interests includecomputer networks, mobile comput-ing, and information and e-commercesecurity. She is supervising a numberof research projects on these subjects,which are funded by various fundingsources, including the UK Engineeringand Physical Sciences ResearchCouncil (EPSRC) and Department of
Trade and Industry (DTI).

Documents

Security enhanced accountable anonymous PKI certificates for mobile e-commerce