EFFICIENT 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, U.S.A.

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 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 data

AFTER 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.

314

S. Andukuri M. and Edward Chow C. (2010).

EFFICIENT ASYMMETRIC IPSEC FOR SECURE ISCSI.

In Proceedings of the International Conference on Security and Cryptography, pages 314-317

DOI: 10.5220/0002996903140317

 SciTePress

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 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 cthe 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.

Figure 2: Proposed AsymmetricIPsec Scheme.

At the destination only the TCP, iSCSI header

are 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 same encrypted 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 2 shows

the proposed scheme.

2 ASYMMETRIC IPSEC FOR

ISCSI PROTOCOL DESIGN

The essentials of the Asymmetric IPsec for iSCSI

scheme are detailed as follows:

Third party

scsi

iscsi

tcp

ipse c

Re-decryption

Decrypted

here

Encrypted

here

Decrypted

here

To iscsi

target

To iscsi

initia tor

Encrypted

here

Initiator Target

Re-encryption

Unencrypted

payload

scsi

iscsi

tcp

ipse c

Encrypted

payload

Only heade rs

Decrypted

here

Only headers

Encrypted

here

Payload

Decrypted

here with

custom key

To is csi

target

To iscsi initiator

Payload

Encrypted

with custom key

Initia tor

Targe t

Encrypted

payload

Unencrypted

payload

scsi

iscsi

tcp

ipse c

scsi

iscsi

tcp

ipsec

EFFICIENT ASYMMETRIC IPSEC FOR SECURE ISCSI

315

2.1 When the Initiator is Sending

iSCSI Date to the Target

• In the 'sending side' code of the IPsec layer on

the initiator, identify and isolate the user data in

the network traffic going to the target .

• Encrypt the rest of the traffic (i.e. All traffic

other than the user data) using the standard IPsec

mechanism, using keys generated and managed

by the IKE.

• Use a custom key, generated independently of

the IKE mechanism, to encrypt the user data. Do

not share this key with the target. Save this key

for future use to decrypt the same user-payload

when it is returned.

• At the target, decrypt the headers using standard

IPsec procedure, but do not attempt to decrypt

the user payload. Pass it in the encrypted form to

the upper layers so that the SCSI layer can write

it as is (in the encrypted form) to disk.

2.2 When the Initiator is Trying to

Read the iSCSI Data from the

Target

• On the target, encrypt the headers using standard

IPsec mechanism. Do not attempt to encrypt the

user payload.

• On the initiator, decrypt the headers using the

keys generated and managed by IKE. Use the

second, custom key originally used to encrypt the

user data, to decrypt the data.

• In order to come up with an implementation of

this scheme, the pattern of the flow of packets

between the initiator and the target, WITHOUT

IPsec was studied to understand the exact

sequence of packets – both when writing to the

target and when reading from the target. The

study threw a surprise. When the initiator is

writing, the user payload is carried as a part of

Data-out PDUs. When the initiator is reading, the

user-payload is carried in a plain-vanilla TCP

packet. A packet with a Data-in PDU precedes

this packet. Even more surprisingly, the

DataSegmentLength field of the Data-In PDU

reflects the length of the user payload, even

though the payload is actually carried by a

separate packet. The author could not find an

answer for this behavior nor a way to change it

so that a Data-in PDU contains the user payload.

Hence the solution implemented was designed

accordingly.

The proposed scheme entails changes to the

IPsec-specific code in the Linux 2.6 network stack.

To understand how the actual code-modification

scheme was arrived at, it helps to recap how data

would be handled by the IPsec code in its native

form.

2.3 The Native IPsec operation on

iSCSI

The IPsec scheme used in the current thesis is called

'transport' mode. This means an ESP header is

inserted between the IP header and the TCP header.

The 'protocol' field in the IP header is changed by

the IPsec layer to '50' to indicate the presence of an

ESP header following the IP header. Prior to the

'encryption' part of the IPsec code, this 'protocol'

field of the ip header was populated with ‘6’, which

is 'TCP'. This information is saved in the IPsec layer,

before the 'protocol' field is overwritten with '50'.

The saved value will be entered later in the last byte

of the padding that is going to be added at the end of

the payload. The iSCSI header together with the user

data forms the payload for the TCP layer. The TCP

header plus the iSCSI payload, in turn forms the

payload for the IPsec protocol. This IPsec payload is

padded so that the total length (tcp header + IPsec

payload + padding) is an exact multiple of the block

size of the encryption algorithm being used. Care is

taken to make sure that the padding is at least 2

bytes long. The last byte of the padding, is set to the

