WEBVTT 00:00.000 --> 00:10.000 The title of my quote is, while the current limit attestation, there's a 00:10.000 --> 00:21.000 deficit being type confidential competing. So, this is not, I decided to decide. I want to talk about my dissatisfaction. 00:21.000 --> 00:28.000 So, I'm afraid my question is answered by previous talk that I want to continue. 00:28.000 --> 00:36.000 The first question is, current CPU based remote attestation, major does not measure 00:36.000 --> 00:43.000 all degree of image. The CPU based remote attestion may just only ensure this process 00:43.000 --> 00:52.000 including objects, the virtual data, and the kernel already. Do you think is it enough? Question two. 00:52.000 --> 01:01.000 After the kernel built, keeping based remote attestion is used on computer computing. However, can we 01:01.000 --> 01:10.000 test the battle TPM implementation? So, the side question also, I want to talk the detail in 01:10.000 --> 01:16.000 question to the next slide. So, the side question is, some remote attestion studies is 01:16.000 --> 01:24.000 offered by the same credit plan does. Can we test the attestation results? And the question 01:24.000 --> 01:32.000 flow, can remote attestion studies the real migration? Because the real migration is 01:32.000 --> 01:38.000 major peculiarities, whole credit computing. The question is, is the attestion 01:38.000 --> 01:56.000 in CPU is the same on attestation time? So, this data will be a virtual PT, a virtual 01:56.000 --> 02:09.000 image. So, this red shows two types of PTPM. One is, one is, one is, this Copenus SDSM 02:09.000 --> 02:19.000 national property is red. So, this implementation, the PTM is included in the VM image. 02:19.000 --> 02:31.000 Once it has a hand, TDX is the TPM trust domain. Another trust domain is used for 02:31.000 --> 02:39.000 TDX. So, I think the implementation is not so big problem. The problem is, can we 02:39.000 --> 02:50.000 test the key management of the TPM? The implementation should be open source, but how 02:50.000 --> 02:57.000 there, some code domain there does not open. This problem is nation by statistics paper. So, 02:57.000 --> 03:08.000 this is the data at statistics. Can we migrate the TPM and use the notation, because 03:08.000 --> 03:23.000 to migrate the TPM, we have to migrate the TPM keys. 03:24.000 --> 03:30.000 So, the little problem caused by the responsibility of the problem. The first one is, 03:30.000 --> 03:35.000 major increase, the responsibility of the CBM integrity. And second problem is, 03:35.000 --> 03:40.000 increase the responsibility of signing the attestation. And the side of the problem is, 03:40.000 --> 03:46.000 who is responsible for managing the signing key? I think we have to solve these 03:47.000 --> 03:53.000 problems. Thank you. 03:53.000 --> 04:16.000 Hi, welcome. This is a lovely talk about some newer issues to our 04:17.000 --> 04:23.000 computer solution for IBMA frames, as I said in the current. 04:23.000 --> 04:27.000 The solution is consecular execution or IBM secure execution for Linux 04:27.000 --> 04:33.000 formally. It is a computer solution based on, again, access control. The 04:33.000 --> 04:40.000 trusted host cannot access the memory of the secure guest. The loop of trust is 04:40.000 --> 04:45.000 called the ultravisor, which is the hardware and firmware entity that is trusted, 04:45.000 --> 04:53.000 that is the interface between the untrusted host and the trusted guest. 04:53.000 --> 04:59.000 One key thing is that the boot image is encrypted with the public key of the 04:59.000 --> 05:05.000 machine. So, it can contain secrets. Attestation is not needed, because you can put your 05:05.000 --> 05:09.000 keys or looks keys in the entity. But we also do support the 05:09.000 --> 05:15.000 motorization and drop ping and secure dumps. We have actually done a bunch of 05:15.000 --> 05:20.000 talks about this, which you can easily found online, if you want more details. 05:20.000 --> 05:26.000 Both at the KVM phone, or also here's the first them. So, this is about 05:26.000 --> 05:34.000 secure execution in general. And now, I want to shed some light on one of our 05:34.000 --> 05:40.000 latest features that's called, we call it Regulable Secrets. And the general idea is that 05:40.000 --> 05:45.000 we don't know what one keys, in clear text, anywhere, but in the trusted execution 05:45.000 --> 05:51.000 environment. Even when there are in use to a four or four encryption or something like that. 05:51.000 --> 05:56.000 So, it goes like, on the top left, we have a trusted system where we read that 05:56.000 --> 06:01.000 key with a key with another key that's encrypted. And send that to our secure 06:01.000 --> 06:05.000 execution guest, that's our confidential computing guest, in other terms. And 06:05.000 --> 06:10.000 add this encrypted key to the firmware. And there's the keys encrypted with 06:10.000 --> 06:15.000 like the image with the public key of the machine. And the machine 06:15.000 --> 06:19.000 will decrypt if key, verify it's integrity, and stored it, somewhere 06:19.000 --> 06:24.000 self, a safe, where no one else can go to it. And at some point, in the 06:24.000 --> 06:28.000 execution of the guest, it can retrieve the key. But the key is not 06:28.000 --> 06:32.000 retrieved in clear text, but as a protective key. With a different key, 06:32.000 --> 06:39.000 the logist has a different color. And when the key retrieved, it's 06:39.000 --> 06:46.000 we call it a wrapped key. So, it's wrapped with another key. You can do 06:46.000 --> 06:50.000 hardware as a lighter crypto operation with that wrap key, just throw in 06:50.000 --> 06:56.000 your encrypted key in the instruction, and the instruction will then as 06:56.000 --> 07:02.000 part of the instruction execution, unwrap the key, and do review 07:02.000 --> 07:09.000 a crypto thing it wants to. So, this is also for a 07:09.000 --> 07:15.000 Israeli architecture, so we can invent our own operations for that. And 07:15.000 --> 07:19.000 that's it, that's from my side. And actually, yeah, this is actually 07:19.000 --> 07:23.000 already all upstream and downstream. So, it's not like something 07:23.000 --> 07:26.000 you can just, sorry, the, it's already there. 07:26.000 --> 07:30.000 And now I put my own, my organisers, I put again, head again. Thank you 07:30.000 --> 07:34.000 for being there. I hope you all enjoyed the talks, and see you next year 07:34.000 --> 07:36.000 and in lunch break.