Efficient Asymmetric Secure iSCSI
description
Transcript of Efficient Asymmetric Secure iSCSI
4/29/2006 Murthy SiSCSI 1
Efficient Asymmetric Secure iSCSI
Murthy Andukuri
4/29/2006 Murthy SiSCSI 2
Outline 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
4/29/2006 Murthy SiSCSI 3
Goals
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.
4/29/2006 Murthy SiSCSI 4
Motivation 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
4/29/2006 Murthy SiSCSI 5
Storage 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
4/29/2006 Murthy SiSCSI 6
Related 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.
4/29/2006 Murthy SiSCSI 7
Choices for data security
Third party SW
scsi
iscsi
tcp
ip
ipsec
Re-decryption
Decrypted here
Encrypted here
Decrypted here
To iscsi target
To iscsi initiator
Encrypted here
Initiator Target Re-encryption
Unencrypted payload
scsi
iscsi
tcp
ip
ipsec
Payload withOriginal encryption
Decrypted here
Encrypted here
Decrypted here
To iscsi
target
To iscsi initiator
PayloadRE-Encrypted
here
Initiator TargetPayload with
original encryption
Unencrypted payload
OriginalEncryption at app layer
Payload RE-Decrypted at app layer
scsi
iscsi
tcp
ip
ipsec
scsi
iscsi
tcp
ip
ipsec
W
(Example - ssl)
With IPsec : Multiple encryptions/decryptions
Without IPsec : No authentication. Headers insecure.
4/29/2006 Murthy SiSCSI 8
The proposed schemeEncrypted
payload
Only headersDecrypted
here
Only headersEncrypted
here
Payload Decrypted here with custom key
To iscsi target
To iscsi initiator
Payload Encrypted
with custom key
Initiator TargetEncrypted
payload
Unencrypted payload
scsi
iscsi
tcp
ip
ipsec
scsi
iscsi
tcp
ip
ipsec
Encrypted
4/29/2006 Murthy SiSCSI 9
How SCSI Works
Tells Where to start transfer
Tells how many blocks to transfer
Tells How many bytes to transfer
10-byte Command Descriptor Block
4/29/2006 Murthy SiSCSI 10
What exactly is iSCSI
‘internet’SCSI• SCSI Initiator and Target across IP Network
• SCSI CDB delivered in an IP packet
4/29/2006 Murthy SiSCSI 11
iSCSI protocol layers
4/29/2006 Murthy SiSCSI 12
Why 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
4/29/2006 Murthy SiSCSI 13
How 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
4/29/2006 Murthy SiSCSI 14
Structure of a PDU header
Data
iSCSI Basic Header Segment
4/29/2006 Murthy SiSCSI 15
How 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
4/29/2006 Murthy SiSCSI 16
iSCSI packet Exchange
4/29/2006 Murthy SiSCSI 17
IPsec 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
4/29/2006 Murthy SiSCSI 18
Packet encapsulation combinations in IPsec
4/29/2006 Murthy SiSCSI 19
Encryption algorithm used in current project : AES with a 192 bit keyAES 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
4/29/2006 Murthy SiSCSI 20
How the proposed scheme looks at a packet level
4/29/2006 Murthy SiSCSI 21
How the packet is modified for the proposed scheme
Second, local key and IVto encrypt this portion
Encrypted togetherusing IKE-generated key
Length of payload per packet = 1024
4/29/2006 Murthy SiSCSI 22
Implementation logic during ‘Write’
On Initiator On TargetIf DestPort == 3260 &&
opcode is Data-Out &&
Skb->len 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->len > 32 bytes)
{ Decrypt 32 bytes; if (destport == 3260)
Decrypt till end of iSCSI Hdr If Opcode is Data-Out &&
Skb->len adds up to sum of
headers and body { Do not Decrypt payload Remove ESP header Set next=TCP
}
}
4/29/2006 Murthy SiSCSI 23
Implementation 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->len > 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}
}
4/29/2006 Murthy SiSCSI 24
Development test bed setup
Host : running linux 2.6.12.1Physical memory : 640 M. Processor = 2 Ghz Celeron
80 GB Hard disk
ISCSI Initiator
UML instance running linux 2.6.12.1 andopen-iscsi 0.4-434
uml specs : 'physical memory' : 256M
File system : 1.4 GB
IP = 192.168.0.152
ISSI target
UML instance running linux 2.6.12.1 andiscsitarget-0.4.11
uml specs : 'physical memory' : 256M
File system : 1.4 GB
IP = 192.168.0.151
Bridge and TUN/TAP interfacesBridge created using brctl
TUN interfaces created using tunctl
Physical Host IP = 192.168.0.100
A file on the TargetVirtual machine isPresented as a SCSI diskTo the initiator.
4/29/2006 Murthy SiSCSI 25
Virtual machines of User Mode Linux
Multiple Virtual machines running on a single host. Can be built with any kernel source tree with ARCH=um
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.
4/29/2006 Murthy SiSCSI 26
Kernel 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 module’s details to gdb with add-symbol-file.
4/29/2006 Murthy SiSCSI 27
Expected Savings in IPsec Computational effort
Under Available options
(3*64 + 2 *(2+3))
Under Proposed scheme
(64 + 2*(2+3))
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
4/29/2006 Murthy SiSCSI 28
Performance data with available alternative (on UML test bed)
Write & Read with IPSecEncrypt & Decrypt at Target
0.18 0.21 0.11 0.14 0.09 0.12 0.1
0.44 0.391 0.4110.173
1.226 1.207 1.146 1.156 1.041 1.156 1.043
0.3460.3750.345
8.175 8.839 8.013 8.206 8.465 8.052 7.86
788.92 778.78 790.64 804.02 776.837 787.88 786.852
75.73177.51176.699
79.40676.54882.246 81.418
0
1
2
3
4
5
6
7
1 2 3 4 5 6 7
Sample
Tim
e in
sec
1
10
100
1000
Tim
e in
Sec
1K
10K
100K
1M
10M
100M
4/29/2006 Murthy SiSCSI 29
Performance data under proposed scheme (on UML test bed)
Write & Read under theProposed Scheme
0.11 0.14 0.09 0.12 0.10
0.17 0.15 0.17 0.240
0.89 0.9 0.93 0.85 0.84 0.83 0.85
0.18 0.21
0.18 0.21 0.19
8.68 7.79 8.18 7.63 7.63 7.67 7.61
782.65 782.86 777.23 765.48 762.29 763.15 762.55
79.0983.98 83.2 76.47
76.24 76.4 76.45
0
1
2
3
4
5
6
7
1 2 3 4 5 6 7
Sample
Tim
e in
sec
1
10
100
1000
Tim
e in
Sec
1K
10K
100K
1M
10M
100M
4/29/2006 Murthy SiSCSI 30
Impact of File size on performance
0.100
1.000
10.000
100.000
1000.000
1K 10K 100K 1M 10M 100M
File Size
Tim
e in
Sec
on
ds
W/O Ipsec Ipsec + Encrypt/Decrypt Proposed
4/29/2006 Murthy SiSCSI 31
Lessons 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 doesn’t work !
4/29/2006 Murthy SiSCSI 32
Future 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.
4/29/2006 Murthy SiSCSI 33
Conclusions
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.
4/29/2006 Murthy SiSCSI 34
Benefits 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.