Private Pseudonym Retrieval with Controlled Traceability

추적 가능한 가명 은밀 획득 프로토콜

Abstract

Pseudonyms must be maintained anonymously even to the organization that issues the pseudonyms, but when some event occurs that policy defines the real identity for the pseudonym must be able to be traced. We propose a private pseudonym retrieval protocol with controlled traceability using m-out-of-n oblivious transfer and cut-and-choose technique.

가명을 이용한 시스템에서는 가명을 발급한 기관에게도 사용자의 익명성이 유지되어야 하며, 다만 정책적으로 사용자가 규칙을 어겼을 때는 가명으로부터 사용자의 신원정보를 추적할 수 있어야 한다. 이 논문에서는 m--out-of-n oblivious transfer와 cut-and-choose 기술을 이용하여 추적 가능한 가명 은닉 획득 프로토콜을 제안한다.

Ⅰ. Introduction

Most researches on pseudonym have focused on the unlinkability among pseudonyms in credential transfer, but our concern is a method to issue/retrieve pseudonyms privately with conditional traceability (3)(4)⑹⑺⑼ By "privately”, we mean that even under inevitable exposure of implicit information about user's identity, user can obtain its pseudonyms without letting authorities know which pseudonyms that it will use in future transactions. In the conditional traceability setting, cooperation of pseudonym issuing authorities must enable judicial authority “trace" user's identity from the pseudonym when some "condition" is satisfied that policy defines. By accompanying a key with a pseudonym, user can prove its ownership of the pseudonym using an authentication protocol. Our contribution can be summarized as following:

(1) We provide a new direction to design a pseudonym system using oblivious transfer that has not been used in accessing with pseudonyms.

(2) Using our pseudonym retrieval protocol as a primitive building block, more advanced protocols and systems requiring controlled anonymity can be developed. We show its applications in section 5.

Fig. 1 Overview of Private Pseudonym Retrieval Protocol

Ⅱ. Overview of Our Protocol

A private pseudonym retrieval protocol must achieve the following goals when a user is issued a pseudonym from a service provider-

(1) User must authenticate itself by real identity both to Service Provider and to Judicial authority when it is issued a pseudonym.

(2) Neither Service Provider nor Judicial authority can link a pseudonym with user's identity.

(3) If Judicial authority obtains specific information of user from Service Provider, it can trace user's real identity from the pseudonym concerned.

Our private pseudonym retrieval(PPR) protocol is mainly based on m-out-of-n oblivious transfer(or equivalently symmetric private information retrieval) and cut and choose technique.Assume the following scenario: At the enrollment stage, user authenticates him both to judicial authority and to service provider with its real identity using some security token such as certificates. Interacting with ju 由 cial authority and service provider, user obtains a pseudonym and its corresponding authentication key pair without letting them know which pseudonym it has taken. At service provider, user would like to act as an entity with some pseudonyms and its corresponding authentication keys. Here, even service provider cannot link pseudonyms with the real identity that was used at enrollment stage. However, when some event occurs that policy defines, service provider would like to accuse him of violation and to punish him. At this stage, judicial authority will involve to identify him by combining its own information obtained at the enrollment stage and the information submitted by service provider. After identifying the misbehaving user, j나dicial authority can punish him without letting service provider know the real identity.

To construct this private pseudonym retrieval protocol with controlled traceability, user authenticates himself both to judicial authority and to service provider using its certificate. (1) After establishing secure channels both with judicial authority and service provider, user retrieves candidate indices of pseudonyms of service provider. (2) User fetches (pseudonym, authentication key) pairs of candidate indices from service provider using m-out-of-n oblivious transfer. (3) User sends proof that it correctly fetches pseudonyms with candidate indices to judicial authority with blinded cut-and- choose technique. (4) Judicial authority checks the validity of proof to service provider. If valid, then judicial authority sends OK both to user and to service provider. Both at judicial authority and at service provider, all rest except one chosen blob(here, a pseudonym) must be marked as "used". (5) User now can use one remaining blob chosen as his pseudonym with its corresponding authentication key.

Ⅲ. Private Pseudonym Retrieval Protocol

3.1. Setup

