Title: Efficient Asymmetric Secure iSCSI
1Efficient Asymmetric Secure iSCSI
2Outline of the talk
- Goals of the project
- Motivation for the project
- Current options for security
- Proposed scheme
- Three components iSCSI. IPsec, UML
- Design and Implementation
- Results
- Lessons learnt, Future work, Conclusions
3Goals
- A dual-key asymmetric cryptographic enhancement
of IPsec to reduce total IPsec processing time
and enhance data security for remote storage
using iSCSI. - Demonstrate use of virtual test beds running UML
to develop networking software.
4Motivation
- Remote storage
- NAS Network Attached Storage
- Roots in File server
- NFS,CIFS
- SAN Storage Area Network
- FCIP, iFCP, iSCSI (All SCSI Based)
- iSCSI is the Focus of the project -
- Smart, inexpensive, No special hardware
5Storage Security Considerations
- Importance of storage security
- Need for end-to-end security. Possible currently.
- Using Applications to secure data can leave gaps.
- IPsec provides standardized security
- It addresses security in transmission
- Available options to achieve storage security as
well
6Related Work
- RFC 3723 - Securing Block Storage Protocols over
IP - Microsoft, Cisco, Intel all have
implementations of iSCSI Initiator and Target. - Available hardware implementations of iSCSI
IPsec combined hardware Astute Networks
SA1000 SuperHBA for example.
7Choices for data security
(Example - ssl)
W
With IPsec Multiple encryptions/decryptions With
out IPsec No authentication. Headers insecure.
8The proposed scheme
Encrypted
9How SCSI Works
10-byte Command Descriptor Block
Tells how many blocks to transfer
Tells Where to start transfer
Tells How many bytes to transfer
10What exactly is iSCSI
- internetSCSI
- SCSI Initiator and Target across IP Network
- SCSI CDB delivered in an IP packet
11iSCSI protocol layers
12Why iSCSI
- Maximum use of proven technology
- TCP ensures delivery , order (mostly)
- IP ensures finding/reaching remote hosts
- IPsec ensures security in transmission
- Works on Ethernet cards and cat-5 cables
- Any block device can be presented as SCSI device
- Speeds getting to be comparable to FC
13How iSCSI works
- PDU (Protocol Data Unit) is the basic unit of
communication - iSCSI payload is made of PDU header followed by
Data. - Several PDU types (called opcodes) based on the
source. - Fixed length PDU header
14Structure of a PDU header
iSCSI Basic Header Segment
15How iSCSI works
- Initiator initiates connection (Surprise !)
- Discovery
- Login
- Full Feature phase
- Sends commands to Target
- Target responds
- Logout
- Supports multiple connections per session
- iSCSI needs to ensure order across connections
16iSCSI packet Exchange
17IPsec
- Security integrated into network stack
- Secures ALL traffic between hosts
- Inherent in IPV6, Supported for IPV4
- Consists of 3 protocols
- IKE For Dynamic Key management
- ESP For Encryption and authentication
- AH Authentication only
- Tunnel Mode or Transport mode
- Transport mode chosen in the project
18Packet encapsulation combinations in IPsec
19Encryption algorithm used in current project
AES with a 192 bit key AES uses 128 bit block
size The Scheme is independent of algorithm.
Verified with 3DES (192 bit key, 64 bit block)
Authentication algorithm used Hmac-md5 128 bit
key
20How the proposed scheme looks at a packet level
21How the packet is modified for the proposed scheme
Encrypted together using IKE-generated key
Second, local key and IV to encrypt this portion
Length of payload per packet 1024
22Implementation logic during Write
On Initiator On Target
If DestPort 3260 opcode is Data-Out Skb-gtlen adds up to sum of headers and body Check length of TCP iSCSI Headers Pad TCP header if necessary Encrypt payload Re-compute checksum and update TCP header Encrypt headers Authenticate (ESP) Authenticate (ESP) If (skb-gtlen gt 32 bytes) Decrypt 32 bytes if (destport 3260) Decrypt till end of iSCSI Hdr If Opcode is Data-Out Skb-gtlen adds up to sum of headers and body Do not Decrypt payload Remove ESP header Set nextTCP
23Implementation logic during Read
On Target On Initiator
If (sourcePort 3260) If length indicates presence of payload if necessary pad TCP header encrypt TCPhdr iSCSI Hdr Authenticate Else Encrypt using IKE keys Authenticate (ESP) If (skb-gtlen gt 32 bytes) Decrypt 32 bytes if( (source port 3260) length indicates that there is payload, and no iSCSI Hdr ) Decrypt payload using customized key Recompute checksum else just decrypt using IKE key
24Development test bed setup
A file on the Target Virtual machine is Presented
as a SCSI disk To the initiator.
25Virtual machines of User Mode Linux
- Multiple Virtual machines running on a single
host. - Can be built with any kernel source tree with
ARCHum make option. Can be started just like an
application. - Multiple instances can share a root file system
using Copy-On-Write (COW) layer. - Can optionally access the host file system as
hostfs (Helps during development). - Can be networked to the host, to each other and
outside world. SKA helps make it almost
impossible to hack into the host. Excellent as
honeypot. - Can be attached to gdb and stepped-thru like any
application.
26Kernel Debugging in User Mode Linux
- Debug static kernel code by attaching to gdb.
- Debugging modules is a (quite) a bit more tricky.
- Run the Perl Script in a separate terminal to
create a pseudo terminal - Run the Expect script in a separate terminal,
to setup gdb AND instantiate a screen session
kicking off UML attached to gdb. - Find above session with screen ls. Attach to
it with screen r. - Add modules details to gdb with add-symbol-file.
27Expected Savings in IPsec Computational effort
Under Available options (364 2 (23)) Under Available options (364 2 (23)) Under Proposed scheme (64 2(23)) Under Proposed scheme (64 2(23))
Encrypted 202 16-byte blocks Encrypted 74 16-byte blocks
Decrypted 20216-byte blocks Decrypted 7416-byte blocks
Data shown below is for the round trip of 1K of
user data
28Performance data with available alternative (on
UML test bed)
29Performance data under proposed scheme (on UML
test bed)
30Impact of File size on performance
31Lessons Learnt
- iSCSI Initiator and Target (Apps and modules)
need to built on host machine and installed into
UML rootfs. Take care to point to right kernel
tree. - UML Kernel support for iscsi_transport needs to
be configured as a module and not static. - Debugging modules (Linux and iSCSI) inside UML
proved very tricky. - TCP checksum needs to be recomputed in IPSec
after segmented encryption on initiator. Also
after decryption of data that has been read back. - The payload length is held very dearly by iSCSI
layer (Both initiator and target). Trying to
tweak the length in IP layer doesnt work !
32Future Efforts
- Expand to include arbitrary file sizes
- Include in an IPsec iSCSI TOE
- User interface, /Proc system based enhancements
to improve flexibility, security - Ability to mark packets using netfilter hacks.
- Expand IPsec key generation mechanism to include
iSCSI - With some modifications, the same scheme can be
used to encrypt with application layer SW and NOT
Re-encrypt/decrypt at IPsec.
33Conclusions
- An asymmetric IPsec protocol enhancement was
developed for improving the security and
performance of remote online backup systems. - Demonstrated how UML can be used to facilitate
kernel/networking software. development. - An invention disclosure was filed with University
of Colorado Tech Transfer Office. - A paper to be submitted to ICNP conference.
34Benefits of the scheme
- Addresses gaps in storage security, expected to
improve performance and eliminate need for
multiple tools to provide security. - Cuts hardware costs. CPU/TOE on the Target need
not be as fast as those on Initiator. Or can be
used to process more requests. - Flexibility The scheme can be used with any
Encryption and Authentication scheme supported by
IPsec. - The scheme does not weaken other security
measures. - The idea of the scheme probably can be applied to
SSL tunneling.