Secure Anonymous Group Infrastructure for Common and Future Internet

Applications
Nathalie Weiler
Computer Engineering and Networks Laboratory,
Swiss Federal Institute of Technology, Zürich (ETHZ), Switzerland
weiler@tik.ee.ethz.ch

Abstract and computational costs of well-known approaches

are shown in [3].
Secure group communication protocols, in particular
multi-party key agreement and update algorithms, help pro- This paper goes one step further and introduces an
mote traditional and new Internet multi-party applications infrastructure for secure and yet anonymous group
such as video conferencing or distance education. We pro- communication – allowing for a way of communicat-
pose a framework for marrying such approaches with ac- ing in closed groups without disclosing its privacy. A
cess management mechanisms and applications in real en- secure anonymous group has an access control mech-
vironments. Furthermore, we extend this framework with anism, distributes data traffic encrypted for its mem-
anonymisation techniques for the sake of the individual’s bers only, and hides all or part of its member’s identi-
privacy. Our solution combines traditional unicast based ties to outsiders. In other words, we we understand by
approaches for privacy with authenticated and encrypted secure anonymous multicast (1) that only users who
group communication. Thereby, we are able to build closed fulfil certain conditions are allowed to join the closed
groups in which the members are not disclosed to outsiders. group, (2) that a non-member of the group cannot un-
The introduced secure and anonymous multicast (SAM) derstand the data distributed, and (3) that the identity
framework can be employed as a scalable, configurable ar- of a member may not be disclosed to outsiders of the
chitecture for pseudonym based group communication be- group. Additionally, the member may hide its iden-
tween qualified entities. tity to other group members, if the policy allows for.
Keywords: scalable anonymity, configurable end- A member of a secure and anonymous group presents
to-end anonymous communication, pseudonymous upon his join in the group the necessary proof that he
multicast, anonymous group communication. is entitled to do so. After the join, the member stays
anonymous in the group so that no outsider can ei-
1 Introduction ther identify the sender or the receiver or decrypt the
The success of the MBone – the multicast capable data sent.
overlay network of the Internet – and similar mass Internet based teaching is one of many future ap-
communication networks will be determined by their plications profiting from such a secure anonymous
ability both to preserve the privacy of their users and group infrastructure. Lectures could be followed
to secure the network infrastructure of their operators. anonymously, yet the students could be charged by
IP multicast does not support closed user groups. In administration of the teaching academy. The exami-
other words everyone can listen to all traffic of a spec- nations could be semi-blinded so that the student’s
ified multicast group as any host may join or leave identity is hidden from the examiner allowing for a
a multicast group by sending IGMP [1] messages totally fair qualification, but still the examinee cannot
to their local router. Furthermore, multicast accentu- impersonate someone else. Note also that this situa-
ates certain security threats, esp. active attacks such tion is almost impossible to achieve in traditional non-
as denial-of-service ones, malicious replays or mas- Internet based examinations. Other application fields
querading, because of missing access control mecha- include anonymous review processes or virtual con-
nisms [2]. A typical solution for secure multicast re- ferences comprising external experts whose identity
quires a many-to-many agreement on the encryption should remain undisclosed.
key. Different mechanisms to solve the problems of The contributions of this paper are two-folded:
key establishment and update in such groups have (1) We introduce an application independent model
been proposed in the recent past. The communication for managing closed groups. (2) We complement the
functional building blocks of this model with privacy replaces the sender’s address with its own, and for-
and anonymity services. The building blocks of the re- wards it together with the original message to the
sulting secure and anonymous multicast framework receiver. Forwarding through a TTP provides sender
can be combined according to the application’s needs. anonymity with respect to a passive external adver-
Furthermore, the interchangeability of the key man- sary which is not situated near the sender. The former
agement techniques allows for small to large, for al- technique has the disadvantage that the TTP is a pop-
most static to very dynamic groups. ular point of attack. The sender needs to trust it. A
We organise our paper in four parts: We start with combination of the above technique with public key
an overview over previous approaches for anonymity cryptography results in a mechanism called layered
used in unicast scenarios and describe common at- encryption forwarding: The sender adds for every in-
tacks on these systems. Section 3 introduces the build- termediate hop one layer of addressing information
ing blocks of a secure multicast framework and then and encrypts it for the respective hop. Each hop re-
details our design of a secure anonymous group in- places the sender information with his own address-
frastructure. We evaluate the advantages and short- ing information, strips off the relaying information
comings of our approach in Section 4 and conclude and sends it to the next hop in the chain. Note that the
with an outlook on further work in Section 5. layered encryption forwarding does not change the to-
tal amount of trust required in the communication re-
2 Related Work lationship: All relaying hosts together are trusted with
the same information on the forwarding than in the
Related work consists of three parts. First, we previous scheme. However, the important difference
present essential methods that we identified for is that each on his own is not able to reveal the com-
anonymous unicast connections. Then, we look at plete source and destination information. By adding
the vulnerabilities in practical realizations. Finally, we intermediate nodes in the forwarding path, the la-
cover work done in the area of anonymous multicast1 . tency is increased. However, an attacker requires sub-
2.1 Essential Methods Used in Anonymity stantial more control in the network, such making an
Schemes attack much more expensive.

