WEBVTT 00:00.000 --> 00:17.400 Okay, good morning, everyone, thank you for attending this talk, so today I'm going to present 00:17.400 --> 00:26.160 you all about our work here that the title is actually TC4SE is called trusted channel 00:26.160 --> 00:31.240 for secure on-clave, but basically the whole idea is like the title that I gave in the 00:31.240 --> 00:39.280 false-dem talks, like building like a more high-performance trusted channel for secure on-clave. 00:39.280 --> 00:44.600 So this is basically like a work that I've been doing, I mean like that I did and published 00:44.600 --> 00:51.120 about almost one and a half years ago, and it's already published, but I'm going to 00:51.120 --> 00:56.640 represent here because it is also relevant to the work about attestation and also like 00:56.640 --> 01:02.440 the work itself is publicly available as a source code and also the paper that you can 01:02.440 --> 01:07.400 also obtain if you're more interested in how I'm doing with the work. 01:07.400 --> 01:13.280 So I'm going to start about talking in here, what is the trusted channel in this case, 01:13.280 --> 01:19.400 like I'm trying to borrow the definition from from GASMIA at all about the trusted channel, 01:19.400 --> 01:24.240 basically trusted channel is a secure channel where the trust works, you know, is bound 01:24.240 --> 01:31.240 into the configuration of the endpoints, and that basically in here what our work as well 01:31.240 --> 01:37.520 is that we're trying to focus more on where the trust lies, not on the directly on the 01:37.520 --> 01:46.160 protocol itself, but what are the trust that underlying that underlies the protocol itself, 01:46.160 --> 01:52.080 like in here like if we have to separate machines like machine A and machine B, basically 01:52.080 --> 01:57.040 like the TLS endpoint in here like we'll terminate inside an application and the TLS 01:57.040 --> 02:03.480 is the trust is gained from the private key that is owned by a certain machines and is 02:03.480 --> 02:08.840 verified by a certificate also, some certificate authority where the both machine shoot 02:08.840 --> 02:09.840 trust. 02:09.840 --> 02:17.720 So therefore when the communication and the authentication happens, when each other wants 02:17.720 --> 02:22.840 to authenticate each other, they rely on the trust that they have to disinfectate authority 02:22.840 --> 02:28.920 to establish that that is the valid trusted party that they want to communicate. 02:28.920 --> 02:35.360 So basically the trust boundary in here in the baseline of the TLS channel, basically on 02:35.360 --> 02:41.000 the machines on each machines and on the certificate authority itself. 02:41.000 --> 02:48.920 So from this actually and on our work as well with NLSGX, it comes into the initial questions. 02:48.920 --> 02:53.160 How actually if we want to establish a trusted channel, if we want to build a trusted 02:53.160 --> 03:00.960 communication channel between two separate secure on-clave that is separated by machines, 03:01.000 --> 03:03.560 they actually shoot with terminates the endpoint. 03:03.560 --> 03:07.320 So basically the endpoint should terminate inside the on-clave binary. 03:07.320 --> 03:14.960 If we see from the previous slides the TLS terminates in the application for the application 03:14.960 --> 03:19.960 for the process based on-clave like we found earlier already talk about, basically you 03:19.960 --> 03:24.720 have to terminate the TLS inside the on-clave because that's where actually the cryptographic 03:24.800 --> 03:31.080 and the private parts of the trusted channel will be stored. 03:31.080 --> 03:35.480 So therefore like the end-point should terminate inside the on-clave. 03:35.480 --> 03:42.440 And then how can actually we verify the trusted channel that is, I mean like that is established 03:42.440 --> 03:45.280 by the rightful trusted execution. 03:45.280 --> 03:49.800 So of course in here that we can use a station to prove that the trusted channel is created 03:49.800 --> 03:56.360 by an actual on-clave that is running on a machine that has a T capability in this case 03:56.360 --> 04:02.560 in TLS GX and at the same time actually how to mutually identify each other to achieve 04:02.560 --> 04:04.920 full trust on the trusted channel. 04:04.920 --> 04:10.440 In here we want to attach actually the trust from the trusted channel from the baseline 04:10.440 --> 04:13.160 of the TLS using the attestation. 04:13.160 --> 04:19.560 So actually from the workshop on the Friday actually I also found out that there is a 04:19.560 --> 04:24.680 terminology that I can borrow basically that we perform a T attestation on the T that 04:24.680 --> 04:31.120 is being used for establishing the TLS the on-clave and continuing to that I'm going to 04:31.120 --> 04:35.880 talk a little bit about what is the trust behind the Intel Dcap. 04:35.880 --> 04:41.200 Earlier that Usama already gave an introduction about the Intel Dcap and like there are 04:41.200 --> 04:47.200 attestation specifically for Intel SGX that is Intel APT and Intel Dcap. 04:47.200 --> 04:52.120 So APT is already mentioned as well as already kind of deprecated because Intel gave 04:52.120 --> 04:54.520 more in favor to use Dcap. 04:54.520 --> 05:01.000 So basically this is going forward if you want to establish or use attestation in Intel 05:01.000 --> 05:06.360 SGX or TDX you should you have to use this kind of mechanism. 05:06.360 --> 05:12.600 So in here I'm going to I'm providing you the diagram what is the trust in the underlying 05:12.600 --> 05:15.560 of the Dcap mechanism. 05:15.560 --> 05:22.440 So in the Dcap there is a several enclaves in here which is basically the called I think 05:22.440 --> 05:31.840 infrastructure on-clave or that is important to produce the quotes or basically the attestation 05:31.840 --> 05:39.960 and also like to verify the quotes and also to establish like to obtain what they call the 05:39.960 --> 05:42.040 PC case certificates. 05:42.040 --> 05:50.160 So the trust on the underlying Intel Dcap basically lies from the hardware key that is 05:50.160 --> 05:53.680 that Intel said basically we have to trust Intel in here. 05:53.680 --> 05:59.920 So Intel actually guaranteed that it is installed during the manufacturing process of 05:59.920 --> 06:08.520 the processor so basically it is a hardware-based key and then they derived into the platform 06:08.520 --> 06:15.060 profitioning ID which is basically to identify that it is a valid Intel machine that has 06:15.060 --> 06:16.060 SGX. 06:16.060 --> 06:24.800 Intel basically store this PPI and can use that to identify when using this certification platform 06:24.800 --> 06:30.040 certification on-clave they will generate some and creep the PPI in here and they will 06:30.040 --> 06:35.960 send into Intel PCS server Intel PCS basically a surface by Intel that they will actually 06:35.960 --> 06:43.160 process the PCP ID as a PCK request and then they will generate the PCK certificate which 06:43.160 --> 06:48.920 will be basically similar in like for example in TPM there is endorsement key and endorsement 06:48.920 --> 06:55.360 certificate and Intel PCK certificate is roughly like behaves in a similar way because 06:55.360 --> 07:04.600 they can be used to actually sort like a verify the trust when we are very fine the quotes 07:04.680 --> 07:10.720 that we receive from Intel SGX on-clave and on the same time the hardware key is also used 07:10.720 --> 07:17.360 to derive the root ceiling key which is actually to be used to do for the to generate the 07:17.360 --> 07:23.400 apostation key so all the apostation will actually be signed by this apostation key and 07:23.400 --> 07:29.120 then like it is also derived from the owner epoch basically like some random random number 07:29.120 --> 07:33.280 that is stored in the platform that when you profission the machine for the first time so 07:33.360 --> 07:40.400 basically it kind of gives like an on-limity in the sense basically if you want to to to 07:40.400 --> 07:44.960 reprofission your machines you only need to reset the owner epoch because like you cannot 07:44.960 --> 07:49.040 reset the hardware key because hardware key you always be the same but you want to reset that 07:49.040 --> 07:54.480 because you want to reinstall the machine for example you reset this owner epoch and then like 07:54.480 --> 08:00.240 all the underlying attestation will have a different values because now the root ceiling 08:00.320 --> 08:05.040 key will be different and then the interns like the apostation key will also be different and 08:05.040 --> 08:10.480 then the apostation itself basically it will carry the information from the on-clave measurement 08:10.480 --> 08:16.960 which is MR on-clave which is the hash of the on-clave binaries and also the MR signer which 08:16.960 --> 08:24.320 is the signature of who also the on-clave the creator of the on-clave apart from that we can attach 08:24.320 --> 08:29.760 an authenticated data I think there are some like maybe 40 bytes or something that you can 08:29.840 --> 08:35.440 attach as part of of the quotes and then these quotes will be signed by the quoting on-clave 08:35.440 --> 08:42.880 in here and then the verification can happen by the remote part that they verify that because the 08:42.880 --> 08:48.400 PCK certificate is also attached in here they can verify that if the PCK certificate 08:49.520 --> 08:55.600 has the root of trust into the Intel SGX to the CA because that's how they verify the trust 08:55.600 --> 09:03.680 in the Intel DCAP so going from this basically what is the state of the art that we have there 09:03.680 --> 09:08.640 is the Intel RATLS the one that also have been mentioned a lot basically this is the one that is 09:08.640 --> 09:15.840 proposed by Intel and there are some other work by in here by by Arto Niemie and the 09:15.840 --> 09:21.520 and teams about the trusted socket layer which is the they similarly using attestation in here 09:21.520 --> 09:29.120 but they don't they don't abandon the the the certificate authority if they are using like 09:29.120 --> 09:35.120 PKI infrastructure because in the Intel attestation in here in Intel RATLS they don't 09:35.120 --> 09:42.080 basically use use PKI because they only use basically a self-science certificate the keys 09:42.080 --> 09:46.880 generated inside the on-clave yeah it's generated securely but basically they don't use 09:47.520 --> 09:53.120 PKI mechanism they only use the X5 on-clave certificate as the container of the quotes 09:53.760 --> 10:00.000 so quote verification happens during the handshake like a U-sum already mentioned there is like 10:00.560 --> 10:06.000 like like a pre handshake in the in-tra handshake and post handshake 10:06.000 --> 10:13.280 basically the verification of the RATLS happens in the handshake but the generation of the quotes 10:13.360 --> 10:18.160 happens on the beforehand because it is only happened when when you're initiating the on-clave 10:18.160 --> 10:23.440 for the first time while meanwhile for the trusted socket channel also that is not necessarily 10:23.440 --> 10:32.080 for Intel SGX but basically like it can be applied as well in Intel SGX and then like in this team 10:32.080 --> 10:39.600 basically they quotes the TLS parameters like like for example like the I think like the DC Helman 10:39.680 --> 10:44.400 materials or something like that for for the KX chain and then use that as an attestation so 10:44.400 --> 10:52.960 therefore like the TLS also have the the attestation what do you call like like the 10:52.960 --> 11:03.280 attestation properties so that's basically those two two two what do you call two schemes 11:03.280 --> 11:09.520 that we also evaluate in here and then we identified certain limitations in here one of 11:09.520 --> 11:15.840 them is that dependency on the attestation infrastructure if we actually already see earlier that 11:15.840 --> 11:23.040 the verification like in the decab that you also actually requires to connect into Intel infrastructure 11:23.040 --> 11:28.160 to perform the verification because the one that I haven't mentioned in the previous diagram is how 11:28.160 --> 11:34.320 you perform verification the verification of Intel decab for example the required collateral 11:34.800 --> 11:40.960 can only be obtained from Intel PCS server or if you install what they call a PCCS so they 11:40.960 --> 11:48.560 kind of PC like platform certification cash in service so basically you install a some kind of server 11:48.560 --> 11:53.920 I think like I think it's their reference implementation is not GS server that kind of cash 11:53.920 --> 12:02.400 the request from your machines to PCS so therefore like whenever you request for for for for for 12:02.960 --> 12:08.960 for for for the collateral data for the verification they don't have to spam Intel server so 12:08.960 --> 12:14.640 that's why the like for example I believe that the Azure certification and stuff like that 12:14.640 --> 12:18.960 basically implementing those patterns because like Intel doesn't want everyone just to directly 12:18.960 --> 12:26.560 like spam their server to obtain those data because like if you perform attestation in a more like 12:27.200 --> 12:34.400 like a like a periodic manner I mean basically you can spam Intel has to provide those computing 12:34.400 --> 12:39.360 power and I think that's the one that they want to avoid so they kind of but still like there is a 12:39.360 --> 12:46.400 dependency in here that you have to connect into those PCS or PCCS server and basically if you 12:46.400 --> 12:53.680 depend on building trust a channel into that system if you if adversary basically severe that connection 12:53.760 --> 12:58.000 you cannot establish and trust a channel between on-trace you cannot verify because the verification one of the 12:58.000 --> 13:08.000 verification the verifiers I mean it's unavailable so it can be like one of the like one of the factor 13:08.000 --> 13:17.280 that can potential to be an attack surface another another like issues that we found out is like 13:17.760 --> 13:22.000 performance and also implementation complexity especially if you want to attach 13:22.000 --> 13:30.400 in the parts of inside inside the handshake like the one that that I mentioned the trusted socket layer 13:30.800 --> 13:36.560 implementation that they try to use like the key material for the key exchange as part of the one 13:38.400 --> 13:42.960 used for the attestation so basically they are quoting like the key material for the key exchange 13:43.760 --> 13:49.200 if they I mean like it's quite difficult actually to implement that directly in open SSL so one of our 13:50.240 --> 13:56.000 one of our like goal when when I was doing this research was how easy it would be implemented I mean 13:56.000 --> 14:00.240 it's not that easy to get those information directly from open SSL unless that you actually 14:00.800 --> 14:06.000 like dig down directly into the source code because there's no direct interface to do that 14:07.120 --> 14:12.560 and then the other thing is that also the trust chain and a boundary and especially like if you 14:12.560 --> 14:18.560 like in the intel area TLS they doesn't even have any like a trust like into the into the 14:18.560 --> 14:24.720 root CA certificate so basically you kind of like disregard all the trust chain that it has I mean 14:24.720 --> 14:32.000 like you cannot simply like for example you receive like a certificate from a proper certificate 14:32.000 --> 14:37.040 authority for example less than creep or something like that and you cannot use that in power 14:37.040 --> 14:43.440 together with the attestation so that's why in here that we try to simplify we propose 14:44.160 --> 14:50.560 this what what what we call that TC4S is or like an implementation of a trust channel for secure 14:50.560 --> 14:57.520 on-clave basically to simplify by by by by directing which part that you can trust and which part 14:57.520 --> 15:05.280 that that that you can actually assume based on the protection model of the Intel SGX in here 15:05.360 --> 15:11.840 like I kind of give you like the comparison between the RTLS TLS and TC4S E we try to do a lot of 15:11.840 --> 15:17.120 stuff like in the initial setup even like from the T generation code generation and 15:17.120 --> 15:23.760 verification from the initial setup so therefore during the TLS handshake I mean we don't really 15:23.760 --> 15:30.960 have to do a lot of like like like like like a like a code generation and certification during 15:31.120 --> 15:38.720 when we want to establish a trust channel so from the from the from the design from the trust design 15:38.720 --> 15:44.800 perspective basically this is how it works so in case that we have two machines assume that machine 15:44.800 --> 15:49.680 A will acts as a server that will have like the basically the the main route of trust 15:49.680 --> 15:56.720 basically yeah like we we create a certificate like similar in the RTLS basically create a self 15:56.720 --> 16:03.200 science certificate but then to to let machine B to trust machine A they have to transfer and 16:03.200 --> 16:09.680 then attest that certificate and then the machine B has to has to store the the the trust 16:09.680 --> 16:15.120 that certificate in the trust that certificate store so basically it acts as like like a CA store 16:15.120 --> 16:21.120 like in our operating system but again in the Intel SGX threat model you don't really trust the 16:21.280 --> 16:26.480 operating system itself so you have to store your certificate directly so in here you have your 16:26.480 --> 16:32.800 internal trusted certificate store that you use to actually verify the the certificate later on when 16:32.800 --> 16:39.360 you establish a TLS channel and then on the other hand to let the machine A trust machine B 16:39.360 --> 16:46.960 machine B has to prove themselves by building a CSR from their certificate from their from the 16:46.960 --> 16:53.840 private T and then their CSR has to be quoted I mean like to pass through the at a station 16:53.840 --> 17:00.960 from the SGX and pass into the machine A where machine A will then sign the certificate and 17:00.960 --> 17:07.280 give back into machine B so therefore like machine A machine B can communicate using mutual 17:07.280 --> 17:15.280 mutual authentication like MTLS and then like the the trust can be achieved by like like like the 17:15.360 --> 17:20.400 the certificate the private key of the machine B is actually signed by machine A so and then like 17:20.400 --> 17:25.600 because machine A knows it is actually from them the private keys only stored by them so basically 17:25.600 --> 17:31.920 you're achieving the full trust that a machine B is recognized by machine A and then basically continuing 17:31.920 --> 17:38.960 without having to to repeat that the station when you want to establish the the trust channel 17:38.960 --> 17:47.040 on the next step and in here basically like I'm I'm I'm showing more like the diagrams on 17:47.040 --> 17:54.800 how you establish the the T I mean like to establish the trust like initially like to generate 17:54.800 --> 18:00.240 the the self-science certificate and then build the CSR and then like a perform the at a station 18:00.240 --> 18:06.480 in here generate the at a station in here and then they're exchanging each other and verify each other 18:06.560 --> 18:11.440 and then while the client machine will seal the certificate in their internal trusted store 18:11.440 --> 18:18.240 and then the server machines will sign the certificate signed the CSR and then give back 18:18.240 --> 18:24.560 into the client machines so the client machines can actually use that for the mutual authentication 18:25.680 --> 18:32.320 and finally like we perform some evaluations in here that we kind of see like like 18:33.200 --> 18:40.160 from the network load and also the the time that requires to initiate a channel this mechanism 18:40.880 --> 18:47.440 outperforms other mechanism that performs forifications and at a station verification and 18:47.440 --> 18:54.240 generations during the handshaking like the RTLS and the TSL scheme so therefore like basically 18:55.360 --> 19:01.680 you can you can carry all of the operations regarding at a station in the initial setup 19:02.320 --> 19:07.360 and like during the channel initiation initiation when you're established the TLS channel you 19:07.360 --> 19:12.160 don't have to repeat the at a station but you still have the same trust because the T is generated 19:12.160 --> 19:18.880 inside the on-clave SGX provides the guarantee that the T I mean like if you seal the T I mean only 19:18.880 --> 19:25.040 that on-clave on that machine can unseal the T so therefore it cannot be moved it cannot be migrated 19:25.040 --> 19:30.000 into another machines and then like the trust will still be established I mean the at a station 19:30.000 --> 19:38.000 trust is still there so the challenge that we have in here basically yeah the one in TC4S 19:38.000 --> 19:43.520 if we provide the reference implementation in here that that basically you can follow and it is the 19:43.520 --> 19:49.120 one that is we open source and you can just adapt if you want to have similar scenario you can just 19:49.120 --> 19:54.240 adapt using this scheme and for airtight scenario it is also possible to strip down the intel 19:54.240 --> 19:59.360 decap architecture and infrastructure basically I mentioned earlier that you have to installed 19:59.360 --> 20:04.800 some not GS server and stuff like that we can kind of actually eliminate that and manually 20:04.800 --> 20:11.840 contact intel PCS server obtain our collateral and PCK certificate or self at install into our 20:11.840 --> 20:18.720 on-clave without having to use those type of setup so in in some cases if you want to implement 20:18.800 --> 20:24.720 some kind of airtight scenario you can actually achieve that as well and also this scenario 20:24.720 --> 20:30.720 may also be applied in the on-clave container solutions or even like possibly TDX because like 20:30.720 --> 20:36.160 TDS also use decap so I think they only have a little bit differences in what they are 20:36.160 --> 20:43.040 quoting but this kind of scheme can also be applied in there so finally to conclude basically 20:43.360 --> 20:50.240 this is an attempt to simplify establishing a trosset channel between two remote enclaves 20:50.240 --> 20:55.520 and then basically we leverage the existing TLS protocol without modifying the protocol or even the 20:55.520 --> 21:02.960 handshake itself and then we link the security properties of the PKI of the TLS into the intel intel 21:02.960 --> 21:11.520 decap intel SGX route of trust and then we try to compare qualitatively compare the proposed approach 21:11.520 --> 21:16.800 that it is also a part of the source code so if you if you go into the into the repository you 21:16.800 --> 21:27.120 will also have the example that we try to build the RATLS and also the TSL scheme that we discussed 21:27.120 --> 21:32.800 earlier and basically after after the discussion that we have last Friday I also realized that 21:32.800 --> 21:40.800 now there is the CSR attestation draft that basically performs almost similarly in my opinion and 21:40.800 --> 21:47.040 then that we want to use that for attest the TLS scheme so it's kind of like some similar there 21:47.040 --> 21:53.680 some similarities in that sense so I guess that's it and then that's the link if you want to look 21:53.680 --> 21:59.760 out for more and you can also you can also see the fourth damage for the link into the paper if you 21:59.760 --> 22:05.440 want to see a little bit more details okay thank you very much so if you have any questions we have 22:05.440 --> 22:15.440 about five minutes yeah I guess 22:15.440 --> 22:38.960 okay so the first question is is that how how different it is with the RATLS and then like 22:38.960 --> 22:44.000 the second question is how to maintain the the freshness so the first question the differences 22:44.000 --> 22:51.280 in the RATLS in here is that RATLS doesn't have those like certificate store in there and 22:51.280 --> 22:56.560 basically in RATLS they use the private the private key they generated in the marketplace as 22:56.560 --> 23:02.080 FML so they don't store they don't seal the key I mean it's possible to seal the key but then 23:02.080 --> 23:09.280 I mean they also but one of the point in here is that the verification so typically also happen 23:09.280 --> 23:15.440 during the the establishment of the trust the channel because they don't store the key of each 23:15.440 --> 23:20.800 other so therefore like that's the one that we try to leverage in in the scheme because we have 23:20.800 --> 23:26.400 the certificate store so the and then we retain that certificate store and seal the key as well so 23:26.400 --> 23:31.760 whenever you reboot the uncleaf or there is a power state or stuff like that the trust is still there 23:32.160 --> 23:36.400 and then for the second part about the freshness yeah this is also the questions a lot 23:37.040 --> 23:42.720 like that we that we receive the thing is that Intel at the station actually doesn't 23:42.720 --> 23:48.960 provide any means about freshness if we see this the quote data only give you i'm around 23:48.960 --> 23:54.800 cliff mn signer and some informations about the about the the SGXT CD actually in the in the 23:54.800 --> 23:59.440 collateral that I mentioned you earlier like for example like the I think there is like a 24:00.160 --> 24:04.080 like a software version or something like that that's the only thing that they carry 24:04.080 --> 24:09.520 in the certificate there is no non there is no time and then the other problems actually with Intel 24:09.520 --> 24:16.320 SGXT is that especially in SGX in TDX maybe is a little bit a little bit soft in Intel SGX 24:16.320 --> 24:21.920 basically there's no notion of trust the time so you cannot actually like establish like when is 24:21.920 --> 24:26.960 it created or how fresh it is so that's actually indeed a challenge so for the freshness 24:26.960 --> 24:32.800 this doesn't really solve any replay attack because yeah Intel SGX like Intel D cap and the 24:32.800 --> 24:37.920 at the station they don't provide such thing it's quite different with a TPM at the station 24:37.920 --> 24:43.840 because they do have like at least like their own time counter and then they do have like monotonic 24:43.840 --> 24:48.800 counter internally but Intel SGX they don't have that I mean they did have that but they erased 24:48.800 --> 25:00.240 completely something yeah the question you can inject some user data yeah in this in the 25:00.240 --> 25:05.440 authenticated data itself that's how you inject the data and then that will be part of the quote 25:05.440 --> 25:10.000 itself because the signature of the quote will include the authenticated data so that's actually 25:10.000 --> 25:15.360 where you put the CSR as well so therefore like the CSR can be verified using the the signature 25:15.360 --> 25:24.880 of the quotes yes you can yes you can 25:24.960 --> 25:29.440 I would say not the problem with the details but rather the way that are it's political 25:29.440 --> 25:34.800 itself but yes indeed I mean we can use those nons but the thing is that if you want to see 25:34.800 --> 25:40.000 the freshness in terms of for example in the time frame I mean it's impossible because like you 25:40.000 --> 25:44.160 cannot even store which nons that you have been using for example and then like you can just 25:44.160 --> 25:48.960 repeat the nons when you restart the unpack if you don't store the nons and then like if you 25:48.960 --> 25:57.360 for example you store the on-clave and then seal the data and then the on-clave is rebooted 25:57.360 --> 26:03.600 with the with the nons that is previously has been used but then they replay that I mean 26:03.600 --> 26:08.240 that's the I mean like you can still reuse the nons and then repeat the same stuff because I mean 26:09.040 --> 26:14.960 the freshness in here like for example that you want to achieve is that when are you going to 26:15.200 --> 26:19.600 to to expire of the certificate for example because like in x549 certificate there is like 26:19.600 --> 26:24.240 expiration or something like that this is a problem in tell us just because we cannot really do that 26:24.240 --> 26:31.280 in a sense that the SGX on-clave can aware that this is the this is my current time securely 26:31.280 --> 26:37.040 in a secure manner because there is no notion of a trust of time so for the sense of that freshness 26:37.040 --> 26:43.840 I think that's kind of the difficult stuff that you have to do with SGX yes indeed 26:44.960 --> 27:00.320 can you repeat again yes so the question is that do you verify the m around-clave and 27:00.320 --> 27:05.520 an mr scanner yes during the during the steps that I mentioned earlier in one of the slides 27:05.520 --> 27:09.280 basically that's the part the basically the on-clave should verify because that's how you know 27:09.360 --> 27:14.800 the identity of whom on which on-clave that you're talking to so basically yeah there will that 27:14.800 --> 27:19.760 will be the part of the verification itself as already this coming from a proper the on-clave 27:19.760 --> 27:25.200 that you want to talk to or not because like the identity in here that the Intel attestation gives 27:25.200 --> 27:30.320 is only the identity of the on-clave and the signer typically the signer part is the one that 27:30.320 --> 27:35.840 may be you're more interested because then you know this is the on-clave the idea for something 27:35.840 --> 27:40.960 like that okay thank you