Overview of Secure Network- Attached Disk (SNAD)

1. Overview of Secure Network- Attached Disk (SNAD) Vishal Kher 16 September 2002 Department of Computer Science University of Minnesota

2. Introduction • Title of the paper – “Strong Security for Network-Attached storage” • Authors • Miller, Long (UCSC), Freeman (TRW), Reed (IBM) • Abstract • Developed a scheme called Secure Network-Attached Disk (SNAD) to secure network-attached storage • Use of cryptographic methods to ensure data secrecy, client authentication, data integrity • 15-20% performance loss over raw data transfer • Presence of file system?

3. Outline • Introduction • Security Issues • SNAD Design Goals • Security Mechanisms • SNAD Data Structures • SNAD Security Schemes • Design Issues and Questions

4. Security Issues • Authentication • Specific to the security objective, which one is trying to achieve • Identification • Data origin authentication or message authentication • Access control • This itself is an issue • How to provide when there is no central authority • Peer groups are without hierarchy • ACL might not be good enough (static and controlled by one single authority) • Non-repudiation • Prevents an entity from denying previous commitments • Data Integrity

5. Security Issues • Data Secrecy • Keep data encrypted • Keep metadata encrypted (?) • Secure data transfer and backups • E2E vs. hop-by-hop encryption/decryption • Network attacks • DOS • Network DOS • Disrupting data • Virus, worms • Insider attacks • Should we trust the super user?

6. Security Issues • Dynamic nature • How to add and revoke? • Performance • Computational cost • Space complexity • Communication delay (?)

7. SNAD Design Goals • Encrypt data on the disk • Drives should have sufficient information to authenticate the reader and the writer of the data • 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 • Encrypt and decrypt the data only on the client side • Reduces load on the disk CPU

8. SNAD Design Goals • Data integrity • Detect forged data • User reading data from the server should must be sure that the files received are those originally stored • Vice versa • Flexibility • Support file sharing • Avoid other attacks • Replay attack based on time stamp (time drifting?) • High performance and scalability

9. Cryptographic building blocks • Encryption of data done using RC5 algorithm (?) • 128 bit keys • Cryptographic hash functions • MD4, MD5 and SHA-1 • Keyed Hashes • HMACK (M) = H(Ｋ1 || H( K2 || M) ) • K1 = f(K), K2=g(K) where f, g are different one-way function • Public key encryption • Digital signature

10. Public Key Encryption • Every entity has a private key SKand a public key PK • Public key is known to all • It is computationally infeasible to find SK from PK • Only SK can decrypt a message encrypted by PK • If A wishes to send a private message M to B • A encrypts M by B’s public key, C = EBPK(M) • B decrypts C by his private key, M = DBSK(C)

11. Digital Signatures • Signing procedure • Entity A (the signer) creates a signature for M by doing the following: 1. Compute s = SA(m), SA is signing algorithm for A 2. Transmit the pair (m, s), s is called the signature for message m • Verification procedure • To verify that s on m was created by A, B (the verifier) performs the following steps: 1. Obtain the verification function VA of A 2. Compute u = VA(m, s) 3. Accept the signature as having been created by A if u = true, and reject the signature if u = false

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

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

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

15. 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? • Access control? • 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

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

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

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

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

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

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

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

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

24. SNAD Scheme 3 • Still vulnerable to data disruption (a DOS attack) by the insider • HMAC means nothing • Non-repudiation?

25. Design Issues • Access control? • Files • Key object • Who creates the key object and how? • Who creates the certificate object and how? • Insider attacks? • Adding and deleting users? • Bootstrapping? • What if the user looses the key to a file accessible to him alone?

26. Design Issues • Revoking permissions is a serious problem • Simply deleting the user is not a solution • Might have cached the RC5 key • Re-encrypt the associated files with a new key and hand over the key to the authorized users • Slow • Expensive • What about transfers happening during re-encryption? • Lazy re-encryption • Mark old files dirty • Encrypt new files with a different key • Leaves access to previous files • How lazy should it be? • Open issue in SNAD

27. Design Issues • Adding a user is also a hard problem • Solution proposed in the paper: central authority obtains the RC5 key and and encrypts the key with the new user’s public key! • Things are not that simple • How to add without a centralized authority? • In peer groups some members of the group might need to participate • Should we change the key whenever a new user is added? • Suppose there are 4 clients using 4 files and all have equal access rights • SNAD will use only one RC5 key • Now a new user is added, but requires access to only one of the 4 files