protocol ID saved earlier. The last-but-one byte is

set to the total number of padding bytes (Hence the

need to make sure the padding is at least 2 bytes

long). The TCP header, iSCSI header, iSCSI

payload and the ESP trailer are together encrypted as

one unit. The padding forms the ESP trailer. An ESP

authentication trailer is inserted after the ESP-trailer.

This trailer contains the cryptographic checksum of

Ipheader + esp header + tcp header + iSCSI

header + iSCSI data + esp trailer.

The authentication trailer is NOT encrypted.

On the receiving end, the cryptographic

checksum is recomputed on the same components as

mentioned earlier. This is compared to the value

stored in the ESP authentication trailer. The packet

is rejected if they do not match. If they are found to

be matching, the code proceeds to decrypt the tcp

header + iscsi header + iscsi data + esp trailer. After

decryption, the esp header placed between the IP

header and the tcp header is removed. The '50' in the

'protocol' field of the IP header is replaced by the

value in the last byte of the padding. The last-but-

one byte of the total payload (which is the length of

the padding) gives the number of padding bytes to

be stripped.

SECRYPT 2010 - International Conference on Security and Cryptography

316

3 PERFORMANCE ANALYSIS

We have set up a User Mode Linux (UML) virtual

machines test bed with our Asymmetric IPsec

implementation.

The available alternative involves the following

computations, given in terms of 16 byte blocks – the

block size for the AES encryption algorithm. Table 1

reports the respective durations taken for encryption

and decryption during the round-trip of a single TCP

segment of 1024 bytes. In the table, the TCP header

is shown as consisting of two 16-byte blocks. This

has been done for two reasons.

In the proposed scheme, the TCP header + iSCSI

header unit needs to be an integer multiple of the

block size. Given that the iSCSI header is fixed at 48

bytes (which happens to be an integer multiple of 16

bytes), even if the TCP header were to have the

smallest possible size of 20 bytes, the TCP header

still needs to be padded with of 12 bytes so that the

sum of TCP header size + iSCSI header size comes

to be an integer multiple of the block size.

Incidentally, the TCP header on the virtual machines

was indeed observed to be 32 bytes long.

For the other scheme, even if the TCP header

were to be the smallest possible size of 20 bytes, the

fact remains that the total of TCP header + iSCSI

header + payload needs to be padded to become an

integer multiple of 16 bytes. The total number of 16-

byte blocks does not change. From the above

numbers, it is obvious that the proposed scheme is

expected to take only 36% (74/202) of the other

scheme. This gain in efficiency, combined with the

fact that the data never is left unencrypted outside of

the initiator, makes the proposed scheme attractive.

Table 1: Number of 16-byte blocks encrypted during

round-trip of 1 TCP segment.

Under Available

Options

(3*64 + 2 *(2+3))

Under Proposed Scheme

(64 + 2*(2+3))

Encrypted 202

blocks

Encrypted 74

blocks

Decrypted 202

blocks

Decrypted 74

blocks

From the experiments conducted on the test bed, we

observed as the file size increases from 1M and on,

the performance gains gravitate towards 25% - 30%

range. However, this is less than the expected 65%

gain as mentioned earlier. Running a profiler on the

implementation of the proposed scheme might throw

more light on whether there is room for

improvement.

4 CONCLUSIONS

An efficient asymmetric IPSec protocol

enhancement was proposed for reducing the

processing time and improving security of secure

iSCSI based online-backup systems. A development

test bed was constructed using UML virtual

machines to facilitate the development/debugging of

IPSec kernel/networking code. A benchmark test

bed with two real PCs was installed with the new

modified IPSec module and a set of test runs were

made to collect the performance data of the

proposed system. The analysis of the data from the

UML test bed does not show the expected

performance gains but running the same trials on

actual machines shows performance gains in the

25%-30% range.

REFERENCES

Kirk, J., 2006, “Symantec unveils remote data backup

software” by Jeremy Kirk,

http://www.computerworld.com/securitytopics/

security/story/0,10801,110148,00.html

Clark, T., 2002, “IP SANs: A Guide to iSCSI, iFCP, and

FCIP Protocols for Storage Area Networks”. Addison

Wesley Professional, 2002.

Shurtleff, J., 2004, “IP storage: A review of iSCSI, FCIP,

iFCP,” 2004.

http://www.iscsistorage.com/ipstorage.htm

RFC2401, 1998, “Security Architecture for IP,” Kent &

Atkinson.

†: 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.

EFFICIENT ASYMMETRIC IPSEC FOR SECURE ISCSI

317