A Secure Anonymous Authorisation Architecture for E-commerce Wai-Ki Richard Au, Kim-Kwang Raymond Choo, Mark Looi Information Security Research Centre School of Software Engineering and Data Communications Queensland University of Technology, QLD 4001, AUSTRALIA {w.au, k.choo, m.looi}@qut.edu.au

Abstract We propose a new authorisation architecture based on the extension to the anonymous authorisation framework proposed by Au et al., whereby a new entity, trustee, and a new concept, Key Binding Certificate (KBC), are introduced. In the architecture, the trustee issues a KBC to certify the association between a registered user’s unique identity and the user’s One-Task Authorisation Key (OTAK) where OTAK is used as the user’s unique identifier to preserve anonymity. More importantly, the trustee acts as an identity escrow agent to provide anonymity revocation in a well-regulated manner. Hence, any service provider is able to make authorisation decision based on the Anonymous Attribute Certificates (AACs) issued by referee servers to anonymous users with a high level of assurance. The trustee also empowers the notion of chained referral in situations where users are required to obtain AACs from various referee servers. An improved protocol is also proposed, accompanied by an outline of its security analysis.

1

Introduction

Since the Internet evolves from an academic and research network into a commercial network, more and more organisations and individuals are connecting their internal networks and computers to the Internet. As a result, mass retail electronic commerce in the Internet is born, with more traditional business and services (such as electronic banking, bill payment, gaming) being conducted and offered online over open computer and communications network. One of the security concerns with this phenomenon is granting of privileges to users to access protected resources/services via the insecure Internet in a secure manner. Traditionally, authorisation relies on

reliable user authentication. Identity-based (ID-based) access control systems employ basic mechanisms for identifying legitimate users before granting service access. However, such authorisation mechanisms do not scale well as user account management is tedious, especially for cross-domains settings. In addition, ID-based access control systems face user privacy issue, which is a barrier to the wide implementation in e-commerce. Anonymity addresses the issue of user privacy. However, from the merchant’s perspective, anonymity affects some security requirements, such as accountability, authenticity and non-repudiation. Full anonymity and unlinkability may lead to increased abuse usage by anonymous users and present an unacceptable level of security risk. Controlled anonymity is a trade off between user privacy and merchant-side security requirements. In pseudonymity systems, anonymity can be revoked in a well-regulated manner, preferably with the involvement of neutral trusted third parties. This paper proposes a new authorisation architecture to address scalability and user privacy in ID-based system. The new architecture builds on the anonymous authorisation framework proposed by Au et al. [1], and introduces a Trustee entity and a Key Binding Certificate. The Trustee provides a centralised identity management service, which includes anonymity revocation, to different entities in the e-commerce settings.

2

A Proposed Anonymous Authorisation Architecture

In this proposed architecture, we assume that an existing Public Key Infrastructure (PKI) is in place and each registered entity is issued a public/private key pair and a public key (identity) certificate. The notation introduced in Table 1 will be used throughout this paper.

Referee 2

Referee 1

Trustee 1

Web Server

Web Server

Web Server

Security Server

Security Server

Security Server

Identity Escrow policies

Identity Escrow policies

Key Binding Repository

Key Binding Repository

Web Server

Recommendation policies

Security Server Recommendation policies

Trustee n

Domain 2 te ica

Anonymity Revocation

r t if Ce ing ind yB

tri Ano bu n te ym C ou er s tif ic at e

Trustee Infrastructure

Ke

At

ous Anonym ficate Certi Attribute

Domain 3

Client Application Web Server Security Server Recommendation policies

Web Server Credential Manager Anonymous Attribute Certificate

Access Control policies

Local Domain Authority

Key Manager

Package of Anonymous Attribute Certificates

User Privacy Policies Secure Communication Protocol

Security Server Authorisation Manager Access Control policies

Authorisation Token

Resources

Service Provider

User/Client Domain 1

Domain 5

Figure 1. User-Centric Anonymous Authorisation Abbreviation U ERS APS TS AA SN QACC QREF QOTAK −1 KA , K A AACn IDCU KBCU OTAKU , OTAKU−1 {m}KU [m]K −1 U

ATn Pn

Description User/client External Referee Server Application Service Server Trustee Server Authorisation agent Serial Register Number Access request Referral request New OTAK pair request Public/private key pair of A nth Anonymous Attribute Certificate Identity Certificate of U Key Binding Certificate of U Public/private OTAK pair of U Encryption of message m with public key of U MAC digest/Signature of message m using private key of signer U nth Authorisation Token Phase n

