A Design Methodology for HW/SW Security Protocols

Transcription

1 Università degli Studi di Milano Facoltà di Scienze Matematiche, Fisiche e Naturali Dipartimento di Tecnologie dell Informazione Corso di Dottorato di Ricerca in Scienze Informatiche XIII ciclo Tesi di Dottorato di Ricerca A Design Methodology for HW/SW Security Protocols Alberto Ferrante Matr: R05112 Relatore: Prof. Vincenzo Piuri Correlatori: Prof. Luigi Dadda, Dr. Jeff Owen Anno accademico

2

3 Università degli Studi di Milano Facoltà di Scienze Matematiche, Fisiche e Naturali Dipartimento di Tecnologie dell Informazione Corso di Dottorato di Ricerca in Scienze Informatiche XIII ciclo Tesi di Dottorato di Ricerca A Design Methodology for HW/SW Security Protocols INF/01 Alberto Ferrante Matr: R05112 Tutor: Coordinatore dottorato: Prof. Vincenzo Piuri Prof. Gianni Degli Antoni Correlatori: Prof. Luigi Dadda ALaRI - Università della Svizzera italiana, Lugano, Svizzera Dr. Jeff Owen ST Microelectronics Inc., San Jose, California, USA Anno accademico

4

5 ... To my parents...

6

7 Contents 1 VPNs and Network Security Virtual Private Networks Introduction to cryptography The symmetric key algorithms The public key algorithms The Diffie-Hellman protocol Authentication algorithms Security Protocols The IPSec protocol suite New Version of the IPSec Suite Preliminary Evaluation of Hardware Requirements Network Quality of Service IPSec Hardware Requirements Study IPSec Performance Analysis IPSec Performance Measurement Hardware and Software Configuration of the Test Network Description of the Tests Results Remarks on Performance Guidelines for IPSec Configuration Security Protocols Technologies and Researches Classification of accelerators External View vii

8 viii CONTENTS Internal View Software Accelerator Interface Current Accelerators for IPSec Researches Market Products Network Processors Trends for Security Protocols 51 5 A Model of IPSec High-level Modelling for Synthesis and Testing IPSec Modelling Generation of Test Sequences Results Scheduling Algorithms for Cryptographic Accelerators System Architecture A Packet Scheduling Algorithm Description of the Algorithm Simulations Enhanced System Architecture Small Packet Processing The Sliding Window Scheduling Algorithm Simulations Quality of Service Support Description of the Algorithm Simulations Enhanced System Architecture About Supporting Hard QoS System on Chip for IPSec High Level Architecture External Interface Notes on IKE Analysis of the Data Processing Improving Efficiency: the Intelligent I/O Unit Improved Internal Communications Specifications of the Functionalities Storage of Information Soft Quality of Service Management Notes on Hard Quality of Service Management

9 CONTENTS ix Extending the Processing Capabilities of the SoC Some Notes on Hardware/Software Partitioning Functional Blocks of the SoC IKE Unit Functional Blocks Packet, Memory and Database Classes System Integration and Testbench Results of the Simulations DB Manager The Core of the DB Query Functional Block Further Improving Speed: Multithreaded Queries Conclusions and Future Work 173

10 x CONTENTS

11 List of Figures 1.1 A mobile user connected to a private network Connection of two private networks Datagram transformation for ESP transport mode Datagram transformation for ESP tunnel mode Datagram transformation for AH transport mode Datagram transformation for AH tunnel mode IKE Phase 1 exchange IKE Phase 2 quick mode exchange IPSec outbound packet processing IPSec inbound packet processing Test network structure Network throughput for a 100Mbit/s network CPU effort comparison for a 100Mbit/s network Sender PC Network output traffic for a 100Mbit/s network Instantaneous CPU load with no IPSec Instantaneous CPU load with IPSec Network throughput for a 10Mbit/s network CPU effort comparison for a 10Mbit/s network Fabric side connection, in-line coprocessor Fabric side connection, off-line coprocessor Network side connection, in-line coprocessor Network side connection, off-line coprocessor IBM PCI cryptographic coprocessor high-level schema Luna VPN cryptographic accelerator integration schema xi

