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