Cryptographic Hardware & Embedded Systems for Communications Nicolas Sklavos, Member, IEEE, Invited Speaker
Index Terms— security, cryptography, computer architecture, system-on-a-chip, FPGA, ASIC, VLSI design, embedded systems, Arduino
II. DESIGN PROCESS: SYSTEM-ON-A-CHIP This paragraph is related to the basics of System-On-AChip design process, which contains the following sections: SoC design, design flow and design life through specifications [4-6]. A. SoC Design Let’s assume the design of a crypto-processor for a specific purpose like secure satellite communications, which is illustrated in the next Figure 1: Crypto-Processor Peripherals
Abstract— This work is related to System-On-A-Chip architectures and design methodologies, for cryptographic algorithms implementations. Alternative approaches are presented, for architecture and architectures for block ciphers, stream ciphers, and hash functions. The presented algorithms are the most wide used, in all certain of modern applications. Implementation aspects are given for both ASIC and FPGA integration platforms. Synthesis results are illustrated in hardware terms. This work also introduces the basic principles of random number generators, which are fundamental primitives of security applications also. Comparisons of operating frequency, throughput and allocated resources are given in detail. Future directions in hardware and embedded systems design, concerning Arduino platforms and open source programming, are also given.
Memory Controllers
RAM/ROM Memory Blocks
Communications Datapaths
I. INTRODUCTION
T
HE spreading revolution of communications, and especially the wireless and mobile applications of them, has created special needs for safe and secure communications [1]. With the adoption of the hardware advantages the center of interest has been moved to cryptographic hardware, regarding implementation aspects, of security primitives [2]. With the term cryptographic hardware, the research community refers to both theoritical and practical adoptions of cryptographic engineering, for a variety of purposes and applications such as: encryption and decryption processors, digital signature systems, key generation and distribution schemes, as well as random number generators [3]. In order to implement efficiently a security system, first the responsible team has to design, to implement, to validate and to test the implementation for the efficient performance of it [2]. This work introduces the aspects of cryptographic hardware and embedded systems, regarding implementation issues, for several aspects of secure communications: block ciphers, hash functions, random number generators, etc. It is also presented future directions, concerning promising hardware devices such as Arduino, and gives aspects of open source programming of them. Nicolas Sklavos is with the KNOSSOSnet Research Group, Informatics & MM Department, Technological Educational Institute of Patras, Hellas. (email:
[email protected]).
Data Transformation
I/O Interface
Fig. 1. Crypto-Processor Architecture of a Canonical SoC Design
The main subsystems are: the crypto-processor, the memories sub-blocks (RAM/ROM, memory controllers), I/O interfaces with the external communication systems, units data transformation units, as well as communication datapaths [4]. Such a design, although maybe seemed generic, applies most of the structures and methodologies, that are used in SoC design [5]. The internal subsystems vary in nature and in performance issues. These blocks will be designed developed and specified, during the design process. According to the application needs its time, the above design could be transformed to a more complicated one, which may integrates different interfaces, data transformations, a set of different processors, as well as a number of other peripherals and subsystems like memory units [4]. B. Design Flow In most of the cases, designers do achieve to meet the requirements of the application design, through two alternative design flows. Regarding ASICs (Application Specific Integrated Circuits), the waterfall model is followed, Fig. 2. According to this model, the design process is divided to seven alternative stages, which can be implemented by
different groups, without too many interactions between the teams [4]. The main approach here is that the systems fall over the “wall”, from stage to stage in different words, without the option of a step backward to the activities of the previous stage. Specifications
System-on-Chip Design and Verification Physical
Timing
Harwdare
Software
Physical Specifications: Area, Power etc
Timing Specifications: Frequency, I/Os Time
Hardware Specifications
Software Specifications
First Approach Floorplan
Block Specifications: Time
Block Orientation
Application Prototype Testing
Optimized Floorplan
Synthesis: Block, Units, Subsystems
Block Verification
Application Development
Top Level HDL
Application Testing
Verification: Top Level
Application Testing
RTL Code Functional Operation Synthesis Timing Verification Place & Route Updated Floorplans
Synthesis: Block, Units, Subsystems
Placement
Top Level Synthesis
Prototype & Test
Fig. 2. Waterfall Model: ASICs Design Flow
The waterfall model starts with the specifications orientation, based on the application requirements. Although, there are cases of very complicated application needs, where algorithmic approaches are followed in this stage. After that, the development of the Register Transfer Logic (RTL) is followed. This is needed in order both subsystems and subunits to be developed. The functional verification of the last ones, continues in the next stage of the waterfall model. Next, the design is synthesized into a gate-level netlist. In order to meet the timing requirements, the produced netlist is verified for the timing. The successful result is followed by the place and route stage, which is the physical design. Finally, the prototype chip is constructed and tested. The model is followed in most of the cases and results to successful produced SoC. Although, for very large scaled integrated systems (VLSI), issues of physical design have to be considered in the early stages of the waterfall model, in order to take care on time, that the SoC finally will meet the performance goals. For systems with very high complexity, the designers are used to follow a modified model of the waterfall approach, in order to achieve the requirements, on time-to-market [7]. The model followed in such cases is the spiral development model. Following this approach the design groups work at the same time on the multiple stages of the design, optimizing in parallel each stage of the it. The design flow followed in such cases is illustrated in Fig. 3. All aspects of it are addressed concurrently such as functionality, timing, physical design and verification. The development of both software and hardware is performed in parallel and is concurrent. The verification and the synthesis processes of the modules are performed also in parallel. The synthesis process includes floorplanning, as well as place and route. The interactions are performed throughout the design steps. In most of the applications, a system can be described with different abstraction levels of hierarchy.
Place and Route
Fig. 3. SoC Parallel Design Flow
In any design, it is needed to work down from the top level of abstraction, and up from the least abstraction description. Actually the design continues each time by adding details to the current abstraction level and to the system’s functionality, in top-down approach (Fig. 4). Pure Text
Specifications
Executable Code
Behavioral
Sequential Models
Register Transfer Logic
Clock Cycles
Logic Gates
Digital Logic
Gate Depth, Power
Transistors
Circuitry
Nanoseconds
Rectangles
Layout
Microns
Throughput, Design Time
Function
Cost
Fig. 4. FPGAs Top-Down and Botton-Up Methodologies
The reverse process, bottom-up analysis, adds cost and performance analysis, back and to the higher stages of abstraction description, such as timing information of certain circuitry technology. Top-down and button up design methodologies are followed mainly in the Field Programmable Gate Array Design (FPGAs), devices.
C. Design Life & Specifications The first stage of the design methodologies is dedicated to development and verification of an appropriate set of specifications. When these specifications are applied at a great manner, the design continues with the RTL (Register Transfer Logic) code. Although, this is not an easy matter for the designer, but one of the most crucial and time consumed phase of the procedure. In the cases that these specifications, are fully described from the beginning, it is easy to avoid time delays, and to fixed possible errors. When new specifications are defined later and in the next stages of the design procedure, major errors maybe appear in the last stages of the procedure, which may be proven not reversible. Specifications are defined for both software and hardware parts of the design. The most important of them are contained in the next Table I. TABLE I HARDWARE-SOFTWARE SPECIFICATIONS HARDWARE Functionality Timing Performance Software Interface Power, Energy Area: allocated resources
SOFTWARE Functionality Timing Performance Hardware Interface Software Structure Kernel
There are two major categories, that specifications are divided to, in order to be more flexible and useful for the designers: Formal Specifications: in this category belong these characteristics that are independent of any possible implementation. They are more useful in long term time period. Methods can be adopted, in order to verify that the design will finally meet the requirements, which are set from these ones. Available tools have been developed in order to describe the specifications of this category, which are used from hardware description languages etc. Executable Specifications: is basically an abstract model, for hardware/software parts. These tend to be more useful and flexible, in order to describe the right function operation, in most of the states of the design. In most of the cases, a software model is developed in the early stages of the design procedure, in order the basic functionalities, and communication interfaces to be verified, before the detailed stages of the design start. III. PRIVACY FOR 3G/4G FOR THE LTE/SAE STANDARD Last years the revolution of wireless communications is spreading in all kind of applications, including WEB 2.0, mobile TV etc. This has resulted to the standardization of the pre-4G, which is known as LTE (Long Term Evolution Protocol), to operate efficiently with the 3GPP (Third Generation Partnership Project). Regarding security issues which are applied basically for privacy and integrity protection, a set of encryption algorithms has been adopted.
A. KASUMI, UEA1 and UIA1 One of the widely used block ciphers is KASUMI. It operates on input data blocks of 64-bit, with keys of size 128bit. One of the basic building blocks of data transformation is the S-BOXes. They perform one-by-one substitutions of the input data to the output. Regarding the hardware integration of S-BOXes alternative approaches have been proposed with different advantages. They can be implemented with not much amount of combinational logic, regarding ASIC devices. This approach does not cost enough and have in general good performance. In the cases of high speed needs, RAM blocks can be used alternatively, but with an increased cost penalty, as a result of it. FPGA devices include LUT (Look Up Tables) which can be allocated for S-BOXes integration. They support good performance and they are available in large quantities, in most of the FPGA devices. Furthermore, logic circuitry, as well as memory blocks can be used alternatively to the LUT. The last two approaches keep the same implementations characteristics with the ASIC devices described above. The great interest is attracted for the KASUMI integration, since it is the main core for the operation, and as well as for the implementation, of the other algorithms. In other words, KASUMI is applied as the basic building block for the UMTS both privacy and integrity algorithms. UEA1 is the 3G cipher and UIA1 is the 3G integrity protection algorithm, which are designed and implemented as special modes of operation, based on KASUMI architecture. The detailed specifications of their operations have been defined analytically by the ETSI SAGE task force [8]. B. SNOW-3G, UEA2 and UIA2 Recent attacks, fundamentally based on algebraic methods have proven that there are cases where the security level of KASUMI block cipher could be decreased. In order to avoid such weaknesses and to provide a powerful and flexible algorithm, the task force has been adopted an alternative block cipher, named SNOW 2.0, in order to avoid algebraic attacks. Regarding the integration of SNOW, basically includes a LFSR (Linear Feedback Shift Register) and an FSM (Finite State Machine). Like KASUMI it also includes a chain of SBOXes. A part of them (S1 S-BOX) is taking directly as a part of the AES (Advance Encryption Standard), data transformation function. Special care has been taken regarding security level issues, for the design of S2 S-BOX, in order to support resistance against the algebraic attacks. SNOW-3G is applied as the core unit of both UEA2 and UIA2. More analytically for the UEA2 operation, and for the generation of the bit strings P and Q equal to 64-bit wide each, SNOW 3G is performed. Then after a specified process of data padding, the plaintext is modified into a polynomial over 2 64 elements of a finite field. C. MILENAGE Algorithm MILENAGE block cipher operation is based on the usage of a data and key block, both equal to 128-bit. The core unit in which this block cipher is based is the AES cipher. It obvious, that for MILENAGE implementation the interest is centered to AES hardware integration.
For AES implementation alternative designs for both ASIC and FPGA implementation have been proposed [9]. It can be basically implemented with a full rolling architecture in combination with feedback logic, in order to save allocated resources and to achieve good performance. Although, in the cases where high speed is the main request, a pipeline architecture with a number of transformation stages equal to the data transformation rounds, can be integrated alternatively. This integration is based on cascade registers units. Analytical implementations synthesis results are shown in the following Table II, regarding AES block cipher: TABLE II AES ARCHITECTURES IMPLEMENTATION SYNTHESIS RESULTS HASH FUNCTIONS AES [9] Loop Feedback Architecture AES [9] Pipeline Architecture
F (MHz)
RATE (Mbps)
AREA (CLBs)
22
259
2358
28,5
3650
17314
D. UEA3 and UIA3 Besides the above described block ciphers for 3G, ETSI SAGE task force, in cooperation with security experts, design another pair of algorithms, called UEA3 and UIA3, specialized for the 4th Generation (4G) security purposes. The appropriate specifications standardization has already been submitted to the 3GPP security group. The final decision is going to be made known later on, regarding if they will be included in the forthcoming LTE standard. Since this work is in progress, and as well as the result of it has not been officially announced by the moment, further details on these issues are not available. E. ZUC, 128-EEA3 and 128 –EIA3 For stream encryption purposes ZUC algorithm is used. ZUC is a stream cipher based on 32-bit words key stream, applied for both encryption and decryption operations. The algorithm uses a 128-bit initial key and a 128-bit initial input data block. Data transformations can be divided to three alternative logic layers: a Linear Feedback Shift Register (LFSR), a bit-reorganization (BR), a non-linear function F. Similar to the previous described algorithm ZUC is used as fundamental component of two other encryption algorithms EIA3 and EEA3, used for integrity and confidentiality respectively. 128-EEA3 belongs to the category of stream ciphers and it is used for encryption/decryption purposes, with an applied confidentiality key CK. ZUC performs efficiently as keystream generator, for the 128-EEA3 operation. On the other hand, 128-EIA3 generates a MAC code (Message Authentication Code). The operation is supported by the use of an integrity key, called IK. ZUC algorithm is also the main core unit for the operation of 128-EIA3 algorithm.
IV. HASH FUNCTIONS DESIGN AND INTEGRATION Hash functions can be described as a certain category of cryptographic primitives, which have to perform on a great number of rounds with certain values of specified parameters. Until nowadays different hash functions have been adopted by wireless communications protocols and for networking data transmission: RIPEMD, SHA-1, SHA-2, TIGER, etc, coming to the forthcoming SHA-3 standard, by the end of the year [10-15]. All the above functions are based on a fundamental function, which performs the data transformation and it is well known as “round”, which performs for a great number of times. Each round is based in the same number of steps, which are fundamental internal stages of data modification. The output of a round (i), is the input for the round (i+1), while the output of the stage (x) of the round (i), is the input of the stage (x+1), of the same round (i). As a result of these, the next block could not start hashing modification, if the processing of the previous one has not been completed. The most common design approach is the iterative loop architecture. Following this approach, the initial data message is transformed with two different processes: it is hashed, in order to generate the padding message, and from this output a sub-block is provided to every step round of the function. The detailed design of iterative loop architecture is illustrated in the following Fig. 5. INITIAL MESSAGE
CLOCK
APPENDING MESSAGE PADDING
MESSAGE PADDING
MESSAGE SCHEDULER
ROM
Mi
HASH FINITE STATE MACHINE
Kj
RAM
CVn 1
HASH ITERATION MESSAGE DIGEST
Fig. 5. Iterative Loop Architecture
The requested constants and initial values of each one of the hash functions are loaded from memory blocks, of ROM technology, which are requested for the operation of each data transformation round. The final output, called message digest, is produced by XORing the hash value of the last iteration, with the initial hash value. Specific RAM blocks are used, in order parts of the generated hash value of the output to be stored, as they have to be input data of the next one round. Last but not least, it has to be mentioned that the specified parameters of each one of the hash functions, are crucial factors, and the above general iterative design can be varied, modified and partially changed, in order to achieve the best implementation goal each time. An FPGA implementation of the iterative loop architecture has good performance, high frequency values and not high demands of allocated resources and/or system area. Values of the implementation synthesis results of alternative hash functions are shown in the following Table III.
TABLE III ITERATION LOOP DESIGN: IMPLEMENTATION SYNTHESIS RESULTS HASH FUNCTIONS RIPEMD [10] MD5 [11] SHA-1 [12] SHA-2 [13] BLAKE [14] HAVAL [15]
F (MHz)
RATE (Mbps)
AREA (CLBs)
67 70 70 83 52
2017 1653 1653 1060 116,48
2171 442 551 291 3017
75
196
1708
V. RANDOM NUMBER GENERATORS FOR SECURITY APPLICATIONS The operation of almost all cryptographic applications is based on random number generators (RNGSs), for a great number of purposes such as: keys, parameters for signature generation and verification, ephemeral keys. It is obvious, that random number generators, are considered as fundamental parts of information security architectures, designs and implementations [16]. A. Classes of RNGs The classification of RNGs can be divided to two different categories (Fig. 6). RNGs
Non-deterministic (True)
Deterministic
Pure
Hybrid
Physical
Pure
Non-Physical
Hybrid
Pure
VI. FUTURE DIRECTIONS: OPEN SOURCE HARDWARE One of the continuously rising sectors in embedded hardware is open source hardware. Following the ideals, goals and success of open source software, open source hardware aims to facilitate cooperation between competing platforms, the exchange of knowledge and to improve further interoperability and the establishment of open standards and protocols for communication. As open source hardware platforms, grow and gain more attention and usage in some important areas, the question of security arises. What is the state of security in the most popular open source hardware platforms? How many cryptographic algorithms have been implemented, and how secure are they in reality? How secure and stable are the current popular open source hardware platforms themselves? B. Arduino Platform As an example, we will use the Arduino platform. The Arduino platform consists of a number of boards that bear some strong similarities between them, such as the chip architecture (AVR, with Atmel's ARM platform to be added soon), the common programming APIs (called the Arduino language, a derivative of the Wiring language, which itself is a modified version of C++), as well as some physical characteristics (Fig. 7). The main Arduino board is called the Arduino Uno and consists of an Atmel AVR processor (ATMega328), programmed with a custom open-source bootloader (optiboot) and an assortment of programmable pins.
Hybrid
Fig. 6. Classes of Random Number Generators (RNGs)
The first one category includes deterministic PRNGs, which are pseudorandom number generators. Their operation initializes with a seed and with a specified function, in most of the cases, “new” pseudorandom numbers are produced, for each time of operation. A better vision for “true” RNGs gives the second category which is divided to the classes of physical and non-physical. In the first one, belong the ones, that use non-deterministic effects of electronic circuitry, or even physical experiments. The non-physical ones, apply non-deterministic events like time from a system or of a subsystem values, random values of memory blocks etc. The security of the deterministic RNGs is fundamentally based on the complexity to compute values of a possible attack. While for the non-deterministic security depends on the unpredictability of the output. A number of evaluation processes and standards are taken place, and most of them are applied in practice. Such specifications define the acceptable properties, that trustworthy RNGs must support. For physical RNGs is quite difficult to define designs since the properties that support acceptable security levels are, depend on the concrete implementation. Furthermore, in the case of statistical blackbox test, it is not efficient to define the security level of an RNG.
Fig. 7. Arduino Platform Overview
C. Programming & Communication In order to program an Arduino [16], you need to use their open source software, which includes their APIs and libraries to interact with their hardware as well as external actuators, sensors and communication modules. It also supports external libraries provided by third-parties, to support a vast array of devices and modules (Fig. 8). Arduino includes serial and USB-to-serial communication out of the box, but it also supports a host of other options by extensions. Some of those communication extensions are common, such as an Ethernet module, a Bluetooth module and a WiFi module. Others are more sophisticated and targeted for use by academia and research faculty, such as the popular XBee modules, which provide support for the 802.15.4 and ZigBee protocols. Given the limited processing power of the Arduino, security is confined to a limited set of cryptographic libraries (discussed below). Subsequently, even some of the most basic
security protocols like HTTPS (SSL, TLS) are absent and the WiFi and Bluetooth security is limited to that of the expansion module. As for the security of the 802.15.4 communication, the XBee modules do provide an easy to use AES encryption for those in need of encrypting their data.
[4] [5] [6] [7]
[8] [9]
[10]
[11] Fig. 8. Arduino Programming Interface
D. Security Applications In regards to cryptographic solutions for the Arduino, it is limited due to the constraint of computational power. There are currently only two alternatives for encryption, and limited at that. The MD5 library, which provides the basic functionality of MD5 hashing and cryptosuite, a cryptography suite for Arduino, which block ciphers, secure hashes and message authentication. There is also an intent for supporting public key cryptography in the future. Cryptosuite supports hashing using SHA-1, SHA-2, HMAC-SHA-1 and HMACSHA-2.
[12]
VII. CONCLUSIONS & OUTLOOK
[15]
While wireless communications are coming to offices and houses with a great number of new applications each day, the increased number of users day by day needs safe and secure implementations of them. Cryptographic hardware has attracted the interest of the research community regarding implementation point of view. ACKNOWLEDGMENT The work in Section VI concerning Future Directions and Arduino Platform has been carried out in cooperation with the Codebender Group members, V. Georgitzikis, and M. Orfanos [16]. It has been designed and developed as an open source system. (Please refer to www.codebender.cc). REFERENCES [1]
[2]
[3]
N. Sklavos, X. Zhang, Wireless Security & Cryptography: Specifications and Implementations, CRC-Press, A Taylor and Francis Group, ISBN: 084938771X, 2007. N. Sklavos, "On the Hardware Implementation Cost of CryptoProcessors Architectures", Information Systems Security, The official journal of (ISC)2, A Taylor & Francis Group Publication, Vol. 19, Issue: 2, pp. 53-60, 2010. F. Rodriguez-Henriquez, N.A. Saqib, A. Diaz Perez, C. Kaya Koc, Cryptographic Algorithms and Reconfigurable Computing, Springer, ISBN 0387338837, 2006.
[13]
[14]
[16]
A. Clemments, The Principles of Computer Hardware, Oxford University Press, Third edition, 2000. J. Hennecy, J. Patterson, Computer Architecture, Morgan Kaufmann Publishers, 2003. M. M. Mano, Computer Engineering: Hardware Design, Englewood Cliffs, NJ: Prentice Hall, 1988. N. Sklavos, K. Touliou, “A System-Level Analysis of Power Consumption & Optimizations in 3G Mobile Devices”, proceedings of the 1st International Conference on New Technologies, Mobility & Security (NTMS'07), Paris, France, May 2-4, 2007, Springer, pp. 225235, ISBN: 9781402062698, 2007. Dan Forsberg, Gunter Horn, Wolf-Dietrich Moeller and Valtteri Niemi, LTE Security, John Wiley & Sons Ltd,2010. N. Sklavos, O. Koufopavlou, "Architectures and VLSI Implementations of the AES-Proposal Rijndael", IEEE Transactions on Computers, Vol. 51, Issue 12, pp. 1454-1459, 2002. N. Sklavos, O. Koufopavlou, "On the Hardware Implementation of RIPEMD Family Processor: Networking High Speed Hashing, up to 2 Gbps", Computers & Electrical Engineering, Elsevier Science, Vol. 31, Issue: 6, pp. 361-379, 2005. N. Sklavos, P. Kitsos, E. Alexopoulos, O. Koufopavlou, "Open Mobile Alliance (OMA) Security Layer: Architecture, Implementation and Performance Evaluation of the Integrity Unit", New Generation Computing: Computing Paradigms and Computational Intelligence, Springer-Verlag, Vol. 23, No 1, pp. 77-100, 2005. N. Sklavos, P. Kitsos, K. Papadopoulos, O. Koufopavlou, "Design, Architecture and Performance Evaluation of the Wireless Transport Layer Security", Journal of Supercomputing, Springer-Verlag, Vol. 36, No 1, 2006. N. Sklavos, O. Koufopavlou, "On the Hardware Implementations of the SHA-2 (256, 384, 512) Hash Functions", proceedings of IEEE International Symposium on Circuits & Systems (IEEE ISCAS'03), Vol. V, pp. 153-156, Thailand, May 25-28, 2003.P. Kitsos, N. Sklavos, "On the Hardware Implementation Efficiency of SHA-3 Candidates", proceedings of 17th IEEE International Conference on Electronics, Circuits, and Systems, (IEEE ICECS'10), December 12-15, Athens, Greece, 2010. P. Kitsos, N. Sklavos, "On the Hardware Implementation Efficiency of SHA-3 Candidates", proceedings of 17th IEEE International Conference on Electronics, Circuits, and Systems, (IEEE ICECS'10), December 1215, Athens, Greece, 2010. N. Sklavos, C. Efstathiou, "On the FPGA Implementation of HAVAL Hash Functions", proceedings of The IEEE Region 8 EUROCON 2007, International Conference on "Computer as a Tool" (IEEE EUROCON'05), Serbia & Montenegro, November 21-24, 2005. Codbender.cc, available at www.codebneder.cc.
Nicolas Sklavos is Assistant Professor with the Informatics & MM Dept, Technological Educational Institute of Patras, Hellas. He is also adjunct faculty, Assistant Professor, with the Computer Engineering & Informatics Dept., University of Patras, Hellas. He holds an award for his PhD thesis on “VLSI Designs of Wireless Communications Security Systems”, from IFIP VLSI SOC 2003. His research interests include Cryptographic Engineering, System on Chip Design, Computers Architecture, VLSI Design, Security of Computers and Networks. N. Sklavos has participated to a great number of European and National projects both research & development, in the areas of his research. He serves as evaluator of both European Commission Projects (FP7) and General Secretary of Research and Development, Hellas. He is director of KNOSSOSnet Research Group. Since 2007, he is the Chair of IEEE Hellas GOLD Affinity Group. He is the Editorin-Chief for the Information Security Journal: A Global Perspective Journal, Taylor & Francis Group. He serves as Associate Editor for IEEE Latin America Transactions, IEEE Press, and Computers & Electrical Engineering Journal, Elsevier. He has been Guest Editor of Special Issues for Elsevier & Springer publishers. He was the General Co-Chair of ACM MobiMedia 2007 and General Chair of ATHENA Summer School. He has participated to the organization of more than 100 conferences organized by IEEE/ACM/IFIP, as Publicity, Publication Chair, Program Chair and Program Committee member. He has authored or co-authored more than 100 scientific articles, books, chapters, tutorials, in the areas of his research. His published works have received up to 800 non-self-citations.