12 xii LIST OF FIGURES 3.7 Motorola MPC190 accelerator The flow-through architecture HIPP III 8530: block diagram A board using the HIPP III 8530 accelerator Example of a system using Toaster2 in distributed configuration Cisco Toaster2 architecture: TMC and processor complex Testing of a system using its specifications UML class diagram of IPSec Statechart of the TunnelESP class Statechart of the Header ESP class Statechart of the TrailerESP class Reference scheme Reference scheme for the scheduling algorithm Simulation scheme CPU load due to cryptography for a 2-accelerator system Throughput for a 2-accelerator system Average processing latency for a 2-accelerator system Average global latency for a 2-accelerator system Average processing latency comparison for a 1-accelerator system Throughput comparison for a 1-accelerator system The sliding window schema Percentage of packets processed by the CPU; W = Relative CPU usage. CPU parameters: T init ratio = 3; T enc ratio = Relative throughput. CPU parameters: T init ratio = 3; T enc ratio = Relative average latency. CPU parameters: T init ratio = 3; T enc ratio = Reference scheme for the scheduling algorithm Simulation scheme CPU load due to cryptography for a 2-accelerator system in the Packet Average case Throughput for a 2-accelerator system in the Packet Average case Average processing latency for a 2-accelerator system in the Packet Average case

13 LIST OF FIGURES xiii 6.20 Average processing latency for a 2-accelerator system in the RR Average case Average processing latency for the RR Average and the Packet Average cases. α 0 = 50; β 0 = ns Packet distribution among different priority levels for the network trace we have considered Average processing latency comparison for a 4-accelerator system Throughput comparison for a 4-accelerator system CPU usage comparison for a 4-accelerator system Overview of the SoC architecture Internal architecture overview with the Intelligent I/O unit Internal overview of the Intelligent I/O unit basic architecture Internal architecture overview of the Intelligent I/O unit with fragmentation management Internal communication scheme Improved internal communication scheme UML class diagram describing the relations among the different parts of the SoC Sequence diagram describing the behavior of the SoC when a new IPSec inbound packet arrives Sequence diagram describing the behavior of the SoC when a new inbound packet which does not need any IPSec processing arrives Sequence diagram describing the behavior of the SoC when IKE needs to be activated Sequence diagram describing the behavior of the SoC when an IKE packet is received Statecharts describing the input-dedicated part of the Net I/O Manager unit Statecharts describing the output-dedicated part of the Net I/O Manager unit Statecharts describing the In DB Manager unit Statecharts describing the IKE DB Manager unit Statecharts of the Scheduler unit Memory - CPU performance gap Maximum memory usage for different combinations of network bandwidth requirements and data rate supported by the device

14 xiv LIST OF FIGURES 7.19 Average memory usage for different combinations of network bandwidth requirements and data rate supported by the device Maximum and average memory usage comparison for different network speeds Maximum number of packets that need to be stored for different combinations of network bandwidth requirements and data rate supported by the device Average number of packets that need to be stored for different combinations of network bandwidth requirements and data rate supported by the device Comparison between average an maximum number of packets that need to be stored depending on the network bandwidth Internal architecture of the Memory unit The MEM block of the Memory unit Memory usage for a PQ policy; required bandwidth is lower than the system throughput Memory usage for a PQ policy; required bandwidth similar to the system throughput Memory usage for a PQ policy; required bandwidth is higher than the system throughput Number of packets; a PQ policy is considered; required bandwidth is lower than the system throughput Number of packets; a PQ policy is considered; required bandwidth is similar to the system throughput Number of packets; a PQ policy is considered; required bandwidth is higher than the system throughput Throughput for a PQ policy; required bandwidth is lower than the system throughput Throughput for a PQ policy; required bandwidth is similar to the system throughput Throughput for a PQ policy; required bandwidth is higher than the system throughput Memory usage for a WFQ policy; required bandwidth is lower than the system throughput Memory usage for a WFQ policy; required bandwidth is similar to the system throughput Memory usage for a WFQ policy; required bandwidth is higher than the system throughput

15 LIST OF FIGURES xv 7.38 Number of packets; WFQ policy; required bandwidth is lower than the system throughput Number of packets; WFQ policy; required bandwidth is similar to the system throughput Number of packets; WFQ policy; required bandwidth is higher than the system throughput Throughput for a WFQ policy; required bandwidth is lower than the system throughput Number of packets; WFQ policy; required bandwidth is similar to the system throughput Number of packets; WFQ policy; required bandwidth is higher than the system throughput Typical IKE interfaces required to the integration with an IPSec environment Subdivision of IKE into different components The PRNG component The MD5 component The AES component The RSA component The finite state machine implemented into the IKE Manager Sequence of operations in the IKE Manager The pad entry memory structure The rqt memory structure The pkt memory structure The ikedb entry memory structure The ipsec sa entry memory structure The mem data memory structure IKE unit architecture IKE simulation testbench Memory utilized by IKE Utilization of the IKE units SA creation final time Basic architecture for the core of the database query functional block Average query times Average number of queries per second Hit and replacement rates for the SPD cache Hit and replacement rates for the SAD cache

