Anonymous Authentication Scheme for XML Security Standard with Refreshable Tokens Rie Shigetomi
Akira Otsuka
Hideki Imai
Institute of Industrial Science University of Tokyo 4-6-1 Komaba Meguro Tokyo, 153-8505 JAPAN
Information-technology Promotion Agency, Japan Bunkyo Green Court center office 16 floor 2-28-8, Hon-Komagome, Bunkyo Tokyo, 113-6591 JAPAN
Institute of Industrial Science University of Tokyo 4-6-1 Komaba Meguro Tokyo, 153-8505 JAPAN
[email protected]
[email protected]
[email protected]
ABSTRACT
1.
Anonymity is a highly desired feature in Internet transactions. On the other hand, unconditional anonymity may contain some traps. For instance, it may cause irresponsible, or even criminal, use of the Internet. Thus, it would be desirable to have revocable anonymity in our internet applications. In this work, we suggest an anonymous authentication scheme for WS-Security. Our scheme assures the user’s anonymity but the server can check, and even reject without unveiling the user’s identification the user’s right for accessing a specific service. The main tools which we use to achieve our rejectable anonymous protocols are ”Refreshable Tokens”. Our scheme does not require any active trusted third party in contrast to previous works in the literature. However, in situations where the identity of a user suspect of malicious act is required, the server could be easily to deny the user’s service.
Recently, paper based transactions are being rapidly replaced by digitized transactions. To encourage smooth data transaction, the format of these kind of digitized information is standardized. To meet the demands of secure data transmission on HTTP based protocols, Web Service Security (WS Security) was standardized by IBM, Microsoft and VeriSign. Authentication is a vital part of WS-Security. However, no attention was paid to the issue of anonymity of the users in the authentication protocols of WS-Security. WS-Security is a standard for transactions between two people, providing ways to protect the data by encryption and authentication[1]. It easy to see this is vital to digital transaction, but this also leads to another problem – privacy problem. More and more consideration has been shown on privacy problem, as the use of digitized information has become more and more of the part of our everyday life[7][8]. We suggest an anonymous authentication scheme for WSSecurity. This scheme assures the user’s anonymity but still allows the server to check the user’s right to access a specific service. Moreover, we also introduce a scheme for rejecting the anonymity of users which may have conducted illicit acts. We use a tool called ”Refreshable Tokens” to achieve rejectable any malicious user for the WS-Security[10]. The main ”spirit” of refreshable tokens can be summarized as follows:
Categories and Subject Descriptors C.2.0 [Computer-communication networks]: GeneralSecurity and protextion; D.4.6 [Oparating Systems]: Security and Protection—Authentication, Cryptographic Controls
General Terms Information Security
INTRODUCTION
1. Before using a certain service provided by an organization, a user ask for a refreshable token.
Keywords
2. The token grants to the user the right to use its services for a limited number of times
XML, Privacy Protection, Credential System, Anonymity
3. When a token cannot be used anymore, a user can refresh it anonymously. Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. ACM Workshop on XML Security, October 31, 2003, Fairfax VA, USA. Copyright 2003 ACM 1-58113-777-X/03/0010 ...$5.00.
86
4. When a token is used more times than its limit permits, the identity of the user is unveiled – this is so even if the token is already refreshed. 5. Any malicious behavior of an user becomes associated with its token, thus rejecting it from being refreshed.
Thus, it easy to see that refreshable tokens are a very powerful tool to control the number of times a user has access to a certain service and/or the number of transactions of a user while still granting certain anonymity. In our scheme, a cheating user can act maliciously at most once, since it will never have its token refreshed anymore. In schemes where the identity of the user who performed a malicious act is required, a trusted third party could be easily introduced to judge whether the user’s anonymity should be unveiled or not. Potentially, refreshable tokens seem to have many applications.
1.1
Related Work
Our suggestion is similar to Kerberos, which is a network authentication protocol. When a client access Kerberos, she needs a ”certified ticket” which is granted by a trusted authority. This ticket can not be forged due to cryptographic assumptions used in the Kerberos system [9]. However, Kerberos ticket includes the client’s identification, so the server can trace what the client does. Although there are a lot of approaches for achieving anonymous credential schemes, most of them demand users to obtain credentials from organizations and them demonstrate possession of these credentials. Such systems are anonymous in a sense that two transactions carried out by the same user cannot be related[4][5][6]. However, these schemes need “Challenge and Response”, so, their authentication protocols require multiple exchanges of messages. WS-Security does not support multiple exchanges of messages, so these schemes could not be incorporated into it. Our scheme does not require multiple exchanges on authentication. For the authentication of the token, all the user has to do is to send a token set with the user’s message. But, when refreshing the token, our scheme does require multiple exchanges, so we show the protocol into SOAP[2]. For most services which use XML and WS-Security, authentication is the most important part, and refreshing is done independently, thus it does not represent a burden to the overall process. Also, WS-Security supports a Security Token to be used for multiple organizations. Refreshable Tokens can be used in these kinds of situations as well.
1.2
2.1
Security Definition
Next, we will define Unlinkability, Unforgeability, Double use traceability and Refreshability. If a scheme satisfies Unlinkability, Unforgeability, Double use traceability, then the scheme is called “Refreshable Tokens Scheme”. “Refreshable Token Scheme” is in basic a two-party protocol between a user, Alice, and an organization, Bob. The scheme is comprised of the following a six procedures: Definition 1. (Refreshable Token Scheme) Key Generation On input a security parameter l, this probabilistic algorithm outputs the initial group public key Y (including all system parameters) and the secret key S for Bob. Setup A protocol for the user Alice who wants a entry for the service from Bob. A probablistic polynomial-time algorithm on input Y, for Alice outputs inf ou0 which is Alice’s information, and msg0 which is a message for getting first token. inf ou is only used by Alice and could be same as inf ou0 . Refresh A probabilistic polynomial-time algorithm that takes msgi , Y and , S which is known only by Alice, outputs (msgj , σj ) for a new token. refresh oracle when queried with msgi , inf ou and Y, answers with Refresh(msgi , inf ou , Y). Verify A probabilistic polynomial-time algorithm that on inputs (msgj , σj ) outputs valid or invalid. Present A probabilistic polynomial-time algorithm that on inputs (msgj , σj ) outputs rj . Trace A polynomial time algorithm that on inputs (msgj , σj ) and (rj1 , rj2 ) outputs inf ou0 .
Our Contribution
We show how to incorporate an anonymous authenticating scheme into WS-Security and a getting token scheme into SOAP[2]. The scheme we use allows maliciously acting users to be denied to access this service. When the identity of malicious users has to be revealed, a trusted third party can be easily introduced to both judge malicious acts and to actually revile the identity.
1.3
“Refreshable Tokens” is a expansion of previous off-line electronic cash scheme. The difference is that a coin includes the privacy information of the user, which is a key to the user’s identification, and after refreshing, the user can get a different coin which includes the same privacy information. This privacy information promises that anybody can compute the user’s identification from a double usage of the same coin.
Outline of Paper
Definition 2. (Security Definition for Refreshable Tokens) Unlinkability No one decide whether two different tokens are related to the same user. Given (msga , σa ) and (msgb , σb ), it is computationally infeasible for an probabilistic polynomial time adversary A to decide whether there exists same information inf ou who engaged (msga , σa ) and (msgb , σb ).
This paper is organized as follows: we will show preliminaries – Refreshable Token in section 2, XML Protocol in section 3, Applications in section 4, and conclusion respectively.
Unforgeability Given polynomial l tokens, it is computationally infeasible for an probabilistic polynomial-time adversary A to prepare l + 1 tokens.
2.
Double use traceability The organization can compute the identification of the user when same token is doubleused. Given (msgk , σk ) if the user used this token twice, the user is efficiency unveiled for who has polynomial time computer.
PRELIMINARIES – REFRESHABLE TOKEN Next, we will show what “Refreshable Token” is[10].
87
Token Present Bob Public: g, z = g x Private: x
Alice Private: A, . . . . . . . . . .a. . . b. . . m . . . . n. . . .a. . .b. . . . . . . . . . . . . . . . . . . . . . . . . . (g , g¾ , g , g , z , z , w1 , w2 , w3 , d)
check the sign choose α ∈R Zq
α
¾
computes β1 = aα + m, β2 = bα + n
β1 , β 2
verify g β1 = (g a )α (g m ), g β2 = (g b )α (g n )
Figure 1: Token Present We will discuss the security definitions from two aspects. That is the refresh-aspect and the parallel-aspect. A single user is permitted to hold and use multiple tokens at the same time for a single service. We call this the parallelaspect of “Refreshable Tokens”, because the user could be provided services parallel. This aspect has been also the part of electronic cash schemes, and has been well discussed. When a token is refreshed, the value infou is passed on to the next token. We call this the refresh-aspect of “Refreshable Tokens”, as not only it is special to “Refreshable Tokens” but also this could lead to feasibility for incorrect protocols.
Suppose Bob has a public key g, z = g x and the corresponding secret key x. Bob randomly choose a and calculates b (ab = A mod q). Then Bob signs token ready for Token Refresh.
2.2
2.2.2
Anonymous Token Refresh Protocol
In this section, we will show the complete protocol of Anonymous Token Refresh. We consider 2 types of entities, Alice(a user) and Bob(an organization). Let G = hgi be a cyclic group generated by g of order q = #G. Suppose that we have x1 , x2 , x3 ∈ G and y1 , y2 , y3 = xr1 , xr2 , xr3 , where r is chosen randomly and uniformly from Zq . Then, a tuple (y1 , y2 , y3 ) is called a blinding of (x1 , x2 , x3 ). The relation between (x1 , x2 , x3 , y1 , y2 , y3 ) and (x1 , x2 , x3 , r1 , r2 , r3 ) is indistinguishable from that of (x1 , x2 , x3 ) and random tuples as far as DDH assumption holds. Next, we assume that for a user with identity A (say, account number of the user), a token is in the form (x, xa , xb , xm , xn , Sig(x|xa |xb |xm |xn )), where a is randomly chosen from Zq and b is determined to satisfy ab = A. This forms a variant of 2-out-of-2 Feldman VSS with a polynomial f (t) = mt + a, g(t) = nt + b and a secret a = f (0),b = g(0). From DH assumption, it is infeasible to compute xab from x, xa , xb , therefore to determine the secret, one must need at least two values on the polynomial f (t), g(t). On the other hand, it is easy to prove in Zero-Knowledge that for a given identity A, whether a tuple, (x, xa , xb ), satisfies the relation g A = g ab . We can show the proof is equivalent to prove (g, g a , g b , g A ) to be a DH tuple.
Token Generation – RT generation When Alice is provided a service from Bob, she needs the first token issued by Bob for transaction from Bob.
2.2.1
88
1. Bob makes token including signature: (g a , g b , g m , g n , z a , z b , w1 , w2 , w3 , d). 2. Alice accepts the token if g d = z c w1 , (g a )d = (z a )c w2 and (g b )d = (z b )c w3 hold. 3. Then, Alice proceeds Token Refresh for getting a new anonymous token.
Token Present – RT present When Alice wants to start a service from Bob, she gives her token to Bob. Let M be a message to Bob from Alice. 1. Given a message M , Alice calculate α = H(M ). H is a hash function. 2. Given a token (g a , g b , g m , g n , z a , z b , w1 , w2 , w3 , d), and, β1 = mα + a and β2 = nα + b, she simply sends all of them to Bob. 3. Bob accepts the token if the signature is corret and g β1 = (g a )(g m )α and g β2 = (g b )(g n )α .
2.2.3 Anonymous Refresh – RT refresh When Alice finishes her transaction, Alice need a new token from Bob. 1. Given a token (g a ,g b ,g m ,g n ,z a ,z b ,w1 ,w2 ,w3 ,d), Alice simply gives the token to Bob. 2. Alice randomly chooses a0 ∈ Zq∗ , and computes b0 = A/a0 mod q where A is her identity. Furthermore, she 0 0 0 0 blinds (g, g a , g b ) to (y1 0 , y2 0 , y3 0 ) = (g r , g a r , g b r ) ∗ using randomly chosen r ∈ Zq . Then She sends (y1 0 , y2 0 , y3 0 ) to Bob. 3. Alice proves in Zero-Knowledge proof of the equality of DH exponent that (g a , g b , (g a )r , (g b )r ) is a DH tuple, 0 0 and that ((g a )r , (g b )r , (g a )r , (g b )r ) is a DH-PRODUCT.
Token Refresh Bob Public: g, z = g x Private: x
Alice
Private: A, .b. . .m . . . .n. . . a. . . .b. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . (g , g¾, g , g , z , z , w1 , w2 , w3 , d) a
(g ¾ jointly computes
ar 0
0
0 0
, g br ), (g a 0
0
r
0 0
, gb r ) 0 0
0 0
ar br a r b r ZKP ¾ (g , g ), (g , g- )
signature scheme 0 0 0w 0 0w y30w choose w ∈R Zq w1 = y1 , w2 = y2 , w3 =-
c0 = c/u d = c0 x + w
¾
0
choose a0 , m0 , n0 ∈R Zq compute b0 = a0 /A mod q choose r0 ∈R Zq jointly computes
choose m0 , n0 ∈R Zq 1 1 computes ww1 = (w10u y10v ) r , ww2 = (w20u y20v ) r 1 ww3 = (w30u y30v ) r computes 0 0 0 0 0 0 c = H(g a |g b |g m |g n |z a |z b |ww1 |ww2 |ww3 )
verify 0 0 0 0 y10d = (z r )c w10 , y20d = (z ar )c w20 0 0 y30d = (z br )c w30 dd = d0 u + v Token 0 0 0 0 0 0 (g a ,g b ,g m ,g n ,z a ,z b ,ww1 ,ww2 ,ww3 ,dd)
Figure 2: Token Refresh 0
0
4. If Bob is convinced, then he signs on (g a )r , (g b )r blindly using Schnorr signature[3] as follows: (a) Bob randomly chooses w ∈ Zq∗ , and sends w10 = y10w , w20 = y20w and w30 = y30w to Alice. (b) Alice randomly chooses u, v ∈ Zq∗ , and she com1 1 putes ww1 = (w10u y10v ) r , ww2 = (w20u y20v ) r and 1 ww3 = (w30u y30v ) r . (c) Alice randomly chooses m0 , n0 ∈ Zq and computes 0 0 0 0 c = H(g a |g b |g m |g n | a0 b0 z |z |ww1 |ww2 |ww3 ) and sends c0 = c/u mod q to Bob. (d) Bob replies to Alice with d0 = c0 x + w. 0
0
(e) Alice accepts the signature if y10d = (z r )c w10 , 0 0 0 0 y20d = (z ar )c w20 and y30d = (z br )c w30 hold. (f) Alice unblinds dd = d0 u + v mod q, then the re0 0 0 0 0 0 sulting token is (g a ,g b ,g m ,g n ,z a ,z b ,ww1 ,ww2 , ww3 ,dd). 0
0
Note that g dd = z c (ww1 ), (g a )dd = (z a )c (ww2 ) 0 0 and (g b )dd = (z b )c (ww3 ) hold.
89
2.2.4 Revoke – RT revoke If Alice double-spends a token, Alice’s identity should unveiled, named. In this case, Bob holds two challenges (α = H(M ), β1 , β2 ) and (α0 , β10 , β20 ). 0 0 β1 −β1 β2 −β2 Bob can compute, a = β1 − α−α 0 α and b = β2 − α−α0 α Hence, Bob can get A = ab, the User Identify of Alice.
3.
XML PROTOCOL
Next, we show “Refreshability of Tokens” on XML protocol which RT Refresh is on SOAP and RT Present is on Web Service. We use the following conventions: • SND = send data • CAL = calculate values, and take the moduler p of the results when not otherwise noticed • RCV = receive data • GEN = generate a random value • CHK = check the validity of number (if the number is invalid, return error) • SVE = save data
3.1
¶
Refresh Protocol
... alpha1 ... alpha6 beta1 ... beta6 g^a g^b ....
We show the XML protocol on SOAP for RT Refresh of section 2.2.3.
3.1.1
Client Protocol
If a client needs a new token, then the client has to proceed refresh protocol. The client has got g, A (= id), z and old token ti = (g a , g b , g m , g n , z a , z b , w1 , w2 , w3 , d). The client does the following: 1. GEN a0 r0 2. CAL b0 = A/a0 mod q 0
3. CAL yd1 = g r , yd2 = g r
0 0
a
, yd3 = g r
0 0
b
, yd4 = g r
0
³
A
µ
4. SND (to the server)
¶
´
³ 8. RCV (from the server)
yd1 yd2 yd3 yd4
¶
µ
´
5. RCV (from the server)
¶
³
... alpha1 alpha2 alpha3 alpha4 alpha5 alpha6
³
... ... ... ... wd1 wd2 wd3
µ
´
9. GEN u, v, m, n(rand) 10. CAL w1 = (wd1u yd1v )1/r , w2 = (wd2u yd2v )1/r , w3 = (wd3u yd3v )1/r
µ
´
0
0
0
6. CAL β1 = α1r b , β2 = α2r a , β3 = α3b , β4 = α4a , 0 0 β5 = α5a , β6 = α6b
12. CAL c = H(ga|gb|gm|gn|za|zb|w1|w2|w3)
7. SND (to the server)
14. SND (to the server)
0
0
0
0
90
0
11. CAL ga = g a , gb = g b , gm = g m , gn = g n , za = 0 0 z a , zb = z b
13. CAL cd = c/u mod q
¶
³
... ... ... ... ... cd
¶
³ ....
µ
´
5. RCV (from the client)
¶
³ ....
µ
´
6. CHK searching whether ti has already marked in refreshed tokens 0
µ
´
0
0
0
0
0
7. CHK β1 == (g r A )α1 , β2 == (g r A )α2 , β3 == (g r A )α3 , 0 0 0 0 0 0 0 0 β4 == (g r A )α4 , β5 == (g r a )α5 , β6 == (g r b )α6 8. GEN w 9. CAL wd1 = yd1w , wd2 = yd2w , wd3 = yd3w
15. RCV (from the server)
¶
³
dd
¶
µ ´
¶
0
³ ...
17. CAL newd = dd · u + v mod q
µ
18. SVE a0 , b0 , m0 , n0 , newtoken = (ga, gb, gm, gn, za, zb, w1, w2, w3, newd)
Server Protocol
13. SVE ti , dd, w (adding refreshed token list) 14. SND (to the client)
¶
¶
³ ...
µ ´ 3.2
µ 2. GEN α10 , α20 , α30 , α40 , α50 , α60 0
0 0
a
³ ...
1. RCV (from the client)
3. CAL α1 = (g a )α1 , α2 = (g b )α2 , α3 = (g r 0 0 0 0 0 0 0 α4 = (g r b )α4 , α5 = (g r )α5 , α6 = (g r )α6
´
12. CAL dd = cd · x + w mod q
When the server receives a user’s request to refresh token, the server has got g, z ,x and the list of Refreshed Tokens, and does the following:
0
´
11. RCV (from the client)
16. CHK yd1dd == (z r )cd wd1, yd2dd == (z r )cd wd2, 0 yd3dd == (z r )cd wd3
3.1.2
³ ...
µ 0
10. SND (to the client)
0
)α3 ,
4. SND (to the client)
91
´
Present Protocol
We show the XML protocol on Web Service for RT Present of section 2.2.2. If Alice sends one token to Bob for being provided service, Alice has to calculate and sends her token. Alice needs a message M written service information, including receiver information and sending date. That is because if all messages
¶
³
POST /StockQuote HTTP/1.1 Host: aatoken.aitea.net Content-Type: text/xml; charset="utf-8" Content-Length: nnnn SOAPAction: "http://aatoken.aitea.net/sorp_test/" 0.1 ... ...
µ
´ Figure 3: Example: Refresh Protocol on SOAP
3.2.1
4.1
Client Protocol
The User(client) has got a, b, m, n M = message for server and token ti = (g a , g b , g m , g n , z a , z b , w1 , w2 , w3 , d) She creates M and calculates: α = H(M ), β1 = a · α + m mod q and β2 = b · α + n mod q. Then, she include next information in SENSU Authentication Information: ti ,β1,β2,M (Binary data). The figure 4 is our suggestion for WS-Security.
3.2.2
Server Protocol
He receives ti = (g a , g b , g m , g n , z a , z b , w1 , w2 , w3 , d), β1,β2,M from XML, then check if ti is correct in the following manner: • CHK ti has already been used or not with the list of Used Tokens. • CHK g d == z c w1 , (g a )d == (z a )c w2 and (g b )d == (z b )c w3 • CAL α = H(M ) • CHK g β1 == (g a )α (g m ), g β2 == (g b )α (g n ) And then, he adds this token to list of Used Tokens: ti , β1, β2, M .
4.
APPLICATIONS
Our contribution could not only provide privacy solutions for existing applications, but could lead to new applications which were impossible for the lack of a way to protect privacy. We show two examples of how our system could be used to solve privacy problems.
92
Questionnaire
The first example is questionnaire. Questionnaire is mostly used by companies and organizations to know the trends of consumers. This requires the server (companies and organizations) to collect and analyze user’s information. It is easy to see that this leads to privacy problem. Both the quality of information and user’s privacy is important. It is often hard to keep the quality of information in digitized questionnaire. Double-submit and other malicious acts could be avoided only by making use of authentication. On the other hand, to protect privacy, this authentication should be anonymous. This could be achieved by using authentication based on our scheme. A user acquires a token before answering questionnaire, and sends it for completing it. The server can control double-submit by authentication, and user’s privacy is protected by the use of anonymous token. It is not rare to hold a series of questionnaire. In these situations, the server can refresh the token anonymously for the next questionnaire. This allows the server to reject a malicious user who has answered but cooked up to report. By using token rejcetion, the server can protect the quality of information.
4.2
BBS(Chat)
This scheme is also useful for BBS and chat systems. Malicious users are often seen to post bad articles on BBS, eg. obscene expressions, ascii arts, etc. Other users might feel offended by malicious statements and want to block maliciouse users to post articles. To avoid this kind of situation, we ask the user to give a token for each posting article. The judgment whether a user is malicious can be done by voting. This gives the right to judge to every user. The server can reject to refresh token
¶
³
... MIIEZzCCA9CgAwIBAgIQEmtJZc0rqrKh5i... ... ... 1 ...
µ
´ Figure 4: Example: Present on WS-Security
to malicious users.
5.
CONCLUSION
We have proposed a new token scheme which is anonymously refreshable without loosing double-use traceability. Also, our solution is adapted to be recessed to XML for a lot of kinds of application.
6.
REFERENCES
[1] Specification: Web service security. Version 1.0 05 April 2002. http://www106.ibm.com/developerworks/library/ws-secure/. [2] Simple object access protocol (soap) 1.1. W3C Note 08 May 2000. http://www.w3.org/TR/SOAP/. [3] S. Brands. Untraceable off-line cash in wallets with observers. In Proc. of CRYPTO ’93, pages pp 302–318. Springer, 1994. [4] J. Camenisch and I. Damgard. Verifiable encryption and applications to group signatures and signature sharing. In Tech. Rep. RS-98-32, Department of Computer Science, University of Aarhus. Brics, Dec. 1998. [5] J. Camenisch and A. Lysyanskaya. Efficient non-transferable anonymous multi-show credential system with optional anonymity revocation. In EUROCRYPT2001, vol.1976 of LNCS, pages pages 331–345. Springer, 2001. [6] J. Camenisch and M. Michels. A group signature scheme based on an rsa-varian. In Tech. Rep. RS-98-27, Department of Computer Science. Brics, University of Aarhus, 1998.
93
[7] D. Chaum. Group signatures. In Advances in Cryptology - EUROCRYPT ’91, pages pp.257–265. Springar, LNCS 547, 1991. [8] D. Chaum. Security without identification: Card computers to make big brother obsolete. In Communications of the ACM, v. 28, n. 10, pages pp. 1030–1044. ACM, Oct 1985. [9] J. Kohl and C. Neuman. The kerberos network authentication service(v5). In RFC 1510, September 1993. http://www.ietf.org/rfc/rfc2119.txt. [10] R. Shigetomi, A. Otsuka, T. Ogawa, and H. Imai. Refreshable tokens and its application to anonymous loan. In SCIS 2003(in Japan), 2003.
