Nobody that knows what they are talking about is making claims like "system x does not have any security holes". It's all about threat models, probabilities, and ultimately tradeoffs.
Consider a scenario where you need to compute some a function of secret data, but unfortunately that function isn't of the shape that any CC- or FIPS-certified solution (HSM or otherwise) supports out of the box, and ordering one to be built against your specifications would eat through your budget for the next 15-20 years. Your choices roughly are:
- Use a HSM anyway, but only use it to encrypt the data (or its encryption key), and have your application servers decrypt, evaluate the function, return the result and delete the data from memory every time they need to? Then you're arguably just doing fancy encryption at rest.
- Use enclaves. Even though they are much less hardened than a CC certified and audited solution, let's say you assign some probability to the event that somebody compromises them and burns the corresponding 0-day on you. Would you assert that that probability is 1? If not, why not still do it?
And you can still store the actual data encryption keys in a HSM and any higher-level features that it does support! In fact, if you use your HSM in a pretty low-level way (i.e. with an interface like "decrypt data x using key k"), access to the HSM needs to be guarded carefully, and enclaves can be a candidate for that.
- Don't evaluate the function, or possibly don't even store the data in the first place. The only problem with enclaves, in my view, is if they would make people disregard this option due to the misunderstanding that "enclaves are perfectly secure". (This applies to any security technology, but the fancier/more magical a solution looks like or is marketed as, the higher the temptation.)
- Do none of the above, but still store the data and evaluate the function on your systems. This is arguably the norm today in most organizations.
Consider a scenario where you need to compute some a function of secret data, but unfortunately that function isn't of the shape that any CC- or FIPS-certified solution (HSM or otherwise) supports out of the box, and ordering one to be built against your specifications would eat through your budget for the next 15-20 years. Your choices roughly are:
- Use a HSM anyway, but only use it to encrypt the data (or its encryption key), and have your application servers decrypt, evaluate the function, return the result and delete the data from memory every time they need to? Then you're arguably just doing fancy encryption at rest.
- Use enclaves. Even though they are much less hardened than a CC certified and audited solution, let's say you assign some probability to the event that somebody compromises them and burns the corresponding 0-day on you. Would you assert that that probability is 1? If not, why not still do it?
And you can still store the actual data encryption keys in a HSM and any higher-level features that it does support! In fact, if you use your HSM in a pretty low-level way (i.e. with an interface like "decrypt data x using key k"), access to the HSM needs to be guarded carefully, and enclaves can be a candidate for that.
- Don't evaluate the function, or possibly don't even store the data in the first place. The only problem with enclaves, in my view, is if they would make people disregard this option due to the misunderstanding that "enclaves are perfectly secure". (This applies to any security technology, but the fancier/more magical a solution looks like or is marketed as, the higher the temptation.)
- Do none of the above, but still store the data and evaluate the function on your systems. This is arguably the norm today in most organizations.