16 xvi LIST OF FIGURES

17 List of Tables 6.1 β 0 and corresponding number of bytes that can be processed in such time by one of the accelerators Pattern parameters in bytes Simulation results for the initial exchanges Simulation results for the child exchanges Size of the essential part of the SPD record; IPv4 addresses and 32 bit memory addresses are considered Size of the SAD records; IPv4 addresses and 32 bit memory addresses are considered Different configurations used during the simulations Sizes of the caches in number of elements and in bytes xvii

18 xviii LIST OF TABLES

19 Acronyms AES Advanced Encryption Standard. AH Authentication header. API Application Protocol Interface. ASIC Application-Specific Integrated Circuit. CBQ Class-based Weighted Fair Queuing. DES Data Encryption Standard. DH Diffie-Hellman. Diffserv Differentiated Services. DMA Direct Memory Access. DoI Domain of Interpretation. DoS Denial of Service. ECC Elliptic Curve Cryptography. ESP Encapsulating Security Payload. HMAC Hash Message Authentication Code. IETF Internet Engineering Task Force. IKE Internet Key Exchange. xix

20 xx ACRONYMS ISAKMP Internet Security Association and Key Management Protocol. IP Internet Protocol; if not differently specified, the version 4 of this protocol. IPv6 Internet Protocol version 6. IPSec IP Secure. IPComp IP Compression. L2F Layer 2 Forwarding L2TP Layer 2 Tunneling Protocol. MD5 Message Digest algorithm 5. MTU Maximum Transfer Unit. NoC Network on Chip. NP Network Processor. PAD Peer Authentication Database. PPP Point to Point Protocol. PPTP Point to Point Tunnelling Protocol. PQ Priority Queuing. WFQ Flow-based Weighted Fair Queuing. QoS Quality of Service. RFC Request For Comments. RTL Register Transfer Level. SA Security Association. SAD Security Association Database. SHA Secure Hash Standard. SoC System on Chip. SPD Security Policy Database.

21 ACRONYMS xxi TCP Transmission Control Protocol. TLS Transport Level Security. UDP User Datagram Protocol. UML Unified Modelling Language. VPN Virtual Private Network.

22 xxii ACRONYMS

23 Acknowledgments T he first people I would like to acknowledge are my parents and all my family who have supported me during these last twentynine years. This thesis would not even exist without the help of Vincenzo, who is my advisor: his precious suggestions helped me a lot during these three years of PhD... Thank you Vincenzo! A special acknowledgment goes to the referees of this thesis, Prof. Miroslaw Malek, Prof. Eduardo Sanchez, and Prof. Renato Stefanelli. I would also like to acknowledge Prof. Dadda, Jeff, Fabien, and Marco for their invaluable contribution to this thesis. Furthermore, Jeff is the one who came up with the idea of working on these topics, therefore he deserves a special thank. All the people at the ALaRI institute, such as Prof. Sami, Umberto, and all the staff deserve to be mentioned for their support and understanding during the last years. I would also like to take the opportunity to acknowledge all the students I met at ALaRI: all of them taught me a lot; some of them also helped me during this research... Antonietta, Antonio, Rodrigo, Sathish, and Uljana, thank you! I would also like to mention my friend Sara: her help with the English in some parts of this thesis has been greatly appreciated! Last but not least, I would like to thank all my friends, who continuously supported me during my life. xxiii

24 xxiv ACKNOWLEDGMENTS

25 Introduction The ability to communicate has become of fundamental importance for every activity of the human life: companies need to connect different seats and to communicate with their customers and partners; human beings need to communicate with others, with companies, and institutions. Security and privacy is also an important need of the modern world: the rising competitiveness among industries imposes an increasing level of protection for each Company s confidential information; private information of the human beings also need to be protected or, anyway, only pieces of information should be able to be revealed by each person to certain recipients. This need for security is obviously in contrast with the need of communication. As a matter of fact, sending information over any communication mean could expose them to possible evesdroppers. The only way to solve this contrast is to introduce some security mechanisms in communications. Communication security is crucial for economic and social development. Many security mechanisms have been studied and deployed over the years. Presently used mechanisms are based over cryptography or, for few very advanced applications, quantum cryptography. The latter technology is the future for a limited number of applications as it requires peculiar technological conditions. Traditional cryptographic techniques will probably continue to be used for common applications for many years. Wether the possible advent of quantum computers will determine the end of traditional cryptographic techniques or not, need to be clarified. As a matter of fact, quantum computers will be able to factorize large prime numbers in very small times. This is potentially dangerous xxv