We identified several essential techniques used for To recipient

the anonymisation of unicast connections.

M = M0 XOR M1 XOR M2 XOR M3
Shuffled routing minimises the risks of success-
E0 = M0 XOR P0,1 XOR P0,2 XOR P0,3
ful attacks from adversaries which control parts of
E1 = M1 XOR P1,0 XOR P1,2 XOR P1,3
the network. The sender chooses a set of anonymis-
0 1
ing nodes out of a cloud for relaying its message to M0 = 0
E2 = M2 XOR P2,0 XOR P2,1 XOR P2,3
M1 = 0

the receiver. Under the assumption that an adver-

E3 = M3 XOR P3,0 XOR P3,1 XOR P3,2
sary controls only parts of the cloud, the sender has
a fair chance to choose randomly one of the non-
compromised nodes. 2
M2 = M
Explicit and implicit addresses are a means to ob-
tain receiver anonymity, i.e. to conceal the real recipi- 3
M3 = 0
ent of a message [5]: An address is implicit if the ad-
dress contains no information either on the actual lo-
cation of the addressee or on the physical reachabil-
ity of the addressee. Only members of a certain group Figure 1. Superposed Sending: Example.
are able to use this implicit address for addressing the
addressee. On the other hand, an explicit address con- Superposed sending, or the Dining Cryptogra-
tains information that can be used in a straightforward pher (DC) method provides sender anonymity by
manner to route a message to the addressee. using a combination of several cryptographic trans-
One of the simplest techniques for anonymous formations [6]. Three cryptographers dine at their
communication uses such a trusted third party (TTP) favourite restaurant. Their waiter informs them that
as intermediary communication partner: A sender re- the bill has all ready been paid anonymously. How-
lays her message for the receiver to the TTP. This one ever, the cryptographers want to know if one of them
1 We do not cover approaches for secure multicast as there exist paid or if a third party paid for the diner. The solution
several recent, good overview papers [3, 4]. is quite simple: Each cryptographer flips a fair coin
with the person to his left, and another to his right. ATTACK 2: If an adversary can establish a correlation
Then each cryptographer announces the XOR of the between the beginning and end of a connection
two coins he sees. If he paid the bill, he announces the based on his passive observation of a link, we
opposite of the XOR. If no one paid, then the XOR of speak of a timing attack.
all the announced values will be 0. If someone paid,
then the XOR will be 1. In a network, this solution ATTACK 3: A third form of traffic analysis attack is
translates as shown in Figure 1. The major drawback the profiling attack. I.e. an attacker can trace
of the DC method is that an agreement protocol is users in long observation periods.
needed for determining who is allowed to send next. ATTACK 4: Messages in which the coding is not al-
This problem is called the collusion resolution prob- tered during transmission are subject to the mes-
lem. Furthermore, any three nodes can conspire and sage coding attack. Such messages are linkeable
determine the sender of the message (the fourth re- through pattern matching, hence traceable.
maining node in our case). In general, a DC network
consisting of n nodes is resistant to attacks of any sub- ATTACK 5: A system is vulnerable to a collusion at-
set of n 2 nodes: Supposing that a subset of n 2 tack, if a coalition of corrupt insiders is able to
nodes can successfully attack such a network is equiv- gather more information together than each one
alent in saying that the adversary is able to determine on its own is entitled to. The exploitation of this
the inputs to the one-time pad shared between the two information can break the system’s security.
parties that do not participate in the attack. However
a single one-time pad is enough to make a transmis- ATTACK 6: In a flooding attack order to separate the
sion illegible to any outsider. The superposed send- message he is interested in. The systems subject
ing method is a sender anonymity providing tech- to this attack typically rely on a kind of group
nique which has been proven to yield information the- anonymity, meaning that each message can only
oretic secrecy in the sense of Shannon. However, the be anonymous in a group of sent messages.
usability is restricted by the collusion resolution prob-
We analyse existing approaches according to their
lem and the low performance in a widely distributed
abilities to cope with the attacks. The practical real-
anonymising network.
izations are classified according to the targeted service
Mixing [7] describes a technique that combines sev-
into e-mail based ones, web centric ones, and network
eral methods: (a) A mix consists of a cascade of un-
based ones.
trusted third parties using layered encryption with
random bit strings. (b) It supports source routing in ``````Approaches Remailer
both directions, i.e. a sender may include a return path
in the same way it includes a forwarding path. (c) It Attacks
`````` Type Type Type

