Yes, hello, my name is Martin Lindere, I'll be talking a little bit about hardware back
SSH keys today, so we'll be taking a bit to look at how TPMs work, how SSH agent works
and my sort of hacks around those things.
My name is Martin Lindere and I said, my nickname is FoxPROM, I've been doing open-source software
development for almost a decade now, we're little over, and then after all per since 2016
and I'm also part of the board of HAKERIUM, which is also HAKERSpace.
When I don't do open-source stuff in my free time, I work at Norwegian State Broadcaster,
mostly doing sort of infrastructure DevOps stocks.
My main interest is usable security tooling, so I've also been writing a bunch of
security tooling as the CTL and some other TPM things.
So why do we care about hardware back to keys, why are these things important to us?
So the main thing we care about is key compromises.
The reason for that is that if RKs or our tokens are leaked, somebody else can impersonate
us, get access to our servers or something else, and this is not limited to SH keys,
it's going to happen to access tokens, cookies, anything that's on your hard drive, that
you're not protected.
And the way to demonstrate this actual problem, there's a board group page, reach last
year, where somebody got access to an SH key and managed to hack some servers based off
from private access to some CI systems.
You also had GitHub.com, there are say host keys leaked, which meant that you can impersonate
the github.com SH server, because that's how we trust them.
And sort of how do we usually go about protecting our keys or SH keys?
Well, we could be using ubiquies, which are cool need devices that probably a bunch of us
have, but my main issue with them is that you're expensive, a bunch of people, you need
to, that's only 100 euros, people think that's a lot of money for sort of hardware tokens.
So clearly we sort of can do better, like we have something in our machines that everybody
can use today to protect the keys, and they're called trusted platform modules.
So these things have sort of been widely distributed and used in machines for the past decade.
They are secure crypto processors, so they do key generation, they do sort of signing
at station, they come into variants, at the screen TPM, which is sort of a separate hardware
device on the motherboards, and then you have the firmware TPM, sort of FTPMs, which are implemented
as part of their CPU or your CPU secure the processor.
Intel has not SGX, but Intel and me, I think it's implemented, and we have the AMD trust
some stuff that implemented TPM as well.
TPMs give you a couple of features, you get platform integrity, which I'll show quickly,
and they also have hierarchies and keys, and you also get some at the station features
to make sure that you're talking with an authentic device, or you're able to sort of differentiate
between separate hardware devices.
The platform integrity comes most in the form of PC outlet registers, and each of these registers
has just one part of your operating system during boot, during runtime, and you can sort
of make keys and stuff, only open if these has just matches.
If you're curious about these numbers, and what do mean the API group has sort of a list
of all of the different registers, and what they hash during boot chain.
You can also do keys and key generation.
TPMs are sort of not that powerful devices, so we need the way to sort of make keys
out actually like storing them on the TPMs.
So what we have is three different hierarchies seeds in the TPM, which runs through a key derivation
function, and these allows us to make sort of a bunch of keys on a low-powered device
without really having to store them anywhere.
The hierarchies are as follows, you have no key, which is the session key, that's unique
per boot.
You add owner key, which is the owner hierarchy, which is unique for the device owner.
So anything you make under owner hierarchy, you reset it when the device can be
the owner, and all of the keys below that hierarchy is well used as.
You also have the endorsement hierarchy, which is for the lifetime device, which allows it
in the click chain, back to the device, back to some manufacturer, and you can make a
search on that.
So the shell keys are keys that we can make on TPM, we can then take them out of the TPM
to prevent it from storing them, and then they're securely packaged, and can only be
decrypted by the TPM itself.
The way this works with the TPM to token, is how to create some, this is the endorsement hierarchy,
we make a context, we create a new key, below this primary context, we load the key,
we can make some message, and then we can sign this message with our key,
and then we can verify this signature, that's sort of the basic things about it.
We also have TPM policies, which can restrict our usage with some with different TPM values
and system state.
This is now sort of being implemented in system D, called PCR Rock.
So yeah, TPM's store devices, not a little bit of a limited cryptography,
and that's the main thing, not quantum resistant yet, which is a little bit of an issue,
and they're not really that much of friendly tooling on built around them.
There are some not natively supported by OpenSSH.
So how do we make them supported by the state?
We do this through the SSH agent interface.
So the agent interface can hold a private keys for SSH, it has sort of a fairly simple, unique socket,
API you can use, it catches passwords, and you can offload key operations to the agent.
The way this works is that we make an SSH agent.
We add some ED251MN key, and we can list the key.
Further when we want to use this key, if we actually specify the public key instead of the private key,
in the configuration and the SSH command-line interface,
the SSH will actually go and fetch the key across to SSH agent instead of doing the key operations itself.
And you can also use that SSH around.
So this is agent.com, is implemented fairly well by Go library under CryptoSH agent.
It's part of the extended OpenSource library, Stang library for Go,
and sort of does all the things we need, it does key signatures, key listing, and can interact with all of these things.
So I start hacking on SSH TPM agent, one half years ago.
It's an agent that does TPM keys for the simple.
So yeah, it's supposed to teach key generation of RSA 248,
and then list mainly P256 and P358 keys.
You can also do things that are important existing OpenSource H keys,
dealing them to TPM, and this is using the Google Gold Library called Go TPM,
which is a native implementation, it doesn't rely on the existing C libraries for the TPM.
So the way the agent works is that we specify some socket location,
then we start the agent.
We can then do the normal SSH TPM key, Kegan Tendration,
because mirroring the existing usability of SSH is practical.
If you want to help people use it, instead of reinventing something new.
And then we can then add the key to our agent.
We then export the SSH audit socket to our agent,
then we just list it as usual.
So it just interacts with SSH as you would expect.
We can also make an SSH key by default from normal OpenSource H,
and then you can use the dash dash import one to sort of take existing key
and see it to our TPM, which allows our machine to be on the one that unlocks the blob.
So, right.
So, the way this works is that we can run the SSH TPM agent.
We then do a key Kegan of some EDD cell key.
We don't give a password because we don't care that much about it.
And then we have a new key, which is here.
So, this is sort of a secure blob.
You can't really do anything with it.
And then we can sign and then we need to load it into our agent.
And then the SSH command line in the face is going to detect that key.
And then if we sign it,
that's why it's signed.
We can write a signature with the normal SSH key again, that's why.
And it's going to use the TPM backed key instead.
And then if you do it a no check validate thing,
it's going to say it's a good signature.
You can also, so the key generation here is sort of gives you key as unique.
But you can also make keys from that different hierarchies.
So, here we can reload the assigning key from only hierarchy.
And then when we call back on the SSH,
we get the hard code on the hierarchy keys.
The cool thing here is that this is a unique per device in this case.
So, if even if you do a complete reinstall, under the same command,
you'll get those keys back.
Yes, and this is actually called for like host keys,
because when you come extract them from the device,
you come like take them away, use manual device,
and then make people impersonate.
You have to have live access to the device and sort of some of around things.
We're going to also do remote key wrapping.
So, imagine you are some company that has SSH keys,
and you want to provision them to your client machines.
On the client, we can make, and that's okay,
which is one of the hierarchy keys.
We can then, on the remote side,
we can make us a self-on-new key, an ECDSH key.
We can then wrap this key from our client machines
with the key we just generated.
On the client, we can import that key,
and this only that client that can actually use that key.
And that's useful if you want to do remote provisioning.
Yes, it also has host keys worked.
So, here we do the dash A, which does the normal SSH host key,
key generation that you expect.
I then have a shortcut to install some system D service files,
and then make in them do SSH-D configuration file.
If we then start to socket,
and then restart SSH-D,
we then have a small binary that lists out the keys we need,
or curious about, and if we do a key scan,
we have the key delivered from the SSH client.
And this is useful because then you come to an export key,
or you come to an impersonation of the device itself.
Yes.
We also have some other sort of cool features,
so we have, yes.
So, MC presented the utility key,
which I have a unit of here.
So, let's imagine we have a utility key here,
and then we start another SD agent.
So, one of the sort of the main things is
if you have multiple different agents with different keys,
you need to sort of juggle around socket files.
So, I have a proxy support in the agent,
so we can give RTPM agent access to the utility key,
and socket, and then we need to dash L.
It's going to load up to the utility key,
and then,
new,
exciting.
No.
Rolling center app.
Slow.
Ah, there we go.
And then we have the T key,
and if we do now model key,
and we add it to the agent we have,
you're now going to see that both shows you the TPM agent key,
and the utility key itself,
and you can sort of use this one socket,
an agent sort of a proxy to different agents,
instead of sort of juggling sockets.
Well,
all of this is made possible with sort of the TPM 2.0 keys key file,
key file spec,
it's written by James Potomly,
currently not standardized,
but it's sort of an ASN1 specification
for how to sort of deal with TPM keys.
So, I did a bunch of work on this,
or a bunch of work,
that I implemented this in though,
and it has several support cases,
so the linear steering supports it,
and the OpenSalt TPM project supports it,
and it's basically an ASN1 format for TPM keys.
It's supports loadable,
importable, seal keys,
and you can sort of do different things with TPM keys.
So, I wrote library for that,
so you can use it in your go stuff,
if you do go,
and then it interacts with OpenSalt,
so you can do the TPM 2 provided from OpenSalt,
do some key that you want to create,
and then TPM key again is going to understand that key,
which is quite useful.
So, one of the interesting parts stories isn't secure.
So, let's see,
I had problems with the internet today,
so we'll see if this actually works.
So, this is my gift up account.
I'm going to prove to,
if I have, again, there's no agents.
So, I'm going to set into my gift up accounts,
and I should deny that,
permission to deny it, awesome.
So, don't create a new TPM key.
What's a secure password?
One, two, three, four.
And we do this again.
One, two, three, four.
Awesome.
We have now made a key.
So, we're going to do the TPM key.
We're going to do a new key.
And this is the part where I should have found my...
I should have put it in my pocket, but I didn't.
Ooh.
This is a cure. I promise you.
Use a cure key.
Push the key.
There, it's added.
So, now we do TPM add of the TPM key.
We SSH to get.com.
Oops.
And you work?
One, two, three, four.
It works.
We have access to my gift up account.
And if anybody's curious,
that's the key.
I'll give you three, four seconds to type it out
or copy it or something.
Is there?
And if you're curious, I've done this before.
It's a key from August 1st, 24th.
Here's the QR code.
That's a password.
It's still there.
It hasn't been accessed for half a year.
And I've done this three times.
So, this works.
Or it works.
It's approval secure in some way.
Maybe.
Some improvements.
I would like to do some more TPM policy stuff.
It's a bit, if you don't TPM policy,
it's a bit finicky with how PCR locks and stuff works.
So, I want to do some integration to our system DPCR lock.
I want that unlock support because I want the sandbox,
some of the parsing system stuff we do.
That turns out it's a bit hard when you call external binaries.
I was also supposed to do a 1.0.0.0 release before this talk.
But I got to start playing games instead.
So, that was for planning on my end.
And if anybody thinks this is interesting,
it has some feature requests.
Feel free to give me a future request.
I also don't talk at all systems ago.
So, if you think TPM's are cool,
but you also care about the station,
or having some from certificate or authority things.
I talked about that part in September.
Which is basically sort of how do you provision shortly,
as I say certificate, bound to the TPM.
So, that was my talk.
Thank you very much for having me.
And probably time for some questions.
Thank you.
Several minutes for questions.
Cool.
Perfect.
Can you just limit the accessibility of the Japanese somehow,
to a content of set up?
I really do a specific content.
I am excited about that.
I don't know.
I think there is a TPM resource manager,
which should make some of the TPMs up invisible for some processes.
So, it's a hot reloads TPM state,
but I'm not quite sure how that works.
Some bit unsure.
So, the TPM doesn't really store keys.
It has three seeds.
And then does hierarchy,
key iteration function instead.
So, you can make as many keys as you want.
The actual question, though, is how many keys can you load at the same time?
And when I did the whole, the hierarchy's key stuff,
I loaded the RCA key and the ECD's key at the same time.
Turns out the TPM doesn't really like that,
because it has limited memory and starts giving me weird errors.
So, I need to figure out that part out.
So, we can make as many keys as you want.
And the second you sort of rotate one of the seeds.
Those keys are unusable by the TPM or your machine.
Yes?
Yeah.
When you say the TPM has the limit,
it's a super, super small and low power device.
So, you can't really store everything.
So, what you do instead is that you can just load a couple of keys.
But everything you load, you can encrypt it on TPM,
and then take it out and only that TPM,
but the seeds can be encrypted.
Yeah.
And if that's some sort of, I forget how it's,
but it's some AS encryption with some key iteration stuff.
So, if you manage to break it,
a bunch of other things to broken.
But it's sort of a protection of the secret key material,
which with secret stuff being derived from the hierarchy stuff.
I just bit.
Yeah.
No, no.
It's only unsealable by the TPM.
But if you manage to break the cryptography that TPM used to seal it,
then it's fine.
Yeah.
Where is it?
Before you said that to you,
you might confuse it.
Yeah.
And when the same moment,
you could be the same.
Yeah.
So, someone stole my laptop.
In theory, they can do that.
So, if you do, like, sell off your laptop,
you should, like, rotate TPM hierarchies seeds.
And then they can, at maybe recover some of the,
like, the state, the stateful keys,
like the whole piece from the endorsement stuff.
So, you just don't want to risk,
rotate the seeds when you give away your laptop.
Good recommendation.
I decided to write, like, stand along by the way,
instead of developing, for example,
because they sell library for a TPMs,
and instead of working.
So, probably, TPMs 11 is a bad idea.
Externally loading so names into your secure sort of process,
not great.
As they have just had secure dishes,
because of that.
So, doing an agent or a simple interface,
which agent is better idea than loading external code,
and then sort of using those interface functions.
So, because if you want to use PKS-S11,
that's a bunch of things already supporting it,
but the tool chain is terrible.
So, you have to do, like, 20,
no 10 commands, I think, to make one key,
instead of SSH TPM key again.
So, it's, it's, it's a bit more usable approach.
Yeah.
Is your host case stuff using the owner case, or is that?
You can decide.
Okay.
The default is that it creates something you have to load,
but the hierarchy key stuff needs to be,
a bit better integrated to properly work with host keys.
But in theory, it's, you can, you can choose yourself.
Make some keys, or do the hierarchy key instead.
Yes?
Can you come close to me now?
I assume, uh,
if I just crash the end of one row,
so there is,
so there is somebody in Sweden using this,
extensively at work, or something,
and if they do 100 signatures,
one of those signatures to fail with a very weird error.
I'm not quite sure why,
and I haven't managed to reproduce it,
even though I tried to do 1000 signatures,
I can't really reproduce it up lightly.
So, that might be a kernel issue,
because I've seen some of the meta people having issues,
some of the transient issues with the TPM,
some of the kernel,
but it also might be the goal I'm really doing,
something we are just,
but I'm having to really manage to figure out part-out.
I don't think there's more questions?
Yeah, I think the time is up as well.
Yeah, thank you.
Thank you.