Trusting Your Cloud Provider. Protecting Private Virtual Machines – Armin Simma
SECRETS: My talk is first and foremost about secrets.
Most people refer to data at rest or data in motion by the term “secrets”. When we talk about secrets usually we mean data at rest or data in motion. There are effective measures to protect these data, one of which is encryption. As you write in CfP 2013: “..uses encryption, access control…”. Concerning (IaaS-)clouds we have data IN EXECUTION. That is, the virtual image / virtual machine (VM) sent to the cloud provider is the secret to be protected. The problem is: this secret must execute on someone else’s system. Of course, we cannot simply encrypt the VM and send it to the provider. Homomorphic encryption would be a solution to this problem but at the time of writing it is academic i.e. it is not ready (and secure enough) to be used in real systems. In my talk (and our project) I want to show that it is possible to protect secrets (VM of the cloud customer) running on the providers host system using Trusted Computing technology.
FAILURES: Root users (superusers) usually have full control over and full access to a system. In our case the root user at the cloud providers site has full access to the provider’s host system. Thus he has full access to the guest image (i.e. the VM of the customer). What if root is doing wrong or malicious action? He could gain insight or manipulate the guest image. Here is potential failure. In my talk I want to show how to keep root users from failures.
VISIONS: In our project we were building a prototype to show that it is possible to build the proposed system. But the technical system is not enough. We need an “ecosystem” to bring our idea to real life. This is my vision: We have a trusted third party (I call it TTT trusted third tester) that vouches for a trustworthy (in that case thoroughly tested) system and publishes reference hash values to compare with the running system. The cloud customer can use these reference values plus attestation technology to check that a trustworthy system is running on the provider’s host. Using so-called sealing technology the VM will be decrypted on the provider’s site only if the provider’s system matches the reference hashes.
Cloud | Trust | Security
Security is the top inhibitor for companies not moving to the cloud
Problem Statement: Insider attacks within the cloud
There are a number of real-world examples of insider attacks on cloud based systems (including Salesforce.com leak of confidential information). These date back to 2007…
DBIR provides a classification of “insider attacks” as 18% – Quoted from Alex Hutton’s DeepSec keynote
How can we ensure that a [malicious] insider doesn’t have access to the customers VM.
Assumptions
- no physical access
- cloud provider is “partially” trusted at least
Solutions
Encrypt the VM
Simple idea, but not possible as the provider will need to decrypt it in some way to run it. Decryption key must be known in some way to the provider.
Security based on trust
Assurance needs a kind of “proof”
Typically such “proofs” are given by service level agreements, but do not often cover security of the service. If any “proof” exists at all, it is done by an external audit or 3rd party certification of the cloud provider.
Suggested solution in a nutshell
Based on MAC (Mandatory Access Control) to allow more fine-grained policies and system-wide policies.
SELinux is an implementation of MAC for Linux
Dan Walsh gives many examples where SELinux would have prevented known vulnerabilities (e.g. shellshock, CVE-2011-1751)
By using SELinux it is possible to create a configuration to:
- Restrict root from copying snapshots and VM images
- Restrict root from doing other malicious things
- Prevent logs from being removed or manipulated
SELinux policy files can however become VERY complex over time…
The conceptual problem is that an administrator must be able to perform maintenance and install new patches. This could allow an administrator to bypass protections. This can be prevented allowing only patches to be applied by a secondary root user who must validate and logon physically with hardware token. Reducing the possible exposure.
Privileged Identity Management – a number of standards exist and should be taken into consideration (especially when it comes to logging actions)
TPM (Trusted Platform Module)
The second piece of the puzzle… used to store and protect keys against external attack and theft.
Tamper resistant, and relatively cheap hardware (1-2$). Currently over 600 million+ TPM chips exist
Version 2 is on the horizon
Root of Trust (RoT) gives an initial anchor for a security system
TPM was used in this solution for:
- authentication / identification of the machine
- storage of hash values
- integrity measurement
- attestation
TPM measured boot:
Before any component is executed, it is measured (i.e. hash is logged into the PCR) – Measure > Extend > Execute
After hashes are stored into the PCR a remote entity can implement reporting (attestation). This attestation can be compared against reference values (golden values) to ensure the process has not be altered.
POC for this was developed over the past few years, but now seems invalid due to the release of OpenAttestation
Overall ecosystem
A Trusted Third Tester (TTT) would need to publish signed integrity values for the “golden values” checks
A Cloud Attestor and Advisor (CAA) would need to have software on the customer site to perform the attestation
Related work
Homomorphic Encryption
Main idea: Perform operations on the cipher-text, only person with the key can view the results decrypted
Would resolve all these issues if it’s fast/reliable enough
Problems with TPM-based solutions
- Inefficiency problem
- Whitelist “golden values” –
- Systems are NOT always the same, and therefore need/have different “golden values”.
- Reference systems need to be 100% the same
- Attacks on TPMs
- Some are known (presented later at DeepSec)
- Hardware and Software-based issues
- TOCTOU
- Time Of Check, Time Of Use
- Encryption of VMI using sealing
- Cloud provider must disclose details of their platform
- Necessary for attestation
Links:
Like this:
Like Loading...
Related
Cатсн²² (in)sесuяitу / ChrisJohnRiley 
Pingback: Week 47 In Review – 2014 - Infosec Events