Security Issues In OSD

1. Security Issues In OSD Vishal Kher 21 October 2002

2. Outline • Security for NASD • Comparison With Our Regional Model • Intrusion Detection • Conclusion

3. How Things Were.. • Fileserver protects critical information resources • Requests go through the fileserver • Every request is inspected • Malicious requests never read the disk Howard Gobioff, PDL Retreat 1998

4. How NASD Changes Things... • File manager is not on the datapath • Policy decisions made by file manager • Drive must enforce policy Howard Gobioff, PDL Retreat 1998

5. Basic Security Strategy • Integrity of communications (requests/data) • digital signature (HMAC-SHA-1), often called a MAC • signature = crypto_checksum( secret key, message) • fixed length, lossy, all bits sensitive to all message, key bits and order • receiver computation demonstrates sender has key, no tampering • Privacy of communications • encryption (Triple-DES) • new-message = encrypt(secret key, message) • Freshness of communications • nonces (you can generate a value that I know is not old) • timestamps, sequence numbers Garth Gibson, NSIC OBSD presentation, September 7, 2000

6. What Does NASD Require to be Secure? • 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

7. Key Hierarchy • MasterKey • Used by administrator to control the key hierarchy, to set the DriveKey, and for other administrative tasks • DriveKey • Sets up partitions and PartitionKeys • PartitionKeyN • Used by File manager to manage a partition and to set the WorkingKeys • Drive and File manager store these keys • WorkingKey • Used by FM to generate capabilities • Each drive maintains two working keys per partition

8. Key Hierarchy • Black and Gold Keys are the working keys • In case of a single working key update of the key invalidates all outstanding capabilities • Use two working keys to • Avoid bulk invalidation and storm of requests for new capabilities • Graceful expiration of capabilities in the old working key Blue Key DriveKey PartitionKeys CapabilityKeys MasterKey Gold Key

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

10. The Region Approach • Central Metadata server per region • Mobility of objects, device and client • Object will reside at the proper location (self routing) • Metadata servers share metadata – fault tolerance Region Region OSD OSD Client Manager Manager Network Client OSD OSD Client Manager OSD

11. The Region Approach • Object replication depending on the demand for the object • Intra-region as well as Inter-region mobility • Automatic backup based on object attributes • Perform all of the above in a secure manner • NASD is good for single region • The capability-key is per object based • If the file manager is compromised, whole system is compromised

12. Issues Due To Mobility • How to move an object within a region? • Metadata Manager moves the object • The object moves without contacting the Metadata Manager • Problems • With the NASD approach capability keys need not be stored on the device • The capability keys are generated from partition keys, which are device dependant • If we move the object, we will have to move the keys? • If we change the keys, we need generate and distribute new capability-keys to the existing clients • Need to authenticate the identity of the device • What if the object is encrypted? • Need a secure protocol for seamless key-management

13. Issues Due To Mobility • How to move a object from one region to another? • All of the previous problems still hold • The source metadata manager has no control over the remote device (no access to partition keys) • Need for secure communication and negotiation between metadata severs • Device mobility • Intra-region • Device authentication, metadata manager has the partition keys • Inter-region • Use the old metadata manager, old metadata manager re-routes the request to the new metadata manager • Use the new metadata manager, generate new keys • Device authentication

14. Other Issues • Fault-tolerance • Metadata severs form a distributed systems • If one server goes down, one of the servers take its role • The new metadata server should know all the keys • Share the secret between the servers, threshold secret scheme • If the metadata sever is compromised all devices are compromised (partition keys) • If a device is unavailable or damaged (may be due DOS attack or physical damage), the data on the device cannot be retrieved • Divide the data among n disks in such a way that using at least t <= n disks we can retrieve the data

15. Intrusion Detection • We need some disk level or object level intrusion detection • Why? • Example • Object replication, on high demand • An attacker can send large number of requests for an object • Waste of space due to replication, expensive key-management operations • Object mobility • What if an attacker keeps moving object making object unavailable? • Object level intrusion detection • Object detects attacks and takes action (blocks request from attacker machine) or contacts metadata manager • Use logs to detect malicious activity

16. Conclusion • Studied the NASD approach • Compared with our regional approach • NASD security scheme doesn’t scale well in our approach • Need better scheme than NASD • Need of a secure protocol to support floating objects, devices, and clients • Need for disk level and/or object level intrusion detection • Can we leave the access control to the device or the object