WEBVTT 00:00.000 --> 00:12.920 All right, folks. Thanks for joining. My name is Yoshimichi. I'm as Fritz Sondi. I'm a 00:12.920 --> 00:19.240 postdoc at ETHZIC in Switzerland. Today, I'm going to be presenting our work, Ari Webbs. 00:19.240 --> 00:25.240 We're not the station for Web Services. This is a joint collaboration with my collaborators 00:25.240 --> 00:31.640 from Key University and Tokyo University in Japan. With the QR code on the right, 00:31.640 --> 00:39.320 a bottom left corner, you can go to the paper and then on the bottom right corner, 00:39.320 --> 00:45.160 you can take a look at the live demo. I do have to note, it's not working right now for 00:45.160 --> 00:52.560 some reason. As we all have, you know, tried to play for the demo gods. This is in work out. 00:52.560 --> 01:01.360 So, yeah, but it works. I promise. All right, let's get going. So, as we have, you know, 01:01.360 --> 01:06.200 as you are in the confidential computing dev room, I'm pretty sure that you are all looking 01:06.200 --> 01:12.520 forward that, you know, teas are going to be the next few thing in, you know, in our services. 01:12.520 --> 01:19.160 This include Web Services as well. So, for instance, there is a other-lim chat service called 01:19.160 --> 01:25.800 the Continuum. This is operated by Edge of the Systems, and they use teas to protect 01:25.800 --> 01:33.320 the prompts, use of prompts when they're interacting with the LLMs. And there are also 01:33.320 --> 01:38.440 other use cases, for instance, they could also be non-operative bloggers. They could also 01:38.440 --> 01:43.400 be secure questionnaires. They could also be a professor presented deep learning with 01:43.400 --> 01:51.120 when they were using Web data. So, let's imagine that you are a, you know, you know, 01:51.120 --> 01:57.280 software engineer at a Web development company. You're like, well, I want to protect 01:57.280 --> 02:03.520 user prompts or user data. Let's stick a tea onto it. And, you know, you for successfully 02:03.520 --> 02:10.720 do it. You pat yourself on your back, saying that, now you're all good. Right? Well, 02:10.960 --> 02:15.840 there's actually a lot of issues. And in this particular work, we are going to be looking 02:15.840 --> 02:22.160 at the issue of remote attestation. So, the multi-station, we have looked at it so much 02:22.160 --> 02:26.160 in this particular bedroom, so I'm not going to be talking too much about it. However, in 02:26.160 --> 02:33.280 the context of Web ecosystem's remote attestation has a compatibility issue. What I mean 02:33.280 --> 02:39.920 by that is that these users, when they're actually trying to interact with tea enabled 02:39.920 --> 02:47.040 Web systems, they will run into the issue where how in the world they will be able to 02:47.040 --> 02:53.120 verify these proofs that are sent from the remote attestation. So, one way of doing it is 02:53.120 --> 02:58.560 to install client software, for instance, like a blog browser plugin. However, this would cause 02:58.560 --> 03:02.320 user friction. So, for instance, you know, they would have to go to like a Web store and they 03:02.400 --> 03:07.200 have to install this and whatnot. And your average user would not like to do that. 03:08.400 --> 03:15.440 On top of this, there is has been a recent research that showed that installing browser plugins 03:15.440 --> 03:20.880 could lead to information leakage. Born that about in a different kind of a paper, but 03:20.880 --> 03:27.520 in these are all the consequences of installing custom client software. Another, you know, 03:28.240 --> 03:32.640 instance could be like, wait, why don't we wait for standardization, right? So, for instance, 03:32.640 --> 03:37.360 there's like rats and there's also this integration with RA with TLS and DTLS, which I'm 03:37.360 --> 03:41.600 going to be covering a little bit later. However, there are two downsides of this. The first 03:41.600 --> 03:50.240 one is that standardization efforts may not result in a final standard all the time. What I mean by 03:50.240 --> 03:55.040 that is that there could be a lot of different conflict of entries, there could be a lot of discussions 03:55.040 --> 03:59.760 and maybe there might be like, well, okay, that's probably not move on forward with this. 04:00.800 --> 04:06.640 Another issue is that the standard, even if we have a standard, the standardization body 04:06.640 --> 04:12.480 cannot force the browser vendors to implement that particular feature into their browsers. 04:12.480 --> 04:19.520 This has been seen in a lot of different cases and the monetization could also be part of that as well. 04:20.480 --> 04:27.840 So, there are a couple of ways to work to this, the first and most closest one is the 04:27.840 --> 04:35.280 verifier that is created by a continuum. The great thing about this verifier is that it actually 04:35.280 --> 04:40.480 is compatible with browsers, but you don't actually need to install anything. However, there is 04:40.480 --> 04:46.880 a confidentiality issue because the entity that is running the verifier and the entity that is 04:47.760 --> 04:52.080 running continuum are the same people. So, you have a conflict of interest. 04:53.280 --> 05:00.240 Okay, so other suit-related issues I really work are rats. That is a standardized array model. 05:00.240 --> 05:06.320 However, the issue with this is that there are any talks about how to integrate this into the 05:06.320 --> 05:12.160 web ecosystem and what kind of issues we rise when you actually do that. Another really work 05:12.160 --> 05:17.920 is integrating a decision directly into the TLS and DATLS layer. The great thing about this, 05:17.920 --> 05:22.960 if this happens, is that it is fully transparent. The remote decision procedure would be fully 05:22.960 --> 05:28.320 transparent to the user, so therefore they do not need to even care about installing anything. 05:29.120 --> 05:34.560 The issue is that this is still an ongoing effort and we still not know what the timeline is 05:35.040 --> 05:45.520 of this outcome of the standard. Given the fact that TML web service is emerging and we are expecting 05:45.520 --> 05:53.040 it to emerge more, we need to have something that works right here right now, which we are 05:53.040 --> 06:01.280 going to introduce our web. Our web's, in short, is a highly compatible remote station scheme 06:01.920 --> 06:08.480 that is, to the current week web ecosystem and this is thanks to the fact that it is built using 06:08.480 --> 06:15.280 well-known, well-established web mechanisms, for instance like WAPKI and Certificate Transparency. 06:17.440 --> 06:23.760 This allows our web's, allows users to verify remote station proofs using existing browsers, 06:23.760 --> 06:30.480 basically they don't need to install any kind of software on their side. This means that it is 06:30.480 --> 06:36.400 immediately deployable and here I should tell you that you should visit the remote, but 06:37.360 --> 06:44.720 well as I said, it does not work right now. Hopefully tomorrow, the issue is that the Certificate 06:44.720 --> 06:51.360 Transparency monitor we are using is down right now and it is not our fault. Hopefully, hopefully, 06:51.360 --> 07:00.400 but anyways, so how does this work? Let's get a little bit deeper into how our system looks like. 07:00.720 --> 07:07.440 So, on top of the user and the service, we also have a untrusted third party verifier 07:07.440 --> 07:14.240 that verifies the remote station proofs, from the TA on the user's behalf. 07:15.600 --> 07:20.880 Note that this is untrusted so it can do whatever it wants, so basically you could try to, 07:20.880 --> 07:24.640 in personate a TA could try to do all sorts of wacky stuff. 07:25.040 --> 07:31.520 What the user does, because it does not want to install any software, it would actually 07:31.520 --> 07:39.760 visit the website that is exposed by the web verifier that lists out all the good stuff about 07:39.760 --> 07:46.720 whether the software was verified or not, whether the proofs were verified or not and what kind 07:46.720 --> 07:53.360 of information is included in the proofs. One thing that I do have to note here is that the service, 07:53.440 --> 08:00.080 the web service, and the verifier are not colluding, meaning that they will not be malicious 08:00.080 --> 08:09.200 at the same time. Okay, so you might think, well, this is very easy, right? No, it's actually not, 08:09.200 --> 08:14.240 there's a lot of challenges we actually had to go over when we're designing the system. 08:14.240 --> 08:19.520 The first one is, as we said, there's a lot of things that could go wrong because we're 08:19.520 --> 08:26.720 assuming a untrusted verifier. So, for instance, when the mouse is verifier is existing and in 08:26.720 --> 08:33.840 this particular case, the service would be trustworthy. They could try to lure these users to visit 08:33.840 --> 08:40.640 their own malicious fake TA website that basically replicates the one that they're trying to visit. 08:41.360 --> 08:46.480 We're trying to, in our paper, we claim that we can prevent this from happening 08:47.280 --> 08:53.120 by having users check whether they're going to the correct domain or not. The fact that 08:53.120 --> 08:57.520 whether they can actually verify that our check this or not is a completely different issues 08:57.520 --> 09:04.560 and it's orthogonal to our work. In a second case, and where the service is malicious, 09:04.560 --> 09:10.800 they could try to lure people our users to a particular fake website and then try to extract 09:10.800 --> 09:15.440 all that good information that trying to collect from them. In this particular case, 09:15.520 --> 09:21.280 we're assuming that the verifier is trustworthy, so the verifier would say, 09:21.280 --> 09:25.120 hey, you're trying to visit a malicious website, please don't proceed. 09:27.680 --> 09:33.520 Our challenge that we had to solve was this issue that a malicious website 09:33.520 --> 09:41.440 could actually try to change the address. The domain name that is tied to a particular TA 09:41.440 --> 09:50.560 to a fake malicious machine that they own. This is why we use certificate transparency, 09:50.560 --> 10:00.240 certificate transparency with log all of these data information that was associated with a 10:00.240 --> 10:09.040 particular domain and it's public key associated to it. So this is the sort of the overview of 10:09.040 --> 10:14.800 our web's. You see a lot of different things, but the most important part is the communicating 10:14.800 --> 10:20.880 face where the user before they would actually visit and start communicating with the TA, 10:20.880 --> 10:28.080 they would actually access the verifier's website to check whether the verifier's website is 10:29.200 --> 10:36.080 up or not this time not, but hey, and then what happens is that the information this 10:36.080 --> 10:41.760 played there is correct or not and then once they're actually verified that all of those 10:41.760 --> 10:48.720 information is correct, then they would start visiting and interacting with the trusted application 10:48.720 --> 10:58.640 from the web service already. So you might be wondering, well, how would other web's work 10:58.640 --> 11:03.360 in a world-real world scenario? So in this particular case, we're going to be assuming that the 11:03.360 --> 11:10.720 user is a user that values security, privacy, and also usability that might not be your average 11:10.720 --> 11:15.680 user that would say, oh, I would be more than happy to install client-size software. This 11:15.680 --> 11:21.280 would be your average user that says, well, I want to benefit from all these nice good stuff, 11:21.280 --> 11:26.400 but also same time I don't want to be installing all that nasty stuff from online. 11:26.560 --> 11:34.000 Aside from the browser software, on the other side, web services, these web services 11:34.000 --> 11:41.040 could be, for instance, services that use things that may not align with user interests. 11:41.040 --> 11:47.040 So what I mean by that, for instance, let's take a look at training machine learning models with 11:47.040 --> 11:54.320 web data. On the user's perspective, they might not want their data to be exposed when their 11:54.320 --> 11:59.440 data is being used for training, but also same time they might want to use these machine 11:59.440 --> 12:07.040 trained models because they could have a lot of benefit from it. On the other side, on web service 12:07.040 --> 12:12.080 point of view, they might want to train these machine learning models with using user data, 12:12.080 --> 12:18.000 but also same time they might want to respect the user's privacy and also at the same time 12:18.000 --> 12:27.120 comply with data regulation laws like GDPR and CCPA. T is a great use case for this. However, 12:27.120 --> 12:32.320 if we're collecting data and the user needs to know that they're being connected to a 12:32.320 --> 12:38.800 correct TE, well, how do we actually do that? On the web's would be your perfect solution. 12:39.120 --> 12:46.560 So, I think I am extremely quick for this presentation. It went really well, but 12:48.000 --> 12:54.560 I'm going to be heading with this slide. If you have any questions, feel free to ask me right now. 12:54.560 --> 12:55.360 Thank you. 12:55.360 --> 13:03.120 Yes, on the back. 13:03.120 --> 13:30.400 So, the question was, the question was that whether this effect model makes sense, the fact that 13:30.400 --> 13:36.720 it verifies untrusted and whether this actually whole thing would only work if the verifier is 13:36.720 --> 13:42.720 untrusted. The short answer to that is no. If the verifier is always trusted, then we don't even 13:42.720 --> 13:47.840 need to do all this kind of stuff. However, there might be a lot of cases where you don't want 13:47.840 --> 13:53.840 a bit trusted verifier. For instance, it could be run by a third party that you might not have heard 13:53.840 --> 14:02.160 about, or it might be run by someone that, you know, by like a, obviously, independent person. 14:02.160 --> 14:07.440 So, in this particular, we wanted to kind of cover these cases as well, but if you want to 14:07.440 --> 14:14.320 trust a verifier, you can always go ahead and do so. However, that is literally going to 14:14.320 --> 14:20.000 go back to the trust model of what the continuum verifier is implementing right now. So, 14:20.080 --> 14:26.320 we wanted to also try to see what we can do if we untrust the verifier. 14:29.920 --> 14:31.600 Really? Okay, sorry about that. 14:50.080 --> 14:55.040 So, you didn't actually explain that I would have followed whatever you do, but after 14:55.040 --> 15:00.160 being all of this, are you telling me that I don't have a track model of you not trusting the 15:00.160 --> 15:05.200 verifier? Are you thinking that you can provide all the verifiers? Oh, I see. 15:07.200 --> 15:12.000 Okay, okay, I think so the question was, and sorry for not understanding it on the first time, 15:12.000 --> 15:18.960 the question was, under the current set model where you don't trust the verifier, 15:19.040 --> 15:24.640 can you still guarantee the correctness and the security of this whole system? Okay. 15:25.680 --> 15:32.320 The short answer to that is, yes, we're not provided right now because it's going to be going through 15:32.320 --> 15:35.920 a lot of different stuff. If you're really interested, we can talk offline. Also, 15:35.920 --> 15:40.320 same time, please take a look at the paper if you also want to take a look at all the security 15:40.320 --> 15:44.880 analysis that we have done. But the short answer to that is, with all these systems that we have 15:44.880 --> 15:50.720 in place, especially for instance, the using the CT monitors and also using like known 15:50.720 --> 15:55.360 browser notifications, the app should we are able to mitigate a lot of the attacks that 15:55.360 --> 15:58.320 an untrusted verifier will be able to try to commit. 16:04.320 --> 16:06.320 I think the person on the back was the first. Sorry. 16:06.320 --> 16:10.880 Are you looking at a one-nerveifier? How could you run multiple verifiers in parallel? 16:11.920 --> 16:18.800 That's a good question. So that's a good question too. The question was, can you run 16:18.800 --> 16:23.600 or are you assuming single verifier or can you run multiple verifiers in parallel? 16:24.720 --> 16:30.880 In the paper, we only assume one verifier. However, it could also be an ecosystem where different 16:30.880 --> 16:36.080 entities could run their own verifiers and users may want to choose which one they want to use, 16:36.080 --> 16:42.720 or the services could choose they want to use. So that's still open for implementation and 16:42.720 --> 16:48.080 design. But in the paper, we only assume right now one. Thank you for a question. Yes, please. 16:48.080 --> 16:55.120 Just a quick question. From a user perspective, like the user will be talking with 16:55.120 --> 17:03.680 an HTTP yourself. What the user needs to go to the verifier and what the user knows 17:04.320 --> 17:11.120 that you are out at the stocking to is somehow a link to this verifier that you open 17:11.120 --> 17:20.800 different sets. And I know that then point I'm talking to is being verified by the verifier. 17:21.760 --> 17:28.240 Okay, so I think the question is how those the user even know that the verifier is correctly 17:28.240 --> 17:37.520 verifying the URL endpoint that is trying to visit. Okay, the answer to that is the fact that 17:37.520 --> 17:42.720 so I didn't talk about this in the presentation because it's a little bit too much details. 17:42.720 --> 17:47.280 However, because you have bring it up right up, I'll talk a little bit more about how we actually 17:47.280 --> 17:52.880 implement this. So in the implementation, what happens is that the TA basically the web service 17:52.880 --> 18:00.800 would have to insert a link into their website to prompt to the user say visit this website 18:00.800 --> 18:07.120 before you actually talk to us. And then that would then jump or basically that would 18:07.120 --> 18:13.200 butt that button would open up the verifier and that verifier would be able to know 18:13.520 --> 18:19.200 these on these kind of refills that the the web ecosystem has implemented that this is the link 18:19.200 --> 18:26.400 that the user is trying to verify and this is the result that I have been verified throughout the 18:26.400 --> 18:33.440 whole time. Again, of course, you might be wondering what if this could happen, what if that could 18:33.440 --> 18:37.760 happen, all these security analysis is in the paper, if you want to know more, you can also 18:37.760 --> 18:41.680 chat offline as well. But that's like the, you know, not show that's what happens. 18:43.040 --> 18:45.760 I remember there was someone, yes, yeah, go ahead. 18:45.760 --> 18:53.120 What up, the example of trying to think of a much more than normal even I wonder if I don't know 18:53.120 --> 19:02.400 how an web service implemented. So this is an scenario where the user knows a web service that is offered 19:02.400 --> 19:08.080 and just has a show something where it's like some external all the software which then provides 19:08.080 --> 19:14.320 which software is expected. What is it another threat? What is that you're trying to take it out? 19:15.200 --> 19:22.400 So if I understand your question correctly, are you asking whether the, so in the, in the 19:22.400 --> 19:30.720 use case of training machine learning models with web data that the user is aware that this is 19:30.800 --> 19:35.040 they're interacting with a team able service. It says a trusted execution environment 19:35.040 --> 19:41.680 or it's clear that it's in a secure environment. It's, they don't know if I can trust the web service 19:41.680 --> 19:46.720 itself because the task like some logging mechanism to send the data somewhere else, it says 19:46.720 --> 19:51.360 I'm here to answer a trusted environment, but the service itself is already broken and I know 19:51.360 --> 19:59.760 it's running securely, but the service is broken. So how can I verify or how do you think about 20:00.080 --> 20:05.840 the web service itself to be trustworthy? So in that bucket here, so the question was, I think 20:05.840 --> 20:11.600 I found it so incorrectly, even if we are have a machine learning training model running into 20:11.600 --> 20:17.360 machine learning training inside a TE, if the web service is broken, it's web service itself is 20:17.360 --> 20:24.640 broken, then all that data that has been collected can be leaked everywhere, right? So the short 20:24.640 --> 20:30.160 answer to that is that we could just chuck that web server inside the TE as well. In this 20:30.160 --> 20:36.720 particular case, we're not assuming that the web server would have to rely on all that data that 20:36.720 --> 20:41.760 is collected by the TE. Like for instance, it could be like, you know, some kind of metric that 20:41.760 --> 20:46.720 only the TE would be collecting and then the web server might not be like, you know, be transparent 20:46.720 --> 20:51.840 to that. But if you want to still implement that, we can just chuck that web server also inside the TE 20:51.840 --> 20:58.480 and we also still have the same issue about, you know, we want the station other webs. So yeah. 20:59.120 --> 21:02.000 Okay, time's up. So yeah, thank you so much.