Everyone, I am Sama from TU Dresden, I am also co-chering this TRE open suit at GA4GH and with
me his pack, his flash ports and we will walk you through attestation part which has already
come up in a couple of talks already, so we will be going a bit more technical into it and
the kind of protocols which we need and what security guarantees they provide.
So the relationship to the first time will be the first point then giving a little bit
of context of the whole design space, the technical background is what I will cover and
then pack this going to talk about the open source implementation that he is developing
for the draft standard and finally, if you do not understand anything I will give you just
one final point about what this all means and as I said is a bit technical.
So together with some of my proponents we arranged a marriage of TLS working group with
the rights working group, the remote attestation part and the story goes like this that
rights was ready to accept anything because as I mentioned before the diversion attacks
if you do not have any connection to the TLS protocol it breaks.
So there is no benefit of remote attestation at all.
TLS had two guarantees or two conditions so to say they said no protocol change and you
do not need to and the second one was they should not be any privacy or security regression.
Under these conditions we are fine with it and then things happen, rights ready to accept
anything unconditionally, seat working group was born in the ITF back in October and soon
afterwards some people started breaking the contract that the two parties had that was no change
in the TLS protocol, they started breaking out that with the key schedule changes.
Relevance to the first them is that we are providing of course like we have already provided
free material services for you for confidential computing folks here that we arranged the
marriage and now what we are looking for you as support is to keep this marriage on for
living happily ever after which is the babysitting services and what these are I will tell
you more technically what these babysitting services are that we need from you specifically
for open source part what we are providing peg will explain you his that the implementation
that he has developed and then I will explain a little bit of the formal verification results
that we have so we provide both open source and for use for the community.
Technically what it means is that we have a test it TLS protocol that is a combination or
a composition of attestation protocol and the TLS protocol I can combine it in three different ways
pre and try and post it depends on what point in time the signature is happening on the all the
claims claims from a rare perspective is any of the other majorments and all the things which you put
inside that evidence. So pre and try and post I could do TLS handshake before doing TLS handshake
during or afterwards this leads to these categories and there is a technical difference why we need
to categorize those from a security and privacy perspective meaning that other than the the
security concerns like what exactly in the stack in the whole stack is going to change.
Is it the protocol that is going to change or is it the deployment that is going to change
or is it the higher layer other than higher layer from a perspective of TLS that is going to change
or a protocol perspective. The higher layer you have to change in any case there is no way around
that because you have to do a puzzle you have to do the verification of the of the evidence that you
obtain and other than that basically you have to see what other things you want to change that is
the protocol and the deployment that is for doing pre handshake attestation you need the CA or the
TA to change. For pre handshake there are already replay attacks back in 2024 we had a paper on
this which was basically saying that if you have pre handshake attestation as a reminder you
generate an evidence you keep using it forever it can be used in many many connections many many
clients and you do not know exactly what the status of your thing is.
Intro handshake attestation improves that replay attacks but it still does not protect you from
the diversion attacks which is to say that you want to connect to cloud.example.com what can happen
is I mentioned already in one of the talks what can now go wrong is that you can be
divided over to anywhere in the world if that thing is secure or not that thing only.
If everything in the world is kept secure every server in the world is kept secure you are secured
but if that's not the case then everything falls apart which is a very bad guarantee that's
not what we want in confidential computing right it's saying that I have to trust everyone in the
world to remain secure for me to provide this guarantee over to you which is which is kind of just
a useless guarantee that if everyone is secure of course this is secure so what do we gain by
doing all of this confidential computing whole domain falls apart which you just talked about.
Other than that other than the two attacks the replay and the diversion one there is a relay
attack which we recently just found thanks to Ecker like he pointed out towards this which with
an explode and we found his reasoning to be correct I will give you some context afterwards.
The thing is that when the evidence is not bound to a specific TLS connection it can be
relayed over and you don't know which server it is coming from it can be the case that the
general a tester has generated it but the attacker is pretending and just taking that evidence and
putting it into your into your TLS connection and that's where the whole thing breaks you think that
you are connecting to this genuine AI agent was the example that we took here so any genuine
a tester but that's not really the case you are actually connecting to an adversary which is the
connection that you build. So here is a bit of a technical thing which is really really important to
understand and the thing is that I can do the binding at different levels binding of the evidence
to the to the TLS connection and at the point the intra handshake does this binding which is
this key it's the authentication part has not even yet started the authentication part starts
from the certificate message if you bind your evidence to this intra handshake which is to say
that you want to have the these keys which are for the handshake traffic secret they are basically
not sufficient to authenticate that server you don't actually authenticate it the second point
is that the handshake traffic secret keys are actually meant to encrypt the handshake traffic
which is these handshake messages whether you encrypt them or not it has no impact whatsoever
on the security of the whole protocol they are relevant from privacy perspective but they have nothing
to do with the security what I did in my former proof is that I removed all of these brackets which
are very small shown here I sent them unencrypted on the channel nothing changes every security
property remains the same which is a proof that actually they have nothing to do with it and binding
to this provides you nothing except that false sense of security the ATSE the application traffic
secrets which are generated at this point in time are the real one when it is authenticated the
server is authenticated at that point in time the second thing is that now that is relevant because
the secret that you are going to send over at the end of the channel is going to be
encrypted with this specific key a key derived from this specific key and that is really important
to understand that intra handshake intrinsically does not provide you the guarantee that we actually
need this is the secret that the client wants to protect and not the handshake traffic.
So, what we provide is exported authenticators based solution and this goes back to RFC 961
which cloud fair Nick at cloud fair proposed and the thing is that you build a typical TLS protocol
and then on top of that protocol you do use these messages which is the authenticated request
the server as an attester in this case the client will send that authenticated request and it will
get back an authenticated from the server which will contain three messages of the TLS its own
purpose you reusing these messages because it is well tested and formally verified and these
messages then provide this message in our case will provide you the evidence that the attester
has for the case of the server as attester and that is pretty much my part and now we will
explain you the part for implementation.
I am just going to hold this thing and right so yeah so I was kind of frustrated also
by the the bunch of different ways of doing attestant over attestation together with TLS and yeah
so what wanting to kind of being excited by the idea of standardisation and wanting to kind of push
forward on that and start it looking at how would we actually implement this draft and yeah so the
implementation that I am liking on is like based on RustLS and it kind of the kind of key component
is that you can export key material which is this function down here and that is kind of the the
important thing which allows us to do these exported authenticators it is transport agnostic as in
it just it doesn't necessarily use TCP we can remove the implementation that we kind of
the example implementation is based on quick and supports either one party or either client or server
attestation or both and this work is supported by cyberpunk fellowship program thank you very much
to them and so yeah one of the the difficulty is with implementing this is was kind of the lack of
implementation of RFC 9261 these exported authenticators is not in any of the popular TLS and
implementations yeah even though it's been an IFC since a little while there is a cloud fair
of got a like proof of concept partial implementation of it but actually the point at which
I started implementing this I wasn't aware of that which it was a problem not just because there
wasn't a library to just pick up and use and have exported authenticators ready to go but also
because of like confusion when reading the RFC and about how actually it helps to have a actual code
implementation type of very clear idea of of of what is meant by perhaps these things the other big
blocker was needing to it really uses the TLS handshake messages rustle less intentionally doesn't
expose these and most TLS implementations don't you had so this really is something and it even says
in the IFC that this the implementation of this handshake messages should be done in the TLS implementation
not in kind of application implementation and so yeah I would need to fork rustle less or whatever
other TLS implementation which didn't really want to do so yeah that was that was a bit of a blocker
but yeah got something together which which does kind of
okay it does work and yeah it's kind of zooming out a bit to what you can actually do with
this right now so kind of moving from the the theory to the practical as an implementer and
what when how we might actually use these so yeah it works well for server to server communication
where we've got full control of client and server and the client isn't isn't isn't just you
don't need to worry about supporting the standard TLS client or proxies where we kind of get around
this problem by having standard clients go through a reverse proxy we've got on on your laptop or
whatever the client machine is got a proxy and then on the server as well and meaning you can use
a standard HTTP client or a standard HTTP server so yeah I work at flashbots where we're using a
very similar protocol which is kind of inspired by this but we're not doing all the the consent
the things some of the stuff in the RFC the conceptual message wrappers and the exported
eventicators just for practical reasons not using those but we're using a very similar protocol
and we're using this for this ethereum block building which we do where we need guarantees
the block building strategy is is kind of being done by the rules which is why we need all in all
the kind of orange lines on the diagram we need attested channels so yeah and what what you can't
do right now with this is like obviously browser you can't you know just implement this in
in JavaScript and the browser right now you know it would need the standard to be adopted and then
then probably many years before this browser API which would which would allow this and another
reason the what I kind of block I've been looking at like what a lot of other projects use
particularly like agentic AI there's like a whole bunch of private AI projects popping up that
that use assisted channels and what a lot of these are end up doing is using like nested encryption
where they because they want for example to terminate TLS through cloud flare and then so they're
like doing a having end to end encryption by doing another encryption for example they're HPK
or noise noise protocol and an issue we're having a flash box with using with using this
with generally with TLS and certificate authorities is needing involvement of this
certificate authority at the moment of CVM booth so then if we've got a whole bunch of these nodes
running this running CVMs and we need to you know quickly redeploy a fix and take you know
take them all down and bring them all back up because you can't have the private key be persisted
across reboots because it needs to be generated inside the CVM and stay in the CVM you then kind of
relying on the certificate authority let's encrypt or whatever to do this at a new challenge at
the point of boot and if anything goes wrong with that in some cases it can be quite complicated
and also involving a name server and stuff and you know we're concerned that you know that's
a kind of bottleneck and having having the TLS outside of the CVM would be kind of nicer but it
doesn't give us strong as strong guarantees and so yeah just one more point it's kind of completely
zooming out as to why I am really excited about confidential computing generally and why it's relevant
to free an open source software is because I think yeah we all love to be able to compile and
and compile open source stuff on our own machines and it would be wonderful if there was also a way
to check that opens us software is running on the server side and I think that's yeah I really
exciting use case for computer computer yeah so just wrapping it up that the takeaways from
free an open source perspective we are working towards open source implementation and open source
form of verification both of which will provide you find nice guarantees of what we actually
dream about and not just market about and as a recap pre handshake attestation has the problem
of replay attacks and diversion attacks and intra handshake has the problem of diversion and relay
attacks and finally that post handshake attestation is unavoidable you may want to do attestation
at regular intervals of time or maybe at some point in time after the connection is established
it's unavoidable you can't say that I do pre or intra and I can live with it that's not
possible because the new use case is like agentic AI that was just mentioned so and so on when
the workload is actually changing one time attestation is just useless that doesn't provide you any
guarantee so as a final thing we are requesting some feedback on the draft standard that we have
and some community input and specifically what we would like to hear from this community is
is there someone in the room who wants the protocol changes in the TLS protocol and if yes
give us why and show us how this can be secured these are some of the key references of course
you can have a look afterwards all the resources are here I really want to thank all the people
who have been contributing in this work from asco authors with me as well as as contributors many
of them from this community as well thanks very much I would love to hear from your thoughts
anyone in the room who wants the protocol changes let's say if you don't have a question so I have
a question for you so anyone in the room who thinks that doing the changes to the protocol
TLS protocol itself up to the level of key schedule changes is a visible way to go forward
yeah some of I have a question so I think answer to your question is for the yes but also I have
the very full of the whole question so we have an impressive amount of people here I think
it's much appreciated that you have been you and I've been trying to push for this
here's some of the disation bodies I think it's painful thing like can you maybe share a little
bit on on the meta experience like how painful is it to try to get a consensus with so many
different companies and stakeholders and is there a way is there a light at the end of the tunnel
there is definitely a show okay so to repeat the question so what do we see as the way forward
and what are the different perspectives from the standardization body and how do we see this
standardization happening not all of the contributors here share the same opinion the contributors
mean that basically they have given us very valuable feedback in the many years of the work
that we have been doing like I think five years already some of them might have different opinions
so this is only listing the people who have contributed that we consider very valuable to it
and some of the go-hothers with me who have written papers on it but to specifically mentioned
your comment on the different diverse opinions we do see the light at the end of the tunnel
because of this impossibility proof that we have where I show that even if we do these PLS protocol
changes it's not going to be secure because of this specific reason the server is not authenticated
at this point in time and doing these changes are avoidable they can avoid these changes
thank you very much