SSH authentication using user and machine identities – Morten Linderud

Um, my name is Martin Lindu. I go by Nick Moaron on the internet. I have been doing open source software development for around 10 years now. I've been an Arch Linux developer since 2016 where I've been doing uh packaging uh been part of security team, reproducible builds and maintaining different projects. I care a lot about usable security tooling. So I've been doing sort of projects around secure boot uh UFI and now lately a bunch of TPM projects. I'm also board member of Haka uh who's heavily present today uh helping to run the hardware uh hacking village. Uh when I don't do a lot of open source uh stuff I work DevOps at uh an arcade u working on things like the

elections and uh sort of the visual storytelling stuff. Um but first let's go back to the basics. So we should make an SSH key. Um so when we do uh SSH we preferly would make a key. Uh we'll call this ED251 9. Uh do we want a passphrase? Yes. Let's use 1 2 3 4 1 2 3 4. And now we have made this uh SSH key uh and we want to use this to to uh authenticate. Um, so what we do is that we copy this to our server, which is very important because you can tell because it says important in the in the domain. Uh, and then we type in the root password.

Um, and next time we try to connect to this uh, SSH uh, service uh, we can do uh, we type in password and we get access to our service. Uh so the cool thing about this is that they now have access to a root key which SH key instead of using the password. Uh and the reason why we can't uh uh while user can't see the key uh is because cd25519 is it because of the uh permission of the key or I accidentally leaked the entire key. Uh so if you now failed to access the server my key is exposed. Uh this is what we usually call uh key compromises or key extractions. Uh the

server is now uh you can now copy key get access to service and it's not connected to the uh service it. It's not you can connect to this SSH service and prefer to have uh by way of preventing these things. Um so this is not limited to SSH keys. Uh this can also be done to like things like cookies, access tokens and things that are not directly connected to your hardware or your identity but can be abused without you uh having access to to the key. It can be used for privilege escalation, impersonation or you can do things like compromising uh GitHub repositories if you just have access to the key. SH keys are trivially uh brute forceable if you

know the password. Uh and that's sort of the thing you want to prevent. This is uh isn't really a theoretical thing. Uh you have a fairly recent case now where of an AP I think that got access to a vulnerable Jenkins server. They extracted SSH key from Jenkins and then use that to uh compromise the GitHub repositories of the organization. Um which is bad. We should try and prevent that. It should be more strongly tied to something uh that would prevent you from uh taking the key away. You also have GitHub and that leaked their RSA host key by accident which would allow you to do uh some form of uh SSH uh man in the middle attacks or

intercept the connection.

So what we would preferably have is somewhere to have device bound keys. uh this would prevent this would prevent uh people from taking our keys and you use them without having access to your machines. We'd like to strongly tie this to some identity claims like your Microsoft identity at work or your octa accounts or some other uh provider. We would also like to try and make sure that SSH keys are strongly tied to the machine you're using them on. that would help you prevent um things like it would it would ensure that you also have access to the correct device and for enterprise setting you would have to also be from device that is enrolled MDM

or some device that your company has control over and all of these sort of things together would prevent you from would actually like allow you to sort of have more trust in SSH keys or other credentials uh that we would like to uh secure So one of the cool things that is sort of ubiquitous these days is trusted platform module or TPM. You can use uh UB keys to sort of secure them better. But TPMs are very much sort of standard hardware on most machines today. Um they are sort of secure crypto processors. Uh they do things like check the boot integrity and do platform at the station. That will take a little bit look. uh they're usually implemented as

some form of uh separate hardware, some sort of module that you connect to your motherboard, but they can also be sort of uh implemented as part of your uh CPU firmware. I think Intel used SGX but now it's in some other thing and the AMD securing and cloud thing. Uh it supports platform integrity which allows you to have some reassurances in how you boot and which state your computer is in. we have for uh way to do uh keys and hierarchies uh which we take a look at and then at the station which is strongly tied to the machine identity part that we'll look at uh afterwards. So the way the platform integrity thing works is that you have these uh platform

