Asylo: an open-source framework for confidential computing
cloudplatform.googleblog.com
cloudplatform.googleblog.com
It looks to me that while Asylo is agnostic about the specific TEE used, it is primarily targeted at Intel SGX [1]. Instead of having to trust Google to run your code correctly and not read your data, you'd have to trust Intel to manufacture a secure enclave and essentially bake in a private key that cannot be read. You could use the public key to encrypt your code and workload, and it would run in a part of the processor that Google presumably cannot access (or measure [2]).
A good further introduction might be this paper [3] (especially the diagram on page 2), or this answer [4].
I'll repeat my main concern with this system: you will reinforce Intel's position as 'feudal lord' in this model [5].
[1] https://github.com/google/asylo/tree/master/asylo/identity/s...
[2] https://arxiv.org/abs/1702.08719
[3] https://eprint.iacr.org/2016/086.pdf
[4] https://security.stackexchange.com/questions/175749/what-are...
https://venturebeat.com/2017/07/16/ibm-z-mainframe-brings-en...
The whole point of Asylo is to provide a hardware abstraction layer to make applications portable across different enclaves; it's the opposite of reinforcing Intel's position.
Yes, I shouldn't have conflated Asylo and SGX (or TEEs in general – where SGX is now dominant for the remote attestation model). The concern was with SGX, maybe even specifically to it being used together with other TEEs for ubiquitous DRM on consumer devices. Asylo could indeed drive competition in the case of remote attestation.
That’s exactly the level of abstraction that we’re looking to provide in Asylo. The parent post linked to the asylo/identity/sgx directory, which contains SGX-specific implementations of some of our higher-level identity abstractions [1]. For instance, “EnclaveAssertionGenerator” defines an interface for generating attestations bound to an enclave’s identity, and “sgx::LocalAssertionGenerator” (an internal construct to our framework) provides that functionality for SGX.
[1] https://github.com/google/asylo/tree/master/asylo/identity
My main concern is not "reinforcing Intel's position" --- it could just as well be AMD, or ARM, or any other relatively tiny group of hardware manufacturers; the point is that everyone else is giving up and handing the ultimate control over their computing devices and the software they run to a small group, and that is most doubleplus ungood.
https://www.gnu.org/philosophy/can-you-trust.en.html
https://en.wikipedia.org/wiki/Next-Generation_Secure_Computi...
In our view, trusted computing has applications well beyond DRM.
"Intel SGX is a set of central processing unit (CPU) instruction codes from Intel that allows user-level code to allocate private regions of memory, called enclaves, that are protected from processes running at higher privilege levels."
I still don't fully understand the security model of enclaves (for instance, the same wikipedia page also talks about modifying spectre to work against enclaves[2]).
[1]https://en.wikipedia.org/wiki/Software_Guard_Extensions [2]https://github.com/lsds/spectre-attack-sgx
(disclaimer: I work at Google, but obviously not on this)
You can find an overview of what enclaves are at https://asylo.dev/about/overview.html.
The security model of enclaves is as follows: Enclaves rely on the OS for their resource management/scheduling, however, the OS cannot compromise the enclave.
As to refactoring--it is really up to the developer. With sufficient POSIX support, an entire POSIX-compliant app can live inside an enclave. On the other hand, for security reasons, the developer may decide to refactor their application.
We started with C/C++ mostly because that's what we need for the bottom layer of a POSIX-like stack. For instance, to use OpenSSL we need to be able to build C and if we wanted to support, for instance, Python we would need to build its C language components. Some of the applications we want to target include Redis and SQLite and, again, there we need C and broad support for POSIX APIs. Ideally, those applications would build for Asylo out of the box, but we have some work to do to get that to work.
Going forward, we are very interested in broader language support. For instance, we are currently working on support for Go. Rust would also be interesting because it (potentially) offers an orthogonal set of security guarantees at compile time.
The Asylo framework has partial support for POSIX APIs and system calls. Each programming language implementation that implicitly depends on system calls in either its generated code or runtime environment will need to be inspected and tested. Languages that depend on unimplemented system calls or POSIX APIs to provide basic functionality will pose some challenge, depending on just which system it needs. If a runtime forwards calls to non-crucial system calls that Asylo does not currently support, then Asylo would need extending to satisfy the linker with at least a stub implementation that calls abort().
Asylo does provide support for basic I/O, sockets, and threads, so basic language functionality within Asylo should not be a significant challenge. We welcome any pull requests you might have to support your favorite language.
Developers using Asylo still must be concerned about writing buggy code. If you write past the end of a buffer with user data passed into the enclave, that code is still vulnerable. We haven’t fixed that part of the software development process.
Obvious disclaimer: currently working at Google on Asylo.
My question is built on the presumption that SGX is the only real TEE available right now.
Also, how is Google dealing with PRM/EPC memory limitations of SGX?
Specifically for attestation purposes, Asylo defines the EnclaveAssertionGenerator[1] and EnclaveAssertionVerifier[2] interfaces; these will need technology-specific implementations.
In this initial release we only support a simulated backend, for experimental development. We'll continue looking into specific TEE technologies going forward.
[1] https://github.com/google/asylo/blob/master/asylo/identity/e...
[2] https://github.com/google/asylo/blob/master/asylo/identity/e...
It's just my opinion. I know the meaning of the word Asylum, but as I explained below...it's the association that I get from it. It's like using the word Niggardly - even though the definition is not related to race, people don't use it because it just sounds wrong.
https://en.wiktionary.org/wiki/asylo
Asylum simply means a shelter or protection from danger.
[1] https://en.wiktionary.org/wiki/άσυλο [2] https://el.wiktionary.org/wiki/άσυλο In Greek
It's like if I said the word niggardly. The meaning is completely unrelated to race, but you're not going to say it.
"seeking political asylum" is a common use
Asylum can also mean a safe place - for example someone seeking asylum.