All right, folks. Thanks for joining. My name is Yoshimichi. I'm as Fritz Sondi. I'm a
postdoc at ETHZIC in Switzerland. Today, I'm going to be presenting our work, Ari Webbs.
We're not the station for Web Services. This is a joint collaboration with my collaborators
from Key University and Tokyo University in Japan. With the QR code on the right,
a bottom left corner, you can go to the paper and then on the bottom right corner,
you can take a look at the live demo. I do have to note, it's not working right now for
some reason. As we all have, you know, tried to play for the demo gods. This is in work out.
So, yeah, but it works. I promise. All right, let's get going. So, as we have, you know,
as you are in the confidential computing dev room, I'm pretty sure that you are all looking
forward that, you know, teas are going to be the next few thing in, you know, in our services.
This include Web Services as well. So, for instance, there is a other-lim chat service called
the Continuum. This is operated by Edge of the Systems, and they use teas to protect
the prompts, use of prompts when they're interacting with the LLMs. And there are also
other use cases, for instance, they could also be non-operative bloggers. They could also
be secure questionnaires. They could also be a professor presented deep learning with
when they were using Web data. So, let's imagine that you are a, you know, you know,
software engineer at a Web development company. You're like, well, I want to protect
user prompts or user data. Let's stick a tea onto it. And, you know, you for successfully
do it. You pat yourself on your back, saying that, now you're all good. Right? Well,
there's actually a lot of issues. And in this particular work, we are going to be looking
at the issue of remote attestation. So, the multi-station, we have looked at it so much
in this particular bedroom, so I'm not going to be talking too much about it. However, in
the context of Web ecosystem's remote attestation has a compatibility issue. What I mean
by that is that these users, when they're actually trying to interact with tea enabled
Web systems, they will run into the issue where how in the world they will be able to
verify these proofs that are sent from the remote attestation. So, one way of doing it is
to install client software, for instance, like a blog browser plugin. However, this would cause
user friction. So, for instance, you know, they would have to go to like a Web store and they
have to install this and whatnot. And your average user would not like to do that.
On top of this, there is has been a recent research that showed that installing browser plugins
could lead to information leakage. Born that about in a different kind of a paper, but
in these are all the consequences of installing custom client software. Another, you know,
instance could be like, wait, why don't we wait for standardization, right? So, for instance,
there's like rats and there's also this integration with RA with TLS and DTLS, which I'm
going to be covering a little bit later. However, there are two downsides of this. The first
one is that standardization efforts may not result in a final standard all the time. What I mean by
that is that there could be a lot of different conflict of entries, there could be a lot of discussions
and maybe there might be like, well, okay, that's probably not move on forward with this.
Another issue is that the standard, even if we have a standard, the standardization body
cannot force the browser vendors to implement that particular feature into their browsers.
This has been seen in a lot of different cases and the monetization could also be part of that as well.
So, there are a couple of ways to work to this, the first and most closest one is the
verifier that is created by a continuum. The great thing about this verifier is that it actually
is compatible with browsers, but you don't actually need to install anything. However, there is
a confidentiality issue because the entity that is running the verifier and the entity that is
running continuum are the same people. So, you have a conflict of interest.
Okay, so other suit-related issues I really work are rats. That is a standardized array model.
However, the issue with this is that there are any talks about how to integrate this into the
web ecosystem and what kind of issues we rise when you actually do that. Another really work
is integrating a decision directly into the TLS and DATLS layer. The great thing about this,
if this happens, is that it is fully transparent. The remote decision procedure would be fully
transparent to the user, so therefore they do not need to even care about installing anything.
The issue is that this is still an ongoing effort and we still not know what the timeline is
of this outcome of the standard. Given the fact that TML web service is emerging and we are expecting
it to emerge more, we need to have something that works right here right now, which we are
going to introduce our web. Our web's, in short, is a highly compatible remote station scheme
that is, to the current week web ecosystem and this is thanks to the fact that it is built using
well-known, well-established web mechanisms, for instance like WAPKI and Certificate Transparency.
This allows our web's, allows users to verify remote station proofs using existing browsers,
basically they don't need to install any kind of software on their side. This means that it is
immediately deployable and here I should tell you that you should visit the remote, but
well as I said, it does not work right now. Hopefully tomorrow, the issue is that the Certificate
Transparency monitor we are using is down right now and it is not our fault. Hopefully, hopefully,
but anyways, so how does this work? Let's get a little bit deeper into how our system looks like.
So, on top of the user and the service, we also have a untrusted third party verifier
that verifies the remote station proofs, from the TA on the user's behalf.
Note that this is untrusted so it can do whatever it wants, so basically you could try to,
in personate a TA could try to do all sorts of wacky stuff.
What the user does, because it does not want to install any software, it would actually
visit the website that is exposed by the web verifier that lists out all the good stuff about
whether the software was verified or not, whether the proofs were verified or not and what kind
of information is included in the proofs. One thing that I do have to note here is that the service,
the web service, and the verifier are not colluding, meaning that they will not be malicious
at the same time. Okay, so you might think, well, this is very easy, right? No, it's actually not,
there's a lot of challenges we actually had to go over when we're designing the system.
The first one is, as we said, there's a lot of things that could go wrong because we're
assuming a untrusted verifier. So, for instance, when the mouse is verifier is existing and in
this particular case, the service would be trustworthy. They could try to lure these users to visit
their own malicious fake TA website that basically replicates the one that they're trying to visit.
We're trying to, in our paper, we claim that we can prevent this from happening
by having users check whether they're going to the correct domain or not. The fact that
whether they can actually verify that our check this or not is a completely different issues
and it's orthogonal to our work. In a second case, and where the service is malicious,
they could try to lure people our users to a particular fake website and then try to extract
all that good information that trying to collect from them. In this particular case,
we're assuming that the verifier is trustworthy, so the verifier would say,
hey, you're trying to visit a malicious website, please don't proceed.
Our challenge that we had to solve was this issue that a malicious website
could actually try to change the address. The domain name that is tied to a particular TA
to a fake malicious machine that they own. This is why we use certificate transparency,
certificate transparency with log all of these data information that was associated with a
particular domain and it's public key associated to it. So this is the sort of the overview of
our web's. You see a lot of different things, but the most important part is the communicating
face where the user before they would actually visit and start communicating with the TA,
they would actually access the verifier's website to check whether the verifier's website is
up or not this time not, but hey, and then what happens is that the information this
played there is correct or not and then once they're actually verified that all of those
information is correct, then they would start visiting and interacting with the trusted application
from the web service already. So you might be wondering, well, how would other web's work
in a world-real world scenario? So in this particular case, we're going to be assuming that the
user is a user that values security, privacy, and also usability that might not be your average
user that would say, oh, I would be more than happy to install client-size software. This
would be your average user that says, well, I want to benefit from all these nice good stuff,
but also same time I don't want to be installing all that nasty stuff from online.
Aside from the browser software, on the other side, web services, these web services
could be, for instance, services that use things that may not align with user interests.
So what I mean by that, for instance, let's take a look at training machine learning models with
web data. On the user's perspective, they might not want their data to be exposed when their
data is being used for training, but also same time they might want to use these machine
trained models because they could have a lot of benefit from it. On the other side, on web service
point of view, they might want to train these machine learning models with using user data,
but also same time they might want to respect the user's privacy and also at the same time
comply with data regulation laws like GDPR and CCPA. T is a great use case for this. However,
if we're collecting data and the user needs to know that they're being connected to a
correct TE, well, how do we actually do that? On the web's would be your perfect solution.
So, I think I am extremely quick for this presentation. It went really well, but
I'm going to be heading with this slide. If you have any questions, feel free to ask me right now.
Thank you.
Yes, on the back.
So, the question was, the question was that whether this effect model makes sense, the fact that
it verifies untrusted and whether this actually whole thing would only work if the verifier is
untrusted. The short answer to that is no. If the verifier is always trusted, then we don't even
need to do all this kind of stuff. However, there might be a lot of cases where you don't want
a bit trusted verifier. For instance, it could be run by a third party that you might not have heard
about, or it might be run by someone that, you know, by like a, obviously, independent person.
So, in this particular, we wanted to kind of cover these cases as well, but if you want to
trust a verifier, you can always go ahead and do so. However, that is literally going to
go back to the trust model of what the continuum verifier is implementing right now. So,
we wanted to also try to see what we can do if we untrust the verifier.
Really? Okay, sorry about that.
So, you didn't actually explain that I would have followed whatever you do, but after
being all of this, are you telling me that I don't have a track model of you not trusting the
verifier? Are you thinking that you can provide all the verifiers? Oh, I see.
Okay, okay, I think so the question was, and sorry for not understanding it on the first time,
the question was, under the current set model where you don't trust the verifier,
can you still guarantee the correctness and the security of this whole system? Okay.
The short answer to that is, yes, we're not provided right now because it's going to be going through
a lot of different stuff. If you're really interested, we can talk offline. Also,
same time, please take a look at the paper if you also want to take a look at all the security
analysis that we have done. But the short answer to that is, with all these systems that we have
in place, especially for instance, the using the CT monitors and also using like known
browser notifications, the app should we are able to mitigate a lot of the attacks that
an untrusted verifier will be able to try to commit.
I think the person on the back was the first. Sorry.
Are you looking at a one-nerveifier? How could you run multiple verifiers in parallel?
That's a good question. So that's a good question too. The question was, can you run
or are you assuming single verifier or can you run multiple verifiers in parallel?
In the paper, we only assume one verifier. However, it could also be an ecosystem where different
entities could run their own verifiers and users may want to choose which one they want to use,
or the services could choose they want to use. So that's still open for implementation and
design. But in the paper, we only assume right now one. Thank you for a question. Yes, please.
Just a quick question. From a user perspective, like the user will be talking with
an HTTP yourself. What the user needs to go to the verifier and what the user knows
that you are out at the stocking to is somehow a link to this verifier that you open
different sets. And I know that then point I'm talking to is being verified by the verifier.
Okay, so I think the question is how those the user even know that the verifier is correctly
verifying the URL endpoint that is trying to visit. Okay, the answer to that is the fact that
so I didn't talk about this in the presentation because it's a little bit too much details.
However, because you have bring it up right up, I'll talk a little bit more about how we actually
implement this. So in the implementation, what happens is that the TA basically the web service
would have to insert a link into their website to prompt to the user say visit this website
before you actually talk to us. And then that would then jump or basically that would
butt that button would open up the verifier and that verifier would be able to know
these on these kind of refills that the the web ecosystem has implemented that this is the link
that the user is trying to verify and this is the result that I have been verified throughout the
whole time. Again, of course, you might be wondering what if this could happen, what if that could
happen, all these security analysis is in the paper, if you want to know more, you can also
chat offline as well. But that's like the, you know, not show that's what happens.
I remember there was someone, yes, yeah, go ahead.
What up, the example of trying to think of a much more than normal even I wonder if I don't know
how an web service implemented. So this is an scenario where the user knows a web service that is offered
and just has a show something where it's like some external all the software which then provides
which software is expected. What is it another threat? What is that you're trying to take it out?
So if I understand your question correctly, are you asking whether the, so in the, in the
use case of training machine learning models with web data that the user is aware that this is
they're interacting with a team able service. It says a trusted execution environment
or it's clear that it's in a secure environment. It's, they don't know if I can trust the web service
itself because the task like some logging mechanism to send the data somewhere else, it says
I'm here to answer a trusted environment, but the service itself is already broken and I know
it's running securely, but the service is broken. So how can I verify or how do you think about
the web service itself to be trustworthy? So in that bucket here, so the question was, I think
I found it so incorrectly, even if we are have a machine learning training model running into
machine learning training inside a TE, if the web service is broken, it's web service itself is
broken, then all that data that has been collected can be leaked everywhere, right? So the short
answer to that is that we could just chuck that web server inside the TE as well. In this
particular case, we're not assuming that the web server would have to rely on all that data that
is collected by the TE. Like for instance, it could be like, you know, some kind of metric that
only the TE would be collecting and then the web server might not be like, you know, be transparent
to that. But if you want to still implement that, we can just chuck that web server also inside the TE
and we also still have the same issue about, you know, we want the station other webs. So yeah.
Okay, time's up. So yeah, thank you so much.