Service provider prepares pseudonym pool vl: (p/DvV 如J, v2:(pIDV2, kV2)--- 히 1:(0刀g, 如“), where vi is an index for the pair, pIDvl and kvl are a pseudonym ane its corresponding authentication key with index vi, respectively.

Judicial authority prepares index pool (vl> unusede (u2, unused)(m, unused)- Player M authenticates himself both to judicial authority and to service provider and establishes secure channel with each authority using some security token and certificates.

3.2. Protocol action

(1) JA 7 m: JA randomly chooses an index list L= 332, …where indices in the index list must be ''unused, and send it to M.

(2) M «스 SP: M performs m-out-oFn oblivious transfer against SP to fetch m pseudonym pairs [侦纠i, 幻J, (①ID物虹私 kvm)] that have the same indices in L. We can use the oblivious transfer protocol in [10L

(3) M — JA: Player sends [(M, 晶(肉江)), (必 瓦(如2)), …, (m, 电您血))]to JA, where bi is a key to encrypt kvi.

(4) JA M: JA chooses randomly m-1 indices and requests decryption keys of those of M.

(5) M -스 JA: M sends blob decryption key to JA. [6p 62,

(6) JA 스% SP- JA decrypts the blobs to validate by providing service provider [(讥, 如), (源, 幻J, …, (幻顶-1, 她—J, (侦+L 幻顶-口), …(vn, kvm)] list. Then, SP checks the validity of the index and the key pairs, and sends back its result to JA. Note that JA cannot know neither m~th pseudonym nor its authentication key.

(7) JA — M, SP: If all are valid, then JA sends OK both to SP and to M. SP will delete or mark "used" the m-1 entries and JA store (M, 祈)pair in its storage. Also JA must convert the m indices into "used If not, it sends ABORT to both of them. SP must delete or mark "used" the m entries known to M. Mismatch occurs because M fetches the different entries from what JA forces to choose. If mismatches occur p times, JA is able to find exactly m entries from M by asking M m correct pseudonym and key pairs.

(8) Player M can now play as pIDve with the corresponding authentication key kVj with service provider.

Ⅳ. Security and Extension

SP cannot find out which pseudonym a user has because of oblivious transfer and cut and choose. Without cut and choose, SP can guess which pseudonym the connecting user fetches because JA requests validity of some index when the user is connecting. However, by applying cut and choose here, SP is not able to know the remaining pseudonym index. Also, JA does have only an index of pseudonym for the user, and thus, it cannot link pseudonym with user's identity.

If some event occurs that policy defines, SP sends corresponding user's (vi, pIDvi) pair to JA. JA then is able to match an entry with (M, m) in its database. Even in this case, SP is not able to know who really violates rules.

Instead of revealing m-1 blobs, we can modify our protocol to reveal m-alpha blobs in the cut and choose stage. By doing so, user can get alpha pseudonyms, which is useful when a limited unlinkability (within alpha pseudonyms) must be maintained. However, revealing smaller part of blobs means that user has more probability to cheat by fetching different pseudonyms from those indexed by JA. To be safe from this reduction of blob opening, m also must be chosen larger . proportionally. The probability that user succeeds to hide its choosing of a pseudonym that is not indexed by JA is

#

Thus, sufficiently large m corresponding to alpha must be chosen considering the overhead of communication and security. Blobs in cut and choose stage are data that are hidden from JA, but actually it does not need to be hidden from JA because only the index and its authentication key for some pseudonym does not give any information that might be abused to JA. However, the authentication key for some identity(here, pseudonym) is usually known only to its owner, and so is our protocol.

Ⅴ. Applications

Persistent anonymity requires both impossibility of identity-pseudonym mapping and consistent use of a pseudonym. Thus, applications requiring the . persistent anonymity are fit to . our PPR protocol. Refer to (1) for more applications with detailed analysis requiring anonymity. Anonymous auction, anonymous email and anonymous publication are examples of applications requiring persistent anonymity. Besides those, followings are the main target of application of our PPR protocol.

(1) Anonymous certificate issuing

Very practical approaches to anonymous certiflcates/credentials without unlinkability have been suggested by〔2〕and〔8〕. Our scheme can be used to issue anonymous certificates/credentials while providing controlled traceability. After user obtains pseudonym with our PPR protocol, using the pseudonym, he can request to issue a certificate for his public key and the pseudonym to Certificate Authority. Here, the role of service provider can be transferred either to Registration Authority or to Certificate Authority. Certificates obtained in this way are- persistently anonymous, but at the time of violation, it can be used to trace its user's identity by judicial authority.

(2) Anonymous BBS

Many Internet BBS attracts people by their allowance of anonymity, but freedom of expression is sometimes abused. Thus, some extent of restriction is required. Our PPR protocol can play a role in anonymous BBS by issuing user a pseudonym. Violation of a regulation and a law at the BBS will cause involvement of judicial authority that is able to trace user's identity by the aid of BBS operator.

(3) Anonymous consult!ng/counseling

Medical or business consulting sometimes requires anonymity, but the history of consulting must be maintained by consultant. Also, in emergency case, the identity of consulter must be able to be revealed.

Ⅵ. Conclution

We presented a method to retrieve privately a pseudonym from pseudonym pool. The protocol presents also the tracing algorithm for the pseudonym concerned. Our scheme has versatility in that it is applicable to various applications that require persistent anonymity such as anonymous certificate issuing, anonymous BBS, anonymous consulting. In our work, no special structure for pseudonyms is defined, but a pseudonym is just a random number. Therefore, we believe that our private pseudonym retrieval protocol can be incorporated into other anonymous credential systems supporting unlinkability for enhancing user's privacy.

*이 논문은 2004년도 한국학술진흥재단의 지원에 의하여 연구되었음 (KRF-2004-015-D00389)