General-purpose Secure Anonymity Architecture

Contents

Overview

The rapid development in the area of computer science, software, hardware and communication made it possible to integrate information systems ina a constantly increasing factor. This tendency with together with the spreading of Internet sets newer and newer challenges for the information science. For the first problems of bandwidth and reliable data transfer several general architectural solutions exist. In the last ten years new needs arose: besides the given features secure communication was also required. In the field of encryption, integrity-protection, remote authentication honored solutions are already known (such as TLS [1]).

The latest development brought the protection of personal data - privacy - into the spotlight. As more and more databases get connected and made - partially publicly - searchable, so will getting information about persons become easier. As a kind of counter-measure that is why data-protection is needed. Anonymity can be understood as an extreme measure of such kind, where the identity of the subject needs to be hidden, this way eliminating (or at lease reducing to an acceptably small probability) the chance, so that an attacker may connect personal data to a person this way creating an unauthorized on-line profile [2].

For providing anonymity several different techniques exist, but we lack a uniform framework, where besides security techniques (e.g. encryption) arbitrary anonymity methods can be realized. The general-purpose secure anonymity architecture (GPSAA) aims to fill exactly this void - to combine security features with the two kinds of anonymity techniques:

  • Anonymous message sending methods: in the communication between two parties they make it hard to figure out (even with the help of eavesdropping on the communication channels) who sends messages to whom [3]. Typical scenarios include anonymous e-mail or anonymous web-surfing.
  • Anonymous authorization schemes: with the help of an anonymity authority they make possible for a service provider to be certain that an anonymous subject is authorized to use a specified service. Typical application areas are: anonymous electronic payment (subject is the client, anonymity authority is the bank and the authorization is the payment) or anonymous electronic voting. In most cases in order to work correctly such schemes require anonymous message sending.

The Architecture

According to the introduction such a general framework is required, which enables to combine security features with techniques of the two above mentioned anonymity categories.

The anonymity problems during the electronic communication arise mainly because of the properties of the IP protocol family (i.e. each IP packet contains both the sender's and the recipient's IP address, which makes both of them back-traceable, not anonymous). However, since the popularity of the Internet changing these protocols is not an option, anonymity has to be provided in upper layers. With these prequisites was the layer hierarchy of GPSAA designed (see Figure 1).

GPSAA Layers

Figure 1 - Layers of GPSAA

The first layer above TCP/IP is the ADL (Anonymous Datagram Layer), whose function is to deliver fixed size packets anonymously. Building on this the next layer, ASL (Anonymous Session Layer) is able to manage anonymous bi-directional streams with the help of SAR (segmentation and reassebly). Based on anonymous streams, the conventional security layers can be applied. Finally, on the top resides AH (Anonymous Handshake), which handles the application-level anonymous authorization.

ADL - Anonymous Datagram Layer

Aim of ADL is to transport fixed size packets between two communicating parties anonymously. During this (see Figure 2) the packets will be encrypted at the sender, and will be delivered through an ADL channel. In is important to note that first the channel is not necessary one physical unit, it can consist of several relaying proxies, and second that each relaying proxy encodes the packets further and reordes them as well so that by eavesdropping communication lines the routes of the packets cannot be followed. How such encodings (encryption and decryption) work and how many relaying proxies are utilizied is not part of the ADL specification. ADL aims to define an interface, which described the requirements for possible implementations. By using such a general construction, one might use several different methods in an actual implementation.

ADL Message Sending

Figure 2 - Sending Packets through ADL in General

ASL - Anonymous Session Layer

Building on ADL the next step is to enable to establish a bi-directional anonymous stream. ASL serves this purpose. No special anonymity functionality is defined for this layer, its task is to cut data received from upper layers into fixed size packets (as required by ADL) at the initiator side and to reorder (since in order to confuse attackers ADL reorders packages) and reassemble these at the responder side.

On top of ASL resides the security layer, which performs security functions on data streams. Although there is encryption in ADl as well, but it was used there only to provide protection against compromizing anonymity (i.e. one has to trust some relaying proxies), wherease now we don't even trust in the proxies any more and end-to-end security has to be established.

AH - Anonymous Handshake

Now we are ready to employ anonymous authorization above the secure bi-directional anonymous stream as part of AH (see Figure 3).

AH Triangle

Figure 3 - General data flow of the anonymous authorization as part of AH

Anonymous authorization consist of two phases. In the first phase the subject requests anonymity tokens from the anonymity authority (1) (2) during which the subject is not anonymous, on the contrary, he has to be authenticated. Actually accessing the service happens in the second phase, where the subject is already anonymous. He hands the tokens over to the service provider and requests the service (3). After this the service provider checks the tokens (4) and based on the answer from the anonymity authority (5) fulfills the request (6). GPSAA only formulates requirements for the AH, no special algorithm is envisioned, the main emphasis is to be as general as possible, in order to allow interchangeable suites.

GPSAA Implementation

Besides formulating interfaces and requirements as part of GPSAA, implementing the architecture is under way. This reference implementation follows the details of Figure 4. For the first tests at ADL the PROB-channel [5], and at AH level the blind-signature scheme of Chaum [4] was implemented.

GPSAA Overview

Figure 4 - Implementation scheme of GPSAA

Conclusion

The general-purpose secure anonymity architecture is a general framework, which enables the combined usage of security functions and anonymity services.

References

[1] Dierks, T., Allen, C.: RFC 2246 - The TLS Protocol Version 1.0. Certicom, 1999.

[2] Froomkin, A. M.: Flood Control on the Information Ocean: Living with Anonymity, Digital Cash and Distributed Databases. 1996.

[3] Reed. M., Syverson, P., Goldschlag, D.: Anonymous Connections and Onion Routing. IEEE Journal on Selected Areas in Communication Special Issue on Copyright and Privacy Protection, 1998., pp. 482-494.

[4] Chaum, D.: Blind Unanticipated Signature Systems. US Patent #4 759 064, 1998.

[5] Toth, G., Hornak, Z.: Measuring Anonymity in a Passive, Real-time System, 2004.

GERGELYTOTH99_AT_GMAIL.COM