Identity (public) key Identity (private) key Identity (public) key

Identity: e.g. Name

Identity Certificate (from Certification Authority in PKI)

OTAK 1 (public key) OTAK1 (private key)

OTAK 1 (public key)

OTAK 1 (public key)

OTAK 1 (public key)

Attributes 1

Attributes 2

Attributes 3

OTAK 1 (public key) OTAK 2 (public key)

Anonymous Attribute Certificates (from Various Referee Servers) OTAK2 (private key)

Key Binding Certificate (from Trustee)

Private keys kept confidentially by User

OTAK 2 (public key)

OTAK 2 (public key)

Attributes 4

Attributes 5

( OTAK One-Task Authorisation Key )

Figure 2. Linking Different Certificates

Table 1. Table of Notations

2.1

One-Task Authorisation Key (OTAK)

In an e-commerce environment, different merchants conduct and offer their business on the insecure Internet where access rights are granted to users in both local and foreign administrative domains. The diversity of the users ranges from corporate business partners with established strong trust relationships to potential customers without any existing established trust. For conducting B2C e-commerce and other applications securely on the Internet, views are divided on whether access control systems should focus more on

authorisation than user authentication. Research has indicated that customers prefer to remain anonymous for privacy and security reasons, yet service providers want to verify the access rights of users. To address this issue, we propose using independent cryptographic keys for authentication and authorisation. The public OTAK, instead of an identity key, is used as the unique identifier of the user in a particular task/activity. User attributes for authorisation purpose are bound to an OTAK in a Anonymous Attribute Certificate where an OTAK is bound to the identity key in a Key Binding Certificate, as illustrated in Figure 2. Consequently, the authorisation process can be separated from the

user authentication process.

2.4

2.2

The trustee is a trusted third party providing a centralised identity management service to different entities in the e-commerce settings. It is independent of any business entities (service providers or referee servers) and has four important functions at various stages of the authorisation process, as follows: (1) Generating public/private OTAK pairs and key binding certificates for requesting users, (2) Ensuring the integrity and uniqueness of OTAK for referee servers, (3) Providing identity escrow service to service providers and manages the revocation of anonymity, and (4) Empowering the notion of chained referral as discussed in Section 4. A trustee server is used to serve local users in its administrative domain. As some trustee services involve entities in foreign administrative domains, an infrastructure of domain-based trustee servers is needed so that the trustees can work collaboratively in a federation. Taking an example in the identity escrow service, a service provider can lodge the application of anonymity revocation to a local trustee. Upon approval, the request is forwarded to the designated trustee (may be in a foreign administrative domain) to provide the necessary revocation. The revoked identity information can be delivered to the service provider directly or through the local trustee in a secure channel.

Anonymous Attribute Certificate (AAC)

AACs are the referral credentials issued by various referee servers to a registered user. In real world applicationa, a user may have several existing business relationships with some commercial or governmental entities (e.g., having a credit account with a credit card company, a driving license from the transport department, and a number of memberships in various clubs). There are different business relationships among these organisations and a trust infrastructure can be formed. These external business entities can act as referee servers and provide referrals in the form of AACs to their clients upon request. When the user requests to access a resource/service anonymously, the service provider can make the authorisation decision based on the assessment on the AACs submitted by the user. While the user is identified by the OTAK public key in the AAC, the revocability of anonymity is guaranteed by the trustee, who generates a trustee signature by signing the OTAK public key with the trustee’s private signing key in the AACs. AnonymousAttCertificate ::= SEQUENCE { acinfo AnonymousAttCertInfo, signatureAlgorithm AlgorithmIdentifier, signatureValue BIT STRING } AnonymousAttCertInfo ::= SEQUENCE { version AttCertVersion , serialNumber CertificateSerialNumber, issuer AttCertIssuer, issuerUniqueID UniqueIdentifier, oneTaskAuthKey OneTaskAuthKey, attributes SEQUENCE OF Attribute, validityPeriod AttCertValidityPeriod, trustee TrusteeIdentity OPTIONAL, trusteeSignature TrusteeSignature OPTIONAL, trusteeSignAlg TrusteeAlgorithmIdentifier, extensions Extensions OPTIONAL }

2.3

Key Binding Certificate (KBC)