fragments or pads the message sent in order to sent Message

0

1
 p
2

out only packets of same length. So, the adversary can

not use the packet length as one information source
Volume
  p
in a traffic analysis attack. (d) It assembles and re-
Timing
  p
( )1

orders messages in batches in order to conceal more

Profiling
Message  p p
( )2

useful information from an observing adversary. The

mix technique was introduced for the email system.
Coding
Collusion  p
( )3
p4
Several existing system relay on it. A major improve-
(Insider
ment of the mixing technique is the introduction of
Attack)
dummy messages in the mix system.
Flooding   
2.2 Vulnerabilities in Practical Realizations
Table 1. How do existing e-mail based approaches
An anonymous communication system is best de-
cope with different attacks?
scribed by its handling of possible attacks. Therefore,
we begin by defining reasonable attacks on such a sys- 1 Not all mixmaster include dummy traffic to prevent timing at-
tem: tacks.
2 Depends on amount of dummy traffic.
ATTACK 1: By analysing the lengths of messages 3 If the chosen remailer is compromised, the system’s security is
transmitted, an adversary can correlate different broken.
4n
connections to client-server pairs. This method is 1 of n mixmasters may collude.
called traffic analysis of message volume.
````` Approaches
`````
Attacks `` Anonymizer1 LPWA [8] Crowds [9] Rewebbers [10] JANUS [11]

Message     
Volume
Timing   p
( )2  
Profiling     
3 p Insider: p p p
Message Coding
Outsider:
Collusion n.a.4 n.a.   
Flooding    n.a. n.a.

Table 2. How do existing WWW based approaches cope with different attacks?
1 http://www.anonymizer.com
2 HTTP requests frequently appear in bursts. I.e., typically, the web browser is the first to send a request. An insider, incorporating a crowds

member, knowing the other member’s processing speeds can reveal the true path position of the original request from analysis of the intervals
and delays between requests.
3 With link encryption between client and proxy: weak protection, otherwise no protection.
4 Centralised system.

````` Approaches
``````
Mail based approaches are generally classified into Attacks ` Onion
Routing
Freedom
Network
three different types: (1) A Type 0 remailer, the sim- Endpts:  Endpts: 
plest system, strips off headers and forwards the re-
maining message. Examples are anon.penet.fi (not Message Volume
Between Between p
operational anymore) or www.mailanon.com. (2) The
Onion
Routers:
p AIPs:

class of the Type 1 remailers encompasses all remail- Endpts:  Endpts: 

ers that use any variant of layered encryption such as
cypherpunk systems2 . (3) Mixmasters3 or Type 2 re- Timing
Between Between p
mailers are more resistant against spamming and traf-
Onion
Routers:
p AIPs:

