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.
I do sympathise with this point of view and it's always going to be context dependent, but I'm reminded in these discussions of the success of the credit card companies. Everything about how credit cards work would be laughed out of the room by the average security researcher, and yet, they crushed all the other payment systems. Cards are textbook examples of worse is better, perfect is the enemy of the good and so on.
And of course at the heart of every credit card is a very small TEE. Not a general purpose computer, sure, but still a chip that can have bugs or be physically attacked. And it protects money! Yet the system works anyway.
Our industry could do a lot of good if it just embraced TEEs a lot more, even if they sometimes needed patching or even needed physical replacement. There's lots of ways to do defense in depth, or just accept the business costs during a degraded period.
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...
SGX hasn't been usable on the client side for years, it's only now sold into server SKUs. So I think that theory may have been falsified.
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.
I do sympathise with this point of view and it's always going to be context dependent, but I'm reminded in these discussions of the success of the credit card companies. Everything about how credit cards work would be laughed out of the room by the average security researcher, and yet, they crushed all the other payment systems. Cards are textbook examples of worse is better, perfect is the enemy of the good and so on.
And of course at the heart of every credit card is a very small TEE. Not a general purpose computer, sure, but still a chip that can have bugs or be physically attacked. And it protects money! Yet the system works anyway.
Our industry could do a lot of good if it just embraced TEEs a lot more, even if they sometimes needed patching or even needed physical replacement. There's lots of ways to do defense in depth, or just accept the business costs during a degraded period.
The important part is that physical attacks on credit card chips do not scale.