WEBVTT 00:00.000 --> 00:10.920 All right, let's get going here. My name is Matthew. I'll be talking about confidential 00:10.920 --> 00:15.720 computing on arm and how we're going to support this with open source software. 00:15.720 --> 00:24.240 Why do I thank you? No, that's good. So the idea here is to support an end-to-end scenario 00:24.240 --> 00:29.760 without any black magic, without any special binaries. It's all open. The projects are there. 00:29.760 --> 00:34.200 And we have links at the end of the slide. So there will be a lot of things that are being 00:34.200 --> 00:40.920 presented here. There's a lot of moving parts. I do realize that. And this is why, I guess I said, 00:40.920 --> 00:47.920 all of the links and all of the details that are going to the solution are at the end. You can all 00:47.920 --> 00:52.560 build this. You can all run this to the same way that I have this morning. All the instructions 00:52.560 --> 00:56.480 are there. So let's go through this. 00:56.480 --> 01:00.960 So before going any further, what I would be presenting today is a collaboration between 01:00.960 --> 01:11.240 Lanaro and Arm. We've been at this for over a year now. And so if we're going to the rats 01:11.240 --> 01:17.720 architecture, what the pieces that we're going to explore today are the boxes in orange. So 01:17.720 --> 01:24.840 we're going to talk about what's running on the target or a server. So the end-dorser, 01:24.840 --> 01:33.120 we're also going to use the key broker and the verifier in order to run our solution. 01:33.120 --> 01:41.000 So this is our stack, all of them are open source software. If we're going at the bottom, 01:41.000 --> 01:46.440 we do not have hardware that is available right now. So we have two virtual machines that are 01:46.520 --> 01:54.920 available to us. Either the FVP model from Arm or the Q&U machine. And if you choose to use Q&U, 01:54.920 --> 02:01.320 there's two machines that are supported. The virtual and the SPSA that we just finish integrating 02:01.320 --> 02:07.800 with the RME extension. On top of that, trusted firmware. So all of the patches are upstream. 02:08.760 --> 02:14.920 EDK2, the same thing. All of the patches were upstream just before Christmas. So you can use 02:15.000 --> 02:16.920 the master branches there. That's not a problem. 02:18.120 --> 02:22.520 That one next couldle. There's a few more patches to upstream, but this is being worked on by Arm. 02:23.080 --> 02:29.240 And on top of that, you have your choices of the MM. So either KVM tools, Q&U, or cloud-high 02:29.240 --> 02:38.360 provider. So if we're looking at the secure side, so the RMM, which is the realm world, 02:38.360 --> 02:44.200 the upper-visor equivalents in the realm world. And on top of that, we have our Linux stack. 02:45.560 --> 02:51.400 On the next stack, we have at the station agents that we have added to a refile system. 02:51.400 --> 02:56.200 So when we're talking about at the station's agents here, we have the tools in order to manipulate 02:56.200 --> 03:04.680 and extract the CCA token. And we also have an application that is interacting with our key broker 03:04.680 --> 03:14.200 in order to fetch our secret payload. There's a colleague of mine as well that is working on 03:14.200 --> 03:19.160 all of the container side of the solution. So that's being worked on, but we're not going 03:19.160 --> 03:27.320 to talk about that today. Okay. The verifier. This is project Verizon. 03:28.200 --> 03:32.840 There's been extensive talk about that. So Verizon is an open source project, 03:32.840 --> 03:39.320 allowing you to build a verifier. So we're using that. We have two versions. 03:39.640 --> 03:43.720 There's one that is running in the cloud that people can use. It's all really there. 03:43.720 --> 03:47.640 So it only lessens the amount of steps and the amount of things that you have to do 03:47.640 --> 03:51.960 in order to put the solution together. And if you're behind a firewall where you 03:51.960 --> 03:56.360 really, really want to run it on your own, you can do that as well. That's not a problem. 03:58.520 --> 04:01.640 So that's the verifier side. And lastly, we have our key broker. 04:04.040 --> 04:09.560 Key broker split into two parts. One part is the application side that is running on the refile system 04:09.560 --> 04:15.000 that we have. Again, you can download that and build that. There's no surprises there. 04:15.800 --> 04:21.480 And the key broker server. So that is running on your platform. You instantiate it. 04:21.480 --> 04:28.200 You give it a key. And it will basically wait for requests. So all of that. 04:30.760 --> 04:36.440 So before the firmware info, let's talk about the tools. We also have tools as I mentioned. 04:36.440 --> 04:42.920 So integrate it with the solution. That way you do not have anything. You have examples to work with. 04:42.920 --> 04:49.560 And you do not have anything extra to do. So a couple of key of tools that we're going to use. 04:49.560 --> 04:58.520 So CCA work with authorization. So many plates. The CCA token. So extract it from the platform. 04:58.520 --> 05:05.720 You can basically print it out and explore the content of it. And we also have a round measurement tool. 05:06.440 --> 05:14.440 That job leap is going to talk about in more details to more. But that is basically part of project 05:14.440 --> 05:21.160 the reason. And it allows you to compute the initial rim and the round, which are the measurement 05:21.160 --> 05:28.520 for your virtual machine. So I've talked about all that. So what we're going to do here is take 05:28.520 --> 05:35.640 all of these tools together in order to explore an inch one scenario. And that scenario going 05:35.640 --> 05:43.320 back to our RATSAR architecture is the background check model where you have a device that is looking 05:43.320 --> 05:49.080 for a secret payload in order to execute. So there will be a key broker app that will 05:50.120 --> 05:57.240 make a request to our broker. The broker will go to the verifier, verify the platform token. 05:57.240 --> 06:03.160 If that is in line with the policies that were pre-populated, that will come back to the 06:03.160 --> 06:09.560 key broker. The payload will be encrypted and going back to the endorser. So we're going to go through 06:09.560 --> 06:18.040 these steps here. So the first step here is basically to download our stack, build it and run it. 06:18.040 --> 06:25.080 So whether you're using the FEP model or Q&U, it is the same. We'll just boot and boot to a host. 06:25.720 --> 06:31.000 And that host gives you your RME enabled platform and from there you can launch a round. 06:31.640 --> 06:37.880 Once you're in the realm, you're basically into the environment where you will be executing your 06:37.880 --> 06:46.200 private payload. Second step is to start the cable cursor and we're going to see how to do that. 06:47.640 --> 06:55.080 And you can use the verifier that runs in a cloud or you can run your own. It's exactly the same thing. 06:55.720 --> 07:05.000 Okay, so if we are, again, into our realm environment, we have a CCO, work like at the station tool, 07:05.720 --> 07:12.600 in order to fetch the report or the CCA token from the platform, you simply launch the command report. 07:12.600 --> 07:19.080 It will give you a slew of thing and one of which is the initial measurement. So that is your RIM. 07:19.720 --> 07:24.600 It basically gives you the state of your virtual machine when it's started. 07:26.120 --> 07:32.600 The idea here is to take that key and record it. You record it in order to start your 07:32.600 --> 07:39.480 key broker with that key. So it's a pre-populated policy. So when you have a request, the keys will be 07:39.560 --> 07:47.080 compared and if they match, then you are basically allowed to get your secret payload. 07:47.960 --> 07:52.200 This is just the policy that we have enacted for this demonstration here. There's 07:53.640 --> 07:56.840 a tons of different fields that you can basically add to your policy, 07:58.040 --> 08:02.920 based on what you want to achieve and results that are expected. 08:03.080 --> 08:11.960 So again, so we have cellular realm. We have started our key broker service. We have a WIM 08:11.960 --> 08:20.440 that matches in both instances. And now for that, it's time to request our secret payload. 08:20.440 --> 08:25.480 So going back to the realm, we are simply starting our key broker server application. 08:26.520 --> 08:32.680 I'm using my personal machine here and we're asking for a skywalker key. So basically the sky 08:33.160 --> 08:40.040 locker payload. So what will happen is that the key broker application will go down to the platform. 08:40.040 --> 08:45.720 It will fetch the token and it will simply send that to the key broker. The key broker will 08:46.360 --> 08:52.520 ask our fire. The very fire will accept the payload. If everything matches, we have 08:54.360 --> 09:02.120 basically a payload that comes back to the application and the secret payload that we have 09:02.120 --> 09:08.440 received contains a simple string that is made the force be with you. There's a lot of things 09:08.440 --> 09:14.040 that have happened in all this and we're going to go through that. So when we have 09:15.320 --> 09:20.360 we have our realm, we have our key broker and we have a very fire. Again, the very fire runs 09:20.360 --> 09:25.880 in the cloud so we do not have to instantiate it. So what happened when we launch our application? 09:25.880 --> 09:31.960 So this is, I'm starting at three because two slides ago or three slides ago, I started at three. 09:31.960 --> 09:39.960 So three basically means when do we launch our request? So when the request got launched, 09:41.560 --> 09:48.280 we fetched our CCA token from the platform that was wrapped with a wrapping key and sent to the 09:48.280 --> 10:00.920 key broker. The key broker extracted the platform token from our evidence send that to the 10:01.000 --> 10:06.200 verifier. We have a pre-populated key, what a static key in there. Again, you can change all of that, 10:06.200 --> 10:16.680 but this is for the benefit of the demonstration. We had in step number seven, we have our 10:16.680 --> 10:23.240 attestation results. If the attestation results are in our being compared by the key broker, 10:24.200 --> 10:32.360 that matched and the the result was sent back encrypted with the wrapping key, 10:32.360 --> 10:38.040 decrypted and we have basically our content which was made the force be with you, but that can be 10:38.040 --> 10:44.920 anything meaning a secure payload that you have now acquired the right to run on your platform. 10:47.480 --> 10:52.840 So as I said, all of the links that I talked about, all of the technology that I talked about 10:52.840 --> 10:59.080 is there, these are the links, they are instructions to put them together. You can everything is 10:59.080 --> 11:04.840 available to download, compile, and run the exact same way that I have run it, and I know that they 11:04.840 --> 11:10.920 run and they work because I have done exactly that to put this together. There's no surprises. 11:14.440 --> 11:18.920 So that was a lot of information in the real-time questions. 11:23.800 --> 11:38.040 So how much of this, what you've showed here, all the boxes, how much it matters? How much of this, 11:38.040 --> 11:47.880 all of the material that I've asked is specific to CCIon arm. It is right now, it is tailored 11:48.520 --> 11:56.520 for an arm platform, but it's not arm-specific at all. So the policies and the platform 11:56.520 --> 12:01.480 token is obviously arm-specific, but there are different formats that can be that are open source, 12:01.480 --> 12:06.040 that can basically be used for other architecture that will just work. 12:08.200 --> 12:13.320 So there's nothing very arm-specific about that. The gentleman in the back raises question first. 12:17.880 --> 12:31.400 Yeah. So we're talking about the room and the room, the initial measurement, 12:31.400 --> 12:36.840 and the question was about freshness. I did not talk about freshness, but there's a 12:36.840 --> 12:40.200 non-secluded rule that as well. So that's your freshness. 12:46.200 --> 12:47.560 I didn't get that. What? 13:06.840 --> 13:20.120 So basically the question is about the room. It's still a use case where we would like to extend 13:20.120 --> 13:26.760 the room or use the room. So one thing that we're currently working on is device assignment. 13:26.760 --> 13:32.200 So if you basically have a device that was acquired by or that was given to your confidential 13:33.160 --> 13:39.640 and you still have to a test at device, but that was not part of the initial measurement that 13:39.640 --> 13:45.240 your room was. So everything that will be part of that process will also have to be authenticated, 13:45.240 --> 13:50.440 that driver, and that device will have to be authenticated. So that might be a case where we would 13:50.440 --> 13:59.240 like to go to a third party for authentication. And those devices basically when you insert a module, 13:59.320 --> 14:03.640 they come up to life. So it depends on when you do that. Yes. 14:03.640 --> 14:10.760 Okay. To entangle question, the first thing that I think, so the room is the content of the evidence, 14:11.480 --> 14:17.880 initially. The question is, is the room the content of the initial content of the evidence? 14:18.920 --> 14:24.200 The room is the state of your virtual machine when it got started. 14:24.200 --> 14:28.040 Of your room when it got started. That is when bed is measurement. 14:28.040 --> 14:31.560 And because of RAM, initially measurement, that's content of the evidence. 14:31.560 --> 14:37.800 Right. It's part of your CCA token. And there's two parts of the CCA token. 14:37.800 --> 14:43.000 There is evidence. Yes. Okay. Then that's clear. Now who's creating that? 14:43.560 --> 14:49.880 There was boxes. There was a error coming out with evidence. Which of the boxes are creating the evidence? 14:49.880 --> 14:55.560 So the question is, which or what entity in there is creating the room and the RAM, 14:55.560 --> 15:01.000 or the attestation token? Yeah. The whole attestation token. So basically, 15:01.000 --> 15:09.480 that attestation token is comprised of two main chunk, the platform chunk, and the realm chunk. 15:09.480 --> 15:15.000 So the platform chunk comes from the secure processor in the hardware. So you basically hear 15:15.560 --> 15:22.840 because we are a virtual platform. We do not have real hardware. So that is embedded directly into the TFA. 15:24.200 --> 15:31.720 And there's ways to modify that. But basically, so that comes from, when you're doing a request, 15:31.720 --> 15:36.360 it goes all the way down to the TFA. The TFA will interact with the secure processor. 15:36.360 --> 15:42.920 You'll get the platform chunk that way. And the RMM is basically doing the realm part of it, 15:42.920 --> 15:48.920 packaged together, signed and sent back to the application. So we're still calling it an endorsement, 15:48.920 --> 15:54.360 but someone's like a detester. We're calling it an endorsement in the diagram, but that sounds like 15:54.360 --> 16:03.640 an attestance from me. I thought I used the language from RFC 9334. Then I'd made a mistake. 16:03.720 --> 16:09.560 Okay. I have a warm invitation for this question. 16:09.560 --> 16:10.920 Speak louder, please. 16:10.920 --> 16:11.400 Yeah. 16:11.400 --> 16:17.080 I'm going to get the invitation for questions. So, you know, like Kubernetes, you should consider this in a whole red. 16:17.080 --> 16:21.640 For what about, like, actually, you know, security Kubernetes when you control things, 16:21.640 --> 16:26.840 especially when you look at Tallah, for example, it's an array system for us. I just 16:27.080 --> 16:31.800 want to say, how did they benefit from this work? 16:31.800 --> 16:37.640 That's the question. How do you take this burden out and you build it into, like, E.S. or 16:37.640 --> 16:41.240 E.S. or E.S. on the top of the other one? I just had a risk to do it. 16:41.240 --> 16:49.400 Okay. So the next step is, how do you take this into a real destroyer, a real cloud environment, 16:49.400 --> 16:56.680 using Kubernetes? Yeah. So that's the next step. So this is just providing the base 16:56.760 --> 17:04.120 platform. How would you build a CCA enabled infrastructure on ARM? Then after that, 17:06.360 --> 17:10.360 my colleague Kevin is basically integrated, integrating, 17:10.360 --> 17:15.960 content and Kubernetes together. So that these can basically be used to say more that they 17:15.960 --> 17:24.520 would be for a non-secure VM environment. That is not part of this scheme here. We're still at 17:24.600 --> 17:33.160 a layer where we haven't included the, the glue that would take this from the base support to 17:34.280 --> 17:40.440 a real cloud environment or a cloud provider environment, I should say. Did you have a question? 17:40.440 --> 17:44.680 A question in that moment. I'm not sure if it will last a, you know, raise your hand? 17:44.680 --> 17:50.520 It will last a previous question. Are you a thousand-month data? Are you a thousand-month data? 17:50.840 --> 17:58.360 No, okay. So I work on data containers. So people are really, really looking forward to 17:58.360 --> 18:05.640 have this fully integrated on data containers. So talk to me. Talk to, talk to Thomas, talk to 18:05.640 --> 18:12.280 Joffrey. We're all working together and fantastic. So yeah. So at the moment, let's have a talk 18:12.280 --> 18:19.400 about how we can see how we can speed up these developers. Absolutely. We did hands. 18:21.720 --> 18:35.160 Sir, come again. So the detail of the secure processor. I do not have that details because I have 18:35.160 --> 18:41.960 not implemented this on a real hardware. But typically, you would, I would be a co-processor. 18:42.280 --> 18:47.000 That would be a mix of co-processor, secure co-processor, and TPM. 18:56.680 --> 19:03.160 What's next on our roadmap? Very, very good question. There's a few, we are working on 19:03.160 --> 19:08.760 memory encryption. We want to finalize the container integration and the big, big chunk 19:08.760 --> 19:17.080 is device assignment. So again, so you have a device that is given to you via via file. That was 19:17.080 --> 19:24.120 not part of the initial measurement of the realm. So how do you integrate that? How do you do 19:24.120 --> 19:31.240 DMA to it? How does a DMA to you? Very complex problem. And we're working with different people from 19:32.040 --> 19:36.920 that are taking care of other architectures because we do not want to have a norms specific solution. 19:36.920 --> 19:45.800 It's a very complex problem. How are we doing on time? One minute. One minute.