The key binding certificate KBCU binds the user’s public OTAK to his public identity key or another public OTAK. It is created by the trustee and its access is restricted in order to preserve the privacy and anonymity of U. The definition of a KBC is provided below. Note that the two independent cryptographic keys in a KBC can be of different ciphers and key lengths. BindCertificate ::= SEQUENCE { bcinfo BindCertInfo, signatureAlgorithm AlgorithmIdentifier, signatureValue BIT STRING } BindCertInfo ::= SEQUENCE { version BindCertVersion, serialNumber CertificateSerialNumber, trustee Trustee, trusteeUniqueID TrusteeIdentifier, firstPublicKey FirstPublicKey, firstecipherAlg AlgorithmIdentifier1, secondPublicKey SecondPublicKey, secondcipherAlg AlgorithmIdentifier2, trusteeSignature SignatureValue, trusteeSignAlg AlgorithmIdentifier }

2.5

Trustee Infrastructure

Anonymity Revocation Service

The revocation of anonymity should be authorised by a neutral trusted authority, preferable a law enforcement entity, e.g. the court, which should be external to the infrastructure for trustee systems. Since the trustee act as an identity escrow agent to implement anonymity revocation, the trustee should hold a repository of identification information with the following fields in a record, namely: an individual user’s public OTAK, identity certificate (identity key) or another public OTAK, and the expiry details. When situations require a service provider to trace the identity of the holder of an OTAK in the AACs submitted by a user, the service provider can send a tracing request to the trustee whose identity appears in the AACs. However, this tracing request needs to be accompanied by some pre-agreed documentation issued by some court or law enforcement entities. Upon satisfying all requirements in the pre-defined policy, the trustee can then reveal the binding of the OTAK and the user’s identity key/certificate under supervisions of an external legal authority. In the proposed architecture, the referee servers are prohibited from disclosing the association between

a user’s identity and the AACs issued. In a real world implementation, some legal binding agreements or legislation are required to reinforce this regulation. If referee servers collude with service providers, the user’s identity in an activity can be revealed. However, referee servers such as commercial banks, clubs, governmental organisations are unlikely to violate these regulations, considering the legal and financial implications. Furthermore, individual users have the liberty of choosing referee servers with good reputations for issuance of AACs. Hence, this anonymous authorisation architecture provides a reasonable safe environment for real world e-commerce implementation.

3

Credential-based Authorisation Protocol Revisited

In the extended authorisation protocol, the newly introduced trusted entity, Trustee, randomly generates unique public/private one-task authorisation key pairs (OTAKU ,OTAKU−1 ) for users for each new task. Consequently, the probability of two users sharing the same public/private OTAK pair is reduced significantly. This aids to prevent the colluding users attack. The protocol develops through four phases as explained below.

new OTAKU−1 and KBCU , which contains OTAKU . Using TS’s public key, U can verify the signature. If the verification returns true, then U will terminate the protocol run and accept {OTAKU , OTAKU−1 }. 1.

U −→ TS :

{IDCU , QOTAK , NU }KTS [P1 , {IDCU , QOTAK , NU }KTS ]K −1

2.

TS −→ U :

−1 {KBCU , OTAKU , NU }KU , −1 [P1 , IDCU , {KBCU , OTAKU , NU }KU ]K −1

U

TS

Phase 2. Access Request U encrypts the public OTAKU , the access request QACC and a randomly chosen nonce NU , using the public key of APS, with whom U desires to communicate, to form a ciphertext αU . U signs on αU and the phase 2 identifier with OTAKU−1 and then sends αU together with the signature to APS. Upon receiving the message, APS decrypts the ciphertext received with APS’s private key to obtain OTAKU (which is U’s unique identifier) and QACC . APS can then verify the signature to determine if the message received originates from U. Once the verification is satisfied, APS assigns an authorisation agent AA and a unique serial register number SN to U. 1.

U −→ APS :

{OTAKU , QACC , NU }KAPS , [P2 , {OTAKU , QACC , NU }KAPS ]OTAK −1

2.

APS −→ U :

{AA, SN , NU }OTAKU , [P2 , {AA, SN , NU }OTAKU ]K −1

APS

Phase 1. New OTAK Request The protocol begins when a user/client U requests for a public/private OTAK pair from the designated trustee server TS. U sends the “new OTAK pair request” QOTAK to TS, together with phase 1 identifier P1 , U’s identity certificate IDCU (which contains U’s public identity key KU ) and a randomly chosen nonce NU , encrypted using TS’s public key. The use of nonce NU ensures that an old message cannot be replayed, assuming that a player will not reuse a nonce. The use of a phase identifier P1 ensures that messages from different phases cannot be replayed, thus preventing type-flaw attacks. TS proceeds to generate a new public/private OTAK pair {OTAKU , OTAKU−1 } that has yet to been assigned, using a secure random key generator algorithm. Then TS creates a key binding certificate KBCU to associate KU with OTAKU . TS computes the ciphertext α, which is the encryption of KBCU , OTAKU−1 and the nonce NU originated from U, using the requesting client’s public key KU . Then TS signs −1 on α, P1 and IDCU using KTS . TS will then send the ciphertext α and the signature to U. Upon receiving the message, U decrypts α with KU−1 to retrieve the