uh configuration registers uh they are 24 of them and they are some part of the uh boot chain which is hashed and stored as part of TPM. uh these do a lot of things. Uh 1 to 7 is usually the platform registers a part of your boot chain and the rest of them is sort of the application or the runtime part of it. Uh for the Linux part of this there's the API group specification that sort of details which register is used what and you can use this to create either policies or lock keys uh towards TPM. Uh we also have the concept of hierarchies and seeds. So TPMs are sort of not great computers. What they do is

that they have hardcoded seeds and other seeds that you do uh can create key set of through a key derivative function. And you have three seeds by default. An endorsement seed is the ones that sort of burned into TPM and this is for the lifetime of the device. The uh owner uh hierarchy or owner seed is for the lifetime of the owner that has it that can be rotated. And then you have the null seed which is basically for the uh the lifetime of the you boot the machine the seed gets seated and you can sort of do a temporary credentials under that seed. uh the endorsement seed is chained back to the manufacturer which means

that you can get a certificate and you can verify it's an authentic TPM uh because it was signed by the manufacturer and you can also do shielded keys like uh create some key extracted out of the TPM and it will be uh secure. So the way this works uh because it has a terrible API is that you say which hierarchy you want. Uh so this is the endorsement hierarchy which produces a context. We can make a key out of that uh which in this case is an RSA key. We have then the public part which is the public uh cryptography uh part of it like the public exponents and stuff. And then we have the private part which is a

sealed blob to the TPM. What that allows us to do is to take the uh load this public and the private part uh which can be uh carried outside of the TPM back into the TPM again. Uh and in this case gives us a new context. We can use that to create some form of u data which we can then sign uh with some uh with some message and use to verify signature. Um

so TPMs also support policies. That means that you can sort of explain to the TPM uh what system state you have to use it on or what user or admin can be able to do uh do some operations with the key which allow you to sort of only have these keys usable if your system is in a given state. Uh they also support sign policy so you can rotate them and stuff but that's little bit beside what we're going to do today. The main problems with TPMs these days though is that they're sort of slow. They are not HMS uh HSM or hardware secured modules. Uh they are fairly slow. You can most sort of discrete TPMs

do like seven or eight signatures a second which is sort of usable not super usable for anything that requires uh a lot of um activity. It's still has limited cryptography. So most uh most of them these days only have RSA 2048 and then the NIST uh P256 and 384 curves. And it only really supports a SHA 256 and a SHA 384 uh hashing algorithms. That means this these things are not super secure for like quantum cryptography and stuff. And I think there's starting to be a bit on the low end of the bit size uh with the new um new sort of the new bit demands that this is looking at. Uh also the things

that we need to do is that we need to have some way some more user friendly tooling but sort of the commands I already showed you terrible and I don't remember that off hand and neither should you. And the other issue though is that uh it's not really supported by open SSH because open SSH doesn't really like TPMs that much. Um but there are still other ways of using it uh with SSH. Uh and that's the SSH agent. Uh the SSH agent is some demon that allows us to uh hold private keys for SSH. It communicates over unique socket uh and it uh helps you to do things like caching the password, caching the pin.

You can als you can also use it to offload key operations. Uh so the cool thing with uh SSH is that if you uh do an SSH agent, you create some key uh to the agent and then we list it. So it means that the agent is aware of the key. Uh what we can what we usually do in SSH is that we refer to a private key. But when we have the agent, we only need to refer to the public part of the key. uh that can either be done as part of the SSH configuration uh or part of the SSH uh command line instead. Um and that what that allows us to do uh

is to effectively implement some agent that does the TPM key operations for us and only use the public part to identify the key. Um implementing an SSH agent is fairly trivial at least in Go. uh it implements sort of a full SSH agent client inter uh agent client interface along with an SSH server and makes it easy for us to sort of interact with SSH as a whole. So that's what I did. I wrote an SSHTPM agent uh which allows us to do uh TPM keys. Uh it supports the key creation of the most of the algorithms that uh SSHTPM does. Um it also supports some of the open SSH key uh formats uh and it uses

