 Hi folks, I'm sorry we're a bit late and it's really good to be with you. This is Mike Brasile from Red Hat and I'm joined by Nathaniel McCallum also from Red Hat. Sorry we have video problems but as long as you can hear us that's the most important thing. Nathaniel can you hear me? I can hear you fine Mike, thank you. That's good, so let's assume that everyone else can hear us. So we're going to be talking about running sensitive workloads on untrusted hosts and specifically about our project NARCS. So NARCS is an open source project part of the confidential computing consortium and we'll give you a bit of detail as we go through. But first of all what is the problem that NARCS is trying to solve? Well it's about the need for confidentiality and integrity. Whatever sector you're in, whether it's banking and finance, telco, HIPAA, whatever just a standard enterprise, you will have sensitive enterprise functions. Whether you're deploying in the cloud, on edge, in premise, there are certain things that are sensitive. And when we talk about security in computing and on the cloud etc. we tend to talk about isolation. But there are three types of isolation. So I want to go through those briefly now. So let's consider that we are on the cloud in this example and we have a host which is in red if you can see red there. And we also have a tenant and the tenant has a workload on the host and there's another workload on the host as well which is not owned by the tenants and by a different tenant. So the first type of isolation we call workload from workload isolation and that is when a malicious or compromised workload is trying to either see inside i.e. break confidentiality or in fact mess with the data or the running execution of another workload. That's a bad thing obviously. You need to help on that happening. Luckily, this is something which is pretty well known how to deal with. Both VMs and containers have some pretty mature controls actually about stopping this happening. So we'll call that type 1. Type 2 is where a workload tries to interfere with the host. It may be trying to break out. It may be trying to look at memory. It may be trying to change memory. But again, this is not a good thing because we want to protect the host from malicious or compromised workloads. So again, actually we've got some good news here because the technology is pretty mature here. Again, we've got things like SE Linux or hardware, VTX controls, whether that's on containers or VMs. We're actually pretty good at stopping this most of the time. So that's good. But what about a third type of isolation? Well, that we can call workload from host isolation. This is rather tricky. What we're basically trying to stop the host looking inside with, looking inside, sorry, or trying to change the workload. Now the way that containers and VMs are generally run on hosts, this really doesn't work. We don't have controls with existing technologies that allow us to do this. So what do we do? And why do we care? Well, we talked about protecting sensitive workloads. Let's say you work in a highly regulated or compliance heavy sector like healthcare, finance, government enterprise, which have specific things like telco. Or you're maybe running on a host which is itself vulnerable. Maybe it's out on the edge. Maybe it's somewhere where people can compromise it. Because if they can get in, they can mess with your workload. This is tricky stuff. And it doesn't matter whether the host is itself malicious or it's being compromised. If it wants to look inside that workload, it can. There's actually quite a nice picture of the virtualization stack from that XKCD about a year old now. Talking about all the different places, things can get compromised. Hopefully we don't see this everywhere. But so Nathaniel, I think because of the slides, I'm afraid I had a power cut here. Are you able to hear me? Yes, I can hear you. To the next slide, do you think 14? While I wait for the things to come back up. I don't seem to be able to advance the slides. Trust. There we go. Wait. I will come back. So I'll take over since Mike's having difficulty. So basically the way that we can try to counter this third avenue for attack, the host to workload attack, is by using a new technology called trusted execution environments. And apparently it's going to take me very long to switch slides here. I click in and it does eventually go. There we go. No. Okay. So basically a trusted execution environment is where we. Mike, are you back? Okay. So a TEE is basically a protected area within a host. And it's important to note that this protection is actually enforced by hardware, not by software. So it does not have the properties that we have when we're using software protections in this way. And basically what we want to be able to do is we want to set up a TEE and we want to be able to attest to that TEE cryptographically verifying its contents so that we can deliver things like the workload and the sensitive data. And if my slides would advance, a TEE basically provides memory confidentiality, integrity, protection, general compute, and hardware random number generator. These things effectively isolated from the host. One thing to note in particular is that we in the, in the NRX project are worried about generalized compute. So things like specialized compute environments are not as interesting to us. So this is our definition of a TEE. And it does take forever for my slides to change. Okay. So how do we know that is a valid TEE is one of the important questions. And this is where we need to do our cryptographic attestation. So we need some kind of measurement on the tenants that proves that the code that's running inside of the TEE is only the exact thing that we want to be inside of that TEE. And we need, we need this to be able to establish an encrypted channel to that TEE. I don't know if technical support can hear me or not, but it takes a very long time for me to switch slides. Please click on the next icon. Right side toolbar of your screen. I don't see a next icon on the right toolbar of my screen. Nice to know. I can help you to click on the slide. I'm back. I'm back, I think. So what slide are we on? We're on slide 20 now. 20. Yep. Yeah. So the basic idea here is we want to, please go back to slide 20. Okay. So we need, we need to provide an attestation to the tenants that measures the TEE to show exactly what's in it. And then once we do that, we can establish an encrypted channel to TEE so we can deliver things like code and data under a encrypted channel. So attestation needs to include things like a measurement of the TEE itself. We need some kind of hardware root of trust and we need to be able to do a Diffie Hellman to create a session key with that TEE. So next slide. Sure. So I should be able to take over now, I think. So what we've got now is the ability to protect our workload from a host, which is malicious or compromised, which is what we're trying to achieve for that isolation, the third type of isolation. So these sound great. However, life's not quite as simple as that. First of all, there are multiple different implementations of this. The main two at the moment are AMD's SEV and Intel's SGX. There have been announcements from IBM that they're planning to do a different one. But the problem is that each time you design a workload, you're going to have to design it differently and develop it completely differently. And that's not a good thing. And the next thing is that for each of these different approaches, you're going to have to choose what language you do it in because there are different SDKs to support. So are you going to do everything in C, everything in C++, or everything in Java? How does that work? The next thing is attestation. So Nathaniel already mentioned attestation. Attestation is basically checking that the TEE you have is a real one, that it's not someone's spoofing. And actually doing that attestation is difficult, partly because there may be changes, vulnerabilities may be discovered, for instance, in different chip sets. And being able to react to those and make dynamic trust decisions is very complex. The last one is related to that in that we've seen already quite a few vulnerabilities being reported against, for instance, SGX, not only then. And how do you decide where you should deploy your workloads? Is it safe to deploy your respective workloads to a particular generation or a particular version of a chip set? So this isn't perfect. If you just want to deploy workloads, we used to be able to point a workload out of a particular host and just run it using something like OpenShift, Kubernetes or OpenStack. This isn't easy in the current world of TEEs. So introducing the Dragon or introducing N-Ox, this is the problem that we are trying to solve with N-Ox. Making TEEs usable and still maintaining the levels of security that people require. So just a brief overview. First of all, we use TEEs for confidential workloads. In fact, we support SGX or we will be supporting SGX and SGV and looking to support others as they come along. We intend to make it as easy as possible to deploy your workloads and we have chosen WebAssembly as a runtime. WebAssembly is becoming enormously popular at the moment. We maintain very strong security design principles. We are absolutely intending to be cloud native and it's open source. Of course, this is an open source summit, the open source summit and it's currently a project, not production ready, but it's open source. So I'm going to hand you over to Nathaniel again. Nathaniel, do you want to briefly talk about this slide? Sure. Thanks, Mike. The key principles here for N-Ox are that we don't trust the host owner. I think that should be pretty obvious. The second one is that we don't trust the host software because at any point it might be compromised even if it's very well engineered. A third point is that we don't trust the host users. There may be, for example, a rogue admin running on your cloud. They currently have all of this access but for whatever reason they want to have access to your data. So we don't want to trust them either. We also don't generally want to trust the host hardware, although there is obviously a major exception here for the CPU and firmware. But things like, we are already, for example, aware of the industry of things like TCP and engine offload attacks, things like that. So we don't want to trust that hardware if we can avoid trusting it. And so this leads us to the 10 N-Ox design principles. The 10 N-Ox design principles are that we want to have a minimal trusted computing base. We want to have a minimum number of trust relationships that is minimum number of parties that we trust. We want to have deployment time portability so that you can take a workload that is prepared for deployment and you can move that from one host to another and it doesn't matter what the CPU is or what the specific hardware technology is. We want that at deployment time. Number four is that we want to ensure that the network stack is outside of the trusted computing processes that have come to us historically through the networking stack and we want to avoid those as well. Number five is that we want security at rest in transit and in use. So all three is what we are aiming for and we think that that is a new bar for baseline of security. Number six, we want auditability so all of our code, we care about it significantly when we're doing pull requests and things to make sure that it's written in simple straightforward ways so that it can be audited and of course it's all open source which is our next principle. Everything we do is open source so open source no exceptions. Number eight is that we want to use open standards. So for example, the interface between the application and the deployment platform is the open standard WASI which is used for WebAssembly. So this is a standard, you don't have code to NRK specifically, you can deploy existing workloads using existing standards. Number nine is memory safety. We care a lot about memory safety and this eliminates an entire class of attacks. So we chose of course WebAssembly here for the workload deployment which gives us very strong memory safety promises and then for everything that we are writing in native code we write in Rust which also has very strong memory safety promises and of course we support the adoption of backdoors so we have a commitment not to backdoor the NRK platform. And we probably have a cross jurisdiction and cross country multinational development team so when none of us is beholden to all of the we don't have everyone beholden to the same jurisdiction which is a nice position to be in. So let's just have a bit of a talk now about the runtime architecture. This is a somewhat simplified picture of the architecture but it does bring out the main thing. So let's look at the bottom for a start. There are two types of trust execution environments. You'll see the Web Keep there. We use the Web Keep to describe a trust execution environment with all the runtime and protections that we put in it. So an Arts Keep is what you deploy into. So there are two different types. There's the process-based Keep of which the most well known is SGX from Intel and there's a VM based Keep of which the most well known at the moment is SEV from AMD. And above that we've got some Web Assembly pieces and above that the application and any language bindings. What I might do is let Nathaniel talk a bit more about the Web Assembly layers. We already mentioned those W3C standards but do you want to go into a bit more detail about this? Yeah, one key point as I emphasized in the previous slide is that we are using the Web Assembly engine as the target for our payloads and the Web Assembly system interface, WASI for the system interface between Web Assembly and the things that it needs to ask the host to do on its behalf. It's really important to note that these are both W3C standards. So as I mentioned before you don't have to write against NARCs you just have to write using your normal language and your normal tooling using the existing Web Assembly tooling that your language provides you and then you can deploy it with NARCs. And there are many, many different languages which have a target compile target. So you can write in C, C++, Java Rast, Go, Haskell, Python and compile the existing application into Web Assembly. So let's talk about the layer below that as well. I mentioned it a bit, Nathaniel, but do you want to maybe describe some of the differences at the technical level? Yes besides the Web Assembly engine the majority of our native code goes into making the specific technologies that we want to abstract across compatible in order to expose this upper layer. So we get things like support for process based keeps. These are things like Intel's SGX. Risk 5 is also developing a thing called Sanctum which is similar in how it works. And then on the right hand side we have VM based keeps, things like AMD's SCV, IBM Powers, PEF and Intel has a technology that they have started to develop it currently goes under the name MKTME. And these technologies of course are all rather different under the covers, but we want to be able to make them all expose that W3C standards compliant layer at the top. So that is essentially how the bottom layers work. And you can see here basically how we actually build this up. So our root of trust of course is always in the CPU and above that we have two major components. The first is the host kernel and obviously the host is going to need to have a kernel to run and we also have the NARCs provided loader. So this is something of an NARC ship but notice explicitly that it's distrusted. So even though we ship our loader we distrust our own loader. This is because it falls outside of the security boundary that we want to enforce. And so those bottom pieces are explicitly outside of our trust domain. Inside of our trust domain we have a technology called a SHIM and the basic idea of a SHIM is it's rather different on each technology. So for example it's separate code on SGX and separate code on SEV. But the basic idea of the SHIM is to adapt the specific hardware technology to have a common interface for our WebAssembly JIT on top. And that's more or less where all of our architecture dependent code lives. There'll probably be a few exceptions to that but the majority of the platform specific stuff will live inside of our SHIM. Above that then of course we have our WebAssembly JIT which has a thin interface of WASI on top of it which is exposed to the application. It's important to talk about trust. As I mentioned before the CPU is trusted. The kernel loader is explicitly distrusted and everything else is trusted via the measurement that the CPU provides us. So we actually get our ads a station of everything that is above and inside our trust domain. This is what it looks like for example on a process-based keep like SGX. The next slide is going to show you what it looks like on a virtual machine stack and you'll notice that it's actually pretty much the same thing. The only big difference is how the loader works. The loader in the case of SEV is a virtual machine manager. So it's a very custom build, very, very small, lightweight one, but that's essentially what does it and then our SHIM is something like a microkernel, very small designed for one specific purpose and written in Rust. So I think we should probably move on to the demos. I'm hoping the demos will work. I hope that this will work. So where are we? So this is to remind you what the picture looks like and this is what we're going to be talking about. So we'll talk first about SGX. So for the demo we are not looking at the WASI or the WebAssembly layers. We're looking solely at the pieces that are required in the actual key, because this is an early stage proof of concept demo. So as we move across here, what we want to do is have an application which runs in SGX. So let's see if we can show a demo. Are you seeing this? I don't see anything but for our viewers, all of our demos are available on our website. So you can go to narchs.io and go to the wiki and the demos will be available there. Mike, are you able to get it working? Okay. So I'm hoping you can now see this. No, it's not working. So this is should say far from perfect. Okay, so let's carry on. I'm very sorry about that. Yes, please check out our website. Please check out our website narchs.io That's correct. So let's carry on. So we basically do the same thing with SEV and again we would be showing you a demo which is certainly not working. The moment, please. I hope so. I cannot see them. I think we have to move this screen here. Here we go. I've stopped sharing. Perfect, I can see them. Okay, fine. So basically what we want to be is that we could run the same application on top of both a process base key and a VM base key. And indeed that is exactly what we have just done, the same binary. And if you had seen the demos, you'd know that these were screenshots from the demo. And one is on SUX and one is on SEV. And in fact, they're running exactly the same picture there. Something weird has just happened to my screen. It's exactly the same static-elf binary that is running in both. Or rather static-py binary. So what we've done here is we've emulated the Linux syscall ABI layer on top of these two different technologies. This is we consider an internal interface, so we are only going to implement those syscalls for example, which we absolutely need for the rest of the SAC above. But it does provide a common layer for us to build upon. Okay, what can you see on the screen? I see the Are we seeing the right thing now? I've just received an M. I can see the where we are. It's the same yeah, the same static-py binary running on top of our shim basically. And as we mature these shims, our plan is to move upwards on the stack and be able to implement our WebAssembly piece. We actually do have an early implementation of WebAssembly that is running WebAssembly binaries, but it doesn't do it on top of the existing hardware technologies. So it's more a matter of porting existing code at this point. So we hope to have a demo on that for ever soon. So yeah, where we would like to be next is... Let's talk a bit. Go ahead, Mike. Yes, so I said where we want to be next, which is putting the other bits on top, which is the workload and the WebAssembly stack. So let's talk a little bit about the wider project, because this is not just about the runtime. There are other pieces like the application. So here's a fairly simplified picture of what's going on here. So on the left we have the keep which has the n-arcs runtime and the application. And that's what we've been talking about. That's all trusted because it sits inside the green colored TE. Below that we have the n-arcs host agent. As Nathaniel already mentioned there are parts of that which are not trusted. So we need to be very careful about making sure that nothing in there that needs to be trusted. On the right-hand side we have the n-arcs client agent. So that would normally be addressed by either CLI or an orchestrator such as OpenShift, Kubernetes, OpenSpack. So what you might do is say, please create a keep for me and put this workload in it. So the n-arcs client agent will talk to the n-arcs host agent and work with it and the CPU and firmware to create a keep. And if that is attested correctly i.e. if we convince it's a real keep and we have cryptographic proof that it is, then we encrypt the workload so that it can be sent directly into the keep. In other words, at no point is your workload or any of the data associated with it unclear on the host or on the network or in storage. It's always encrypted from the time it leaves the n-arcs client agent all the way into the n-arcs runtime. We said we don't trust the host. We don't trust the host in the actual execution. We don't trust it even in the loading and provisioning. So there's lots of pieces to be done there. So this is a draft and rather simplified version of some of the bits and pieces that need to be going on there. I won't go into this in detail. This is currently a pull request on our website in Git. I'm talking about all the different bits and pieces and this is in fact simplified. It doesn't talk about some of the critical critical approach called establishment, for instance. This is the stage we're at at the moment. Do you want to add anything to that, Nathaniel? No, just we are moving up the stack and if you're someone who has experienced deploying applications and have specific opinions we'd love to hear from you. Absolutely. So last very near last slide we've had problems with formatting here obviously but we want to make the point we're an open project. We believe very, very strongly in openness. The code is open. The Wiki is open. The design is open. The issues in PRs are open. So if you have a question if you want to submit a PR you can do that all on GitHub. We have a chat which is open to everybody. It's our rocket chat chat.nr.io All of our CI and CD resources can be used. So if you push something as a PR all the testing in CI and CD will happen in the open. That's on packet IO and we'd like to thank packet and rocket chat for providing us with those resources. We have stand-ups every day of Monday through Friday. Those are open to all please come along. And we take diversity very, very seriously. We think we're doing okay. We have two guys here speaking but we have a course diverse team and we have a contributor a covenant code of conduct which we take very seriously. So we really welcome anyone who wants to come along. This is our last slide. We want you please come along and I noted some questions in the Q&A which I get it's now time to answer and if you have anything else you want to say Nathaniel. No, that's it. Thank you all for coming. We really appreciate talking about this. We're really excited for the future. So help us come build it. So a few questions someone asked what is the website? The website I've asked about is HTTPS colon sign slash nrx.io I've been moving to nrx.dev at some point but at the moment you'll find us there on nrx.io Another great question is what is the relation with open enclave? Some features of nrx are they competing with open enclave? So open enclave is another project which is part of the confidential computing consortium which is the Linux foundation project to encourage use of trust execution environments in open source and it's from Microsoft and we speak frequently to the folks from that project. The answer to that is that they take a rather different approach and we expect different use cases to be appropriate for nrx and some for open enclave. There may be some overlap but their approach is more of an SDK approach rather than a runtime approach. So you design your application using that which gives you different options for how you deploy things and how you use them. Nathaniel, do you want to add anything about difference with open enclave? Yeah, I think that open enclave is a great project. I think Dave is even here who's one of the people that works on that project, Dave Thaler from Microsoft. It's a great project and I think that we really are targeting different use cases. In particular nrx is using tees to solve one particular security problem but we see ourselves as a project that is more than just tees. We really want to provide a cohesive environment for deployment of web assembly applications into the cloud and that is a more general problem than the tees specific problem which may have other use cases that we don't intend to target. I'm quite happy for us to collaborate where we can and I think both projects are great. So thank you for the question. Yeah and I would add that if you have any questions that you'd like to ask on chat later on Dave is I think going to be available as well Nathaniel and I certainly I will be at the ccc complex computer consortium chat. If you go to the sponsor hall and I think we're in the Silver and Bronze exhibit hall B you'll find the confidential computing consortium. We'd love to see you there and we're very happy to answer any questions or to try to answer any questions you have. So there's another good question from Minway Sheep I hope I pronounced that correctly. I apologize if I haven't. Can I implement the Wazem chip or will we use an existing open source one? Good question Nathaniel, talk about Wazem time. Yeah, so we use the Wazem time library which is an existing project that started out life at Mozilla but NRX and Red Hat are one of the co-founders of the bytecode alliance which is currently attempting to drive Wazem time as well as Wazem time in particular. So the answer is no we have not reimplemented the Wazem chip from scratch and in fact we are using a library that has contributors from all over the industry not only Mozilla but also hardware vendors silicon vendors and many other segments of the industry are contributing to so please check out Wazem time if you'd like to talk about Wazem project. Yeah and we hope very soon to be in a position where you can actually start playing with our implementation and our use of Wazem time. Dave Steyler is in the chat and it reminds me that the Confidential Computing Consortium had just this last few days published a white paper as an introduction to the work of Confidential Computing Consortium and providing some definitions of some of the pieces that were out there. So what else we got? I wish I wish we're working very hard if you come and join us maybe we can make it ready sooner but I'm available yet we are we're working hard on that. Here's another one from Minweshi how does NR support accessation over the jitter application? Yeah A very interesting question because it will go for that if I add... So basically we are working on accessation as having multiple layers so the lowest layer of accessation is the NRX runtime itself which is written in native code and is not jitted and this would include the WebAssembly JIT. So you're going to basically get one measurement for... I love the panel, I will continue talking but lowest level is the the runtime itself we can hear you now you're just saying that the lowest level is the runtime itself. Yes the lowest layer is the runtime we will test that separately from the other individual pieces and then as you deliver additional layers of code into the keep as it's built up you will get separate attestations of each of those. There is no... we aren't measuring the output from the JIT we are measuring the inputs to the JIT. Yes, and of course one of the key things is that the attestation is being handled by the client by the tenant. So the tenant should not send and will not be allowed to send in NRX the workload which is the application until it is happy that lower levels of attestation have successfully completed and that completion will also yield enough peeing data, cryptography data to allow the workload itself to be encrypted so of course the client already trusts that the workload is correct that's the application and then sends it encrypted to run on the already attested runtime inside the keep that answers your question. I'm not seeing any other questions at the moment we have a few minutes if anyone would like to ask any questions you are very welcome there is still over 40 people on the call so any questions you have very happy to answer maybe it would be a good time just to use a couple of minutes to talk about some of the types of engineering we are doing at the moment and the sort of people that might be able to help out yeah absolutely so most of our work up until recently has been focused about yeah most of our work up until this point has been focused on low level development of the hardware platform and we are however moving up the stack so we are currently flushing out our web assembly runtime we are flushing out our network protocol for for testing and delivering code and data we have lots of network protocol work to do so if that is of interest we would love to hear from you there if you are interested in a web assembly we would love to hear from you there we also just have general systems engineering work to do so for example we need a keep manager this is a thing which basically launches each of the individual keeps and keeps track of their life cycle and make sure that handles all the communication the tenants so if you are interested in that kind of application work that's great we always willfully need of people to help write tests make sure that everything we are doing is formant if you are a security engineer we would love for you to attack us or at least review or tell us all the horrible things we are doing and seek to do the best and we love documentation if you are good at writing technical documentation I know I would prefer to write code so you can help me out a lot we would also love graphic artists to do things like help improve our website and give us different types of work there what else have I missed Mike? we need we need everyone everyone yeah sorry that's it thank you very much for your attention everybody it's been great I'm sorry we had problems at the beginning we really appreciate your sticking with it so we will be available to chat either actually in the red hat chat if you can find that or indeed on the ccc chat so I'm looking forward to seeing you there thank you very much indeed for your attention goodbye