Good afternoon.
Thank you all for being here.
I'm Jagraman.
I'm a software engineer at Oracle.
Just to give you a quick background about myself,
I used to work in the QEMU KVM project previously.
And then I switched to working on an open source,
measured wood project called trench wood.
And to last year and there was year last year to present about that.
And recently I've been focusing my attention on remote attestation in the cloud.
So it's a quick follow from a legal department.
And these are my co-workers who couldn't be here unfortunately.
So my plan for today is to explain what Oracle is doing in the remote attestation space.
So what is the problem?
So like Sal, Kimich mentioned yesterday for a confidential computing solution
should have four aspects.
It should have confidentiality.
It should have integrity.
It should have the ability to perform remote attestation.
And it should be rooted in a hardware root of trust.
So our current offering has some confidential shapes based on AMD ACB.
But we do not have the service and the support yet.
And we do not have support for remote attestation.
And so we're planning to add those to complete the entire confidential computing solution for our customers.
So in today's presentation I quickly go over the solution we chose for our customers.
I quickly touch upon our design and also the various data formats like the endorsements, evidence and results format and why they are important.
What Oracle's contribution has been in the last year and where we plan to be in the future.
So there are various proprietary and open source solutions.
And I want to explain why we chose the reason for our customers.
Firstly, the reason comes with all the components necessary to build an attestation solution.
It has a server and a suite of tools to interact with the server and manipulate the tokens and various other data.
It is a ITF apps compliant which is important because we do not want to create our own proprietary solution fragment the problem space.
It is scalable in the sense that we can easily add support for newer and emerging hardware and software technologies and attestation protocols.
It is interoperable meaning if you can integrate this project with any other project that is compliant with that specification.
It is very important for our customers because it allows the customers to choose anyone in the market.
For example, they can choose any key broker service based on their business needs who just conform with that specification.
And lastly and most importantly it is open source.
So it benefits from the community collaboration and personally have seen a lot of brilliant and passionate people working on this project.
Here is a simplified design, a blog diagram of our design.
Since it is based on the large architecture, there are four primary components.
There is a server, there is an admin who provisions reference values to it.
There is a relying party which is trying to figure out if I can trust a team.
In this I want to mention two significant points.
The first is the TEE is made of composite attestors.
It is not homogeneous.
So we have to have a way to collect evidence from all these attestors and presented as an attestation token.
And that is where our recent effort on project called RAPSD comes into play.
I also want to quickly touch upon how the reason provided solution.
It primarily consists of two front facing services called the provisioning and verification service.
The provisioning service implements key cloak which is a way to authenticate the admin.
To make sure that I am receiving endorsements from someone I trust.
And it supports an open ID connect tokens.
The verification service is scalable.
The service where you can it can it has it currently has support for PSA and CCA schemes.
And we collaborated with the Verizon folks to add support for the service in this game.
The important question here is hey you guys are cloud providers where you care about a verification service because you are not supposed to trust the cloud provider.
And the answer to it is that's correct.
We do not we do not host a verification service.
Rather our goal is to enable our customers to build out their own service easily with smoothly.
And we want to enable that and we want to provide a way.
And we will supply the reference values and endorsements valuable necessary.
Or a way for them to obtain it.
And this is where sticking to the large architecture is the important for us if they can get endorsements from L1 who supports those data formats.
So concerning endorsements there are two types one is the trust anchor.
It consists of root keys which are used to validate the integrity of evidence generated by the testers.
And the other is the reference value which specifies what the expected value of the claims should be.
And that uses a format called coreM concise reference integrity manifest to represent these endorsements.
However, the base spec needed to be extended for service and P.
And that's when we saw we met with an engineer called Deona from Google who was already working on an ITF profile for codeM.
To extend it for service.
And we took that profile and implemented a tool called GoGenRF that is able to generate endorsements for service and P.
And we plan to merge it with an existing version tool that already supports PSA and CCA architecture.
Just to give you a quick idea about the service and P profile.
It is essentially a key that collection of key value pairs, which tags each claim in a CVS and P attestation report.
For example, the tags 641 says points to the measurement that the service and P hardware generates.
Moving on to evidence.
So there are a few ways to represent evidence.
And we felt like CMW is the best way to represent evidence obtained from an attester.
Primarily because it's very simple. It is a key value pair with the key being the media type of value which is in which is a binary evidence.
And so remember we mentioned that our P consists of composite attestors.
So we have to have a way to represent all these evidence from this composite loop of every attestors into a single token.
And that's when a CMW collection comes into play where it can gather all those evidence and put it into a simple token.
In this regard, we are focusing on a tool called RaxD.
And the reason why this tool is important here is, for example, in today's presentation from Fabian who is trying to modify the SSH to make it circular, we want to have an endpoint where this anyone can connect to collect evidence.
And that's the we envision it to provide such endpoint, including say for example if there is a relying party who wants to collect evidence.
They can contact the same endpoint.
If you want to implement a tested TLS and during the process you want to collect evidence, you can use the same endpoint to put together a standard evidence that any verified use for attestation.
And concerning 7S&P, Thomas helped us with registering a media type for 7S&P because 7 Linux produces this evidence or exports the evidence we are the configFS TSM file system.
We felt like naturally creating a TSM report format would be suitable in this case.
So at the end of attestation, we have it produces a result and this is a snippet of a result and most importantly it contains what is called as a trustworthiness vector,
which describes various security aspects of the TEE.
For example, runtime okay means that is the memory circuit that can be trusted the memory circuit.
So it's the hardware is the hardware genuine hardware.
Say, for example, someone advertised as an A&B, SEDS&P.
Can I confirm, is it A&B, A&B, SEDS&P in B?
So we can use 7S&P to address those two aspects of security, but we need more attestors for giving a comprehensive picture of security.
So what has Oracle's contribution been to open source in the last year?
So we created a SEDS&P plugin for the region server.
We also implemented a tool called GoGend Reflectimension to generate reference values, partially from evidence and also we compute some measurements on the flight.
Depending on the VM configuration, which the reference values will be deployed.
We are pushing RAD2 to collect evidence from a broad set of attestors and we contribute to the community actually to keep the project on what to say to keep it more relevant to the emerging technologies.
So at this point, I have recorded a demo, but I'm trying to see if I can give you a live demo.
So...
Okay, so this is the server, and I'm going to issue my commands on the pin on the right.
So I'm going to give you an idea of what the status of the game.
So there are currently no endorsements, okay?
So I'm going to generate the endorsement using the GoGend Reflectimension, and it generates the endorsement in a C-board format.
So I'm going to use this endorsement and send it to the server.
So the first one is the trust anchor, which is the AMD Rookie for 7S&P.
And the second one is going to be the endorsement I just created.
Okay, so now let's go back to the server and check the key stores.
So now it has the reference values, and I can mention, it has a key value here.
So this one, I think, is the endorsement.
That is a version of the one that I can add to it.
So now let's send the sample evidence token and see what the server will have.
So, oh thank you.
The server passes the result, but I'm going to decode the result so that we can easily understand it.
Oh sorry.
Okay, I'm just going to go back to the backup there.
So I have already decoded it from a previous output, this is what it looks like.
The trustworthiness vector tells you how much you can trust it.
And that is the status and then sorry.
Oh, I'm not sure, I'm sorry.
So this is the sample of the output.
There's an overall aggregate status and then there's individual aspects of security.
So, so what do we want to do?
So this is what they've done so far, and then.
So like I mentioned previously, there are other aspects of security we want to cover.
So we want to add more schemes to the various own server.
And we want to improve RAT's D to support such attesters.
We want to also have a service to convey the reference values.
And the last one is authorization by which I mean.
We know that we know what the TE is.
So we know that TE has, okay, this technology.
It has VTPM, it has IMA, et cetera.
But we do not know who it belongs to.
So in today's presentation somebody, I forget the name.
There was a KPM platform binding that is required.
Similarly, that needs to be a binding in between the evidence that we generate.
And the owner of the platform to make sure that relying part if you get the attestation result.
No, that the result belongs to them.
So for example, if they want to deploy, let's say, this decryption key.
They know that, okay, so this evidence belongs to, say, Bob.
So I can give him his fee.
So that's the authorization problem we are trying to solve.
I want to take a minute to thank some folks in the various projects.
The owners are really farmers and irrigation.
They've been beyond helpful.
Awesome.
Thank you so much.
I really appreciate it.
If you have any questions, I'll be happy to answer it.
Thank you so much for your time.
There's no kind of compliance with the specific way to open my mind.
Correct.
So you find saying because it really opened things like here's something that every does without any connection.
I know about it in the private approach also.
I think for confidence that I'll be taking it to the next one.
I think of the old, because it makes sense to say,
I'll receive times to people or to the graphs who think that you have any compliance.
I'll just find this right, and I'll sort of go.
You can say that because I think what you mean is you follow the architecture space.
You follow the polling points on the window.
It will meet your power of compliance in terms of going through the communication program.
But that's not a compliance.
There's another thing that we have following that problem.
Yeah.
That is correct.
It's not a compliance.
Right.
So you have no such standard to comply to.
I understand.
Thank you for bringing that up.
It is.
It's open.
It will remain open.
So it's here.
And then.
It is a very interesting question actually.
Yeah.
So I thought about it.
There are two ways.
There are actually two thoughts.
The first one is we know that the individual evidence and
Mattersters, they are self-contained.
You don't.
For example, 7 S&P.
The evidence is already signed by the hardware.
Somebody were to tamper with it.
You can easily find it out.
Secondly, for now.
We have secure boot.
That will.
That will ensure that the.
Very fire is running.
What very fire is running.
An expected.
Build of.
Actually.
And we.
The.
There is some.
Discussion to be had.
But that's a valid problem.
And we have mitigated.
But I want to go on to.
Other questions.
Yeah, I think.
You were mentioning.
The trust was.
The.
I assume you're you're.
Spaving them from our policies.
Yeah.
And the question.
Are you paid with them?
Or do you.
More.
Because that is a subject that is not.
But then stone yet.
So the trust was.
But that.
But they are not.
They're like you.
Some of the.
Something.
But you come.
Or the two are the.
Other.
Okay.
And so the.
Also the.
Yeah.
We heard some.
That's the.
The.
Okay, we, we've had some people say that.
They don't the.
Some people do like effort entail.
but some other say it needs to be modified a little bit.
My personal opinion is I think the structure of it is good
that it addresses different aspects of security.
For I would say it talks about file integrity.
I have to think about it on the fly.
Sorry.
Okay, thanks, Hank.
Thank you.