Presentation is loading. Please wait.

Presentation is loading. Please wait.

SNARE Security in Storage Systems December 2004. Slide 2 SNARE References 1) SNARE: A Strong Security Scheme for Network- Attached Storage. Y. Zhu and.

Similar presentations


Presentation on theme: "SNARE Security in Storage Systems December 2004. Slide 2 SNARE References 1) SNARE: A Strong Security Scheme for Network- Attached Storage. Y. Zhu and."— Presentation transcript:

1 SNARE Security in Storage Systems December 2004

2 Slide 2 SNARE References 1) SNARE: A Strong Security Scheme for Network- Attached Storage. Y. Zhu and Y. Hu, IEEE Symposium on Reliable Distributed Systems (SRDS), October ) 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 ) Network Security and Storage Security: Symmetries and Symmetry-Breaking. D. Beaver, IEEE Security in Storage Workshop, 2002.

3 Slide 3 SNARE Agenda Security in brief. Storage Security. SNARE – Overview. SNARE – Protocols. Performance issues. Threat analysis. Conclusion.

4 Slide 4 SNARE 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.

5 Slide 5 SNARE Security Essentials (cont.) Security essentials: Confidentiality. Integrity. Availability. Additionally: Anonymity / Privacy. Survivability. Robustness / Reliability. Completeness. Authenticity.

6 Slide 6 SNARE Typical Threats Eavesdropping. Man in the middle attacks: Tampering. Replay. DoS – Denial of Service. Internal / external adversary.

7 Slide 7 SNARE Storage Security – The Players “Sender” – writes or distributes the data. “Receiver” – reads the data. “Storage” – stores the data. Authentication server (optional).

8 Slide 8 SNARE Network security vs. Storage Security NetworkStorage CommunicationNodes 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.

9 Slide 9 SNARE 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.

10 Slide 10 SNARE Access Control The “sender” might be unavailable when the message is delivered. A proxy may represent the sender: Cryptographic mechanisms. Access control.

11 Slide 11 SNARE 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.

12 Slide 12 SNARE 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 (?).

13 Slide 13 SNARE NAS - introduction NAS – Network Attached Storage. The storage appliance is connected directly to a TCP/IP network. Limited processing capabilities.

14 Slide 14 SNARE 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.

15 Slide 15 SNARE SNARE – Scope Provides infrastructure for enforcing security. Used by file system. Does not provide access control policy.

16 Slide 16 SNARE SNARE – Assumptions The server is trusted. NAS – less trusted. Server and clients have reasonable processing capabilities.

17 Slide 17 SNARE 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.

18 Slide 18 SNARE SNARE – Infrastructure

19 Slide 19 SNARE Keys Private + public key. Per user. Private – known only to user. Public – known to all. Used for authentication. K d – 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.

20 Slide 20 SNARE 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. hk u = MAC Kd (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.

21 Slide 21 SNARE Write Process NAS Server Client AuthReq K lockbox K file-data capability

22 Slide 22 SNARE Read Process NAS Server Client AuthReq K lockbox K file-data Request capability

23 Slide 23 SNARE Revocation Keys have a lifetime (specifically KeyData). AV – Access control Version number: Per file. Signed by the server. Blacklist at the NAS. Changing K d : Keys of clients who have already been authenticated are revoked.

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

25 Slide 25 SNARE File Object

26 Slide 26 SNARE File Object (cont.) HMAC – f hash (file object information, K d ). 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=f hash (object ID, K d ).

27 Slide 27 SNARE 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.

28 Slide 28 SNARE SNARE – Protocols Authentication. Pros & cons. Key Distribution. Pros & cons. Communication with NAS. Pros & cons. Basic Operations.

29 Slide 29 SNARE 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).

30 Slide 30 SNARE Authentication

31 Slide 31 SNARE 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.

32 Slide 32 SNARE Authentication – Pros & Cons Pros: Cons: Secure authentication – protects against eavesdropping. NAS is not a player in authentication. Server – security single point of failure.

33 Slide 33 SNARE Key Distribution AuthReq AuthReply Directly follows the authentication. ClientServer

34 Slide 34 SNARE Key Distribution (cont.) Client sends request – AuthReq. Server verifies request, and sends Capability: Permissions. Expiration time. Signature.

35 Slide 35 SNARE Key Distribution – Pros & Cons Pros: Cons: Secure channel. Revocation / expiration. Protocol completely trusts SFS.

36 Slide 36 SNARE 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 Response ClientNAS

37 Slide 37 SNARE Request Contains data and arguments. Contains KeyData. Signed by hk u.

38 Slide 38 SNARE Response Contains data and arguments. Contains a synchronization timer. Signed by hk u.

39 Slide 39 SNARE Basic Operations – Block Write

40 Slide 40 SNARE Basic Operations – Block Read

41 Slide 41 SNARE 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?

42 Slide 42 SNARE 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.

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

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

