Where can I find SGX threat Model? I want the exact threat model stated by Intel. I looked at "SGX explained" document and it pointed to SGX threat model several times but not very well organized. I have a question about where does SGX stand for flash memory containing bios and firmware? how about ME (Intel Management Engine)? are they covered by Intel SGX threat model?
Thanks for your prompt reply.
Actually, my question is that in https://www.blackhat.com/docs/us-16/materials/us-16-Aumasson-SGX-Secure-Enclaves-In-Practice-Security-And-Crypto-Review.pdf, it is mentioned that SGX protects from BIOS, ME, etc. however, I can't find if SGX protects BIOS from getting compromised or if it gets tampered somehow SGX by monitoring the BIOS, can detect it?
In "SGX explained", it is mentioned that details of the ME are not available and thus we don't know what is happening. I want to know if there is any more information about the question of how BIOS, driver, ME, etc. are protected under SGX?
thanks once again.
Hi Meysam, I hope this post finds your week going well.
Let me see if I can provide some overall illumination to your question until we get a more official response from inside of Intel.
In the largest context possible the SGX threat model is to provide integrity and confidentiality protections for data and code that is operating on that data in the face of an IAGO threat environment. The objective of the SGX security architecture is to provide a protected region of memory that can only be operated on by the processor when running in enclave mode. The security guarantees are designed to be effective even in the face of a BIOS, ring 0 or hypervisor compromise.
Presumably the security guarantees would even be in effect if there was a compromise of the Management Engine (ME) or Baseboard Management Controller (BMC) architectures. Only Intel can answer these last questions definitively and they are unlikely to discuss anything surrounding these issues.
More information on the SGX/IAGO threat model can be found here.
This threat model is actually the direct reciprocal of what you are questioning. SGX does not convey any security guarantees or protections to the BIOS, drivers, ME, BMC or the operating system at large. It's purpose is to protect a limited area of code and data from security compromises that may be induced in these system components.
I found your question somewhat interesting since we have done extensive work in this area. We were active in SGX development even before hardware was available. It was apparent to us at that time that the challenge to SGX viability was going to be the need to conduct partitioning of applications in order to place security sensitive code and data in an enclave. The economics of software development and security virtually guaranteed that such practices would not be undertaken.
As a result we focused on a model where SGX could be used to guarantee that the surrounding operating system or container environment was in a known state. In essence we were focused on inverting the SGX security model to achieve something similar to what you are questioning, ie. the integrity of the platform writ large.
The system involved a modeling engine in an SGX enclave that introspected kernel based Turing events (actor/subject) interactions. The OS exported the event parameters for a context of execution (COE) into the enclave based modeling engine and then put the process requesting the event to sleep. The enclave modeling engine made a decision on the validity of the requested event and set a status bit in the task control structure of the process indicating the validity of the event and then woke the process up. We built a custom Linux Security Module that inspected the status bit and allowed fine grained security controls to be implemented on the COE.
This process provided a model where nothing could occur on the platform unless it was approved by the SGX protected engine. Since, ostensibly, nothing on the platform could interfere with the SGX based modeling engine, the integrity of the platform could not be compromised without first compromising SGX integrity guarantees.
All of this was particularly interesting in light of the Core2 speculation vulnerabilities. These obviously need adversarial code on the platform, that by definition cannot be executed if it does not match the behavioral trajectory map that enjoys SGX based protections.
Unfortunately, for SGX, no one ever seemed to be able to wrap their heads around the implications of this architecture. Instead, security economics drove the SGX market to a model of fat enclaves that run unmodified applications or interpreters in enclave context, and now ultimately to the pinnacle of the technologies decline, where the integrity covenants have been removed from the hardware (Icelake) in order to make this model possible.
We could certainly sit around the lake with a bottle of single-malt and argue about all of this. However, one only needs to look to Oakland's paper that examined the security posture of Microsoft's Haven project which concluded that directed side channel attacks were devastating to shield architectures, to appreciate the implications of the trajectory that SGX is on. This should be particularly sobering in the face of the fact that the side-channel attacks have become much more elegant since those papers were written.
Long story short, SGX doesn't protect anything outside of code and data in initialized enclaves, unless one is clever and perhaps a bit unorthodox in their approach to using the technology.
Anyone who can tote a good bottle of single-malt is welcome to our lake place in the glacial moraine country of West-Central Minnesota if they want to argue about any of this. I've adopted a resolution to not argue about technology but will reconsider if the single-malt is suitably old.
Hopefully all of this is helpful to your investigation, we now return you to your previous programming.
Best wishes for a productive remainder of the week.
Hello Dr. Greg and Jesus,
Dr. Greg, Thank you so much for your informative response. So my takeaway from your answer is that SGX doesn't have any extra protection for BIOS rather than a standard Intel CPU, and SGX is as vulnerable to some attacks like https://www.blackhat.com/presentations/bh-usa-09/WOJTCZUK/BHUSA09-Wojtczuk-AtkIntelBios-SLIDES.pdf as an Intel non-SGX CPU is? The same as drivers and ME. However, SGX protects code and data from compromised BIOS or ME drivers that want to make unauthorized access to EPC? (as pointed out in this presentation https://www.blackhat.com/docs/us-16/materials/us-16-Aumasson-SGX-Secure-Enclaves-In-Practice-Security-And-Crypto-Review.pdf).
Please correct me if I am wrong. And once again, thank you, Dr. Greg and Jesus, for all your help.
Once again Dr. Greg provides a great answer. Intel does not provide a more specific "thread model" than what you have seen. In short, Intel SGX secures the code and data that is within it's enclaves even if those system components you mentioned are compromised. The monitoring and protection of those components is beyond the scope of Intel SGX.
That article you referenced was written in 2009. I cannot say for sure but it is possible that the gaps they exploit have been closed in the past 11 years.
The first part of your statement,"SGX doesn't have any extra protection for BIOS rather than a standard Intel CPU," is true. SGX does not protect BIOS. However, the second part of your statement is not necessarily true: "SGX is as vulnerable to some attacks like.." As stated earlier, SGX protects your code and data even if your BIOS and other system components are compromised. However, no security technology is perfect....