1

I was pondering my computer theory and this question has been bugging me for a while .

Is it possible in some way to have a running process with its memory "encrypted" on an insecure system ?

If some one started a thread and its bits where encrypted with a key would`t it have to have its key visible in ram any way ?

I use a lot of remote virtual boxes and want to know if they can even be secure platforms . I can`t think of anything though that would stop the host from peering into the ram .

James Andino
  • 143
  • 6
  • Where would you store the key? Where would you store the plaintext data (data and executable code) that the CPU should see? – user May 26 '14 at 14:23

2 Answers2

1

In virtual machines, the host is God. It can do anything. Even if you could keep all data encrypted (which would be expensive -- e.g. see this question), it still must be decrypted at some point within the CPU, so that processing can take place. The host has complete control of the CPU.

Encrypted RAM may be useful only in contexts where the CPU is assumed to be honest, and you try to defeat external peeking into the RAM (e.g. cold boot attacks). If your CPU is itself hostile to you, then there is little you can still do "securely" (although some people tried).

Thomas Pornin
  • 322,884
  • 58
  • 787
  • 955
1

There is actually a way to do this: it is called Fully Homomorphic encryption: http://en.wikipedia.org/wiki/Homomorphic_encryption#Fully_homomorphic_encryption

In principle you can encrypt the data on the client, have the server compute the result of an arbitrary circuit on the encrypted data without decrypting it, then send the encrypted result back to the client, which can decrypt it to obtain the result of the computation. Even the description of the circuit itself can be encrypted such that the server cannot determine what it is computing.

Unfortunately, in practice, the best existing schemes still add too much overhead to make this practical, but it is an active area of research and more efficient methods may be found in the future.

jbms
  • 466
  • 2
  • 3