I came across this paper (https://www.blackhat.com/docs/us-17/thursday/us-17-Swami-SGX-Remote-Attestation-Is-Not-Sufficient-wp... which said the following:
"Before an enclave can be instantiated on an SGX capable processor, it must first get an authorization token, called Launch Token, from Intel provided Launch Enclave. The Launch Enclave uses a combination of mrenclave, mrsigner, the attributes of the enclave and a white-list signed by Intel to decide whether to grant Launch Token or not. Once an enclave obtains a Launch Token, it can continue using it indefinitely—even when the policies of the Launch Enclave might get updated later on and deny access to Launch Token for that enclave! "
The sentence conveys as if the system could allow potentially "recalled" enclaves to continue to run on the System.
Is this true?
You can and should use a saved launch token for performance enhancement (https://software.intel.com/en-us/node/709000). But there are required approval of measurement and certificate. Please take a look at this early posting for more info (https://software.intel.com/en-us/forums/intel-software-guard-extensions-intel-sgx/topic/703602)
Believe the BlackHat paper is correct. Say your enclave had a vulnerability (which you didn't know at the time of deploying), but a malware managed to exploit that vulnerability. Later on, you blacklisted your vulnerable enclave in the hope that the malware will not be able to get the new launch token. But the malware can just copy the old launch token and manage to run the vulnerable enclave, even with the blacklist in place.
Hoang Nguyen, is this incorrect?
Just pointing out that the ideas presented in the BlackHat paper were not demonstrated by the author whom I personally spoke to. They refer to a technique from another paper (SGX-Step : A Practical Attack Framework for Precise Enclave Execution Control) that can perhaps be used to facilitate the attack, but it's not clear that such an attack could be easily carried out. For instance, if you limit the number of enclave threads to 1, it won't be possible to re-enter an enclave and reuse a previously saved state.
Browsing through SGX-Step paper, it seems to talk about side channel and page table control etc... Here's SGX-Step abstract:
Recent research convincingly demonstrated, however, that SGX’s strengthened adversary model also gives rise to to a new class of powerful, low-noise side-channel attacks leveraging first-rate control over hardware. These attacks commonly rely on frequent enclave preemptions to obtain fine-grained side-channel observations. A maximal temporal resolution is achieved when the victim state is measured after every instruction. Current state-of-the-art enclave execution control schemes, however, do not generally achieve such instruction-level granularity.
This paper presents SGX-Step, an open-source Linux kernel framework that allows an untrusted host process to configure APIC timer interrupts and track page table entries directly from user space. We contribute and evaluate an improved approach to single-step enclaved execution at instruction-level granularity, and we show how SGX-Step enables several new or improved attacks. Finally, we discuss its implications for the design of effective defense mechanisms.
Really apples and oranges... (Didn't SGX-Step paper came much later on than BlackHat? I was at SysTex but I don't remember the details now.)
Coming back to the question on launch token, I don't think the assertion in BH paper is incorrect.