CSE 545 Issues in Storage Securitypdm12/cse545/slides/cse545-storagesec-1.pdf · 2008. 5. 6. ·...

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


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


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


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


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


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


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


• Survey of 500 system managers from Spring 2001

Frequency & cost of attacks

9


Yearly trends (CSI survey)

10


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


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


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


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


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


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


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


NASD in Action

• Consider file read as an example

• Step 1: client requests access to file from NASD file manager

18


NASD in Action

• Step 2: File manager installs a private credential (a capability) to the NASD drive for access to the requested file

19


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


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


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


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


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


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


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


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


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


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


OSD: Security Methods

30


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


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


iSCSI

33


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


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


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


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


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


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


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


Plutus: Architecture

41


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


Merkle Hash Tree

• Highly efficient signing construction

Fileblock1 Fileblock2) Fileblock3) Fileblock4)

H(L1,R2) H(L3,R4)

H(L12,R34)

43


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


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


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


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


Next Day

• Real-world performance issues

• Encryption on disk

• Providing integrity

47

CSE 545 Issues in Storage Securitypdm12/cse545/slides/cse545-storagesec-1.pdf · 2008. 5. 6. ·...

Documents

Transcript of CSE 545 Issues in Storage Securitypdm12/cse545/slides/cse545-storagesec-1.pdf · 2008. 5. 6. ·...