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