U

Phase 3. Referral Requests Upon receiving the message from APS, the client U can execute the authorisation agent on the client platform. Depending on the requirements of individual service provider, U may need to request for referral credentials from one or more external referee servers. If U need to request for referral credentials from n external referee servers, the protocol shown below is executed n times. 1.

U −→ ERS :

{IDCU , KBCU , QREF , NU }KERS , [P3 , {IDCU , KBCU , QREF , NU }KERS ]OTAK −1

2.

ERS −→ U :

{AAC , NU }OTAKU , [P3 , U , {AAC , NU }OTAKU ]K −1

U

ERS

Phase 4. Authorisation Decision Once U has collected the required referral credentials, U will send these referral credentials to APS. Based on the submitted referral credentials {AAC1 , . . . , AACn }KAPS , the service provider will reach a decision on whether to grant the authorisation token AT1 .

1.

U −→ APS :

{OTAKU , AAC1 , . . . , AACn , SN , NU }KAPS , [P4 , {OTAKU , AAC1 , . . . , AACn , SN , NU }KAPS ]OTAK −1

2.

APS −→ U :

{AT1 }OTAKU , [P4 , SN , NU , {AT1 }OTAKU ]K −1

U

APS

With the authorisation token, U is then able to request for service on the designated application server.

4

Trustee and Chained Referral

Different referral servers have different methods to assess the user requesting a referral. Some identity-based servers require authentication of legitimate users making use of identity certificates or username/passwords, and then refer to the user account/profiles stored in local repositories. Alternatively, the assessment can be based on some third-party anonymous attribute certificates submitted by the user. In this proposed architecture, the trustee empowers the mechanism of chained referrals by providing key binding certificates to chain up the one-task authorisation keys. It acts as a centralised agent to manage the revocation of anonymity in the chain of anonymous attribute certificates. We consider two different possible scenarios where chained referral can be deployed, anonymous chained referral and chained referral with user authentication.

4.1

U −→ ERS :

{OTAKUNew , KBCOTAKU , AAC1 , . . . , AACn , QREF , NU }KERS , [P3 , {OTAKUNew , KBCOTAKU , AAC1 , . . . , AACn , QREF , NU }KERS ]OTAK −1 UNew

4.2

Chained Referral with User Authentication

