0

Assume an application developed in a PaaS public cloud environment. The application stores and processes some kind of sensitive data.

Encryption-at-rest seems clearly described already, and the option to manage keys outside the cloud which can help ensure nobody outside your organisation has access to your unencrypted data when stored in cloud.

Encryption-in-transit seems clearly described already. E.g. TLS encryption at Presentation-level would mean that the unencrypted data is not readable at the lower levels of the OSI-model during transit.

This leaves us with data-in-use. Cloud providers are increasingly vague on this, and there seems to be much misunderstanding on this aspect. The time data is logically stored in RAM and being processed by e.g. an application, to my understanding it is not encrypted. This is the part of Cloud encryption I do not fully understand how to explain, and I need your help.

  • Who can theoretically access the clear data at this point?

    • Would container escape techniques allow an attacker to access other cloud-customers' data?
    • Would a memory dump of the virtualisation-layers or the physical machine in a datacenter allow an attacker to access clear data?
    • Are there other ways an attacker could move "below" the virtual application and access the information as it is being prcocessed?
  • To my old-school-hardware-brain (while this may be complicated by the many levels of abstraction involved), at some point the data must exist on some server somewhere in RAM. How is the data protected at that point? From attackers? From the cloud provider? From other customers?

  • Is this even a viable attack vector to be concerned about? Why? Why not?

Notes:

  • "Confidential computing" initiatives is outside scope for this question, since it is not yet in use on a wider scale to my understanding.
  • What I want to understand is: At what points in time is what information/data accessible to whom in a cloud infrastructure.
  • I want to understand what is "possible" rather than what is "intended". Please correct, if my understanding is wrong.

2 Answers 2

1

Theortically? Anyone, Yes, Yes, Yes. Virtual sandboxing multiple layers, container, OS, vm, host OS etc. Yes I think there have been demonstrated leaks in all those sandboxing layers at some point.

So yeah, if you program is running and has a if(x==y) statement obviously the machine running that statement needs (mostly) to have x and y unencrypted. The question is what other programs can access the memory.

If you are running on your own hardware you "only" have to worry about

  1. Your hardware
  2. BIOS
  3. OS
  4. unwanted software ie viruses
  5. third party libraries and supporting software
  6. drivers
  7. god knows

If you are running on someone else's hardware its all that plus do you trust them?

If they are running other peoples software on the same hardware as your software. All of the above + vulnerabilities in the divisions between virtual machines.

0

at some point the data must exist on some server somewhere in RAM. How is the data protected at that point? From attackers? From the cloud provider? From other customers?

We are rapidly moving towards a world where data is encrypted in RAM; see for example GCP's confidential computing initiative which means that data in RAM is encrypted with a VM-specific key. It is still unencrypted in the CPU itself (including caches) but that removes a number of the attacks you are worried about.

As for your cloud provider, you to a large extent have to trust them. Again, the major vendors are making moves to reduce the amount of trust you have to give them - see e.g. this post from AWS - but that trust is still to some extent required.

Is this even a viable attack vector to be concerned about? Why? Why not?

Without a threat model, this is an impossible question to answer. If you are being attacked by a nation-state level actor, you're probably screwed no matter what you do.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.