26 xxvi INTRODUCTION for some public-key cryptographic algorithms (e.g., RSA) but not for others. These algorithms can be substituted with others that are not based on prime number factorization (e.g., ECC) and the whole cryptosystem will be able to work without any problem. In any case experts believe that actual secured data communications if properly configured are usually the most secure part of the whole IT system. The less secure parts of each IT system are the ones involving humans. As a matter of fact one may have the most advanced and well configured security mechanisms, but human factor can play a fundamental role in revealing classified information. Companies employees can reveal (by intention or not) important information without the real need to involve the IT infrastructure. Solving this problem is far more difficult than any other: technical problems can be solved by adopting new technologies, but the human problem can only be solved by educating people to security. This education process may take many years to give proper effects. An area of communication security is the one of security protocols. These protocols offer a way to use cryptographic algorithms for providing communication security. As a matter of fact, cryptographic algorithms are not usable by themselves: they need mechanisms for exchanging keys between the parties that are involved and for managing the secure connections. This is what secure protocols exactly do. Secure protocols are based on cryptographic algorithms and these algorithms are very resource consuming. Specialized hardware is therefore used to support high network performances as general purpose CPUs cannot often provide the necessary computational capacity. Gilder s [52] and at the Moore s [53] laws say that this situation is not going to improve with time: while Moore says that computational capacity is doubling every 18 months, Gilder says that available network bandwidth doubles every 12 months. Goal of the work presented in this dissertation is to study a comprehensive design methodology for mixed hardware/software architectures dedicated to security protocols. The IPSec (IP Secure) protocol suite is taken as a reference for this work, as it has assumed great importance, being also included as mandatory security mechanism in the new version of the IP protocol, IPv6.

27 INTRODUCTION xxvii The work here reported can be subdivided into different phases: 1. Study of the application requirements (IPSec suite protocols and a study about virtual private networks); this is necessary to understand the problems that may arise by using these protocols. 2. Profiling of one of the current IPSec software implementation: this allows to understand in which cases hardware acceleration is really necessary and the performance requirements. 3. Study of the actual hardware/software architectures for secure protocols. 4. Study of advantages disadvantages of the actual architectures. 5. Development of an abstract model of IPSec; this model will be used as a reference during the design phase. Starting from the model a testing methodology for IPSec-based systems will be developed. 6. Optimization of relevant aspects of presently used IPSec implementations. 7. High-level design of an innovative System on Chip for efficiently processing IPSec traffic. In the following chapters the previously discussed topics are presented. In Chapter 1 an explanation of the main technologies involved in virtual private networking is given. Focus is mainly concentrated on the security protocols which are involved. The IPSec suite of protocols is mainly presented, as well as an introduction on cryptography. Chapter 2 provides a performance analysis of the IPSec suite of protocols. Experimental results there reported show that IPSec is very resource consuming and hardware accelerators are crucial in reaching high performances. This is also confirmed by other works found in the literature. Performance considerations also help in configuring IPSec-based networks. Chapter 3 provides an overview of the existing hardware accelerators on the market. A classification of security protocol dedicated accelerators is firstly given. A list of currently available accelerators and network processors is then provided. As most of them are commercial products only marketing information are often available.

