WEBVTT 00:00.000 --> 00:16.000 Hello, my name is Fabian Visumann. I'm a master's student at Facebook University of 00:16.000 --> 00:21.200 Applied Sciences and today I'll talk about the integration of InterTDX remote 00:21.200 --> 00:29.440 administration into the SSH protocol. I will start with a really brief overview about the 00:29.440 --> 00:35.600 technologies I've used, then I'll state the project goal that I had and then I'll talk about 00:35.600 --> 00:44.480 the protocol and the implementation. So InterTDX is a confidential computing solution on the 00:44.480 --> 00:50.320 virtual machine level and it isolates a workload from the software outside the cluster 00:50.320 --> 00:58.160 main so the host OS for example and InterTDX remote administration provides us with means to 00:58.160 --> 01:06.880 verify that InterTDX is enabled for a certain virtual machine along with many other attributes 01:06.880 --> 01:12.640 that we can check and verify and the evidence produced can then be verified by the 01:12.640 --> 01:19.440 new realign party and on Azure confidential virtual machines there are some special mechanisms 01:19.440 --> 01:30.960 that Azure provides us with their Azure attestation service. I will also use SSH SSH is a really 01:30.960 --> 01:36.320 common server client protocol that provides us with remote shell access, five transfer or 01:36.320 --> 01:42.480 port forwarding between two machines and it comes with encryption and authentication both 01:42.480 --> 01:49.280 of the server and decline build in. It's a really popular protocol used by many other applications 01:49.280 --> 01:56.880 like Git Asswing and many others. This means if we implement attestation in SSH we can use remote 01:56.960 --> 02:06.320 attestation with many other applications that use SSH. So my goal for this project was to modify 02:06.320 --> 02:15.440 open SSH so that our client only connects to an SSH server that can prove that it's running inside 02:15.440 --> 02:24.720 at TDX enabled the end. In the protocol which is a challenge response protocol the client will 02:24.720 --> 02:31.040 take the role of the challenger requesting attestation and it will also be the reliant party 02:31.040 --> 02:40.400 and the server will take the attesting part. The protocol starts with the usual SSH setup including 02:40.400 --> 02:47.040 authentication and encryption. So from this point on everything happens encrypted the whole 02:47.040 --> 02:53.600 attestation information is only shared encrypted over the secure channel and it also happens 02:53.600 --> 03:02.480 after the client the user has shown the server that is actually a legitimate user of the system 03:02.480 --> 03:12.080 so unauthorized third parties can not request attestation information. The protocol for attestation 03:12.080 --> 03:17.440 then starts with the attestation request that includes a random non-strosen by the client 03:19.840 --> 03:27.520 and the server will then use this non-stru generate the inter TDX quote and it will take this quote 03:27.600 --> 03:32.960 to the error attestation service. I am mentioning other error all the time because that's 03:32.960 --> 03:40.560 why I built the proof of concept. Azure will take the TDX quote generate a signed JSON 03:40.560 --> 03:47.520 vet token and forward this through the server and the server will take the JSON 03:47.520 --> 03:54.320 token and send it to the client for inspection. The client will inspect the JSON vet token 03:54.400 --> 04:01.520 fetch the certificates used for the signage and with these certificates the signature will be 04:01.520 --> 04:08.960 validated and then the claims and denones are validated so you can set up rules that the client 04:08.960 --> 04:18.480 has to check before the connection is established and if everything is okay the usual SSH process continues. 04:19.200 --> 04:29.200 The implementation I did is based on open SSH. I created a new remote attestation SSH service. 04:29.200 --> 04:37.680 A service in SSH is a thing that a client can request from the server from the server so 04:37.680 --> 04:45.760 everything you have just seen happens inside this new service that I built. I fused the 04:45.760 --> 04:52.960 Intel Trust Authority CLI tool for cheap and easy TDX quote generation but I'd like to mention 04:52.960 --> 05:01.040 that I built this in the summer of 2024 so I had to use the preview version for Microsoft Azure 05:01.040 --> 05:08.320 provided by Intel. The Trust Authority CLI binary also needs a privileged process which is 05:08.320 --> 05:14.000 difficult at that stage of the SSH protocol at least in the open SSH implementation. 05:14.320 --> 05:23.600 Because SSHD is a privileged process but at this point SSD spawns another process specifically 05:23.600 --> 05:32.000 for the establishment of the session which is SSH session which has less privileges but 05:32.640 --> 05:40.640 open SSH has a monitoring limitation that we can use to relay messages between these two processes. 05:44.480 --> 05:50.800 Coaching generation looks like this we have the nons that we pass into the Trust Authority CLI 05:50.800 --> 05:58.480 quote command. There's also the option to pass a nons specifically a nons but in my observation 05:58.480 --> 06:04.480 this doesn't end up in the JSON web token so the client can verify that it's actually the 06:04.480 --> 06:11.520 result of this attestation process and as a result of the CLI tool we get the quote and some 06:11.600 --> 06:16.400 runtime data the user data is the base 64 version of the nons we put in. 06:18.400 --> 06:25.440 JWT creation uses a post request to Microsoft Azure. I found this URL in some example I 06:25.440 --> 06:32.720 couldn't get to work but the URL works so we just read what we've got from the tool into a JSON payload 06:32.720 --> 06:39.440 sent this to Azure and get me just retoken. This is a small portion of the token we get at the top 06:39.440 --> 06:46.880 we see the information required to fetch the certificates. These are X509 certificates and we can 06:46.880 --> 06:54.960 use them for validating the JSON payload and then we have some attributes this is only a small 06:54.960 --> 07:02.960 X tract based the XMS runtime namespace and then you see user data which is the base 64 version 07:02.960 --> 07:10.640 of the SHAA 512 version of our nons so this is the step where our client can be sure that 07:11.520 --> 07:19.440 this is not some random attestation JSON the token found on the internet. I've also linked the 07:19.440 --> 07:26.880 full version on JWT that I owe if you want to see more of this and then you have the usual attributes 07:26.880 --> 07:38.800 like the attestation type and whether our TCP is up to date. That RMS Lite you can find my email 07:38.800 --> 07:47.920 there this a demonstration pre-recorded on the GitHub for this project and also there are 07:47.920 --> 08:02.480 links to the slides and the turnpaper I did after the implementation. Thank you. 08:09.760 --> 08:17.600 Yes I know the service request I mentioned the SSH protocol states that a server that gets a request 08:17.600 --> 08:24.000 that can't handle has to deny the request and terminate the connection. In my implementation 08:25.120 --> 08:31.600 the client will shut down the connection if the request is not accepted but I have 08:31.600 --> 08:41.600 fully implemented some kind of negotiation so if we speak to a normal unpatched SSHD it just won't work. 08:41.600 --> 09:05.840 Okay. Kind of a practical reason I had to get my hands on an internet IDX machine and 09:05.840 --> 09:13.920 Azure was the only place where I could get my hands on a machine with a confidential TDAX machine 09:20.160 --> 09:29.360 maybe I didn't have time to do much so in TDAX mode attestation using the Azure service was 09:29.360 --> 09:36.560 the first and only simple way I could have done that. I have no experience beside this project with 09:36.560 --> 09:40.720 an internet IDX or in mode attestation so but it's a really good point yes. 09:41.680 --> 09:48.000 So the question is also related to that in my opinion is when we actually ask the cloud to 09:48.000 --> 09:54.000 why did we do that so we just enjoy and I think that's signed by the cloud provided itself. 09:54.640 --> 09:59.200 Yes and that's where the request in terms that could have happened that the server that you show 09:59.200 --> 10:03.520 in your guide now it could have been made with some further machine yes and that's running on some 10:03.520 --> 10:08.480 other machine but it's saying that I would like to know that it's running on actual machine which I 10:09.440 --> 10:14.960 still trust the cloud service provider to do all of the things and the more attestation in 10:14.960 --> 10:21.440 this case especially the need to not provide any data like this in the specific case of the 10:21.440 --> 10:26.560 content and should be in fact modern activities with the claim that CSP is out of the DCP 10:26.560 --> 10:33.520 would not be of course it's a good starting point and it could be changed somehow but 10:33.520 --> 10:43.680 it's CSP's building into the network. Yes it's it's definitely just a starting point the scenario 10:43.680 --> 10:52.080 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 10:52.080 --> 11:01.440 policy that I only want to dump this on a on a TDX machine that I know is correctly configured so 11:01.440 --> 11:06.880 if I make a mistake in configuration I can notice that using the steps every time I make a backup 11:07.600 --> 11:13.760 but yes in more complex scenarios within the attacker involved there are issues or at the 11:13.760 --> 11:17.360 point where I really don't trust the cloud provider that's totally right 11:44.080 --> 11:48.480 we do anything by using SSH rather than a task quickly in this and 11:48.480 --> 11:55.600 harnessing for this server job and trying to shake a bill do you have a look at some other 11:55.600 --> 12:01.360 literature to do something like with some inclusion of how this application and SSH 12:01.360 --> 12:08.080 can be a task quickly in this or with those IPLs as we have to do so do you have some idea of the 12:08.400 --> 12:16.880 cloud provider? I have read the ITLS paper I think it's just different use cases so as I mentioned 12:16.880 --> 12:25.760 SSH is a really popular tool that is used and if we implement a decision there it can benefit a lot 12:25.760 --> 12:33.680 of applications a quad difference I've seen in the implementation is that TLS can rely on the 12:33.680 --> 12:41.760 presence of X509 as far as I am informed so in TLS we can just use an existing data structure 12:41.760 --> 12:49.200 and embed a decision in there and as we have seen in OpenSSH I had to add X for steps in the protocol 12:49.200 --> 12:53.520 that it's a lot of back and forth between the involved parties 12:53.520 --> 13:05.520 Do they only find their clubs or okay the next steps is, okay thank you