p
fic analysis attacks. Their vulnerabilities are shown in Profiling 
p 
p
Table 1. A means that the discussed approach is re- Message
sistant against this kind of attack, a 
indicates that Coding
p1
the approach has no protection mechanism against Collusion 
this attack. Flooding  
Since the WWW is probably the most frequently
used application on the Internet, the demand for Table 3. How do existing network based ap-
anonymous Web browsing is increasing. We choose proaches cope with different attacks?
five representatives of this category and summarised
their vulnerabilities in Table 2. They are especially 1 resists up to n 1 colluding onion routers (of n existing ones in
vulnerable against traffic analysis of message volume total) since n nodes are needed to decode the onion.
and timing because they do not include any kind of
delay mechanisms. A more detailed description of the techniques with a cascade of untrusted third parties.
approaches is given in [12]. These routers maintain a set of encrypted TCP connec-
Most approaches are concerned about a certain ap- tions to each others. Therefore, each pair shares one
plication, typically e-mail or WWW. Onion routing symmetric secret key. However, the core of the system
and the Freedom Network are some of the few so- is the onion itself, i.e. the layered forwarding address
lutions providing anonymous connections, indepen- structure containing for each one of the used onion
dently of the actual application. routers the next hop information and key seed mate-
The Onion routing network [13] consists of a num- rial (for the generation of the symmetric keys that will
ber of onion routers, i.e. routers that use the forwarding be employed by the onion router during the actual
2 http://anon.efga.org/Remailers/TypeIList routing of the data). After the setup of the path, the
3 ftp://utopia.hacktic.nl/pub/crypto/remailer/ onion proxy accepts data from the application, breaks
it in blocks of fixed length, encrypts it according to by legitimate participants or members. In our Inter-
the chosen path, and transmits the result to the onion net learning scenario, only enrolled students should
router network. On the path, each onion router strips attend the lecture. As the sender cannot control the
its envelope and forwards it to the next hop. The re- membership in an IP multicast group, anybody may
sponder proxy assembles the data blocks and sends receive the multicasted data. The typical approach to
them to the receiving application. Besides being trans- solve this problem is to encrypt the multicasted data
mitted in uniformly sized blocks, the data is mixed, i.e. with a symmetric session key, and to distribute this
collected and reordered randomly. Synthetically gen- key to the legitimate receivers. The distribution of
erated traffic may be added to long term connections. the session key must be efficient in dynamic groups4
However, the experimental prototype shows unfortu- and scalable to a large number of members. In the
nate correlations between several data sources. So, de- remaining of this section, we will now first describe
spite of mixing, the chances of a successful traffic anal- the building blocks of the secure multicast framework
ysis attack are still considerable. A replay attack can be we designed (Section 3.1). Then, we explain the ex-
tackled with nonces in a successful manner. A flood- tensions of this framework for anonymous but yet
ing attack is the promising approach in case of long secure group communication (Section 3.2). Finally, in
lasting connections. Section 3.3, we show how to deal with degenerated
The Freedom Network [14] is an anonymising over- cases of all members staying anonymous and how the
lay network running on IP. Its similarities to Onion delay of distribution to anonymous users can be min-
Routing and PipeNet are strong: The Anonymous In- imised.
ternet Proxies (AIP) form the backbone of the anony-
mous network. The anonymising protocol uses lay- 3.1 A Framework for Secure Multicast
ered encryption between AIPs considered as semi-
Internet Distri-
trusted third parties. The integration of anonymous Teach- buted
Virtual
Others
Casino
mail servers using pseudonym servers is planed. ing Games
However, the Freedom Network suffers from a far With Without
Application Authentication Authentication
worse design flaw: Active attackers incorporating two
AIPs can trace everyone who uses them as first and Access Management
last AIP. The first AIP must mangle the payload of the

Split Keys
Periodic
ReKey
CTree

DTree
CFlat

DFlat
incoming packet and the last one recognises them by

...
Group Management,
checking if the computed checksum matches the in- Key Distribution and

Heartbeat
Revisions
dicated one. If it does not, the packets were mangled Synchronisation

None
CCP
and an IP address can be associated to the pseudonym
used so by revealing the anonymised identities.
Network
2.3 Anonymous Multicast Reliable
IP
Reliable
non-IP
Non-
Reliable IP
Multicast Multicast Multicast
Concerning anonymity in multicast, few work has
Simulated
been done so far. [15] introduces a simple protocol Real Network
Network
for multicast based anonymity, i.e. the protocol uses
the inherent anonymity in multicast to achieve re-
ceiver anonymity and uses a set of trusted forward- Figure 2. Secure Multicast Framework.
ing nodes to guarantee – under certain conditions
– sender anonymity. However, the protocol uses the
Our framework consists of four functional building
same technique as one uses for denial-of-service at-
blocks as depicted in Figure 2. We describe the tasks of
tacks.
each block and enumerate example representatives.
3 Secure Anonymous Multicast Commu- The application block encompasses all sort of user
nication application programs involving more than one par-
ticipant wishing to communicate. Example applica-
A group typically consists of participants that send tions are the already depicted Internet learning sce-
and receive data. Each participant may play both nario, distributed multi-party games, virtual casinos,
roles, e.g. in an Internet based teaching scheme, the the MBone applications, or Internet based trading
teacher may give lectures, but may also listen to the communities.
questions asked by students. Secure multicast scenar-
ios require the data to be sent to and received only 4 I.e. groups with changing memberships.
 The access management controls if the joining par-
Secure Multicast
ticipant is entitled to do so, i.e. if the credentials he Group (SMC)
presented upon join are valid for the requested group.
Further on, it must be ensured that, at each point in
time, the access rights or security policies are fulfilled P1 P9
(as we expect these to be dynamic, to change over
time). Different admission schemes are possible and P2
P10
implemented: everyone, only paying participants or
access lists’ schemes. SAM A
The third building block called creation, distribu- SAM B
tion and synchronisation of the necessary key mate-
P5 P6
rial ensures the core business of the secure multicast P7
communication. Its responsibility is to provide each
participant just in time with the correct keys needed P8 Anonymous
P3 Participants in SMC
to understand and/or verify the origin of multicas- P4
Anonymous Participants in
ted data, and to send confidential and/or authenti- SMC

cated data to the group on the other hand. Solutions

for these tasks include the following ones: (1) Early de-
veloped, centralised approaches use a key distribution Figure 3. Illustration of our Approach.
centre controlling the entire distribution process [16].
(2) Recent distributed approaches rely on tree based group M consisting of the participants P1 , P2 , P5 , P6 , P9 ,
hierarchies to manage the keys. Examples are the and P10 . Through the membership of the SAM server
one way function trees [17] and rekeying approaches A, P3 and P4 participate anonymously in the group.
[18]. Sometimes, they are combined with the Diffie- Similarly P7 and P8 join the group M together with
Hellman types of key exchanges for performance rea- the SAM server B. All multicast traffic divulged in the
sons [19]. (3) Secure group management schemes such group M is transmitted in a secure way by the SAM
as the VersaKey family [20] include centralised to dis- servers to their respective anonymous subscribers. So,
tributed approaches that may be switched during op- in this scenario, the membership of the anonymous
eration. Synchronisation protocols are needed in or- participants is hidden to external eavesdropper and
der to enable the timely delivery of the keys, and al- internal members of the group M.
low each participant to keep track of valid and invalid Our concept for secure and anonymous multicast
keys, too. An example of a synchronisation protocol is communication extends the more general framework
the revision concept used in VersaKey. for secure group communication as shown in Figure 4.
Finally, the network used may be a real one, a sim- Therefore, we performed the following additions:
ulated one or an overlay net, e.g. virtual network. Its
task is the provision of accurate multicast support for  The extension of the application block let to a
the chosen use case. division into two sublayers. As the application
With this framework, we have a powerful basis for should not become dependent of the underlying
the development of new secure group communication infrastructure5 , the framework dependent part
protocols allowing us to exchange protocols in one was decoupled from it. The resulting application
block without the need to replace and customise all programming interface (SAM-API) implements
other blocks. One example of a possible usage is its the application specific functions related to the in-
conceptual extension to anonymous secure multicast terfacing of application and framework. For ex-
as shown below in Section 3.2. ample an agents’ application requires authenti-
cated and confidential communication between
3.2 Design the agents “in the field” bidding for network re-
Conceptually, we let new members join the se- sources. Hence, the agents’ application needs an
cure multicast group without having them to reveal interface to the framework to require the fulfil-
their identity to any outsiders and/or members of the ment of this demand. A distributed game, on the
group. Therefore, we introduce a new participant in other hand, may only require, if at all, the authen-
the multicast group: the secure and anonymous mul- tication of a player in the join phase and no con-
ticast (SAM) server. Figure 3 depicts an example of 5 It seemed a poor design choice to do so just for anonymity pur-

two SAM servers A and B joining the secure multicast poses.

 The SAM servers joining on behalf of the users
Application
that wish to remain unknown to both the group and
Application
any outsiders are treated as normal members of the
SAM-API
group and play their expected role in the chosen
group key management technique. However, the true
Pseudonym based members, i.e. the anonymised group members, re-
Access Management Authentication ceive the secure group communication through the
SAM server. Therefore, we use the SNAP (Secure Non
Group Management,
Anonymous Group local Anonymising Protocol) architecture described in
Key Distribution and
Synchronisation
Management [12]. Thereby, we inherit the user administration and
persona generator service on one hand and, most im-
portantly, the users are protected from any malicious
observer in their local environment due to the pro-
Network Anonymous Multicast tected transmission between SAM server and user.

User SAM-Server Remote Server

General Secure Secure (Enhanced SNAP Server) or SMC Group
Multicast Anonymous
Framework Multicast (SAM)
Framework
SNAP
General Purpose
SNAP Store-and-Forward
Persona
Figure 4. A Framework for Secure and Anonymous Generator
HTTP(S) Proxy Server

Multicast (SAM). SNAP

SMTP Server
Key
Management
User Administration Anonymous
Multicast Server
fidential data transmission at all. In the Internet
learning scenario, finally, only the data transmit- Authorisation Key Administration
ted during examinations must be authentic. Administration

 The access management block is enhanced SNAP Components

with a pseudonym based authentication mecha- Additional Components
nism: Each user is given a randomly generated for Secure Anonymous
Multicast
pseudonym upon verification of the credentials
he presented during the authentication process.
Figure 5. Enhanced SNAP Server for Secure and
 The management of the group keys used for Anonymous Multicast.
data traffic encryption and for confidential and
authenticated distribution of the group manage-
ment information is done by standard secure The implications of the usage of the SNAP architec-
group techniques or methods that draw profit ture on the simplified secure multicast framework are
of the group topology such as the one-to-many many-folded: First, the new SAM server derived from
scheme described in [21]. The Internet learning the SNAP server must be able to join a secure multi-
application, e.g., uses a one-to-many scheme that cast group. Therefore, we included a key management
scales to large, dynamic groups for lectures and a component in our design and implementation (see
many-to-few scheme for written exams. Further- Figure 5). Its task is to organise the keys used in every
more, we need to include pseudonymity aware- secure multicast groups it participates in. Second, we
ness in the addressing schemes used for mem- need to administrate the keys and credentials given
bers. by the SAM user to the server to join a group. This
includes the administration of the keys and the au-
 Finally, we need to add the required network in- thorisation credentials. Finally, the SAM server should
frastructure – the SAM servers – allowing for distribute the received multicasted data to the enti-
users to remain unknown to outsiders or to both tled users and send the user’s data encrypted and/or
outsiders and the group.
signed with the correct key(s) to the targeted secure second group will only include users that are have
multicast group. at their disposal the required technology to join a se-
cure multicast group. For this case, we extended the
3.3 Special Cases anonymous multicast server in the SAM server with a
3.3.1 Degenerated Cases dummy traffic generating engine as commonly used
in mixes (see Section 2 for a description of the mix
We distinguish between two degenerated cases such technique).
as depicted in Figure 6: The first only includes anony-
mous participants in the secure multicast group with- 3.3.3 Certifications
out any normal members. The second one includes
only normal users. This case is equivalent to the case A special access management scheme was included in
of a secure multicast group with the exception that no the order to allow for fair, semi-blinded examinations.
member of the group can claim to know that there are We introduce certified pseudonyms for students. The
only normal members. Only a collusion of all mem- protocol for a student S who desires to take a semi-
bers could reveal this fact. As long as there is one blinded examination of examiner E is as follows:
member not colluding, he could be assumed to be a 1. S checks if E allows for semi-blinded examina-
SAM server. tions in the digitally signed course description. In
Both cases do not require a change in the building case of a negative answer, semi-blinded examina-
blocks. They are handled as “normal” distributed sce- tions are not possible for this course.
narios. 2. In the case of a positive answer, S requests a cer-
tification of his pseudonym P used in the course
from the certification authority of the university.
3.3.2 Merge of Unicast Connections Therefore, he needs to proof that the pseudonym
P is bound to his real identity in an unalterable
Secure manner by his SAM server. The certification au-
Multicast Group thority stores the certificate in a safe fashion and
(SMC) puts the pseudonym together with the timing in-
formation of the exam on the access list for the
secure multicast group of the examination.
P1 P9 3. S joins this group anonymously through the indi-
cated SAM server at the time of the exam.
4. E grades the signed performance of P and for-
P2
P10 wards the grade to the certification authority and
SAM A to the pseudonymous user P.

4 Evaluation
4.1 Scalability of the SAM framework
P3
The SAM server, until now referred to as one server
per local environment, may consist of a network of
P4 SAM servers for scalability reasons such reducing the
P5 trust required. Therefore, techniques such as Onion
Second Secure Routing or the Freedom network (Section 2) are em-
Multicast Group
for Anonymous ployed.
Participants P6 P7 P8
4.2 Complexity Analysis
The additional costs for the SAM architecture orig-
inate from two improvements on a typical group ar-
Figure 7. Merge of Unicast Connections. chitecture: (1) the introduction of anonymity mecha-
nisms, and (2) the usage of secure group communica-
If a SAM server reaches a critical number of users tion.
subscribed through it to the same secure multicast The latter one is heavily dependent on the used
group, it may include all these users in a second secure group key management scheme. The communication
multicast group as depicted in Figure 7. Of course, this costs of the most frequent operations in centralised
 Secure Multicast
Group (SMC)
Anonymous Participant Secure Multicast
in SMC (through SAM A) Anonymous Group (SMC)
SAM A SAM C Participants
P9 in SMC
(through SAM C)
P1
P1 P9
SAM B SAM D P10

P2
P10
SAM E

P7
P2
P3 P8 Anonymous
P4 P3
Participants in SMC
Anonymous Participants in P5 P6 (through SAM D) P4 P5 P6
SMC (through SAM B)
Anonymous
Participants in
SMC (through P7 P8
SAM E)

(a) Only Anonymous Participants. (b) No Anonymous Participants.

Figure 6. Degenerated Cases.

and distributed, tree-based approaches are shown in work for a specific application should be carefully
Table 4. n denotes the number of members in the chosen with respect to the expected group topology.
group, k the length of the key in bits.
4.3 Resistance to Attacks
Operation Centralised Distributed, Tree- The resistance of the SAM framework to the de-
based fined attacks cannot be given at a general level be-
cause it depends on the exact configuration used.
Group ini- nk 2nk + log(n) A near ideal setup uses SAM servers organised
tialisation as in the onion routing approach with pseudonym
based authentication and dummy traffic generation.
The SAM servers will not only process multicast traf-
Join of a nk + log(n) 2log(n)k + log(n)
fic, but also the traditional traffic of the SNAP server:
member
e-mails, web browsing and other TCP based traffic.
Leave of a nk + log(n) 2log(n)k + log(n) 5 Conclusions
member
In summary, the SAM framework provides an en-
Table 4. Communication costs (in terms of multi- vironment for anonymous group communication de-
cast size) of the most frequent operations in com- rived from a general purpose and application inde-
mon secure multicast approaches. pendent secure multicast framework build on top of
state-of-the-art technology. The exact composition of
the framework is configurable by the application, e.g.
The impact of the anonymisation depends on both the application decides on the access mechanisms or
the number of users per SAM server and the total if encryption algorithms are mandatory.
number of SAM servers. The first factor gives an in- The usage of network of SAM servers for scalability
dication for the number of additional unicast sessions reasons reduces the trust required in each of the indi-
needed. The second factor specifies the number of ad- vidual servers.
ditional joins in the secure multicast group. So, the Furthermore, we prevent observers in the local en-
mechanisms in each building block of the SAM frame- vironment of the user from learning any information
about the traffic transmitted between SAM server and
user. This property called local anonymity is inherited [9] Michael K. Reiter and Aviel D. Rubin, “Crowds:
from the SNAP server. Anonymity for web transactions,” ACM Transactions on
Finally, the SAM framework allows for hybrid au- Information and System Security, vol. 1, no. 1, November
thentication mechanisms. Some application require 1998.
only registered users to participate, but after authenti- [10] Ian Goldberg and David Wagner, “TAZ Servers and the
cation, they have no interest in which particular user Rewebber Network: Enabling Anonymous Publishing
send which message. An example of such an appli- on the World Wide Web,” First Monday, vol. 3, no. 4,
April 1998.
cation is a virtual casino: A player must reveal some
personal identification such as age and financial in- [11] Thomas Demuth and Andreas Rieke, “Securing the
Anonymity of Content Providers in the World Wide
formation for legal and operational reasons when he
Web,” in Proceedings of SPIE’99, San José, CA, USA, Jan-
changes money to playing chips. But the information
uary 1999, vol. 3657, pp. 494–502.
on which game he wins his chips should not be acces-
[12] Nathalie Weiler and Bernhard Plattner, “Secure Anony-
sible. In other words, once he got the chips, he should
mous Protocols for Local and Multicast Environ-
remain anonymous in the virtual casino. The simplest ments,” Technical Report 73, TIK, ETH Zürich, Switzer-
solution for this approach in the SAM framework is a land, October 2000.
pseudonym based solution. [13] Michael G. Reed, Paul F. Syverson, and David M. Gold-
Further research on this topic will encompass schlag, “Anonymous connections and onion routing,”
(1) the analysis of the behaviour of different applica- Journal on Selected Areas in Communications, vol. 16, no.
tions in the SAM framework with respect to selected 4, May 1998.
authentication methods and group management tech- [14] Ian Goldberg and Adam Shostack, “Freedom Net-
niques, (2) the quantitative evaluation of the differ- work 1.0 Architecture and Protocols,” White Pa-
ent components concerning performance and usabil- per, http://www.freedom.net/info/freedompapers/
ity, and (3) the theoretical assessment of the degrees of index.html, November 1999.
anonymity resp. pseudonymity achieved with respect [15] Clay Shields and Brian N. Levine, “A protocol for
to the defined attacks. anonymous communicastion over the internet,” in
Proceedings of the 7th ACM Conference on Computer and
References Communication Security (CCS’2000), Athens, Greece,
[1] W. Fenner, “Internet group management protocol, ver- November 2000.
sion 2,” RFC 2236, November 1997. [16] S. Mittra, “Iolus: A framework for scalable secure
[2] Anton Ballardie and John Crowcroft, “Multicast- multicasting,” in Proceedings of ACM SIGCOMM ’97,
specific security threats and counter-measures,” in Pro- Cannes, France, September 1997, pp. 277–288.
ceedings of ISOC Symposium on Network and Distributed [17] David Balenson and David McGrew amd Alan T. Sher-
System Security, San Diego, CA, USA, February 1995. man, “Key management for large dynamic groups:
[3] Lakshminath R. Dondeti, Sarit Mukherjee, and Ashok One-way function trees and amortized initializa-
Samal, “Survey and comparison of secure group com- tion,” Internet Draft draft-irtf-smug-groupkeymagmt-
munication protocols,” 2000. oft-00.txt, August 2000.
[18] Ohad Rodeh, Kenneth P. Birman, and Danny Dolev,
[4] Matthew J. Moyer, Josyula R. Rao, and Pankaj Rohatgi,
“Optimized group rekey for group communication
“A survey of security issues in multicast communica-
systems,” in Proceedings of Network and Distributed
tions,” IEEE Network, November/December 1999.
System Security Symposium (NDSS’00), San Diego, CA,
[5] Andreas Pfitzmann, Dienstintegrierende Kommunikation- USA, February 2000.
snetze mit teilnehmerüberprüfbarem Datenschutz, Ph.D.
[19] Yongdae Kim, Adrian Perrig, and Gene Tsudik, “Sim-
thesis, Universität Karlsruhe, Deutschland, Informatik-
ple and fault-tolerant key agreement for dynamic col-
Fachberichte 234, Springer Verlag, 1990.
laborative groups,” in 7th ACM Conference on Computer
[6] David Chaum, “The dining cryptographers prob- and Communication Security, November 2000.
lem: Unconditional sender and recipient untraceabil- [20] Germano Caronni, Dan Sun, Marcel Waldvogel,
ity,” Journal of Cryptology, pp. 65–75, 1988. Nathalie Weiler, and Bernhard Plattner, “The VersaKey
[7] David L. Chaum, “Untraceable electronic mail, return Framework: Versatile Group Key Management,” IEEE
adresses, and digital pseudonyms,” Communications of Journal on Selected Areas in Communications, Special Issue
the ACM, vol. 24, no. 2, February 1981. on Middleware, September 1999.
[8] Eran Gabber, Phillip B. Gibbons, David M. Kris- [21] Nathalie Weiler, “SEMSOMM - A Scalable Multiple En-
tol, Yossi Matias, and Alain Mayer, “On secure cryption Scheme for One-To-Many Multicast,” in Pro-
and pseudonymous client-relationships with multiple ceedings of the IEEE 10th International Workshop on En-
servers,” ACM Transactions on Information and System abling Technologies: Infrastructure for Collaborative Enter-
Security (TISSEC), November 1999. prises (WET ICE ’01), June 2001.