You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I am somewhat skeptical of this mitigation for TEEs in the case where the the cloud is the TEE operator. In that case, distributing coordinators doesn't help because the keys have to make it into the TEE at some point (see 1.9). I think we should mention that here because in practice, I believe that distributing coordinators across clouds is not super practical for TEE deployments.
My concern here would be if an attacker controls the cloud provider and the first/delegated party, and all coordinators run on that cloud provider, the attacker can construct the entire private key and decrypt the data.
As for getting the key into the TEE, I believe we are assuming a secure communication channel between the coordinator and the TEE (i.e. the TEE has an internal private key with an externally known public key, allowing the coordinator to send in encrypted data that even the TEE operator couldn't see.)
Ah, sorry I missed this assumption. What you have makes sense in that case, although this is a difference in how the ARA deployment works (which does put root of trust in the cloud operator). I think as long as this is an optional mitigation I am fine with it.
Originally posted by @csharrison in #14 (comment)
The text was updated successfully, but these errors were encountered: