Why is on-chip data considered to be secure in secure processor setting?

Question

I was taking a look into the paper PHANTOM: Practical Oblivious Computation in a Secure Processor. The introduction says,

Confidentiality of data is a major concern for enterprises and individuals who wish to offload computation to the cloud. In particular, cloud operators have physical access to machines and can observe sensitive information (data and code) as it moves between a CPU and physical memory. In response to such attacks, commercial interest in protecting off-chip data has begun to grow.

To protect against such attacks, prior work has proposed secure processors that automatically encrypt and integrity-check all data outside the processor – whether in DRAM or non-volatile storage. Although secure processors encrypt memory contents, off-the-shelf DRAMs require that memory addresses be transmitted over the memory bus in cleartext. An attacker with physical access can snoop the memory bus and observe the locations of RAM accessed and in turn learn sensitive data such as encryption keys or information about user-level programs and guest VMs in a virtualized server.

The assumption of a secure processor looks kind of far-fetched to me.

• If the processor is hosted at cloud, why is even the on-chip data being considered to be secure given that the hardware is in complete control of the cloud service provider?
• If the cloud service provider is untrusted, what is the guarantee that they will run the program on a secure processor, not an ordinary one?

Answer 1

If the processor is hosted at cloud, why is even the on-chip data being considered to be secure given that the hardware is in complete control of the cloud service provider?

First of all, some trust has to be installed to your cloud service provider. You're definitely depending on the services of the service provider. Furthermore, access to the keys - where-ever they may be located - is presumably automated. This means that at some level the cloud provider probably has access to them.

If the cloud service provider is untrusted, what is the guarantee that they will run the program on a secure processor, not an ordinary one?

In the end, audits may give you some kind of assurance. Of course there are ways of checking the CPU itself, but in the end you rely on the provider. Note that trust is never an absolute. For instance, checking a processor ID cannot give you complete trust that this processor is secure, but it would make it harder for a cloud server to spoof it.

But that goes the other way as well. It's not that likely that the cloud server provider itself will try and penetrate your security; they rely on you to provide a service. Being known as an untrusted provider will kill their main business case. But a large cloud provider consists of people. You may for instance have to deal with a disgruntled employee.

Security is a game of layers. You try and protect each layer to the best of your abilities. Adding more security to the memory interface seems to provide some security at that particular layer. It depends on the setting / use case if it is worth the cost (not just in money, but also in required knowledge, time, overhead, complexity etc.).

You know your use case and thread model best. In the end it is up to you to decide if such measures are worth the cost.

Answer 2

Actually, you do not need to trust the cloud provider. All you need to do is trust the processor manufacturer (say Intel, for Intel Sgx).

There are allegedly ways in which one can "seal" a processor into its packaging, so any attempt to tamper with it will simply break it. Then the processor is guaranteed to either work as the manufacturer designed it, or not work at all. At the beginning of the computation, the processor simply authenticates itself (the manufacturer will provide you with a database of public keys of its processors) and then you'll know that the processor and all its contents can be trusted ... at least to the extent to which you trust the manufacturer. ORAM schemes combined with Merkle tree authentication can then in principle "extend" the amount of trusted storage to as much RAM (and virtual memory on disk) as you want.

That's the theory at least! Personally, I am not 100% confident about the whole "sealing" thing. And since processors and operating systems tend to interact in rather complex ways (speculative execution, for example) there is always the risk that of a subtle divergence between the clean theoretical model of the ORAM and the actual implementation that will leak information.