the Google go TPM uh libraries to do the TPM interactions themselves. Um so the way this works is that we have some authentication socket. We have the SSH agent. We can then make some TPM key uh which uses the same interfaceish as the open SSH uh stuff. We can then uh create uh or add the new TPM key to the agent and the standard SSH uh tooling is going to be aware of the key. We can also make an normal SSH key as long as it's one of the supported algorithms. Uh and then we can also import it into the SSH TPM agent. So we can sort of rewrap uh the existing key into the TPM.

Uh so this is cool. Um it also has some other support keys uh some other supported features features like some proxy support and some host key support which allows you to sort of combine multiple agents into one front end or have your SSH host keys uh as part of uh the TPM. But the main question though is it secure? Uh so I've already leaked my um uh already leaked my uh key once. So let's do it again. Um so what I'm going to do now is I'm going to do going to create a new uh new key in the DPM. Uh the pin is 1 2 3 4 uh 1 2 3 4. Uh and now we have the

key. What I'm going to do now is I'm going to go on my GitHub. We're going to go and add this key to my account. That's the wrong thing.

We're going to call this Pads uh Oslo. We're going to look at the public part of this key. We can take that, add it to our GitHub, and to prove it works.

So now we have added the key to the agent and we're going to prove it works by authenticating with github.com. That should work.

And we have authenticated GitHub. Uh if you're interested in the key, that's the key. Uh so if you try and take a print screen of this or try using it, uh you won't be able to. Uh and if you want the QR code for it, What's it uh cutm your end code? Okay, I forgot the command line because I didn't prepare it. Um but here's another SSH key that I've uploaded to my GitHub as well with the password 1 2 3 4 and that's the QR code of the pin. Uh so you can try hackme or my GitHub if you really feel like it. And this sort of solves the uh SSH key problem we already have. I've

given you my key. You're probably not going to be able to use it. Uh which is a huge improvement over what we already have been doing. Um the way this works is through a spec called the TPM 2.0 key file spec or that's how we serialize the keys. It's an AS1 format for storing the TPM keys and it also has several providers. So, OpenSL has a TPM2 provider uh and the Linux key Linux kernel also support these keys as well. And that allows us to use some sort of common format for all of these TPM keys which allows us of or make keys somewhere else insert them into our agent and so on. It supports

loadable importable and sealed keys. And because there was no good uh framework for this in Go, I wrote one myself uh which is located here and it allows us to sort of easily create uh TPM keys. So if you use Go, you want the TPM key, we can just define a new loadable key. We can give it a description. Uh we can say it's an elliptic curve key with uh some 256 uh bytes of security. Uh we can write out the bytes of this uh key into a file. And if you want to sign things uh we can just use the standard crypto uh signer API in go and it just well it just works which is quite nice.

You can also u make keys yourself through the go TPM uh API. So the uh template is how the TPM knows what object it should create. We can create loaded object which is how the TPM loads objects and then we can sort of serialize our own uh key with a description and the public and private part of the key. And we can write this out uh onto a new key file. Um and this is sort of uh this nice. This solves the key problem but it needs some way to distribute this key. Remember we're making a CA. We want to have some way of distributing these keys and SSH has this certificate um SSH sort of

the certificate uh key types um and they allow us to do uh ties have some central authority that can sign certific certificates that we can use instead. It can be tied to some user it can be tied to some capabilities of SSH like if you want the real terminal or not. And you can also do cool thing which is uh giving um a time age to the keys. So you can say it's only valid for 5 days, one week or just 5 minutes if you really want to do that. What this allows us to do is not only have keys that are non-extractable but also help us have keys that are shortlived um which helps

