A SINGLE-CHIP IPSEC CRYPTOGRAPHIC PROCESSOR Maire McLoone, John VMcCanny DSiPTMLaboratories, School of Electrical and Electronic Engineering, The Queen's University of Belfast, Northern Ireland. Email:
[email protected],
[email protected]
ABSTRACT The need for securing the Internet has become a kndamental issue over the last decade and the Internet Protocol Security (IPSec) standard, which incorporates cryptographic algorithms, has been developed as one solution to this problem. Typically, hardware implementations of cryptographic algorithms provide physical security and high speeds. In this paper a novel singlechip hardware IPSec cryptographic design is described, which comprises the Rijndael encryption algorithm and HMAC-SHA-I authentication algorithm. In particular, the design supports the cryptogwphic requirements of the IP Authentication Header (AH) and"%ncapsulation Security Payload (ESP) and any combination of.'these two protocols. Indeed, it is capable of supporting any application requiring authentication andor encryption, such as wirele's ,local area networks (WLANs) the Secure Socket Layer (SSL) protocol, virtual private networks (VPNs) and firewalls. The IPSec cryptographic design can provide both the necessary security and performance for phone line modems, TI wireless and IO Mbit/sec ethernet networks.
1. INTRODUCTION Internet protocols were first developed in the mid-1970s when the Defense Advanced Research Projects Agency (DARPA) became interested in establishing a packet-switched network that would facilitate communication between dissimilar computer systems [l]. DAFWA funded research work by Stanford University, which resulted in the development of the Internet Protocol (IP) suite. The current version of this protocol is IP version 4 (1Pv4). However, a newer version, IPv6 [2], was designed to accommodate the increase in the Internet's popularity and is currently being utilized in limited portions of the Internet. IPSec (Internet Protocol Security) is an extension to the IP suite and is a globalised solution to the problem of Internet security. It is applied to the Network layer - layer 3 of the 7layer OS1 reference model. More specifically it operates on the Internet layer of the TCPnP protocol suite and thus, provides inherent security to any application. Rather than requiring each email program or Web browser to implement its own security mechanism, IPSec involves a change to the underlying facilities
0-7803-7587-4/021$17.00 02002 IEEE
133
that are used by each application [3] and also allows security to be applied to network traffic without involving end users. In this paper we present a novel architecture and singlechip hardware design capable of performing the lPSec Authentication Header (AH) and Encapsulating Security Payload (ESP) cryptographic requirements. The two authentication algorithms specified for use in AH and ESP are HMAC-SHA-I and HMAC-MD5. In this paper we choose the HMAC-SHA-I algorithm for implementation since SHA-I proves to be the stronger and more secure of the two underlying hash algorithms [3, 41. The Data Encryption Standard (DES) algorithm is designated as the encryption algorithm to be employed in ESP. However, in June 1997 the DES algorithm was successfiIlly cracked [5]. As an interim measure the National Institute for Standards and Technology (NIST) standardized Triple-DES, which is now commonly used in ESP. In December 2001, after a lengthy development effort, DES was replaced by the Advanced Encryption Standard (AES) algorithm, Rijndael, as the Federal Information Processing Encryption Standard (FIPS). This modification has yet to be reflected in the IPSec standards. Predicting that this change will take place in the near future, the design outlined in this paper utilizes the new Rijndael algorithm in implementing IPSec. It is believed that IPSec as it stands is too complex to be secure [6], since it supports many different algorithms, modes and system situations. Therefore, in the proposed IPSec cryptographic design, only the stronger of the two mandatory authentication algorithms and a well-studied secure encryption algorithm, selected by NIST to protect sensitive data, are chosen for implementation. The design is also capable of supporting any application requiring both authentication and encryption. For example, it could be utilized to provide the security needs of wireless LANs. In recent years, there has been a tremendous growth in the wireless communications market. The IEEE 802.11 protocol is the principal standard for wireless LANs. However, the authentication and encryption methods defined by the existing IEEE 802.11 standard have recently been shown to be unsatisfactory [7, 81 and it has been suggested that IPSec should be employed to provide the security requirements [SI. The required processing power for security functions, especially for IPSec, is large and for many applications greatly exceeds that possible through software implementations [9]. Therefore, there is a need to implement such computations directly in hardware. Hardware implementations typically achieve significantly higher speeds than their equivalent software counterparts. The design presented in this paper has
been implemented on a Xilinx Virtex XCVIOOOE FPGA device. However, the concepts and approach used are readily extendible to other FPGARLD technologies and to ASIC implementation. The paper is arranged as follows. The IPSec protocol is described in section 2 and in particular the AH and ESP security mechanisms are discussed. The IPSec hardware design is explained in section 3 and performance results are provided in section 4. Section 5 contains some concluding remarks.
2. IPSEC PROTOCOL IPSec is essentially a set of extensions to the IP protocol and is described in several Request For Comments (RFCs) [IO, 11, 121. IPSec is designed to provide.support for: Confidentiality
-
Authentication
-
Integrity
-
Replay Protection
-
Protects the data from disclosure to unauthorized bodies. Assures that received data was indeed transmitted by the body identified as the source in the data packet header. Maintains data consistency and ensures that data has not been altered by unauthorized persons. Protects against replay attacks, in which a packet is extracted from the data stream and reused later by an attacker.
The IPSec protocols include instructions for integration in both IPv4 and IPv6. However, in this paper the protocols are discussed only in respect to IPv6. The two security mechanisms of IPSec are the Authentication Header (AH), which provides data origin authentication and connectionless integrity, and the Encapsulating Security Payload (ESP), which provides connectionless data confidentiality services [ 131. Both the AH and ESP are used in accordance with a security association (SA). The security association is the agreement between two or more bodies on the security services they wish to utilize, such as which algorithm, mode and keys to use in the AH and ESP mechanisms. IPSec supports two methods of operation, tunnel mode and transport mode. In transport mode, only the upper-layer protocol data segment of the IP packet, for example, a Transmission Control Protocol (TCP) segment, is authenticated or encrypted and it is typically used for end-to-end protection of data packets between two hosts. In tunnel mode the entire IP packet is authenticated or encrypted. The result is then transmitted within another IP packet which contains a new outer header. In effect, the entire original packet travels through a ‘tunnel’ from one point of an IP network to another. Tunnel mode can be used between firewalls to create a virtual private network (VPN) [14]. Efficient key management is also an important aspect of IPSec. The default automated key management protocol chosen for employment with IPSec is the Internet Key Exchange (IKE) [15]. IKE is not discussed in this paper and the authors concentrate only on the cryptographic requirements of AH and ESP.
134
2.1 IP Authentication Header The Authentication Header (AH) provides support for data integrity and authentication of the IP packets [4]. The AH is described in Table 1. The scope of authentication in the AH varies between transport and tunnel mode. In transport mode, the MAC is calculated over all the IP header fields which remain unaffected during transit or which are predictable in value by the receiving end-point. Header fields that will change in transit are set to zero for the MAC calculation, for example, the authentication data field. In tunnel mode the entire original IP packet and the new IP header and extension fields are authenticated except for those fields that change during transit.
2.2 IP Encapsulating Payload Data The IP AH does not transform the payload data of an IP packet and thus it remains unprotected to attacks such as eavesdropping. The Encapsulating Payload Data (ESP) mechanism offers data confidentiality, including message and limited traffic flow confidentiality [4]. ESP can also provide authentication if required by the user. The ESP header is described in Table 2. Similarly to the AH, the scope of encryption and authentication varies for ESP in transport and tunnel mode. In transport mode, the Payload data, Padding, Pad Length and,Next Header fields are encrypted. If authentication is iny$orated, only the IP payload is authenticated. In tunnel mode the entire original IP packet is encrypted and optionayyauthenticated.
2.3 Authentication Algorithm - HMAC-SHA-1 The two authentication algorithms specified in the IP Authentication Header and Encapsulating security Payload RFCs [ I I , 121 are the HMAC-MD5 and HMAC-SHA-1 algorithms. MD5 and SHA-I have many similar characteristics and therefore, a hardware design capable of performing both message digests is possible. However, the SHA-I message digest is 32bits longer than the MD5 digest and is considered stronger against brute force attacks. In 1996 the MD5 algorithm was shown to be vulnerable to specific collision search attacks [16]. Hence, in this paper we have selected only the HMAC-SHA-1 algorithm for implementation purposes. The secure hash algorithm (SHA-I) operates on a message in 5 12-bit blocks and produces a 160-bit message digest. The maximum message length acceptable is 2” bits. SHA-I is performed as follows:
-
Pad message to length E 448 mod 5 12 Append message length as a 64-bit binary number Parse message into N x 5 12-bit blocks of data Initialize 5 x 32-bit words, A, B, C, D and E Perform 80 iterations of SHA-1 processing function on first 5 12-bit data block Resulting 160-bit output initializes A, B, C, D and E for processing function of next data block After all N data blocks have been processed, final output forms 160-bit message digest
Field
Payload Da f a
Padding
Pad Length
I Nexf Header
I
Function
Length
Security Parameter Index (SPI) Sequence Number
32-bit 32-bit
Identifies the security association Counter value which indicates number of messages sent from sender to receiver using current SA - allows replay protection Refers to the data to be encrypted by the encryption algorithm. variable The data is a transport-level segment in transport mode and an entire E’packet in tunnel mode Padding is used to ensure that the length of the data to be 0-255 encrypted (payload data +pad length + next header) is an integral bytes multiple of the encryption algorithm’s input block size. Padding can also be used to disguise the message’s true length and thus provide traffic flow conidentiality 8-bit I Specifies the length of the padding field I 8-bit I Identifies the tvoe of header that follows the ESP header.. e. x, . I
