 knowing, verifying what you're on. So the things we are going to talk about today include a quick overview of continental computing, what this is about. Talking about what is attestation. Talking about various use cases for continental computing. Who knows what the picture on the right is. What? Only one hand? Are you kidding? This is a hack, isn't it? Going from root of trust to actual trust. Various platform-specific details. And supporting technologies. And this one is harder to find as a picture. Any idea? Someone who has not had KVM form. So these are the foundations for the effort. So this is really, I'm going to talk relatively fast and brush over on a number of topics because this is really a summary of a blog. But there is a blog that is on the right of the blog. So you can scan that QR code or work later on the website and you'll find links with modalities. So what is continental computing? Continental computing is mostly about predicting data in use. And there's this quote from a guy named Kevin Mitty. Maybe you have heard about him. Saying, I compromise the confidentiality of the proprietary software to advance my agenda of becoming the best at breaking through the log. Hackers typically try to do that. And the problem with infrastructure, as we shall see, is that your infrastructure today is where you run your stuff. We saw that in the keynote today. But why should your infrastructure see your data? Your software now runs on someone else's computer, also known as the cloud. So you have some sort of virtual machine host, for instance. And then it has various resources that it's going to provide for you, like a CPU, memory, disks, networking, and so on. And these resources are used to run various workloads. So typically that could be containers that will run inside your host. Now there are various sandboxing technologies and they are essentially designed to make sure that your containers cannot escape to the host, cannot damage it, cannot do whatever they want with the resources. They are not really designed for the other way around, for someone on the host picking inside your workload, inside your container, et cetera. And so that means that if you want to run competitors on the same machine, they will typically be unhappy because they are not sure that some rogue admin was not paid by the other guy to pick into their data. So we have some technologies that have been established for a long time for disk encryption, network encryption. You're familiar with those. And what is really missing is that what is in your memory is essentially an open secret to a host admin. So they can read that and it's maybe, usually it's secret because it's in memory, but it's really, again, an open secret. So what if we added some memory encryption to product against that? And the memory encryption doesn't need to be super strong, but it has to be something that happens all the time for all the data that goes to memory. And then later, there were some technologies that were added to protect the integrity of the CPU state because if you run that in a virtual machine, you don't want your virtual machine to be able to change the register state to jump anywhere in the code or stuff like that. And finally, that's going to be most of the talk. You need to make sure that what you run is exactly what you want to run. So a decision is there to prove that what you're running is running on the right context in the right environment. And that you are running what you think you're running. Oh, you want me to talk in the mic? Okay, sorry. So first, let's start with rule of trust. So you're probably familiar with something like a TPM, sorry, for instance. And that's the rule of trust that measures and lasts the next step. And then again and again, until you reach typically your workload. And so each step there will, as it goes, measure itself and record that in some physical device that is going to have a hardware-enforced recall of what happened. So this leads to the idea of trust domains. And in the case of continental containers, which is illustrated here, you have a number of things. Okay, so a lot of stuff is misaligned there. What is the resolution of this screen? Sorry. So the... You have a number of security domains that you need to consider. The first is the trusted platform, which offers a number of security guarantees that are essentially enforced by hardware cryptography. And so the platform will just give you these guarantees, but it doesn't really know what data is in there. And then you have the host, which will provide things like resources, like physical memory devices and so on. And again, the idea is that they just provide the resources, but they don't have access to what's inside because the data is encrypted all the way. And finally, you have the tenant or owner, which is all the stuff that you care about. And it's not just running on this piece of infrastructure. You see on the right something called the relying parties. That's typically, that could be something that could be on premise for you or something in a place you trust, maybe another enclosure. And that's where you're going to do things like verifying what you're running in your trusted system. So what kind of guarantees does confidential computing really provide? Well, the thing that we really care about as the name implies is confidentiality. So what this means is that we will protect data in use from leaks, from tampering, from things like that. However, we will not protect against crashes. As a matter of fact, we might make them more frequent because our case is where we'll just say, stop, we won't go there. We cannot product disk or network data. That's really your role to do that. And there is no kind of guarantee of service. And again, there is an increased risk of not having any kind of forward progress. And finally, it's all hardware based cryptography, typically for memory and so on. So that's something that with sufficient effort if you have NSA level access to the system, then maybe you can actually decrypt stuff. More importantly, it's really highly implementation dependent. What you see on the right is a chart that is just for AMD generations. So different generations will give you different level of production. So the bottom line is you don't get automatic security out of this, right? And the next question is how fast was this car driving? So what is attestation? It's essentially proving what you run, that you run what you want to run exactly and where you want to run it, specifically in a confidential environment. So let's start with a little bit of terminology with the rats model that the IETF has established for us. So you have a component called the verifier. The verifier is really in charge of checking your policies. And this starts by an endorsement process where an endorser is going to say, for instance, this hardware, I put some trust in this hardware for this or that reason. For instance, because I built it. Then you have reference values providers that are going to provide to the verifier various reference values, like for instance, this is the list of hashes for the software that I accept to run. So I've measured my software ahead of time and I know that this software can run there and the reference value provider hosts that. And finally, a verifier owner is going to have various appraisal policies that it can put in the verifier that are going to say this evidence is accepted. This evidence is not accepted. So for instance, while we develop confidential containers, we have this appraisal policy, which is anything goes because we are developing it. And so we just accept the workloads run, essentially. This base or whatever. And then you have an attester. So that's the thing that we'll try to prove who they are that is going to send some evidence to the verifier that goes through these various steps. And then the result of this attestation process go to a relying party that could be used, for instance, based on other appraisal policies this time set up by the relying party owner. And that could decide, for instance, to release some secrets or do something like that. So the basic concept, again, is that you're offering some proof about the configuration of a system. In general, generally speaking, attestation is really proving some kind of property. In our case, what interests us is, is this system actually running with encrypted memory on with the right firmware with these kind of properties? For those of you who saw Vitaly's talk just before this one, he was mentioning some of the properties that are available. Now, one important kind of attestation is remote attestation. And that's when you decouple the evidence from its verification. And you all know that when you have a lock and you give the key to, let's say, your girlfriend, and then you no longer trust your girlfriend, so you change the lock. And you've decoupled the two, right? Just run an example. So there are two big models for verifying this evidence. The first one is passport check model, where you present the evidence. It's exactly what happens when you present your passport at the airport. So the attestation is going to send its evidence, like who am I, et cetera, to the verifier. Then issue some kind of ID. And you present this ID to the relaying party. So in a cloud, typically, that would be some sort of secret internal to the cloud that you're going to present each time you want to use an API in the cloud. Another model is the background check model, which is closer to what you do with biographic measurements, where the attestor present the evidence directly to the relaying party. And the relaying party presents a variation of this evidence to the verifier. And the verifier says, yeah, this guy can go through. So in order to try to compare various ways to analyze evidence and do an attestation, I suggest we use a relatively simple pipeline that I could remit just to model the change of trust. So the R stands for root of trust. That's typically certificates or hardware components. The E is for endorsement. So typically, you'd have a signing key that is issued by, and validated through the certificate. Then the M is for measurements. That's typically in the case of a TPM that has shares of the data that you're looking through. So you decide to run some kind of boot loader. You measure this boot loader, you hash that, and that's what is recorded in your TPM. I is for identity. That's, for instance, a reference value that you would pass to your verifier. T is for trust. That's all the aspects related to policies. I decide to accept this evidence or not. And ultimately, what you get out of that typically is secrets. So this could be passwords. This could be description keys and so on. So let's see a couple of examples to understand how this works. So if you see secure boots, the root of trust is the TPM. The endoso is the manufacturer of the device. The, what you would measure typically would be something like firmware or boot loader or stuff like that. What you get out of that, so in terms of what identifies your device is some kind of signed attestation. Whether you trust that or not is then defined by the policy that you have in your system. You can decide to boot without secure boot at all, if you want. And typically the secrets that you get out of something of this would be, so Vitaly was explaining how in his case you would get a disk encryption key that you can only get out of the TPM at this specific step but you can get other cloud API secrets and so on. Now to get to something maybe a little more familiar when you go through selling a property you have these same steps except it's a notary that has signed records and there's a deal of it that measures what you're talking about. You get a property description and the trust policies do I give money based on what I know or not and the secret is you get the keys of the house. And it's really the basis for, historic gold basis for money as well and the sense that gold or silver is really the root of trust, ultimately at least initially that was supposed to be what the bank notes were representing. The person, the entity endorsing this root of trust is a government that has some of these gold somewhere in the banks. The market value is what you measure for how much you have in terms of money and so on which is in terms of identities identified by the number you see for instance on the bank notes. Handing over cash is how you accept the policy or not. I want to buy this, well then I hand over cash and I'm happy with that and of course the secret you get in that case is the secret recipe of grandma that tastes so good and it's a view for money. So the attestation again in our case will be what you measure and you do that using cryptography so the same three domains we had before. Now there are multiple ways to do that. So for instance AMD with a CV started with something called pre attestation and what pre attestation does is essentially measure some specific components and you measure your payload before you even start running it and so the hypervisor decides it does some operation and then you decide I launch that or I do not and I'm going to have a talk later today while I show you in practice how this works. Post attestation is slightly smarter you can automate things better because you can essentially measure from the guest itself and get the measurements for your own identity that you can then transmit over the network for instance to the relying party or whatever and ultimately you probably care most about the workload so at some point there will be some kind of workload attestation though very often the mechanisms for that are not very different from what you use today like having this specific container hash is what I trust et cetera. So now continental computing is a relatively large field and there are many ways to deploy it and use it while you use cases essentially going from virtual machines to complete clusters. So the base technology is in general today based on virtual machines there are some continental computing technologies like SGX or SME that are based at the process level but the ones that really interest us are based on virtual machines. So from that you can build functions that boot very fast et cetera and the best example of this today is something called Keran VM or confidential workloads so you essentially boot something very fast and you do one thing and then you exit. Now if you want to orchestrate on a larger level then you need to integrate that within an ecosystem like Kubernetes, OpenShift et cetera and that's the purpose of something like confidential containers. So in that case you will use confidential machines as a runtime for your containers and you'll be able to deploy your containers the usual way and do all the scaling and all the things you're used to. And the whole and she let us if you decide to put the whole cluster inside virtual machines. So in that case even the control plane itself is in continental virtual machines and you have to be very rich to do that. So the base technology behind it all is confidential virtual machine and if you're curious about the picture on the top right that's what you get from DuckDuckGo at least that's what I got last week when I searched confidential virtual machine I have absolutely no idea what this is. It's confidential even to me. So first you need to have new hardware and firmware binary interfaces that expose the new features. This is highly hardware dependent at the moment. The host channel is no longer trusted. However it has to expose these new features so you trust it to the extent that you can access something but the real trust will be in the cryptographic operations that happen. Same thing with the hypervisor. The hypervisor needs to expose new features. It needs to know new ways to do IOs, new ways to expose measurements and so on. But it is not trusted even if it does that. So where the boundary of trust happens is when inside the VM, so the VM becomes the confidential enclave that you are starting to trust and inside there you have a guest firmware and a boot sequence that is typically measured as well as a guest scan load. Same thing you want to measure that and make sure that you know what you're running. So I mentioned confidential workloads for things like very simple functions. So what you see here is a current VM in action in that case on this specific laptop. That's not the confidential version that you're seeing here but you see that this is really the real time operation. So the way this works is essentially that a VM is exposed as a library to the host through a project called libkaren and then you have a direct integration with Podman. So if you're familiar with Podman you can download images that went on and it's going to run relatively well. And that project got very early support for SCV compared to the rest of the projects I'm talking about here. In particular they were the first to do working remote attestation. So it's interesting that confidential containers as a project had defined a protocol and we were not the first ones to implement the protocol that current VM project did. So for confidential containers the next step in our use cases we essentially use Kata as a basis. So Kata was already running workloads and containers as essentially a virtual machine was a pod and the Kata runtime will transmit the creation of containers et cetera so that it happens inside the virtual machine. So there was already some level of isolation from Kata itself and confidential containers builds on that to use the technologies that the confidential computing technologies. So these are the components that are impacted essentially. The next step up is as I mentioned, continental clusters. So one example of this is a project called Constellation by Edgeless. So in that case I cannot show it in real time. The real thing takes something like 40 minutes or something like that to bring up a cluster but then you have a cluster that is completely that is essentially completely confidential including the control plane. And so you say I want to start with for instance three worker nodes and two control nodes and you have five confidential VMs that all authenticated each other and after that it works mostly like a standard Kubernetes cluster. So you make it in the whole cluster confidential and it works at the cloud provider level so you start your session by saying I am on Azure, I am on whatever and it does these things for you. So you can see what it looks like and if you're familiar with Kubernetes you'll probably recognize a few things here. And so what you see here is going inside this container and checking that SCV is active there and that's what you have inside. So one interesting aspect of this project is that they rely on something called attested TLS and that's essentially a way of attesting the other side of a TLS transaction. So that's interesting because it lets you build things that span more than one containers. They also added something called a joint service and that's a way to add, when a new node wants to join the cluster to make sure that the new node itself is confidential. They also have this at the user level, a verification service that is user facing and lets a user check before I deploy my workloads there I want to make sure that the cluster is known to become confidential. So how do we build actual trust and keep the trust alive along the way? So how does attestation really work? You start as I said by doing some cryptographic measurement for instance of your confidential VM or some enclave that you care about. This is done by hardware or firmware in a way that cannot be tampered with. That's the important part. And once this is done, you get some sort of reduced version or some ID, some condense version of hash or something like that of that measurement that you can send to the attestation service and that you can then compare with whatever is in your database of identities. And if the attestation service is happy with it, it will typically request something from a key broker service or something like that and send you back the keys. That can be a decryption key for this, that can be whatever. Now of course the interesting point is that you can say no. And when you can say no to something you said yes before. So that's another important aspect of remote attestation. So let's say you discover that this particular version of the Linux kernel has a flaw in it and can expose data. Then you can decide to exclude that now from your database and it will no longer boot. Though it did, it was accepted before. So the actual flow is slightly more complicated than what I just showed because the attestor first does a request but to avoid replay attacks and things like that, the relaying party typically responds with a cryptographic challenge with a nonce in it and so on so you have to encrypt with that nonce and that makes sure you're not responding with by replaying something or stale data. So then you present your evidence encrypted with that nonce in it. The evidence is relayed to the verifier and the attestation result is then returned and then if that passes the secrets retrieved from the secret broker and send back to the attestor. So we have the same remits flow there in terms of how this happens in practice. So I've tried to make it general because the name of these values components are different between AMD and Intel but roughly it's the same process. So another interesting aspect of attestation is that different kinds of proof are needed for different kinds of consumers. What I mean with that is that for instance when you're booting the system the thing that you care about is is my firmware and Linux kernel are they the one I want? Are they not compromised? Are they versions that I trust? And so in that case you're facing the system to try to build a trusted execution environment and make sure that it is trusted. User facing is you want to prove to some user of the system, hey, is the system actually safe? And of course you have to have a way to trust that which the user can verify. So typically that relies on some end also publishing their public key somewhere and so you can validate with their public key that what you got was actually emitted by that end also. We all know how this ends. Someday the private key is leaked and that whole process is invalidated but at the moment this is safe for the existing technologies. Another kind of attestation is workload facing checking if the runtime environment of a specific workload is valid. Peer facing is two workloads that want to check one another and make sure that they're not talking to the wrong guy and leaking through the other side. And cluster facing is essentially nodes who want to join a cluster and they want to check that before I admit that node in the cluster I want to check that it's actually running what I expect. Now there are plenty of platform this specific details that I really skimmed over. So the vendor landscape today for continuous computing looks roughly like this. You have the AMD secure encrypted virtualization is sort of the first implementation of that that was really widely available. This relies on a separate processor essentially a small ARM core on the side which will store all the really important stuff and you have to go through that processor to do things like getting a new key, getting encryption activated and so on. So that's AMD's approach is having this separate core on the side that does this kind of things. Now they had two later iterations. SCV ES stands for encrypted state and adds encryption of the CPU register file which otherwise in SCV the hypervisor could modify almost at will. And SCV and S&P is a larger change. Secure nested pages add some integrity production and adds things like product interrupts, et cetera. The Intel equivalent is called trust domain extensions or TDX. And it's a very different approach because on that approach it's essentially a new mode in the processor called SIEM, secure beta pressure mode. And so the processor goes to that mode where only Intel stuff runs when it needs to do something complicated. IBM does it completely differently with something called secure execution which is firmware based. Power has something called a product execution facility which is a little closer to Intel than AMD implementation. And ARM has something called continental computing architecture which is like for like Intel based on having a layer below that the operating system cannot touch. Now what these technologies share is that they are all based on virtualization but they all work differently. And so essentially you're finding a bunch of random zombies when you want to. So AMD was the first one and that was essentially the message side. It was somewhat flawed. There was memory encryption through hardware which was good but it was built on top of virtualization unlike that other encryption technology called SME. As I said it relies on a separate security processor and only features pre attestation. Now the problem is that several vulnerabilities were discovered relatively quickly that gave it a bad rep which passes to this day. So the map up crew were SAP ES and SAP S&P. ES as I said products CPU stay from tampering. No major impact on attestation. S&P does have productions against physical access to pages, the hypervisor remapping and so on but more importantly you can get attestation data from within the guest. And so another interesting thing is something they call VMPL which lets you build enclaves that are more privileged than others to implement things like virtual TPMs et cetera. So Intel TDX relies on the STX to create secure enclaves where they do a lot of the stuff and it's virtualization based but there is no separate security processor and essentially you use the secure arbitration mode to invoke services that are provided by STX enclaves on the side. So various binary modules provided by Intel will expose the required services and they have to be measured at boot and so on. So in particular attestation is provided by a cooling enclave. In terms of supporting technologies well you need the host and guest Linux kernel support, hypervisor support, guest firmware support, host provisioning for supporting tools like for instance, self-cuddle for starting a system I'm going to show that later today. Generic key broker services and attestation. Compatibility layers to try to mimic what exists and to be able to reuse the infrastructures that exist like for instance a virtual TPM that mimics real TPMs. So this is provided by something called the Secure Virtual Machine Service Module or SVSM. So the blog details all this. So that's why I'm really skimming through. Go in the blog and you'll have pointers to the various documents and references et cetera. So my conclusion is essentially that attestation means different things. We really scratch only the surface. It's a large collection of technologies. Even in a given context you can have attestation mean different things. So folks tend to talk past one another. You have to be careful about what you're talking about. Preserving the chain of trust correctly requires really careful thinking. And again if you see my talk later today you'll see a bit surprised there on what can go wrong. Technologies are not consistent across the board so Intel and AMD do not think the same way. Again you can take a picture of that if you want more details for the six part blog series. Now it's time for questions. Sorry I was a bit longer than I anticipated. So only two minutes, yeah. I'm in some kind of humor or software. As you said, for example the big blog TPM. So I'll try to summarize the question for online and you correct me if I summarize wrong. The question is really about what kind of hardware provides this and how can I get that hardware and how can I go without it if I don't have the hardware. Is there an alternative that I can do in software? So for the first question these are typically new instances that get deployed as we speak so for instance there are new CVSMP instances on Azure that you can order today where they will have this pre-configured for you and you go in that case through the attestation mechanisms provided by Azure. Regarding whether you can implement that in software you can mimic some of that in software for development purpose. However what the software cannot do for you is product from someone on the same machine being able to pick out their memory and I'm going to give examples so the other talk is that I think 5.15 or something like that and I'm going to show you how you can actually dump the memory of a VM and see what's inside and search for root passwords and stuff like that and you find them. So the question is whether I could encrypt the memory in flight. Encryption by definition has at some point data in clear that data today has to be stored in memory and unless your whole message fits in registers which let's say you have 16 registers on x86, 64 bits that's not a very long message and plus yeah I'm out of time but yeah so the short answer is I don't think so I don't think you can do it safely unless for very very short messages.