1
EFFICIENT ASYMMETRIC SECURE ISCSI
BY
MURTHY S. ANDUKURI
A thesis submitted to the Graduate faculty of the
University of Colorado at Colorado Springs
in partial fulfillment of the
requirements for the degree of
Master of Science
Department of Computer Science
2006
© Copyright by Murthy S. Andukuri2006
All Rights Reserved
This thesis for the Master of Science in Computer Science degree by
Murthy S. Andukuri
has been approved for the
Department of Computer Science by
______
C. Edward chow, Chair
______
Marijke Augusteijn
______
Jugal Kalita
______
Date
Murthy, Andukuri S. (M.S., Computer Science)
Efficient Asymmetric Secure iSCSI
Thesis directed by : Professor C. Edward Chow
iSCSI is an application level protocol that enables storage of data on a disk attached to a networked remote host. IPsec, when used in conjunction with iSCSI, secures this data while in transit. IPsec provides security by encrypting the data at the sender and decrypting at the receiver. This means that the data is exposed and vulnerable at the receiver. There are currently two choices to secure the data at rest on the remote disk - both involving the use of third party encryption software to either (1) re-encrypt the data at the remote end or, (2) Encrypt the data before transmitting to the remote end. The second option, while better than the first, still requires additional encryption software on the remote site, impacts on overall performance, and introduces additional security risk. The current thesis proposes a new asymmetric IPsec scheme to enhance the security of data at the remote end, while simultaneously avoiding the cost of additional of software and improving the over all 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 senderand traditional IPsec is modified to encrypt/decrypt only on the TCP/iSCSI headers. A development testbed was built using User-Mode-Linux virtual machines for developing/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 testbed wasbuilt 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%.
Acknowledgements
I would like to express my sincere appreciation to Dr. Edward Chow for his patience during the unusually long time I took to come up with the idea for this thesis, and to implement the scheme as described in the thesis.
CONTENTS
Chapter
1.Introduction
1.1Motivation for enhancing remote storage security
2IPsec
2.1The SAD and SPD databases
2.2How the SAD and SPD are used for outbound traffic
2.3How the SAD and SPD are used for inbound traffic
2.4IPsec deployment options
2.4.1Basic options of IPsec deployment
2.4.1.1IPsec AH in transport mode
2.4.1.2IPsec ESP in transport mode
2.4.1.3IPsec AH in tunnel mode
2.4.1.4IPSec ESP in tunnel mode
2.5IPsec Implementations
2.6IPsec operation modes
2.6.1'Daemon' mode of IPsec operation
2.6.2Manual mode of IPsec operation
Chapter 3
3SCSI based Storage Options
3.1SCSI based Internet storage architectures
3.1.1FCIP: Fiber channel over IP
3.1.2iFCP
3.1.3iSCSI
3.1.4ISCSI Command progression between Initiator and target
3.1.4.1iSCSI Protocol layers
3.1.5Motivation for the project
3.1.6Stages in iSCSI initiator-target interactions
3.1.6.1Naming/Addressing
3.1.6.1.1Formats of iSCSI name
3.1.6.2Session establishment and management
3.1.7Phases of iSCSI session of interest in the current thesis
3.1.8Full Feature Phase
3.2iSCSI 'Write's
3.3iSCSI 'Read's
3.4Other PDU exchange relevant to the thesis
4Details of the proposed enhancement
4.1When the initiator is sending iSCSI date to the target
4.2When the initiator is trying to read the iSCSI data from the target
4.3The native IPsec operation on iSCSI
4.4How the native-IPsec issues are managed in the implementation
4.4.1Identify iSCSI data.
4.4.2Encrypt the headers separately
4.4.2.1iSCSI packets which do not carry any user data.
4.4.2.2iSCSI packets carrying user data.
4.4.3Updating TCP checksums:
4.4.3.1The sending side in the initiator:
4.4.3.2The receiving side of the initiator
4.4.3.3Scope of the implemented solution
4.4.3.4Ethereal Packet pattern for write to target
4.4.3.5Ethereal Packet pattern for read from target
5Performance data and analysis
5.1Role of User Mode Linux......
5.2Performance Analysis
5.2.1Computational details of the available scheme
5.3Performance data of the proposed scheme on a UML test bed
5.4Analysis of results from UML testbed......
5.5Performance data of the proposed scheme on the lab test bed
5.6Analysis of results from the lab test bed......
6Lessons Learnt
7Future Directions
8Conclusions
8.1Advantages of the current approach
8.2Limitations of the current approach
9Bibliography
10APPENDIX A : User Guide of AIPsec
10.1Setting up IPsec
10.1.1Build the setkey utility
10.1.2Package dependencies for setkey
10.1.3Commands to build setkey
10.1.4Generating a key
10.1.5Generating SAD and SPD entries using the setkey utility on target
10.1.6Displaying SAD entries on the target
10.1.7Displaying SPD entries on the target
10.1.8Generating SAD and SPD entries using the setkey utility on initiator
10.1.9Displaying the SAD entries on the initiator
10.1.9.1Displaying SPD entries on the initiator
10.2Appendix B : Running the iSCSI target program
10.2.1Installing target on a host machine
10.2.2Installing target on a UML
10.2.3Running the target
10.3Appendix C: Running iSCSI Initiator program
10.3.1Installing the initiator in the host machine
10.3.2Installing the initiator in a virtual machine
10.3.3Running the iscsi initiator
10.3.3.1Sample iSCSI Initiator Config file
10.3.3.2Sequence of commands to run iSCSI Initiator
10.4Appendix D: Compiling UMLs, setting up bridge and debugging kernel modules with UML
10.4.1Building and installing uml modules
10.4.2Debugging uml modules
10.4.2.1Perl script to setup ground for debugging modules in gdb
10.4.2.2Using GDB to debug modules
10.5Appendix E : Compiling sg_dd and setting it up
11Appendix F: A typical run through the test bed
11.1Step 1: Create the ‘disk’ on the target
11.2Step 2: Start the iSCSI target software
11.3Step 3: Start the iSCSI Initiator daemon
11.4Step 4 : Login to the target
11.5Step 5 : Verifying that data is scrambled on the target
11.6Step 6: Read data from the Initiator......
11.7Step 7: Verifying the correctness of the data......
TABLES
Table
1.A Sample SAD
2.A Sample SPD
3.Basic Header Segment (BHS) of an iSCSI PDU Header
4.Initiator PDUs......
5.Target PDUs......
6.Keywords in various PDUs
7.Phases in an iSCSI connection......
8.PDU exchange during an initiator 'write'......
9.PDU exchange during a an initiator 'read'......
10. Number of 16-byte blocks encrypted during round-trip of 1 TCP segment.....
11. Performance of the UML test bed when transferring a 1K file
12.Performance of the UML test bed when transferring a 10K file
13. Performance of the UML test bed when transferring a 100K file
14. Performance of the UML test bed when transferring a 1M file
15. Performance of the UML test bed when transferring a 10M file
16. Performance of the UML test bed when transferring a 100M file
17. Performance of the lab test bed when transferring a 1K file......
18.Performance of the lab test bed when transferring a 10K file...... 6
19. Performance of the lab test bed when transferring a 100K file
20. Performance of the Lab test bed when transferring a 1M file
21. Performance of the Lab test bed when transferring a 10M file
22. Performance of the Lab test bed when transferring a 100M file
FIGURES
Figure
1. Option 1: IPsec in transit. No security for data at rest
2. Option 2: Re-encryption/decryption at target site
3. Option 3: Encrypt data at client site. No IPsec
4. Option 4: Encrypt at client site. Transmit using IPsec
5. Option 5: The proposed scheme
6. IPsec AH Header
7. IPsec ESP header and trailer (without authentication)
8. IPsec AH transport mode
9. IPsec ESP in Transport mode
10. IPsec in AH Tunnel mode
11. IPsec ESP in Tunnel mode
12. Basic SCSI architecture
13. Command flow in an iSCSI setup
14. Details of the iSCSI layered model
15. Structure of a 10-byte CDB
16. Contents of a 10-byte CDB when writing of 1K to target
17. Contents of a 10-byte CDB when reading 1K from target
18.PDU exchange during an iSCSI login
19. Packet modification under proposed scheme
20. Packet sequence between initiator and target during a 'write'
21. Packet sequence between initiator and target during a 'read'
22. A schematic of the UML test bed used in the current thesis
23. Performance on UML test bed under currently available alternative
24. Performance on UML test bed under the proposed scheme
25. Performance of the different schemes of iSCSI communication
(on UML testbed)
26. Performance on the lab test bed without IPSec
27. Performance on the lab test bed under currently available alternative
28. Performance on the lab test bed under the proposed scheme
29. Performance gain under proposed scheme for files sizes 1K - 100K
30. Performance gain under proposed scheme for file sizes 1M - 100M
31. Performance of the different schemes of iSCSI communication
(on Lab test bed)
1
Chapter1
- Introduction
The goals of the current thesis are as follows.
- To propose a dual-key asymmetric cryptographic enhancement of IPsec that reduces IPsec processing time and enhancesdata security during remote storage using iSCSI.
- To demonstrate how virtual machines running UML can be used to develop/modify/run kernel and networking software on virtual testbeds for networking projects.
1.1Motivation for enhancing remote storage security
Remote backup of data for security has become a subject of rapidly growing interest in the recent times[1][2]. 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 [3][4]. 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 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. Figure 1shows such a scenario.
Figure 1. Option 1: IPsec in transit. No security for data at rest
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 [5].
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 data AFTER it has reached its destination. This makes data very vulnerable to theft when the target site gets break-in[6].
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 2 shows such a scenario.
Figure 2. Option 2: 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 [4]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 Option 2 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.
Figure 3. Option 3: Encrypt data at client site. No IPsec
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. Figure 4 shows such a scenario.
Figure 4. Option 4: Encrypt at client site. 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 the process of encrypting/decrypting the transmitted data be divided into two parts –
The encryption of the TCP and iSCSI headers is performed per the normal IPsec procedures – using the keys generated and managed by Internet Key exchange (IKE) between the source and destination.
The core IPsec encryption functionality, i.e.,the algorithm implementation excluding the IKE, is still used to encrypt the user data. However, the key for the encryption is generated on the source machine independent of the IKE mechanism. This key will NOT be shared with the destination. At the destination only the TCP, iSCSI headerare decrypted per normal IPsec process to extract the iSCSI details and to write the user data, which continues to be in encrypted form, to the remote disk. During retrieval by the sender, the user data is returned in the sameencrypted form and accompanied by headers that are now appropriately encrypted by IPsec on the target. Upon arrival, the headers are decrypted per the normal IPsec scheme, i.e. using the keys mutually agreed upon through the IKE mechanism. The user data is now decrypted using the core IPSec decryption functionality but with the customized, locally generated key that was used originally to encrypt the data. Figure 5 shows the proposed scheme.
Figure 5. Option 5: The proposed scheme
Chapter2
2IPsec
IPsec [5][6] is the name given to a collection of protocols that together form the mandatory security component of the next generation IPV6 protocol. This is an optional part of IPV4. IPSec offers protection to the data by encrypting and/or authenticating it at the sender before transmitting. There are three protocols in IPsec.
- Internet Key Exchange (IKE) guides how a handshake is established between the sender and receiver, how keys are exchanged and renewed. It has an IANA (Internet Assigned Numbers authority) port number of 500.
- ESP (Encapsulation Security Payload) guides how data can be encrypted at the sender and decrypted at the receiver. This has an IANA protocol number of 50.
- AH (Authentication Header) guides how the data can be authenticated at the sender and verified at the receiver. The IANA protocol number for this protocol is 51.
There is a vast amount of literature available – explaining, analyzing and evaluating IPsec protocols and implementation. A summary is given below to help understand the role and relevance of IPsecin the current thesis. The figures are reproduced from [7] because they do an excellent job of illustrating the concepts.
IPsec secures data traffic between two hosts by encrypting and/or authenticating the data. In either case, the two hosts agree on details like the crypto algorithms, the keys, the lifetimes of the keys etc during an IKE phase that takes place before the actual encryption/authentication. The two hosts in question can be either gateways behind each of which there are other hosts as in any subnet, or the actual points of termination for the traffic. In the former case, when hosts in one subnet try to communicate with hosts in the other, the traffic can be protected by encrypting /authenticating only in the span of the network between the gateways (not end-to-end). In this case, the entire packet is embedded in new IP headers, thereby creating an IP tunnel. In the latter case, IPsec is said to operate in the 'transport' mode. In either case, during the actual data transfer, encryption and authentication headers and/or trailers are inserted into the data packets. The placement of the headers/trailers depends on the actual mode of IPsec protection. These headers carry information that helps the receiver look into its own IPsec-related databases (to be discussed below) for identifying the information to decrypt/re-authenticate the data.
2.1The SAD and SPD databases
Imagine data communication between hosts 'A' and ''B' using IPsec. The set of all parameters like the protocol to use (AH or ESP), keys, crypto algorithms, lifetime keys, etc., that either of the hosts needs to process the payload. is called a 'Security Association' (SA). This is unidirectional therefore each host has an out-bound SA and in-bound SA. An Outbound SA on host A appropriately mirrors the corresponding in-bound SA on host B and vice versa. The set of all security associations is called a Security Association Database (SAD). A typical SAD looks like in Table 1[8].