Cloud Storage Security

Transcription

1 IBM Research Zurich Christian Cachin Nov Cloud Storage Security 2009 IBM Corporation

2 Overview Cloud computing security Storage security concepts Data encryption Key management Key-management standard (OASIS KMIP) Multi-client integrity protection Fork-linearizable protocols Data replication Replicated storage on the Intercloud Secure deletion Conclusion IBM Corporation

3 Cloud computing and security Cloud services are convenient No investment cost Pay only for consumption Scalable No skills needed Access from everywhere Standardized services IBM Corporation Clouds pose threats Unknown exposure Inherent risk of outsourcing No established contracts Loss of control Fast and reliable network needed Customization not possible

4 Cloud storage - secure? Kernel.org Linux repository was compromised in Aug Linux kernel sources exposed, but it is public anyway Thanks to cryptographic integrity protection in revision control system (git), kernel code modifications could be detected Was other content modified? What if other storage and services in the cloud are modified? 2012 IBM Corporation

5 Cloud computing - dependable? A problem in Amazon's cloud services disabled computing and storage services for about one day Clients were affected, including websites that use Amazon's resources Problem affected multiple, supposedly independent "zones" in Amazon's infrastructure 2012 IBM Corporation

6 Cloud-computing security concerns Customer's interests Protect outsourced programs and data Prevent attacks by provider (?) More importantly, protect Against attacks on provider by other tenants Against provider's jurisdiction Provider's interests Protect infrastructure Against abuse by tenants, like botnets and spammers that pay for service Against tenant-to-tenant attacks Maintain service quality for others IBM Corporation

7 Storage security and clouds IBM Corporation

8 Basic security mechanisms Mechanism Data-at-rest encryption Data authentication / integrity protection Applied by user (client) Applied by provider (server) ( ) ( ) Data replication Access control to data IBM Corporation

9 Encryption and access control Client Access control Why encrypt stored data when there is access control? Many attackers bypass access control Storage systems have many layers Deleting data no longer possible Encryption shifts access control to key-access Easier to guard keys Client Access control Encryption Storage Storage IBM Corporation

10 Data encryption IBM Corporation

11 Data encryption for cloud storage Client application Transparent encryption Cloud storage interface Specific clientside encryption Internet Server-side encryption Cloud storage service Cloud storage has many variations "Simple" object storage Key-value stores: S3... NFS/CIFS file system Archiving / backup interfaces Encryption possible On client By service At any layer Cloud storage pool IBM Corporation

12 Data encryption for cloud computing Client VM Virtual machines (VM) use virtual disks Virtual device When turned off, VM is simply a virtual-machine image (VMI) Bootable virtual disk Cryptographic virtual device Virtual disk storage service Cloud storage pool Encrypt virtual disks as usual VMI encryption problematic Automated boot process Where are the master keys? SSH host key of VM Storage encryption keys For best client protection, VMI would not contain cleartext keys Provide keys at boot time Alternatively,... a root-less VM? IBM Corporation

13 Key management IBM Corporation

14 Key management? Key-management in enterprises Key management moves to the cloud (Keys-as-a-service) IBM Corporation

15 Key management as a service Key management becomes a (cloud) service Centralized control Lifecycle management Automated and policy driven [BCHHKPV10] Focus on data-storage keys Tape, disks, filesystems Cloud storage Key Management Interoperability Protocol OASIS Key Management Interoperability Protocol (KMIP) Vendor-neutral format for accessing key server in enterprise KMIP V1.0 (Oct. 2010), in multiple products (IBM Tivoli Key Lifecycle Manager V2) Contributions from IBM Research - Zurich Tivoli Key Lifecycle Manager IBM Corporation

16 Integrity protection IBM Corporation

17 Integrity protection for one client Storage contains n data items x 1,..., x n Client accesses storage via integrityprotection layer Uses small trusted memory (for keys or reference values) Integrity layer operations Read item and verify Write item and update trusted memory Two common implementations Data authentication with MAC (allows replay attacks) Store short reference value v computed with Merkle hash tree, read/verify and write/update of data item with O(log n) work Integrity Client IBM Corporation v

18 Multi-client integrity protection Single-client solution Relies on hash/reference value v Stored locally in trusted memory Changes after every update operation Multiple clients Need to synchronize trusted memories Solution with digital signatures Every client has a public/private key pair Write operation produces signature σ on hash v Client stores signature and hash (σ, v) on cloud Approach allows replay attacks Easy to prevent with trusted coordination service Otherwise, resort to ensuring fork-linearizability Integrity C 1 C 2 C IBM Corporation

19 Integrity violation from replay attack C 1 C 3 C 1 write(1,x) write(1,u) write(1,t) C 2 write(2,v) read(1) x write(2,w) C 3 read(1) u read(2) w IBM Corporation

20 Multi-client integrity protection and forking attacks Server may present different views to separated clients E.g., not show the most recent WRITE operation to a reader Creates a "fork" between their histories Clients cannot prevent this without communication Protection with protocols that ensure fork linearizability [MS02]: If malicious server forks the views of two clients once, then their views are forked ever after they never again see each others updates Every inconsistency and integrity violation results in a fork Best achievable guarantee for storage on untrusted server Forks can be detected on a "cheap" low-security external channel Use only a semi-trusted coordinator [C11,CKS11] Prototype implementation in VENUS [SCCKMS10] IBM Corporation

21 Fork-linearizability graphically C 1 write(1,x) write(1,u) write(1,t) C 2 write(2,v) read(1) x write(2,w) C 3 read(1) u read(2) w w(1,x) w(2,v) w(1,u) r(1) u r(1) xw(2,w) w(1,t) View of C 1 r(2) w View of C 3 View of C IBM Corporation

22 Integrity for cloud storage and cloud computing Storage integrity solutions Single-client is easy Multiple clients requires coordination among clients Forking consistency notions provide graceful degradation Verify correct behavior of cloud with one operation Integrity of computation on untrusted clouds comes next Cloud gives new motivation to protocols that verify remote computation IBM Corporation

23 Data replication IBM Corporation

24 Data replication in cloud storage Replication ensures availability Data copies may become unavailable Problem is synchronization of copies Technologies depend on network characteristics Storage controller for local and SAN storage Centralized gateways to cloud storage In future, decentralized access to cloud storage Replication usually combined with erasure coding (generalized RAID) All cloud storage services use replication (or erasure coding) internally Including "geo-replication" to remote sites for disaster recovery IBM Corporation

25 Storage on the Intercloud Metadata Resilience Integrity Encryption Client Keys Cloud storage layer developed at IBM Zurich [BCEHSVZ11] Storage on the Intercloud Limits trust in single provider Properties Confidentiality Integrity Resilience through replication Implemented as client-side library Modular, layered structure Transparent to client Transparent to remote clouds Used by multiple clients No client-to-client communication Clients may fail (crash) Clients store only credentials locally IBM Corporation

26 Replication Alice Bob Charlie Clients read and write object values Do not communicate No synchronized clocks Storage nodes replicate data Faulty nodes may erase or modify data Do not communicate with each other IBM Corporation

27 Replication algorithm Clients read and write objects (values) Client operations take time and may execute concurrently No locks No single point of failure Clients may fail Algorithm ensures a "consistent" view of single storage object If no operation is concurrent, then every read returns the most recently written value Otherwise, read may return old value (written before) or new value (written concurrently) Emulates a shared memory Semantics of operations under concurrent access? (here: regular) Linearizability ensures that all operations appear atomic Implementation based on logical timestamps (sequence numbers) 2012 IBM Corporation

28 Data replication using key-value stores (KVS) KVS operations PUT(k,x), GET(k) x, LIST() {k}, REMOVE(k) How to achieve multi-writer storage with KVS replicas and wait-free semantics? Theorem [BCEHSVZ11]: Need to store at least two copies of every value Store value at a temporary and an eternal key 2012 IBM Corporation

29 Secure deletion IBM Corporation

30 Secure deletion via encryption Erasing stored data (= sanitizing storage media) is almost impossible Layered storage systems Every layer may cache data and leave traces Magnetic disks must be specially wiped SSDs cannot be sanitized with current methods Use encryption and securely delete the key Key must be stored in memory that can be erased securely In practice Some SSDs already provide FDE (internal encryption) that helps sanitization Encryption-based sanitization will appear on all storage layers in future IBM Corporation

31 Logical secure deletion Alice Encryption Bob Encryption Charlie Encryption Provider stores data of multiple tenants Provider must erase tenant data when service ends Data encrypted, e.g., with one separate key per tenant When tenant moves out, provider destroys tenant's key (Same goal achieved when tenant encrypts and manages key; this is transparent to provider.) Disk drive Policy-based key management allows fast deletion by attributes: Expiration date Tenant Project Etc IBM Corporation

32 Conclusion Cloud storage security is addressed by Provider-side measures Methods implemented by users Cryptography is effective Encryption Integrity protection Data replication ubiquitous Crypotgraphic protection becomes common IBM Corporation

33 Thank you Christian Cachin Security research IBM Research - Zurich Trustworthy Clouds - Privacy and Resilience for Internet-scale Critical Infrastructure, EU FP7 No IBM Corporation

34 Literature (1) [BCEHSVZ11] C. Basescu, C. Cachin, I. Eyal, R. Haas, A. Sorniotti, M. Vukolic, and I. Zachevsky, "Robust data sharing with key-value stores," in Proc. Intl. Conference on Dependable Systems and Networks (DSN), June [BCHHKPV10] M. Björkqvist, C. Cachin, R. Haas, X.-Y. Hu, A. Kurmus, R. Pawlitzek,and M. Vukolic, "Design and implementation of a key-lifecycle management system," in Proc. Financial Cryptography and Data Security (FC 2010), LNCS 6052, [C11] C. Cachin, "Integrity and consistency for untrusted services," in Proc. Current Trends in Theory and Practice of Computer Science (SOFSEM 2011) (I. Cerna et al., eds.), LNCS 6543, [CJS12] C. Cachin, B. Junker, and A. Sorniotti, "On limitations of using cloud storage for data replication," in Proc. 6th Workshop on Recent Advances in Intrusion Tolerance and resilience (WRAITS 2012), June [CKS11] C. Cachin, I. Keidar, and A. Shraer, "Fail-aware untrusted storage," SIAM Journal on Computing, vol. 40, Apr IBM Corporation

35 Literature (2) [KGPCH11] A. Kurmus, M. Gupta, R. Pletka, C. Cachin, and R. Haas, "A comparison of secure multi-tenancy architectures for filesystem storage clouds," in Proc. Middleware, LNCS 7049, [OASIS KMIP] OASIS Key Management Interoperability Protocol (KMIP) standard, [SCCKMS10] A. Shraer, C. Cachin, A. Cidon, I. Keidar, Y. Michalevsky, and D. Shaket, "Venus: Verification for untrusted cloud storage," in Proc. ACM Workshop on Cloud Computing Security (CCSW 2010), IBM Corporation