WEBVTT 00:00.000 --> 00:17.720 I have been working on the software that manages confidential VMs on ARM in QMU and Cloud 00:17.720 --> 00:24.560 Hypervisor, and that got me wondering how we compute the reference values that correspond 00:24.560 --> 00:29.560 to a given VM and other check during a destination. 00:29.560 --> 00:37.960 I'd like to give a quick overview of the findings of how and present a tool that allows 00:37.960 --> 00:43.160 to compute those values. 00:43.160 --> 00:47.760 This is the kind of software start that we were considering, much you talked about it 00:47.760 --> 00:53.760 during yesterday's computational computing session. 00:53.760 --> 01:05.800 On the top left, the VM and creates and manages the VM, the hypervisor, the 01:05.800 --> 01:15.040 KVN, tells to its trusted counterpart, to install the VM, then ARMN tells the guest, 01:15.040 --> 01:23.600 which contains at least an application on the kernel, but can contain a lot of different 01:23.600 --> 01:32.720 components, like EFI firmware, bootloader, Paravizer, containers, anything you can 01:32.720 --> 01:33.720 think of. 01:33.720 --> 01:45.360 Each of these components can request a destination at one time from a very file. 01:45.360 --> 01:51.520 The atestation first should look familiar, initially we provide a very file with reference 01:51.520 --> 01:52.520 values. 01:52.520 --> 02:01.160 During a destination, the verifyer sends a challenge, announced to the atester, then ARMN 02:01.160 --> 02:10.600 and hardware creates an atestation token, a good and sign it, and then the verifyer checks 02:10.600 --> 02:18.320 those signature and compares the values contained in the atestation token against its 02:18.320 --> 02:25.240 reference values if they match its sends a positive result. 02:25.240 --> 02:33.520 In the right, the atestation token is played between information about the platform and information 02:33.520 --> 02:43.880 about the code and data that goes into the RAM, which is what I will be focusing on. 02:43.880 --> 02:54.520 I would like to say the RAM is what we call the trusted environment on the right here. 02:54.520 --> 03:09.240 So the question is, when we create the VM, I remember everything that goes into the RAM, 03:09.240 --> 03:16.760 so it starts by hashing the VM parameters to create the initial measurement, the RAM, and whenever 03:16.840 --> 03:24.680 we load an image into the RAM, it touches each page of that image and add it to the RAM. 03:24.680 --> 03:33.360 It also has the initial vcp registers, so the order of operation is crucial because each 03:33.360 --> 03:42.680 operation takes a remas input, there are also runtime measurements that components within 03:42.680 --> 03:50.200 the RAM can extend the hash some images, the loading for example, and add that hash to the 03:50.200 --> 03:52.840 runtime measurement. 03:52.840 --> 03:59.600 The question is, how do we compute this frame as a reference value provider? 03:59.600 --> 04:08.560 The easy way is to just run the whole payload once on a machine request and extract the 04:08.640 --> 04:13.640 rim that you can then probably run it to the very fire. 04:13.640 --> 04:20.080 In general, that is impractical and it won't be feasible because you won't have access to 04:20.080 --> 04:26.800 the machine that can be paid off, so we've created this two CC error measurements, it 04:26.880 --> 04:32.080 says it's another the raise and project. 04:32.080 --> 04:41.440 You pass it the images that you load into the RAM and the command land parameters of your 04:41.440 --> 04:52.480 VMM and it outputs a reference value that you can provision your very fire with, the main complexity 04:52.560 --> 04:59.840 in calculating the rim, is that there is no standout on VMHPM and we'll have the own way 04:59.840 --> 05:08.000 of loading a payload and we'll have the own memory map and the own iacumat, because we want 05:08.000 --> 05:15.040 to measure the firmware tables that describe the platform to the RAM, we need to know exactly 05:15.120 --> 05:26.880 that memory map, so the two defines a canonical loading order for the operations that went into 05:26.880 --> 05:34.960 the rim calculation and it also describes a couple of virtual platforms, so if the VMM follows 05:34.960 --> 05:42.160 that specification then we can generate the firmware tables, measure them and we'll end up with 05:42.160 --> 06:00.480 the same, the same measurements, and a possible problem with pre computing that in this way 06:01.680 --> 06:10.560 is that it doesn't scale well for each possible configuration you need to generate a RAM, so 06:10.640 --> 06:19.520 you can with a straight even with a straight VM specification, it could become a manageable 06:19.520 --> 06:28.400 if you want to add less of different parameters, so we've explored a way to do it dynamically instead 06:28.400 --> 06:36.640 of provisioning the very fire with the RAM reference value, we can equip it with the ability to 06:37.600 --> 06:46.240 compute the rim during attestation, the way it works is when when creating the VM, 06:47.840 --> 06:57.440 the VM and also creates a log of anything that went into computing the rim, and the log is 06:57.520 --> 07:05.600 unmergeed and it's passed through the the firmware table, and during attestation the attestance 07:05.600 --> 07:14.560 this log along the attestation token, the very fire then attempts to compute the rim 07:15.920 --> 07:24.640 by passing the log, it's important to note that the log is untrusted but images that we use to compute 07:24.720 --> 07:30.960 the rim are trusted, and the parameters that are in the log can be checked against the 07:30.960 --> 07:38.960 policy at reloading to the very far, if the very fire manager is to come up with the same ring 07:38.960 --> 07:45.440 as the one in the attestation token, when it comes to the ability result and it comes to 07:46.240 --> 07:59.200 cache the rim as a reference value for later, I've been completing the very fire and the 07:59.280 --> 08:09.840 relying party here, so we have a prototype of this based on the keyboard code that 08:09.840 --> 08:16.080 marked your mentioned yesterday, so the keyboard guard is the relying party and talks to a 08:16.080 --> 08:22.480 very fire to get some part of the attestation to, for example, get the platform token, 08:22.720 --> 08:37.680 and then the keyboard guard itself can compute the rim at one time, so I presented three options 08:37.680 --> 08:46.640 for completing the run token and our two allows to explain and with two of them, 08:46.640 --> 08:56.560 it's proof of concept at the moment and we like input from possible users about what we should 08:56.560 --> 09:05.440 be focusing on next, there are a few things to standardize in particular the protocol that we use to 09:05.440 --> 09:12.640 send along the log alongside the attestation token, that will be needed as well for runtime 09:12.640 --> 09:24.960 environments which can be augmented, run domain by components running in the run, so we do need 09:24.960 --> 09:36.240 describing what the equation is going to be in the, most of it and there are some links in the slides, 09:38.240 --> 09:48.320 we can talk about, you can recreate something, you can learn a bit on a lot of bits and 09:49.200 --> 10:13.200 it's all based on Q and Q and the armfast model, so it's easy to run a domain, sorry 10:13.280 --> 10:26.480 it's the hobby is the log for the rim it's very small but so we only store hashes of the images 10:26.480 --> 10:34.720 that went in there, so it's a few hashes and a couple of parameters not much, so I've been wondering 10:34.720 --> 10:41.600 if instead of pre-generating the firmware tables we could also pass the whole firmware table in 10:41.600 --> 10:49.360 the log, so the verifyer can check the content instead of us generating it, so that would be a bit bigger 10:49.360 --> 11:00.800 but not too much, so I'm not sure if instead of the first building design for these cases like 11:00.800 --> 11:06.800 my A to the hand, I love the arm, initial work is being designed to serve the size staff, so arm has got 11:07.760 --> 11:27.600 more of the size pieces, so how well does this map to IoT, well for the moment we've been focusing 11:27.600 --> 11:41.040 on cloud computing, so this is all based on demo that represent a cloud work, but the tool is generic 11:41.040 --> 11:48.240 it's a very small library that you can use for anything new, so the principle of launching a VM on 11:48.240 --> 11:56.960 can be derived to IoT as something I'd like to explain 12:18.960 --> 12:27.680 like a lot of issues, so the question is why do you want to use it, and how about IoT? 12:27.680 --> 12:40.240 Right, the question is to we plan to use the TCG TPM log and where is the route of trust in there, 12:40.240 --> 12:48.720 so we are basing the log format on the TCG TPM to the moment, we're just adding a few 12:49.920 --> 12:59.840 event types in there, and the route of trust in the arm CCA architecture is based on the hardware 12:59.840 --> 13:08.000 security chip, and that's the chip that signs the attestation token that goes out to the 13:08.080 --> 13:19.840 very fire, so all the measurements which are performed by the RMM are changed to this hardware 13:19.920 --> 13:33.120 with the trust, and so your questions? 13:33.120 --> 13:44.400 It's the only thing that we trust is the final calculation of the ring, so unless we arrive to this 13:45.120 --> 13:51.760 ring value, we're not trusting anything in between, so the log and the log only describe the 13:51.760 --> 13:53.840 different step that one is duplicating that end. 13:53.840 --> 14:17.120 For the hosting structure, how are we given any thought in the live patching on the host? 14:17.120 --> 14:29.200 Not me in particular, but I know there is some effort to modify or to update the firmware and 14:29.200 --> 14:47.040 the kernel at one time, so I don't know, at the moment it's based on QM or the 14:47.840 --> 15:09.720 USB signal, you guys want to ask why, so I just allow, of course, you can see if anything is 15:09.720 --> 15:14.460 finished, it's helpful. 15:14.460 --> 15:23.460 use the attestated TLS protocol when the logo is small. I don't quite see where that fits in with the line. 15:28.460 --> 15:31.460 Right, that's right. 15:33.460 --> 15:37.460 Yes, no, no, there is no problem with that, it's just adding. 15:37.460 --> 15:47.460 So we send the attestation token raw as a single payload and we need to add some fields in there to store the logo and that's all I mean. 15:51.460 --> 15:52.460 Yeah, you have to know. 16:07.460 --> 16:09.460 Thank you.