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

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

Embed Size (px)

Citation preview

1

Configurable Security for Scavenged Storage Systems

NetSysLabThe University of British Columbia

Abdullah Gharaibeh

with: Samer Al-Kiswany, Matei Ripeanu

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

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

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

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

StorageSS ‘08

We conduct this study in the context of MosaStore scavenged storage system

7

Outline

MosaStore Architecture

Security Requirements

Security Protocol

Evaluation

StorageSS ‘08

8

MosaStore Architecture

StorageSS ‘08

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

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

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

Security protocol – write operation

StorageSS ‘08

14

Outline

MosaStore Architecture

Security Requirements

Security Protocol

Evaluation

StorageSS ‘08

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

Performance Evaluation

StorageSS ‘08

Testbed:

10 machines

Each machine has : Quad-core 2.33GHz Xeon processors, 4 GB RAM, connected at 1Gbps.

17

Performance Evaluation

StorageSS ‘08

1GB file split into 1MB chunks, one client and eight benefactors

18

Performance Evaluation

StorageSS ‘08

1GB file split into 1MB chunks, one client and eight benefactors

19

Performance Evaluation

StorageSS ‘08

1GB file split into 1MB chunks, one client and eight benefactors

Caching dramatically improves performanceLess than 17% degradation for the full solution

20

File Size Impact

StorageSS ‘08

Files are split into 1MB chunks, one client and eight benefactors

21

Number of Benefactors Impact

StorageSS ‘08

1 GB file split into 1MB chunks, one client

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

Thank you

netsyslab.ece.ubc.ca

StorageSS ‘08

24

Security Protocol – Write Operation

StorageSS ‘08

25

GSS-API

StorageSS ‘08

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.