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
Dear Asylo developers,
I have searched (on your websites, blogs, etc) for a list of concrete threats that Asylo will protect against once it's ready for production and how it protects the enclave from those threats.
Asylo is designed to integrate applications with enclaves that provide confidentiality and integrity guarantees against the following threats:
Malicious or compromised administrator
Malicious or compromised tenant of a hypervisor
Malicious or compromised network
Compromised operating system
Compromised BIOS
I just wonder if there is a more precise answer and a list of techniques that you use to secure the enclave (e.g. ram encryption etc.)
Lastly, I wonder what the best practise is to get sensitive data + code into the enclave running in an untrusted environment. Building the enclave locally, uploading it to the untrusted vm and execute it and afterwards downloading the enclave again including the results? Is there a mechanism in the enclave to protect the user from man-in-the-middle attacks when communicating with the docker container over a port?
I apologize if there is an obvious answer to those questions that I have not found or understood.
Thank you so much and best regards,
Jan
The text was updated successfully, but these errors were encountered:
Dear Asylo developers,
I have searched (on your websites, blogs, etc) for a list of concrete threats that Asylo will protect against once it's ready for production and how it protects the enclave from those threats.
I know it's hard to say since there are so many possible threats, I found the following on https://asylo.dev/about/overview.html#security-backends
I just wonder if there is a more precise answer and a list of techniques that you use to secure the enclave (e.g. ram encryption etc.)
Lastly, I wonder what the best practise is to get sensitive data + code into the enclave running in an untrusted environment. Building the enclave locally, uploading it to the untrusted vm and execute it and afterwards downloading the enclave again including the results? Is there a mechanism in the enclave to protect the user from man-in-the-middle attacks when communicating with the docker container over a port?
I apologize if there is an obvious answer to those questions that I have not found or understood.
Thank you so much and best regards,
Jan
The text was updated successfully, but these errors were encountered: