Cloud Storage Security

Cloud Storage Security

IBM Research – Zurich Christian Cachin Nov. 2012

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

Cloud computing and security

■ Cloud services are convenient

– No investment cost

– Pay only for consumption – Scalable

– No skills needed

■ Clouds pose threats

– Unknown exposure

– Inherent risk of outsourcing – No established contracts – Loss of control

Cloud storage - secure?

■ Kernel.org Linux repository was compromised in Aug. 2011

– 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?

Cloud computing - dependable?

■ A problem in Amazon's cloud services disabled computing and storage

services for about one day

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

Basic security mechanisms

Mechanism

user (client)

Applied by

provider (server)

Applied by

Data-at-rest

encryption

✓

(✓)

Data authentication /

integrity protection

✓

(✓)

Data replication

✓

✓

Access control

to data

✗

✓

Encryption and access control

Client

Client

■ 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

Data encryption for cloud storage

■ 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 Client application Cloud storage interface Internet Cloud storage service Cloud storage pool Transparent encryption Server-side encryption Specific client-side encryption Transparent encryption Server-side encryption Specific client-side encryption

Data encryption for cloud computing

■ Virtual machines (VM) use virtual

disks

■ When turned off, VM is simply a

virtual-machine image (VMI) – Bootable virtual disk

■ 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? Client VM Virtual disk storage service Cloud storage pool Virtual device Cryptographic virtual device

Key management?

■ Key-management in enterprises

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

■ OASIS Key Management Interoperability Protocol (KMIP)

– Vendor-neutral format for accessing key server in enterprise

– KMIP V1.0 (Oct. 2010), in multiple products

Key Management Interoperability Protocol

Integrity protection for one client

■ Storage contains n data items x₁, ..., x_n ■ Client accesses storage via integrity-

protection 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,

Integrity

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

Integrity violation from replay attack

C

C

C

C

C

write(2,v) read(1)→x write(2,w)

read(1)→u

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]

Fork-linearizability graphically

C

C

C

write(2,v) read(1)→x write(2,w)

read(1)→u

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

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

Storage on the Intercloud

■ 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)

Integrity

Resilience

Encryption

Client

M

et

ad

a

ta

K

ey

s

Replication

Alice

Charlie

Bob

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

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

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

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

Logical secure deletion

■ 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.)

■ Policy-based key management allows

fast deletion by attributes: – Expiration date – Tenant – Project Disk drive Alice _Charlie Bob Encryption Encryption Encryption

Conclusion

■ Cloud storage security is addressed by

– Provider-side measures

– Methods implemented by users

■ Cryptography is effective

– Encryption

– Integrity protection

■ Data replication ubiquitous

Thank you

■ Christian Cachin

–www.zurich.ibm.com/~cca/ ■ Security research

–www.zurich.ibm.com/csc/security/ ■ IBM Research - Zurich

–www.zurich.ibm.com

■ Trustworthy Clouds - Privacy and Resilience for Internet-scale Critical

Infrastructure, EU FP7 No. 257243 –www.tclouds-project.eu

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 2012.

[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, 2010.

[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, 2011.

[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 2012.

[CKS11] C. Cachin, I. Keidar, and A. Shraer, "Fail-aware untrusted storage," SIAM Journal on Computing, vol. 40, Apr. 2011.

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, 2011.

[OASIS KMIP] OASIS Key Management Interoperability Protocol (KMIP)

standard, http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=kmip

[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), 2010.