WEBVTT 00:00.000 --> 00:11.000 So, hi, welcome to our talk. 00:11.000 --> 00:15.000 We will give an update on the Coconut SDSVSM project. 00:15.000 --> 00:19.000 We have a quick introduction on confidential virtualization. 00:19.000 --> 00:24.000 We want to take out the hypervisor and the cloud provider of the things that we need to trust. 00:24.000 --> 00:29.000 And rely on the hyper platform to provide confidentiality for the virtual machine. 00:29.000 --> 00:32.000 This comes with a little problem. 00:32.000 --> 00:36.000 Usually the hypervisor is emulating devices and providing services to the guests, 00:36.000 --> 00:39.000 but it can no longer do because we don't trust it anymore. 00:39.000 --> 00:46.000 So, as a solution to this, we need an execution environment that we can put these things. 00:46.000 --> 00:51.000 And for example, on AMD, we have the term of the SDSM, 00:51.000 --> 00:54.000 the secure VM service module. 00:54.000 --> 00:57.000 And it runs inside of the TCP of the CVM. 00:57.000 --> 01:00.000 It's isolated from the hypervisor and the guest. 01:00.000 --> 01:02.000 And this is very useful. 01:02.000 --> 01:04.000 For example, providing a virtual TPM device, 01:04.000 --> 01:15.000 or helping with storing AFI variables as a migration helper and a lot of other things. 01:15.000 --> 01:21.000 Okay, so Coconut SDSM is the implementation of such a service module. 01:21.000 --> 01:27.000 We've got to start it out for AMD, Surface and P, 01:27.000 --> 01:33.000 but we're working on generalizing it and support for Intel, TDXs on the way. 01:33.000 --> 01:39.000 Currently we support pure and new hypervient vanadium master hypervises. 01:39.000 --> 01:41.000 It's written in Rust. 01:41.000 --> 01:46.000 So I've been 2002, a partialized in the MIT license here. 01:46.000 --> 01:50.000 Currently, main feature provides a virtual TPM device to the guests. 01:50.000 --> 01:55.000 And right now, we're still relying on an enlightened operating system, 01:55.000 --> 02:00.000 but the parameterizer is on the program. 02:00.000 --> 02:03.000 So, how does it look like? 02:03.000 --> 02:07.000 Yeah, Coconut comes packaged as an IGVM file. 02:07.000 --> 02:12.000 This is a file format that specifies the initial state of the guest. 02:12.000 --> 02:16.000 So memory layout and content and registers. 02:16.000 --> 02:18.000 It makes it easy because you have that file. 02:18.000 --> 02:21.000 You can easily calculate initial launch measurement. 02:21.000 --> 02:25.000 This gets loaded and everything is measured into the initial launch measurement, 02:25.000 --> 02:28.000 which is then later part of the attestation report 02:28.000 --> 02:32.000 that you can request and to verify by remote attestation 02:32.000 --> 02:35.000 that we're running what we're expecting to run. 02:35.000 --> 02:40.000 Yeah, and the S&P provides this feature called PMPL. 02:40.000 --> 02:46.000 So that's a privilege mechanism to isolate the SBSM from the guest operating system. 02:46.000 --> 02:50.000 Yeah, it launches, first it's an SBSM is launched, 02:50.000 --> 02:55.000 then it launches the OVMF, which in turn then puts the Linux OS. 02:55.000 --> 03:01.000 Yeah, we provide TPM device to the guest. 03:02.000 --> 03:07.000 This is TPM is a femoral that means it's reconstructed at every boot. 03:07.000 --> 03:12.000 So, all the primary keys are recal-regenerated. 03:12.000 --> 03:13.000 So it uses its identity. 03:13.000 --> 03:17.000 This is mostly added to the fact that we don't have a secure storage, 03:17.000 --> 03:20.000 where we could persist these things. 03:20.000 --> 03:22.000 Yeah, but it provides the PCIs. 03:22.000 --> 03:27.000 That can be used as usual for measure boot and runtime measurements. 03:27.000 --> 03:31.000 Yeah, and the S&P at the station report that can be requested 03:31.000 --> 03:36.000 also includes the TPME keys, so we can then, after remote attestation, 03:36.000 --> 03:40.000 be sure that we're talking to a valid TPM device. 03:40.000 --> 03:47.000 Yeah, OVMF also uses volatile, if you store it right now, 03:47.000 --> 03:50.000 it's for the same reasons, we don't know how to store it in a safe way. 03:50.000 --> 03:53.000 Which makes it hard to configure secure boot properly. 03:53.000 --> 03:56.000 So, because everything will be lost or you can't change the keys. 03:56.000 --> 04:00.000 And also since we're lacking secure management mode, 04:00.000 --> 04:04.000 we can't really protect the storage from the guest device 04:04.000 --> 04:07.000 and enforce the if you've already had policies. 04:07.000 --> 04:12.000 Yeah, so we have a few questions left in this whole screen. 04:12.000 --> 04:15.000 This is, of course, we're using any equipped boot disks, 04:15.000 --> 04:18.000 so how do we get the key to unlock the boot disk? 04:18.000 --> 04:22.000 And also need to talk about when and how to do the remote attestation. 04:23.000 --> 04:26.000 And the question is, maybe we can add a persistent storage 04:26.000 --> 04:30.000 so that we can store the TPM state and the if you buy it. 04:30.000 --> 04:33.000 But we talk about this later a little bit. 04:33.000 --> 04:36.000 Yeah, quick overview of the TPM that we have. 04:36.000 --> 04:39.000 So we're using the TCG reference implementation, which is written in C, 04:39.000 --> 04:43.000 and then of course, because we unwrapped, we need an additional small C library 04:43.000 --> 04:48.000 and we also pull an open SSL for all the crypto stuff. 04:48.000 --> 04:55.000 Yeah, the guest can talk to that TPM via the SSM guest interface. 04:55.000 --> 05:01.000 It's an AMD specific protocol. 05:01.000 --> 05:07.000 And yeah, it requires enlightened drivers in in over a map and in Linux. 05:07.000 --> 05:13.000 Yeah, I already said the thing is the firmware, but we can still use it for measured boot. 05:13.000 --> 05:17.000 Yeah, quick overview on the roadmap, so we have our first development release plan soon. 05:17.000 --> 05:24.000 We're working on implementing some kind of user mode tasks. 05:24.000 --> 05:28.000 So splitting off the SSM kernel from some user tasks. 05:28.000 --> 05:34.000 Of course, there's a lot of infrastructure and a lot of details to be implemented. 05:34.000 --> 05:41.000 Yeah, next big thing is X2 APIC support, which is also required to make other platforms work, 05:41.000 --> 05:43.000 except AMD. 05:43.000 --> 05:50.000 Yeah, in the long horizon, we have the full power horizon mode that is hopefully we get there at some point. 05:50.000 --> 05:55.000 Yeah, of course, we're working on upstreaming all the driver bits into the other projects. 05:55.000 --> 05:59.000 And also Q and we need some patches still, they're not upstream yet. 05:59.000 --> 06:05.000 And yeah, we hope to implement some secure persistent storage for coconut. 06:14.000 --> 06:26.000 Okay, now we can talk a bit more about one of the main features we want to provide with SVSM, which is the state persistent. 06:26.000 --> 06:31.000 As Oliver mentioned, our all our services now are not persistent. 06:31.000 --> 06:36.000 So we cannot store any state and everything is rebuilt on every boot. 06:36.000 --> 06:39.000 So we want to support state full services. 06:39.000 --> 06:51.000 Essentially for mainly for VTPM, for state full VTPM and to use, I mean, to provide a UFI variable so that can be updated at one time by the user. 06:51.000 --> 06:57.000 So our state, the SVSM state will contain VTPM, all the state of our services. 06:57.000 --> 07:02.000 In order to do that, we need to persist and that kind of information somewhere. 07:02.000 --> 07:13.000 So our idea is to provide a storage driver to SVSM, where the backend will be provided by essentially by the host in some way. 07:13.000 --> 07:19.000 It could be a network driver or a simple file stored in a host file system. 07:19.000 --> 07:23.000 For this reason, we need some kind of encryption on top of course. 07:23.000 --> 07:31.000 And another requirement we are is to support multiple drivers, because SVSM, one goal of SVSM is to run on different environments. 07:31.000 --> 07:35.000 So the main question is out to the grid to state. 07:35.000 --> 07:37.000 And the answer is that we are ready. 07:37.000 --> 07:40.000 So in previous presentation is to do attestation. 07:40.000 --> 07:44.000 In this case, we will talk about the attestation, because we are really, 07:44.000 --> 07:46.000 hardly in the boot phase. 07:46.000 --> 07:52.000 We are in SVSM, which is a firmware, which is even before OBMF. 07:52.000 --> 07:59.000 So we will do that attestation of course to receive the key to the grid. 07:59.000 --> 08:08.000 To the grid, the storage that contains all the state of the services that SVSM will provide. 08:08.000 --> 08:10.000 Our remote attestation will work. 08:10.000 --> 08:17.000 We already talked a lot about them, but essentially SVSM will generate an assisted with the hardware, 08:17.000 --> 08:24.000 we generate an attestation report that contains an evidence, send it to a remote server that will check that everything is fine. 08:24.000 --> 08:27.000 So the launch measurement is the one that we expected. 08:27.000 --> 08:36.000 So the software that is running is the software that really we want, and the hardware is a genuine hardware that provide confidentiality. 08:36.000 --> 08:40.000 If everything is fine, the remote server will send back to SVSM the key, 08:40.000 --> 08:44.000 and that key will be used to unlock the state. 08:44.000 --> 08:48.000 Now we have a couple of challenges, network stack. 08:48.000 --> 08:55.000 We don't have the network stack in SVSM, and we are not sure we want to support it and maintain it. 08:56.000 --> 08:57.000 Yeah, exactly. 08:57.000 --> 09:01.000 And we also want support multiple attestation protocols. 09:01.000 --> 09:08.000 As I mentioned, we are not tied to a specific architecture, specific cloud vendor, 09:08.000 --> 09:11.000 so we want support multiple attestation protocols. 09:11.000 --> 09:20.000 So one of our proposal that we discussed last year at Plumber was an attestation proxy. 09:20.000 --> 09:32.000 So essentially a simple application running into the host that will, for what all the requests coming from SVSM to the remote attestation server using an HTTP connection, 09:32.000 --> 09:36.000 where the HTTP will be done by the host. 09:36.000 --> 09:41.000 These architectures, several advantages like we don't need any network stack on SVSM, 09:42.000 --> 09:47.000 and we will use feature that already works supported by VMM, 09:47.000 --> 09:53.000 like a serial port or this connection between the SVSM and the proxy. 09:53.000 --> 10:03.000 The drawbacks that we discussed at Plumber a lot was some cloud vendors does not provide any natural connectivity into the host. 10:04.000 --> 10:12.000 Our application cannot reach in any way the remote server in that environment. 10:12.000 --> 10:19.000 And also for some attestation protocol could be an issue that the TLS is ended into the host. 10:19.000 --> 10:25.000 And so the SVSM could have some issue to authenticate the source. 10:25.000 --> 10:37.000 So another idea that was shared by HPE, I put the link in this slide on this proposal was essentially to move that application into the guest. 10:37.000 --> 10:45.000 So we called that attestation bridge, and it would be a essentially similar application, 10:45.000 --> 10:51.000 but it could be for an Wi-Fi application, since you already have your Wi-Fi support and address stack. 10:51.000 --> 10:59.000 So we can write an application and Wi-Fi application that do something similar of the proxy with a scribe. 10:59.000 --> 11:07.000 Or it could be a minimum operating system like a very minimal Linux kernel with the application on top. 11:07.000 --> 11:14.000 Or when in SVSM, as Oliver mentioned, we are providing support for user space, 11:14.000 --> 11:19.000 and maybe we will provide support for standard rest in SVSM in a user space. 11:19.000 --> 11:24.000 That which could also be an SVSM user space application. 11:24.000 --> 11:29.000 The main advantages of this architecture is everything is self-contained into the firmware, 11:29.000 --> 11:33.000 so everything is into the IGVM of file that Oliver mentioned, 11:33.000 --> 11:37.000 and we don't require anything to run into the host. 11:37.000 --> 11:40.000 So also we don't require the connectivity into the host. 11:40.000 --> 11:44.000 We also have some drawbacks by with this approach. 11:44.000 --> 11:47.000 And eventually the bridge will be part of the launch management, 11:47.000 --> 11:49.000 so if you have some kind of CVS, 11:49.000 --> 11:54.000 since the bridge could be a big part of the firmware, 11:54.000 --> 11:59.000 you need to update your IGVM and your launch management. 11:59.000 --> 12:02.000 The bridge also requires some kind of setup, 12:02.000 --> 12:08.000 so the VMM needs to, I mean, we need to define some kind of configuration 12:08.000 --> 12:11.000 to tell to the bridge how to configure the network. 12:11.000 --> 12:14.000 And the bridge phase could be a bit more complex, 12:14.000 --> 12:19.000 because SVSM needs to build this kind of bridge that could be like a temporary VM 12:19.000 --> 12:21.000 or something like that, then draw everything away. 12:21.000 --> 12:25.000 I mean, use it to get the secret to unlock the storage, 12:25.000 --> 12:30.000 then draw away everything and start the real OVM map and guest. 12:30.000 --> 12:35.000 And so talking about the state, 12:35.000 --> 12:39.000 we have some potential attacks we want to prevent, 12:39.000 --> 12:42.000 which are essentially rollback and clone attacks, 12:42.000 --> 12:45.000 with rollback and host can, 12:45.000 --> 12:49.000 and many users can provide to SVSM state, 12:49.000 --> 12:51.000 which is included with the right key, 12:51.000 --> 12:53.000 but could be an old state. 12:53.000 --> 12:57.000 This kind of attacks can, for example, 12:57.000 --> 13:02.000 hand-down some update on the second boot keys we stored 13:02.000 --> 13:06.000 into the UFI viable store. 13:06.000 --> 13:11.000 And the clone attacks is the host can spawn multiple VMs 13:11.000 --> 13:14.000 with the same SVSM state, 13:14.000 --> 13:17.000 so we're using the multiple VMs, 13:17.000 --> 13:19.000 we will use the same TPN, 13:19.000 --> 13:22.000 which can back the uniqueity of the TPN. 13:22.000 --> 13:25.000 And in order to protect this attacks, 13:25.000 --> 13:29.000 we have something in mind like for the rollback, 13:29.000 --> 13:32.000 use a boot counter, 13:32.000 --> 13:34.000 and for clone, 13:34.000 --> 13:38.000 we can allow successful attacks station only 13:38.000 --> 13:43.000 for a single instance for the VTPM identity, 13:43.000 --> 13:48.000 only one time for each request coming from the user. 13:48.000 --> 13:51.000 Anyway, if you are interested about those, 13:51.000 --> 13:57.000 we are discussing in the TCG virtualization platform working group, 13:57.000 --> 14:00.000 possible changes to the TPN specification, 14:00.000 --> 14:03.000 and also support attestation protocols. 14:03.000 --> 14:05.000 We need to put some links here, 14:05.000 --> 14:09.000 so if you are interested, please join. 14:09.000 --> 14:13.000 Now, just to recap everything, 14:13.000 --> 14:16.000 so our boot phase will work. 14:16.000 --> 14:18.000 Essentially, the first step, 14:18.000 --> 14:22.000 the hypervisor will load into the confidential VM memory, 14:22.000 --> 14:27.000 the SVSM and the VM map from the IGVM file, 14:27.000 --> 14:29.000 and SVSM will boot. 14:29.000 --> 14:32.000 During the boot, we need to talk with the SVS, 14:32.000 --> 14:34.000 so we need to talk with the remote server, 14:34.000 --> 14:36.000 using the proxy of the breach, 14:36.000 --> 14:38.000 and generate the attestation reaper, 14:38.000 --> 14:39.000 send it to the server, 14:39.000 --> 14:43.000 and receive back the key to unlock the storage. 14:43.000 --> 14:45.000 At this point, 14:45.000 --> 14:48.000 the SVSM can utilise the TPN, 14:48.000 --> 14:49.000 the virtual TPN, 14:49.000 --> 14:50.000 and UFI viable service, 14:50.000 --> 14:54.000 and contain the boot's launching of VMF. 14:54.000 --> 14:57.000 How VMF can use second boot, 14:57.000 --> 14:58.000 and measure boot, 14:58.000 --> 15:00.000 thanks to the TPN, 15:00.000 --> 15:05.000 and can then launch the operating system, 15:05.000 --> 15:08.000 which will be able to use the TPN 15:08.000 --> 15:10.000 to, essentially, 15:10.000 --> 15:12.000 a state full TPN, 15:12.000 --> 15:16.000 so it can be used to do the looks, 15:16.000 --> 15:17.000 looks key, 15:17.000 --> 15:19.000 or unsealing, 15:19.000 --> 15:23.000 and then automatically mount the root file system. 15:24.000 --> 15:25.000 We have a demo, of course, 15:25.000 --> 15:26.000 we don't have time, 15:26.000 --> 15:27.000 so we put a link, 15:27.000 --> 15:29.000 it's a complete demo, 15:29.000 --> 15:30.000 a proof of concept, of course, 15:30.000 --> 15:32.000 with everything we saw, 15:32.000 --> 15:34.000 and also we maintain a copper repo, 15:34.000 --> 15:36.000 so if you want to try, 15:36.000 --> 15:37.000 essentially, 15:37.000 --> 15:40.000 some of the changes that we need in a state 15:40.000 --> 15:41.000 in Linux, Quimo, 15:41.000 --> 15:43.000 and the ADK2 are not yet upstream, 15:43.000 --> 15:45.000 so if you want to try, 15:45.000 --> 15:49.000 we have a copper repo with all of those packages, 15:49.000 --> 15:51.000 plus SVS. 15:52.000 --> 15:54.000 Yeah, that's time for question. 15:54.000 --> 15:55.000 Thank you. 15:59.000 --> 16:01.000 So, she's got a question. 16:01.000 --> 16:03.000 First of all, it's an observation 16:03.000 --> 16:04.000 that we should have been on this, 16:04.000 --> 16:06.000 and yesterday, in the presentation, I show. 16:06.000 --> 16:07.000 So, you can, 16:07.000 --> 16:08.000 instead of, 16:08.000 --> 16:09.000 we either proxy, 16:09.000 --> 16:10.000 or pre-shoot, 16:10.000 --> 16:11.000 to multiple, 16:11.000 --> 16:13.000 to terminate the TLS, 16:13.000 --> 16:16.000 you start inside the TPN, 16:16.000 --> 16:20.000 and use the proxy as just the transport, 16:21.000 --> 16:22.000 Yeah. 16:22.000 --> 16:23.000 Yeah. 16:23.000 --> 16:24.000 Because, 16:24.000 --> 16:25.000 if you are ready to pulling in, 16:25.000 --> 16:26.000 it's open as a set, right? 16:26.000 --> 16:27.000 Right. 16:27.000 --> 16:28.000 If you have the bio-ups, 16:28.000 --> 16:29.000 actually, 16:29.000 --> 16:31.000 you have the bio-in bio-ride bio-connect, 16:31.000 --> 16:32.000 yeah. 16:32.000 --> 16:33.000 And then you have the guy, 16:33.000 --> 16:35.000 which is a good point. 16:35.000 --> 16:36.000 I will repeat what, 16:36.000 --> 16:38.000 I mean, it's an observation, 16:38.000 --> 16:39.000 as a Justin for us. 16:39.000 --> 16:40.000 Essentially, 16:40.000 --> 16:41.000 he's suggesting to, 16:41.000 --> 16:43.000 instead of using the proxy, 16:43.000 --> 16:44.000 or the bridge, 16:44.000 --> 16:47.000 we can do something like a mix, 16:47.000 --> 16:49.000 using the proxy just to, 16:49.000 --> 16:51.000 just really as a proxy, 16:51.000 --> 16:54.000 and the TLS connection into the bridge. 16:54.000 --> 16:55.000 So, in this case, 16:55.000 --> 16:58.000 the proxy will be used for the real, 16:58.000 --> 17:00.000 TCP connection, 17:00.000 --> 17:04.000 and TLS will be handed into SVSM. 17:04.000 --> 17:06.000 This will solve the TLS issue, 17:06.000 --> 17:07.000 but we still have this issue of, 17:07.000 --> 17:09.000 some common vendors that doesn't 17:09.000 --> 17:11.000 have connection into the host hypervisor. 17:11.000 --> 17:13.000 So, maybe we need to support both, 17:13.000 --> 17:14.000 but yeah, thank you. 17:18.000 --> 17:23.000 So, you can, 17:23.000 --> 17:27.000 you can, 17:27.000 --> 17:29.000 you mean, 17:29.000 --> 17:31.000 SVSM will generate it. 17:31.000 --> 17:32.000 So, 17:32.000 --> 17:34.000 you can, 17:34.000 --> 17:35.000 as a sense, 17:35.000 --> 17:36.000 you can, 17:36.000 --> 17:37.000 yeah. 17:37.000 --> 17:38.000 So, 17:38.000 --> 17:39.000 actually, 17:39.000 --> 17:40.000 the current implementation, 17:40.000 --> 17:41.000 the endorsement key, 17:41.000 --> 17:42.000 sorry, 17:42.000 --> 17:43.000 the question is, 17:43.000 --> 17:44.000 thank you, 17:44.000 --> 17:45.000 the question is, 17:45.000 --> 17:46.000 as SVSM, 17:46.000 --> 17:47.000 the TPM, 17:47.000 --> 17:49.000 into SVSM and endorsement key, 17:49.000 --> 17:50.000 yes, 17:50.000 --> 17:51.000 that endorsement key, 17:51.000 --> 17:52.000 currently, 17:52.000 --> 17:54.000 is generated randomly, 17:54.000 --> 17:55.000 a total boot. 17:55.000 --> 17:57.000 The idea is to, 17:57.000 --> 17:59.000 when we support the storage, 17:59.000 --> 18:01.000 is to provide also an offline tool, 18:01.000 --> 18:04.000 that you can use to install, 18:04.000 --> 18:05.000 which key, 18:05.000 --> 18:06.000 do you want? 18:10.000 --> 18:13.000 I'd like to file on to what Thomas said, 18:13.000 --> 18:14.000 because, 18:15.000 --> 18:18.000 the SIM card industry has been using, 18:18.000 --> 18:20.000 this model that he described, 18:20.000 --> 18:24.000 with DLS in the sort of trusted execution environment, 18:24.000 --> 18:26.000 for more than 25 years. 18:26.000 --> 18:27.000 So, like, 18:27.000 --> 18:29.000 if they managed to get it done, 18:29.000 --> 18:30.000 I think it's possible, 18:30.000 --> 18:31.000 in a virtual machine, 18:31.000 --> 18:32.000 yeah, 18:32.000 --> 18:33.000 like from a performance, 18:33.000 --> 18:35.000 but in the source and on a problem, 18:35.000 --> 18:36.000 because they are also, 18:36.000 --> 18:37.000 nobody directly, 18:37.000 --> 18:38.000 since, 18:38.000 --> 18:39.000 like, 18:39.000 --> 18:41.000 the message is directly to the SIM card, 18:41.000 --> 18:42.000 but instead, 18:42.000 --> 18:43.000 the option outside, 18:43.000 --> 18:45.000 that needs to initiate the connection first, 18:45.000 --> 18:46.000 because otherwise, 18:46.000 --> 18:47.000 the server that infrastructure is, 18:47.000 --> 18:48.000 and indeed, 18:48.000 --> 18:49.000 to contact. 18:49.000 --> 18:50.000 Okay. 18:50.000 --> 18:51.000 There is some machinery, 18:51.000 --> 18:52.000 but, 18:52.000 --> 18:53.000 it's manageable. 18:53.000 --> 18:54.000 Yeah, 18:54.000 --> 18:55.000 so there's presidents. 18:55.000 --> 18:57.000 Okay. 18:57.000 --> 18:58.000 Yeah? 18:58.000 --> 19:01.000 Just back up on the endorsement key, 19:01.000 --> 19:02.000 question, 19:02.000 --> 19:03.000 how do you, 19:03.000 --> 19:05.000 how do you trust the virtual TPM? 19:05.000 --> 19:07.000 It sounds like what we need, 19:07.000 --> 19:08.000 is another bond, 19:08.000 --> 19:10.000 chat on the artist's statement, 19:10.000 --> 19:12.000 the confidential TAM, 19:12.000 --> 19:14.000 rather than the TPM, 19:14.000 --> 19:15.000 just the TPM. 19:15.000 --> 19:16.000 So, the hardware TPM, 19:16.000 --> 19:18.000 there's a certificate over here. 19:18.000 --> 19:19.000 Okay. 19:19.000 --> 19:21.000 It means I know it's by a hardware, 19:21.000 --> 19:22.000 by TPM. 19:22.000 --> 19:24.000 This is an extremely device. 19:24.000 --> 19:27.000 This is sort of constructed by the cloth, 19:27.000 --> 19:28.000 and the confidential TPM. 19:28.000 --> 19:30.000 There's no direct trust path, 19:30.000 --> 19:31.000 though, 19:31.000 --> 19:32.000 being able to say, 19:32.000 --> 19:34.000 this is the TPM that is definitely 19:34.000 --> 19:35.000 trustworthy. 19:35.000 --> 19:36.000 There's an extra step, 19:36.000 --> 19:39.000 that wasn't entirely carried in the diagram. 19:40.000 --> 19:42.000 Yeah. 19:42.000 --> 19:43.000 We didn't, 19:43.000 --> 19:44.000 essentially we didn't, 19:44.000 --> 19:45.000 the question is, 19:45.000 --> 19:47.000 the real TPM has some kind of, 19:47.000 --> 19:48.000 some kind, 19:48.000 --> 19:51.000 as a certificate that prove 19:51.000 --> 19:54.000 that the endorsement key is essentially 19:54.000 --> 19:56.000 identical identity of the, 19:56.000 --> 19:58.000 of who generated the endorsement key. 19:58.000 --> 20:00.000 Do we have something there? 20:00.000 --> 20:02.000 The answer is currently no, 20:02.000 --> 20:05.000 but when we will provide the state full TPM, 20:05.000 --> 20:06.000 we can provide the tool, 20:06.000 --> 20:08.000 and you can essentially generate 20:08.000 --> 20:09.000 whatever you want, 20:09.000 --> 20:11.000 and you stole also the endorsement key. 20:11.000 --> 20:12.000 So we'll be up to the user, 20:12.000 --> 20:13.000 to the user, 20:13.000 --> 20:15.000 to configure the SBSM, 20:15.000 --> 20:18.000 to do that steps. 20:18.000 --> 20:21.000 The problem with this is that in a quiet environment, 20:21.000 --> 20:24.000 the quiet vendor is the opposite rate. 20:24.000 --> 20:26.000 So you don't have a natural person. 20:26.000 --> 20:28.000 We can do all of those checks, 20:28.000 --> 20:29.000 I'm providing signature, 20:29.000 --> 20:31.000 that is just a third point. 20:31.000 --> 20:33.000 That's the piece that is missing, 20:33.000 --> 20:35.000 and I would love to see a solution for it. 20:35.000 --> 20:36.000 Yeah. 20:36.000 --> 20:38.000 We are providing the building blocks, 20:38.000 --> 20:41.000 and we are not working on currently, 20:41.000 --> 20:43.000 on that things. 20:43.000 --> 20:45.000 But the building blocks will be there. 20:45.000 --> 20:46.000 So essentially, 20:46.000 --> 20:50.000 if there will be a certification authority, 20:50.000 --> 20:52.000 that the user want to choose, 20:52.000 --> 20:54.000 they will be able to store whatever they want 20:54.000 --> 20:55.000 into the virtual TPM, 20:55.000 --> 20:58.000 and then check the identity. 20:58.000 --> 20:59.000 Okay. 20:59.000 --> 21:00.000 Sorry. 21:00.000 --> 21:02.000 One more question. 21:02.000 --> 21:03.000 One more question. 21:03.000 --> 21:05.000 Who are like real world and constructive? 21:05.000 --> 21:07.000 How do you suppose who will specify which 21:07.000 --> 21:09.000 the decisions are worth deducting? 21:09.000 --> 21:12.000 And the expected say publicly of it? 21:12.000 --> 21:14.000 The question is, 21:14.000 --> 21:16.000 when we use, 21:16.000 --> 21:19.000 when we talk with the remote attestations somewhere, 21:19.000 --> 21:21.000 we have multiple guests, right? 21:21.000 --> 21:22.000 Right. 21:22.000 --> 21:23.000 It gets you to want to talk to some sort, 21:23.000 --> 21:24.000 or how do you specify it, 21:24.000 --> 21:26.000 like where is it stored, right? 21:26.000 --> 21:27.000 It would be, 21:27.000 --> 21:29.000 it would be stored into the IGVM, 21:29.000 --> 21:30.000 in some way, 21:30.000 --> 21:31.000 or provided in some other way, 21:31.000 --> 21:33.000 by the IPR-wise or TOSVSM. 21:33.000 --> 21:34.000 So when you start your VM, 21:34.000 --> 21:38.000 you will configure SVSM with, 21:38.000 --> 21:39.000 I mean, 21:39.000 --> 21:43.000 with the destination server you want to reach. 21:43.000 --> 21:44.000 For example, 21:44.000 --> 21:45.000 in the case of the proxy, 21:45.000 --> 21:47.000 you will launch the proxy, 21:47.000 --> 21:50.000 specifying where the remote server is, 21:50.000 --> 21:52.000 need to be reached. 21:52.000 --> 21:53.000 Like you have one proxy for the, 21:53.000 --> 21:55.000 for all the guests on the host. 21:55.000 --> 21:57.000 They will all talk to the same destation server. 21:57.000 --> 21:58.000 You can spawn multiple proxy, 21:58.000 --> 21:59.000 if you want. 21:59.000 --> 22:02.000 So our idea for now is to have one proxy for each VM. 22:02.000 --> 22:03.000 Okay. 22:03.000 --> 22:04.000 Thank you. 22:04.000 --> 22:05.000 Thank you. 22:05.000 --> 22:06.000 Thank you.