veracruz
veracruz copied to clipboard
veracruz-project
Change enclave shutdown conditions
Requested feature Change enclave shutdown conditions to make the shutdown command more secure. A way to do that would be to specify who can issue that command or shutdown the enclave after a timeout. Solutions are discussed below.
Motivation At the moment any party can shutdown the enclave and terminate the computation, hence a malicious party could deny other parties access to the platform. Moreover, it could abuse the system by fetching the results first then shutting down the enclave before other parties get the results. A solution for this specific problem is to automatically shutdown after a timeout. This doesn't guarantee that every party gets the results, but the enclave can't run forever. There might be other forms of abuse. Cf. discussion below.
We cannot predict if a party read the result they need, as it may want to read several files in the FS. Hence you cannot know the exact time, implicitly, when a party has not intention to access the Veracruz instance any further.
Assume we have a list of parties can request shutdown, (either all parties or some specified in policy). I think the question is if we receive one shutdown request, what do we do?
- shutdown immediately or potentially after a delay, This will have the problem you mentioned that a malicious party may purposely denies all future access to the instance.
- wait for all
shutdownrequests. Here, an pale instance might run forever due to a missingshutdown, until the cloud or a FaaS infrastructure terminates the isolate.
I do not have a preference myself, and I think both methods are secured based on the assumptions that (1) Isolate should not be compromised; (2) Veracruz will not actively leak information to the outside.
We should definitely terminate the enclave after a timeout: there will always be ways for malicious parties to deny other parties access to the platform but we have to protect the platform against DoS as well, we can't keep the enclave running for ever. So how about a timeout and a shutdown right, both specified in the policy file?
In this case, I do not think we even need to timeout, we just terminate on a single request. Also not sure we can get reliable time in all isolates.
In this case, I do not think we even need to timeout, we just terminate on a single request.
A timeout would mitigate DoS attacks without preventing them completely.
Also not sure we can get reliable time in all isolates.
I was considering to have the server terminate the enclave. That's the direction I'm following in https://github.com/veracruz-project/veracruz/pull/394. The server will always be able to perform DoS attacks on the enclave but that's part of our threat model.
As of now the shutdown condition is still the same: any client can request immediate enclave shutdown. I suggest to implement a timeout on the server side that kills the enclave some time after the computation is finished. The server isn't part of the TCB but is already trusted to correctly handle the infrastructure (spawn the enclaves). That would protect clients from each other as discussed above. This mechanism could be combined with the consensus mechanism that we used previously.