Confidential Computing

>> All right.
Good morning everyone. Thank you for coming to the confidential
computing session. So, the session is all about security and
privacy for the Cloud. So, it's great to have you here, and we have a very, very exciting group of speakers. The list of achievements and the awards that they
have is so big that I had to print a page of paper
just to remind myself. So, I think it's going to
be an exciting session. The first speaker is
Mark Russinovich. Mark is the Chief Technology
Officer for Azure. He's an expert on Distributed
Systems, Operating Systems. He has the pleasure
and the responsibility of running one of
the largest Distributed Systems ever built by mankind. So, it's a tough job. Mark is also an author
of several books. He has ran startups. So, he has a very broad range of experience and he's going to tell us about Azure
confidential computing. >> Yeah, and we
found out yesterday Donald hasn't read my book. >> I was going to say I'm
putting it on my reading list. >> Okay, good.
Good morning everybody. So, this morning I'm
going to talk to you a little bit about what we call confidential computing
in our vision at Microsoft in Azure, specifically with MSR, on how this technology
is going to evolve, and eventually I think become standard for
all computation. I'll start by talking
about the way that we approached it in Azure, starting eight years ago
when I began in Azure. Even back then, people
were looking at the Cloud skeptically for
a lot of different reasons. But one of them of course, a big one was, the security
of their data in the Cloud. The various threats that they thought their data would
be exposed to if they stored their data in a Cloud provider where it's being managed by somebody else. Including, for example,
a hacker breaking in through the
multi-tenancy boundary and getting access to their data, malicious insider taking
their data and releasing it, or a third party coming and then, through legal means,
coercing or having the Cloud provider turnover
the customer's data, and all of these without
the customer's knowledge. All of these we wanted
to make sure at Microsoft that, as
much as possible, we could protect
the customer data in light of these threats, and specifically for
the legal request for customer data that we
wouldn't be put in the middle, that it would be a matter between law enforcement and the customer. So, we started looking at how we could increase the
protection of our data. If you take a look at the way
that Cloud providers have evolved the protection
that data, of course, one of the things we've
seen over time is that all of us have put in mechanisms
to encrypt data at rest, starting with system managed
keys and then adding customer managed keys or bring your own keys solutions for customers to
protect their data. We've always
encrypted our data in transit between data centers
and you're seeing us introduce encryption even if the customer's data links aren't encrypted within the data center. Then the missing piece though, was how do we protect the data while it's
being computed over. These mechanisms where customer would store their data
encrypted in the Cloud but then not be able to compute over it are fairly uninteresting to
the customers and to us. At that point the Cloud is just this giant
storage solution. The customer still left with providing computational resources outside the Cloud and having to worry about transmitting
data back and forth. If we could bring the computation to
the data center and still protect the data, then we'd achieve protection of the data through all aspects
of its life-cycle. So, we saw the development of what are called Trusted
Execution Environment. I believe everybody
in the room here is probably familiar with them. So, I won't spend
too much time on them, other than to say that they've interesting characteristics with respect to the problems
that we're solving here, or the fact that
it's a black box. From outside the black box, you can't see what's going on inside the black box, ideally. The black box can
attest to what code is inside the black box
in a secure way, and then the black box can also seal secrets inside of
itself for a later access. The two examples of
enclaves that we've seen, that are in practical use for Cloud providers would be SGX, which is part of
Intel processors, and then Virtual Secure Mode, which is a technology that was released in
Windows Server 2016. Unlike SGX, which is hardware
protection of the data, Virtual Secure Mode is hypervisor
protection of the data. So, even the host partition, a privileged partition,
a system administrator, wouldn't have access
to the data being protected by the Virtual
Secure Mode black box. The Trusted Executioner
application architecture that we see resulting
from these technologies, where the enclave
process isolation, sub-process isolation, the black box
actually lives within a process in
the operating system, shares the address
space of that process. So, what's inside
the black box is portion of the address space is trusted, and from the outside
that's untrusted. But the trusted portion
can reach outside of the black box and access
data for efficiency sake. Rather than having to copy
data back and forth inside, it can access encrypted data that is outside the black box. This requires a decomposition of the application into
these two pieces, the trusted portion and
the untrusted portion. So, Azure Confidence Computing, looking at these technologies, we realize that there's
a lot more than just making black boxes or
SGX available to customers, or Virtual Secure Mode
available to customers. There's a lot of other pieces
that we needed to fill in. So, if you take a look at all of what we consider
confidential computing in Azure, it consists of everything from making these enclaves available. We now have SGX cluster stood
up in Azure that we make available through
a limited preview forum for customers that sign up
and want access to them. We also are working on an SDK that allows developers,
enables developers, to develop these
applications that are decomposed into
the untrusted and trusted portions with
a fairly easy way for them to access functions
from outside the black box, inside the black box, and have the underlying
SDK runtime take care of the transport and the transitions between the
enclave and the outside world. We're also working on an
attestation services, is of course necessary for
trusted code on the outside to verify the integrity of the trusted or code in
the inside of the enclave. That attestation that comes
from the enclave provider, whether it's the hypervisor or the hardware needs to be
validated some place. That validation is coming in the form of an
attestation service. So, we're in the process of building an
attestation service, one that will attest to
SGX enclaves as well as other enclaves
technologies as they come out so that the software, either inside the data center
or outside the data center, can verify the
authenticity integrity of this code that's inside
one of these enclaves, and that it's actually
a trusted enclave. Finally, one
other aspect of it is, actually two other aspects
that we need to mention, are that we're looking
at also providing confidential computing
capabilities inside of our PaaS and SaaS
applications as well. So, making it very
easy for customers to consume these rather than
having to build applications. Of course, all these
are necessary from the building blocks to create
these applications up into finished services
that end-users can take advantage of when they're accessing their data or
processing their data. Then finally, one of
the key aspects of the collaboration with
Microsoft Research has been looking at how we can
harden these black boxes. Most of you know here that
black boxes, these enclaves, SGX specifically, have been subject to
side channel attacks. So, we're looking
at ways to prevent leakage of data
outside of an enclave, either through side channel
or through corruption of the enclaves code or exploitation of bugs
in the enclave code. That's an ongoing
research problem with Microsoft or with MSR. So, speaking of the
information leaks, the side channel attacks. Being able to look
at the execution of the enclave from the outside. Seeing its behavior through
page faults, memory accesses. This is one of the examples of a side-channel
leakage that could potentially reveal
information about the data that's being processed
inside the black box. One of the papers that struck me as fascinating was one
by Microsoft Research, where that by looking
at page faults they were able to reverse engineer the JPEG images being processed by
a JPEG decoder, to close enough
where you could get a pretty good idea of
what the image look like. So, these kinds of
problems we want to protect against by
having a verified runtime, an instrumented application
that does two things. One, prevent the enclave from releasing secrets
to the outside. The other one is to prevent these information leaks
by looking at the side channels of
the execution from the outside. So, this is just a
simple example here of, actually that should be
animating for some reason. It's not but the idea is the data comes in and
depending on the tree, different parts of
the address space or different cache lines
or pages are accessed, and you can reverse engineer
which paths through the decision tree the code took. So, I want to show you
an example of one of the projects that
MSR Cambridge has ongoing, which is oblivious computation. The protection against these inadvertent
side channel leaks. I'm going to show
you by taking a look at support vector
machine execution. Did you change
the password? I did that. What? No, I did that. Sorry about, this it's secure
login here. Too secure. >> Of course I know why. >> Here it goes. >> Because it's not on the power. >> Okay, so this is the example. First trace I'm going to
show you is a tool that monitors the execution
of memory accesses, encode accesses, of the support
vector machine computation as it's processing data. You can see for much of the time that these traces actually do not line up based off the two different inputs A and B. That is an example of how we could look
at the differences, or look at the trace
execution history and reverse engineer the data being
processed by the SVM algorithm. On the other hand, version of the SVM algorithm
that's been fed through the oblivious
computation compiler executes and no matter where we stop the trace you can see that the trace pattern
is exactly the same, for both data inputs A and B. So, we view this as one of
the ways that we can help our developers protect against the leakage of
side channel attacks. There's still a tremendous amount of research going. In this space. There are some performance
overhead, as you would expect, to this kind of
oblivious modification of the code and that overhead varies depending
on the algorithm, research work is ongoing
to minimize that overhead. Let's talk about
some of the examples of competence we're
computing that we're also exploring both in
the Azure product group as well as with MSR. We start with one of them, which is always encrypted
storage with SQL server. Let me talk a little bit
about that one. I'll talk about
confidential blockchains. There's financial data
processing and there is secure multi-party
machine learning. When it comes to SQL server, the way the customers
today protect their data from access by the Cloud provider
or by the host, or it is feature called
SQL is always encrypted, where they have the key
on the client side, the SQL runtime, Client Runtime transparently takes
that key and encrypts data on the way
into the SQL server and decrypts it on the way out. So, the data is always in encrypted form on
the back-end, in the server. The downsides of this though are that the SQL server is
not able to see the data, and therefore not able to perform rich expressions on
top of the data. Some simple comparisons,
if you're using a symmetric encryption
algorithm like equality are possible but
certainly not ranges. So, what Confidential SQL
version of Always Encrypted, which is something
we've announced it's coming and we're working with the SQL product team to
get into released form. The SQL data is processed inside the database's engine is
executing inside of an enclave. The data is encrypted on
the way into the Cloud and then the keys are released
after attestation of the SQL engine to the SQL engine so that
it can process the data. In this case, you get
arbitrary rich expressions just like you would with
unencrypted version of SQL. The data remains
encrypted in flight, it remains encrypted on disk and it remains encrypted
as it's been computed over. Another scenario like I've mentioned is
Confidential Blockchain. If you take a look at the way
blockchains are evolved, they started with absolutely no
confidentiality at all. So, the Bitcoin and
Ethereum networks, everybody that's participating in that network can see
everything that's going on. In fact, that's a property that's necessary for
the security of those networks. Over time we've seen different paths being explored for providing
confidentiality. Like side chains and like
zero-knowledge proofs. All of these add
a significant amount of complexity to the interactions
with the blockchain and the construction of the
blockchain and they have limitations as well in terms of their scalability and how much data then can be shared
by the network itself versus sent off into a side chain that only the parties involved
with that can see and therefore makes it very
difficult to take that data off those side chains and make it available to other parties
that weren't part of that. Further, zero-knowledge
proofs, for example, have a high
computational overhead, and so that will slow down the execution of the blockchain. By placing the blockchain
network within a network of Trusted Execution environments
where they test to each other the code
that they're running, the parties that are governing the individual nodes can
certify which code they trust, including the blockchain code as well as the CoCo runtime code, the CoCo being
the project name for this, which stands for
confidential consortium, that code establishes this
network and then implements the basic run-time
primitives that are blockchain ledger can
be layered on top of. This includes secure storage of the blockchain network on disk as well as the secure release of this information to parties that should
have access to, which makes possible
a few things. One of them, extremely high
transaction throughput and extremely low latency because once you end up trusting
the nodes in this way, the nodes trust each other
you can fall back to crash tolerant consensus
algorithms as opposed to prac pBFT algorithms or
proof-of-work algorithms. Further, because everything that happens in the Enclave
is trusted, you can program arbitrary
confidentiality rules into that code as through
governance policy. One of the very common scenario
as we've heard is that multiple parties are
transacting with one another inside
the blockchain, they should only be able to
see their own transactions. But there's an auditor
that is part of this consortium that
needs to be able to see the transactions
of multiple parties. So, how do you set that
up in a dynamic way? It's actually very
straightforward if you've got a
network like this, because you just implement those confidentiality rules
as you would in any trusted network
which is simply through access control policies, where the auditor has access to arbitrary transactions
in the code inside the enclave that's part of CoCo with a blockchain
primitives laid on top of it would only make that those transactions available
to authorized parties. So, confidentiality. The governance can
also be built in to vote on which parties can be added to the blockchain as
well as to evict parties all with very high throughput and low latency like I mentioned. This is a picture of
the CoCo architecture. What we've done with CoCo is created a prototype
last year that we actually demonstrated
publicly when we announced CoCo to the world. The CoCo prototype
has evolved now and we're building
a production version of CoCo. This runtime, like I mentioned, arbitrary blockchains can
be layered on top of. So, this initial prototype we're layering of the Ethereum
Blockchain on top of it. So, it's compatible with
off the shelf Ethereum, though with confidentiality
atributtes added to Ethereum. So, you can specify confidentiality on top
of smart contracts. This project, we intend to
make completely open-source. That means that
customers can take this and run it on their own servers
outside of Azure. The goal here isn't
necessarily to make sure that this is locked into Azure or Microsoft
only technologies. It's open-source. The enclave runtime that we're working on will support
both Linux and Windows. CoCo will eventually support both Linux and Windows
and it will be published in GitHub
for other parties to participate in the
development of it. We also expect other
blockchain ledgers to be integrated on top of
CoCo over time as well. So, let me show you
a quick example of CoCo, and what I'm going to do. I lost track of this
one. Here we go. >> Is it locked up again? >> No, I don't think so.
Yeah, it's locked up. I don't why it's doing this. This is SSH session
to a Linux machine, that is running in
Azure and SGX machine. So, what I'm going to
do first is show a simple smart contract- thanks. So, I'm going to show a simple
smart contract executed on the Ethereum CoCo
integrated blockchain. This is standing up
a five-node Ethereum network, and then we'll execute
as many transactions as it can and then show us
the throughput that it achieves. Of course on the public
version of Ethereum, which is based off of
proof -of-work consensus that transactions throughputs 10-15 transactions per second. You can see here that, again, this is Ethereum, stock Ethereum, integrated with CoCo
and it's achieving, you can see around 12,000 transactions to 13,000
transactions a second. We've also, just to push the limits of the CoCo Framework, just created
a simple ledger network and then integrated
that with CoCo, and this is standing up
a five-node version of that network and then also trying to see how
fast we can drive it. You'll see that it's significantly higher
than what we got with Ethereum and yet there's still more performance
optimization to do. So, you can see that we're achieving close to 100,000
transactions a second. We think we can get up to
150,000 transactions a second or higher in
five-node network here. Then finally, one of the last cases that
we're looking at, and this one's very exciting from a number of different domains, is multi-party confidential
machine learning. One of the canonical
scenarios for this is the processing
of medical data, where different parties
are coming together with health information gathered
from different sources, whether X-rays, CAT scans,
other diagnostic data. These parties are bringing
it together and they can get a deeper insight than any one
of them individually can, but there's regulatory
restrictions or privacy concerns over sharing their data with
these other parties. With confidential computing
and these enclaves, they can, if they trust the algorithm
running inside the enclave, release keys that
enable the enclave to access their data
and then perform this multiparty
computation over it. So, I'm going to switch
back and show you a very quick demo of that. This is the hospital scenario
with three parties. So, we have the server. This is where
the training will happen. We've got Hospital A,
we've got Hospital B, and I'll show you Hospital A is taking its plain text data, it's going to encrypt it, and then it's going
to encrypt it with the server key that
came from the enclave. Now, the server will
process the data, show the encrypted model
outside the enclave and then when we go
back to Hospital A, you can see Hospital B
is getting back the encrypted weights and decrypting them with it's
own key and then showing them. So, in this case, Hospital A and Hospital B, we're able to get insights out
of the data without either one having access to
each other's data, just trusting that
machine learning algorithm and the Trusted Execution Environment it was executing in. So, that's a quick look at
confidential computing. I fundamentally believe, we fundamentally
believe that in Azure, that we're at the beginning of a transformation of the way computing is done
today because of limitations in
enclave technology. We'll see this only for very kind of extreme cases of customer
sensitivity over data. We expect that this
will unlock data that would otherwise not
come to the Cloud and allow it to
come to the Cloud, but that over time
these primitives are powerful enough
that we will see the creation of
effectively the equivalent of these private data centers
on prem data centers within the public cloud protected with
enclave technology. Also, as part of
our intelligent edge, Intelligent Cloud strategy, of course enclave
technology will be critical on the edge
to protect data, sensitive data, as
it's being processed on a collected from
those edge devices. So, with that, I want to thank you very much for taking a look at our competing program. Few things I want to emphasize, this is open-source, tight
collaboration with MSR. We'd like and seek collaboration with the research community on these projects that
I've talked about. There's a lot of spaces
to explore here, and we don't think we're going to be the ones
that can do all of it, so collaboration is
certainly welcome. And just want to highlight
Emmanuel Acosta, where is he? Where did he go? There he is, right in front of me.
From MSR Cambridge. He's been the lead collaborator with us in Azure on this project. So, go ahead and turn over
next speaker. Thanks. >> Let's thank Mark. I think we have time for a
couple of questions, and then all the speakers
will be around. So, but let's keep
the questions short. Let's take two questions. Yeah. >> Can you please comment on how you will extend these enclave technologies
to accelerators, given that Azure is now incorporating accelerators
and there're more to come. >> This is an area
of ongoing research. I don't really have anything
more to say about it other than we are
exploring how to do that. Of course, the machine
learning example highlighted the need for that, that the training which is, not best done on CPUs, but done accelerators, is one of the scenarios that we're
looking at very closely. >> One more question. >> Maybe just an answer to that. This morning Stavros
Pineios was presenting. So, there is a tech demo
in doing that. You can find Stavros and he can tell you a little bit
about his research. There was a small pic
this morning >> Thank you. >> Yes. >> I have a quick question.
Could you please comment something on the use of homomorphic computing in Azure and how practical that
is now, nowadays. >> Yeah. So, that's
another big effort in Microsoft researchers,
homomorphic encryption, and we watched the development of that very closely as well, it's got some limitations and has performance overheads as
well associated with it. We don't think necessarily
this is one size, fits all space. In fact, homomorphic encryption
inside an enclave, the combination of the two is something we're
also looking at, as ways to extend the power
of homomorphic encryption. >> Right. Let's thank Mark
again, thank you very much. >> Thanks. >> So, our next speaker
is Dawn Song. Dawn is a Professor in the Electrical Engineering and Computer Science at Berkeley. Dawn has a very broad range
of interesting security, ranging from software security, network security,
distributed systems, applied crypto, blockchain, and
machine learning and security. Dawn received a very
large number of awards, including the
MacArthur Fellowship, Guggenheim Fellowship,
the NSF CAREER Award, Sloan Research Fellowship, MIT Technology Review
award, and many others. I would highlight that Dawn is ranked as the most cited scholar
in computer security, so that's a special achievement. So, we are very lucky to
have Dawn here today, thank you very much, and
I'll hand over to you. >> Okay. Yeah, thank you. Thank you everyone
for being here. Today, I'll talk about
towards secure, practical, confidential computing with
open-source secure enclave. Now, wearing two hats, I'm a professor at UC Berkeley in Computer Science
Department and also, I'm the founder and CEO of a new startup called Oasis Labs. So, here we'll hear a lot about the value of data analytics
and machine learning, they can really bring us a greater power in terms
of gaining insights from data and to help us to make better decisions in many different areas
including healthcare, IoT, smart building, and financial services,
many different areas. Also, as we all know, data is the new oil. Unfortunately, a lot of this
data also is very sensitive. So, as we use the data
we need to be very, very careful with
protecting user's privacy. So, first let's
look at how current framework works for data
analytics and machine learning. So, how current
framework works is that users data is
being collected, and then the analysts will write analytics and
machine learning program. This program will then run on that computation
infrastructure, which then computes
their results. However, the current framework is insufficient for our security
and privacy protection. For a number of reasons and in particular several
different types of threats. The three types of
threats is that here, the analytics and
machine learning program itself actually maybe untrusted because they can
be inside the attacks, the analysts account may
have been compromised, hence the attacker
can actually inject a malicious program into the analytics and
machine learning program. Also, the second threat is the computation
infrastructure itself maybe untrusted as well. Again, attackers may have compromised the computation
infrastructure and hence, can then steal sensitive data during the computation process. Finally, the computation result itself can reveal
sensitive information about the inputs as well because these computation
results actually are computed from the sensitive
inputs to start with, and hence the computation
result itself may reveal sensitive information about the inputs as well. So, to adjust all these three
different types of threats, we need to develop
different types of technologies, and this is something that's in my group has been working at in. So, first to address the threats of
computation outputs revealing sensitive information
about the inputs, we have been developing technologies in computing
practical solutions for differential privacy
and for adjusting the threats of
untrusted data analytics and machine learning program, and we have been
developing technologies for our program rewriting
and verification, so that we can actually automatically rewrite
the data analytics and machine learning
pipelines to ensure that even though
the original analytics and machine learning program
maybe untrusted, the rewritten program will ensures that it will satisfy the desired security and
privacy requirements. To address the threats of
untrusted infrastructure, we leverage technologies
for a secure computation. Given this session is on
confidential computing, this is the area that we will actually focus more
in in this talk, the secure computation side. I wanted to show this overall
picture just to explain that when we do data analytics
and machine learning, the privacy and security aspect
is actually fairly broad. We need to actually protect the security and privacy of data from many different angles, and not just
confidential computing, and it's important so that we actually combine these
different technologies to really ensure the security and privacy
protection for user's data. But for this talk, we will mainly focus on adjusting the second type
of threats listed here, using secure computation to protect against
the untrusted infrastructure. So, the concept of secure
computation is very simple, the goal is
essentially to be able to simulate
a trusted third party, where essentially user's data is being used to compute
a certain function. With this simulated
trusted third party, we can ensure that from the
computation perspective, user's data is being protected. So, an attacker will not
be able to see more than, in this case, the
computation results. Also in this user, we also want to ensure
that the right program is being executed and it
does the right things. One example illustrating
the importance of secure computation
is, for example, we want to build a word-embedding model from user's text messages,
and, of course, user's text messages
are really sensitive, and the computation infrastructure
may not be trusted, so we want to enable the secure computation
so that we can build the language model, in this case, while preserving the privacy of
user's text messages. When we talk about
secure computation, there are two main types
of tech approaches. The first one is
cryptography-based approach, and the second type is
hardware-based approach. >> So, with the crypto-based
secure competition, there are different techniques, including fully-homomorphic
encryption as well as secure
multi-party computation. The challenge of a
crypto-based secure computation is that the performance
overheads can be very high. Oftentimes it's
orders of magnitudes performance overheads compared
to native computation. Because of this, it's
significance and it limits the usage scenario for
crypto-based secure computation. The second type of approach for a secure computation
is hardware-based, in particular leveraging
secure hardware to enable abstraction that we call
Trusted Execution Environment, also called a Secure Enclave. So, in this case a
Secure Enclave can provide the capability of
hardware-based isolation as well as attestation. The advantage of secure
hardware is that it can provide
a really great performance, and oftentimes the performance can be very close to
native computation. Hardware-based as a computation
essentially can enable a very general-purpose
computation and can enable many different
security applications. So, with the Trusted
Execution Environment, we essentially can
run a program inside a Secure Enclave and then in this case the operating system and other processes
running outside of the Secure Enclave they
won't be able to tamper with the execution of
the program running inside, and also they won't be able to learn what's running inside, ideally, and hence it provides the integrity
and confidentiality. Also Secure Enclave
can, in this case, provide a hardware-based
remote attestation capability, where the Secure Enclave
can attest to a remote user what program is running inside the Secure Enclave and
what is initial state. So, Secure Enclave can serve as a really strong
cornerstone security primitive for us to build
secure systems on top of. It can provide very strong
security capabilities including authenticate
itself, the device, authenticates what program
is running inside, and providing the integrity and confidentiality of the execution. It can really be
a platform for building new security applications
that couldn't be built otherwise for the same
practical performance. There has been many example
security applications and systems built on
top of Secure Enclave, for example using Intel SGX, including a lot of great
work down here at Microsoft. So, besides these example
security applications that have been demonstrated the Secure Enclave can enable, also here I want to
just briefly mention another user scenario
where Secure Enclave can really help solving
even greater problems. So here, many nations state leaders have
recognized the importance of A.I. and stated that "Whoever controls and leads in A.I.
will rule the world." So, the question is,
who is controlling and leading A.I. today and who will be ruling the world tomorrow? So here, this is the
status quo today. Users data is being collected
and big companies build. Personnel profiles for users and then use these personal
profiles to serve users, for example providing
driving directions and even giving a job device
and light planes. However, currently in
the setting, these services, their goal is to maximize
company revenue. So, the question is, is there a different future where we can build intelligent agents and
virtual assistants that are actually under user control they can leverage
services provided by third parties but they maintain the user profile and
there will be several uses, driving directions, Java
device and light planes, and the important difference
here is that they will be operating under the modes
of maximizing user value. So, the question is,
is this possible? How can we actually achieve this? So, as I mentioned, I wear two hats. So, at Oasis, we are building a new technology called the privacy-preserving smart
contracts at scale. So, what do we do
here is that we are building a new
blockchain platform, and on top of the
blockchain platform one of the key primitive and
capability that will provide is what we call privacy preserving
smart contracts. This privacy preserving
smart contract has a number of unique
capabilities and properties. It can provide
automatic enforcements of codified privacy requirements. So, in this case,
the privacy requirements actually it will be encode this as codes inside their privacy preserving
smart contracts, and also we can achieve these enforcements without
relying on any central party. We plan to build this privacy-preserving
smart contracts to be able to scale to real-world
applications including machine learning
even at class scale. This primitive of
privacy-preserving smart contracts can make it much easier for its developers to build privacy-preserving
applications without having to be a privacy expert. In order to enable this privacy-preserving
smart contracts at scale, the Oasis blockchain platform uses a number of
different technologies to provide this capability, including in a confidentiality preserving smart
contract execution, which essentially
protects the execution of this smart contract from leaking sensitive information during
the computation process. To also add application layer, it provides
privacy-preserving data analytics and machine learning, including providing
differential privacy for the application to prevent the output after computation from leaking sensitive
information about the inputs. We also developed
new architecture and technology for the blockchain platform
to enable scalability, to enable scalable
smart contract execution. With this privacy preserving
smart contracts technology, we can build blockchain of intelligent and
smart contracts, where we can actually have various machining smart contracts that are actually run on top of the blockchain and
Oasis blockchain platform, and these machining smart
contracts essentially can help pull data from potentially mutually distrusted
data sources together, then build, for example, differentially private
financial service models, fraud detection models
and even medical diagnosis and treatment models. So, one of the key
capabilities of enabling this privacy
preserving smart contracts is the ability to do confidentiality preserving
smart contract execution. One of the key ingredients to
enable this confidentiality preserving smart
contract execution is to leverage the capability
of secure hardware. All the hardware
manufacturers have recognized the importance of
building secure hardware. So, over the years, they
have all been developing different solutions for a secure hardware
including Intel SGX. However, today we still have lots of open challenges
in building secure hardware. So first, how secure can that
be and what threat model, and what would you entrust
with a secure hardware? For example, you
have bitcoin keys, you have financial data,
and you have health data. In fact, this is, I will call, a grand challenge is
can we actually build a truly trustworthy
Secure Enclave that can serve as a cornerstone
security primitive, that can be widely deployed and enable secure systems
to be built on top. If we can achieve this, it can truly usher the entire community into
a new secure computation error. So, what's the path to trust
with a Secure Enclave? There are several
important steps. So first, we need to
open source design for the Secure Enclave
and ideally we would like to have formal
verification for the security and correctness of
the Secure Enclave, and also we need to
ensure secure supply to management to ensure the security of the manufacturing process. It's very important to have an open source and
Secure Enclave design. Currently none of the commercial Secure
Enclave TEE solutions are open to the public. Hence, as the public, we actually cannot
analyze or verify a hardware vendors
design in the setting, and also currently there's no industry agreements
and what is the right solution for
building Secure Enclave. With the open source
Secure Enclave design, it's to provides
the transparency that's needed for the whole
community to, together, analyze and verify the security
and the correctness of the Secure Enclave and to enable high assurance and open source help build a whole community. So, there has been
greater efforts on building open-source
secure hardware. One example is Sanctum from MIT, which builds a secure processor
design using RISC-V ISA, and it's designed to be able to defend against the cash-based
side-channel attacks. So, extending
Sanctum, we now have a new project called
the Keystone in collaboration between Berkeley
and MIT and there are other institutions who will
be joining the team as well. So the Keystone Enclave is an open source Secure Enclave
on top of RISC-V, and in particular leveraging the existing physical
hardware capabilities already available in
today's RISC-V tips. The goal is to provide
a strong memory isolation, we want it to be simple
and portable and provides a remote attestation capabilities
and fully open-source. There are a number of goals for the Keystone design that are important components to
achieve overall the goal of building a truly trustworthy open
sources Secure Enclave. I won't go into
individual goals in detail, and then certainly will talk more about the side channel aspects. So Keystone leverages the existing physical
hardware capabilities into these RISC-V tips, and to build the
open-source Secure Enclave. By using this Secure Enclave, essentially it helps to enable the system to separate
the privilege and trusts. So, in particularly in this case we actually have three modes; the user mode, the supervisor
mode and the machine modes. The enclave and also the components that enable
the Secure Enclave, are run at the machine
modes level. Whereas the operating system are running in
the supervisor mode and other user processes are
running under the user mode. One of the key components for Keystone as the security monitor, which essentially helps
provides the memory isolation. In particular, we enable
the physical memory protection with the machine modes and the virtual memory oscillation
with the S-mode. The Keystone in
particularly relies on the standard RISC-V primitives. In particular there are two main primitives
that we rely on. One is the Physical
Memory Protection, PMP, and the Trap
Virtual Memory, TVM. Due to time limit, I wont have time to go into
the details of all these, but these hardware capabilities
make it actually much easier to provide
the memory isolation for the Secure Enclave. As a result, the Keystone design for Secure Enclave actually
is much simpler than, for example, SGX and also
the Sanctum as well. So, this is the Keystone
architecture, again, I won't have time to
go into the details. So, I will actually
skip these, and again, because of the fact that
the Keystone leverages existing hardware capabilities in RISC-V for the memory amendments, it can provides
much more flexibility in terms of the type of enclave that they can enable in the sense that
the enclave size can be dynamic and where
the enclave can be located is dynamic as well. So due to time limits
I think I have to skip these details, how we actually use the PBM and TVM to enable
the memory isolation. Also Keystone plans to use other paths to help with
the key management as well. So, as a collaboration
between Berkeley and MIT, so we are working hard building the Keystone Secure Enclave, and we have a timeline that
we hope that in the fall, we actually will have a first release after
Secure Enclave, where it won't be full featured. In particular the first release
will contain some of the key capabilities for memory isolation and
some capabilities from the secure boot, remote attestation, and to
secure key provisioning. So, we plan to actually deploy the efforts to the Amazon AWS, using the FPGA as a first
deployments and later we plan to have it deployed on
the NEO HiFive unleashed chip. So using such capability for confidentiality preserving
smart contract execution. Again, we can enable privacy,
preserving smart contracts. They always use
Blockchain platform, and using these
overall capabilities, we hope to truly enable a blockchain of intelligent
smart contracts. Here, let me just give
you one example of a simple application that
we have been building and together as collaboration
with researchers and doctors from ETH and Stanford
for an app called Kara, a privacy preserving tokenized data market
for medical data. So as we all know, medical data is often
locked in data silos, so the goal here is
that we want to be able to incentivize doctors and patients to share data and to be able to
improve medical research and by leveraging the capabilities
of privacy preserving smart contracts on top of
the Oasis Blockchain platform. So in this case,
users and patients, can upload to
their medical data in encrypted form to the Oasis
blockchain platform and then the medical researchers
can essentially build privacy preserving
smart contracts and within this smart contracts, the researchers can include Machine Learning, model training, and model serving codes. Also the privacy
preserving smart contracts can specify terms of
use, for example, how users may get the
compensation for contributing their data to the smart contracts and also as stating that, for example, the data
will only be used for training Machine Learning model inside the smart contract. As users agree with
the terms of use, users medical data
can be contributed to the smart contracts. As the smart contract
collects enough data, it can then run the Machine Learning
model training codes to train the machinery models
and then in the end, the medical researchers can then evaluate the trained
Machine Learning models. So in this way, it helps to significantly reduce the friction for
medical researchers and pharmaceutical companies
to get access to data for training Machine
Learning models to find better cures for diseases. Then we have some upcoming paper
at our conferences. To summarize for
the technologies that have been discussing and
so Oasis Labs has just recently launched and also we have launched
our private Testnet where we encourage and invite our patient developers to join our private testnets to build applications on top
of the platform. So the current example I mentioned is actually
a collaboration with some of the app developers to build on top of our platform. With all these technologies
and Oasis Labs, we hope to build a privacy first, high-performance cloud computing
platform on blockchain. All this work for Keystone is a collaboration
between MIT and Berkeley, and we have a great team
as Oasis Labs. Our longer goal is
that we want to build a truly trustworthy, secure hardware that can enable all these
great applications. However, as I
mentioned in the talk, there are many challenges
that I actually didn't have time to go
into all the details. So more researchers are needed for research and development, and it requires
a community efforts. So let's tackle the big
challenges together. Thank you. >> Thank you. We have time for a couple
of questions. Yes? >> [inaudible]. How did you plan
to tackle the nontechnical issues? For example, you
talked about verifying the supply chain for building these chips
and somebody may trust the US regulated company like Intel for example
or whatever and somebody may prefer a EU regulated company doing that and somebody
a Chinese regulate company like how do we
agree on these things that don't have to do
much with technology? >> Yeah, that's a great question. So, that's actually
another reason why we want to have open-source secure enclave
so then in this way, we don't have to rely
on any single party. So any hardware manufacturer can then go manufacturers and different users can also choose which hardware manufacturers that they trust more than others. Also, I do strongly believe that while the whole community
will actually or they have a lot of
experience in many of these other aspects of putting secure enclave but the
secure supply chain management is the one area where
as the whole community, we actually haven't
really tackle it head on. We don't actually have a lots of experiencing but it's
a very important area. So, we hope that with the Keystone projects and we're
actually helping to build a community together with different institutions and the hardware manufacturers
as a whole community, that actually can be an area of focus as a next step
in the near future, and that's where we can put
the proper processes and also various verification
procedures to help us to make progress towards this goal of
secure supply chain management. >> All right. Let's
thank Dawn again. Thank you. Our next speaker is Professor Srini
Devadas from MIT. He's a Webster Professor of Electrical Engineering and
Computer Science at MIT. His interests are also
broad in Computer Security, Computer Architecture,
and The Applied crypto. Srini received the 2017 IEEE W. Wallace amygdala
Award and the 2018 IEEE, Charles A Technical
Achievement Award, for his research in
secure hardware. He also received the MIT's
highest teaching honor, the Everett Moore Baker
Memorial Award and the Bose Award for
Excellence in teaching. So thank you very much
and hand over to you. >> Thanks for the kind
introduction, Manuel. I want to give you folks a sense of what is going to take to build secure computer
architectures that can do the things that the previous
two speakers want to do, the lightweight
secure enclaves and so on, and it's fairly challenging. They've been many attacks exploiting side channels but not just side-channel attacks but attacks exploiting
out-of-order execution, speculative execution
that have come out and I want to give
you a sense of how these attacks work because
we need to understand how these attacks work in order to actually defend against them. So, we've been working
on defenses against the latest and most portent
of these attacks, I'll tell you
a little bit about that, and I'll close with talking
about secure enclaves. I'll be brief
because they've been covered quite nicely
by Mark and Dawn. But the stakes are
a little bit higher because in the case of just building
conventional processors, you get to trust system software, you get to trust
the operating system, and you can make it
do a work for you that corresponds to handling
sensitive data but you can't do that when you have a secure enclave if
you want to minimize the trusted computing base
and you want to shrink it down by
whatever it is two, three orders of magnitude
from tens of millions of lines of code down to
thousands of lines of code. So, I'll say a little bit
about that then. So, let me just start. So you're probably thinking,
"What is this picture?" Well, I had this
really pretty picture of the described
compartmentalization and secure containers in processors and I realized I probably
illegally downloaded it. So this is a picture of my toolbox and so I
own this picture. It essentially gives
you a sense more seriously about what
architectures have to do. Architectures have to isolate
processes from each other. This is fundamental
to multiprocessing. It's fundamental to time sharing. It's been with us for 50 years. If this is violated, if architectural isolation is violated, we really have nothing. I mean we have no security, we have no privacy, you
don't have integrity either. So it's important to maintain architectural isolation
and over the years, computer manufacturers have used many different performance
optimizations in order to improve your IPC instructions
per cycle et cetera, and it turns out
these operations were done largely at the
microarchitectural level and they were hidden
from the ISA, the Instruction Set
Architecture, and in particular, these microarchitectural
optimizations have been shown to leak privacy and potentially influence
correctness as well. So, let me say a little bit about the latest of these attacks corresponding to spectrum meltdown that obviously received a lot of press but
very briefly here, what one can do if you want to just execute
a sequential program is obviously go
from instruction I to I plus one to I
plus two et cetera, and every once in a while
you're obviously going to have a branch and that's
corresponds to control flow. You could certainly wait until the branch has been resolved
so you know that you want to go in this left direction but if in fact it takes a long time for
the branch to be resolved, because you have to go look at the memory location for example, then you might in fact
decide to speculate. So, you decide that you probably going to go
left and you decide to take the left fork and you start computing J and J plus one even before you finish
up on instruction I and if you speculate correctly, then everything is great and
you've gained performance. But if you miscalculated and you've decided that
what you really should be doing is to
go right, I should say, you decided to go right but
in fact you had to go left, then you've executed K
and potentially K plus one and you have to roll back and you've done some things that can clearly be cleaned
up from a standpoint of architectural state and there's no question that processors today definitely do this cleanup. But unfortunately,
what happens is that while you're executing
K and K plus one in this incorrect way or should I say in
a mispeculated way, you may have changed the
micro architectural state and that could leak information. So, this notion of speculation was considered just a
performance optimization but it has serious
security implications. Essentially, the attacks
that have been proposed, there's just a wide
variety of them. I mean every conference
seems to have sessions now, architecture conferences
or new types of attacks, but they have two
characteristics in common. First, primarily, I
exploit cache tag state. So, you have caches
which are obviously important for performance and they've been around for a while, caches are micro
architectural state and you bring things
into the cache, when you execute it
for example the K and K plus one incorrectly, and that changes
the state of the cache. The cache state,
unfortunately, in speculation, is not rolled back in
the conventional processors, and because you don't do that, there's some side effects
to the misspeculation. The other thing
that's interesting is that you have
branch predictors and computers that correspond to deciding how to predict
which way to go, whether to go left or right. In this case, you
have a situation where the learning associated
with a branch predictor, I mean, these are not
deep learning engines, or at least not yet. But they definitely have capabilities associated with
history cables, et cetera. The inputs to
these branch predictors, that respond to learning which way to go for
a particular branch, may come from other processes. So, there's no isolation within the branch predictors on learning from your own process, and that is actually also being exploited in these attacks. So, this is really
a huge attack surface, and so this is really a picture that I won't spend
so much time on, but I leave you with spice
potentially everywhere, because you have processes that are sharing branch tables, processes that are
sharing caches, DRAM controllers,
there's timing channels, cache tags, and so
on and so forth. So, this is
a fairly exciting time in computer architecture, primarily because
we have to go back and rethink how we would do time-sharing in the context
of all of these spies. So, I want to give
you a sense of how to categorize
these different attacks. So, here's a little picture
that taxonomized attacks corresponding to both the new ones
and the old ones. So, the idea here is that you have a domain, you
have protection domains. That's really what
time-sharing is about. So, you have a domain
of a victim, the victim has some secret that the victim wants to touch, and use for encryption or maybe
it's just sensitive data, medical records, what have you, and then you have an attacker. The attacker is concomitantly using resources of the machine, it may simply be
a time-shared situation, you may only have a single core, but they also could
be multicores, and there could be
space sharing as well. So, these two domains are
supposed to be separate. You have two different domains corresponding to the victim
and the attacker. The first thing is that
there's these channels, these channels are these side channels that have to be created, and then any number of them, in a cache tag state, the most common in at least in
current day attacks, but there are others as well. What the attacker does is
it creates a receiver. So, this is really a
piece of code that can somehow exfiltrate
through this channel, the secret or some form
of the secret that isn't the victims
protection domain. There's also a transmitter
that's associated with a piece of code and I'll tell you a little bit
more about this in a second, that touches the secret. So, this transmitter is actually running in the victim's code. So, it has permissions
associated with that. So, the basic idea is that, if you create this transmitter and the receiver and
you have this channel, well, you've essentially
a broken privacy of the victim. So, if you look at the different attacks
that are out there, and so just to give
you a sense of why this taxonomy is broad and incorporates
both the recent attacks and attacks that
are 20 years old, let me give you a sense
of an age-old attack that was done about 20 years ago on the RSA encryption algorithm. Where it has
conditional execution, depending on what
the bit of the key is, you either do a modulus
or not, roughly speaking, and you do a lot of computation
in one case going left, and you don't do very
much going right. This is a problem because this
is part of the algorithm, and this algorithm
is actually doing different things based on
the secret key or maybe has to, because, obviously the output has to depend on the secret key. But if you haven't written
the program in such a way, you could be in
a situation where, regardless of
speculative execution, you're just doing more work on the left-hand side
versus right hand side. The micro architectural
channel associated with the cache could change the execution
corresponding to what the execution would be
if the secret key bit were zero versus one. So, this change with respect
to going left or right is exfiltrated through
the cache tag channel based on caches and cache misses that can be
viewed by the attacker. So, you can get a sense of what the victim's cache hits
and cache misses are, based on what your cache
hits and cache misses are, if you shared the cache. So, this was an
attack that was done 20 years ago and the fix
for this attack is, something that Mark mentioned, you can try to do
oblivious execution by balancing parts, et cetera. You can certainly
do this for RSA, but as you'll see,
cryptographic algorithms got a lot more complicated, and these attacks
are still valid in the case of anonymous
attestation schemes like SGX and I'll get to
that a little bit later. Now, you can take these attacks corresponding to
spector and meltdown, and you can view this in this taxonomy by thinking
about meltdown as being something where the attacker was able to write
this transmitter by essentially creating
a permissions check before accessing some data. Because of speculative execution, that data was actually
accessed and brought into the cache in
a particular corner case, before the permission stack
was actually validated. So, that was a corner case in the processor pipeline that corresponded to the meltdown bug. Spectre Is a broader class of attack where you can actually synthesize this transmitter
by looking at victim code. It's broader, it's also
harder to accomplish, but it's something that clearly has been
done at least in, let's say, in
the test tube level, if not in the wild. So, these things are things that just from a pure standpoint, are things that you
need to fix if you want architectural isolation the way it was promised
to us 60 years ago. So, how do you defend against
these types of attacks? I'll just focus on the cache
channel because that's the most popular channel
for exfiltration. It's a matter of
carefully designing processor caches in this case
to do perfect isolation. So, people have done
cache partitioning, this cache partitioning schemes
that are in processors, and in general to protect
against these attacks, the different schema
would be that you have the block one
of these steps. You got to break that pipe
there and we've focused on, in our research, focused
on blocking the channel. That seems like the easiest
thing to do but there's other ways of defending as well. So, Intel has Cache Allocation
Technology built-in. It's abbreviated CAT. Essentially, it's something that is a quality of
service mechanism, it wasn't meant for security, but it's a way of
making sure that a runaway process doesn't
trash the cache for you, and you still get
performance even though you're using
only part of the cache, you'd at least get
one part of the cache. Now, computer
architecture one-to-one, caches are made up
of sets and ways, you can think of the sets
as being horizontal rows, but what you see here are different colors
corresponding to the ways. Essentially, a way is something that says
if you have two ways, then you can either
go here or there in a particular set
and its associativity. So, you can partition the cache
using sets or using ways, CAT does it using ways. You can essentially say that the attacker cannot evict a piece of data from
the victim's way. That's essentially
what CAT does is, it's the quality of
service mechanism. I'm not quite enough
for isolation, for perfect isolation, for a
couple of different reasons. The first is that
shared addresses are visible. So, it's possible that you
have some shared libraries, and the victim and the attacker
could be sharing data, and that corresponds to the data that's in
the victim's way, for example, because
the victim access first. So, it's possible that that won't get evicted but
you can see the cache, it's associated with
the shared addresses. Then, the other part of, it
is a little bit more subtle, is that you have
replacement policies associated with these caches. LRU is the policy that you learn about in
computer architecture 101, recently used but
nobody builds LRU, at least not perfect LRU,
they're approximated. It turns out that
replacement metadata can leak information even though you had isolation in the waste or you had
isolation in the sets. So, I'm not going to go
into the details here, but roughly speaking, the reason, the first reason that
CAT leaks information, and it doesn't protect you, is simply that cache hits are not isolated across domains. So, in the shared address case, if an attacker brought a piece of shared data
into its way, the victim will hit on it. If the attacker didn't, then the victim would miss on it, and so you get
some information from that. Then, because you use
approximate LRU schemes, even though you have
this partitioning of blue and red over here, the first three columns here or the slots correspond
to one domain, the red one because one
to a different domain. You can think that
this isolation, but if you have
an approximate LRU scheme, a PLRU or Pseudo-LRU
which is used quite commonly in
various processors, it's possible that you can sense a difference in what was
evicted from the victim even though you had
this isolation because of the replacement policy
having imperfect isolation. So, CAT doesn't protect you
and so we had to improve it, and so we said well,
we'll call it DAWG. So, this is just an abbreviation, Dynamically Allocated Way Guards. It's a way of taking the CAT mechanism
and fixing these two that I've told you about. Just briefly, I just
have one on it, you have to track
global protection domains. You have to be very careful about what goes into the cache, and what gets evicted
from the cache, and you can do this
by essentially making sure that cache tags or replacement metadata don't
interfere with each other. It's a fairly simple change. Hardware manufacturers
will tell you that this is an invasive change
to the hardware, because you're messing with the cache hash
function, et cetera. But I'm a proponent of open source and
clean slate design, so for us, it's easy. But it's not something
that can be done. Any change in hardware obviously
takes years to deploy. But this is not something that would be as
invasive, I would say, as changing the
processor pipeline and changing the number of
stages for example. So, roughly speaking, you have additional data
associated with what gets evicted and what gets
pulled into the cache. Also, the replacement policy, perfect LRU does
not have a problem, random replacement
doesn't have a problem, but if you use
an approximate LRU scheme, you have to do
a little bit more work to ensure perfect isolation. So, now you'd say "Okay, this was the cash tag channel." I'll just leave you with this other micro
architectural state including branch predictors state
that needs to be isolated, if there were attacks, there were potent enough to exfiltrate through
those channels, and you could use this type
of technique over there. Again, you have to look
very carefully at what you bring how you modify the
micro architectural state. There is a little bit
of a complication. The unfortunate part of
the dog scheme that we derived is that you're disallowing hits across
protection domain. So, if you have
some shared addresses, then it's possible that
these shared addresses will be replicated across ways, so the same address
in two two ways of the cache and this is
okay for read only data, but obviously it
would be a problem if you guess wrong and the data was writable and so you have to do some work with the operating system
to try and fix that. So, let me close by just
briefly telling you about what the challenges are in building secure enclaves
in speculative processors. This material covered in a
couple of different ways. So, very briefly we want to shrink
the trusted computing base, you don't want all of the
operating system to be trusted. You'd like to minimize that to perhaps as security
monitor as is the case in Sanctum or microcode as is
the case in Intel SGX. SGX has some nice properties
associated with it, it does all of these things and shrinks the trusted
computing base but it has some serious issues
associated with side channels. It leaks privacy in
many different ways. Microsoft had
a very nice paper that was mentioned on a leak
through the page tables, through the page
fault mechanism but there's other ways and
hyperthreading for example is yet another way and we've already talked
about speculation. Unfortunately, all
of these things have gotten to the point
where now you can take SGX machines rumor has it since
I haven't read the paper, but it's going to come out
August 14th and you can extract private keys
from SGX machines when the machine is running
anonymous attestation using EPID because there was cats that I talked
about back in the RSA, example weren't
completely balanced and therefore that these
micro architectural channels, exfiltration through
the cache and also through out-of-order
execution so, a subset of the people who did the spectra attack published this paper that's
going to come out as I mentioned on
August 14th and using insecurity which are
essentially breaking the SGX ecosystem and I think the title of
the paper is something like Extracting The Keys of The Intel SGX Kingdom
or something like that. So, that's not very
satisfying obviously. So, there's work to be done. So, this wasn't
because we were smart, it was probably more
because we were lucky that we decided
that we would build non-speculative
processors way back when we started
our sanctum project. Speculation is hard
to build in hardware I knew about a whole bunch
of other attacks and I don't know of a way of isolating hyperthreaded applications
from each other so we decided we wouldn't do
hyperthreading either but we did definitely look into
the cache tag channels and we have a petition caches
and sanctum and we clean up after ourselves in terms
of the time shared processes. I want to say a little bit about Sanctum's Chain of Trust, Dawn mentioned this. So, the idea really here is that you build
processors that have again public keys and private
keys associated with them and the way it
works in sanctum is that no one one the private key. It's generated randomly when
that chip is fabricated, that chip is powered up
I should say or on an FPGA and privilege
doesn't imply trust, but you do have machine mode where the small piece of code
called the security monitor runs and it essentially
verifies all of the allocation decisions that
the operating system makes, and you can get
secure enclaves using this mechanism and of course the key question is
what's your threat model? Did you incorporate
all of the attacks that are possible today in the threat model and did
you design for that? And it's simply armor ammunition, it's going to keep going, I don't see an end to that. Again, Dawn mention this. The page fault attack
is an important attack, it's I would say
a design flaw on SGX. We fixed it a couple of different ways in
Sanctum verses Keystone. In Sanctum, there's
two sets of page tables, the enclave page tables are
inside of enclave memory. So, that fixes
this page fault attack in the sense that you
can't see those addresses but there's other ways
of doing it including as Dawn mentioned using the physical
memory protection primitive in risk five. So, just to give you a sense of what it takes to
build an enclave. I've shown you this picture
obviously not possible here, but the colors are what
you want to look at, those are the things that
changed, really the interfaces, we needed reset logic for all of the orange colors and
then we needed to add a little bit of logic
corresponding to the blues. So, it's about
a two 2 percent change. This is what I meant
by it's not invasive, at least from my standpoint, in terms of actually
taking a processor or a stock processor and
putting enclaves on it. So, let me just tell you
about status and close. Sanctum has released, it has limited functionality but it
provides secure enclaves, you could run it on
Amazon Web Services, F1 instances that have FPGAs. We invite you to if you haven't done an official release yet but that's happening. John mentioned Keystone, which is I guess next generation. I would definitely like
to look at building a speculative
out-of-order processor. It's not going to be
very high performance because it's academic work, but it's interesting from a standpoint of what
does it take to go build something that's resistant to spectral meltdown attacks without the cop-out of saying, "Well, we don't do
speculation so, we're protected against them." Adam Chlipala gave a nice talk yesterday about his system, his cop system and he's doing open source cryptographic
primitive verification. We have open-source hardware, it'd be wonderful
if we could marry those two and Adam and I and Arvind at MIT have
a DARPA project on doing that. So, that's all I had.
Thanks for your attention. >> Thank you. Yeah question [inaudible]
design mechanisms right? and then somebody has
to build policy and so on and traditionally
we've been lousy at making
sure that software people use things correctly. Maybe we're missing
the right way of documenting things, tools
automatically change, the most canonical
example is that we thought that always end-user
data never get mixed with each other then
some OS person thought there's acute calcium optimization
ofrsomething and mapped the old kernel data into the user address space and there is more dominant
than spectrum. Okay. Any ideas about how
to automatically check for unsaved user to encourage people to use
this mechanism is the right way? >> Yeah, so I think
if you look at the Native Client type
approaches. Right. I mean that's
the best answer I have where I think
you want to runtime inside of the Secure Enclave and I think Dawn may
have mentioned this as well in passing inside of
the secure enclave- actually, no, it was Mark who had
this picture inside of the secure enclave
that's actually sanitizing what
this enclave does. So, now, I'm a hardware person, I do not want to write
that piece of software, but I think that you want to have an essentially an environment
that unintentional errors, obviously there's badly
written programs, but that you also
programs sometimes do silly things and if you want to protect people from
their silliness, you have to have some sort
of layer on top of it. So, I think that's
kind of the right way of doing it. Right? >> [inaudible]. >> Okay good. Should
Dawn just say they do it in Oasis. Okay. >> All right, we have time for one more question while I plug in the power to my laptop. No more questions?
One question, yes. >> How much slower is
the machine that speculation can hyperthreading run than
a normal processor? >> I'm sorry. I stopped paying
attention. Sorry, could you repeat the question? >> How much slower
is the processor without speculation
in hyperthreading? >> Not that much. I mean, I think we're talking- oh, sorry. Hyperthreading would
be about 20 percent, just hyperthreading
would be 20 percent. It's little bit
unclear as to where the 20 percent comes
from, the improvement. Speculation, out of order
speculation is more than that. I mean, I would hazard
that within a factor two. >> Okay. >> Much higher. It's much higher. >> It's much- sorry. >> Much higher than two. >> You can get much
larger than the two? >> Every wrong
speculation its impact would be much higher than two. >> He knows what [inaudible]. >> Thanks. >> But I think the way that we thought about doing
this is really- I mean, there's also
a simple course- there's this other philosophy
that says you can have simple course and you can
have a lot of course. You make the software, a person paralyze
his or her application, right? >> Yeah. >> All right. Thank
you very much. Let's thank Srini again. So, our next speaker
is Peter Pietzuch. He's a professor at
Imperial College London. Peter leads the
large-scale data in systems group in
the Department of Computing. He has done a lot of
research on scalable, reliable, secure, large-scale
software systems, including publications
in impressive range of conferences including OSDI, VLDV, NSTI, and many others. So, we're very fortunate
to have him here and talk about SGX. Thank you. >> All right. All
right. Thank you very much for the introduction, Manel. So, what I would
like to talk about today is some work that
we've been doing over the last couple of years
on thinking how to provide system support for
Trusted Execution in a Cloud environment. So, what got us excited about the
Trusted Execution Model, that it essentially, well, deals with the problem that
the tenant can move to a Cloud environment
without having to implicitly trust
that Cloud provider. But the question here becomes, what system support
needs to exist in that Cloud environment
so that you can actually move
existing workloads? So, the issue is that
a Cloud tenant would effectively think of
the Cloud environment as an untrusted black box. So, there's a very large
and complex stack that the Cloud provider runs with
millions of lines of code, and obviously this is where a large number of
security issues can come from. So, when you have vulnerabilities
in the Hypervisor, in the OS kernel, and so on, they can be exploited with
large range of attacks. Then, similarly,
there's the issue of insider attacks where
people who have privileged access to the Cloud environment themselves can then compromise
the tenant applications. Actually, when you think about existing hardware security
mechanisms that we have, they don't really trying to address this problem directly. Because the regular model is that the Cloud provider actually doesn't trust the Cloud tenant. So, a lot of the isolation
mechanisms that we have, they're all about protecting
the privileged part of the Cloud infrastructure
from tenant applications. But this is essentially
what the Cloud tenant wants is the reverse. So, this is what we thought is exciting about Trusted Execution, that it's a dedicated
security feature that actually gives control to Cloud tenants to protect their applications
and their data. So, one way to see this, when you look at SGX as an implementation of
Trusted Execution, it's actually a
user space concept. So, you don't need to
be a privileged process if you want to create an enclave, and that enclave memories then encrypted and
integrity-protected, and only the protected code
can access that memory, but the hardware will
prevent access from higher privileged parts
of the environment such as the OS kernel
or the hypervisor. So, Cloud tenant can directly, ideally, take advantage
of this hardware feature. But the question becomes, well, so if you are
a Cloud tenant, you want to move
a particular workload to a Cloud with
Trusted Execution, you want to take advantage
of this model, well, how can you do this without modifications to
your application? So, the question here is what is the support
that should exist in that Cloud environment so
that people can actually use Trusted Execution
or Intel SGX. So, what we've been doing is exploring this design space of different types of
systems support that we could offer to Cloud tenants. They're a couple of
things that one can do. So, probably one of the earliest approaches
that was proposed, I would call the
Library OS approached, so this is represented by work that Microsoft did on
a system called Haven, where you effectively take an application with all
of its dependencies, and an entire
library operating system, and you place this inside
of an SGX enclave. So, then you have effectively
a self-contained way of supporting that application
inside of the enclave. Then you're only exposing
a very thin Hypercall like Interface to the outside
to do, well, some low-level IO
operations where you rely on the outside environment. So, when you think
about this model, it has a very clearly defined
interface to the outside. But you potentially have a large trusted computing base because of the library
operating system in all of the systems support that you're putting inside of the enclave. So, we've been exploring
that model with a system called SGX-LKL that I'm going to
talk about more in a moment, that is a library
OS for supporting unmodified Linux binaries
that execute an SGX enclaves. So, another way of designing
system support is to take a slightly different approach
where you reduce the trusted computing base by only placing the application, its library dependencies, and the standard C library
inside of an SGX enclave. So, this is something
that we've explored in a system called SCONE, that does this for supporting Linux applications
inside of SGX enclaves. So, now the interface
that you're exposing to the outside world is essentially the system call interface. So, it's a much
broader interface than more calls that are exposed, but you've reduced
the trusted computing base. Because inside of your enclave, you only have
a standard C library, but you no longer have the
library operating system. Then finally, you can think of partitioning
your application as the furthest that you can go in terms of reducing
the trusted computing base. So, here what we're doing is
we're take an application. We're only taking
the security sensitive functions of that application. This is what we're placing
inside of the SGX enclave. Then we have an application
specific interface to the outside world
of function calls, so that the security
sensitive functions can interact with the rest of the application
that runs outside. So, this gives us
a small trusted computing base, but it does also incur a more complex interface
to the outside world. So, the SDK that Intel released for creating SGX applications follows that model. It essentially gives you
an RPC-like mechanism for placing some functions
inside of an enclave. So, piece of work
that we've done is a framework called Glamdring, that I'll also talk
a little bit about, that tries to help developers
making the decision which functions from
the application to place inside of
an SGX enclave, and what to execute outside. Okay, so let's talk
a little bit more about the Library OS approach. So, what are some of
the challenges with that? So, one significant challenge
is performance. Because enclave transitions
by themselves, they're expensive because, well, the hardware has to
perform particular checks whenever execution transitions
in and out of an enclave. Since we have to exit an enclave whenever we want
to invoke a system call, we will naturally incur those expensive transitions when we run a particular workload. So, this performance overhead
can be quite significant. So, this is an
experiment that we did where we measured the rate at which we can execute system calls when we increase
the number of threads, comparing native
execution with SGX. You can see that
you're losing about an order of magnitude in terms of performance
when you have SGX enclaves. So, for a system call
heavy workload, this is a significant problem. So, what can we do about this? Well, one obvious idea is simply to reduce this number
of enclave transitions. So, try to avoid
exiting an enclave and instead have threads stay
inside of the enclave. So, the more we can stay inside, the less we suffer from
that performance cost. So, how can we do this? Well, one thing that we've done, we used a level threading
inside of SGX enclaves. So, instead of relying on hardware threads
and preemption, we have used a level threading, and those threads essentially
never exit the enclave. Instead, we have
a scheduler inside of the enclave that switches
between those threads. That results in a significant
performance benefit. The other thing is to move some OS functionality
inside of the enclave. So, thread synchronization
is one example, memory management, file system, signal handling, and so on. So, things that normally
would invoke a system call the interaction with
the outside operating system. If you can move this inside
of the enclave, you avoid those expensive exits. So, these are
the ideas that we've then realized as part of SGX-LKL, that provides system
support for enclave. So, SGX-LKL can run unmodified
Linux applications. So, you take an application, all of its dependencies, you provide us an encrypted
file system image, and you can then launch
it inside of an enclave. So, the way SGX-LKL provides
a library operating system, that it actually uses the
Linux Kernel as a library. So, it uses space on something called LKL then external library, which is an architecture
specific port of the Linux Kernel, and we can run this entirely in user space inside of an enclave. So, by doing this,
we for example get a trustworthy file system
and a network stack, that we can then exploit for SGX. So, there are a couple of interesting features
in the SGX-LKL design. So, one is that user
level threading. So, we can do
thread synchronization within enclaves without exiting. So, if a futex implementation inside of an enclave that
we can use for this. So, the other thing that we do, we support asynchronous
system calls. So, whenever the
application actually needs to execute a system call, because we have used
a level threading, we can ensure that the system call requests to simply put into a queue that is shared
with the outside, and we can show you
a different threat while we're waiting for
the result of that system call, and that can also
improve performance, and this is a technique
that we've also explored in the work on SCONE. Then finally, we have
a custom memory allocator, where we essentially do
our own memory management, both for the Kernel and
the enclave application inside. So, if one picture on
the SGX-LKL architecture, so this is what an enclave looks like when we're running
an application. So, we have that encrypted
file system image with the application
that we want to run, and then we have the LKL
library inside of the enclave, and in addition also
standards on C library. So, when we are launching an application using
SGX-LKL and enclave, we will first create
that enclave, we will then load LKL we will boot the LKL Kernel
inside of the enclave, and then the Kernel will mount the encrypted disk image
with the application, and it will invoke
dynamic linker loader to the load the binary
into the enclave. So, when the application
then executes, it then can invoke functions
of the standard C library, and then whenever those functions need to run a system call, then this will then go, become a function
called in LKL and it will execute the
functionality within LKL. If then LKL needs to interact
with the actual hardware because for example
it needs to do an IO operation to
reach a disk block, or it needs to send or
receive a network packet, this is then done
through a set of shared cues that we have
with the outside world. Using our asynchronous
system call mechanism. So, this gives us a significant
performance improvement compared to a model where
we would exit the enclave. There are couple of other things that we had to worry about. So, another one is
signal handling. So, we need to have signals
support but the problem here is that whenever
the process receives a signal, it's actually delivered
to the outside, so what we do is register permissive signal handler
on the outside, and then demultiplex
the signals inside, so that we can deliver them to the correct user level threats
inside of the SGX enclave. So, with this model,
we can now provide a trusted Linux file system
inside of the SGX enclave. We can actually support
any file system that is included in the Linux Kernel. For the encryption and integrity protection of the file system, we can use standard
Linux facilities, like for example, device mapper API for encryption
and integrity protection. So similarly, for
the network stack we can do the same thing. So, we can support any network
protocol that is supported by the Linux Kernel, and then the actual encryption
of packets can happen at lower layer in
the network stack, so we can use layer two
or layer three encryption of the role packets. So, when we look at the interface that we're
exposing to the outside world, it's quite a thin interface. So, we can subdivide the calls into workload-independent
hosts calls. So, there are calls that actually will be called
during the bootup of LKL but they are independent of the application workload
that we're running, and then we have
some Workload-dependent calls, so mostly related to
block IO, and network IO. So, the reason why this
distinction is sensible is that, obviously, that host interface
itself is a side channel. So, we need to worry about protecting those workload
dependent hosts calls, and ensuring that they
don't leak any information about what is happening
inside of the enclave. This is for example
one piece of ongoing work that we're doing is that we
are asking the question, "Can we make this host interface
itself Oblivious?" So, can we make sure
that an attacker that will observe the entire
sequence of host calls, will not learn
anything about what is happening inside
of the SGX enclave. So, SGX-LKL is available
as open source on GitHub, so you can play around with it, you can launch Linux binaries
from an Alpine Linux image, and the other interesting
thing is that, we have support for
managed language runtime. So, you can use SGX-LKL to run the Java Virtual Machine or
the V8 JavaScript engine. So, you can effectively
run Java applications inside of SGX enclaves. Okay. So, this is
an example of using a library operating system to
support Cloud application. So, let's look at
the other extreme of partitioning and application. So, why is that
an interesting thing to do? Well, so what about
if you want to run a really large Cloud application inside of an SGX enclave. So, let's say we want to support Apache Spark inside
of an SGX enclave. So here, we're looking at
a large amount of code, if we place all of this inside of an enclave for example
using SGX-LKL, we potentially looking at many vulnerabilities that
would be in that code base. So, instead, what we would
like to do is simply identify the security
sensitive parts, which is the data that we're processing and job
implementation, the task implementation of the analytics job
that we're running. So, in the research community
the many examples where people have partitioned
applications for SGX manually. So, we've done some work on a system called "Secure Keeper", that partition Zookeeper into security sensitive parts
and then untrusted part, Microsoft did some work on
partitioning MapReduce. So, there are many examples
where people do this by hand, but what we were
interested in is, can we help developers to
ideally automatically determine the minimum functionality
that needs to be run inside of
an SGX enclave to achieve, to enforce a particular
security policy? >> So, we've created
a SGX partitioning framework called Glamdring, and it's a compiler based
framework for partitioning C applications at
the source code level. It works by executing
a number of steps. So, it relies on a developer
first annotating what the security sensitive parts are that should be protected. So, this is essentially
the security policy that a developer
needs to express. So, once they've done this, there's static analysis that we perform at
the source code level, to then understand which parts of that application that
need to be protected. Then we rely on source to
source transformation to create the enclave part of the application in
the untrusted part. So, let's briefly look at
this in a bit more detail. So, first, you need to provide
the annotation and this is simply a source level annotation. So, in the example
of Spark, let's say, you want to protect
the data that initially is encrypted and sits on HDFS. So, say, you would
provide an annotation in the Spark code before it's
being read by the framework. So, you can add a pragma
that says that, data is sensitive and
should be protected throughout the execution
of the application. So, the way we then
use those annotations, is that we use them as part of the static analysis to figure out how to partition
the application. So, we generate the program
dependence graph that captures all of
the data and control flow dependencies between
different parts of the program, and we start our analysis at the particular nodes that were annotated by the developer. And to ensure
data confidentiality, we're interested in
everything that is affected by sensitive data. So, we do a forward
data flow analysis to enforce integrity policy, we essentially do the reverse. So we do a backflip, backward data flow
analysis to understand everything that's may impact a particular result that
we want to protect. So then, what we need to
place inside of the enclave, is essentially the union
of that analysis, and this is then what we consider to be part of
our trusted computing base. So, we then automatically rewrite the source code to implement
that partitioning, and we do this using
the LLVM compiler tool chain. By then rewriting the
application and essentially adding the appropriate enclave
and outside calls, so that we can do
the transitions when we move control in and
out of an enclave. There's actually one last step
that we need to deal with, and this has something to do with the fact that we rely on static analysis for
this partitioning. So, static analysis obviously
makes assumptions about, for example, valid execution in the semantics of
the programming language. The problem is that,
an attacker has complete control over code
that lives outside. In particular, they could violate those invariants
the static analysis used. So, therefore, we need to
make sure that whenever control moves into the enclave, those invariants actually hold. And the way we achieve this is by adding runtime checks that simply verify that
the partitioning is still sound, based on the assumptions that
the static analysis made. So, I'll slide on some results. So how well does this work? Well, so we did an evaluation with
three applications Memcached, DigitalBitBox which
is a Bitcoin wallet, and LibreSSL, a TLS
implementation, and we applied Glamdring to
partition the application, and the outcome was that
between 22 to 40 percent of the application is then placed inside of the enclave
and the rest is outside. So, obviously, there's
no magic here, it depends ultimately on how your application
is structured, how powerful
your static analysis is, and this will then
determine how big the trusted computing
base will be. But it's definitely a way of helping a developer
to effectively obtain a principled way to decide which functionality
they want to protect using an SGX enclave. So, to summarize, so trusted Execution in our eyes has a lot of promise in terms of dealing with real-world cloud
security problems today. But at the same time,
it also creates new challenges in terms
of system support and also tool support to take and port applications
that we have, and secure them using
Trusted Execution. So, if tenants want to run unmodified
existing applications, so approaches that, for example, use library operating system, can help with doing this and effectively doing
it transparently, but at the same time, it is also important
to think but how to integrate appropriate tools with development environments for new types of applications and the work that we've done
with Glamdring with static analysis is one
example of achieving this. Okay, so this is all I
wanted to share and I'm very happy to take
any questions. Thank you. >> Thank you Peter. Have time
for a couple of questions. Yes. [inaudible] >> Yeah. So, the thing
to keep in mind with Trusted Execution
Models like SGX, is that they don't really have, they don't focus on
availability right. So, they don't give
you any guarantees in terms of availability. So, an outside attacker
that, for example, controls the schedule or
the operating system can simply withdraw resources
from the enclave. The enclave relies on
the outside scheduler to run. So effectively, the enclave cannot launch
a denial-of-service attack because its scheduling relies on the outside operating system. But in general, in all
of those approaches, they can't defend against
denial of service attacks. >> One more question? Yeah. >> Did you say something
about the memory [inaudible] >> Yeah. Well, I mean, it's actually not as
bad as one would think, because obviously one
of the advantage of Linux is that it has
been optimized for embedded architectures
and essentially it can run in low memory footprint. So, if we run SGX-LKL, we can fit within current EPC sizes, actually
quite comfortably. So it fits, so it uses
less than 96 megabytes. For some of the
larger applications, we will run out of EPC memory, so we will use SGX paging and the other
performance very much depends on whether
your working set will fit within the EPC or not. And again, for some workloads
that's the case, obviously once you run complex Java applications
with a JVM, yeah, at some point with
the current SGX implementations and the memory limits, you will see lower performance. But there's no
fundamental reason why its future SGX implementations could not have larger EPC sizes. >> Right, thank you
very much. Let's thank all the speakers and this concludes this
session. Thank you.

Be First to Comment

Leave a Reply

Your email address will not be published. Required fields are marked *