sort of uh lessen the compromises of it. Uh so another go example uh we define some time range right now and then add five minutes to it. Uh we can make a new SSH key and then we can do um SSH uh certificate. Um so we say it's a user search. We give it key ID which is the TPM uh which says valid after valid before which is sort of the time range it should be valid and we can give it a set of permissions that's sort of the standard ones. uh you can do agent forwarding, you can do the port forwarding, you can get the real terminal and then it can also load the

RC file of the user. Um this is signed and then the user can use this to authenticate with the server. Uh and the way that SSH uh trust the CA uh is through this trusted user CA key SSH uh directive. Yes.

So now we have sort of uh solved the yeah so now we have uh device bound keys and we have some way of distributing them through the co authority. Uh now we want sort of want to have identity claims. Uh identity claims are um something that we trust. It can either be sort of your Microsoft um Microsoft authentication portal. It can be signed by Microsoft and then you can go validate that these uh attributes uh to your login is actually from Microsoft itself. uh it's this is user uh implemented through something called open id connect um and it's sort of standardized across multiple vendors and allows us to sort of do these things identity provider is called an IDP uh

and they sort of uh are signed from provider itself open ID connect is u based on something called JVT or uh JSON web tokens um they can be valid remotely which means that we can have a token trade around get the public keys from our provider and um sort of check that they have been signed itself. Uh the way these things work is that we have an algorithm that says how it's uh signed. Uh this part is protected by a signature uh which has uh several claims from our uh identity provider. In this case, we have the email and we have that email has been verified. Um and then this entire thing is uh protected by an

RSA uh signature. Um, so the identity providers themselves, uh, there's a bunch of them. You have Octa, which you can use, uh, Keyclos for self-hosting. Microsoft, uh, Enra, I think that a lot of people probably use in their data J, uh, work. And then you also have Google through their sort of their portal and all of these things that are usable uh, for users. You can sort of make people log in and you can get back uh, some different claims. Uh personally I'm interested in GitHub but GitHub doesn't actually have um open ID connect uh towards users so you can't use them. Um so I had to sort of try and work around that. Um and to sort of figure out how these

providers are configured uh we have this sort of endpoint well-known open ID configuration which lists a bunch of sort of the setup for open ID connect. So this is the one from Microsoft online and you see that they support a bunch of different claims. Uh most of these are connected to their ashure stuff I think. Uh but they still have sort of uh a bunch of sort of different claims you can authenticate and verify they actually work. Uh the one thing we are interested in though is maybe the ACR uh value uh because that's the value that says tells you if you are actually using two-actor authentication or not. um because just using uh sort of

username passwords that's not super useful for us. We want to have some way of actually verifying identity. So we want strong identity claims. The way people usually do this these days is two factor authentication and we want to know from the uh IDP if we actually have a user that's authenticated with two-factor authentication. Uh this is done with the ACR claim uh in the open ID connect spec. The issue though is that it's it's there but it's not really standard standardized. So the values or sort of the two factor authentication claims from the IDB itself uh we don't really know what it means. It's all vendor specific and the only two sort of semi-standardized values are silver and

bronze which I don't really know what that entails. Uh but that means sort of that figuring out if somebody has is actually using two factor authentication isn't easy. Uh Google refuses to tell you this because they don't want want vendor lock in. uh they would prefer that you don't know. Microsoft gives you some of these values, but I couldn't figure out what the values were. Um so I needed another way of sort of supporting IDP providers without having to sort of hardcode a bunch of uh identity providers and figure figuring out how they work. So SIG store is a Linux Foundation project. Uh it's mostly used for keyless signing uh which we don't really care about in this context.

Uh but what they do have is that they have a public for good um federated IDP which is hosted by Linux Foundation. Uh it does identity providers for us. So we can do Microsoft, Google, GitHub uh through a single identity provider and as long as we decide that we trust uh Sigur uh then this probably works for us. uh and this sort of a what should I say quick hack uh to get this working instead of sort of hard coding uh all of the different providers. Um so the next issue though is how do we know that the authentication that we want want is actually from the uh uh CA. So we want the certific

