1 INTRODUCTION2 ASYMMETRIC IPSEC FOR ISCSI PROTOCOL DESIGN3 PERFORMANCE ANALYSIS6 CONCLUSIONEFFICIENT ASYMMETRIC IPSEC FOR SECURE ISCSI Murthy S. Andukuri* and C. Edward Chow† Department of Computer Science, University of Colorado at Colorado Springs, 1420 Austin Bluffs Parkway, Colorado Springs, CO 80918, USA [email protected], [email protected] Keywords: IPSec, Asymmetric Secure Protocol, iSCSI, Online Data Backup Abstract: In this paper we propose a new asymmetric IPsec scheme to enhance the security of data at the remote end, while simultaneously improving the overall performance. The idea is to apply IPsec encryption/decryption in a segmented manner on the iSCSI traffic, such that the user data remains encrypted after leaving the sender, and is decrypted only when it is retrieved by the sender. A dual key cryptographic scheme is proposed where the private key is used to encrypt the iSCSI payload at the sender and traditional IPsec is modified to encrypt/decrypt only on the TCP/iSCSI headers. A development test bed was built using User-Mode-Linux virtual machines for developing and debugging the asymmetric IPsec software and running as the sender and receiver to verify the functionality and security features of the proposed design. A benchmark test bed was built with two real PCs where the asymmetric IPsec modules can be dynamically loaded. The performance results show that the existing implementation of the proposed asymmetric IPsec scheme reduces the IPsec processing time by about 25%. 1 INTRODUCTION Remote backup of data for security has become a subject of rapidly growing interest in the recent times (Kirk, 2006). The importance of backups, and remote storage for security in today's networked world can hardly be overstated. Of the various options available, iSCSI seemed the most worthy of study because its design smartly makes full use of the universally proven strengths of existing protocols like TCP, IP and IPsec, thereby reducing the cost, effort and time of learning, setup and deployment. The various mechanisms that can be used are FCIP, iFCP, iSCSI (Clark, 2002) (Shurtleff, 2004). Among these, iSCSI has been getting a lot of attention of late because it can be run on commonly available, relatively inexpensive IP networking infrastructure already in place. iSCSI is an application layer protocol that uses the available IP network to make a remote storage disk accessible as a simulated local SCSI disk. †: This research work was supported in part by two NISSSC AFOSR grant awards under numbers FA9550-06-1-0477 and FA9550-04-1-0239. *: Murthy Andukuri is now with Verizon Business. This work was done as part of his master thesis. This locally accessible remote disk can be written to, or read from, like any local disk. An iSCSI setup has two parts - The iSCSI initiator is the 'client' program located on the source machine and writes to / read from the remote machine. The iSCSI target is the software on the destination machine that helps store the data and return it on demand. iSCSI restricts itself to handling the user-level data and leaves the actual details of transmission to the TCP and IP layers. By default, the data is transmitted in plain text between the initiator and the target. This vulnerability can be remedied by using IPsec to secure the data in transit. IPsec is designed to provide interoperable, high quality, cryptographically-based security for IPv4 and IPv6. The set of security services offered includes access control, connectionless integrity, data origin authentication, protection against replays (a form of partial sequence integrity), confidentiality (encryption), and limited traffic flow confidentiality. These services are provided at the IP layer, offering protection for IP and/or upper layer protocols (RFC2401). IPsec encrypts the data leaving the network layer on the sender and, at the receiving end, decrypts the data before it leaves the network layer. This secures the data in transit but does not help secure the dataAFTER it has reached its destination. This makes data very vulnerable to theft when the target site gets break-in. This vulnerability can be alleviated by reencrypting the received data using a third party software – and redecrypt, so that the IPsec layer can encrypt it in preparation for transmission back to the sender. Figure 1 shows such a scenario. Third party SWscsi iscsitcpip ipsec Re-decryptionDecrypted hereEncrypted hereDecrypted hereTo iscsi target To iscsi initiatorEncrypted hereInitiator TargetRe-encryptionUnencrypted payloadscsi iscsitcpip ipsec Figure 1. Re-encryption/decryption at target site. This situation presents the following issues: • The data is in an un-secured form on a remote disk just after being received, and just before being transmitted. • This scheme involves three encryptions and three decryptions that increase the computational and operational costs. • The third party software involves extra cost. Another solution (Shurtleff, 2004) is to use application layer software to encrypt the data on the sender, store it in the encrypted state on the receiver and decrypt it only on retrieval. This scheme also involves three encryptions and three decryptions. However, this is better than that of Figure 1 described above, because the data is never in an un-encrypted state outside of the Initiator. This presents two choices, both of which have issues of their own. Scenario 1: Use an application layer software to encrypt user data, and transmit it without IPsec. Figure 3 shows this scenario. This leaves the iSCSI, TCP and IP headers exposed during transit. While the data is encrypted, the headers remain vulnerable. Scenario 2: Use an application layer software to encrypt user data and decrypt it after retrieval. Transmit using IPsec. This secures the TCP and iSCSI headers (and optionally the IP header as well). However, this also involves • RE-encryption of the encrypted payload on the sending side, • Decryption of the same on the receiving side to undo the above encryptions • RE-encryption of the encrypted payload on the receiving side for retrieval by sender • Decryption of the same on the sender (after retrieval) to undo the above, second encryption. As such, it is obvious that this scheme only partially addresses the shortcomings of the previous approach. The proposed efficient asymmetric IPsec scheme hopes to address the above concerns as follows. It is proposed that