SGX is one of those things where 95% of the time the actual motivating use case is evil DRM and frankly you have a very well motivated world of hackers desiring to break it for all sorts of different reasons. My gut feeling is that it fulfills a purpose of making a mid level manager somewhere get a bonus, potentially marginally increase the efficacy of a DRM scheme (e.g. blue ray video -- all official players require windows and run on the TEE) and any actual "good" use cases are somewhere along the lines of good incidental marketing, including the cloud computing ones...
It's just another spin on a very old debate in computer security: nothing is perfect, so where do you draw the line?
SGX was designed from the start on the assumption that there would be bugs or people would find clever unanticipated attacks, so it has a games console-like resealing procedure that lets the platform be fixed in place via firmware and microcode updates. SGX pre-dated Spectre, so those assumption were proven true, and the platform was resealed a bunch of times.
Is this a success or failure? The article takes it as obvious that it's a failure. But if you judge a general purpose computing system by the standard of "did it ever need to be patched" then there has never been a success. Clearly that can't be where the line is drawn.
An alternative place to draw the line might be whether the system provides the needed guarantees when fully patched and there are no known bugs. According to this standard, SGX is a mixed bag. The original SGX implementation fully took hardware attacks into account including on DRAM chips. Later versions were deliberately weakened to try and find product-market fit, as developers were unable to handle a programming model more complex than "boot an entire VM with our app inside it" (and frankly even then weren't able to get it right, I've seen so many botched RA implementations). But you hit hard physical limits: making untrusted DRAM secure trades off against making it large. Developers reject anything that requires them to conserve RAM, and so the original SGX design died there.
This was arguably not Intel's fault. A few hundred megabytes of RAM was sufficient to achieve many important security goals with the original SGX model, but developers just don't care enough to do learn a new programming model or paradigm. It's easier to just trust the cloud providers to not peek, like everyone else does.
AMD SEV ended up getting more support from the cloud vendors because it required less work from developers, but AMD's implementation was much worse than Intel's was and spent much of the time I worked on this stuff in an entirely broken and un-resealable state.
SGX is one of those technologies that was maybe ahead of its time. Privacy tech in general is a hard sell because there are very few scandals where tech firms leak data, so blocking that possibility via more programmer effort was a hard sell in a world where skilled programming time was scarce. Maybe AI changes the game here, hard to say.
We've had a similar conversation before and I think we're on the same page in terms of the facts, but we differ on the framing. So here's mine:
I don't think the article is saying "don't use TEEs", more like "don't rely on TEEs". If you have a system that's already secure and you run it inside a TEE, it's an extra layer of defense in depth. Great. If you have a system that's only secure because it's in a TEE, then you don't have very much security at all. If a forged attestation from an arbitrary machine breaks your entire security model, you're in especially hot water.
It is obvious to us to just "don't do that", but there seems to be a general lack of awareness of the true security properties of TEEs, and people keep building bad systems on top of them. I think the article is doing a good job of communicating the actual security properties.
SGX is one of those things where 95% of the time the actual motivating use case is evil DRM and frankly you have a very well motivated world of hackers desiring to break it for all sorts of different reasons. My gut feeling is that it fulfills a purpose of making a mid level manager somewhere get a bonus, potentially marginally increase the efficacy of a DRM scheme (e.g. blue ray video -- all official players require windows and run on the TEE) and any actual "good" use cases are somewhere along the lines of good incidental marketing, including the cloud computing ones...
It's just another spin on a very old debate in computer security: nothing is perfect, so where do you draw the line?
SGX was designed from the start on the assumption that there would be bugs or people would find clever unanticipated attacks, so it has a games console-like resealing procedure that lets the platform be fixed in place via firmware and microcode updates. SGX pre-dated Spectre, so those assumption were proven true, and the platform was resealed a bunch of times.
Is this a success or failure? The article takes it as obvious that it's a failure. But if you judge a general purpose computing system by the standard of "did it ever need to be patched" then there has never been a success. Clearly that can't be where the line is drawn.
An alternative place to draw the line might be whether the system provides the needed guarantees when fully patched and there are no known bugs. According to this standard, SGX is a mixed bag. The original SGX implementation fully took hardware attacks into account including on DRAM chips. Later versions were deliberately weakened to try and find product-market fit, as developers were unable to handle a programming model more complex than "boot an entire VM with our app inside it" (and frankly even then weren't able to get it right, I've seen so many botched RA implementations). But you hit hard physical limits: making untrusted DRAM secure trades off against making it large. Developers reject anything that requires them to conserve RAM, and so the original SGX design died there.
This was arguably not Intel's fault. A few hundred megabytes of RAM was sufficient to achieve many important security goals with the original SGX model, but developers just don't care enough to do learn a new programming model or paradigm. It's easier to just trust the cloud providers to not peek, like everyone else does.
AMD SEV ended up getting more support from the cloud vendors because it required less work from developers, but AMD's implementation was much worse than Intel's was and spent much of the time I worked on this stuff in an entirely broken and un-resealable state.
SGX is one of those technologies that was maybe ahead of its time. Privacy tech in general is a hard sell because there are very few scandals where tech firms leak data, so blocking that possibility via more programmer effort was a hard sell in a world where skilled programming time was scarce. Maybe AI changes the game here, hard to say.
We've had a similar conversation before and I think we're on the same page in terms of the facts, but we differ on the framing. So here's mine:
I don't think the article is saying "don't use TEEs", more like "don't rely on TEEs". If you have a system that's already secure and you run it inside a TEE, it's an extra layer of defense in depth. Great. If you have a system that's only secure because it's in a TEE, then you don't have very much security at all. If a forged attestation from an arbitrary machine breaks your entire security model, you're in especially hot water.
It is obvious to us to just "don't do that", but there seems to be a general lack of awareness of the true security properties of TEEs, and people keep building bad systems on top of them. I think the article is doing a good job of communicating the actual security properties.