28 xxviii INTRODUCTION Chapter 4 gives an overview of the current scenario of the security protocol implementations along with an evaluation of the future trends in the field. Chapter 5 provides an innovative model of the IPSec suite of protocols by using UML. As IPSec is very complex, these specification can help understanding it and the relations between its different parts. The use of UML allows for abstracting the model from the implementation, thus providing a suitable base both for design, including HW/SW partitioning, and for testing. A testing methodology based on the UML model is presented at the end of this chapter. Chapter 6 proposes some optimizations to the presently used HW/SW interfaces for IPSec accelerators. These optimizations are both useful for presently used systems and for developing new architectures for IPSec. As a matter of fact, optimizing the present systems also allows to understand their problems. The optimizations we propose in this chapter consist of some packet scheduling algorithms which allow using together multiple cryptographic accelerators and software implementations of the cryptographic algorithms. Reference system is composed by a normal PC architecture hosting a certain number of accelerators. Only cryptographyrelated operations are offloaded to them. This is a scheme used on present low-end servers. This scheme can anyway be replicated, by considering different processing and communication speeds, on different, more performant, architectures. An algorithm for extracting better performances when small packets are processed in such an architecture is also presented. All the algorithms presented in this chapter allow for optimizing very important parts of IPSec and for designing an enhanced, more flexible, architecture. Chapter 7 presents a study over a high-performance comprehensive solution for IPSec. Different high level architectures are presented along with the main requirements. Main parts of these architectures are developed in detail. Chapter 8 presents some proposals for designing two functional blocks of the IPSec SoC: the core part of the blocks implementing the IKE protocol and the database query functionality. These two functional blocks were chosen because there exist no implementation of them in the literature. Chapters 5, 6, 7, and 8, along with Section 2.2, contain the original contribution of this work. Parts of these sections were published in [20, 18, 41, 19, 23].

29 INTRODUCTION xxix To summarize, the original results shown in this dissertation are: a performance measurement of IPSec; an abstract model of IPSec and a testing methodology for IPSecbased systems; three packet scheduling algorithms for multi-accelerator based systems; the high-level architecture of an innovative SoC for IPSec; a SystemC model of IKE, allowing to perform optimal HW/SW partitioning of it; the internal high-level design of two functional blocks of the SoC.

30 xxx INTRODUCTION

31 1 Virtual Private Networks and Network Security Since many years the need of internal Companies communication has increased. The ability to support mobile users and to connect seats located in different places have become of fundamental importance in everyday business. In this chapter we present some techniques presently used to support these functionalities and the main technologies behind them. 1.1 Virtual Private Networks To support communications out of local networks, private separate networks were firstly used. This solution gives good performances and security, but it is very costly as it requires to rent private communication lines. As the Internet has become pervasive, the idea of Virtual Private Networks (VPNs) has become popular. The main idea of VPNs is to use secure protocols to build secure communication channels and to allow the machines connected to these channels to act as if they were connected to the same private networks. The main idea is therefore to virtually build a private network over a public one: VPNs use obfuscation through secure tunnels, rather than physical separation, to keep communications private [127, 42]. VPNs have become popular for many reasons: ubiquitous coverage: The Internet offers wider coverage compared with the private data network infrastructures. Adding new desti- 1

32 2 CHAPTER 1. VPNS AND NETWORK SECURITY nations to VPNs usually consists of modifying some configuration files; adding new destination to private networks usually consists of adding new circuits and possibly sign interconnection agreements between different providers, cost reduction: for VPNs there is no need to purchase and maintain special purpose infrastructures. General purpose internet connections are sufficient to allow VPN access, security: VPN use cryptography to provide data confidentiality and integrity. In private networks security usually relies only on the telecommunication service provider s physical security practices. Main VPN scenarios are shown in Figure 1.1 and in Figure 1.2. The first figure shows a mobile user connected to a company s network through a VPN. This configuration, that is usually called road warrior, allows the mobile user to access the company s internal network theoretically as if he was connected to it from inside. Whether the access to company s network resources is limited or not, depends on the security policy that have been deployed in the specific network. Usually the mobile user s machine gets a virtual address belonging to the private company s network. The second figure shows two private networks connected together by means of a VPN. This is typical when two or more seats of the same company need to communicate and to share information. A mix of the previously two described scenarios can be deployed for providing different seats interconnection and access to mobile users. In each one of these schemes there is one fundamental network component that is the secure gateway. This machine manages the secure communications and it usually runs a firewall, a gateway, and a VPN server. The Firewall is for filtering the connections to the internal network. Depending on the policy that has been selected, non-secured connections can be refused or not. In any secure network non-secured connections should anyway have limited access to internal resources. The gateway is for routing the traffic, while the VPN server is responsible of managing the VPN connections. VPNs are usually created by associating two different protocols, one for data security and one for emulating a point to point connection. Layer 2 tunnelling protocols are specifically designed to tunnel Point-to-Point Protocol (PPP) [122] frames through an IP network. PPP protocols are used to route privately addressed packets through a publicy addressed infrastructure. For the road warrior configuration, the remote uses sets up a PPP connection, tunnelled on IP, to the secure gateway. Once a PPP connection