WEBVTT 00:00.000 --> 00:13.320 Hello, good morning everyone. I hope you are enjoying the talks excellent presentation 00:13.320 --> 00:21.400 on ARM CCN stuff. So, I am going to continue the chain of talks and my name is Yogesh 00:21.480 --> 00:28.120 Ashpande I work in architecture and technology group in ARM Cambridge and today I am going 00:28.120 --> 00:34.080 to talk about challenges of remote attestation for confidential computing workloads. What are 00:34.080 --> 00:41.080 the challenges one faces? So, as one can see that a CC system is often a complex system 00:41.080 --> 00:47.720 where there is multiple root of trust like one CPU is there which is connected to one 00:47.800 --> 00:53.480 or more GPUs and you can see the model training happens this is a kind of a becoming 00:53.480 --> 01:00.360 an industry kind of a trend to do model training like that and effectively then what what 01:00.360 --> 01:04.920 what it means for attestation effectively in attestor is a collection of attestors where you have 01:04.920 --> 01:10.680 multiple components like multiple root of trust combined together to form a composite attestor 01:10.680 --> 01:16.520 actually. And so, every and basically every individual component has its attestor remote attestation 01:17.480 --> 01:23.480 so, when one needs to assess the trustworthiness of the entire composition one needs to take 01:23.480 --> 01:28.680 individual component attestation and then join the pieces together to evaluate the overall 01:28.680 --> 01:37.240 trustworthiness of the complete attestor. So, in fact within the CPU itself as we discussed just 01:37.240 --> 01:42.360 by the few presenters in the past within the CPU itself there is a workload which runs on a 01:42.440 --> 01:48.120 confidential computing hardware platform. So, effectively if you see the within the CPU itself 01:48.120 --> 01:52.600 it is kind of a layered attester where an attesting environment collects claims about a target 01:52.600 --> 01:58.360 environment which acts as an attesting environment for a workload and collects the claims for 01:58.360 --> 02:04.840 it. So, effectively it is a layered attester meaning you have one layer on top there is another 02:04.840 --> 02:11.000 layer and so, it is again a composition is a kind of a layered composition within the CPU itself. 02:11.160 --> 02:17.560 So, what does this brings into picture? So, what is the impact? So, when we when we talk of 02:17.560 --> 02:23.160 composite attestation it poses many questions. What questions every aspect of attestation is 02:23.160 --> 02:28.520 been touched like when you talk about evidence how the evidence can be constructed for a composite 02:28.520 --> 02:34.440 attestor? How does the supply chain endorsements for individual components be collected together 02:34.440 --> 02:40.360 or how the verifier can make a unified view of the supply chain endorsements coming from different 02:40.440 --> 02:46.280 parts because different components are coming from different vendors and what is the impact 02:46.280 --> 02:51.560 on attestation verifiers is a single verifier enough to do the appraisal of the attester if maybe 02:51.560 --> 02:56.760 not maybe maybe not and if not then how does the attestation results coming from individual 02:56.760 --> 03:01.960 verifiers be collated together joined together so that the lying downstream lying party have a 03:02.600 --> 03:07.880 consistent view of the overall trustworthiness of the composite attestant. 03:11.000 --> 03:16.360 So, we look at each of these individual aspects of the rats and then try to analyze what is the 03:16.360 --> 03:20.680 impact. So, we will start systematically from the attester side attestor produces evidence 03:20.680 --> 03:24.840 and what are the challenges like multiple component evidence is combined to form a composite 03:24.840 --> 03:29.640 evidence and the format and claims can be very different you may have something produced by 03:29.720 --> 03:34.920 in CBO or somebody something produced in some other JSON maybe and then the nature of claims 03:34.920 --> 03:40.760 itself may be different and then you need to join them together to produce an evidence and who 03:40.760 --> 03:46.280 knows I mean there may or may not be a single authority to take the ownership of the complete 03:46.280 --> 03:50.920 evidence then how do you then in such case how do you protect the integrity of the complete 03:50.920 --> 03:57.640 evidence. So, these are the certain set of challenges and in certain systems there may be 03:57.960 --> 04:02.440 requirement that certain amount of certain types of workloads may not be allowed to run on certain 04:02.440 --> 04:07.800 set of hardware platform. So, the platin there should be some kind of a policy and then who owns 04:07.800 --> 04:13.880 that appraisal policy. So, these are the kind of questions or the challenges which are posed 04:13.880 --> 04:18.680 when you try to join different components and create a coherent attestation architecture. 04:19.400 --> 04:25.000 So, that is our architecture does talk a bit about some of the solutions. So, let us look into 04:25.560 --> 04:30.440 that one of the possible solutions is maybe we need a lead verifier on the platform or on the on the 04:30.440 --> 04:35.720 device in the composite device use case the lead verifier job may be simply to collect 04:35.720 --> 04:42.200 component attestor evidences and then join them together it may have its own evidence like 04:42.920 --> 04:48.200 it may have its own target environment or attesting may or may not be it may just collect 04:48.200 --> 04:53.880 evidence push it to the verifier or it may just have a role of an integrator where it takes its ownership 04:53.880 --> 05:03.240 it signs it and sends it evidence sends the composite evidence to the verifier. So, so this is 05:03.240 --> 05:07.800 one possible way of doing it but of course, there are multiple topologies and multiple ways. 05:07.800 --> 05:13.560 So, I would like to highlight what is the work done in the IT efforts working group in 05:13.560 --> 05:19.240 standards body around this and the equivalent implementation in the open source project 05:20.200 --> 05:27.080 so the concise message wrapper is going to be an RFC in like six months time it is in the queue 05:27.080 --> 05:33.480 now and basically it is protocol to how do you collect different type of rat's messages into 05:33.480 --> 05:39.080 a collection and send it over and it could be it could be any rat's message but particularly 05:39.080 --> 05:43.720 we are talking about evidence. So, it is potentially we have seen it is it is powerful use in 05:43.720 --> 05:50.120 combining component evidences and collecting them together to send it to a RF2 verifier and entity 05:50.120 --> 05:55.240 attestation token is already an RFC where you can collect individual component evidence using 05:55.240 --> 06:02.920 each submods and then recently we have started defining different types of attester classes 06:02.920 --> 06:07.560 and that is the taxonomy of composite attester that is very much work in progress in the rat's 06:07.560 --> 06:13.240 working group not yet adopted but we are having regular meetings on that and the eat profile for 06:13.320 --> 06:17.160 device attestation that is something very interesting because when you try to attach 06:19.160 --> 06:25.880 trusted device like GPU into when you want want to connect it into a confidential VM how do you 06:25.880 --> 06:30.520 how does one assess the overall trustworthiness so it gives a profile to produce evidence 06:31.080 --> 06:37.880 for collecting measurements from the trusted device so and of course all this is implemented in 06:37.880 --> 06:42.680 pretty much some of this is completely implemented in variation and some of them in existing 06:42.760 --> 06:47.800 work in progress so the entity attestation token and CMW is pretty mature state in 06:47.800 --> 06:53.000 variation but the bottom to the reds demon is a kind of an agent that sits on the attester 06:53.000 --> 06:58.680 and collects evidence there is a reference implementation in project variation and eat base 06:58.680 --> 07:06.680 device assignment work has been just started so look forward to that as well so now we have 07:06.680 --> 07:11.480 focused on evidence and how do you can collect the evidence let us move on to the endorsements and 07:11.640 --> 07:17.720 reference values so the challenge again is here the same the different reference values are provided 07:17.720 --> 07:25.160 by different vendors they may have different formats for conveying that and then there is no standard 07:25.160 --> 07:31.560 mechanism to query that that kind of endorsements uniformly from across different vendors so 07:31.560 --> 07:37.480 this ecosystem is currently fragmented that brings its own challenges because many supply chain 07:37.560 --> 07:43.480 providers across different hardware as I mentioned needs how does the verify you make sense of 07:43.480 --> 07:51.560 that kind of complexity so and the if when different vendors produce reference values endorsements 07:51.560 --> 07:57.960 in a different format in a different way to query them it is simply a barrier for scaling you 07:57.960 --> 08:04.600 you can't simply scale this kind of a solution so so how do we address this problem so 08:05.560 --> 08:11.240 in our team this is one a few of our colleagues working in different in the rats community 08:11.240 --> 08:16.520 have came together and tried to address this problem by concise selector for endorsement and 08:16.520 --> 08:21.720 reference value that's a draft which is already been adopted in the rats working group so it provides 08:21.720 --> 08:30.200 a uniform way to query endorsements from different suppliers and provides a response in a unified 08:30.280 --> 08:36.040 rash fashion so that the fragmentation in the ecosystem can be harmonized and a consistent way 08:36.040 --> 08:43.160 of producing the endorsements and reference values as well as fetching them in a uniform fashion 08:43.160 --> 08:50.200 is established basically it is based on the root standard called concise reference integrity manifest 08:50.200 --> 08:56.200 so the data model and information model is the data model is very much coming from that and 08:56.680 --> 09:02.840 has been adopted in rat working group the concise reference integrity model and it is pretty much 09:02.840 --> 09:10.920 adopted by most of the vendors whether it is AMD Intel Nvidia and it is been very much going to 09:10.920 --> 09:17.560 be the case for OCP which is one of the data center projects and data centers standards so on the 09:17.560 --> 09:22.200 left is some of the features I won't go too much details about this because I have short amount of 09:22.360 --> 09:27.400 time but I am happy to discuss offline anyone who has any questions on the right is the equivalent 09:27.400 --> 09:33.080 implementation in the open source project version where we have a goalang course of library which 09:33.080 --> 09:38.760 provides which collects evidences in different formats but provides to a verifier in a consistent 09:38.760 --> 09:44.680 format and there is a query response unified API which is defined and there is a rest implementation 09:44.760 --> 09:53.320 of that library now we focus our we discussed about reference values and endorsements values 09:53.320 --> 09:58.520 we discussed about the tester let us know our focus to the verification well when there are as we 09:58.520 --> 10:05.000 see when the composite tester has multiple components a single verifier may not have all the necessary 10:05.000 --> 10:11.400 tools equipments or may not have the necessary expertise to verify everything so it might need to 10:11.480 --> 10:17.960 delegate its work to multiple verifiers produced by their individual vendors so effectively that 10:17.960 --> 10:22.680 may be the case and when there is a case like that you need multi verifier ecosystem then 10:23.400 --> 10:27.880 because as I mentioned there could be lack of knowledge for single entity to stand up and build 10:27.880 --> 10:36.760 that verifier or it could be simply complexities or cost the one single one single entity may not 10:36.760 --> 10:42.760 have all the necessary resources to build the complete complex attestation verification mechanism 10:42.760 --> 10:47.320 so it might need help of their individual vendors to produce and start their attestation 10:47.320 --> 10:52.440 verification service but when there are multiple attestation verification service how do they 10:52.440 --> 10:57.640 coordinate with each other to produce a coherent attestation results for the entire composite 10:57.640 --> 11:03.480 attestation so we have a few of the some of the topological models of interaction between the 11:04.440 --> 11:09.320 and so this is one of the model known as hierarchical model where you get a composite 11:09.320 --> 11:15.320 evidence or combined evidence to a lead verifier who just who just break down the evidence 11:15.320 --> 11:20.120 and send it to the individual component verifiers so you can see that the composite evidence 11:20.120 --> 11:26.680 has been broken down into and component evidences and those are sent to the attestation verifiers 11:26.680 --> 11:30.280 and then you get a attestation results which are partial attestation results from these 11:31.240 --> 11:35.320 they are joined together and returned to the attestor or reliant party based on whatever 11:35.320 --> 11:41.080 model we have and then there is equivalent model known as cascade model where the whole chain is 11:41.080 --> 11:47.080 passed to sequence of verifiers which then individually assesses its own components and then 11:47.080 --> 11:54.280 returns the aggregated attestation results back to the sequence back and the aggregated 11:54.280 --> 11:59.080 attestation results are returned back to the attestor or the reliant party and of course you can combine 11:59.160 --> 12:04.120 these two models to generate a hybrid model wherein the chain one of the verifier acts as a lead 12:04.120 --> 12:13.800 verifier for the downstream verifiers so the models which I presented is is been in the ITF draft 12:13.800 --> 12:18.360 these draft is very much a work in progress again I reiterate this is not yet adopted in the 12:18.360 --> 12:25.160 Rats working group but there has been a sufficient community interest in this work and we have 12:25.160 --> 12:29.800 having regular design meetings on this if anybody has a kind of topological thing feel free to 12:29.800 --> 12:35.640 reach out most important one I want to highlight here is that according to the standards which I 12:35.640 --> 12:42.200 mentioned here that draft is we have started an open source implementation of this lead verifier 12:42.200 --> 12:48.040 which I mentioned you in the so we have started implementing this lead verifier topology this work 12:48.040 --> 12:54.280 has just recently started so this is a kind of a low level design of a lead verifier where you 12:54.600 --> 13:00.360 from the REST API front end you would get the composite evidence media type from that media type 13:00.360 --> 13:08.120 you determine which parser I need to inject and then parser is been invoked to break down the 13:08.120 --> 13:13.400 individual evidences with their own media types and then you dispatch it to individual clients 13:13.400 --> 13:18.760 so you can then dispatch it to a client which talks to maybe an internal trust authority or a 13:18.760 --> 13:23.960 dispatch it to a client which talks to a Nvidia verifier and then you collect the attestation results 13:24.040 --> 13:30.760 from these verifiers and then join them and send aggregated attestation results to one who is 13:30.760 --> 13:37.800 requested the attestation verification so this is very much a work in progress the lead the link 13:37.800 --> 13:44.520 is all the GitHub issues are there if one is interested to look into the open source implementation 13:44.520 --> 13:51.480 this work is started so I come to the last point of course we talked about a tester we talked 13:51.800 --> 13:55.560 about endorsements we talked about verifier but what about the attestation results 13:55.560 --> 14:00.280 well that is the most important because ultimately is the relying party who is consuming the 14:00.280 --> 14:04.760 who is relying on the trust being given to it the trustworthiness assessed by the verifier 14:04.760 --> 14:09.720 so it needs to be simple but at the same time not just with simplicity it needs to express 14:09.720 --> 14:14.760 the compositional semantics it needs to understand that I am getting a results from these individual 14:14.760 --> 14:18.680 components and this is the coherent attestation result I am looking at so 14:19.400 --> 14:24.840 even though there may be component specific attestation results it should have a coherent view 14:24.840 --> 14:32.600 of the entire attestation results so this work is very important because ultimately the 14:32.600 --> 14:37.960 is the stakeholder is the relying party who is relying on the attestation of such kind of complexity 14:39.240 --> 14:45.800 so fortunately we have been working quite a lot in the standards for addressing this and we have 14:45.800 --> 14:51.000 each attestation results which is an obtained in ITF and which is based on an information model 14:51.000 --> 14:58.360 called attestation results for secure interaction and each attestation results is we have tried 14:58.360 --> 15:03.160 and tested either attestation results to see whether we can do compositional semantics where 15:03.160 --> 15:08.520 each sub-mort of each attestation result each sub-mort can contain component attestation results 15:08.520 --> 15:14.920 and you can just express the topology of results in the outer layer and that way it just suffices 15:15.240 --> 15:20.840 to contain the attestation results but I must say that CMW also the concise message 15:20.840 --> 15:25.640 rapper which I mentioned earlier for the evidence can also be very effectively used for conveying 15:25.640 --> 15:31.960 the attestation results where the compositional semantics itself is in the wrapped inside the 15:31.960 --> 15:37.400 message format itself because you can have a CMW inside the CMW so it naturally helps you 15:37.400 --> 15:44.120 build the attestation results in an hierarchical fashion and on the right again as I have been saying 15:44.200 --> 15:48.520 that whatever we work we do in standards is always backed by the open source implementation 15:48.520 --> 15:54.440 so in project version you would find three libraries one goal angle library for ER and the 15:54.440 --> 16:02.440 rust ER library for rust relying rust based integration of this and then there is a Python 16:02.440 --> 16:10.120 ER to decode results yeah so well what I would say is that we have just kind of the composite 16:10.440 --> 16:16.600 attestation story we we have been recently started this work so it's very much under development 16:17.480 --> 16:22.680 but if anybody has any interesting use case which they would love to discuss on composite 16:22.680 --> 16:27.720 attestation and they want to solve please communicate to us where that's working group 16:27.720 --> 16:32.840 rats at ITF dot org and of course on open source implementation if anyone wants to discuss 16:32.840 --> 16:38.120 anything about the open source implementation or if they have a use case which they want to bring 16:38.120 --> 16:49.400 into this community project you are most welcome so thank you so much yes to Zama 16:51.400 --> 16:57.400 okay I understand I think we have been talking easy you are and we can talk offline but I 16:57.400 --> 17:01.720 wanted to make sure also yeah I have concerns not only for practice perspective I have concerns 17:01.720 --> 17:06.200 there from personal perspective which is top open source yeah so my concern here from host 17:06.200 --> 17:13.080 perspective is Intel ITA is not open source and video verified is not open source 17:14.360 --> 17:20.520 this really breaks down the open source spectrum that or the spectrum that we are trying to 17:20.520 --> 17:25.880 make is that as well as in the post and so sorry I didn't get I didn't get the question like 17:25.960 --> 17:31.880 what is my question is Intel ITA has we don't know what policy they apply that's 17:31.880 --> 17:36.840 resources we don't know what protocol they apply that's resource and video has resource 17:36.840 --> 17:42.440 policy grow source protocol so this breaks down the whole open source ecosystem that we want 17:42.440 --> 17:48.040 to develop so I want you to comment on this proposal specifically from host and perspective 17:48.120 --> 17:55.960 how does this maintain the open source spirit of the host okay so I cannot comment on okay the 17:55.960 --> 18:01.880 question is how does this spirit of open source connect with the closed source vendor solutions 18:01.880 --> 18:09.080 so I cannot comment on any specific vendor so to say why they have open source it or why they 18:09.080 --> 18:15.080 have not open source it and why they have not but it doesn't matter if the interface is if 18:15.720 --> 18:21.080 follow a standardized interface to to their very fire and that can be communicated in a 18:21.080 --> 18:26.120 standards way we can always talk to that get the results and combine it I don't see any issue 18:26.120 --> 18:33.960 with that why why are we no it's all open source I don't get that point everything what we are 18:33.960 --> 18:39.320 doing is open source not this but the policy is except so if you don't know the policies you 18:39.320 --> 18:47.320 cannot claim it to be open source right so that that's for them to implement it's for them to 18:47.320 --> 18:53.080 implement yeah I think this is something we should take off like any other questions 18:59.800 --> 19:00.280 thank you 19:09.320 --> 19:11.320 you