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

2. 2 Introduction StorageSS ‘08  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

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

4. 4 Trust Assumptions in Distributed Storage Systems StorageSS ‘08  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

5. 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. 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 StorageSS ‘08 We conduct this study in the context of MosaStore scavenged storage system

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

8. 8 MosaStore Architecture StorageSS ‘08

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

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

11. 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. 12 Security Protocol – Supporting mechanisms StorageSS ‘08  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

13. 13 Security protocol – write operation StorageSS ‘08

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

15. 15 Protocol Evaluation – Security Argument StorageSS ‘08  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

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

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

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

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

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

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

22. 22 Summary StorageSS ‘08  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

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

24. 24 Security Protocol – Write Operation StorageSS ‘08

25. 25 GSS-API StorageSS ‘08

26. 26 Replication StorageSS ‘08  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.