Page
CSE 545Issues in Storage Security
8 April 2008Kevin Butler
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
Outline
• General storage security concepts
‣ Defined threat models
‣ Attacks against storage
• Surveying storage security proposals
‣ NASD & OSD
‣ Security in iSCSI
‣ Storage security research proposals
2
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
Storage Security
• Consider: What is storage security? How to define?
• What is security? What aspects to we want to see?
‣ Integrity
‣ Confidentiality
‣ Authentication
‣ Non-repudiability
‣ Availability(?)
3
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
Methods of Providing Security
• Encrypt everything with 256 bit keys (or 1024-bit, why not?) and we’ve finished the job, right?
• Security is only as good as the weakest element that can be attacked
‣ it’s hardly ever the crypto that’s the problem
‣ Implementation and correct use of cryptographic primitives is essential
‣ Rolling your own crypto is virtually never a good idea
4
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
Storage Security Concerns• To this point, focus is on protecting data integrity
‣ Preventing unauthorized modification of data, modifying requests, replay
‣ MAC, digital signature
• Some level of focus on confidentiality‣ Preventing reading and modifying information in transit
‣ Private and public key encryption
• Availability and performance‣ Denial and degradation of service are useful attacks
• Convenience‣ The eternal tradeoff with security; inconvenient schemes can
adversely affect security5
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
Threat Model: Players• HP Labs FAST ‘02 paper: good terminology for many of the
following concepts• Owners
‣ Create, destroy data, delegate permissions to others, revoke privileges
• Readers, Writers‣ Read or write data, respectively, when owners grant them permission
• Wire‣ Transmits data across a medium between players
• Storage Servers‣ Store, return data when requested
• Group Servers‣ Authenticate and provide access based on membership groups
• Namespace Servers‣ Allow namespace traversal to support directory lookup
• Any action by a player other that what is listed is treated as an attack6
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
Threat Model: Attacks• Data lifetimes: short-term (session data) or long-term
and metadata (persistent data)
• Network security focuses on session-data (what is communicated between peers)
• Key of storage security: focus on securing persistent data as well as protecting session data
• Consequences of attacks can be quite harmful‣ Leaks: access gained to confidential data
‣ Changes: adversary makes valid modifications to data that are not flagged by the system
‣ Destruction: adversary makes invalid modifications, potentially deleting data outright
7
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
Threat Model: Types of Attacks• Adversary attacks the wire
‣ Attacking the protocol itself, or potentially underlying transport protocols
• Adversary attacks the servers‣ Attempting to modify or update data on a file server, for example
• Revoked user attacks the servers‣ A user whose access has been revoked attempts to continue to read or write
files
• Adversary colludes with the storage server‣ Using the OS, for example, to attack the storage system
• Adversary colludes with the group server‣ Gaining access to data after subverting membership group information
• Adversary colludes with readers or writers‣ Reader or writer directly passing files to adversary (difficult to solve)
• Malicious server‣ Server destroys data, rollback attack (untrusted server tricks client into
accepting stale or version-inconsistent data)
8
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
• Survey of 500 system managers from Spring 2001
Frequency & cost of attacks
9
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
Yearly trends (CSI survey)
10
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
Security Primitives
• Consider in greater detail the potential security primitives used by the various countermeasures
• Authentication
‣ Distributed: owners authenticate each player who are authorized for access to their data
‣ Centralized: owners delegate authentication and authorization responsibilities to group server
‣ Mutual authentication needs establishment
• PKI, centralized scheme (e.g., Kerberos), password-based (shared secret): why is this last one bad in distributed systems?
‣ Other way: authenticating servers to users11
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
Security Primitives (ctd.)• Authorization
‣ Note: different from authentication!
‣ Allows user access to data (and ability to delegate access), whereas authentication establishes identity
‣ Is authentication without authorization possible? What about vice-versa?
‣ Server-mediated authorization
• Servers receive and perform all actions from the requisite players (readers, writers, owners)
‣ Owner-handled authorization
• Readers and writers receive keys from owners that can be used for authorization or performing actions
12
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
Security Primitives (ctd.)
• Securing data on the wire
‣ Secure the protocol and underlying transport
‣ SSL/TLS for transport layer, IPsec for network layer
‣ Integrity through keyed MACs, timestamps and nonces for preventing replay
• Securing data on disk
‣ Protection for stolen disks, for example
‣ Symmetric, asymmetric ciphers available (DES, AES symmetric, RSA asymmetric)
‣ Asymmetric ciphers are quite slow: used for initial exchange of symmetric session keys or for storing keys
13
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
Security Primitives (ctd.)• Key distribution
‣ Keys used to do actual data encryption or to prove authorization to the system
‣ Distribution via group server• Centralized group server has list of all keys and ACLs
‣ Owner-handled distribution• File owners supply keys for reading or writing
• Revocation‣ Removes binding between identity and key, and in storage, revokes
access to data
‣ Aggressive re-encryption: immediately rewrite data after revocation
‣ Lazy re-encryption: delay until next time data updated• Does this really protect data?
‣ Periodic encryption: change keys periodically and rewrite data14
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
Other Security Considerations• Granularity
‣ Aggregate users (players) into groups to limit key overhead, use longer-lived keys for similar optimization (but trade off some security either way)
• Convenience
‣ Highly convenient (single sign-on) can be vulnerable, but highly inconvenient can also be vulnerable
‣ Potential solution: smart cards, biometrics and other identity-based encryption
• Difficulties with revocation
• Users don’t like having their eyes removed
15
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
Outline
• General storage security concepts
‣ Defined threat models
‣ Attacks against storage
• Surveying storage security proposals
‣ NASD & OSD
‣ Security in iSCSI
‣ Storage security research proposals
16
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
NASD
• Network attached secure disks
• Major performance improvement: for most read/write operations, clients directly communicate with storage devices and bypass the server (no “store-and-forward”)‣ Server’s role is less management of requests and more policy
definition, cache consistency, namespace management
• Exports variable-sized objects rather than fixed-size blocks‣ Objects contain attribute set, metadata exported from the
drive, and a sequence of bytes
‣ Can correspond to an entire file, or a file fragment (e.g., data stripe unit, database table)
17
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
NASD in Action
• Consider file read as an example
• Step 1: client requests access to file from NASD file manager
18
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
NASD in Action
• Step 2: File manager installs a private credential (a capability) to the NASD drive for access to the requested file
19
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
NASD in Action
• Step 3: file manager sends description of access rights (capability) to the client (public credential) over a public channel, as well as a MAC (HMAC-SHA1) of the capability (private credential) over secure private channel
20
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
NASD in Action
• Step 4: client requests file from the NASD storage: sends security header, public credential (capability), read request, nonce, and MAC of request and nonce keyed with the private credential
21
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
NASD in Action• Step 5: NASD device generates MAC and checks if it
matches what was received; sends back data, status, nonce, MAC of the three fields keyed with private credential
• Note: steps 4 and 5 can be repeated ad infinitum without involvement of the file manager
22
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
NASD: Credentials• Private credential: binds NASD request to public
credential through MAC‣ Relies on a basis key sent from the file manager to the drive: a
shared secret between the two entities used to derive the private credential
• Public credential: communicates rights granted to client‣ Client forwards credential to drive on every request - slight
increase of overhead, but no need for device to maintain record of access rights
‣ Credential contains object (by unique ID), drive’s unique identifier, partition ID, version number of object => object specification
‣ Version number serves as revocation mechanism
‣ Access rights included as well (e.g., ReadData, Create)23
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
NASD: Key Hierarchy• Difficult to rely on one key for delegating responsibility, also
balancing key usage vs lifetime• NASD has 5-layer key hierarchy
‣ Credential keys on bottom, used for client operations‣ Administrative keys form upper layers, used for key generation and
management
• Master key: held by owner of storage device‣ Enables unrestricted access to drive, immutable
• Drive keys: used for administering drive‣ Unrestricted drive access, but unlike master, can be changed
(compromise, failure, periodic changing)
• Partition keys: manage drive partition• Working keys: generate access credentials, perform operations
‣ Black and gold keys: having multiples allows non-synchronous invalidation
24
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
NASD: Key Caching• Caching access keys can reduce the latency of
processing requests
• Reuse the generated private access credential
• Cache invalidation necessary if a value relied upon by the credential changes‣ Basis key, access control version number changes
‣ If basis key changes, cache exhaustively searched for invalidations
‣ Index cache by object ID for public credential for efficient revocation due to versioning changes
• NASD device keeps a cache of credentials, potentially as a hash table
• For AFS workload, 16 KB cache yielded 40-50% hit rate25
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
NASD: Vulnerabilities
• Data is not encrypted on the storage devices themselves
‣ Vulnerable to attacks where adversary colludes with storage system
• All authentication and authorization data available through file manager
‣ Vulnerable to attacks where adversary colludes with file manager
• Pro or con? Individual drives directly participate in security protocols: first approach like this
• Successor: OSD26
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
OSD
• Object-based storage device
‣ Successor to NASD
• Not much different security-wise; essentially the same model
‣ Except for the ability to turn off security if you want
• Biggest difference: more fully realized than NASD
• OBSD: object-based storage device: SCSI device that implements OSD standard where data is organized and accessed as objects
27
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
OSD: Trust Assumptions
• No authentication of client performed by OBSD, but may be performed by Security manager
• OBSD is assumed to be trusted
‣ Integrity of stored data
‣ Perform the security protocol and functions
• Security Manager is assumed to be trusted
‣ Safely store long-lived keys
‣ Apply access-control policies with help of policy/storage manager.
• Application clients untrusted
28
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
OSD: Security Methods
• NOSEC: no security features or algorithms used
• CAPKEY: validates integrity of capability information in command descriptor block (used to communicate commands between application client and server)
• CMDRSP: validates integrity of CDB, status, sense data
• ALLDATA: validates integrity of all data in transit
• Note: no mention of on-disk encryption
29
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
OSD: Security Methods
30
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
OSD: Security Architecture
ApplicationClients
SecurityManager
Policy/Storage Manager
OBSD
Request credential Request capability
Return capabilityReturn credentialincluding capability
key
Shared
Sec
ret
SET_KEY andSET_MASTER_KEY
31
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
iSCSI
• Internet Small Computer Systems Interconnect
• Block-oriented protocol for connecting SCSI devices over TCP
• SCSI commands and data can be included in iSCSI PDU
• Multiple sessions possible, each delivers SCSI commands in order and can recover from lost connections
32
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
iSCSI
33
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
Side note: The battle for
• From the iSCSI RFC:
‣ “Although technically possible, iSCSI SHOULD NOT be configured without security.”
• Lesson from standards bodies: they often make it possible for one to implement the bare minimum
• In defence of the RFC writers: security must be implemented but it’s up to the user whetherto configure it
• IPSec is only optional - deployment in the wild?
34
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
iSCSI Integrity
• Header and Data digest protect integrity of the iSCSI message
• Are the necessary above what TCP provides?
• What it provides: CRC32C check
• Value seems somewhat dubious
• In defence of digests:
‣ 32-bit rather than 16-bit in TCP = less error-prone
‣ Located after payload = calculations on the fly without memory reference
‣ Claim: commodity GigE NICs do not perform CRC; but can be easily accomplished with transport offload engine
35
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
iSCSI Authentication
• Provided by in-band authentication when iSCSI Login PDUs exchanged, and by IPsec (more next slide)
• In-band authentication (ostensibly) provides end to end trust at login, while IPsec provides secure channel
• Of course security is not mandatory…
• Supported types of authentication:
‣ Kerberos v5, Simple Public Key GSS-API (SPKM1, SPKM2), Secure Remote Password (SRP), CHAP, none
36
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
iSCSI and IPsec
• IPsec can be used as the underlying security mechanism for iSCSI
• Provides integrity, confidentiality, authentication‣ Also replay and DoS protection
• Quick refresher on IPsec protocol suite:‣ AH (Authentication Header) provides authentication‣ ESP (Encapsulating Security Payload) provides encryption and
authentication
‣ IKE (Internet Key Exchange), built on ISAKMP framework, provides key management
‣ SPS (Security Policy System) provides policy configuration
• Slightly unwieldy, and somewhat complicated to implement, but very good to have around
37
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
iSCSI: Summary
• Unlike NASD, no notion of individual users; all players are on the same level
• Authentication, authorization left to host
• No concept of group or namespace servers
• Access-control based compared to NASD’s capabilities
• Block-based vs object based
• Storage servers and hosts are mutually authenticated but data is not protected from server
‣ Vulnerable to adversary colluding with server38
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
Plutus
• Cryptographic storage system enabling secure file sharing without trusting server
• Encrypt-on-disk solution vs. the encrypt-on-wire solutions seen to this point
• Key management and distribution handled in a decentralized manner by the client
• Mechanisms provided:
‣ Detect and prevent unauthorized data modifications
‣ Differentiate between read and write file access
‣ Change user access privileges
• HP Labs, FAST ‘0339
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
Plutus: Encrypt-on-disk• What are the advantages of encrypt-on-disk?
‣ Protects against data leakage e.g., stolen laptop, compromised server
‣ Users can set arbitrary policies for key distribution and file sharing
‣ Potentially better scalability as the cryptography is performed by the end hosts• Clients take on a higher overhead
• Assume that servers will store data but not keep it confidential‣ Server may attempt to change, misrepresent, destroy data
‣ Multiple servers might be required if assumption is that a server might destroy data
• Users trust their local machine40
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
Plutus: Architecture
41
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
Plutus: Architecture• Grouping is done by file (not by user)
‣ Files grouped into filegroups, keys shared among files in the filegroup
‣ All files with identical sharing attributes are grouped into the same filegroup
• Files divided into blocks, each block is encrypted with a file-block key (unique symmetric key)
• Lockbox holds file-block keys, access to read and write through file-lockbox keys
• Integrity ensured by signing and verifying a hash of the file contents: public-private key pairs are same for all files in a filegroups
• Optimize signing by using a Merkle hash tree42
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
Merkle Hash Tree
• Highly efficient signing construction
Fileblock1 Fileblock2) Fileblock3) Fileblock4)
H(L1,R2) H(L3,R4)
H(L12,R34)
43
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
Merkle Hash Tree
• Highly efficient signing construction
Fileblock1 Fileblock2) Fileblock3) Fileblock4)
H(L1,R2) H(L3,R4)
H(L12,R34)
43
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
Merkle Hash Tree
• Highly efficient signing construction
Fileblock1 Fileblock2) Fileblock3) Fileblock4)
H(L1,R2) H(L3,R4)
H(L12,R34)
43
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
Merkle Hash Tree
• Highly efficient signing construction
Fileblock1 Fileblock2) Fileblock3) Fileblock4)
H(L1,R2) H(L3,R4)
H(L12,R34)
43
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
Merkle Hash Tree
• Highly efficient signing construction
Fileblock1 Fileblock2) Fileblock3) Fileblock4)
H(L1,R2) H(L3,R4)
H(L12,R34)
43
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
Merkle Hash Tree
• Highly efficient signing construction
Fileblock1 Fileblock2) Fileblock3) Fileblock4)
H(L1,R2) H(L3,R4)
H(L12,R34)
• Proof: root and siblings on path to root• Fileblock1 : {H(L12,R34)}S(C), H(L3,R4), Fileblock2
43
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
Merkle Hash Tree
• Highly efficient signing construction
Fileblock1 Fileblock2) Fileblock3) Fileblock4)
H(L1,R2) H(L3,R4)
H(L12,R34)
• Proof: root and siblings on path to root• Fileblock1 : {H(L12,R34)}S(C), H(L3,R4), Fileblock2
43
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
Differentiating readers/writers• Server is untrusted so cannot enforce separate readers and
writers to same file
• Implement functionality through choice of keys distributed to readers and writers
• Only writers get private key (file-sign key), readers get public key (file-verify key)
• Writer updating block recomputes hash tree over current block hashes, signs hash, places signed hash in file header; readers verify signature
• File-verify key not publicly disseminated through system even though is serves purpose of public key: only authorized readers receive it
44
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
Plutus: Revocation• Expensive for encrypt-on-disk systems
‣ File re-encryption necessary
‣ In Plutus, recomputation of hashes and resigning roots
‣ Key distribution required
• Mitigate with lazy revocation
‣ Complicated when multiple files encrypted with same key (filegroups)
‣ One solution: updated file encrypted with a new key
• Problem: filegroup fragementation
‣ Better solution: key rotation
‣ File owner generates new version of file-lockbox key, created by exponentiating current key with owner’s private key
45
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
Plutus: Key Rotation
• Only owner can generate new file-lockbox keys
• Readers can recursively generate previous keys: previous version is current version exponentiated with the owner’s current public key
• Drawback: all previous public keys must be remembered
46
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
Next Day
• Real-world performance issues
• Encryption on disk
• Providing integrity
47