4 ms·

There have been several attacks like this already (and more likely more to come). The nice thing about the SGX design is many of these issues can be fixed immed

There have been several attacks like this already (and more likely more to come). The nice thing about the SGX design is many of these issues can be fixed immediately with a microcode update. Now if an attack is announced that can't be fixed with a microcode update that is another story :). In general, protecting against these kinds of attacks for any enclave is a hard problem, but it is an active area of research and there are already research proposals for more side channel resilient enclave designs (e.g. see the Keystone project from Berkeley). I expect some of these mitigations will be incorporated into future iterations of SGX, but it will take time.

mmm_grayons 6y ago
You're right, and the idea of a secure enclave is not an inherently bad one. What is bad is treating it as an unassailable fortress, as in signal's address book feature. There's a difference between using it to make critical parts of existing computations more secure and using it to do stuff one wouldn't otherwise do.
- dane-pgp 6y ago
  > You're right, and the idea of a secure enclave is not an inherently bad one. Maybe it is when you're trusting private keys and proprietary technology controlled by a single entity that may be subject to commercial and political pressures that make their motives not aligned to yours.
  - anonymousDan 6y ago
    I hope you're not typing that on an Intel processor :)
    - dane-pgp 6y ago
      $ grep vendor_id /proc/cpuinfo vendor_id : AuthenticAMD
- AlexCoventry 6y ago
  > What is bad is treating it as an unassailable fortress It's also a pretty bad architecture/design failure, for a TEE to share computational resources with untrusted processes. I heard the decision to do so at Intel was due to marketing considerations outweighing the security concerns: Customers didn't want computational resources going fallow for the sake of security. I'm skeptical about whether a truly trustworthy TEE is possible, but it seems even less likely, given SGX's architecture.
pstrateman 6y ago
For signal this issue actually cannot be fixed. One failure is a permanent leak of the profile and contact information for everybody with a weak pin (which is probably virtually everybody).
- anonymousDan 6y ago
  Yes that's a fair point, of course anyone who is using this in production now will be impacted. I was more highlighting that it is a recoverable error in terms of being able to use existing SGX hardware in future.

mmm_grayons 6y ago

You're right, and the idea of a secure enclave is not an inherently bad one. What is bad is treating it as an unassailable fortress, as in signal's address book feature. There's a difference between using it to make critical parts of existing computations more secure and using it to do stuff one wouldn't otherwise do.

dane-pgp 6y ago
> You're right, and the idea of a secure enclave is not an inherently bad one. Maybe it is when you're trusting private keys and proprietary technology controlled by a single entity that may be subject to commercial and political pressures that make their motives not aligned to yours.
- anonymousDan 6y ago
  I hope you're not typing that on an Intel processor :)
  - dane-pgp 6y ago
    $ grep vendor_id /proc/cpuinfo vendor_id : AuthenticAMD
AlexCoventry 6y ago
> What is bad is treating it as an unassailable fortress It's also a pretty bad architecture/design failure, for a TEE to share computational resources with untrusted processes. I heard the decision to do so at Intel was due to marketing considerations outweighing the security concerns: Customers didn't want computational resources going fallow for the sake of security. I'm skeptical about whether a truly trustworthy TEE is possible, but it seems even less likely, given SGX's architecture.

pstrateman 6y ago

For signal this issue actually cannot be fixed. One failure is a permanent leak of the profile and contact information for everybody with a weak pin (which is probably virtually everybody).

anonymousDan 6y ago
Yes that's a fair point, of course anyone who is using this in production now will be impacted. I was more highlighting that it is a recoverable error in terms of being able to use existing SGX hardware in future.