claim but we don't want any claim. we want the claim or we want identity the login that's uh that the CA has requested or not because if we have no way of verifying it then somebody can just man some login through an IDP provider uh and then they can just send it to us and we'll just blindly trust it. So we need some way of uh figuring out how uh if this actually belongs to us. So I spent the day looking at this uh list of values that we can control and sort of how we figure how we can sort of use this to insert some thing that we can check for and after staring

at it for a bit too long I realized that the nons is client provided. Uh so that's supposed to be make sure that we don't sort of reuse the authentication scheme but that also means that we can insert whatever value we want. Uh so I decided that we just the CA can make a random string insert it into the nons and we can just check for it instead of uh uh doing another dance with it. Um so the issue then so the goal then is that the RCA is going to give it give our client some value. this value has to be present in the sign in of the service we have and then it's signed and that

probably gives us a claim that uh this the identity provider has signed a notification request from us at some point. So we now have uh device bound keys we have identity claims or some way of at least ensuring that we have identity claims. Uh the next step though is that we want to make sure that the device is the one that we are using. uh you want like I said you probably want some device that's uh from your enterprise or some from your organization. So you need some way to prove uh that this machine is from us. So machine identities um it's when people sort of work from home and stuff we don't have a lot of

control. Uh some people uh log in to their internal services from their home machine because it's practical instead of carrying a work machine uh everywhere. But if you have a lot of access like on SSH, you preferably would not want that. You want it from machine that you know is good that you control uh from the enterprise. Um so the endorsement keys from TPMS uh is sort of the hardcoded one for lifetime of the machine. Uh it can't sign things. Uh so the TPM people decided that we need something more complicated instead called credential protection. And we have at the station keys. In theory, this should prevent uh should give us some form of anonymization. So that if you want the

identity of machine uh you can do that without actually disclosing which machine it is which is a bit interesting but we don't care about that. So we're just going to do uh do credential protection with endorsement themsel and the way the TPM works with this is that you have something called c uh certify and that's session keys. So certify allows us to verify or sign that an object was created on the TPM. uh TPMS have some strings that we refuse to sign and that allows us to uh ensure that sort of a key was created on this TPM and that the TPM has actually signed this. Uh we have a bunch of um attributes that says that the uh TPM key

can't be uh exported out of the TPM itself and then we can sign all of this and because of that session key we can chain this back to the endorsement key itself. Um so the way this sort of challenge work uh is that the credential protection pro uh proves possession of some machine resident key is a shared secret is encrypted uh and we can do these downs on remotely send it to the TPM and then TPM can uh unlock it. Uh and what that proves is that the TPM we send encrypted credential to uh is from a key that's uh on the TPM itself. Um so credential activate uh is the thing that we have to uh run on the

local own TPM and make credential is sort of the encryption operation itself. Uh it's not unique to TPM. We can do this remotely with just uh public information from the TPM. Uh and then we can send it back. Um so the way we prove position is that we use make credential on the CA. We have the endorsement key. we have some atession key and we have some thing that we want to decrypt. Uh we send this blob to the client or the agent themsself. Uh the client is going to decrypt that blob. Uh it's going to send this blob or the secret string or whatever we wanted to decrypt back to the CA and that uh

helps us to prove possession of the machine that we're actually using. Uh so that means that we have devicebound keys, we have identity claims, uh and we have some way to do machine identity. Um yes, so the SSH agent is going to do the TPM key operations for us. Uh we have uh we have a way to process identity and the machine. So this leads sort of to the thing I've been hacking on since summer, which is SSH TPMCI authority. Uh so let's see if this demo actually works. So what we're now going to do is that we're going to run the CA authority. Um and this is uh effectively uh the CA. It runs locally in this case because

