3 ms·

To me that's twisted logic. "I don't want to have to trust my cloud provider." "Ok, we'll absolutely pinky-swear by this API you can access that our machines

by sounds 7y ago

To me that's twisted logic. "I don't want to have to trust my cloud provider." "Ok, we'll absolutely pinky-swear by this API you can access that our machines are running a trusted setup." "Ok! I'll just trust the API you provide." Even if the API is an x86 instruction, even if you do timing checks and side-channel checks in your code, you're still just in an arms race with your cloud provider while they hold all the power.

lxgr 7y ago
You don't trust the cloud provider, you trust the hardware vendor. They are the root of trust in this scenario. Of course, if that trust, due to malice or implementation defects, is misplaced, you're not better (but also not worse) off than without something like SGX.
- sounds 7y ago
  I addressed that when I said "x86 instruction." An x86 core with SGX can be emulated... (Edit: SGX can't be emulated. I stand corrected. Perhaps a better argument would have been arguing that verifiable builds give the user software freedom by granting them the ability to run the same code everywhere. But trusted computing != verifiable builds.)
  - Reelin 7y ago
    Actually it can't be, barring successful attack against the physical hardware, firmware, or underlying cryptography. SGX employs public-key cryptography to authenticate itself to the end user remotely (the same as SSH). The key it uses is signed by the hardware vendor, so you most certainly won't be able to emulate it. That being said, I have serious misgivings about any hardware I own and use being explicitly designed _not_ to do my bidding. I can certainly see the utility of such an arrangement for a cloud provider though.
AgentME 7y ago
Th cloud provider would be able to provide a message signed by Intel that says "this computer is running only code with hash XYZ at the top privilege level, and the code with that hash has produced public key ABC". The cloud provider would publish the code with hash XYZ, which would be open source and publicly studied to verify the claims that it runs the users' compute workloads securely without allowing other processes to spy on them. The code would create a keypair upon startup, keeping the private key private even from the cloud server operators, and therefore you can know that if you encrypt a message to the public key in the signed message, then only the server's code running with hash XYZ can read the message. You could encrypt your compute workloads (or messages to your own running workload) to that public key and know that the cloud server operators can't read the message. This does require trusting the CPU manufacturer (Intel) though. It's possible that Intel could collude with a server operator to create fake remote attestation messages, and trick you into encrypting your compute workload to them instead of the securely-sandboxed code of hash XYZ. That's not any worse than the current setup where your submitted compute workloads can't at all be encrypted in a way that the cloud operators can't read. Currently, if I want to use a no-name cloud host, then I have to trust the no-name cloud host to not be conspiring against me. With remote attestation, I just have to trust that the no-name cloud host and Intel aren't working together to conspire against me. I trust Intel relatively, so it doesn't matter how shady the no-name cloud host is.
- Polylactic_acid 7y ago
  > I trust Intel relatively This seems like a bad idea. Probably the number 1 reason for a host to go snooping in your VPS is because they have been requested to by a government. A government also has the power to ask intel to let the host do this. So no security has been gained here.
  - AgentME 7y ago
    Without this scheme, the government or the host alone could inspect my VPS. With this scheme, the host acting alone is no longer able to inspect my VPS. That seems like a solid win.
pyuser583 7y ago
I’m not a cloud provider. Nobody has a right to know what’s happening on box. If I want to mislead the servers I interact with, that is a right I have. As a BE developer, I can tell you FE should always be untrusted. Always. Anyone who tells you otherwise is insane. Yes, NetFlix wants to live a fantasyland where they control the display of content. Tough. At the end of the day, I can record my iPad and put it on YouTube.

by sounds 7y ago

lxgr 7y ago

You don't trust the cloud provider, you trust the hardware vendor. They are the root of trust in this scenario. Of course, if that trust, due to malice or implementation defects, is misplaced, you're not better (but also not worse) off than without something like SGX.

sounds 7y ago
I addressed that when I said "x86 instruction." An x86 core with SGX can be emulated... (Edit: SGX can't be emulated. I stand corrected. Perhaps a better argument would have been arguing that verifiable builds give the user software freedom by granting them the ability to run the same code everywhere. But trusted computing != verifiable builds.)
- Reelin 7y ago
  Actually it can't be, barring successful attack against the physical hardware, firmware, or underlying cryptography. SGX employs public-key cryptography to authenticate itself to the end user remotely (the same as SSH). The key it uses is signed by the hardware vendor, so you most certainly won't be able to emulate it. That being said, I have serious misgivings about any hardware I own and use being explicitly designed _not_ to do my bidding. I can certainly see the utility of such an arrangement for a cloud provider though.

AgentME 7y ago

Th cloud provider would be able to provide a message signed by Intel that says "this computer is running only code with hash XYZ at the top privilege level, and the code with that hash has produced public key ABC". The cloud provider would publish the code with hash XYZ, which would be open source and publicly studied to verify the claims that it runs the users' compute workloads securely without allowing other processes to spy on them. The code would create a keypair upon startup, keeping the private key private even from the cloud server operators, and therefore you can know that if you encrypt a message to the public key in the signed message, then only the server's code running with hash XYZ can read the message. You could encrypt your compute workloads (or messages to your own running workload) to that public key and know that the cloud server operators can't read the message. This does require trusting the CPU manufacturer (Intel) though. It's possible that Intel could collude with a server operator to create fake remote attestation messages, and trick you into encrypting your compute workload to them instead of the securely-sandboxed code of hash XYZ. That's not any worse than the current setup where your submitted compute workloads can't at all be encrypted in a way that the cloud operators can't read. Currently, if I want to use a no-name cloud host, then I have to trust the no-name cloud host to not be conspiring against me. With remote attestation, I just have to trust that the no-name cloud host and Intel aren't working together to conspire against me. I trust Intel relatively, so it doesn't matter how shady the no-name cloud host is.

Polylactic_acid 7y ago
> I trust Intel relatively This seems like a bad idea. Probably the number 1 reason for a host to go snooping in your VPS is because they have been requested to by a government. A government also has the power to ask intel to let the host do this. So no security has been gained here.
- AgentME 7y ago
  Without this scheme, the government or the host alone could inspect my VPS. With this scheme, the host acting alone is no longer able to inspect my VPS. That seems like a solid win.

pyuser583 7y ago

I’m not a cloud provider. Nobody has a right to know what’s happening on box. If I want to mislead the servers I interact with, that is a right I have. As a BE developer, I can tell you FE should always be untrusted. Always. Anyone who tells you otherwise is insane. Yes, NetFlix wants to live a fantasyland where they control the display of content. Tough. At the end of the day, I can record my iPad and put it on YouTube.