In certain applications, the referee server ERS may need to authenticate the requesting user U before granting a chained referral credential. If the user identity key is used for authentication, the requesting user U need to obtain a new pair of } and a key binding certificate {OTAKUNew , OTAKU−1 New KBCU binding KU and OTAKUNew . The user also requests another key binding certificate KBCOTAKU binding OTAKU and OTAKUNew . In phase 3 of the protocol, U submits IDCU , KBCU , KBCOTAKU , the anonymous attribute certificates AAC1 , . . . , AACn , the referral request information QREF and a nonce to ERS.

Anonymous Chained Referral

In this scenario, the referee servers only use the available information in the anonymous attribute certificates submitted by the requesting user without revealing the user identity. Either a new or original OTAK may be used as the identifier of the new AAC as explained below.

U −→ ERS :

{IDCU , KBCU , KBCOTAKU , AAC1 , . . . , AACn , QREF , NU }KERS , [P3 , {IDCU , KBCU , KBCOTAKU , AAC1 , . . . , AACn , QREF , NU }KERS ]OTAK −1

UNew

4.3

Reusing original OTAK The requesting user U reuses an existing OTAKU as the unique identifier for the new anonymous attribute certificate. Then both the old and new anonymous attribute certificates are bound to the same OTAKU . In phase 3 of the protocol, U submits QREF together with AAC1 , . . . , AACn and his signature using OTAKU−1 to the designated referral server ERS. U −→ ERS :

binding certificate KBCOTAKU to bind OTAKU and OTAKUNew , the trustee traces all the key binding certificates along the chain up to the user’s identity certificate using the common OTAKs. The chain of certificates becomes a link between the new OTAKUNew and the user’s identity key, and is crucial for anonymity revocation. In phase 3 of the protocol, U submits QREF , KBCOTAKU together with AAC1 , . . . , AACn to ERS. and his signature generated with OTAKU−1 New OTAKUNew will be used as the identifier in the new anonymous attribute certificate.

{OTAKU , AAC1 , . . . , AACn , QREF , NU }KERS , [P3 , {OTAKU , AAC1 , . . . , AACn , QREF , NU }KERS ]OTAK −1

Personal Tree of Authorisation Keys

Conceptually, the one-task authorisation keys of a certain user are used independently. However, due to the relationship of the anonymous attribute certificates in a chained referral, two OTAKs can be correlated by the KBC . Thus, it is possible to have the OTAKs for a user to be organised in a hierarchical or other structure (e.g., a tree as shown in Figure 3). A personal key manager can be developed to manage the usage of one-task authorisation keys efficiently with high privacy.

U

5 Creating a new OTAK Alternatively, U may } request for a new OTAK pair {OTAKUNew , OTAKU−1 New from the trustee. Before creating a new key

Security Analysis

Fundamentally, each phase of the credential-based authorisation protocol can be regarded as a key

and a signature consisting of the earlier encryption with some other messages under the sender’s private key. Again, A is not able to decrypt the intercepted message without knowledge of the corresponding OTAKU−1 .

User

OTAK21

B

C

4

OTAK3

OTAK4

6 KBC

OTAK2

KBC 5

OTAK1

K

KBC7

1

C

B

K

3 KBC

KBC 2

Identity Key

OTAK22

OTAK41

OTAK - One-Task Authorisation Key KBC - Key Binding Certificate

Figure 3. Personal Tree of Keys transport protocol, where one principal chooses a session key (i.e. a public/private OTAK pair, or some message) and securely transports it to another designated principal. The primitives used in the authorisation protocol are the (relatively standard) notions of a secure encryption scheme and a secure message authentication scheme. The improved credential-based authorisation protocol is a secure key transport protocol if the underlying message authentication scheme is secure in the sense of existential unforgeability under adaptive chosen-message attack and the underlying encryption scheme is indistinguishable under chosen-plaintext attack. We provide a brief outline of the protocol’s security analysis as below. Replay and Substitution Attacks Since a randomly chosen (fresh) nonce NU is included in every message (either in the encryption or signature) that is sent by the client U, old messages cannot be replayed. If a malicious adversary A substitutes the message with an old message, U will detect this attack in the reply message it receives as the nonce from U is included in the reply message. Alternatively, time-stamps can be also used (instead of a nonce). Hence, the improved protocol is secure against replay and substitution attacks. Impersonation and Man-in-the-Middle Attacks Messages originated from the client U is always encrypted with the public key of the designated recipient. Although a malicious adversary A can intercept and/or replace the intercepted message with other message of her choice, A is not able to decrypt the intercepted message without knowledge of the corresponding private key. Messages sent to U consist of an encryption of some messages under U’s OTAKU ,

Type Flaw Attacks As the design of protocols is often at an abstract level, vulnerabilities such as type flaw attacks arising at lower levels are often overlooked. Type flaw errors are implementation-dependent attacks resulting from misinterpretation of the bit strings used to encode messages. In the improved protocol, the phase number inclusion (e.g., Pphase number ) is included in messages to prevent a malicious adversary from exploiting type flaw attacks. Colluding Service Provider Attacks If different service providers collude, they can link the AACs using the same OTAK. However, the identity of the user is preserved (i.e., not revealed or leaked) since neither the key binding certificate nor the identity key certificate are sent in the messages by an individual user to the service providers. Hence, the improved protocol is secure and provides user privacy even if service providers collude. Since the trustee is tasked with issuing unique OTAK pairs for every individual task (requested by the registered user), the OTAK pair is unlinkable with previous activities.

6

Conclusion and Future Work

We have proposed a new anonymous authorisation architecture, which facilitates user privacy and provides a higher level of assurance to service providers in the authorisation services. The introduction of a trustee provides a centralised identity management services (including anonymity revocation) to various entities, and empowers the notion of chained referral. Further directions for this work include formally analysing the improved protocol using either the formal specification or the computational complexity approach, the implementation of the architecture in a controlled test environment, and extending the infrastructure of the trustee for a more practical deployment in today’s e-commerce settings.

References [1] R. Au, H. Vasanta, K. Choo, and M. Looi. A User-Centric Anonymous Authorisation Framework in E-commerce Environment. In Proceedings of International Conference on Electronic Commerce (ICEC’ 04), 2004.