it's easy. Uh and I'm first going to uh SSH into my NAS server at home. This should fail. Doesn't fail. Okay. Uh we're going to try a Sage. And now we get the password prompt uh to the client uh up there just with ECBC. Uh and what I'm going to do now is I'm going to run the authority. Um yes, that one's going away. And then I'm going to SSH into my NAS. This NAS is then going to open the SIG store identity provider. I'm going to click login on GitHub. And then we authenticated uh it's going to issue a shortlive certificate and it's going to SSH into my uh server. Uh and if you look at the output of the SSH

agent, we see that this has provisioned an uh elliptic curve DSA key and the certificate as well. Yes. So what this is effectively is that the certificates these provisions are shortlived. They last for five minutes and then we need another one. Uh we have done some way of identity authentication through an open ID connect rider and behind the scenes we've also done the machine identity parts of it. Uh which is the credential protections. The also cool part about about this is that we haven't um actually uh reimplemented either the server or the client. we're just hooking into the agent and then uh using that instead. Other solutions like the teleport uh client server stuff involves that you have to sort of do

full buying of the SSH server and the client which is probably a hard sell on a lot of enterprises or you yourself if you want to use this. Um and this sort of is just a cool little hack. Uh so the way this works um is that we do some we make a key which is supposed to be the uh CA key. Uh we set up a configuration uh which says which SSH host that we want. Uh we give it the C file that's is supposed to sign the request we want and then we just give it uh a list of users that have access to the server. Uh so in this case this is my user. Uh I've

decided that I wanted to use GitHub. uh email uh is the one that I should preferably be logging into when I use this tool and EK is the endorsement hard-coded endorsement key which is part of my machine and sort of the thing I have to use to uh do the machine identification.

Yes. Um so to getting the e uh the endorsement key uh from the machine I didn't get to figure out a better way to do it. So I wrote my own little tool. Uh and this is sort of the hash of the public part of the uh of the endorsement key and that's sort of to make sure that we have it enrolled before we use this because it's hard to sort of establish uh this key after the fact. So this is preferably done as part of sort of enrollment uh procedure. So you at some enterprise getting the Northman key and before handing it off to the user. Um and that sort of is the way that prove

that machine is uh ours. Uh running the SSH uh the CI server uh currently just does sort of the local host thing all standard and the client setup is sort of the interesting part uh because this is part of the uh SSH configuration to client. So SSH supports something called match host XC and that means that if you match on some host it's going to run a secondary command. In our case, we have our special SSH CPM ad command uh which just uh communicates with a CA uh with our host and our username and that's sort of what's uh fetching the certificate from the CA server into our agent before authentication starts.

So that the station protocol itself um is what should I say uh hu uh not huge but a bit complicated. So I did a blog post explaining this uh a few months ago when I originally wrote this talk. Uh but I'll try and explain it here as well. Uh hopefully some people find it interesting. So the server has two endpoints. Uh one called a test and one called submit. A test is one that we use to initialize the authentication towards CA. uh we don't know what the CA has but we have to provide our uh username which host we're using and the endorsement key and then submit this the sort of two challenges that we need to do through

our identity provider and the credential protection. Um so we do creation of two keys which is at key called the AK and the TPM TPM bound key which is the uh key on the machine that we're supposed to be using. uh we submit this authoration. The open ID issue challenge is effectively the CA verifying that the identity provider has given you a valid credentials. Um we decrypt the credential on the client and then we submit all of this and back in it provides a signed a safe certificate that we uh throw into our agent. So the way this works is uh the bank key we do the TPMT create command which gives us back that station keys.

Certified creation is the one that we do to sort of make sure that the key itself is uh part of the TPM. So this is the agent communicating with the TPM. We do the same dance again uh for the TPM bound key uh which is the agent communicating with the TPM. We do a creation and then we certify the creation that's going to give us that station of the keys. Um the at station itself uh is that where we we give all of our uh SSH host that's SSH username and the uh the keys that we created. The CA authority is going to do some pre-validation of all of these things ensure that it exists in