45 Slide 45 SNARE Threat Analysis - Authentication Threat Security Property Mechanisms Client impersonationIntegrity Secure channel using SFS - Mutual authentication. Key interceptionConfidentiality Authentication and key distribution are encrypted (SFS). User impersonationIntegrity, Confidentiality Authentication request is PK signed. The public key is matched to UserID. KeyData tamperingIntegrity KeyData is signed (hk u ). “Cryptographic decay” Confidentiality ExpTime – expiration time on key.

46 Slide 46 SNARE Threat Analysis – Communication with NAS Threat Security Property Mechanisms Tamper with Requests / ResponsesIntegrity All requests / responses are signed using hk u. Replay of requestsIntegrity Using time stamps on all requests. Replay of responsesIntegrity Not prevented. Since the client uses Fs from the NAS to update its timer. Tamper with data blocks by man in the middleIntegrity All data blocks have a checksum + there is an HMAC over the checksum. Tamper with data blocks by NASIntegrity Checksum is on plaintext – performed by client. Out of order block readingIntegrity Not prevented. A method of packet counter (+IV) is suggested. Man in the middle eavesdroppingConfidentiality All data blocks are end-to-end encrypted at the client (key known only to client). User impersonation at the clientConfidentiality / integrity SessionID is a unique hash – difficult to guess. ? – User / client share the same machine / memory. Copy file from one NAS to anotherIntegrity / availability Block pointers are encrypted by Kd. Cracking the pointers without data key – difficult to guess. ? – K d might also be available to adversary.

47 Slide 47 SNARE Threat Analysis – Communication with NAS (cont.) Threat Security Property Mechanisms User falsifies permissions Integrity KeyData is signed by hk u. NAS impersonationIntegrity NAS uses Kd to sign responses (using hk u ). Replaying NAS Responses is possible.

48 Slide 48 SNARE Vague issues User / Client relationship. Client-user authentication: client can deceive users. Copy resistance – if adversary has access to NAS, he might have K d … 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 (?).

49 Slide 49 SNARE Conclusion SNARE: strong storage system security-wise. A few minor vulnerabilities. A bit vague Interface with file system. Performance. Scalability.

50 Appendix

51 Slide 51 SNARE Secure Channel Using SFS Both authentication and key distribution are exchanged via a secure channel. “SFS” – Secure File System (reference 2).

52 Slide 52 SNARE 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. K cs =SHA-1(“KCS”, K S, k S1, K C, k C1 ). K sc =SHA-1(“KCS”, K S, k S2, K C, k C2 ).

53 Slide 53 SNARE Authentication - Details SessionID – created by client. A unique identifier for the session. SessionID = SHA-1{“SessionInfo”,K cs,K sc } K cs,K sc 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=K U, {SignedAuthReq} K U -1. SignedAuthReq={“SignedAuthReq”,SessionID,SeqNo}. UserID – know to server. Distributed to client.

54 Slide 54 SNARE Key Distribution – Details AuthReq= {“UserAuthReq”, UserID, ObjectID, SessionID, SeqNo}. Capability: KeyData = {“KeyData”, UserID, ObjectID, Perms, nonce, ExpTime, AV} hk u = MAC Kd (KeyData). AuthReply = {“UserAuthReply”,KeyData, hk u, SeqNo, k lockbox }.

55 Slide 55 SNARE Request – Details A client request to the NAS has the form: M = {RequestArgs, RequestData, SeqNo, F s, KeyData, MAC hku (M)}. RequestArgs – operation type, etc. RequestData – payload for writing (in write operations). SeqNo – uniquely identifies the request. Fs – timestamp.

56 Slide 56 SNARE Response – Details A NAS response to a client request is of the form: M = {RequestArgs, RequestData, SeqNo, F s, MAC hku (M)}. RequestArgs – operation status, etc. RequestData – requested block (in read operations). SeqNo – uniquely identifies the request. Fs – the NAS timer, used for time synchronization.

57 Slide 57 SNARE RC5 SNARE uses the RC5 algorithm for data encryption. Designed by Ronald Rivest, Block cipher (data dependent). Simple to implement. Block size: 32 / 64 / 128 bits. Key size: bits. Encryption mechanism: Integer addition. Bitwise XOR. Variable rotation.

58 Slide 58 SNARE HMAC Hashed Message Authentication Codes. A message authentication function. Designed for IPSEC. RFC Defines the protocol for calculating a hash from a message. Does not define the hash function (SHA-1, MD5…).

59 Slide 59 SNARE SHA-1 Secured Hash Algorithm. First created as a FIPS (Federal Information Processing Standard). Became RFC A hash of the data is called a “message digest”. Message digest size: 160 bits.


Download ppt "SNARE Security in Storage Systems December 2004. Slide 2 SNARE References 1) SNARE: A Strong Security Scheme for Network- Attached Storage. Y. Zhu and."

Similar presentations


Ads by Google