[HN Gopher] Show HN: ssh-tpm-agent - SSH agent for TPMs
___________________________________________________________________
Show HN: ssh-tpm-agent - SSH agent for TPMs
Author : Foxboron
Score : 71 points
Date : 2023-07-29 13:28 UTC (9 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| lathiat wrote:
| This is a great idea. I now exclusively use SSH keys on hardware
| security modules of some kind. I use "Secretive", a mac app that
| does the same, plus a yubikey using yubikey-agent
| (https://github.com/FiloSottile/yubikey-agent; there are too many
| complicated ways to use SSH keys with a yubikey this is one of
| the friendliest ones). Depending on the security and frequency of
| which I access the service impacts whether I need presence
| confirmation or use secretive versus the yubikey.
|
| I would be remiss to mention there are existing SSH TPM projects,
| not sure how this one differentiates. It seems to at least have
| the user experience pretty simple, similar to yubikey-agent (and
| secretive), and unlike some of the existing solutions which have
| quite a few extra steps:
| https://github.com/tpm2-software/tpm2-pkcs11/blob/master/doc...
|
| I really love it when projects like this address there are
| "competitors" or other software in the space and provide a fair
| comparison. It would be great to see one of those here :) For
| example you can easily use SSH FIDO keys but they aren't
| supported by all server sides, ECDSA keys often are (though not
| always!) etc :)
| linsomniac wrote:
| The ; got included in the yubikey-agent URL:
| https://github.com/FiloSottile/yubikey-agent
|
| Thanks for those pointers!
| Foxboron wrote:
| It's not written in the README.md, but `ssh-tpm-agent` is
| very much a copy-paste of `yubikey-agent` but with a bit
| better testing and the yubikey part swapped with TPM stuff.
| osy wrote:
| What's the threat model of TPM? They claim it's for "physical
| attacks" but they can only enforce it when there is no software
| vulnerability or unauthorized privileged access anywhere so it's
| a very small area of the Venn diagram where you have an attacker
| whose capability is "physical access" but also "does not possess
| any exploit or one-touch-access". This narrows down the list to:
|
| * Malicious coworkers, family members, and house keepers against
| a computer who is NEVER left unattended (i.e. screen locked when
| you leave 100% of the time)
|
| * Local government agents (i.e. the local police) who can
| confiscate your powered on device but cannot afford to buy 3rd
| party cracking services that utilize exploits or more advanced
| extraction techniques (external RAM dumping)
|
| * A device that is completely powered off and confiscated by a
| powerful nation state agent but not later on returned to the
| original owner and they forgot to wipe the device in case of
| implants.
|
| In any case the design of TPM is completely flawed and suffers
| from "astronaut architects". If you grep the three volume 1000+
| pages of the TPM 2.0 architecture documents, you'll not find a
| single mention of "threat model".
|
| Specifically TPM is a multi-million dollar industry signed on by
| many tech companies (including Microsoft who uses it as an excuse
| to get you to buy a new PC because TPM == more secure right, but
| also because older computers don't support it) because places
| like governments and banks require it because they also don't
| understand threat models.
|
| TPM protection is fundamentally flawed because:
|
| * It cannot protect against a compromise in the boot chain (e.g.
| a UEFI driver is exploited, and it lies to TPM about the
| subsequent stage of code that is loaded while running a malware
| implant)
|
| * It cannot protect against RCE (remote code execution). This
| means if Windows ever has a vulnerability that can be exploited
| remotely, they can keylog -> steal your PIN -> replay it later to
| dump the key. Or just dump the key in memory if they have a PE
| (privilege escalation) as well.
|
| * It cannot protect against a user volunteerly installing malware
| (Bonzi buddy?)
|
| * It cannot protect against an attacker who installs something on
| your unattended computer (USB Rubber Ducky, Flipper Zero, etc)
|
| Basically the most common ways people get compromised sees no
| protection from TPM while esoteric attack situations that no
| attacker will realistic attempt are protected.
|
| TPM can never protect against these cases because it is logically
| (fTPM) and/or physically (dTPM) separate from the CPU. That means
| it cannot perform any policy enforcement against a CPU whose
| execution is under control of the attacker.
| lathiat wrote:
| It means malware can't exfiltrate the SSH key from your machine
| and keep using it. But yes they can potentially use it while
| still on your machine depending on if presence confirmation or
| re-inputting a credential is required. But that still closes a
| big gap.
|
| On a Mac secretive can also pop a notification making it more
| likely to passively observe such usage (not fool proof though)
| and the key can't (easily, maybe with some complex exploit) be
| used from an app not signed by the original developer. It can
| also require re input of your password. That specific security
| probably isn't possible on Linux though.
| candiddevmike wrote:
| > It means malware can't exfiltrate the SSH key from your
| machine and keep using it
|
| Are you sure about that? Presumably the secret parts of the
| SSH key are being read into memory at some point, or a RCE
| could dump the key the same way ssh-tpm-agent does.
|
| Don't rely on a TPM to store secrets. Use a secrets store
| that can be audited for use and have it generate dynamic,
| short lived credentials. For SSH, use SSH CAs.
| Foxboron wrote:
| >Are you sure about that? Presumably the secret parts of
| the SSH key are being read into memory at some point, or a
| RCE could dump the key the same way ssh-tpm-agent does.
|
| This is not how ssh-tpm-agent works. It does the key
| signing inside the TPM so you do not have access to the key
| on the machine itself.
|
| The private key _never_ hits memory or the machine itself.
| alex7734 wrote:
| TPM is not designed to prevent intrusion from hackers, it's
| designed to turn your general purpose computer into an
| appliance by preventing you, the owner, from modifying the OS
| in your computer as you see fit (and interact with third party
| services at the same time, thanks to remote attestation).
|
| It means that instead of _just patching_ the software in your
| computer to customize it now you have to resort to using 0days
| to do it like a criminal which makes it considerably harder.
|
| It does help against hackers, of course, and the same
| restrictions do secure you against some attacks (evil maid
| attacks) but that's not the intent.
|
| The threat model TPM protects against is:
|
| - You log in into Netflix (or whatever)
|
| - Netflix sends your PC the movie so you can watch it.
|
| - Your PC now has the movie in memory.
|
| - You extract the movie from your PC's memory and you can now
| watch it forever without Netflix's permission.
|
| What the "trusted" in Trusted Platform Module means is that
| with TPM they can trust your PC to not let you do that.
| jrockway wrote:
| It's a double-edged sword, right? On the one hand, Windows 12
| can be completely iOS-like and you can't do anything about
| it. On the other hand, someone with physical access to your
| machine can't replace your OS that sends them your disk
| encryption password as soon as you get a DHCP lease.
|
| Chrome OS really got this one right. You can disable all the
| security, but there is hardware that tells you that happened.
| It can also tell your employer so you don't download their IP
| to a laptop running malware. That's all it's ever been used
| for; no matter how much people try to make DRM a thing, it's
| never once worked. Every Netflix-exclusive show is easily
| downloadable on Usenet.
| KennyBlanken wrote:
| The sword analogy is getting a bit awkward here, but the
| people making the sword only care about how well it
| protects media and software - because they want their
| marketplaces (app/music/movie/game stores) to be as
| attractive as possible to media conglomerates.
|
| They don't give a damn how well it protects you.
| jrockway wrote:
| I'm uncertain. Microsoft isn't making any real money off
| of media. They sell licenses to use Outlook and rent you
| some computers, and there's their income.
| jrockway wrote:
| I mean, your complaints are that it doesn't make software more
| secure. That's true but that's an orthogonal effort. Imagine
| there was a world where software was secure (they rewrote
| Windows in Rust or whatever); now what tools do you need to
| ensure that someone didn't replace your secure software with
| their own compromised version? (For example, how do you know
| that LUKS is asking for your full-disk decryption key, and not
| some piece of malware that some random package maintainer added
| to /etc/systemd?) That's the gap that the TPM is designed to
| fill.
|
| Meanwhile, sure, it's not going to prevent you from clicking a
| link in your email to fakebank.com and typing in your SSN.
|
| I'm surprised that people are surprised that a $0.20 chip
| doesn't eliminate software bugs.
| patrakov wrote:
| In the TPM threat model, the attacker is you, and the defender
| is your employer who wants to make sure that you don't
| exfiltrate keys from your work laptop to any other (i.e.
| unauthorized) device.
| jimkoen wrote:
| > that can be exploited remotely, they can keylog -> steal your
| PIN -> replay it later to dump the key. Or just dump the key in
| memory if they have a PE (privilege escalation) as well.
|
| That can't happen if a TPM is used correctly. If the TPM is
| coupled with an OPAL enabled SSD for example, the actualy key
| used for data encryption is never loaded into main memory.
| Sure, disk content can be read by a malicious OS, but you do
| not gain access to any encryption keys. Additionally, you
| prevent MITM attacks by using challenge response authentication
| which some TPM's support, so again, your key is never revealed.
|
| > It cannot protect against an attacker who installs something
| on your unattended computer
|
| This is a strawhat since you won't ever be able to protect from
| user space malware. Apart from that, TPM's can enforce
| mandatory access control if supported (I know the T2 on Macs
| does exactly that). So no, you cannot easily install a root kit
| and expect it to work.
|
| > It cannot protect against a compromise in the boot chain
| (e.g. a UEFI driver is exploited, and it lies to TPM about the
| subsequent stage of code that is loaded while running a malware
| implant)
|
| At this point we are in the realm of an attacker stealing your
| device, desoldering a chip and rewriting the firmware on that
| chip. Were talking about _considerable_ ressources spent, just
| to trick you into thinking your device hasn't been compromised.
|
| I know that on non-Apple devices vendors will likely use some
| insecure off the shelf solution, but if done correctly these
| things are as close to unbreakable as possible.
|
| > Basically the most common ways people get compromised
|
| The TPM spec was written by NIST and it's purpose is not to
| protect the common user, but to offer advanced security
| features for business clients and governments. And there, a
| device that get's stolen is a common occurence.
|
| The reason you see it integrated in consumer devices for cost
| reduction. It getting abused for DRM purposes is entirely the
| media industries fault.
| s09dfhks wrote:
| At first I was expecting this to be a joke repo for "technical
| program managers". Was hoping it'd just print "connected to $1"
| intelVISA wrote:
| That sorta TPM does wealth extraction, this sorta TPM protects
| data extraction.
|
| Both are frequently mandated and provide heavy lock-in so YMMV.
| anotherhue wrote:
| This looks great. I was using GPG's ssh agent functionality with
| 'keytotpm' but this is cleaner.
| elric wrote:
| How many keys can I store inside a laptop's TPM? Is there a
| limit? I have hundreds of SSH key pairs, one for each thing I
| connect to. My .ssh/config file defaults to a nonexistent key for
| all hosts, except for hosts configured elsewhere in the file,
| where each host gets its own IdentityFile entry.
| heavyset_go wrote:
| Why are you doing this instead of using hardware security keys?
| Foxboron wrote:
| It has 6.3 Kb or something of memory. So not a lot.
|
| What `ssh-tpm-agent` does is that it simply doesn't store the
| keys on the TPM at all. It creates the ephemeral SRK, then load
| a sealed private key back into the TPM that allows us to use
| it.
|
| So you can have a couple hundred SSH key pair this way.
| sneak wrote:
| What is your threat model that requires such complexity?
| [deleted]
| elric wrote:
| It's not terribly complex, and it's all scripted. I don't
| like my identity being trackable across services, or across
| areas of my life. For instance, dickheads have created
| databases of public keys scraped from services like github,
| which can be used to identify the vast majority of github
| users whenever they ssh into some other service. By default,
| the ssh client will try to authenticate with every available
| keypair until it finds a match, which can further leak
| information about you(r machine).
| sneak wrote:
| Yes, I understand the attack, but what is the threat? You
| are already uniquely identifying yourself to each of these
| servers. What is the threat to you if your identity is
| correlated between them? You probably have the same
| username on many of them, no?
|
| It seems like privacy cosplay to me, tbh. I'm genuinely
| curious what type of threat it actually protects against,
| if any. What happens when two different systems you ssh
| into knows it's elric on both?
| ChoHag wrote:
| [dead]
| sah2ed wrote:
| Show HN: My SSH server knows who you are
|
| https://news.ycombinator.com/item?id=10004678
___________________________________________________________________
(page generated 2023-07-29 23:01 UTC)