Hello, my name is Fabian Visumann. I'm a master's student at Facebook University of
Applied Sciences and today I'll talk about the integration of InterTDX remote
administration into the SSH protocol. I will start with a really brief overview about the
technologies I've used, then I'll state the project goal that I had and then I'll talk about
the protocol and the implementation. So InterTDX is a confidential computing solution on the
virtual machine level and it isolates a workload from the software outside the cluster
main so the host OS for example and InterTDX remote administration provides us with means to
verify that InterTDX is enabled for a certain virtual machine along with many other attributes
that we can check and verify and the evidence produced can then be verified by the
new realign party and on Azure confidential virtual machines there are some special mechanisms
that Azure provides us with their Azure attestation service. I will also use SSH SSH is a really
common server client protocol that provides us with remote shell access, five transfer or
port forwarding between two machines and it comes with encryption and authentication both
of the server and decline build in. It's a really popular protocol used by many other applications
like Git Asswing and many others. This means if we implement attestation in SSH we can use remote
attestation with many other applications that use SSH. So my goal for this project was to modify
open SSH so that our client only connects to an SSH server that can prove that it's running inside
at TDX enabled the end. In the protocol which is a challenge response protocol the client will
take the role of the challenger requesting attestation and it will also be the reliant party
and the server will take the attesting part. The protocol starts with the usual SSH setup including
authentication and encryption. So from this point on everything happens encrypted the whole
attestation information is only shared encrypted over the secure channel and it also happens
after the client the user has shown the server that is actually a legitimate user of the system
so unauthorized third parties can not request attestation information. The protocol for attestation
then starts with the attestation request that includes a random non-strosen by the client
and the server will then use this non-stru generate the inter TDX quote and it will take this quote
to the error attestation service. I am mentioning other error all the time because that's
why I built the proof of concept. Azure will take the TDX quote generate a signed JSON
vet token and forward this through the server and the server will take the JSON
token and send it to the client for inspection. The client will inspect the JSON vet token
fetch the certificates used for the signage and with these certificates the signature will be
validated and then the claims and denones are validated so you can set up rules that the client
has to check before the connection is established and if everything is okay the usual SSH process continues.
The implementation I did is based on open SSH. I created a new remote attestation SSH service.
A service in SSH is a thing that a client can request from the server from the server so
everything you have just seen happens inside this new service that I built. I fused the
Intel Trust Authority CLI tool for cheap and easy TDX quote generation but I'd like to mention
that I built this in the summer of 2024 so I had to use the preview version for Microsoft Azure
provided by Intel. The Trust Authority CLI binary also needs a privileged process which is
difficult at that stage of the SSH protocol at least in the open SSH implementation.
Because SSHD is a privileged process but at this point SSD spawns another process specifically
for the establishment of the session which is SSH session which has less privileges but
open SSH has a monitoring limitation that we can use to relay messages between these two processes.
Coaching generation looks like this we have the nons that we pass into the Trust Authority CLI
quote command. There's also the option to pass a nons specifically a nons but in my observation
this doesn't end up in the JSON web token so the client can verify that it's actually the
result of this attestation process and as a result of the CLI tool we get the quote and some
runtime data the user data is the base 64 version of the nons we put in.
JWT creation uses a post request to Microsoft Azure. I found this URL in some example I
couldn't get to work but the URL works so we just read what we've got from the tool into a JSON payload
sent this to Azure and get me just retoken. This is a small portion of the token we get at the top
we see the information required to fetch the certificates. These are X509 certificates and we can
use them for validating the JSON payload and then we have some attributes this is only a small
X tract based the XMS runtime namespace and then you see user data which is the base 64 version
of the SHAA 512 version of our nons so this is the step where our client can be sure that
this is not some random attestation JSON the token found on the internet. I've also linked the
full version on JWT that I owe if you want to see more of this and then you have the usual attributes
like the attestation type and whether our TCP is up to date. That RMS Lite you can find my email
there this a demonstration pre-recorded on the GitHub for this project and also there are
links to the slides and the turnpaper I did after the implementation. Thank you.
Yes I know the service request I mentioned the SSH protocol states that a server that gets a request
that can't handle has to deny the request and terminate the connection. In my implementation
the client will shut down the connection if the request is not accepted but I have
fully implemented some kind of negotiation so if we speak to a normal unpatched SSHD it just won't work.
Okay. Kind of a practical reason I had to get my hands on an internet IDX machine and
Azure was the only place where I could get my hands on a machine with a confidential TDAX machine
maybe I didn't have time to do much so in TDAX mode attestation using the Azure service was
the first and only simple way I could have done that. I have no experience beside this project with
an internet IDX or in mode attestation so but it's a really good point yes.
So the question is also related to that in my opinion is when we actually ask the cloud to
why did we do that so we just enjoy and I think that's signed by the cloud provided itself.
Yes and that's where the request in terms that could have happened that the server that you show
in your guide now it could have been made with some further machine yes and that's running on some
other machine but it's saying that I would like to know that it's running on actual machine which I
still trust the cloud service provider to do all of the things and the more attestation in
this case especially the need to not provide any data like this in the specific case of the
content and should be in fact modern activities with the claim that CSP is out of the DCP
would not be of course it's a good starting point and it could be changed somehow but
it's CSP's building into the network. Yes it's it's definitely just a starting point the scenario
I had in mind was let's say I have a bunch of data I want to to back up using SSH and I have the
policy that I only want to dump this on a on a TDX machine that I know is correctly configured so
if I make a mistake in configuration I can notice that using the steps every time I make a backup
but yes in more complex scenarios within the attacker involved there are issues or at the
point where I really don't trust the cloud provider that's totally right
we do anything by using SSH rather than a task quickly in this and
harnessing for this server job and trying to shake a bill do you have a look at some other
literature to do something like with some inclusion of how this application and SSH
can be a task quickly in this or with those IPLs as we have to do so do you have some idea of the
cloud provider? I have read the ITLS paper I think it's just different use cases so as I mentioned
SSH is a really popular tool that is used and if we implement a decision there it can benefit a lot
of applications a quad difference I've seen in the implementation is that TLS can rely on the
presence of X509 as far as I am informed so in TLS we can just use an existing data structure
and embed a decision in there and as we have seen in OpenSSH I had to add X for steps in the protocol
that it's a lot of back and forth between the involved parties
Do they only find their clubs or okay the next steps is, okay thank you