Configurable Security for Scavenged Storage Systems

1. Configurable Security for Scavenged Storage Systems Abdullah Gharaibeh with: Samer Al-Kiswany, Matei Ripeanu NetSysLab The University of British Columbia

2. Introduction • Data Deluge • Scientific applications (e.g., climate simulation, biological research) • Checkpointing (e.g., application and virtual machine checkpointing) • Scavenged storage provides a solution with good price/performance ratio StorageSS ‘08

3. Scavenged Storage? Systems that opportunistically aggregate idle disk space and I/O bandwidth from participating workstations. Offers two main advantages: • high-throughput due to striping and component decoupling • low-cost solution as it is built atop of commodity resources StorageSS ‘08

4. Trust Assumptions in Distributed Storage Systems • Completely trusted environment • All system components and communication channels are trusted • Hosted on dedicated clusters and are optimized for performance • E.g., GoogleFS, Lustre • Untrusted environment • System components and communication channels are untrusted • Deployed over wide area networks • E.g., Farsite, OceanStore • Partially trusted environment • Includes a combination of trusted and untrusted components • E.g., Plutus, MosaStore StorageSS ‘08

5. Our Goal We aim to design and implement a security protocol in the context of a partially trusted environment, and to evaluate the associated overheads for different security levels. StorageSS ‘08

6. Our Environment • A partially trusted environment • Trusted metadata service • Untrusted storage nodes, clients and communication channels • An adversary can • Modify and deploy a malicious client or storage node • Spoof messages on communication channels • The system doesn’t need to provide stored data confidentiality • As a tradeoff to simplicity and performance We conduct this study in the context of MosaStore scavenged storage system StorageSS ‘08

7. Outline • MosaStore Architecture • Security Requirements • Security Protocol • Evaluation StorageSS ‘08

8. MosaStore Architecture StorageSS ‘08

9. MosaStore Design Guidelines • Component decoupling– to improve scalability • Lazy interaction – to enable high-performance • Statelessness – to minimize failure effects and recovery overhead StorageSS ‘08

10. Outline • MosaStore Architecture • Security Requirements • Security Protocol • Evaluation StorageSS ‘08

11. Requirements • Requirements related to security services • Authentication and authorization • Data and transport integrity • Accountability (i.e. assigning blame for integrity violations and data loss) • Requirements related to system characteristics • Acceptable performance degradation StorageSS ‘08

12. Security Protocol – Supporting mechanisms • Public key cryptography • Used to manage trust and certification • Two types of certificates • Machine certificates • User certificate • Generic Security Services API (GSSAPI) • Used to establish mutual authentication and security contexts StorageSS ‘08

13. Security protocol – write operation StorageSS ‘08

14. Outline • MosaStore Architecture • Security Requirements • Security Protocol • Evaluation StorageSS ‘08

15. Protocol Evaluation – Security Argument • Authentication: offered by enforcing mutual authentication between communicating entities • Authorization: provided by an independent access control module consulted by the manager • Transport integrity: provided by sending all traffic within the security context resulted from the mutual authentication • Stored data integrity: maintained by having the manager to store per chunk hash • Accountability (i.e. responsibility for integrity violations): proved by using chunk receipts stored at the manager and having the client to sign each stored chunk StorageSS ‘08

16. Performance Evaluation Testbed: 10 machines Each machine has : Quad-core2.33GHz Xeon processors, 4 GB RAM, connected at 1Gbps. StorageSS ‘08

17. Performance Evaluation 1GB file split into 1MB chunks, one client and eight benefactors StorageSS ‘08

18. Performance Evaluation 1GB file split into 1MB chunks, one client and eight benefactors StorageSS ‘08

19. Performance Evaluation Caching dramatically improves performance • Less than 17% degradation for the full solution 1GB file split into 1MB chunks, one client and eight benefactors StorageSS ‘08

20. File Size Impact Files are split into 1MB chunks, one client and eight benefactors StorageSS ‘08

21. Number of Benefactors Impact 1 GB file split into 1MB chunks, one client StorageSS ‘08

22. Summary • Design and implementation of a security protocol that operates in a partially trusted environment (only the management service is trusted) • Protocol evaluation demonstrates • Low performance degradation in small deployments • Close to original performance in deployments that offer more parallelism StorageSS ‘08

23. Thank you netsyslab.ece.ubc.ca StorageSS ‘08

24. Security Protocol – Write Operation StorageSS ‘08

25. GSS-API StorageSS ‘08

26. Replication • The manager sends a signed replicate command (contains the source benefactor B and its chunk receipt) to benefactor A the target for the new chunk replica. • Benefactor A copies the data from benefactor B and verify it against the chunk receipt • Benefactor A generates a chunk receipt and sends it back to the manager. StorageSS ‘08