4 ms·

Amazon has their Nitro secure enclave system that's pretty easy to use. IIUC its based on isolating the code that runs it and in it onto one core set aside for

Amazon has their Nitro secure enclave system that's pretty easy to use. IIUC its based on isolating the code that runs it and in it onto one core set aside for just that, possibly just when it's needed. Having the SE be easy to use is a key thing. Not that the Nitro approach extends well to consumer hardware (it doesn't).

mike_hearn 2y ago
The problem with Nitro is that a TEE doesn't really work if the adversary makes your CPUs. SGX works, conceptually, because of the division of labor between Intel and the people running the machines: 1. Intel can't break into your enclave even by subverting SGX, because it doesn't have access to the computers (isn't your cloud operator or network admin). 2. The people with access to the computer can't break into your enclave, because SGX blocks everyone except the enclave owner and Intel. With Nitro, Apple's approach and a few others the logic becomes: 1. Amazon can't break into your enclave even if Nitro has a back door because Amazon don't have acces.... oh, wait. SGX is conceptually sound because subverting it at the design level requires the CPU maker and the cloud operator to team up against you. This could happen, especially if you use a US cloud and the US government gets involved, but the bar is much higher. And of course you can always choose to run the hardware somewhere the USG can't get at it, requiring a coalition of those two governments or providers
- cryptonector 2y ago
  Governments as threats... that's way beyond what people who want DRM consider within their threat models. TFA was about TPM not being relevant to DRM. For most public cloud users having to trust the cloud operator is just a fact of life. Even if the SE were strong up to but excluding collaboration of the CPU vendor and the cloud operator, the user would have to run most if not all of their code in the SE, which is one thing the SEs invariably can't do.

mike_hearn 2y ago

The problem with Nitro is that a TEE doesn't really work if the adversary makes your CPUs. SGX works, conceptually, because of the division of labor between Intel and the people running the machines: 1. Intel can't break into your enclave even by subverting SGX, because it doesn't have access to the computers (isn't your cloud operator or network admin). 2. The people with access to the computer can't break into your enclave, because SGX blocks everyone except the enclave owner and Intel. With Nitro, Apple's approach and a few others the logic becomes: 1. Amazon can't break into your enclave even if Nitro has a back door because Amazon don't have acces.... oh, wait. SGX is conceptually sound because subverting it at the design level requires the CPU maker and the cloud operator to team up against you. This could happen, especially if you use a US cloud and the US government gets involved, but the bar is much higher. And of course you can always choose to run the hardware somewhere the USG can't get at it, requiring a coalition of those two governments or providers

cryptonector 2y ago
Governments as threats... that's way beyond what people who want DRM consider within their threat models. TFA was about TPM not being relevant to DRM. For most public cloud users having to trust the cloud operator is just a fact of life. Even if the SE were strong up to but excluding collaboration of the CPU vendor and the cloud operator, the user would have to run most if not all of their code in the SE, which is one thing the SEs invariably can't do.