Hello, my name is Fabian Visumann. I'm a master's student at French
Book University of Applied Sciences and today I'll talk about the integration of
InterTDX remote attestation into the SSH protocol.
I will start with a really brief overview about the technologies I've used.
Then I will 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 trust domain, so the host OS for example.
And InterTDX remote attestation 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 underlying 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-clined protocol that provides us with remote
cell access, file 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 ATDX 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 relying 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 an authorized 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 generator to the entity to export.
And it will take this quote to the Azure attestation service.
I'm mentioning other Azure 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 vet token and send it to the client for inspection.
The client will inspect the JSON vet token, catch 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 a rules that the client has to check before the 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.
So everything we have just seen happens inside this new service that I built.
I used the Intel cluster authority CLI tool for cheap and easy TDX code 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 cluster 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 replay messages between these two processes.
Coach generation looks like this.
We have the non-s that we pass into the cluster authority CLI code command.
There's also the option to pass a non-s, specifically a non-s, but in my observation this doesn't end up in the JSON retoken,
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 code and some runtime data.
The user data is the base 64 version of the non-s, 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, send this to Azure, and get the JSON 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 extract.
This is the XMS runtime namespace, and then you see user data, which is the base 64 version of the SHA512 version of our non-sau.
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.io if you want to see more of this.
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.
There's a demonstration pre-recorded on the GitHub for this project, and also there are leads to the slides, and the return paper, either 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 it 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.
I have the same question here.
Kind of a practical reason.
I had to get my hands on an IntellTDX machine, and Azure was the only place where I could get my hands on a machine with a confidential TDX machine.
So maybe I didn't have time to do much, so IntellTDX remote 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 IntellTDX remote attestation, but it's a really good point.
So the question is also related to that in my hand case, when we actually ask the cloud provider to do that, so you just enjoy and you know this.
That sign for the cloud provider itself.
Yes.
And that's where the question stands.
I could have happened that the server that you showed in your diagram, it could have been related to some kind of machine.
Yes.
And that's running on some kind of machine, but it's saying that I would like to know that it's running on actual machine which I accept.
So we still trust the cloud service provider to do all of the things.
And the more application in this case, specifically not to why it can be related.
Like the server in the specific case of the confidential TDX remote attestation.
With the claim that CSP is out of the DCD remote approach, of course it's a good starting point.
And you could be changed somehow.
The CSP is building into the network.
Yes.
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 back up using SSH.
And I have the policy that I only want to dump this on an under ATDX machine.
That I know it's 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.
Any other questions?
Other than the cloud provider.
So how do you think that SSH is referenced from the computer as what kind of things
that's acting on the cloud of the computer?
With that information on specific data.
Do you think you do anything by using SSH rather than a specific data?
Yes.
And I understand that this has a job.
And if you are an interpreter, do you have a look at some other literature?
Do you think you can either do some intuition of clouders?
Have a discussion in SSH?
Can you ask if you can use SSH?
Or do you have any thoughts on that?
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 core 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 you 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.
Okay.
Any final thoughts?
Okay.
Next thanks.
Thank you.