 Hello everybody, my name is Jordan Hand. I'm a developer on the open enclave SDK project and Today we're going to talk a little bit about what the open enclave SDK is what problems that solves What we as a project have been doing for the last 12 months where we're headed and then We're going to take some time to go through a demo of what does it look like to develop an application with the open Enclave SDK run it debug it and just kind of dive into some of the tooling around How to develop these applications So I'm going to start by just framing What is the problem that the open enclave SDK seeks to solve if you've seen Another presentation on confidential computing if you saw Stephen Wally's talk on Monday You've probably heard some of these concepts before but I just want to go over them for a minute and so that we have a baseline for Talking about all the other topics so for a long time we've Known how to protect data when it's at rest So this is like on disk when you're when you turn your computer off You can encrypt the disk and when you reboot you enter some password That can be used to decrypt data on this Moving to in transit. This is things like TLS, you know, you can encrypt data from point A to point B But then once it's on the the destination computer or the source computer It is decrypted when it's used So the problem that we're trying to solve is how do you protect the data when it's in use in in memory? and how do you protect it from Maybe components that are on on the same physical hardware Because to operate on the data you need to To be able to hold it in memory. So that's kind of the The framing of the what the problem solves and there's a number of hardware technologies Intel SGX arm trust zone kind of a different model but AMD's SCV technologies kind of operate in this space and this is hardware isolation of some memory CPU state it kind of depends on on the hardware technology, but Protection from other parts in the system. So how can you silo off code and data? To so that it can't be viewed can't be modified by other parts of the system So that brings us to the open-on-clave SDK. So what is it? It's a CNC plus plus SDK for developing apps that target these hardware platforms So if you want to build an SGX app if you want to build an app on arm trust zone We provide libraries. We provide a consistent API interface to run deploy that application on those platforms so another principle that we've kind of sought out to To make as a part of the SDK is that we want it to be fully open-source and transparent and not tied to a specific cloud vendor or a specific hardware vendor and We want to make sure that all the code running with your trusted application code is Auditable by users and but by anyone who wants to look at it. So We provide libraries that run inside of this trusted environment that I'm talking about this this trusted code and data silo All of that should be auditable by Whoever the the trusted party is this is the application developer the person running the application We also don't want to tie These applications to a specific cloud vendor. So obviously I work for Microsoft, but we Want these applications to be usable anywhere where this hardware exists? Beyond that we want the trusted compute base. So this is like The amount you can basically think of it as the amount of attack surface of an application. We want that to be Potentially as small as possible, but also we want it to be composable. So that means that If you have different components, maybe your application needs Certain components like we're going to talk later about maybe you want libc access you want access to the standard C API Because your application is very challenging to write without it You can add that as a layer to your open-on-clave SDK application Along with other libraries that you may need But we also want to make it possible for applications that Don't necessarily need these things. They're maybe doing something pretty trivial inside of of the enclave We want to be able to allow them to reduce the code size of the application as much as possible And that just helps with a audit ability of the code Can you make sure that all the code running inside your application is secure? It's really hard to do that when You have a very large TCP a very large amount of code running in inside of an enclave and then we also want support for Multiple platforms, so we target Windows and Linux and we try our best to keep feature parity with both of those platforms and We just want to provide a Single experience that doesn't change too much When you cross OS platforms, and so we'll talk a little bit later about about what that means so this is kind of the basic structure and we'll dive more into this in a minute, but This is the basic structure of an on-clave application So you have Normal application code you can think of this is just like you know You write your main function and see and and you run it. This is just regular application code As part of that application code you have an untrusted host component. So everything in red is not trusted in terms of of Hardware isolation so it's outside of the hardware isolation boundary Untrusted host that kind of Serves as a connector between The on-clave application and the the rest of the machine and so we'll talk a minute in a minute about more about that The host OS including the kernel is also untrusted, but there it can do some some operations on our behalf without Still without having access to the data So the only part that is Trusted in terms of inside the hardware isolation boundary is the on-clave application. So this is this green piece And so this includes some runtime libraries that the open-on-clave SDK provides as well as the application code that the developer writes And something else just to note really quick is that if you have multiple on-claives running on the same machine Again, it is maybe hardware dependent, but typically these Applications are isolated from each other as well So then The open-on-clave SDK Seeks to abstract most platform specific details. So you can see the the green pieces are what the open-on-clave SDK offers and then The orange pieces we typically take from other projects. So for SGX we use Intel's Platform software libraries their de-cap libraries, which are used for attestation We use their Linux kernel driver their Windows kernel drivers so we We seek to For spit hardware specific stuff keep that out of the project similarly on trust zone we Build pretty much entirely on top of opt-e And so we leverage that project pretty heavily so one thing that is Important to know is that an on-clave application running just incomplete isolation is often not very useful You need some connection out to your normal world So that you can do things like I Have data that is encrypted. I operated it on on it Inside the on-clave application Now I want to send it over the network to another machine. It's encrypted But I want to send it over the network to another machine If I'm just running inside the on-clave I can't do that. So we need to provide a way for the on-clave application to talk to the outside host application and So if you're familiar with SGX great, that's easy. The on-clave actually has access to All of the host memory for the the containing process. So the on-clave lives as as a carved out section of memory in the process and it can access Anything outside that's also in the process For trust zone, that's not so simple There there is not a shared, you know, the simple shared memory model and so for the OESDK we wanted to Wrap that up so that So that it looks consistent across all platforms that we want to restrict how Communication between the on-clave and the host works To what will work on every platform So what we have is a tool called the is called OE-edgerator It takes in a definition file, which is basically just a list of Functions that are e-calls. So these are calls from the host to the on-clave and O-calls. These are calls from the on-clave back to the host And we'll take a look later just out what one of those files looks like but you can basically think of it As a header file. We just provide function definitions and then the OE-edgerator tool will generate Basically glue codes so codes that will do on different platforms different things potentially an IPC call potentially Marshalling memory between The host in the on-clave and the important part is that it does a lot of things for you that if you were to try To do on your own would be easy to mess up. So for example, Marshalling Data from the host so data from the host is inherently untrusted and SGX if you want to you could just read the data directly from the host but It's your that leaves you Sustectable to time of tech time of check time of use attacks you could Well, yeah, that's basically it so The The edge code the glue code will Marshall data so that it's copied from the host to the on-clave when you're operating on it in the on-clave You can be sure that once you've validated the data once you've ensured that there's no dangerous pointers no Potential for leaking data that it is all inside the on-clave memory space. So this is Basically what the on-clave runtime Libraries look like so we have a core library the open on-clave core library which basically serves as an adapter between The platform specific libraries and the rest of the OESDK libraries so on like I said before on SGX we have the Intel platform software libraries on trust zone we have the Opti API's and so we try to build a consistent interface on top of that that then uses platform specific API's as needed Above that we have a syscall layer. So this is we've tried to implement a large number of POSIX syscalls And on Windows, this is actually the exact same We even though it's running on Windows from inside the on-clave you still use POSIX APIs to and that's that's an again an attempt to Make the experience the same across multiple platforms so you can actually take an on-clave application there are all on-clave applications the code running in the on-clave is An elf binary and you can actually take the same elf binary that you're running on Linux and run it on Windows without recompiling the same exact So we have the POSIX syscall layer which is primarily a number of O-calls calls from the on-clave to the host and then the Syscalls are actually run on the host and the result is returned to the on-clave. So these are primarily untrusted calls, but they serve an important purpose for accessing disk accessing Network, so we provide other libraries instead of the on-clave to help you do that securely, but This is primarily a layer that leverages the untrusted host operating system We have a version of muscle libc that you can build your on-clave application on top of so We want it to look as close to developing a normal C application as possible As part of that we have libraries that that call into the Syscall you know the muscle library calls into the Syscall layer for doing and many of the standard C functions and We also provide we publish You know what these syscalls are as part of the SDK and so you can Choose which syscalls you want to use which syscalls you want to Not you know not allow so then on top of that we have again a version of embed TLS for cryptography operations And then on top of that we have an attestation layer. So this is for generating Attestation evidence. So this is you know in SGX. This is often an attestation quote Um And then finally we provide a C++ library built that we run on top of muscle libc So you that you can actually write C++ applications inside of the on-clip so I mostly went through all of these so we'll just kind of Skip through Each of these slides um Something else that we provide is host libraries for things like enclave creation Interfacing with platform or specific libraries like I talked about before And as well as Kind of primitives for doing the the enclave to host communication Additionally, we have a separate host verify library And so this is for evidence that is attestation evidence so that is generated from within an enclave We have a standalone library that can be run on any Any machines that can verify that evidence. Um, and so there's actually a lot of current work going on to Standardize this across Um Environment platforms because attestation evidence looks different for different hardware vendors different platforms um, and so we want to provide a consistent api to Generate this evidence and then verify the evidence So that's actually some some really cool work that people are doing in the project right now And we're kind of defining what that looks like um something else that we've Strive to do that I talked about a little bit Is make the the experience look consistent on regardless of the host os because The idea is that the host os doesn't really matter what you care about is the The code running inside the trusted execution environment and so We don't want the application to really have to care about what the host looks like So we've provided again a consistent api layer that then Calls into platform specific libraries on On linux or windows so for example for the host verify library we have The cryptographic operations on windows use the crypt they use win32 apis they use the windows See runtime on linux. They use open ssl. They use product apis But from the application from the oe application none of that really matters. They just use oe specific api and then we I talked about this at the beginning with kind of composable tcb size, but we want to Allow application developers to make the choice between Code size on a tech surface and usability and that's not a yes or no Decision that's often a spectrum of my application is is just too hard to write without certain libraries But at the same time I don't want to just allow any code to run in the enclave So giving application developers the ability to make choices about what What code is running in their enclave and being able to add or take away from that code size is Is an important kind of tenant of the sdk So another thing that the open enclave project seeks to provide is kind of tooling to make Developing these applications a lot easier So we want tooling for For signing and for quote verification and In compilation to be Pretty pretty much the same across platforms. That's another thing that is kind of in progress right now Integration with debugger platforms and and idees to Make whatever tools you're using Work with enclave applications and then Modes for simulation and emulation to When you don't have access to SGX hardware or trust zone enabled hardware that you can still Test your application Develop rapidly and then when you can deploy on hardware you just pick it up and it works So some really exciting work that we've been doing in the last 12 months is Adding support for debuggers to more platforms. So we have a gdb plugin that Kind of has been the the mainstay of debugging for oe applications And i'll demo that in a little bit Recently we've also come out with a win dbg plugin Visual studio plugin so you can see in the bottom left our visual studio code plugin A lot just works the same as as any cnc plus plus debugging That you would be used to and we have the same experience on full visual studio as well and then we I talked a little bit about simulation and emulation. So on SGX we have a Almost full simulation mode. So we Basically have implemented everything that SGX would do itself And we've we've written a simulator so that Pretty much everything behaves the same as it does in SGX but running on any x86 hardware Um, I'd say pretty much we don't support attestation primarily because keys are typically in hardware and there's really no no secure way to Generate something that that you could use that would really be usable Um, and then on the trust zone off the side we have instructions for running in a cumio emulator And so that's kind of the same thing. You don't need you don't even need arm hardware to run an oe application for opti So what do we want to do? in the project looking forward one thing that we've Really looked into Recently we've been discussing a lot in our meetings. Um, and I'll talk a little bit later, but Everyone is welcome. The community is welcome to to join in on any of these discussions Um, is a consistent plug-in api so that a new trusted execution environment can add support and Add support for that platform to the oesck in a consistent way so we want to provide a set of apis that a platform must implement To then support all the other features I talked about that layer on top of that um Another thing is is a discoverable support matrix. So We support maybe some features are can be supported on sgx and then some features You know some of those same features don't work on Trust zone for a number of reasons. Maybe the the memory model is too different to support a certain feature um, but we want to make sure that the application can figure out which features are supported on which platforms Preferably at runtime and then the application can can make decisions based on On that support matrix and then another thing we're striving towards in the the coming months is a stable public api. So we are a pre v1 project and so so far we try to keep the api as stable as possible, but Some things we just realized that hey, we did this two years ago and this doesn't make sense anymore so We've had to make some breaking changes to the api, but We want to in the next couple releases get to a point where that api is stable And so those are also discussions that are that are going on right now. So This is actually from a diagram from one of the designs for creating a plug-in api for plot for various platforms Um, and I've actually I've linked the the markdown file for this design. So all of our designs go into They were reviewed as markdown files in prs. They go into the repo. Um, you can Go take a look at any of those designs and so We really want to invite people to to come be a part of the project and help us make these decisions if you want to develop Applications for for these platforms, but maybe use the a feature that Isn't there or something that you'd like to behave differently We want to invite people to come join us because these discussions are happening right now Pretty much none of this is set in stone so let's talk about something that is is fun for me to look at is how the project has grown and changed in the last 12 months so Some of the other contributors to the project gave a presentation on On the open on clave sdk at this conference last year And so I want to take a look at what has changed in that time and Kind of what what the project looks like now so We're seeing about 20 to 60 commits per week. That's actually down a little bit from 2019 That's 1200 commits in total Which is down Actually quite a bit from 2019 and you would think you would look at that need to say Well, I mean are people leaving the project? What's going on? But I actually think at points more to stability in The last 12 months there's been a lot less churn than the previous 12 months in kind of core pieces of the code base and so There was kind of a period where there were tons of changes going in lots of of moving pieces lots of things just Didn't didn't work quite right. We Also added a large number of features. We added Support for opti. So that was just a lot of churn in the code base and we're kind of settling down to a point where We don't we don't need quite so many commit per weekly Things things are actually pretty stable at this point And so we're just trying to refine it more and you can see that the project is is growing in that There we have over double the number of forks from 2019 We've done four releases um in the last 12 months and we're looking to Kind of come up with a consistent release cadence To get consistent releases out there so This year we had 61 unique contributors to the project something amazing is we actually had 63 unique reviewers So that means that almost everybody who's contributing to the project who's submitting ball requests his writing code Is also reviewing other people's code And I think that's really cool for a project. That's maybe not something you see in a lot of projects That people are really interested in In helping out others. Um, I think we have a really cool culture of accepting new contributions new contributors and really helping out new contributors to To get them started on the project. So that's that's actually really cool to see We also have committers from five different organizations So this is a project that started out as a microsoft project Was donated to the linux foundation about a year ago And we're seeing the the contributors to the project grow outside of the bounds of microsoft and that's really cool to see Something else that we've been Kind of working towards is making all of our communications open when you start as a project inside of a company Sometimes that that growing into the open can be challenging But I think we've done a great job of we've recently made every meeting that we have about the project Is completely open to the public. Um, we provide links on our mailing list links on our github repository And there's a a calendar of when these meetings occur So anyone in the community can join any meeting we have about the project We've created a number of special interest groups around out of station If he eyes in architecture testing and tooling And so these groups kind of have their their own separate meetings that again anyone can attend and It's it's allowed the project to move a lot faster in that Um as as a smaller group, maybe you make decisions about out of station You have people in these meetings that all have a background in in the code base They understand what the needs of out of station are and that allows those discussions to move a lot faster Um, and then something else we're moving towards is open ci. So this is um anyone can access any of our ci runs and we're trying to get to a point where anyone can actually run their own ci runs on on the project's infrastructure um yeah, so For the rest of the time i'm going to go through a demo and we're just going to look out. What does it look like to develop an oe application? Um, what does it look like to to debug an application? What is that tool and look like so? Let's see if I can switch over pretty seamlessly So here I have a demo application um That I wrote a little bit ago. It's pretty simple um We have A host side. So let's look at that first because that's going to be the most familiar to most people just a minute so We have a main function. This is just you know your your standard ci application um We have some creation code. So this is setting up the application the uh enclave telling it which What's the enclave binary I want to run? um some flags so you can see I've passed a debug flag and um Simulation flags so this allows me to run in simulation mode Um, and this allows me to attach a debugger to my enclave code And then I just pass all that to a create and that create that Creates a siloed um section of of code and data Um for me to run my enclave in And then we'll come back to this in a minute, but we also have a call into the enclave and we get a value out and we Uh print it up and that's it. That's all the application does at this point. Let's look at what How how i'm going to build that host application it It will look pretty pretty familiar the only thing that um Maybe looks different from your traditional application Is that you can see this tool that I talked about earlier this oe editor tool um, and I'm going to pass it my my interface definition file and It will generate a c file that implements that glue code that I talked about earlier Otherwise, it's it's just pretty much um, what you would expect Well, let's take a look at the Interface definition So you can see I have it is kind of like a a pseudo c-like language, but uh It can define trusted Function calls so this is calls from the host to the enclave and this is Just it will this is to provide editor some definition for how it will Generate the the glue code I could also Write an untrusted function Which is a call from the enclave to the host And it basically looks the same I can give parameters I could pass pointers you know, etc so then in the enclave You can see all I have is the definition for whatever e calls whatever enclave calls. I defined in edl So I defined the interface in edl and then here I have of What the implementation of that function does so I have a function that just adds two numbers that were passed in as parameters And you can see that editor also generated a header file for me Which defines this function and it Generates a host side header file as well. So on the enclave there's a little more interesting things going on in the build So you can see Here it looks kind of the same as the host we generated We generated a c step file for the enclave side We're compiling You know the same same way we did before and then On the enclave side, we also want to sign the binary so that when it's loaded by sgx the signature is validated by to be a trusted Party and in the attestation report for the enclave it will show who signed it. What was the the signature contents What was the hash of the binary? That was loaded into the enclave So those can all be validated at runtime by by some other party that wants to to trust the enclave running So here we just generated a key pair and used the oesign tool which will Generate a platform specific signature for the binary Um, actually really quick You'll find out that there's a On file that I passed at signing time and this defines Some basic things about the enclave. So this is how many memory pages I'm going to load How many thread structures I have and this is kind of platform specific information Is the Enclave debuggable if I don't allow it to be debuggable then I can't pass That debug flag that we saw earlier and I can't attach a debugger So there's kind of some some configurations you can do at signing time so that if you want to sign an application for debug mode or for You know your production mode that you can do that without changing the code So let's go ahead and build this application going to just We already I previously installed the oestk At this location at this off to open enclave location And this file that i'm sourcing is just to set up my path so that it can find My package can take files basically So that was pretty easy. I built the application and then let's go ahead and run it So I we can see in our host we just told the enclave add the number one and two And print the result and so you can see we added the number one and two and we got three So let's look at what does it look like to attach a debugger to The separate points so we have this oe gdb Which is basically just a thin wrapper and a python plugin to gdb And we will go ahead and run it Run the application under that. So let's go ahead and just break on main really quick So this is in the untrusted portion. This is you know, no No oe plugin magic going on here. This is just a normal gdb. It's great. So we have We have our our main application. We we break them. So let's look at Can we set a break point inside the enclave? We want to check out what is what is this function doing? Obviously, this is very simple, but Um, you can see how it would be useful in in other cases. We are going to set a break point on the ad nums equal Um, this is actually you can see it set a break point in sample underscore u dot c That's actually still on the host anything The underscore u is the generated host code. Um, so we're actually going to break really quick in the glue code But if we continue again We see that we have a a corresponding function inside the enclave that we've uh broken on so we're going to an a print b Great, we got the values we expected u and we we exit normally so This is Basically looks, you know, as you'd expect. This is the exact same as attaching gdb to any other application Under the hood. There's a lot more going on For how do you You know make the stack look the same across the You know the host to enclave function call boundary. How do you? Marshall parameters, etc But from a usability perspective, it basically just looks the same So cool That is pretty much all I have you can start dropping questions in Oh just a minute You can start dropping questions in the chat and I will Um answer them as they come in. Thanks everybody so First question is is this only targeted for cloud or does this apply generically such as to embedded systems? so It kind of depends on what hardware you want to target so for um the arm trust zone Opti support this is primarily on Embedded systems iot devices. I don't really I haven't seen much use of Of the outside of of that space. Um, maybe maybe it exists, but not that I have seen um a lot of sgx usage is in in cloud on server class devices, but There is also sgx support on client devices So so it's pretty much to answer your question. No, it's not just for cloud It just kind of depends on on what hardware you want to target, but the stk in general is is aimed at Any any enclave applications you want to develop for any hardware pop um This is kind of a similar question does open enclave target microcontrollers like arms tf-m um, we target any arm platforms that support opti so I don't know a ton about the The arm board space, but anywhere you can run opti you can run open enclave Okay, does the project use some kind of security test slash verification on the code so We have A number of people that do um security audits of The code We don't have I guess I don't I don't know exactly what the question is asking if there's a more maybe formal security verification um that you're looking for there's That i'm not familiar with but we do have people looking at the code um Looking for security vulnerabilities. We address them as as they come up. Um, I don't know if that answers the question What are some of the milestones on the roadmap for the oesdk in general? So this is pretty much what I talked about earlier. This is um a stable api is a really big one. Um the as as an sdk platform we that wants to kind of target multiple hardware vendors and Make it easy for anyone to write an application and run it wherever Having an api that doesn't change is pretty important for that. Um We don't want to be breaking our users on every release. So that's I would say a pretty big milestone that we're shooting for um another Another thing that we're shooting for is making it easy for hardware vendors or people that want to add support for more platforms to Come in and do that in a consistent way How can you know, what's the advice we give to people? What is the are the platforms and tool the Tooling we give to allow people to implement that Okay, so for the question earlier about This open on clave target microcontrollers like arms tf dash m Someone dave on the project has answered that we only support tf dash a not tf dash m What os is run inside the enclave? So Again, it depends like I said on trust zone It's running it's running off the os on sgx. There really is no operating system. We actually Have specifically built the You know the libc in the in the library layering just Directly on top of oe library codes so the The kind of this call layer that I talked about earlier relies primarily on the host operating system But other than that there's no operating system running inside of the sgx enclave that All i'm seeing so far So i'll give um, I think we we only have like a couple minutes left, but i'll give a couple minutes to Wait for any other questions to come in Is there already any use case in other projects? um, I don't Quite know what this is asking. I guess does Oh, actually it's the open on clave sdk used by other projects. So we do have A few projects that we do know use the open on clave sdk as as the basis for their Um project. So that is the the ccf confidential computing framework. Um You can go check that out on github. They are built on top of the open on clave sdk There's also a project that was announced recently called sgx lkl and this is an attempt to run the Linux kernel as as the Linux kernel library Which is a library os that Mostly reuses all of the Linux kernel code to run that inside of sgx so that you can run unmodified linux applications inside of an sgx enclave And that that project is built on top of the open on clave sdk as well. All right, so it looks like that's about it for questions Thanks everybody for attending I will probably be in slack for a little bit after this and I'll be in the confidential computing consortium booth for about an hour In a couple of hours here, so thanks everybody. Have a nice day