Security for Network-Attached Storage

1. Security for Network-Attached Storage Vishal Kher 14 March 2003

2. Malicious Clients How Things Were.. • Fileserver protects critical information resources • Requests go through the fileserver • Every request is inspected • Malicious requests never read the disk Authentication Server Client Network File Server Clients Disks

3. NASDArray Malicious Clients NASD Client Network NASDFile Manager Clients How NASD Changed Things... • Performance bottleneck at the file server • File manager is not on the datapath Authentication Server

4. Security Issues • Authorization • How to authenticate the users • How to control access on the device • How to secure data on link and on the device • End to end encryption • Revocation

5. Outline • Motivation • Authorization Schemes • Network-Attached Secure Disks (NASD) • Secure Authentication for Remotely Encrypted Devices (SCARED) • Data Encryption Scheme • Secure Network-Attached Disks (SNAD) • Conclusion

6. Key, Request Client Network Response Key Request Clients General Picture • Key Types • Capability keys • Client receives KC = H(capArgs, K) • Identity Keys • Client receives Ki =H(Client ID, K) Authentication Server D e v i c e File Manager

7. Security in NASD • Developed at PDL, CMU • File manager makes the policy decisions • Passes access rights to the drive through cryptographic capabilities • Device doesn’t need to know the identity of the client • User proves his identity and access rights using capability key and capability arguments • These are passed by the File manager to the client • Scheme for revocation

8. Private Communication Request For Access CapKey = MACK(CapArgs, AV) CapArgs= ObjID, Version, Rights, Expiry,.. Reply, NonceIN, MACcapkey(Reply, NonceIN) M=CapArgs, Req, NonceIN, MACcapkey(M, NonceIN) Protocol Details FM Client Secret Key K (working key) Access Control Version (AV) Stored on the device and FM, Used for revocation Device Secret Key K (working key)

9. NASD Conclusion • Capability is acquired per open request • Still overhead on the file manager • File manager needs to be online • File manager (FM) is a central point of failure • Potential for DoS • Object migration, replication or striping • Multiple capabilities are required • Very fast revocation • URL : http://www.pdl.cmu.edu/NASD/

10. SCARED • Extension of NASD • Developed at IBM Almaden • Allows clients to share keys • Bob receives K1 = H(data1, K) • Bob gives Alice K2 = H(data1 + data2, K1) • K is the key shared between the storage and FM • Public part (data1) depends on the type of the key used • FM does not need to be online

11. Protocol Details • Setting • Client has two keys Ka, Kr, and correspondingDa, Dr • Ka is the access key and Kr is the response key • Step 1: Freshness Guarantee • C S: M = {Frequest, Fc, Dr}, MACKr(M) • S C: M = {Fresponse, Fc, Fs}, MACKr(M) • Fs is the initial session counter • Counter based or Timer based

12. Protocol Details • Request C S: • M = {Oper, data, Da, Dr, Fc, Fs}, MACKa+Kr(M) • Response S C: • M = {Response, Fc, Fs}, MACKr(M) • Capability Keys • FM has ACL • Device verifies that the client has the ability to perform a transaction • Identity Keys • ACL with object on the Device • Device has to verify the identity

13. SCARED VS NASD

14. SNAD Design Goals • Encrypt data on the disk • Drives lack information to decrypt data • End to end encryption • Restrict access to authorized users • Super user should not be able to access the data • Reduces load on the disk CPU • Data integrity • Avoid other attacks • Replay attack based on time stamp (time drifting?)

15. SNAD Data Structures Certificate object Key object Key object File object File object File object Secure block Secure block Secure block Secure block Secure block Secure block

16. SNAD Data Structures • Secure Blocks • Basic unit of data read or written • Block ID - Unique id for the block • User ID - Creator of the secure block • Timestamp - Used to prevent reply attack • Data encrypted using the RC5 key • Key stored in Key object Block Security Information Block_ID USER_ID Timestamp Encrypted Data

17. SNAD Data Structures • File Objects • Contains normal metadata • Example: Block pointers, file size • In addition contains a pointer to key object • One or more secure blocks • No encryption… Do we need to? • At least whole directory structure will be known to insider • A directory and/or file name itself can mean something • MS bookmark information

18. SNAD Data Structures • Key Object • Reference count to know when to delete the key object • Signature – • User hashes the entire object and signs with his private key • Rows store information per user or group • Created by the user upon creation of a file or a file group • K is RC5 key encrypted with users public key

19. SNAD Data Structures • Certificate Object • One per disk • Public Key Stored for • Convenience • Scheme 1 • HMAC key • Used in Scheme 2 and Scheme 3 • Stored encrypted with decryption key held in non-volatile memory on disk! • HMAC keys decrypted during disk startup • Timestamp is updated for each write

20. Compare Y SNAD Scheme1 Client Write Disk CPU/ Client read EK(M) EK(M) EK(M) H V H N Reject S

21. SNAD Scheme1 • Expensive operations on client and disk side • Vulnerable to DOS attacks

22. HMACK’ EK(M) H H Disk CPU: Compare H HMACK’ SNAD Scheme 2 Client Disk CPU EK(M) EK(M) H S Write

23. Compare Y SNAD Scheme 2 Disk CPU Client EK(M) EK(M) H V N Reject Read

24. SNAD Scheme 2 • Expensive operations on client specially on a write • Vulnerable to DOS attacks

25. SNAD Scheme 3 Client Disk CPU HMACK’ EK(M) EK(M) EK(M) H Compare H HMACK’ Write

26. SNAD Scheme 3 Disk CPU Client HMACK’ EK(M) EK(M) EK(M) H Compare H HMACK’ Read

27. Conclusion • Authorization • NASD • SCARED • Improvements • Revocation • Reduce number of keys • Reduce frequency of access to the FM • Support compound objects and object mobility • Encryption • SNAD • Improvements? • Revocation • Group key management