Proceedings Editors’ addresses:
bettini@dico.unimi.it Location based applications in travel, logistics, health care, social networks and other industries already exist and are poised to proliferate. One of the critical issues for a widespread deployment of these applications is how to conciliate their effectiveness and quality with privacy concerns. The PiLBA ’08 workshop was intended to bring together scientists from security and data management to discuss the most recent advances in the field. These proceedings include the eight contributions on this topic selected from the submissions by the PC chairs with the help of the members of the program committee, and presented at the workshop. They include an extended abstract of the invited talk, two survey papers, and five research papers covering several complementary aspects of privacy in location based applications and services.
the organization of this event. A particular acknowledgment to the PC members, to Javier
Josep Domingo-Ferrer and Qianhong Wu
Agusti Solanas, Josep Domingo-Ferrer and Antoni Mart´ınez-Balleste´
Daniele Riboni, Linda Pareschi and Claudio Bettini
Ruggero G. Pensa, Anna Monreale, Fabio Pinelli and Dino Pedreschi
Sergio Mascetti, Dario Freni, Claudio Bettini, X. Sean Wang and Sushil Jajodia
Claudio Agostino Ardagna, Angelos Stavrou, Sushil Jajodia, Pierangela Samarati and Rhandi Martin
Ahmad-Reza Sadeghi, Ivan Visconti, and Christian Wachsmann
Marcos Simpl´ıcio Jr., Paulo S. L. M. Barreto, Tereza C. M. B. Carvalho, Cintia B. Margi, and Mats Na¨slund 6 12 24 44 61 82 102 123
Josep Domingo-Ferrer and Qianhong Wu
Universitat Rovira i Virgili, UNESCO Chair in Data Privacy, Dept. of Computer Engineering and Mathematics, Av. Pa¨ısos Catalans 26, E-43007 Tarragona, Catalonia e-mail {josep.domingo,qianhong.wu}@urv.cat Abstract. Vehicular ad hoc networks (VANETs) allow vehicles to disseminate messages about road conditions to other vehicles. As long as these messages are trustworthy, they can greatly increase traffic safety and efficiency. Hence, care must be exerted to ensure that vehicle-generated messages do not convey inaccurate or false content. A natural way to proceed is to request endorsement by nearby vehicles on the content of a message originated by a certain vehicle. However, such a message generation and peer-to-peer endorsement should not result in any privacy loss on the part of vehicles co-operating in it. We survey the available solutions to this security-privacy tension and discuss their limitations. We sketch a new privacy-preserving system which guarantees message authentication through both a priori and a posteriori countermeasures. 1
Introduction VANETs allow vehicles to broadcast messages to other vehicles in the vicinity. It is suggested that each vehicle periodically send messages over a single hop every 300ms within a distance of 10s travel time (which is a distance range between 10 m and 300 m)[RH05]. This mechanism can be used to improve safety and optimize traffic. However, malicious vehicles can also make use of this mechanism by sending fraudulent messages for their own profit or just to jeopardize the traffic system. Hence, the system must be designed to ensure that the transmission comes from a trusted source and has not been tampered with since transmission.
Another critical concern in VANETs is driving privacy or vehicle anonymity. As noted in [Dot06], a lot can be inferred on the driver’s privacy if the whereabouts and the driving pattern of a car can be tracked. However, it is possible for attackers to trace vehicles by using cameras or physical tracking. But such physical attacks can only trace specific targets and are much more expensive than monitoring the communication in VANETs. This paper addresses the latter attacks. 2
Countermeasures for securing VANETs VANETs function to improve safety only if the messages sent by vehicles are trustworthy. Dealing with fraudulent messages is a thorny issue for safety engineers due to the self-organized property of VANETs. The situation is deteriorated by the privacy requirements of vehicles since, in a privacy-preserving setting, the message generators, i.e. the vehicles, are anonymous in the sense that their identities are unknown. A number of schemes have been proposed to reduce fraudulent messages; such proposals fall into two classes, namely a posteriori and a priori. 2.1
A posteriori countermeasures A posteriori countermeasures consist of taking punitive action against vehicles who have been proven to have originated fraudulent messages. To be compatible with privacy preservation, these countermeasures require the presence of a trusted third party able to open the identities of dishonest vehicles. Then the revoked vehicles can be expelled from the system. Cryptographic authentication technologies have been extensively exploited to offer a posteriori countermeasures. Some proposals use regular digital signatures [RPH06,RH07,RPAJ07,AFWZ07]. In these proposals, vehicle privacy is provided by a pseudonym mechanism, in which certificate authorities (CAs) produce many pseudonyms for each vehicle so that attackers cannot trace the vehicles producing signatures in different periods with different pseudonyms, except if the CAs open the identities of the vehicles. The pseudonym mechanism is not that efficient due to the heavy overhead of pseudonym generation and storage. Other schemes use sophisticated cryptographic technologies such as group signatures [GBW07] or ring signatures [LSHS07,GGT06]. The latter methods are more efficient, but those using ring signatures cannot trace malicious vehicles due to the unconditional anonymity of ring signatures. Along this research line, the scheme in [GBW07] seems the most efficient one that can provide revokable anonymity. 2.2
A priori countermeasures A priori countermeasures attempt to prevent the generation of fraudulent messages. This approach is based on the assumption that most users are honest and will not endorse any message containing false data. Another implicit assumption is the usual common sense that, the more people endorse a message, the more trustworthy it is. Along this research line, the schemes in [GGS04,ODS07,PP05,RAH06,DDSV08] exploit the assumption that there is a majority of honest vehicles in VANETs. Hence, these schemes introduce some form of threshold mechanism: a message is trusted if it has been verifiably endorsed by a number of vehicles above a certain threshold. Among these schemes, the proposals in [DDSV08] may be the most efficient while enabling anonymity of message originators. But their scheme does not provide anonymity revocability, which may not suit some applications in which anonymity must be revoked “for the prevention, investigation, detection and prosecution of serious criminal offences”[EP05]. 3
Discussion Unfortunately, neither a posteriori nor a priori countermeasures are solely sufficient to secure VANETs. By taking strict punitive action, a posteriori countermeasures can exclude some rational attackers producing bogus messages to obtain benefits or pranks. However, they are ineffective against irrational attackers such as terrorists. Even for rational attackers, damage has already occurred when punitive action is taken. It seems that a priori countermeasures function better in this case because they prevent damage beforehand by letting the vehicles trust only messages endorsed by a number of vehicles. Although the underlying assumption that there is a majority of honest vehicles in VANETs generally holds, it cannot be excluded that a number of malicious vehicles greater than or equal to the threshold are present in specific locations, for instance. For example, this is very plausible if some criminal organization undertakes to divert traffic from a certain area by broadcasting messages informing that a road is barred. Furthermore, for convenience in implementation, existing schemes use an even stronger assumption that the number of honest vehicles in all cases should be at least a preset threshold. But such a universally valid threshold does not exist in practice. Indeed, the threshold should somehow take the traffic density and the message scope into account: a low density of vehicles calls for a lower threshold, whereas a high density and a message relevant to the whole traffic of a city requires a sufficiently high threshold.
The situation is aggravated by the anonymity technologies used some proposals. A system preserves anonymity when it does not require the identity of its users to be disclosed. Without anonymity, attackers can trace all the vehicles by monitoring the communication in VANETs, which in turn can enable the attackers to mount serious attacks against specific targets. Hence, anonymity is a critical concern in VANETs. However, anonymity can also weaken a posteriori and a priori countermeasures. Indeed, attackers can send fraudulent messages without fear of being caught due to anonymity, and as a result, no punitive action can be taken against them. Furthermore, some proposals provide strong anonymity, i.e. unlinkability. Unlinkability implies that a verifier cannot distinguish whether two signatures come from the same vehicle or two vehicles. This feature may enable malicious vehicles to mount the so-called Sybil attack: a vehicle generates a fraudulent message and then endorses the message herself by computing on it as many signatures as required by the threshold in use; since signatures are unlinkable, no one can find out that all of them come from the same vehicle. Hence, elegantly designed protocols are required to secure VANETs when incorporating anonymity. 4
Towards a combination of a priori and a posteriori countermeasures Bearing in mind that enhancing safety and traffic efficiency is one of the main thrusts behind VANETs, we propose a new efficient system to balance public safety and vehicle privacy. Both a priori and a posteriori countermeasures are resorted to in order to thwart attackers. To the best of our knowledge, ours is the first system equipped with both types of countermeasures. We achieve this goal by drawing on the novel technology of message-linkable group signatures (MLGS). In an MLGS scheme, a vehicle stays anonymous if it produces two signatures on two different messages. However, if it produces two signatures on the same message, then it will be identified, which effectively thwarts the Sybil attack in a privacy-preserving system. This novel technology also enables us to realize a threshold-adaptive authentication in which the threshold can adaptively change in light of the context of messages, instead of having to be preset during the system design stage. Furthermore, a fast batch verification method is presented to speed up the validation of authenticated messages. Since vehicles periodically receive a large number of messages to be validated, such a batch verification is critical to make authentication implementable in VANETs. Details on the new scheme will be given in [WD08].
Acknowledgments and disclaimer This work was partly supported by the Spanish Government through projects CONSOLIDER INGENIO 2010 CSD2007-00004 “ARES” and
TSI2007-65406-C03-01 “E-AEGIS”, and by the Government of Catalonia under grant 2005 SGR 00446. The authors are with the UNESCO Chair in Data Privacy, but their views do not necessarily reflect the position of UNESCO nor commit that organization. processed in connection with the provision of public electronic communication services and amending Directive 2002/58/EC (COM(2005)0438 C6-0293/2005 2005/0182(COD)), 2005 [WD08] Q. Wu and J. Domingo-Ferrer. Improved trustworthiness of vehicular communications with a priori and a posteriori countermeasures. Manuscript in preparation, 2008. Location Privacy in Location-Based Services:
Beyond TTP-based Schemes Agusti Solanas, Josep Domingo-Ferrer, and Antoni Marıtn´e z-Balleset´
Rovira i Virgili University Department of Computer Engineering and Maths
UNESCO Chair in Data Privacy
Av. Pıas¨os Catalans 26
E-43007 Tarragona, Catalonia, Spain { agusti.solanas,josep.domingo,antoni.martinez} @urv.cat Abstract. Location-Based Services (LBS) are gaining importance due to the advances in mobile networks and positioning technologies. Nevertheless, the wide deployment of LBS can jeopardise the privacy of their users, so ensuring user privacy is paramount to the success of those services. This article surveys the most relevant techniques for guaranteeing location privacy to LBS users. The rigid dichotomy between schemes which rely on Trusted Third Parties (TTP-based) and those wh ich do not (TTP-free) is emphasised. Also, the convenience of both approaches is discussed and some ideas on the future of location privacy in these services are sketched.
Keywords: Anonymisation/pseudonymisation in LBS, Trust management in LBS. 1
Introduction
The Information Society rests on the Information and Communications
Technologies (ICT). Location-Based Services (LBS) are becomin g an important ICT
and will be eventually available anywhere anytime. LBS provide users with highly
personalised information accessible by means of a variety of mobile devices that
are able to locate themselves, e.g. by using a GPS or a fixed network
infrastructure with GSM [1]. Mobile devices are ubiquitous and services related to the
users’ current location proliferate. Examples of LBS are lo cation-based tourist
information [
The extensive deployment of ubiquitous technology is not without privacy
drawbacks. By sending their locations, LBS users could endanger their security
and privacy because, for example, an attacker could determine their location and
track them. This tracking capability of attackers opens up many computer-aided
crime possibilities (harassment, car theft, kidnapping, etc.). Also, if an attacker
impersonates an LBS provider, the traffic patterns of LBS users could be
influenced by false information, and the users’ location could be compromised [
Several countries have taken legal initiative to cope with privacy problems
related to electronic communications. In Europe, the European directive on Data
Protection and Privacy [
Although there are many other relevant topics related to LBS (e.g profile
anonymisation [
Contribution and plan of this article In this article, we provide a survey of the most relevant and recent schemes designed to offer location privacy to LBS users. We analyse, organise and classify them in two main groups: (i) TTP-based schemes and (ii) TTP-f ree schemes. Moreover, we sketch some ideas on the future of location privacy in LBS and some lines for future research.
The rest of the article is organised as follows. In Section 2 we suggest a classification of the methods for location privacy in LBS proposed in the literature. Section 3 is devoted to the analysis of TTP-based schemes and Section 4 studies TTP-free approaches. Finally, Section 5 contains a brief di scussion and some suggestions for future research. 2
Classification of methods for location privacy in LBS In the simplest form of communication between an LBS user (U ) and an LBS provider (P ), the former sends a simple query (Q) containing an ID, his location (L) and a request for information (I) that he wants to retrieve from P . Thus, a simple query sent from U to P can be Q = { IDU , L, I} = { IDU , xU , yU , “Where is the closest bus station?” } (cf. Figure 1.A). By sending their current locations to P , LBS users assume that P manages their data honestly and refrains from any misuse. However, LBS providers cannot always be trusted and more complex communication schemes are needed.
Most of the solutions proposed in the literature to address the location privacy problem are based on Trusted Third Parties (TTP), i.e. entities which fully guarantee the privacy of their users. Although this approach is widely accepted, it simply moves users’ trust from LBS providers to intermedi ate entities. By doing so, LBS providers are no longer aware of the real locations and identities of the users; trust and, by extension, power are handed over to intermediate entities such as brokers, pseudonymisers or anonymisers. The problem is that users are not necessarily satisfied by completely trusting intermediate entities or providers, especially after the recent scandals related to the disclosure of personal data by this kind of trusted entities1 (cf. Figure 1.B).
The main difference between the simple communication scheme and the TTPbased one is that in the latter the set of intermediate entities can be expected to be smaller than the number of service providers. Therefore, intermediate entities can be well-known and the risk of trusting a dishonest entity is lessened. However, due to the above mentioned scandals, many users would prefer to trust 1 In Autumn 2007, several data privacy disasters happened in the UK connected to Her Majestys’ Revenue and Customs. Two computer disks full o f personal data on 25 million British individuals disappeared; HMRC also lost another disk containing pension records of 15,000 people and a laptop containing personal data on 400 people. In 2006 in the U.S, data on 26.5 million people were stolen from the home of an employee of the Department of Veterans Affairs, and queries by 658,000 users were disclosed by the AOL search engine.
LBS Privacy Methods TTP-based
TTP-free Simple
Policy-based
PIR-based Pseudonym-based
Anonymity-based
Collaboration-based Obfuscation-based nobody, which leads to TTP-free schemes. These represent a s ubstantial change of paradigm (cf. Figure 1.C). Instead of trusting a third party, users collaborate to protect their privacy. As it is explained in Section 4, there is not even need to trust the users one collaborates with. Figure 2 depicts our proposed classification of location privacy methods. The main aim of the classification is to emphasise the rigid dichotomy between these two paradigms: (i) TTP-ba sed methods and (ii) TTP-free methods. In the following sections we review s ome of the most relevant representatives of TTP-based and TTP-free method s. 3
Privacy in TTPb-ased schemes TTP-based schemes are very common because they are easy to un derstand/develop, and because, in general, they offer a reasonable trade-off bet ween efficiency, accuracy and privacy. Moreover, some of the ideas used in these schemes arose in more mature fields like e-commerce.
In the simple scheme described in Section 2, users send their location information and queries directly to the LBS provider. In this scheme, whatever location privacy LBS users can get depends on the honest behaviour of the LBS provider.
In the following sections we concentrate on some TTP-based s chemes that aim to protect the location privacy of the users. 3.1
Policy-based schemes Policy-based schemes are one step forward in LBS privacy wit h respect to the simple scheme. Although the conceptual framework is the same (i.e. a user submits queries to a provider), in this case, providers adhere to a set of privacy policies known by users. Hence, if providers do not properly follow their privacy policies, users have the right to ask for a compensation and/or take legal action against providers.
Privacy policies are legal notices that contain statements defining what
service providers can do with their users’ personal data. Priva cy policies are
published by service providers, and users decide whether such policies are acceptable
to them. These policies refer to many concepts and specific languages are used
to define them [
These schemes are widely used on the Internet by e.g. e-comme rce sites which
define their privacy policies in e.g. P3P (Platform for Privacy Preferences) [
Pseudonymisers Pseudonymisers are the simplest intermediate entity between LBS users and providers. Pseudonymisers receive queries from users and, prior to forwarding them to LBS providers, they replace the real IDs of the users by fake ones (i.e. pseudonyms). In this way, the real user IDs remain hidden to the provider, but pseudonymisers must store the real IDs and their corresponding pseudonyms in order to forward the answers from the providers to the users. Clearly, users must completely trust pseudonymisers, because the latter see all the location information on the former.
The main problem of this technique is that an attacker (e.g. the LBS provider
herself) can infer the real identity of the user by linking the user location with
e.g. a public telephone directory (e.g. by using the aforementioned RSI or OI
attacks [
Anonymisers Anonymisers are the most sophisticated option in TTP-based location privacy. Instead of taking care of policies or users’ identifiers, ano nymisers assume that communications are anonymous, i.e. LBS providers do not require an ID to answer queries2. Anonymisers aim to hide users true identity with respect to emitted location information. In this section we concentrate on techniques that hide the location information of users and we assume that identifier abstraction is already guaranteed. 2 If this assumption was not made, it would be easy to track a given LBS user by simply checking the ID or the pseudonym (like in the case of pseudonymisers).
A very common way to hide the real location of the users from the LBS
provider is by using the k-anonymity property. k-Anonymity is an interesting
approach to face the conflict between information loss and disclosure risk, suggested
by Samarati and Sweeney [
Many examples of this kind of approach and other similar ones based on
cloaking can be found in the literature [
In [
Current research on anonymisers focuses on improving the efficiency of the intermediaries and designing highly personalised services able to guarantee the privacy of the users. 4
Privacy in TTPf-ree schemes Due to the shortcomings of the TTP-based schemes, other meth ods that do not rely on TTPs have been proposed. First, we consider the collaboration methods that aim to obtain the same results (e.g. k-anonymity, l-diversity, efficiency) than the ones based on TTP. Then, we pay attention to the methods based on the obfuscation of the real location without collaboration. Finally we point out a new location privacy trend based on Private Information Retrieval (PIR). 4.1
Collaboration-based methods
In [
In [
Obfuscation-based methods
Obfuscation is a TTP-free alternative to collaboration-ba sed methods.
Obfuscation can be understood as the process of degrading the quality of information
about a users’ location, with the aim to protect that users’ p rivacy [
In [
SpaceTwist [38] is the most recent proposal for non-collabo rative TTP-free location privacy. SpaceTwist generates an anchor (i.e. a fake point) that is used to retrieve information on the k nearest points of interest from the LBS provider. After successive queries to the LBS provider, SpaceTwist is able to determine the closest interest point to the real location whilst the LBS provider cannot derive the real location of the user. The main advantages of this method are: (i) no TTP and no collaboration are needed; (ii) the closest interest point is always found; (iii) the location of the user is hidden in a controlled area. However, due to the lack of collaboration, this method is not able to achieve the k-anonymity and/or the l-diversity properties. 4.3
PIR-based methods A totally different approach to TTP-free LBS privacy is propo sed in [39]. In that article, Private Information Retrieval (PIR) is used to provide LBS users with location privacy. Although the idea of using PIR techniques is promising, the proposed approach requires the LBS provider to co-opera te with users by following the PIR protocol; this prevents the use of this method in real environments, where LBS providers simply answer queries containing a location or an area without any regard for location privacy. However, if this shortcoming was solved and without significant computation and efficiency penalties, using collaborative PIR amongst peers (i.e. users) could be a really promising future research line. 5
Discussion and future work In the above sections we have reviewed some of the most recent and relevant contributions to location privacy protection in LBS. There is a clear distinction between TTP-based schemes and the TTP-free ones. Altho ugh TTP-based schemes are the most common ones, TTP-free schemes seem supe rior in terms of privacy due to the following shortcomings of intermediate TTPs: (i) TTPs are critical points which can be attacked; (ii) TTPs are bottlenecks; (iii) There must be many users subscribed to a TTP for the latter to be able to compute suitable cloaking regions (offering sufficient privacy and accuracy).
In general TTP-based schemes are weak because users rely on a single trusted entity. This entity can be impersonated by a bogus TTP created by the attacker, in which case all the information shared by users with the bogus TTP falls in the hands of the attacker. A way to mount such an attack is to tamper with transmitters or use a more powerful signal.
Despite being inferior regarding privacy, TTP-based schem es are easier to implement than collaborative-based methods because all th e infrastructure required by users to circumvent the use of a TTP is not necessary. However, obfuscation-based methods are also easy to implement. We be lieve that there is room in the market for both approaches.
The use of k-anonymity and l-diversity properties must be carefully considered because in some scenarios they are insufficient to preserve users’ privacy [40]. In our opinion, there are a lot of opportunities for synergy between future work in PIR and TTP-free LBS privacy. Indeed, current PIR techniq ues face the (very serious) limitation of needing co-operation from the datab ase server in following the PIR protocol. If practical PIR protocols are developed which do not need such a co-operation, it will be possible to use them for TTP-f ree location privacy: if a query can be submitted to a non-co-operative commercial LBS server in such a way that the latter does not learn what the query is about (i.e. the location supplied by the user), then one obtains a TTP-free LBS privac y protocol. Acknowledgements The authors are solely responsible for the views expressed in this article, which do not necessarily reflect the position of UNESCO nor commit that organisation. This work was partly supported by the Spanish Ministry of Education through
In First International Conference on Security in Pervasive Computing, Boppard, Germany, March 12–14, 2003, Revised Papers , volume 2802 of LNCS, pages 50–59. Springer Verlag, 2003. The CURUPIRA-2
Block Cipher for Constrained
Platforms: Specication and Benchmarking Marcos Simpclio Jr 1, Paulo S. L. M. Barreto 1 ?, Tereza C. M. B. Carvalho 1,
Cintia B Margi1, and Mats Naslund 2 1Laboratory of Computer Architecture and Networks, PCS-EP, University of Sa~o
Paulo, Brazil {mjunior,pbarreto,carvalho,cbmargi}@larc.usp.br 2Ericsson Research - Stockholm, Sweden
mats.naslund@ericsson.com Abstract. Privacy is a key concern in Location Based Applications (LBAs), especially due to their intensive use resource constrained devices in which general purpose ciphers are dicult to deploy. In this paper, we address this issue by specifying a new, faster key-schedule algorithm for the Curupira block cipher. This special-purpose cipher follows the Wide Trail Strategy (such as AES) and is tailored for resource-constrained platforms, such as sensors and mobile devices. Furthermore, we present our benchmark results for both the Curupira-1 (which adopts the original key-schedule specication) and the Curupira-2 (which adopts the new one) in appropriate testbeds.
Keywords: location based services, symmetric cryptography, involutional block ciphers, sensor networks, constrained platforms, ciphers benchmark. 1 The continuous and widespread development of context-aware applications based on Wireless Sensor Networks (WSNs) shows their potential to allow a high level of integration between computers and the physical environment. LocationBased Applications (LBAs) play an important role in this scenario, automatically adapting their behaviors to the available geo-spatial location information and the nearby sensors and devices. This way, these systems are able to provide both novel and more eective services. However, due to the sensitive nature of the data involved (both location information and other data collected by the network nodes) the security of the communication in these applications is an important concern.
Battery-powered sensor nodes and other limited platforms normally
employed in LBAs impose several constraints over the cryptographic algorithms
? Supported by the Brazilian National Council for Scientic and Technological
Development (CNPq) under grant 312005/2006-7. yThis work was supported by the
Research and Development Centre, Ericsson. Telecomunicaco~es S.A., Brazil
that can be eectively deployed. For example, commercial motes usually have a
memory size of 8-12 KB for code and 512-4096 bytes of RAM, as well as 4-16 MHz
processors [
To date, many architectures have been proposed to provide security in WSNs.
One of the most popular is TinySec [
The literature includes numerous analyses of modern cryptographic
algorithms, aiming to identify those well-suited to WSNs both in terms of security
and performance. One of the most extensive is presented by [
An alternative to address these issues is the adoption of Curupira [
In this paper, we propose a new, faster key-schedule algorithm for the Curupira algorithm and analyze its security. We also present a benchmark comparing Skipjack, AES and Curupira in relevant platforms. In order to discern between the two versions of the Curupira cipher, we write ‘ Curupira-1" for the one adopting the original key-schedule and \ Curupira-2" for the new specication. We write simply \ Curupira" when the discussion applies to both.
This document is organized as follows. We introduce basic mathematical tools and notation in section 2. An overview of the Curupira-1, including its keyschedule algorithm, is given in section 3. The second version of the key-schedule is presented in section 4, which also discuss security, performance and implementation issues for the resultant Curupira-2 block cipher. Our benchmark results are presented in section 5. We conclude in section 6. 2
Mathematical preliminaries and notation The nite eld GF(2 n) will be represented as GF(2)[ x]=pn(x), where pn(x) is a primitive pentanomial of degree n over GF(2), i.e. deg( pn(x)) n. This way, all multiplications over GF(2 8) are made modulo p8(x) = x8 + x6 + x3 + x2 + 1. This choice of p8(x) incurs in a simple form for the primitive cube root of unity, c(x) = x85 mod p8(x) = x4 + x3 + x2.
An element u = u7x7 +: : :+uixi +: : :+u0 of GF(28) where ui 2 GF(2) for all i = 0; : : : ; 7, will be denoted by the numerical value u7 27 + : : : + ui 2i + : : : + u0, written in hexadecimal notation. Thus, the polynomial c(x) is written 1C, while p8(x) is written 14D. The multiplication by the polynomials x and c(x) are denoted xtimes and ctimes, respectively.
The set of all 3 n matrices over GF(2 m) is denoted by Mn. Let D and E
denote the MDS matrices (see [
3 3 2 2 1+c(x) c(x) c(x) D = 4 4 5 4 5 ; E = 4 c(x) 1+c(x) c(x) 5 :
6 6 7 c(x) c(x) 1+c(x) 3
Overview of the CURUPIRA-1 structure
This section gives a brief description of the Curupira-1 original specication.
For further details, we refer to [
The Curupira is a block cipher specially tailored for constrained platforms.
It operates on 96-bit data blocks (organized as M4 matrices, mapped by columns
instead of by rows) and accepts 96-, 144- or 192-bit keys, with a variable number
of rounds. The cipher round structure is similar to the one in BKSQ [
S-Box, identical to that used in Anubis [
D (the one dened in section 2), which results in intra-columnar diusion; { Permutation Layer ( ): all the bytes in the second and third rows of the block are permuted according to the rule (a) = b , bi;j = ai;i j ; 0 6 i < 3; 0 6 j < n; { Key addition Layer ( ): the round key is XORed with the block.
Fig. 1. Curupira Round Structure
These transforms only involve basic operations such as table lookups, XORs and byte shifts. Thus, they can be implemented in most platforms in a very ecient way. Nonetheless, when space is available, they can be further accelerated using pre-computed tables, operating over entire columns of the block instead of byte-to-byte.
The CURUPIRA-1 key-schedule The Curupira-1 key-schedule algorithm is easily invertible and follows a structure closely related to the one dictated by the Wide Trail Strategy, which assures a high diusion speed. Also, it has the advantage of being cyclical, which means that the original key is recovered after a certain number of rounds, avoiding the need of storing any intermediary sub-key during both encryption and decryption.
In this rst construction, a 48 t-bit user key K, 2 6 t 6 4 is internally represented as a matrix K 2 M2t. To generate a sub-key Kn+1 from its predecessor Kn, the sub-keys pass through three dierent transformations (illustrated in Figure 2): { Constant Addition ( (q)): a set of nonlinear constants, incrementally taken from the S-Box, are XORed with the bytes in the rst row of the round key; this way, for a 48t-bit key, the rth round and the column j, the qj(r) constant is given by: qj(0) = 0 and qj(r) = S[2t(r 1) + j], 0 6 j 6 2t; { Cyclic Shift ( ): rotates the second row one position to the left, and rotates the third row one position to the right, keeping the rst row unchanged; { Linear Diusion ( ): the round-key is left-multiplied by the matrix E (dened in section 2).
Furthermore, the round keys (r) eectively combined with the data blocks are chosen by the Key Selection algorithm r, which applies the S-Box to the rst row of the sub-key Kr and truncates it to 96 bits (i.e., the size of the block). Thus, even if the Key Selection is not part of the key evolution, it adds nonlinearity to the key-schedule. 4
The CURUPIRA-2 key-schedule The Curupira-1 key-schedule specication is quite conservative, aiming for a high security level against related-key attacks. Thus, it is reasonable to adopt a simpler yet secure key-schedule algorithm in order to improve the overall cipher performance. That is the approach of the Curupira-2 key-schedule, which will be described in the following sections. A 48t-bits long user key K (2 6 t 6 4) is internally represented as an element K belonging to the nite eld GF(2 48t) = GF(2)=p48t(x), where p48t(x) is a pentanomial in GF(2) chosen in such a way that x8 is a primitive root of p(x). An element u(x) in this eld can be seen as a byte vector, i.e. u = (U6t 1; : : : ; U0), where U0 indicates the lesser signicant byte. This way, the cryptographic key K is directly mapped to K, starting at its most signicant byte, K6t 1.
A pentanomial representation was chosen because primitive pentanomials are
available for all values of t used by the Curupira. In fact, the use of trinomials
would result in a better performance, but unfortunately they do not exist for
elds of type GF(2 n) when n is multiple of 8 [
For reasons that will become clearer in section 4.3, the pentanomials chosen for Curupira-2 are: { p96(x) = x96 + x16 + x13 + x11 + 1; { p144(x) = x144 + x56 + x53 + x51 + 1; { p192(x) = x192 + x43 + x41 + x40 + 1: The schedule constants are denoted q(s), where the index (s) indicates the round in which they are applied. As in the Curupira-1, the constants are directly taken from the S-box and, thus, no extra storage is needed. This time, however, they are interpreted as elements of GF(2 48t) in such a way that q(0) = 0 and, for s > 0, q(s) = (S[s 1]; 0 : : : ; 0) i.e. a single S-box output is mapped to the most signicant byte of q(s). As shown in the next section, this is a strategic position that makes each constant aect exactly 3 bytes of the round key right after its addition. The sub-keys are updated during the cipher operation by means of two operations: a reversible transform, @ : GF(248t) ! GF(248t); and an auto-inverse transform : GF(248t) ! GF(248t). They are dened in such a way that @(u) u x8 and, for the polynomials u = (U6t 1; : : : ; U0) and v = (V6t 1; : : : ; V0) in GF(248t) :
Vi = U11 i Vi = Ui
U12+i if 0 6 i < 6t otherwise: 12;
Together with the schedule constants, these transforms compose the key evolution function r : GF(248t) ! GF(248t), dened as r(u) @ (u q(r)), in such a way that K(0) K and K(r+1) = r(K(r)).
The transform is used to ensure a greater diusion to the schedule when keys greater than 96 bits are adopted, since it combines some of the least signicant bytes of the key with the most signicant ones. Without this operation, two 144-bit keys diering only at the byte K11 would generate sub-keys whose 12 least signicant bytes would be identical for the rst 6 rounds; also, for 192bit keys, this result would hold true for the rst 12 sub-keys. As these least signicant bytes are the ones actually selected in each round, the eect of the transform is essential to assure a higher diusion speed for 144- and 192-bit keys.
Also, the @ transform is particularly interesting due to its performance, specially on resource-constrained platforms, as stated in the following theorem: Theorem 1. Let p(x) = xn + xk3 + xk2 + xk1 + 1 be a primitive pentanomial of degree n = bw over GF(2) such that k3 > k2 > k1, k3 k1 6 w, and either k3 mod w = 0 or k1 mod w = 0. Then multiplication by xw in GF(2n) = GF(2)[x]=p(x) can be implemented with no more than 5 XORs and 4 shifts on w-bit words. Moreover, if 2 2w bytes of storage are available, the cost drops to no more than 2 XORs on w-bit words and 2 table lookups.
Proof. For u = Ldn=01 (udxd) 2 GF(2n), let Ui = uwi+w 1xw 1 + : : : + uwi where i = 0; : : : ; b 1, so that u = Ub 1xw(b 1) + Ub 2xw(b 2) + : : : + U0, which for brevity we write u = (Ub 1; : : : ; U0). Then one can compute u xw as: (Ub 1xw(b 1) + Ub 2xw(b 2) + : : : + U0) xw = Ub 1xn + Ub 2xw(b 1) + : : : + U0xw = Ub 2xw(b 1) + : : : + U0xw + Ub 1(xk3 + xk2 + xk1 + 1) = (Ub 2; : : : ; U0; Ub 1) Ub 1(xk3 + xk2 + xk1 ):
Assume that k3 = w(k + 1) for some k; the case k1 mod w = 0 is handled analogously. Thus: u xw = (Ub 2; : : : ; U0; Ub 1)
Ub 1(xw + xw k3+k2 + xw k3+k1 )xwk
Since deg(Ub 1) 6 w 1 and deg(xw + xw k3+k2 + xw k3+k1 ) = w, their product is a polynomial of degree not exceeding 2 w 1, and hence it ts two w-bit words for any value of Ub 1. Besides, multiplication of this value by xwk corresponds to simply displacing it k words to the left. We can dene: T1[U ] T0[U ]
U (U k3 + k2)))
Thus, we can write u xw = (Ub 2; : : : ; Uk T1[Ub 1]; Uk 1 T0[Ub 1]; : : : ; U0; Ub 1). The values T1 and T0 can be either computed on demand or else pre-computed and stored in two 2w-entry tables. One easily sees by direct inspection that the computational cost is that stated by the theorem.
Applying this theorem for the polynomials adopted by the Curupira-2, we can evaluate the cost of the transforms @ and its inverse: p96(x) = x96 + x16 + x13 + x11 + 1 : @ : (U11; : : : ; U0) x8 = (U10; : : : ; U1 T1[U11]; U0 @ 1 : (U11; : : : ; U0) x 8 = (U0; U11; : : : ; U2 T1[U0]; U1 T0[U11]; U11);
T0[U0]); p144(x) = x144 + x56 + x53 + x51 + 1 : @ : (U17; : : : ; U0) x8 = (U16; : : : ; U6 T1[U17]; U5 @ 1 : (U17; : : : ; U0) x 8 = (U0; U17; : : : ; U7 T1[U0]; U6 p192(x) = x192 + x48 + x45 + x43 + 1 : @ : (U23; : : : ; U0) x8 = (U22; : : : ; U5 T1[U23]; U 4 @ 1 : (U23; : : : ; U0) x 8 = (U0; U23; : : : ; U6 T1[U0]; U5 T0[U17]; : : : ; U0; U17);
T0[U0]; : : : ; U1); T0[U23]; : : : ; U0; U23):
T0[U0]; : : : ; U1):
For all key sizes, we have T0 = U (U 5) (U 3) and T1 = (U 3) (U 5).
These equations show that both @ and @ 1 transforms have the same cost and, thus, it is also valid for r and its inverse, r 1(u) (@ 1 (u)) q(r). In contrast, when compared to the key-schedule of the Curupira-1, this second schedule algorithm has one disadvantage: there is no simple way to reinitialize the key after a reduced number of rounds. However, in many applications, its higher speed both during encryption and decryption can be a much more interesting feature, compensating its lack of cyclicity. 4.4
The key selection
r The round keys (r) 2 Mn eectively used in each round are calculated by means of the key selection function r : GF(248t) ! Mn, dened in such a way that: (r) = r (K) , ( i(;rj) = S[Ki(+r)3j ] if i = 0; i(;rj) = Ki(+r)3j otherwise:
This way, only the 12 least signicant bytes are taken by r . Also, the S-box is applied to the bytes that will be combined with the rst row of the block, adding nonlinearity to the key-schedule, while the bytes for the other rows are taken directly. The whole process involved in this second version of the key-schedule algorithm is depicted in Figure 3.
Fig. 3. The new key-schedule specication (adopted by Curupira-2)
Security analysis revisited
Since, for both versions of our cipher, the round structure remains the same, most
of the Curupira-1 security analysis [6, section 4] also applies to the
Curupira2: the adoption of the Wide Trail Strategy in combination with a highly
nonlinear S-Box thwarts the most well known modalities of attacks, such as linear,
dierential and integral cryptanalysis. As a consequence, no attack faster than
exhaustive search was found for more than 7 rounds of the cipher. These results
were also conrmed by third party analysis [
Weak keys are keys that result in a block cipher mapping with detectable weaknesses, which normally occurs when the nonlinear operations depend on the actual key value. This is not the case for the Curupira, where keys are applied using XOR and all nonlinearity is xed in the S-box. Also, the nonlinear round constants considerably reduce the probability of xed points in the key-schedule process, making the existence of weak keys very unlikely.
Related-key attacks exploit a known relationship between dierent unknown
keys, leading to a predictable behavior for the sub-keys generated by the key
schedule. Some of the most widespread techniques involve key dierentials and
key rotations (cf. [
Furthermore, for key lengths that are larger than the length of one round key, the existence of sets of keys that produce identical values for at least one round key is inevitable. Thus, even if the transform adds diusion power to the key-schedule and prevents the existence of trivial sets with this property, they should be more easy to nd than in the Curupira-1. Even so, it remains unclear how such keys could possibly be successfully used in a related-key attack.
As a last remark, the Curupira structure involves only simple operations
such as XORs, shifts and table lookups. As long as the running times for these
transforms are not data-dependent on the target platform, the cipher
implementation can avoid many side-channel attacks (such as timing-attacks [
Implementation and Performance Issues The Curupira-2 algorithm is very exible in terms of implementation, oering many memory/performance trade-os. It cannot only use the same techniques developed for the Curupira-1 round functions [6, section 5]. These include the usage of a few tables with pre-computed results, but its key-schedule also allow some useful optimizations depending on resources available.
The round keys can be either computed on-demand or fully pre-calculated and stored in a table for ready access. In the rst case, the cipher requires a reduced amount of RAM memory, since only one sub-key is stored at any given time. However, as the key-schedule of Curupira-2 is not cyclic, there is no easy way to compute the rst round key from the last one. An easy way to overcome this problem is to use two arrays ka and kb to store the rst and the last subkeys, respectively: when one wants to encrypt, it suces to copy ka into kb and reuses ka memory space to create the encryption sub-keys; in the end, ka will have the last key while kb will store the rst one, assuring that both sub-keys are always available. The decryption is handled analogously. In this case, the last sub-key could be computed during the cipher initialization. We note that this strategy is only possible because the key schedule is easily invertible.
For 6t-byte keys (2 6 t 6 4), the round sub-keys can be calculated in any direction at the cost of one circular permutation, 2+6(t-2) XORs and one computation of T0 and T1. Also, T0 and T1 can be either implemented using two 256-bit tables or calculated on-the-y, taking 1 XOR + 2 shifts and 2 XORs + 2 shifts, respectively. In fact, the circular permutation does not need to be eectively implemented: the same eect can be achieved if the index corresponding to the most signicant byte of the key is stored and used as the rst byte of the key for every calculation; this way, it suces to update this index after each invocation of the @ and @ 1 operations.
Reviewing the Curupira preliminary calculations [6, section 5.1], the cost of its round function is 3 R 1 XORs, 2(R 1)=3 xtimes operations and R S-box lookups per byte. When the key-schedule and key selection are taken into account, we add at most 1 =3 S-Box lookups, 1 =3 ctimes operations and 2 XORs per key byte and per round in the Curupira-1, while this cost drops to at most 5=12 S-Box lookups, 5 =8 XORs and 1=12 computations of T0 and T1 per key byte and per round in the Curupira-2. In comparison, Skipjack takes basically 48 XORs and 16 F-table lookups per encrypted byte. Thus, supposing that the cost of any of these basic operations are approximately the same and not counting auxiliary operations not directly related to the ciphers structures (such as counter increments and key index updates), Curupira-1 with 96-bit keys and 10 rounds is about (45 + 27) =64 112:5% as Skipjack when the round keys computed on demand. On the other hand, Curupira-2 with the same keysize corresponds to (45 + 7 :5)=64 82% of Skipjack computation in the same conditions. This result should be expected for similar implementations of both ciphers on byte-oriented platforms.
Furthermore, more powerful processors (32-bit servers, for example) could
implement the s transform in a more ecient way, operating over columns
instead of bytes. Also, the multiplication by x8 can be easily implemented using
a single table that calculates T0 and T1 at the same time, an approach similar
to those adopted in some very optimized versions of AES [
Benchmark
In this section, we present the results of our comparison between Curupira,
Skipjack and AES in terms of processing time and memory usage. As discussed
in section 1, the motivation behind the choice of Skipjack resides in the results
presented in [
For the implementation running on Avrora, as recommended by its documentation, we adopted avr-objdump and avr-gcc (both GNU utilities) as compilation tools, while MPLAB IDE v7.60 and MPLAB C18 compiler are used together with the PIC microcontroller. The speed-optimized versions of each cipher, resulting from the available compiler optimizations, are the ones considered in this document. It is important to notice that, even if both platforms include indirect addressing in their instruction sets, our tests showed that the compilers were not able to fully take advantage of these instructions, resulting in less than optimal machine codes when pointers and/or matrices were used. That is the reason why we decided to evaluate two dierent programming techniques: one that uses pointers and matrices and another that uses basic-type variables more intensively, avoiding indirect addressing. While the rst approach normally results in more exible code (where the size of the keys can be more easily changed, for example), the second allows more optimized implementations with xed-size keys (enabling loop unrolling with little loss of compactness)
The implementations running on the 8-bit platforms are detailed below:
CURUPIRA (8 bits) using the proposed optimizations for constrained platforms, we elected two versions of the Curupira for each scheduling algorithm: 1. Curupirac-1: complete version (meaning that it accepts all key sizes) of the Curupira-1. It requires two 256-byte tables, one for the S-Box and another for the ctimes operation and uses many pointers and matrices 2. Curupirac-2: complete version of the Curupira-2, using two 256-byte tables for the S-Box and xtimes operations. Such as Curupirac-1, it is also based on indirect addressing instructions. 3. Curupirak96 -1: Curupira-1 restricted to 96-bit keys. It uses the same tables as the Curupirac-1, but relies on basic types instead of indirect addressing instructions. 4. Curupirak96 -2: Curupira-2 restricted to 96-bit keys, using the same tables as the Curupirac-2 but relying on basic-type variables.
Skipjack (8 bits) two versions were developed according to the specication: 1. Skipjackc: relies on indirect instructions just like Curupirac-1 and Curupirac-2, providing a useful source of comparison with these ciphers. It uses a single 256-byte F-table and calculates the round keys on demand. 2. Skipjackk: adopts programming strategies similar to those present in the Curupirak96 , strongly relying on operations over basic-type variables instead of matrices and pointers. Such as the Skipjack c, it also uses a 256-byte F-table and calculates the round keys on-the-y.
For the 32-bits platform, we decided to take advantage of some highly
optimized cipher implementations publicly available. The chosen algorithms, written
in Java, were compiled and run on Netbeans IDE 5.5, using the JDK 1.6. The
details of the implementations are given below:
AES (32 bits) we adopted the implementation of Barreto [
CURUPIRA (32 bits) the optimizations in the algorithm are similar to those present in AES, specially regarding the pre-computation of the round keys and the intensive use of tables, in the same number as AES.
Skipjack (32 bits) the cipher tested is a Java adaptation of Barreto’s
algorithm [
Results: 8-bits platforms The ciphers memory usage, for both 8-bit platforms, is presented in Table 1. This table shows that all tested versions of the Curupira take more space in memory than Skipjack, an expected result considering the higher complexity of its round function and key-schedule algorithms. Despite this dierence, the tested ciphers Algorithm Curupirac-1 Curupirac-2 Curupirak96 -1 Curupirak96 -2 Skipjackc Skipjackk are both compact enough to be easily deployed in most constrained platforms, taking less than 3KB as a whole.
Both Curupira and Skipjack do not need to pre-compute the round keys and, thus, they require a reduced amount of RAM. We were not able, however, to directly measure the RAM usage with the tools available for the tested platforms. Nevertheless, due to its greater block and key size, we speculate that Curupira takes a higher amount of RAM than Skipjack. For example, when using two arrays to store the rst and the last keys, Curupira-2 would take about twice ((96 + 2 96)=(64 + 80)) the amount of RAM needed by Skipjack. These numbers remain very tiny when compared to pre-computed keys storage, though.
For the PIC microcontroller, Figure 4 shows the number of CPU cycles, per byte encrypted, of both tested ciphers. The time measured corresponds to a single encryption of random blocks using dierent keys. Even if the Curupirac implementations allow three dierent key sizes, only the 96-bit keys are depicted in this graph. Also, we explicitly distinguish the processing time required for the key scheduling and the encryption itself (as Skipjack reuses the original key cyclically, we considered it part of the encryption instead of a \key-schedule").
Fig. 4. Comparison between the cipher encryption speeds on the PIC18F8490
The gure shows that Curupirac-1 and Curupirac-2 are respectively 20% and 45% faster than Skipjack c, with the round keys computed on demand. Despite this very positive result, it should be carefully considered since the measured number of cycles includes not only the operations directly involved in the encryption process but also a non-negligible number of auxiliary ones. The inuence of these secondary operations is less expressive on both Skipjack k and Curupirak96 and, as depicted in the right side of Figure 4, Curupirak96 -2 is still 18% faster than Skipjack, while Curupirak96 -1 is 12% slower. One can see that the cost of both Curupirak96 versions in this gure are approximately the ones theoretically calculated in Section 4.6.
The results on the Avrora Simulator were slightly dierent from those in the PIC18F8490, as depicted in Figure 5. Skipjack k speed was considerably improved by this platform change, running about 30% and 4% faster than Curupirak96 -1 and Curupirak96 -2, respectively. A further analysis of the assembly codes show that these results were caused by the inuence of the compiler, which were able to apply dierent optimizations to each algorithm. In contrast, this unexpected behavior was not observed with Curupirac and Skipjackc implementations, which sustained the relative performances presented on the PIC18F8490.
Results: 32-bits platforms The encryption speed of each cipher on the 32-bits platform, with dierent key sizes (and, thus, number of rounds), is depicted in Figure 6. It is important to point out that, as all round keys are computed at cipher initialization, there is no dierence between the encryption speeds of Curupira-1 and Curupira-2.
We obtained similar results for AES and Curupira with the same number of rounds (note the additional graph entry where, for the sake of comparison, both ciphers were tested with the same number of rounds for each key size). This is an expected result since both ciphers adopt well-known optimizations for the Wide Trail Strategy family. On the other hand, the modest result of Skipjack (about 3 times slower than the other ciphers) may seem surprising at rst sight, since its performance usually is the main factor for its adoption on constrained platforms. However, this can be explained by its 16-bit oriented operations, very attractive on constrained processors but less adapted to fully take advantage of the higher number of bits available on powerful platforms. Both AES and Curupira, though, can easily be implemented to operate over 32- and 24-bit words (columns), respectively.
The processing time involved on the ciphers key-schedules was also measured. As depicted in Figure 7, while Curupira and AES presented similar speeds, Skipjack was about 10 times slower. As this operation has to be performed a single time (at initialization), the impact on the cipher overall operation is reduced on scenarios where the keys are not frequently changed. 6
Conclusions We have described a new and faster key-schedule proposal for the Curupira block cipher. As a drawback, when compared to the original specication, it has a lower level of security against related-key attacks. However, according to our security analysis, both versions of the full cipher are secure against cryptanalysis.
We also presented a benchmark comparing Curupira, Skipjack and AES in terms of performance and memory occupation, both on constrained and powerful platforms. According to the results obtained, the proposed block cipher is fast and compact, especially when using the new key-schedule presented in this paper. While Skipjack is considered a good candidate for constrained scenarios, such as LBAs dependent on sensors and low-power mobile devices, Curupira is a suitable alternative to increase the security level and potentially improve performance, introducing a reduced impact in terms of memory usage. Also, when more powerful platforms are also available, the several optimizations allowed by the Curupira can be deployed to obtain an even higher performance in the whole network.
All together, these results show that the Curupira block cipher is a useful solution for providing data encryption at low cost, being recommended for constrained-resource devices and for applications based on such platforms, such as WSNs and LBAs.
Future and Ongoing work We are currently working on the deployment of Curupira on a real WSN in order to evaluate its impact (especially in terms of energy consumption) in some signicant scenarios. Also, we are developing a new MAC algorithm named Marvin, designed to provide a low-cost authenticated-encryption scheme on WSNs, particularly when used in conjunction with Curupira.
Acknowledgments We would like to thank Richard Gold for his useful comments and the review of this paper.
References 1. 3GPP. Specication of the 3gpp condentiality and integrity algorithms document 2: Kasumi specication. Technical report, 3GPP, 1999.
The name According to a Brazilian legend, the Curupira is a spirit of nature and protector of the forests. It assumes the form of a boy with red hair, whose feet are turned backwards. This way, when hunters think they are on the right trail to get it, they in fact are going to the wrong direction, getting confused and lost. This should also work against cryptanalysts :-). Ardagna, Claudio Agostino . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 Barreto, Paulo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123 Bettini, Claudio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24, 61 Carvalho, Tereza . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123 Domingo-Ferrer, Josep . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6, 12 Freni, Dario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 Jajodia, Sushil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61, 82 Margi, Cintia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123 Mart´ınez-Balleste´, Antoni . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 Martin, Rhandi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 Mascetti, Sergio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 Monreale, Anna . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 Na¨slund, Mats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123 Pareschi, Linda . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 Pedreschi, Dino . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 Pensa, Ruggero G. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 Pinelli, Fabio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 Riboni, Daniele . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 Sadeghi, Ahmad-Reza . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 Samarati, Pierangela . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 Simpl´ıcio, Marcos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123 Solanas, Agusti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 Stavrou, Angelos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 Visconti, Ivan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 Wachsmann, Christian . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 Wang, Sean . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 Wu, Qianhong . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6