
Asylo: an open-source framework for confidential computing - nealmueller
https://cloudplatform.googleblog.com/2018/05/Introducing-Asylo-an-open-source-framework-for-confidential-computing.html
======
Confiks
"Confidential computing" might seem to refer to homomorphic encryption, but
has nothing to do with it in its usage here. After searching around a bit, I
suspect that Microsoft Azure first used it in 2017 to refer to code running
within a trusted enclave.

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...](https://github.com/google/asylo/tree/master/asylo/identity/sgx)

[2] [https://arxiv.org/abs/1702.08719](https://arxiv.org/abs/1702.08719)

[3]
[https://eprint.iacr.org/2016/086.pdf](https://eprint.iacr.org/2016/086.pdf)

[4] [https://security.stackexchange.com/questions/175749/what-
are...](https://security.stackexchange.com/questions/175749/what-are-the-
functional-similarity-and-difference-between-tpm-and-sgx-in-trust-c)

[5]
[https://news.ycombinator.com/item?id=15936121](https://news.ycombinator.com/item?id=15936121)

~~~
tptacek
Within 10 years every mainstream computing hardware environment will have some
kind of TEE. They already exist on the iPhone (the SEP), Google's Android
phones (the ARM TEE), upcoming high-end ARM processors in general (I think
they were calling it "CryptoIsland"?), high-end Intel processors (SGX) and
high-end AMD processors (SEV).

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.

~~~
Confiks
> 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.

~~~
jjoergensen
Would I need a commercial Intel license to use it for Intel SGX? I ask because
they don't seem to hand out the licenses to everyone.
[https://software.intel.com/en-us/sgx/commercial-use-
license-...](https://software.intel.com/en-us/sgx/commercial-use-license-
request) [https://software.intel.com/en-us/forums/intel-software-
guard...](https://software.intel.com/en-us/forums/intel-software-guard-
extensions-intel-sgx/topic/759356)

------
userbinator
Make no mistake: this is nothing more than the old "treacherous computing"
that RMS warned about a long time ago, but coming back in new clothes, and is
going to be used the most by DRM and other user-hostile applications. They're
just trying to sneak it past everyone under the guise of "security" and other
ostensibly-somewhat-friendly uses, but don't be fooled.

[https://www.gnu.org/philosophy/can-you-
trust.en.html](https://www.gnu.org/philosophy/can-you-trust.en.html)

[https://en.wikipedia.org/wiki/Next-
Generation_Secure_Computi...](https://en.wikipedia.org/wiki/Next-
Generation_Secure_Computing_Base)

~~~
bluegate010
Many of us on the Asylo team share your reservations about DRM. However, the
capability to run software in a not-entirely-trustworthy environment leads to
many positive possibilities. For instance, you could imagine a world in which
customers didn’t have to trust their cloud vendor or worry about their data
falling into unauthorized hands. Or you could implement chat applications
which can prove to you that your communications really are being encrypted
end-to-end.

In our view, trusted computing has applications well beyond DRM.

------
colonelxc
The main TEE wikipedia article wasn't very informative for me (about as high
level as this blog post). Looking through links off of that brought me to
Intel's "Software Guard Extensions" wikipedia[1] article, which actually
defines enclaves:

"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](https://en.wikipedia.org/wiki/Software_Guard_Extensions)
[2][https://github.com/lsds/spectre-attack-
sgx](https://github.com/lsds/spectre-attack-sgx)

(disclaimer: I work at Google, but obviously not on this)

~~~
savagaon
Disclaimer: I am from the Asylo team.

You can find an overview of what enclaves are at
[https://asylo.dev/about/overview.html](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.

~~~
option_greek
Is it possible to write applications in languages other than C/Cpp ? Even with
Cpp, it appears from the examples that this seems more about handling specific
secure data and seem to rely on special data structures. How do we convert
existing applications to take advantage of Asylo ? Does it involve moving the
sensitive parts to a enclave app and communicating with it from normal one ?

~~~
matthewgingell
Disclaimer: I work on the Asylo Team

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.

~~~
option_greek
Makes sense. Eagerly waiting for NodeJS and Mono to be recompiled using Asylo.
Do you foresee additional complexity in supporting managed languages ? I'm
guessing a mono program with base recompiled to Asylo would be more secure
than using SecureString in C#.

~~~
deeglaze
Disclaimer: I am from the Asylo team

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.

------
stenioaraujo
This is really promising. The use of enclave is strongly chained to its
Hardware. Having a Framework with a plugin-like architecture definitely helps.
I may be wrong, but I have the impression that the development of TEE within
Virtual Machines and Containers is still in its early stages. I am looking
forward to see how Asylo will help on this.

------
robododo
Does this all hinge on EPID? So will cloud workloads have to phone home to
Intel for assertions to be satisfied?

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?

~~~
bluegate010
Asylo is not tied to EPID; the framework aims to abstract away any unique
behavior specific to TEE implementations, and provide a common backend
interface that developers can code against. The goal is to allow developers to
easily migrate their apps between backends with little to no source-code
changes.

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...](https://github.com/google/asylo/blob/master/asylo/identity/enclave_assertion_generator.h)

[2]
[https://github.com/google/asylo/blob/master/asylo/identity/e...](https://github.com/google/asylo/blob/master/asylo/identity/enclave_assertion_verifier.h)

------
option_greek
This is very exciting. May be this can hold the fort till fully homomorphic
computing becomes a reality.

------
alexnewman
I don’t get why people trust Secure Enclave it calls home over tls and dns for
ra. Certainly tls can be broken by state actors.

------
hungerstrike
The name doesn’t inspire confidence to me. Too close to Asylum, but I guess
they’re going for “a silo”.

 _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.

~~~
gschier
I think asylum is exactly what they mean. Asylo is the dative singular of
asȳlum according to Wiktionary:

[https://en.wiktionary.org/wiki/asylo](https://en.wiktionary.org/wiki/asylo)

Asylum simply means a shelter or protection from danger.

~~~
geospeck
Most likely they mean άσυλο[1][2] It has many meanings one of them is "safe
place" too.

[1]
[https://en.wiktionary.org/wiki/άσυλο](https://en.wiktionary.org/wiki/άσυλο)
[2]
[https://el.wiktionary.org/wiki/άσυλο](https://el.wiktionary.org/wiki/άσυλο)
In Greek

