4 ms·

Trusted computing enables you to prove to a remote party what your machine is executing. This would be useful to cloud providers so they could prove to their us

Trusted computing enables you to prove to a remote party what your machine is executing. This would be useful to cloud providers so they could prove to their users that their servers are only running their users' code without snooping on it. People would no longer have to choose only from well-known cloud providers to find a trusted host. You could imagine a marketplace where anyone could sell the compute power of their home computers (undercutting cloud providers' prices to make up for their lesser network connectivity) and use remote attestation to prove that they're not spying on or modifying their customers' compute workloads. The people selling their compute power like this can use sandboxing to protect their own system from the customers' compute workloads, and use trusted computing / remote attestation to protect the customers' compute workloads from their own system. I think it's extremely good for users when a technology removes the need for trust in big brands and allows anyone to compete.

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.
dmatech 7y ago
Part of full ownership of a computer is reserving the right to "lie" to any code running on it about its execution environment. This could be for examining malware, testing, reverse-engineering, or anything else. There are still plenty of people unconcerned with the economics of multi-tenant cloud hosting, DRM, or prevention of cheating in videogames.
- AgentME 7y ago
  There's benefits to a system where you have full control and visibility into everything that executes, and there's benefits to systems where that isn't true. I hope 100% open CPUs exist and that there continues to be a strong software ecosystem that works with open CPUs. But it's a fact of the matter that CPUs with stuff to support DRM exist, and we might as well see if we can get some strong pro-user / pro-privacy functionality out of it.

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.

dmatech 7y ago

Part of full ownership of a computer is reserving the right to "lie" to any code running on it about its execution environment. This could be for examining malware, testing, reverse-engineering, or anything else. There are still plenty of people unconcerned with the economics of multi-tenant cloud hosting, DRM, or prevention of cheating in videogames.

AgentME 7y ago
There's benefits to a system where you have full control and visibility into everything that executes, and there's benefits to systems where that isn't true. I hope 100% open CPUs exist and that there continues to be a strong software ecosystem that works with open CPUs. But it's a fact of the matter that CPUs with stuff to support DRM exist, and we might as well see if we can get some strong pro-user / pro-privacy functionality out of it.