our configuration. ensure that we have these things well designed and we're then going to create two secret values uh which is then done with the credential protection and the nons which is then used by the open ID uh uh connect uh issue and we send this effectively back. So we the client doesn't know which uh open ID connect um server it uses and it uh doesn't know the anything in front of the request itself. uh this is represented as some go structures which is translated to JSON. Um so you have that stationation parameters which is the host the user and the station information. Uh all of this is sort of just flat JSON uh with

some B64 encoded strings and back we get the interesting part which is the credential link crypto blob. Uh we get the secret which is the uh public part of the share secret that we do which is some part of some elliptic curve defy helman challenge itself. Open ID YDC is the issue that we're supposed to use be communicating with and the nons is part of the open ID connect uh challenge itself. Um open ID issuer challenge uh that's the agent connecting to the open ID connect issuer. Uh so we do the login flow with the nons that we set ourself and we get the JVT proof back which is signed by the open connect uh service or provider.

uh the agent is going to chat with the TPM and get the credential decrypted and because we use the public part of the endorsement key and the station key. Uh this can only be encrypted if we also have the private part of the endorsement key back is going to be the credential which is the random string uh we have to send back which proves that the uh machine is authentic to the CA. And when we submit this to the CA authority, uh we sort of send back all this information and the CA authority is going to check that everything is valid. It's going to take the open ID connect JVT proof check with open ID issue if

it's actually signed. It's then going to check that it's all has all of the correct configuration that we want and then uh ensure that the decryptered credential from the client is the same as the one we tried to send. Uh it will then take the public part of DPM, synthesize SSH key and then send this back to the agent. itself which is what allows us to uh sign this thing. So the challenge response here um is the which we send from the client to the CA before we get signed SSH certificate back is a secret which is the uh decrypted blob and the JVT string which is the proof from our uh open connect provider and back we get the signed

certificate which is the byte string that we'll uh throw into our agent. uh and the and the result of all of that is that we get two keys. One is the pu uh private uh ECDSA key which is part of the TPM agent and then the certificate which is part of the uh or the certificate that we use to validate uh the uh the of uh the connection itself. So um improvements is the protocol good enough? I don't know. I am sort of an open source hacker dude. I'm not as like a proper security engineer. So I have no clue if this uh protocol is good but it works and it gives us some stronger

claims on our uh SSH keys. Uh we should probably do some more pinning of the uh platform keys. We can chain the entire endorsement key back up to the manufacturer including the serial number of your machine. I need to figure out how that works. I know Teleport uh does part of this as part of it their enrollment procedure. Um and SSH is a bit lacking. Uh so when this when you get like a signature request from SSH, the agent doesn't actually know uh which server it's signing something for. We only get uh uh we only get this blob. Please sign this with this key and we don't know any metadata around the server. It would be

per it would be preferably better if we could have some way of like a signed statement from the host keys saying this is our metadata please sign this because it would be easier for us to reason about what we are actually uh actually want to sign in context. Um there's also uh sort of an entire sort of extension thing with SSH agents uh which we can only control if we actually reimplement the SSH client itself and it would preferably be a good idea uh for the SSH agent either to be able to offload this to another agent or something else. So there sort of bunch of issues with open SSH as well. Um so yeah uh to now shown how we can

sort of do TPM bound keys with the SSH we have written some CA authority that is able to take machine identities and then uh identity claims and machine identity claims and so hand out shortlived SSH certificates and we can use this as part of our authentication scheme uh towards our SSH servers. Uh all of the source code is public. Uh it's on the GitHub. Um and it's uh there if people want to take a look at it. I probably say it's like more of a point of concept than the uh finished thing. But the TPM engine itself is used by multiple people in this room I think maybe. Uh so that's uh something you can

look at if you find interesting. If you have questions, uh, I've have a blog, I have an email, I have a master account if anyone wants to look up that and my GitHub is Fox as well. Thank you. >> Thank you very much.