[MUSIC PLAYING]
DIONNA GLAZE: Hi.
Thanks for sharing your lunch time with me.
I'm going to tell you about this cool stuff
that we're working on, after I tell you why.
So some potential customers have shared with us
that there are some barriers for them moving their workloads
to a cloud instead of on Prem.
And the biggest three factors are regulation,
trust in companies, and compromise,
and what can happen to the data that
is on other people's machines.
I'm not going to talk too much about regulation.
Here we go.
It's the other button.
But I will tell you how we aim to solve problems
with trust and compromise with our open source framework.
All right, so by trust, I mean you are running your software
on other people's machines, and they
can be running arbitrary software
to manage those machines, and they can, unfortunately,
sometimes get compromised.
Not saying that happens at Google.
Now, beyond just the companies, there
can be individual administrators who
have access to these computers so that they can do their jobs.
And they can be compromised in one way or the other
through phishing, or they're overtly malicious.
Now, the compromised component is,
when you're running on these computers,
they can be subject to problems in, like, the Linux kernel.
Everybody running on Linux is open to these same problems.
There is also being able to break out of the DMA jail
from rogue peripherals, and to just go grab--
go snooping memory.
And that's not so great.
So when data is accessible on a machine,
it is also subject to a legal discovery.
So we consider that, also, as part of compromise factors
for confidential data.
So enclaves are two things in the abstract.
They are isolation for your execution and data,
and they are attestation.
I want to tell you a little bit about what that means.
So isolation is that the operating system, the BIOS,
hardware other than the CPU, is all outside of your trust
boundary.
It is not able to see any of your memory
or tamper with your execution at all.
In a typical process, the OS has full control over your process.
The BIOS can be tampered with.
The hardware can have access beyond what you want.
Right, and when this data is not even available to the kernel
and is only available to your enclave,
it is not subject to legal discovery.
The second component of an enclave is attestation.
And attestation aims to answer the question,
with cryptographic guarantees, that the software you're
talking to is really the software that you want
to be talking to, and that it is running on the hardware
that you expect to be giving you these Trusted Execution
Environment guarantees.
When you put these two things together,
you're able to make the following statement, that you
send secrets only to your software,
and only your software can read them.
And that's really important to a lot of potential customers
who want to move to Cloud, for a lot of reasons.
OK, so isolation, attestation are nice properties
to say that an enclave is in the abstract,
but unfortunately, that is not an industry standard.
And there are a lot of technologies
that market themselves as enclaves or Trusted Execution
Environments that don't give all aspects of isolation
and attestation that we really want.
And because it's too early to know
which one of these technologies is really
going to win in the marketplace, it's
nice to have your enclave applications be written
for an abstract notion of an enclave,
so that you can move around.
And that's what Asylo is.
Right?
It is a framework that abstracts over enclave technology
and notions of attestation so that you can easily
migrate between different Trusted Execution back ends.
And now, a really, really awesome cool thing
that is in Asylo is support for a POSIX-based programming.
Now, when you're in one of these Trusted Execution Environments,
you have that the OS is outside of your trusted computing
base, which means that you don't get to use it,
which means it's really hard to write software
in the typical way that people usually write software.
And now to talk a bit more about how the POSIX system works
in Asylo, I want to introduce my colleague, Chong Cai.
CHONG CAI: I'm going to briefly talk about the POSIX support
that Asylo provides.
So, as Dionna talked about earlier, when you're
inside an enclave, it provides security isolation
even from the operating system.
So we're having trouble for code running inside enclave
to access the resources that's usually provided
by the operating system.
So Asylo provides a POSIX layer to make user code get access
to them.
The way, so which includes how to access clock,
IO like readwrite, and other kinds of syscalls
that you normally want to access.
We implement them with security features added.
So normally, when an application makes a syscall,
it access the operating system for the operation.
But in enclave case, code running
is enclave is isolated from the operating system.
So that's not the option.
And we provide, Aslyo provides a POSIX layer,
which is an API level of implementation
for the syscalls.
So the user code that's running inside an enclave
does not need to know, OK, this code
is running inside the enclave, I need
to access the Asylo POSIX API.
They can just access exactly the syscall as user.
And Asylo POSIX layer would run that syscall and in some cases,
it exits the enclave and delegates
the syscall to the operating system with security features
added.
The goal for Asylo POSIX layer is
to provide exactly the same behavior as if it's on a host.
The user code does not need to know it's
running inside the enclave.
They say they can call exactly the same syscall as they would
on the host, and they should expect
exactly the same behavior.
The way we do that is, for example,
for non-sensitive operations, it may just exit the enclave
and delegate the call to the host.
And there are some other interesting examples
that we provide to achieve this goal.
For example, signals.
When somebody registers a handler inside an enclave,
the Asylo POSIX layer saves that handler inside the enclave,
then it exits the enclave, register a handler on a host.
When that signal arrives, the handler on the host
is invoked, which invokes an entry
point to enter the enclave and invoke
the corresponding handler that's registering inside the enclave.
So the user can expect the same behavior
they register handler inside the enclave
and when the signal arrives, their handlers should be
[INAUDIBLE].
Another interesting example is a fork.
Fork is a syscall that limits users
to create a process that's exact the same as a parent.
However, enclaves are not clonable for security reason.
So, in order to support that, we provide
duplication and encryption of the enclave states.
So we load a new enclave.
We encrypt the old enclave data and restore
that in the new enclave.
The security features for fork is not fully implemented yet.
We're working actively to support secure fork.
And even though we are providing security features
for the syscalls that we provide,
sometimes it's not impossible to make it fully secure.
On our website aslylo.dev, we have
documentations fully detailed of syscalls we provide.
And if there is any possible security concern or issues
it may have, the user code should investigate into that
before they make syscalls.
And so what do we have support right now for Asylo POSIX
layer, is we have provide enough POSIX layer support
to run a fully featured GRPC.
We can also run a full feature latest open source Redis.
I will do a quick demo later to show how we can do that.
And in both cases, we don't need to make any source change
to either of them.
We can just to pull exactly the same code from the GitHub
and run that inside an enclave with Asylo.
So you're welcome to check out our website aslylo.dev
if you're interested for updates and documentations for Asylo.
And our open source project is at github.com/google/asylo.
Can check it out if you're interested.
And I'm going to do a quick demo to show how you can
run Redis inside an enclave.
So what do you need to run and use application
like Redis inside an enclave is a workspace.
So first you need a workspace file.
Sorry, the color is probably a little bit hard to read.
So, right here, you want to import--
somehow it's not showing the whole thing.
But you want to import Asylo right here.
Asylo.3.4 is the latest release that we have.
And, of course, you want to import Redis,
if that's the use application you want to be build.
The latest open source, which is Redis 5.0.4.
Asylo provides a build file in Asylo code base
that builds Redis with Bazel, which is the Google build tool.
And, other than that, you need a dot Bazel RC file.
This basically tells Bazel what tool chain,
what cross tool to use, and what the build configs are.
This is exactly the same file copied from Asylo GitHub.
We don't need to make any changes.
Finally, the last thing you need is a build target
to tell Bazel what do you want to build.
So here we provide an application wrapper,
which wraps the user main function
entrance in the trusted part of the code, the raw method.
So the only thing we needed is to wrap
that in cc enclave binary, which is our application wrapper.
You give it a name.
And you put what you want to build as a build target
in the dependencies.
So here Redis main is a target that runs the Redis server.
So that's everything you need.
Now, we can just build application wrapper.
So Bazel is the Google build tool.
So we give it a config, which is enc sim.
Tells it to build the targets in simulated environment.
And Asylo Redis is the target that we just add for cc enclave
binary.
Here it is.
You can see that it builds very quickly.
It's speakers I have configured it
because we don't have enough time to build it right here.
OK, so once you have it built, we
are ready to run the binary, which is placed in the Bazel
bin, and this is the binary we just built.
And we run a binary, we can see that Redis server is running,
is up.
It's running inside the enclave.
Here we have a warning about current maximum
open file is 1,024.
That's because this is the current maximum file
descriptors we allow with Asylo inside an enclave.
And so now it's ready to accept connections.
So in a different terminal, we run Redis client
to connect to the server.
We can pin it and we can set whatever key and a value.
And I'll get it just to like normally you would use Redis.
OK, that's everything I have for the demo.
Is there any questions?
SPEAKER: Thank you, Chong.
CHONG CAI: Thank you.