SNARE

1. SNARE December 2004 Security in Storage Systems

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

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

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.

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

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

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

8. Network security vs. Storage Security

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.

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

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.

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

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

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.

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

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

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.

18. SNARE – Infrastructure

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.

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.

21. capability Klockbox Kfile-data Write Process Server AuthReq Client NAS

22. capability Klockbox Kfile-data Read Process Server AuthReq Request Client NAS

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.

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

25. File Object

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).

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.

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

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).

30. Authentication

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.

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

33. Key Distribution • Directly follows the authentication. AuthReq AuthReply Client Server

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

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

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 Response Client NAS

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

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

39. Basic Operations – Block Write

40. Basic Operations – Block Read

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?

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.

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

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

45. Threat Analysis - Authentication

46. Threat Analysis – Communication with NAS

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

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

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

50. Appendix