By Christopher Moran, Nicoara Talpes

1. “Hey you, get off my cloud: Exploring information leakage in third-party compute clouds” – Ristenpart and others By Christopher Moran, NicoaraTalpes

2. Server-based model • Solution is addressed to VMs that are web servers • Web servers should not have confidential information anyway • "A complete firewall solution can be created in the cloud by utilizing Amazon EC2’s default deny-all mode which automatically denies all inbound traffic unless the customer explicitly opens an EC2 port. “ – default for instances, protects confidentiality • Meets security outlined in Health Insurance Portability and Accountability Act of 1996

3. Assumptions • How does the attacker know when the victim launches new instances? • Assumes that ‘most people’ use small VMs, but those represent only 21% • A web service will not go for small instances if it has decent traffic

4. Limitations • Co-residence reverse engineering is highly dependent on EC2’s architecture, thus not applicable for other providers • Microsoft Azure does not have VM capability • Side-channels not useful for inferring encrypted messages • Use lab-conditions for keystroke timing tests, instead of the cloud

5. Limitations 2 • Unrealistic advantages of the testbed: idle machine, no core switching • VM cross channel leakage could be explained more clearly, use examples of how an attacker might use the leakage • Live example on the cloud • Explanation of how a hacker might use technique • Inefficient covert-channel method : 0.2 bits/sec amounts to 720 bits/hour • Unrealistic: did not determine co-residence using more than 2 instances on a CPU

6. Limitations 3 • Load-based co-residence test will not function for VMs that are not hosting web services: there is a fraction of instances unreachable • D.O.S attack impractical on a large share of victim’s instances since coverage is around 8.4 % (at paper’s budget)

7. Improvements • Paper did not actually do any data theft to prove it is possible. • No data for co-residence success rates for victims that have servers up for longer than two days before the attack • Extrapolation from covert channel communication between 2 VMs to side-channel model( attacker-victim) is not explained.

8. Improvements 2 • No cost projection for achieving any results in the paper • Experiment should have been designed between two parties, the attackers not knowing the victim’s launch schedules, outside public information • Instances cannot be placed with extra-large VMs

9. Solutions • Simple solutions could be implemented by Amazon: breaking parallel placement by assigning more random IPs to new instances • Or remap VMs periodically • The paper does not justify the solution of isolating users to different hardware • The point of cloud computing is sharing resources on the same machine and on-demand scaling. • Pushes people to use larger instances when unnecessary

10. Analysis • Assuming that data on the servers is confidential, is there value gained from the techniques used? • Don’t know data hosted on VM, guesstimate machine’s use based on site and CPU activity, will not know specifics about system, intelligence learned is high level • Could have poorly implemented system that overuses CPU for amount of traffic • Other keystroke timing attacks known before, this did not require co-residency • Technique relies heavily on knowledge of a person’s typing style • Need to know when they are typing sensitive information