SNARE

Security in Storage Systems

December 2004

SNARE Slide 2

References

1) SNARE: A Strong Security Scheme for Network-Attached Storage. Y. Zhu and Y. Hu, IEEE Symposium on Reliable Distributed Systems (SRDS), October 2003.

2) Separating key management from file system security.D. Mazi`eres, M. Kaminsky, M. F. Kaashoek, and E. Witchel. ACM Symposium on Operating Systems Principles (SOSP), December 1999.

3) Network Security and Storage Security: Symmetries and Symmetry-Breaking.D. Beaver, IEEE Security in Storage Workshop, 2002.

SNARE Slide 3

Agenda

Security in brief.

Storage Security.

SNARE – Overview.

SNARE – Protocols.

Performance issues.

Threat analysis.

Conclusion.

SNARE Slide 4

Security Essentials

The weakest link in the chain defines the strength of the security .

Always assume a “smart” adversary. Strong cryptography is not necessarily

strong security. Security scheme is based on a threat

analysis. Cost effectiveness.

SNARE Slide 5

Security Essentials (cont.) Security essentials:

• Confidentiality.

• Integrity.

• Availability.

Additionally:• Anonymity / Privacy.

• Survivability.

• Robustness / Reliability.

• Completeness.

• Authenticity.

SNARE Slide 6

Typical Threats

Eavesdropping. Man in the middle attacks:

• Tampering.

• Replay.

DoS – Denial of Service. Internal / external adversary.

SNARE Slide 7

Storage Security – The Players

“Sender” – writes or distributes the data. “Receiver” – reads the data. “Storage” – stores the data. Authentication server (optional).

SNARE Slide 8

Network security vs. Storage Security

Network StorageCommunication Nodes are separated by

space.Nodes are separated by time (+ space).

Key management

Certain cryptographic algorithms require interaction.

Interaction is usually not possible.

Encryption algorithms

~ Similar.

Error correcting codes

~ Similar.

SNARE Slide 9

Storage Security Basics

Security at 2 layers:• Storage layer.

• Communication layer.

Access Control - The desires of the owner should be reflected even when the owner is no longer present.

Storage may be considered as a Link or as an endpoint.

SNARE Slide 10

Access Control

The “sender” might be unavailable when the message is delivered.

A proxy may represent the sender:• Cryptographic mechanisms.

• Access control.

SNARE Slide 11

Link vs. Endpoint

Re-encryption:• Data may be decrypted by the storage node, and

then re-encrypted:

• Pros

• Cons

Examples: AFS, Microsoft EFS, Freenet.

• Improves security from / to storage.

• Prevents cryptographic decay.

• Subject to man in the middle attacks.

SNARE Slide 12

Link vs. Endpoint (cont.) Disk Encryption:

• An alternative approach to re-encryption is to send the encrypted file directly across the network (end-to-end).

• Data stored on disk is encrypted.

• Sometimes encryption is up to the endpoint (PAST, Freenet).

• Pros:

• Cons:

CryptFS, Secure FileSystem, Microsoft Encrypting File System, SNAD.

• Performance.

• Eavesdropper can tell whether file has changed.

• Replay (?).

SNARE Slide 13

NAS - introduction

NAS – Network Attached Storage. The storage appliance is connected

directly to a TCP/IP network. Limited processing capabilities.

SNARE Slide 14

SNARE – Goals Strong security for NAS. Limited processing resources at the storage. Security properties:

• Confidentiality.

• Integrity.

• Authentication.

• Access control.

• Copy resistance.

• File sharing.

• End-to-end encryption – NAS cannot read data, does not manage keys.

SNARE Slide 15

SNARE – Scope

Provides infrastructure for enforcing security.

Used by file system. Does not provide access control policy.

SNARE Slide 16

SNARE – Assumptions

The server is trusted. NAS – less trusted. Server and clients have reasonable

processing capabilities.

SNARE Slide 17

SNARE – The Players Client.

• = Computer.• Runs a client daemon.• May run several users.

User (+user agent).• Has to be authenticated by server.• Produces file the encryption key.

Authorization server.• Authorizes users.• Manages and distributes keys.

NAS.• Stores the data.

SNARE Slide 18

SNARE – Infrastructure

SNARE Slide 19

Keys Private + public key.

• Per user.

• Private – known only to user. Public – known to all.

• Used for authentication.

Kd – disk key.

• Per NAS.

• Known to authorization server and NAS.

• Used for authenticating user ID and permissions. File-data key.

• Per file.

• Known only to user.

• Used for end-to-end encryption of the files.

SNARE Slide 20

Keys (cont.) File-Lockbox key.

• Per permission profile.

• Known to the server and to users with permissions.

• Used for encrypting the file-data key.

Capability:• KeyData.

• Per user.

• Generated by server - sent to user on first access.

• A record representing the access control policy.

• hku = MACKd(KeyData)

• Per user.

• Generated by server - sent with KeyData.

• Used for authenticating KeyData.

Note: the capability and the file-lockbox key are sent at the authentication protocol.

SNARE Slide 21

Write Process

NAS

Server

Client

AuthReq

Klockbox

Kfile-data

capability

SNARE Slide 22

Read Process

NAS

Server

Client

AuthReq

Klockbox

Kfile-data Request

capability

SNARE Slide 23

Revocation Keys have a lifetime (specifically KeyData). AV – Access control Version number:

• Per file.

• Signed by the server. Blacklist at the NAS. Changing Kd:

• Keys of clients who have already been authenticated are revoked.

SNARE Slide 24

File Object Each file is represented by a File Object. Contains all relevant information about a file. Created by NAS.

SNARE Slide 25

File Object

SNARE Slide 26

File Object (cont.) HMAC – fhash(file object information, Kd).

objectID – unique identifier. AV – Access control Version. lockbox – file-data key encrypted by file-lockbox key. Other fields: length, create time, modify time.

For each block:• checksum (SHA-1).

• pointer – encrypted with key=fhash(object ID, Kd).

SNARE Slide 27

SNARE - Security Properties Revisited Authentication:

• Secure channel.

• User sends request.

• Server sends capability + lockbox key.

Confidentiality:• File is encrypted at the client by a file-data key and is stored

encrypted.

Integrity:• Checksums + HMAC hash.

Copy resistance (?).• Block pointers are encrypted.

SNARE Slide 28

SNARE – Protocols

Authentication.

• Pros & cons.

Key Distribution.

• Pros & cons.

Communication with NAS.

• Pros & cons.

Basic Operations.

SNARE Slide 29

Secure Authentication Both authentication and key distribution are exchanged

via a secure channel. Guarantees future communication in the session. “SFS” – Secure File System (reference 2).

SNARE Slide 30

Authentication

SNARE Slide 31

Authentication (cont.) User requests authentication. Client replies user with SessionID+SeqNo. User signs SessionID+SeqNo with private key, and sends to client. Clients relays to server, adding a SeqNo. Server relays to AuthAgent. AuthAgent verifies signature, finds UserID and sends back to

server. Server relays to client.

SNARE Slide 32

Authentication – Pros & Cons Pros:

Cons:

• Secure authentication – protects against eavesdropping.

• NAS is not a player in authentication.

• Server – security single point of failure.

SNARE Slide 33

Key Distribution

AuthReq

AuthReply

Directly follows the authentication.

Client Server

SNARE Slide 34

Key Distribution (cont.) Client sends request – AuthReq. Server verifies request, and sends Capability:

• Permissions.

• Expiration time.

• Signature.

SNARE Slide 35

Key Distribution – Pros & Cons Pros:

Cons:

• Secure channel.

• Revocation / expiration.

• Protocol completely trusts SFS.

SNARE Slide 36

Communication with NAS Any operation on the NAS is a two way handshake.

Two basic operations:• Block read.

• Block write.

Cannot be performed before authentication and key distribution are complete.

Request

ResponseClient NAS

SNARE Slide 37

Request Contains data and arguments. Contains KeyData. Signed by hku.

SNARE Slide 38

Response Contains data and arguments. Contains a synchronization timer. Signed by hku.

SNARE Slide 39

Basic Operations – Block Write

SNARE Slide 40

Basic Operations – Block Read

SNARE Slide 41

Communication with NAS – Pros & Cons Pros:

Cons:

• NAS has no access to file.

• All data sent / received is signed.

• Data itself is not signed on read requests: less calculations.

• NAS spoofing: Replay of read response?

• Out of order blocks?

SNARE Slide 42

Performance Issues Implementation of the cryptographic protocols. Performance has not been analyzed for multiple

clients.

The client performs more calculations than the NAS:• SHA-1 checksums over data blocks.

• Data decryption.

Thus the bottleneck is shifted to the client.

SNARE Slide 43

Overhead Measurements Apples to apples? So what’s new? PK vs. HMAC - RSA does not justify overhead?

SNARE Slide 44

Performance Multiple clients? FS / OS overhead? Communication overhead? Delays? Sequential / random access?

SNARE Slide 45

Threat Analysis - Authentication

Threat SecurityProperty

Mechanisms

Client impersonation Integrity Secure channel using SFS - Mutual authentication.

Key interception Confidentiality Authentication and key distribution are encrypted (SFS).

User impersonation Integrity, Confidentiality

Authentication request is PK signed.The public key is matched to UserID.

KeyData tampering Integrity KeyData is signed (hku).

“Cryptographic decay”

Confidentiality ExpTime – expiration time on key.

SNARE Slide 46

Threat Analysis – Communication with NAS

Threat SecurityProperty

Mechanisms

Tamper with Requests / Responses Integrity All requests / responses are signed using hku.

Replay of requests Integrity Using time stamps on all requests.

Replay of responses Integrity Not prevented.Since the client uses Fs from the NAS to update its timer.

Tamper with data blocks by man in the middle Integrity All data blocks have a checksum + there is an HMAC over the checksum.

Tamper with data blocks by NAS Integrity Checksum is on plaintext – performed by client.

Out of order block reading Integrity Not prevented.A method of packet counter (+IV) is suggested.

Man in the middle eavesdropping Confidentiality All data blocks are end-to-end encrypted at the client (key known only to client).

User impersonation at the client Confidentiality / integrity

SessionID is a unique hash – difficult to guess.? – User / client share the same machine / memory.

Copy file from one NAS to another Integrity / availability

Block pointers are encrypted by Kd.Cracking the pointers without data key – difficult to guess.? – Kd might also be available to adversary.

SNARE Slide 47

Threat Analysis – Communication with NAS (cont.)Threat Security

PropertyMechanisms

User falsifies permissions

Integrity KeyData is signed by hku.

NAS impersonation Integrity NAS uses Kd to sign responses (using hku).Replaying NAS Responses is possible.

SNARE Slide 48

Vague issues User / Client relationship. Client-user authentication: client can deceive users. Copy resistance – if adversary has access to NAS, he might have Kd… SeqNo in authentication protocol:

• + Not for security purposes – just for matching UserID with the right user.

• - The server checks that the sequence number has not been used before. Permissions: it is not clear how the server knows a user’s permissions.

Thus it is not clear if the lockbox keys are per user, per group… The paper does not confront networks with multiple NAS’s:

• In the authentication protocol the server uses a specific Kd – how is it chosen? Response / request and Read / Write messages – not consistent. Secure channel assures all authentications are fresh (?).

SNARE Slide 49

Conclusion SNARE: strong storage system security-wise. A few minor vulnerabilities. A bit vague

• Interface with file system.

• Performance.

• Scalability.

Appendix

SNARE Slide 51

Secure Channel Using SFS Both authentication and key distribution are exchanged

via a secure channel. “SFS” – Secure File System (reference 2).

SNARE Slide 52

Secure Channel Using SFS (cont.) The client and server create a per-session pair of keys. One for each direction. These session keys are used to encrypt and guarantee the

integrity of the communication in the channel. Kcs=SHA-1(“KCS”, KS, kS1, KC, kC1).

Ksc=SHA-1(“KCS”, KS, kS2, KC, kC2).

SNARE Slide 53

Authentication - Details SessionID – created by client.

• A unique identifier for the session.

• SessionID = SHA-1{“SessionInfo”,Kcs,Ksc}

• Kcs,Ksc are per-session keys.

SeqNo – created by client.• A sequence number for the authentication requests.

• Since a session might contain a few requests. AuthMsg – created by user.

• Signed authentication message.

• AuthMsg=KU, {SignedAuthReq}KU-1 .

• SignedAuthReq={“SignedAuthReq”,SessionID,SeqNo}. UserID – know to server.

• Distributed to client.

SNARE Slide 54

Key Distribution – Details AuthReq= {“UserAuthReq”, UserID, ObjectID,

SessionID, SeqNo}. Capability:

• KeyData = {“KeyData”, UserID, ObjectID, Perms, nonce, ExpTime, AV}

• hku = MACKd(KeyData).

AuthReply = {“UserAuthReply”,KeyData, hku , SeqNo, klockbox}.

SNARE Slide 55

Request – Details A client request to the NAS has the form: M = {RequestArgs, RequestData, SeqNo, Fs,

KeyData, MAChku(M)}.

• RequestArgs – operation type, etc.

• RequestData – payload for writing (in write operations).

• SeqNo – uniquely identifies the request.

• Fs – timestamp.

SNARE Slide 56

Response – Details A NAS response to a client request is of the form: M = {RequestArgs, RequestData, SeqNo, Fs,

MAChku(M)}.

• RequestArgs – operation status, etc.

• RequestData – requested block (in read operations).

• SeqNo – uniquely identifies the request.

• Fs – the NAS timer, used for time synchronization.

SNARE Slide 57

RC5 SNARE uses the RC5 algorithm for data encryption. Designed by Ronald Rivest, 1994. Block cipher (data dependent). Simple to implement. Block size: 32 / 64 / 128 bits. Key size: 0-2040 bits. Encryption mechanism:

• Integer addition.

• Bitwise XOR.

• Variable rotation.

SNARE Slide 58

HMAC Hashed Message Authentication Codes. A message authentication function. Designed for IPSEC. RFC 2104. Defines the protocol for calculating a hash from a

message. Does not define the hash function (SHA-1, MD5…).

SNARE Slide 59

SHA-1 Secured Hash Algorithm. First created as a FIPS (Federal Information

Processing Standard). Became RFC 3174. A hash of the data is called a “message digest”. Message digest size: 160 bits.