Providing Privacy for Web Services by Anonymous Group Identification Giuseppe Cattaneo Finmatica S.p.A. Via Amato, 84131, Salerno – Italy
[email protected] Pompeo Faruolo, Umberto Ferraro Petrillo, Giuseppe Persiano Dipartimento di Informatica ed Applicazioni Universit`a degli Studi di Salerno, 84081, Baronissi(SA) – Italy {pomfar,umbfer,giuper}@dia.unisa.it Abstract In this paper we present a SOAP extension for protecting the privacy of users of a Web Service. This extension allows a user to prove to a remote SOAP server to be member of a trusted group without revealing his/her identity. Our extension has been designed as to ensure interoperability among SOAP applications written in different programming languages. We developed also some implementations of our extension using different programming languages. Moreover, we conducted an extensive experimentation of our implementation to prove its feasibility in a realworld context. In sums, our work suggest that privacy can be added to Web Services with very little impact on the application developer and without compromising the performance of Web Services.
1. Introduction The recent technological trends are pushing toward a thorough adoption of Application Service Provider (ASP) oriented architectures in building complex distributed software systems. The goal of this approach is to let a software system delegate the fulfillment of special purpose tasks to external specialized software agents rather than implementing them by itself. This has both the effects of reducing the costs and improving the quality of the overall system. Web Services are nowadays referred to as the de facto standard enabling technology for the implementation of the ASP model. They offer a simple solution for the integration of heterogeneous systems while proposing a loosely coupled approach to service providing.
The scenario depicted by the ASP model poses many security issues; these range from the need of securing the communication network used for accessing remote services to the adoption of proper services for establishing and maintaining trusting relationships. Many of these issues have been addressed by standardization bodies and industry actors. Among the noteworthy contributions in this field we mention WS-Security [1] and its advancement, SOAP Message Security [2]. These two specifications describe a standard framework for adding security features to Web Services implemented using the Simple Object Access Protocol (SOAP) [3]. Some of the provided enhancements are: message integrity, message confidentiality, and single message authentication. Several other specifications have been proposed for addressing specific security issues such as: advertising the security requirements of a Web Service (WS-Policy) [4], defining a trust model for establishing communications between SOAP endpoints (WS-Trust) [5], allowing organizations to inform a priori their clients about the way their private data will be used (WS-Privacy), allowing SOAP endpoints to establish a secure session at the SOAP layer (WS-SecureConversation) [6], defining Web Services access policies (WS-Authorization). These contributions have been widely recognized as a main advancement in the field of security for Web Services. Unfortunately, the important issue of user privacy has been overlooked. Indeed, in several applications Web Services do not need to identify the client but only need to make sure that the client is authorized to access that service. Consider, for example, the case of the members of an organization that should be granted the permission to access a subscription-based remote service such as an on-line repos-
itory of medical articles. Such a service should be provided in anonymous way (i.e., without requiring the requesting users to identify themselves) while, at the same time, guaranteeing that only authorized users access the service. Two typical solutions to this problem are to configure the service provider so to accept only requests whose originating Internet address belongs to an authorized domain or to introduce group-based credentials to be exhibited for accessing the service. The first solution suffers many drawbacks: for example, an unauthorized user could access a restricted service by just using a machine belonging to a trusted network while an authorized user connected to an untrusted network could not. Even the choice of enforcing a groupbased accounting may reveal to be insecure. A malicious authorized user that discloses the group credentials to thirdparties would compromise the security of the whole system. This problem cannot be solved using existing Web Service authorization mechanisms, such as the one detailed in WSTrust [5], because these approaches require the user to reveal his/her identity, even if in some cases to only an external authority, before accessing a service.
1.1. Our Contribution In this work we present a solution for providing privacy for Web Services through anonymous group identification. Namely, we designed an extension for the SOAP protocol that allows a user to prove to a remote SOAP server to be member of a trusted group without revealing his/her identity. Our extension relies on a variant of a protocol presented by De Santis et al. in [7]. We developed also two prototype implementations supporting this extension. The first one has been entirely implemented in the Java language. The second one features a mixed architecture consisting of both Visual C++ and Visual Basic components. These implementations are almost transparent both for the developer and for the user of a Web Service in the sense that privacy can be added to an existing Web Service with a very small effort. These two implementations are also interoperable because we designed our extension so to exchange data using an application and technology independent encoding. Finally, we conducted an extensive experimentation of our implementations to prove their feasibility in a realworld context (i.e., when dealing with a large amount of identification requests in a short interval of time). Namely, we measured the overhead due to the cryptographic part of our SOAP extension, the throughput achieved by a SOAP server processing anonymous group identification requests under several different load conditions and the average response time of the execution of a Web Service using anonymous identification.
2. Anonymous Group Identification A protocol for anonymous group identification is a protocol by which a service provider can make sure that the service is accessed only by authorized users. Moreover, it guarantees that users maintain their anonymity. In other words, each user simply proves to be a member of the group of authorized users without revealing his/her identity. This is typically achieved by having users pick a pair of public/private keys. Each time access to the service is sought, the user engages in a protocol with the service provider in which he/she proves to have the private key associated with one of the authorized public keys. Our proposal for anonymous Web Services relies on the anonymous group identification scheme introduced by De Santis et al. in [7]. This scheme presents a zero-knowledge protocol that allows a user to identify himself/herself in an anonymous way toward a remote party. The security of this scheme is based on the computational difficulty of factorizing Blum integers. A Blum integer is simply an integer x that is product of two primes of the same length, both ≡ 3 (mod 4). The private key of each user is a square root of a random square of Zx∗ . The protocol presented in [7] is very efficient with respect to the amount of information to be transmitted for achieving identification; its communication complexity is Θ(n + m) where m is the size of the group and n is the length of x. The identification scheme by De Santis et al. The identification scheme proposed by De Santis et al. [7] involves three actors. First, the center that is in charge of handling group initializations. Second, several users actors belonging to a same group. Third, a verification authority that is in charge of verifying the group membership of requesting users. The protocol acts in two phases. The initialization phase is executed only once, at the start-up of the system, and consists of the following steps. The center generates randomly a Blum integer x and a set of Blum integers, w1 , ..., wm . To each user Ui the center sends the Blum integers x and wi . Each user Ui will use the integer wi as his/her private key and yi ≡ wi2 (mod x) as his/her public key. The public keys y1 , · · · , ym will be made accessible to all users. The identification phase consists in many independent repetitions of the following atomic protocol. A user Ui who wants to identify himself/herself to the verification authority will compute an integer u ∈ Zx∗ as the product of a random subset R of the public keys y1 , ..., ym and the square of a random integer r modulo x. Ui then sends u to the verification authority that replies by sending a random bit b (the challenge). The user is expected to send to the verification authority a subset S of indexes of the public keys together
with an integer s such that u ≡ s2 Πi∈S yi (mod x). A legitimate user can always satisfy the challenge. Indeed if the cardinality of R has parity equal to b, then he/she can just send R. If instead R has parity 1 − b then the user can add to R the index of his/her public key, if it has not been used, or remove it from R, if it has been used. Notice that this can be done since a legitimate user knows the square root of his/her own public key. If instead user U ∗ that does not know any secret key plays the protocol in order to gain access to the service then the verification authority exposes him with probability 1/2. By performing independent executions of the protocol, the probability that U ∗ successfully completes all executions of the protocol can be made negligible. Indeed, when U ∗ computes u then he/she can successfully satisfy the challenge for at most one value of b ∈ {0, 1}. If this is not the case, it can be shown that U ∗ can be used to compute square roots in Zx∗ , a supposedly difficult problem.
wich Mean Time. The verification authority should verify that the date used is not older than a fixed security time interval (this assumes the client and the server to “agree” on the current time).
Our variant of the identification scheme by De Santis et al. A straight-from-the-paper implementation of the original scheme by De Santis et al. [7] does not fit the Web Service paradigm. Indeed, requesting a Web Service is intended to be like a procedure call: one party provides the input and the other provides the output without any further interaction. Instead, the original identification protocol requires several interactions among the user actor and the verification actor before the service could be provided. We thus resort to a well known cryptographic paradigm: the random oracle model explicitly formulated by [8]. Here, it is assumed that the two parties have access to an oracle that works like a random function: on input a string σ it returns a string ρ and the strings returned on different inputs are independent and randomly distributed. Thus Ui prepares the first round messages σ = (u1 , · · · , uk ) for all the k iterations of the atomic protocol (we use k = 32 thus allowing probability of 1 in about 4 billions that a user manages to obtain access without knowing any secret key). The k challenges B = (b1 , · · · , bk ) for the k iterations are obtained by invoking the random oracle on input the string σ. Then Ui computes the answer A = (A1 , · · · , Ak ) for each of the k challenges and sends (σ, B, A) to the verification authority. The verification authority checks that the challenges and the answers have been correctly computed and, if this is the case, it grants access to the service. We remark that, in this way, we fall back into the Web Service paradigm: the user sends the arguments for the Web Service, along with the credentials for the anonymous identification (that is, the triplet (σ, B, A)) to the service provider which, after verifying the credentials, returns the output. In our prototypes, we implement the random oracle using the secure hash function SHA-1 [9]. Moreover, to avoid the replay attack we also add to the string σ (used to compute the challenges) the current date expressed in the Green-
The SOAP standard protocol can be extended without compromising existing applications. This is the case of the extensions detailed by the SOAP Message Security [2] specification. These extensions define a single-message security language that can be used to implement several security models such as encrypting or guaranteing the content of a SOAP request, and providing authentication or authorizations schemas. The basic building block of this language is the header block, an element that is encoded in the header of a SOAP request to carry security related information. Security tokens can then be attached to a SOAP request by enclosing them into a block. The current SOAP Message Security specification fully supports two kinds of security tokens: user name tokens and binary security tokens. The former define a standard way for a SOAP request to carry a username together with some security information. These can be customized to implement different authentication or authorization models. The latter specify a standard framework for attaching any binary-encoded security token (e.g., a X.509 certificate) to a SOAP request. In both cases, the SOAP Message Security specification dictates a set of additional attributes (some of which are mandatory) that inform the receiver of a SOAP request about the type of security token, its encoding format and so on. These information can be extended with the addition of other attributes required for the implementation of specific security models.
3. SOAP SOAP is one key technology for the implementation of Web Services. It is a lightweight protocol intended for exchanging structured information in a decentralized distributed environment by means of SOAP messages. We refer the interested reader to [3] for a thorough discussion of SOAP. Instead, in this section we will focus on the existing specifications that describe how to extend SOAP so as to support security features.
3.1. SOAP Security Extensions
4. Our proposed solutions We implemented our variant of the anonymous group identification protocol described in Section 2 following the guidelines dictated by the SOAP Message Security specification. The resulting SOAP extension requires the iden-
tification information used for anonymously authorizing a SOAP request to be enclosed enclosed into the header of the same request. Moreover, we coded two prototype implementations that show in which way it is possible to transparently support anonymous Web Services by using some special-purpose SOAP header processors. These are software components that can be plugged in the SOAP processing chain so as to intercept, process and modify SOAP requests both on the client and on the server side. In this section we will detail the extension of the SOAP protocol we propose. We will then provide a concise description of the architecture of the two prototypes we implemented together with some implementation details.
4.1. Anonymous Group Identification SOAP extension Our extension of SOAP uses a binary security token to encode anonymous group identification information (see Section 3.1). Suppose a client application has generated a SOAP request for anonymously executing a Web Service. As a first step, a proof for anonymous identification is generated according to the protocol presented in Section 2. The proof is converted in a neutral encoding using the Distinguished Encoding Rules of the ASN.1 standard [10]; this ensures interoperability among applications written in different languages. The resulting binary sequence is enclosed as a base 64 ASCII string in a tag element that is in turn inserted in a tag element. This element will be prepended into the header of the SOAP request. In addition, the element must define the following attributes: • ValueType A string identification label defining the value space and type of the encoded binary data. The value we have chosen for our anonymous group identification security token is ”AnonGroupIdAuth”. • EncodingType Defines the encoding format of the binary data. In our protocol it is set to ”wsse:Base64Binary” to denote a base 64 encoding. • GroupId A numeric field telling the identity of the group whose the client originating the request belongs to. • IssueDate The issue date of the SOAP request expressed in the format ”dd/mm/yyyy hh.mm.ss”. It is used by both the client and the server as input for the random oracle. This information is also used by the server to reject requests older than a fixed security time interval. This will prevent third-party malicious users
MIIw3gKBgE76tfz6rP3b6QQ1vzu5ubqahd1YZBkAe...
Figure 1. The header of a SOAP request carrying a token for anonymous group identification.
from intercepting the content of a SOAP request and replaying it to a server (replay attack). This extension gives rise to an additional payload required for encoding anonymous identification tokens in SOAP request that is proportional to the size of the group the user belongs to (e.g., it is approximately 11 kilobytes when using groups with size 1000). An example of a SOAP header containing anonymous group identification is reported in Figure 1.
4.2. Architecture In this section we describe an architecture for transparently adding a privacy layer to Web Services. To this end we define two components, a proof generator module and a proof verificator service, that implement the application logic for generating and verifying anonymous identification proofs. These two components are integrated in the normal flow of events operating the execution of a Web Service by means of two SOAP request processors (here called header handler) acting respectively on the client side and on the server side. Every time a client application issues a SOAP request toward a remote server hosting anonymous Web Services, the request is implicitly (or explicitly, if the used SOAP implementation does not support this feature) intercepted and processed by the client side header handler. This handler invokes the proof generator module and prepends the resulting identification token together with a timestamp to the SOAP header of the outgoing request. Whenever an anonymous service provider receives a SOAP request from a remote client, the server side header handler is implicitly (or explicitly, if the SOAP engine does not support this feature) invoked to determine whether the request should be accepted or not. If the request is for an anonymous Web Service and no anonymous identifica-
at any identification request thus suffering a severe performance loss. The second prototype has been coded in the Java language. Here, we implemented the proof verificator as an inprocess component because Java based SOAP servers generally support stateful header handlers.
5. Enabling Anonymous Group Identification for Web Services In this section we briefly describe the steps that must be accomplished to enable and configure anonymous group identification for accessing Web Services.
Figure 2. The life-cycle of an anonymous group identification request
tion information are provided then it is rejected by raising a SecurityTokenUnavailable SOAP fault. If the identification information are only partially available or they cannot be parsed then the request is rejected by raising a InvalidSecurityToken SOAP fault. In the case that the timestamp reported in the request is older than a fixed security time interval the request is rejected with a FailedAuthentication SOAP fault. Differently, the identification request is processed by the proof verificator service according to the identification protocol seen in Section 2. If the verification is successful then the service request is executed and the response is returned to the application client. Otherwise, a FailedAuthentication SOAP fault is sent back to the requesting client. A representation of the life-cycle of a successfully verified anonymous group identification request is portrayed in the Figure 2.
4.3. Our prototypes We developed two different prototypes for supporting our anonymous group identification SOAP extension. The first has been developed on the Windows operating system using the Visual Basic language for implementing the header handlers and the Visual C++ language for coding the proof generator module and the proof verificator service. The Crypto++ library [11] has been used to code the cryptographic part of these two components. We implemented the proof verificator component as an external stateful service accessible via the ActiveX technology. This has been done since not all the Windows SOAP server implementations support stateful header handler. A stateless header handler would need to load back in memory all group keys
1. Service Development No change is required to be performed both on the source code of the service and of the client applications in order to enforce anonymous group identification. The developer needs only to modify the application SOAP configuration files to let our client side and server side header handler to process SOAP requests to be issued on anonymous Web Services. The only exception to this rule holds when using SOAP implementations that do not allow third-parties libraries to process automatically incoming and outcoming SOAP requests. In this case, the service developer needs to instrument the server and/or the client applications with the code needed to use explicitly our software functions. 2. Service Installation and Usage We suppose there exists a set of users belonging to a same group that have been granted access to an anonymous Web Service hosted by a service provider. To begin, the initialization phase of the De Santis et al. protocol is executed. As a result, each member of the group receives his/her own private key together with a copy of the public keys of all the other group’s members. These keys must be copied in the installation folder of the client application using anonymous identification. The task of disseminating keys can be easily accomplished, for example, by delivering to all members of a group some short-lived passwords to be used for accessing an enrollment Web site where to download pair of keys. Similarly, the service provider has to download a copy of all the group’s members’ public keys. Even in this case, the keys must be stored in the installation folder of the server application that will host anonymous Web Services. From this point on, no further action is required to the client and the server users because the client and the server header handlers will automatically fetch keys from disk and use them according to their configuration.
6. Performance Analysis We performed several different experiments to assess the feasibility of the protocol we implemented. First, we measured the overall amount of computational time needed to accomplish the algorithmic part of the protocol. This measurement is important as it provides a lower bound on the time required to exploit anonymous group identification. In a real world scenario, the verificator service running on the server side will likely process several anonymous identification requests at the same time. Following these considerations we estimated, in our second experiment, the maximum throughput of a SOAP server when processing sequences of SOAP messages carrying anonymous identification requests under different load conditions. We were also interested in to determine which is the overhead that a client application has to pay for accessing Web Services in an anonymous way. So, we evaluated in our third experiment the response time for the execution of a Web Service for a client either with anonymous group identification turned on and off. In the following subsections we outline the settings we used for our experimentations, detail the experiments we performed and discuss their results.
6.1. Protocol Setting In all our experiments we used as keys Blum integers of length 1024 bits. Moreover, we fixed the number of challenges to be satisfied to 32 per identification request. As already said in Section 2, this allows probability of 1 in about 4 billions that a user manages to obtain access without knowing any secret key.
6.2. Experimental setting We run our experiments using, as SOAP server, a 2.4GHz Intel Xeon dual-processor machine running the Windows 2000 server operating system. We tested our two prototypes using, respectively, the Internet Information Server v 5.0 with the SOAP toolkit v 3.0 and the Java Web Services Developer Pack v 1.3 running on the top of Apache Tomcat v. 5.0. We used as clients several other machines with the same hardware specifications connected by a local area network running at the speed of 100 Megabit/second. We conducted our experiments on a simple Web Service that just returns as output a string taken in input. We have chosen this example because its small execution time is useful to better analyze the sole cost of the identification protocol. Moreover we developed a request generator application in Java to perform our experiments. This application uses a multi-threaded architecture to submit to a remote server a
Group Size 50 100 250 500 1,000
Java Create Verify 134 112 193 134 443 356 718 650 1,423 1,328
C++ Create Verify 32 31 62 66 146 171 280 333 547 680
Table 1. Times in milliseconds required to generate and to verify proofs.
parameterized amount of SOAP requests uniformly spread over a fixed time interval with attached anonymous identification information. We were able to recreate artificially different load conditions for our SOAP servers by programmatically running multiple instances of the request generator at the same time on several different machines. We kept synchronized the dates of the involved client machines by using the Network Time Protocol [12].
6.3. Identification Protocol Overhead Our first experiment aimed to measure the amount of pure CPU time required to generate and to verify anonymous identification proofs. Our goal was to verify that the computational cost of such a protocol is small enough to make it viable for a real-world application. Therefore we measured the time required to generate and to verify identity proofs without taking in account the overhead inducted by SOAP. Thus, we coded two applications, respectively in Java and in C++, consisting of the generation and of the verification of a proof according to the protocol presented in Section 2; we tried these on several different group sizes. All the collected data were averaged on five different experiments. The results of these experiments, presented in Table 1, show that the time required to generate and to verify a single proof is relatively small (i.e., in average less than a second for groups with size up to 500). We observe as well that the C++ implementation performs better than the Java implementation. A further investigation showed that this performance gap is due to the way the two implementations maintain and use integer numbers with arbitrary precision. In fact, the Java native BigInteger data type seems to be consistently slower than the similar data type available in the Crypto++ library.
6.4. Server Throughput The previous experiment showed that the computational cost of a single anonymous identification request is affordable in practice. However, it has still to be investigated
Figure 3. Windows SOAP Server throughput when processing identification requests with group size fixed to 1,000.
Figure 4. Java SOAP Server throughput when processing identification requests with group size fixed to 1,000.
whether such a cost is sustainable in a real-world context. In such a case, the verificator server is required to process several identification requests at once. In our second experiment we estimated the throughput of an anonymous identification enabled SOAP server as the average number of SOAP messages carrying identification requests processed in a minute. We chose different group sizes and, for each of them, we evaluated the performance of the SOAP server when processing sequences of anonymous identification requests of increasing frequency. As suggested by the results of our previous experiment, we expect the throughput to be heavily affected by the size of the groups we use. This has been confirmed by the results of our experiments, presented in Figure 3 and in Figure 4, on both the C++ based and the Java based verification service. For every group size, the throughput grows linearly with the frequency of identification requests until the verificator service reaches the maximum number of verifications that it can process in a minute. Then, it remains approximately constant. In the case of C++ implementation, the verification service was able to process approximately 530 identification requests in a minute when considering groups with size 50. The maximum throughput dropped to approximately 75 identification requests per minute when considering groups with size 1, 000. It is interesting to note that the behavior of the Java implementation was slightly different. In this case, the verification service was able to process approximately 520 identification requests for groups with size 50. The throughput for groups with size 1, 000 was approximately of 35 identification requests per minute. Thus, the performance loss due to larger group sizes has grown
larger for the Java implementation. As already pointed out for the previous experiment, this overhead is due to the way Java native libraries implement numbers with arbitrary precision.
6.5. Response Time In our last experiment we evaluated the cost of anonymous group identification from the end-user perspective. This has been done by comparing the response time of an anonymous Web Service with the performance of the same service without anonymous identification. We considered as response time for an anonymous Web Service the whole interval of time required for its execution including the identification proof generation and verification part. We performed our experimentations both on a heavily-loaded SOAP server and on a lightly-loaded SOAP server. In the first case, we kept the server busy with a number of identification requests per minute equal to its maximum throughput (i.e., 75 identification requests in a minute for the Windows SOAP server, 35 identification requests in a minute for the Java SOAP server). In the second case, we generated a very small number of requests (i.e., 10 identification requests in a minute). The outcoming results, presented in Table 2, show a tenfold performance loss for Web Services with anonymous group identification turned on both when using lightly- and heavily-loaded SOAP Servers. We notice that the very high response time for the Java case, even when using a lightlyloaded server, seems to restrict the domain of real-world applications where such an extension can be used.
server load high low
Java id no id 6,675 453 3,734 442
C++ id no id 2,027 211 1,557 207
Table 2. Response time in milliseconds for client applications when using Web Services with and without anonymous group identification. The performance have been measured using a fixed group size of 1,000 and different server load conditions.
7. Conclusion and Future Directions In this paper we presented an extension of the SOAP protocol for providing anonymous group identification for Web Services. This extension is based on a variant of the protocol presented by De Santis et al. in [7] for anonymous group identification. Our extension has been designed as to preserve interoperability among SOAP applications written in different programming languages. This has been obtained by defining an application-independent encoding for data to be exchanged during the execution of the protocol. We were also interested into providing group anonymity as a facility that could be transparently added to an existing Web Service with a very small effort. We reached this goal by encapsulating the application logic of the protocol into header handler components able to process transparently SOAP request without requiring any change in the applications code. The experimental analysis we conducted revealed that the weak point of the considered protocol seems to be the significant overhead that the verification service must pay when processing identification requests for large group sizes. This is evident both when considering the maximum throughput and the average response time of heavy-loaded anonymous identification enabled SOAP servers. This problem could be faced both from a theoretical and from an architectural point of view. From a theoretical point of view, it would be interesting to evaluate the experimental behavior of other anonymous identification protocols. From an architectural point of view, there are several possible solutions to explore. The simplest one is to replicate the verificator service across several different machines and then to distribute identification requests among them. Such a solution is possible as the verificator service is almost stateless. Indeed, the only information it requires, the set of public keys of a group, is not updated very often and thus it can be kept replicated at a low cost. Another solution we propose is to introduce sessions. Suppose a client application is interested into issuing several requests to the same SOAP server, we can require an
initial authorization phase where a client providing correct anonymous group identification credentials obtains a security token to be exhibited for accessing a Web Service. Such a solution could dramatically reduce the number of verifications thus improving the throughput of a SOAP server at a price of breaking the Web Service model by using stateful Web Services.
8. Acknowledgments We would like to acknowledge the help of Gerardo Maiorano during the implementation of the prototypes we presented in this paper.
References [1] Web Services Security (WS-Security). http://www106.ibm.com/developerworks/webservices/library/wssecure/, Apr. 2002. [2] Web Services Security: SOAP Message Security 1.0. http://www.oasis-open.org/committees/download.php/5072/ oasis-200401-wss-soap-message-security-1.0.pdf, Jan. 2004. [3] SOAP version 1.2 part 1: Messaging Framework. http://www.w3.org/TR/2003/REC-soap12-part1-20030624/, June 2003. [4] Web Services Policy Framework (WS-Policy). http://www106.ibm.com/developerworks/library/ws-polfram/, May 2003. [5] Web Services Trust Language (WS-Trust). http://www106.ibm.com/developerworks/library/ws-trust/, Dec. 2002. [6] Web Services Secure Conversation (WSSecureConversation). http://www-106.ibm.com/developerworks/library/ws-secon/, May 2002. [7] A. De Santis, G. Di Crescenzo, and G. Persiano. Communication-efficient anonymous group identification. In 5th A.C.M. Conference on Computer and Communications Security (ACM CCS’98), pages 73–82, San Francisco, California, U.S.A., 3–5 1998. [8] M. Bellare and P. Rogaway. Random oracles are practical: A paradigm for designing efficient protocols. In ACM Conference on Computer and Communications Security, pages 62–73, 1993. [9] Announcement of weakness in the secure hash standard. National Institute of Standards and Technology (NIST), 1994. [10] Information technology - ASN.1 encoding rules: Specification of basic encoding rules (BER), canonical encoding rules (CER) and distinguished encoding rules (DER). http://www.itu.int/ITU-T/studygroups/com17 /languages/X.690-0207.pdf, July 2002. [11] The Crypto++ library project. http://www.eskimo.com/ weidai/cryptlib.html. [12] Network Time Protocol. RFC 1305, Mar. 1992.
