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).
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.
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).
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.
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.
|