WEBVTT 00:00.000 --> 00:13.920 Everyone, I am Sama from TU Dresden, I am also co-chering this TRE open suit at GA4GH and with 00:13.920 --> 00:21.640 me his pack, his flash ports and we will walk you through attestation part which has already 00:21.640 --> 00:26.960 come up in a couple of talks already, so we will be going a bit more technical into it and 00:26.960 --> 00:32.640 the kind of protocols which we need and what security guarantees they provide. 00:32.640 --> 00:37.320 So the relationship to the first time will be the first point then giving a little bit 00:37.320 --> 00:42.680 of context of the whole design space, the technical background is what I will cover and 00:42.680 --> 00:48.160 then pack this going to talk about the open source implementation that he is developing 00:48.160 --> 00:53.440 for the draft standard and finally, if you do not understand anything I will give you just 00:53.440 --> 01:01.480 one final point about what this all means and as I said is a bit technical. 01:01.480 --> 01:08.800 So together with some of my proponents we arranged a marriage of TLS working group with 01:08.800 --> 01:13.320 the rights working group, the remote attestation part and the story goes like this that 01:13.320 --> 01:18.160 rights was ready to accept anything because as I mentioned before the diversion attacks 01:18.160 --> 01:22.120 if you do not have any connection to the TLS protocol it breaks. 01:22.120 --> 01:25.880 So there is no benefit of remote attestation at all. 01:25.880 --> 01:33.640 TLS had two guarantees or two conditions so to say they said no protocol change and you 01:33.640 --> 01:40.000 do not need to and the second one was they should not be any privacy or security regression. 01:40.000 --> 01:45.760 Under these conditions we are fine with it and then things happen, rights ready to accept 01:45.760 --> 01:53.360 anything unconditionally, seat working group was born in the ITF back in October and soon 01:53.360 --> 01:59.040 afterwards some people started breaking the contract that the two parties had that was no change 01:59.040 --> 02:06.720 in the TLS protocol, they started breaking out that with the key schedule changes. 02:06.720 --> 02:12.960 Relevance to the first them is that we are providing of course like we have already provided 02:12.960 --> 02:17.760 free material services for you for confidential computing folks here that we arranged the 02:17.760 --> 02:24.320 marriage and now what we are looking for you as support is to keep this marriage on for 02:24.320 --> 02:29.520 living happily ever after which is the babysitting services and what these are I will tell 02:29.520 --> 02:34.400 you more technically what these babysitting services are that we need from you specifically 02:34.400 --> 02:40.480 for open source part what we are providing peg will explain you his that the implementation 02:40.560 --> 02:45.360 that he has developed and then I will explain a little bit of the formal verification results 02:45.360 --> 02:49.760 that we have so we provide both open source and for use for the community. 02:51.040 --> 02:57.680 Technically what it means is that we have a test it TLS protocol that is a combination or 02:57.680 --> 03:04.160 a composition of attestation protocol and the TLS protocol I can combine it in three different ways 03:04.160 --> 03:08.720 pre and try and post it depends on what point in time the signature is happening on the all the 03:09.440 --> 03:13.440 claims claims from a rare perspective is any of the other majorments and all the things which you put 03:13.440 --> 03:19.040 inside that evidence. So pre and try and post I could do TLS handshake before doing TLS handshake 03:19.040 --> 03:24.240 during or afterwards this leads to these categories and there is a technical difference why we need 03:24.240 --> 03:29.840 to categorize those from a security and privacy perspective meaning that other than the the 03:29.840 --> 03:35.200 security concerns like what exactly in the stack in the whole stack is going to change. 03:35.280 --> 03:39.840 Is it the protocol that is going to change or is it the deployment that is going to change 03:39.840 --> 03:44.720 or is it the higher layer other than higher layer from a perspective of TLS that is going to change 03:44.720 --> 03:50.160 or a protocol perspective. The higher layer you have to change in any case there is no way around 03:50.160 --> 03:55.920 that because you have to do a puzzle you have to do the verification of the of the evidence that you 03:55.920 --> 04:01.520 obtain and other than that basically you have to see what other things you want to change that is 04:01.520 --> 04:07.200 the protocol and the deployment that is for doing pre handshake attestation you need the CA or the 04:07.200 --> 04:15.920 TA to change. For pre handshake there are already replay attacks back in 2024 we had a paper on 04:15.920 --> 04:20.960 this which was basically saying that if you have pre handshake attestation as a reminder you 04:20.960 --> 04:25.600 generate an evidence you keep using it forever it can be used in many many connections many many 04:25.680 --> 04:30.240 clients and you do not know exactly what the status of your thing is. 04:31.840 --> 04:36.800 Intro handshake attestation improves that replay attacks but it still does not protect you from 04:36.800 --> 04:42.080 the diversion attacks which is to say that you want to connect to cloud.example.com what can happen 04:42.080 --> 04:46.160 is I mentioned already in one of the talks what can now go wrong is that you can be 04:46.160 --> 04:52.160 divided over to anywhere in the world if that thing is secure or not that thing only. 04:52.240 --> 04:59.440 If everything in the world is kept secure every server in the world is kept secure you are secured 04:59.440 --> 05:04.960 but if that's not the case then everything falls apart which is a very bad guarantee that's 05:04.960 --> 05:10.640 not what we want in confidential computing right it's saying that I have to trust everyone in the 05:10.640 --> 05:17.440 world to remain secure for me to provide this guarantee over to you which is which is kind of just 05:17.440 --> 05:22.160 a useless guarantee that if everyone is secure of course this is secure so what do we gain by 05:22.160 --> 05:27.600 doing all of this confidential computing whole domain falls apart which you just talked about. 05:29.760 --> 05:35.520 Other than that other than the two attacks the replay and the diversion one there is a relay 05:35.520 --> 05:42.640 attack which we recently just found thanks to Ecker like he pointed out towards this which with 05:42.640 --> 05:46.800 an explode and we found his reasoning to be correct I will give you some context afterwards. 05:47.680 --> 05:55.920 The thing is that when the evidence is not bound to a specific TLS connection it can be 05:55.920 --> 06:01.120 relayed over and you don't know which server it is coming from it can be the case that the 06:01.120 --> 06:06.320 general a tester has generated it but the attacker is pretending and just taking that evidence and 06:06.320 --> 06:12.320 putting it into your into your TLS connection and that's where the whole thing breaks you think that 06:12.320 --> 06:17.600 you are connecting to this genuine AI agent was the example that we took here so any genuine 06:17.600 --> 06:22.240 a tester but that's not really the case you are actually connecting to an adversary which is the 06:22.240 --> 06:29.280 connection that you build. So here is a bit of a technical thing which is really really important to 06:29.280 --> 06:36.240 understand and the thing is that I can do the binding at different levels binding of the evidence 06:36.240 --> 06:42.000 to the to the TLS connection and at the point the intra handshake does this binding which is 06:42.000 --> 06:48.240 this key it's the authentication part has not even yet started the authentication part starts 06:48.240 --> 06:55.120 from the certificate message if you bind your evidence to this intra handshake which is to say 06:55.120 --> 07:01.680 that you want to have the these keys which are for the handshake traffic secret they are basically 07:01.760 --> 07:07.120 not sufficient to authenticate that server you don't actually authenticate it the second point 07:07.120 --> 07:14.960 is that the handshake traffic secret keys are actually meant to encrypt the handshake traffic 07:14.960 --> 07:20.640 which is these handshake messages whether you encrypt them or not it has no impact whatsoever 07:20.640 --> 07:26.080 on the security of the whole protocol they are relevant from privacy perspective but they have nothing 07:26.080 --> 07:30.560 to do with the security what I did in my former proof is that I removed all of these brackets which 07:30.640 --> 07:37.360 are very small shown here I sent them unencrypted on the channel nothing changes every security 07:37.360 --> 07:42.320 property remains the same which is a proof that actually they have nothing to do with it and binding 07:42.320 --> 07:48.320 to this provides you nothing except that false sense of security the ATSE the application traffic 07:48.320 --> 07:53.440 secrets which are generated at this point in time are the real one when it is authenticated the 07:53.440 --> 07:58.400 server is authenticated at that point in time the second thing is that now that is relevant because 07:58.720 --> 08:03.040 the secret that you are going to send over at the end of the channel is going to be 08:03.040 --> 08:07.840 encrypted with this specific key a key derived from this specific key and that is really important 08:07.840 --> 08:13.120 to understand that intra handshake intrinsically does not provide you the guarantee that we actually 08:13.120 --> 08:17.360 need this is the secret that the client wants to protect and not the handshake traffic. 08:18.640 --> 08:24.960 So, what we provide is exported authenticators based solution and this goes back to RFC 961 08:24.960 --> 08:34.720 which cloud fair Nick at cloud fair proposed and the thing is that you build a typical TLS protocol 08:34.720 --> 08:39.920 and then on top of that protocol you do use these messages which is the authenticated request 08:39.920 --> 08:45.120 the server as an attester in this case the client will send that authenticated request and it will 08:45.120 --> 08:49.760 get back an authenticated from the server which will contain three messages of the TLS its own 08:49.840 --> 08:55.520 purpose you reusing these messages because it is well tested and formally verified and these 08:55.520 --> 09:01.120 messages then provide this message in our case will provide you the evidence that the attester 09:01.120 --> 09:08.560 has for the case of the server as attester and that is pretty much my part and now we will 09:08.640 --> 09:11.040 explain you the part for implementation. 09:24.400 --> 09:35.120 I am just going to hold this thing and right so yeah so I was kind of frustrated also 09:35.120 --> 09:43.840 by the the bunch of different ways of doing attestant over attestation together with TLS and yeah 09:43.840 --> 09:49.440 so what wanting to kind of being excited by the idea of standardisation and wanting to kind of push 09:49.440 --> 09:59.920 forward on that and start it looking at how would we actually implement this draft and yeah so the 10:00.880 --> 10:10.400 implementation that I am liking on is like based on RustLS and it kind of the kind of key component 10:10.400 --> 10:15.920 is that you can export key material which is this function down here and that is kind of the the 10:15.920 --> 10:24.400 important thing which allows us to do these exported authenticators it is transport agnostic as in 10:24.400 --> 10:32.800 it just it doesn't necessarily use TCP we can remove the implementation that we kind of 10:33.360 --> 10:41.760 the example implementation is based on quick and supports either one party or either client or server 10:41.760 --> 10:49.520 attestation or both and this work is supported by cyberpunk fellowship program thank you very much 10:50.080 --> 10:59.120 to them and so yeah one of the the difficulty is with implementing this is was kind of the lack of 11:01.200 --> 11:10.640 implementation of RFC 9261 these exported authenticators is not in any of the popular TLS and 11:10.640 --> 11:16.720 implementations yeah even though it's been an IFC since a little while there is a cloud fair 11:16.720 --> 11:23.680 of got a like proof of concept partial implementation of it but actually the point at which 11:24.720 --> 11:31.120 I started implementing this I wasn't aware of that which it was a problem not just because there 11:31.120 --> 11:36.960 wasn't a library to just pick up and use and have exported authenticators ready to go but also 11:36.960 --> 11:45.200 because of like confusion when reading the RFC and about how actually it helps to have a actual code 11:45.520 --> 11:53.840 implementation type of very clear idea of of of what is meant by perhaps these things the other big 11:53.840 --> 12:01.920 blocker was needing to it really uses the TLS handshake messages rustle less intentionally doesn't 12:01.920 --> 12:07.600 expose these and most TLS implementations don't you had so this really is something and it even says 12:07.600 --> 12:13.200 in the IFC that this the implementation of this handshake messages should be done in the TLS implementation 12:13.200 --> 12:21.680 not in kind of application implementation and so yeah I would need to fork rustle less or whatever 12:21.680 --> 12:27.920 other TLS implementation which didn't really want to do so yeah that was that was a bit of a blocker 12:29.120 --> 12:32.080 but yeah got something together which which does kind of 12:33.040 --> 12:41.520 okay it does work and yeah it's kind of zooming out a bit to what you can actually do with 12:41.520 --> 12:50.560 this right now so kind of moving from the the theory to the practical as an implementer and 12:50.560 --> 12:56.400 what when how we might actually use these so yeah it works well for server to server communication 12:56.480 --> 13:03.200 where we've got full control of client and server and the client isn't isn't isn't just you 13:03.200 --> 13:09.200 don't need to worry about supporting the standard TLS client or proxies where we kind of get around 13:09.200 --> 13:18.320 this problem by having standard clients go through a reverse proxy we've got on on your laptop or 13:18.320 --> 13:24.240 whatever the client machine is got a proxy and then on the server as well and meaning you can use 13:24.320 --> 13:32.720 a standard HTTP client or a standard HTTP server so yeah I work at flashbots where we're using a 13:32.720 --> 13:38.640 very similar protocol which is kind of inspired by this but we're not doing all the the consent 13:38.640 --> 13:44.960 the things some of the stuff in the RFC the conceptual message wrappers and the exported 13:44.960 --> 13:51.520 eventicators just for practical reasons not using those but we're using a very similar protocol 13:51.600 --> 13:56.960 and we're using this for this ethereum block building which we do where we need guarantees 13:59.360 --> 14:07.840 the block building strategy is is kind of being done by the rules which is why we need all in all 14:07.840 --> 14:15.680 the kind of orange lines on the diagram we need attested channels so yeah and what what you can't 14:15.680 --> 14:23.280 do right now with this is like obviously browser you can't you know just implement this in 14:23.280 --> 14:30.080 in JavaScript and the browser right now you know it would need the standard to be adopted and then 14:30.080 --> 14:40.800 then probably many years before this browser API which would which would allow this and another 14:40.800 --> 14:46.000 reason the what I kind of block I've been looking at like what a lot of other projects use 14:46.000 --> 14:52.720 particularly like agentic AI there's like a whole bunch of private AI projects popping up that 14:53.920 --> 14:58.560 that use assisted channels and what a lot of these are end up doing is using like nested encryption 14:58.560 --> 15:04.240 where they because they want for example to terminate TLS through cloud flare and then so they're 15:04.240 --> 15:11.200 like doing a having end to end encryption by doing another encryption for example they're HPK 15:11.200 --> 15:20.720 or noise noise protocol and an issue we're having a flash box with using with using this 15:20.720 --> 15:27.360 with generally with TLS and certificate authorities is needing involvement of this 15:27.440 --> 15:34.560 certificate authority at the moment of CVM booth so then if we've got a whole bunch of these nodes 15:34.560 --> 15:42.880 running this running CVMs and we need to you know quickly redeploy a fix and take you know 15:42.880 --> 15:48.720 take them all down and bring them all back up because you can't have the private key be persisted 15:48.720 --> 15:53.920 across reboots because it needs to be generated inside the CVM and stay in the CVM you then kind of 15:53.920 --> 15:58.000 relying on the certificate authority let's encrypt or whatever to do this at a new challenge at 15:58.000 --> 16:02.480 the point of boot and if anything goes wrong with that in some cases it can be quite complicated 16:02.480 --> 16:07.360 and also involving a name server and stuff and you know we're concerned that you know that's 16:07.360 --> 16:14.240 a kind of bottleneck and having having the TLS outside of the CVM would be kind of nicer but it 16:14.240 --> 16:20.960 doesn't give us strong as strong guarantees and so yeah just one more point it's kind of completely 16:20.960 --> 16:28.640 zooming out as to why I am really excited about confidential computing generally and why it's relevant 16:28.640 --> 16:36.400 to free an open source software is because I think yeah we all love to be able to compile and 16:36.400 --> 16:43.840 and compile open source stuff on our own machines and it would be wonderful if there was also a way 16:43.840 --> 16:51.120 to check that opens us software is running on the server side and I think that's yeah I really 16:51.120 --> 17:05.360 exciting use case for computer computer yeah so just wrapping it up that the takeaways from 17:06.640 --> 17:10.960 free an open source perspective we are working towards open source implementation and open source 17:11.120 --> 17:16.560 form of verification both of which will provide you find nice guarantees of what we actually 17:16.560 --> 17:23.920 dream about and not just market about and as a recap pre handshake attestation has the problem 17:23.920 --> 17:29.520 of replay attacks and diversion attacks and intra handshake has the problem of diversion and relay 17:29.520 --> 17:36.400 attacks and finally that post handshake attestation is unavoidable you may want to do attestation 17:36.400 --> 17:41.600 at regular intervals of time or maybe at some point in time after the connection is established 17:41.600 --> 17:46.880 it's unavoidable you can't say that I do pre or intra and I can live with it that's not 17:46.880 --> 17:52.800 possible because the new use case is like agentic AI that was just mentioned so and so on when 17:52.800 --> 17:57.360 the workload is actually changing one time attestation is just useless that doesn't provide you any 17:57.360 --> 18:05.280 guarantee so as a final thing we are requesting some feedback on the draft standard that we have 18:05.360 --> 18:10.160 and some community input and specifically what we would like to hear from this community is 18:10.160 --> 18:15.760 is there someone in the room who wants the protocol changes in the TLS protocol and if yes 18:16.480 --> 18:22.560 give us why and show us how this can be secured these are some of the key references of course 18:22.560 --> 18:28.000 you can have a look afterwards all the resources are here I really want to thank all the people 18:28.000 --> 18:34.960 who have been contributing in this work from asco authors with me as well as as contributors many 18:34.960 --> 18:39.520 of them from this community as well thanks very much I would love to hear from your thoughts 18:56.720 --> 19:00.800 anyone in the room who wants the protocol changes let's say if you don't have a question so I have 19:00.800 --> 19:04.880 a question for you so anyone in the room who thinks that doing the changes to the protocol 19:05.280 --> 19:11.520 TLS protocol itself up to the level of key schedule changes is a visible way to go forward 19:17.760 --> 19:24.160 yeah some of I have a question so I think answer to your question is for the yes but also I have 19:24.960 --> 19:30.080 the very full of the whole question so we have an impressive amount of people here I think 19:31.040 --> 19:36.320 it's much appreciated that you have been you and I've been trying to push for this 19:37.040 --> 19:42.080 here's some of the disation bodies I think it's painful thing like can you maybe share a little 19:42.080 --> 19:47.200 bit on on the meta experience like how painful is it to try to get a consensus with so many 19:47.200 --> 19:52.000 different companies and stakeholders and is there a way is there a light at the end of the tunnel 19:53.040 --> 19:59.440 there is definitely a show okay so to repeat the question so what do we see as the way forward 19:59.520 --> 20:03.680 and what are the different perspectives from the standardization body and how do we see this 20:03.680 --> 20:10.640 standardization happening not all of the contributors here share the same opinion the contributors 20:10.640 --> 20:15.040 mean that basically they have given us very valuable feedback in the many years of the work 20:15.040 --> 20:21.600 that we have been doing like I think five years already some of them might have different opinions 20:21.600 --> 20:26.960 so this is only listing the people who have contributed that we consider very valuable to it 20:26.960 --> 20:33.680 and some of the go-hothers with me who have written papers on it but to specifically mentioned 20:33.680 --> 20:39.280 your comment on the different diverse opinions we do see the light at the end of the tunnel 20:39.280 --> 20:46.480 because of this impossibility proof that we have where I show that even if we do these PLS protocol 20:46.480 --> 20:52.400 changes it's not going to be secure because of this specific reason the server is not authenticated 20:52.400 --> 20:57.680 at this point in time and doing these changes are avoidable they can avoid these changes 21:00.080 --> 21:02.080 thank you very much