_______ __ _______
| | |.---.-..----.| |--..-----..----. | | |.-----..--.--.--..-----.
| || _ || __|| < | -__|| _| | || -__|| | | ||__ --|
|___|___||___._||____||__|__||_____||__| |__|____||_____||________||_____|
on Gopher (inofficial)
URI Visit Hacker News on the Web
COMMENT PAGE FOR:
URI Native Secure Enclave backed SSH keys on macOS
j0hnM1st wrote 1 hour 28 min ago:
Fundamental services like DNS, which was designed as distributed going
down was the cause last 2 outages and really need to think of
alternatives methods to ensure resilience. Shift left, design better.
big-and-small wrote 6 min ago:
Bot comment? Or wrong tab? Moderators?
larusso wrote 3 hours 27 min ago:
Ok I wished for this kind of feature for years. I started using a
yubikey with an ssh key via gpg ssh-agent in 2018 or 2019. When
resident ssh keys came around I switched over to FIDO2 based keys on my
yubikey. The main issue with both was the fact that the default ssh
setup wasnât working anymore. One needs extra configs and more
commands to get to the public key etc. Yubikeyâs are great but block
an USB port. And then there is the age old question for me: One SSH key
per User for all services? One key per machine for all services? Or one
key per service?
This year I started to play around with the 1Password ssh-agent feature
(bit warden has it as well as far as I know)
If you're ok with allowing all your keys being listed in the agent this
works pretty easy out of the box.
I never liked the fact that the default recommended way to use ssh is
to use an agent that just has multiple keys which can be tested one
after another and in most cases stay unlocked there after first use for
the rest of the session.
I configured around to make sure that I explicitly use one key for one
specific service. But that is sadly extra configuration etc etc.
rtyu1120 wrote 5 hours 50 min ago:
The command is available on Sequoia too!
varenc wrote 5 hours 55 min ago:
side note: It's interesting that the `sc_auth` CLI tool to create the
SSH key, is just a bash script! It seems truly ancient, and has
comments referencing mac OS Tiger (20+ years old) and non-existent
files from old macOS. It calls out to
'/System/Library/Frameworks/CryptoTokenKit.framework/ctkcard' (not on
PATH) to actually create the ssh key.
vmodel_ai wrote 7 hours 31 min ago:
It feels pretty good.
dhosek wrote 7 hours 39 min ago:
This may be the thing to get me to upgrade to MacOS 26.
ikiris wrote 8 hours 38 min ago:
Its worth noting that this is the likely NSA backdoored curve under the
hood and probably should not be used.
rkeene2 wrote 9 hours 22 min ago:
If you're willing to go a bit further you can also do GPG signing with
ECDSA, though it requires a patched GPG due to bugs and a patched SSH
agent that allows raw signing. We have a packaged version with a macOS
UI [0], but the same backend [1] works on Linux using the tpm via
PKCS#11.
We have a blog post on this, but I guess it was never made public, but
the only difference between GPG and SSH is the way in which keys and
signatures are wrapped and listed through the various layers -- it's
all just fundamentally ECDSA with a named curve.
[0] [1] /tree/main/Agent/gnupg/...
URI [1]: https://github.com/KeetaNetwork/agent
URI [2]: https://github.com/KeetaNetwork/agent/tree/main/Agent/gnupg/sr...
daft_pink wrote 9 hours 24 min ago:
Why would you want the private key file if you store it within the
secure enclave?
lxgr wrote 9 hours 7 min ago:
Probably for the same reason that OpenSSH's `sk` implementation also
still needs a private key file (even for the "resident key" option):
You need to be able to point OpenSSH's various tools to something in
an identity context, and that something traditionally is a private
key file.
The article even mentions that it doesn't contain any sensitive data:
> Note that the "private" key here is just a reference to the FIDO
credential. It does not contain any secret key material.
It's a slightly different story for non-resident `sk`-backed keys;
these actually require the private key file since the hardware
authenticator itself is (or at least can be) stateless. (It's still
not a security risk if it ever leaks, but it's an availability risk
if it's ever lost.)
Not sure if macOS's backing implementation is stateful or stateless
(or some unfortunate hybrid of both; i.e., it might just store a
stateful wrapped key in some system-level keychain in a way that
intransparently breaks if the OS is ever reinstalled, but also
doesn't allow querying an intact system for any existing
credentials).
daft_pink wrote 7 hours 9 min ago:
Thanks I missed this in the description.
adastra22 wrote 11 hours 39 min ago:
Is there a way to make the lifetime of the key last more than a year?
metafunctor wrote 2 hours 20 min ago:
The key itself appears to have no validity period, the validity
period is only for the certificate made for the key. Maybe you could
create a CSR for the key/identity and then sign it with your own CA
(or self-sign with openssl) for whatever validity period you like.
Then `sc_auth import-ctk-certificate`.
WhereIsTheTruth wrote 12 hours 14 min ago:
I would not trust it personally, specially since the Chip Security Act
is looming
URI [1]: https://www.centerforcybersecuritypolicy.org/insights-and-rese...
johncolanduoni wrote 8 hours 17 min ago:
If the Secure Enclave on your Mac is backdoored, the fact that the
key from your Yubikey (or whatever HSM) is un-extractable will be a
very cold comfort.
jcalvinowens wrote 12 hours 23 min ago:
Does the hardware only support the NIST curves? Or is that just the
example that happens to be given?
arianvanp wrote 12 hours 7 min ago:
Only supports NIST curves and ECDSA yes.
I've heard people make the point before that EdDSA is not great for
secure enclaves due to being suspictable to Fault Attacks which could
lead to (partial) key extraction
jcalvinowens wrote 10 hours 56 min ago:
I don't trust the NIST curves: they were generated in a dubious way
which has been written about extensively elsewhere (the
coefficients for P-256 were generated by hashing the unexplained
seed c49d360886e704936a6678e1139d26b7819f7e90). I always avoid them
unless I have to use them. It makes me sad when hardware forces me
to use them.
> I've heard people make the point before that EdDSA is not great
for secure enclaves due to being suspictable to Fault Attacks which
could lead to (partial) key extraction
Huh, got a link? My understanding is that eddsa is better with
respect to side channels in every way, that was part of the intent
of it's design. I've worked with crypto hardware which supports it.
arianvanp wrote 9 hours 49 min ago:
[1] I think this can be solved by using hedged eddsa (Signal
does this)
URI [1]: https://romailler.ch/project/eddsa-fault/
watermelon0 wrote 12 hours 27 min ago:
Does anybody know why 'p-384-ne' (instead of 'p-256-ne') cannot be
used?
Key can be generated, but 'ssh-keygen -w /usr/lib/ssh-keychain.dylib -K
-N ""' cannot find the key to export.
arianvanp wrote 12 hours 19 min ago:
I think this is an openssh limitation.
openssh only supports sk-ecdsa-sha2-nistp256 and sk-ed25519 security
keys iirc
euroderf wrote 13 hours 9 min ago:
How can I get such a key into my iPhone too, so that I can sign emails
and file and such with the same private key when I'm on my phone, and
my public key is valid for all such operations ? Will iCloud take care
of that ? And then I want it all usable from my (multiple) email
clients...
akerl_ wrote 5 hours 59 min ago:
This is for SSH, not GPG.
arianvanp wrote 13 hours 0 min ago:
These aren't synced over iCloud
What you're thinking of are Passkeys. Which are synced. Somebody
would have to write an SecurityKeyProvider that talks to the Passkey
API instead.
Actually I don't think it's completely impossible. The only thing is
that passkeys are origin-bound. They belong to a specific AppBundle
ID or domain name. If say Secretive would add passkey support then
that specific public/private keypair can't be used by another app.
Though it does sync across instances of the app across devices.
redleader55 wrote 13 hours 21 min ago:
This exists: [1] .
It's a golang library that abstracts usage of ssh keys backed by
hardware on all sorts of devices - mostly designed for laptops, but
supports Linux, Windows and MacOs
URI [1]: https://github.com/facebookincubator/sks
Foxboron wrote 13 hours 12 min ago:
A golang library is cool, but it doesn't give you a working
ssh-agent.
I started working on one few years ago:
URI [1]: https://github.com/Foxboron/ssh-tpm-agent
agartner wrote 12 hours 48 min ago:
I've been using this for a ~year now and it works very well.
Thanks!
berzan wrote 13 hours 26 min ago:
This is just so perfect. No longer a 3rd party glue and separate ssh
agent is needed.
cube2222 wrote 13 hours 43 min ago:
Does anybody know if there is something similar for gpg keys? E.g. for
commit signing?
That is, natively with the Secure Enclave, not exportable.
rkeene2 wrote 9 hours 13 min ago:
See my comment above regarding Keeta Agent, which supports GPG and
SSH with the same key.
moooo99 wrote 12 hours 4 min ago:
Some Fido2 keys like the YubiKey and Nitrokeys support PGP keys as
well. Works pretty nice as well and has the added bonus of your key
not being tied to a pice of hardware that is as likely to break like
a laptop (or be upgraded on a semi-regular basis)
jabberwhookie wrote 13 hours 29 min ago:
You can (mis)use ssh keys for git signing, but GPG on gpg-card and
S/MIME on PIV card are the two standards and their respective
hardware implementations (for signing keys in general.)
fpoling wrote 13 hours 35 min ago:
Git commits can be signed with ssh keys.
jeroenhd wrote 12 min ago:
Unfortunately I've found that not every source management tool
understands SSH signatures and using them may have your commits end
up being shown as signed by an untrusted key.
On Linux, GPG supports TPM2, but I'm not sure if that also works on
macOS.
wahern wrote 13 hours 48 min ago:
Time to up my game and finish adding new features to KeyMux, which
supports enclave keys for SSH, SSL, and PGP, including in mixed-use
scenarios, such as secure enclave-backed SSL peer authentication to a
Vault server for SSH authentication with a non-exportable Vault private
key: [1] ( [2] )
URI [1]: https://keymux.com/
URI [2]: https://apps.apple.com/us/app/keymux/id6448807557
procaryote wrote 13 hours 59 min ago:
Oh, this is neat! I wonder if apple just added support for the secure
enclave as a provider or if this might help fix the bad experience of
yubikeys on the mac. Last time I tried it, the distributed ssh and
ssh-agent didn't play well with security keys
jedberg wrote 14 hours 14 min ago:
If I understand correctly, this means you can't back up the private
key, correct? It's in the Secure Enclave, so if you lose your laptop,
you also lose the key? Since it looks like export only really exports
the public key not the private one?
Probably not the worst thing, you most likely have another way to get
into the remote machine, or an admin who can reset you, but still feels
like a hole.
Or am I missing something?
ps. It amuses me that my Mac won't let me type Secure Enclave without
automatically capitalizing it.
Edit: I understand good security is having multiple keys, I was simply
asking if this one can be backed up. OP answered below and is updating
their webpage accordingly.
WhyNotHugo wrote 3 hours 37 min ago:
Right, you can back up the key.
Thereâs three general approaches to SSH: having per-device client
keys, having per-server keys and having the same key everywhere.
A Secure Enclave, Yubikey or other hardware keys work well with the
first approach. Ideally, you wonât loose all keys at once.
notepad0x90 wrote 3 hours 39 min ago:
posting late in the discussion, but you shouldn't back up our private
keys. The ideal setup is with ssh-ca's anyways.
UltraSane wrote 4 hours 26 min ago:
This is the fundamental paradox of hardware secured keys. Basic ones
generate the private key inside and never let it be exported. This
allows you to be very sure it won't ever leak but also doesn't let
you back it up. Higher end Hardware Security Modules allow the
private key to be exported but only when encrypted with the valid
public key of a destination HSM.
jeroenhd wrote 12 hours 20 min ago:
Yes, that's the point, indeed. One key per device, impossible to
extract, so you need to break into the device to use the key.
If you want to maintain backup access, you can use an SSH CA to sign
your public SSH keys, then keep the private keys on your device. If
you keep the CA keys safe (i.e. physically safe on a flash drive),
this means you can even add new keys after you lose all your devices.
This way, you only need to trust your one CA on your servers (so you
don't need to copy 20 public keys around for every server).
Plus, if you're setting up a (separate) SSH CA, you can also sign
servers' host keys, so you don't need to rely on TOFU to prevent MITM
attacks, if that's something you care about.
midtake wrote 12 hours 37 min ago:
You use multiple keys, if you need a key usable across different
systems then buy a yubikey.
aaomidi wrote 12 hours 41 min ago:
You shouldnât be backing these keys up anyway imo
hylaride wrote 13 hours 42 min ago:
Strictly speaking people should be using multiple keys so if a device
is lost/stolen, you're not left high and dry. Ideally one per
device, especially if they don't support some kind of secure enclave.
I keep one in a yubikey protected by a PIN that sits in a safety
deposit box, too. This way if I have my laptop, phone, and
day-to-day yubikey is a house that suddenly burns down, I'm still ok.
cedws wrote 13 hours 52 min ago:
You're not really supposed to 'export' keys. Any time you move a key
you risk exposing it. The idea of PKI is that only public keys move,
the private key stays in one place, ideally never seen.
asteroidburger wrote 13 hours 42 min ago:
It's much safer to export a key one time and import it into a new
machine, or store it in a secure backup, than to keep it just
hanging out on disk for eternity, and potentially get scooped up by
whatever malware happens to run on your machine.
Nextgrid wrote 9 hours 48 min ago:
Any malware capable of exfiltrating a file from your home folder
is also capable of calling the export command and tricking you
into providing biometrics.
asteroidburger wrote 4 hours 16 min ago:
Not necessarily; "read file" is very different from "execute
command." The biometrics part is a substantial lift as well.
jedberg wrote 13 hours 46 min ago:
I've been in the security space for 25 years, and understand the
theory of PKI. But I've also been in the ops space for 30 years,
and understand that if you don't balance security theory with
operational practice, critical business functions can fail.
Ideally yes, the private key is never seen. In reality, it needs
to be backed up in a secure place so it can be restored in the
event of a failure.
fragmede wrote 9 hours 23 min ago:
No but thatâs the point. If thereâs a copy of the private key
out there, then it can be copied. The whole point is that the
jedberg-laptop-1 key only ever exists as jedberg-laptop-1. When
that laptop gets lost/stolen/destroyed/aged out, there's 100%
certainty that it can't be recreated. The other side of that
equation is that you need a tree of keys and a whole IT
department to manage them so you don't get locked out of your
servers. This particular bit of software is about ssh keys and
exists within a larger conversation about PKI which you know more
about than I, but operationally, you have this, and then you have
a root login private key file locked with Shamir secret sharing
(ssss on debian) that you distribute to a very select few number
of key bearers. And then don't all get on the same plane
together, ever.
adastra22 wrote 11 hours 47 min ago:
I think you are mixing up concerns. You need a backup key. That
doesn't mean you need to backup your key.
Anything (everything?) using SSH authentication supports multiple
authentication keys. Have a yubikey in a locked deposit box or
something.
jedberg wrote 10 hours 59 min ago:
Today I make a private/public keypair, and the private key is
on my laptop in my encrypted home folder. It also gets backed
up to my encrypted offsite backup. That way if my laptop
breaks or is stolen, I can restore from backup and be up and
running as before.
I was simply asking if that is still possible with this method,
nothing more.
And not every service that uses ssh auth allows multiple keys.
adastra22 wrote 7 hours 53 min ago:
As others mention, there is no point to using the Secure
Enclave if you have your key stored on disk or in your
backup. Itâs like putting impressive locks on the front
door, while leaving the window open.
Beyond that, you can do that just fine right now by making
TWO keys. If you lose the laptop, oh well. Recover with your
backup key (which is hopefully kept more securely than you
describe - it can be inconvenient to access since it is only
needed for recovery).
This also lets you go further in locking things down or
providing you notifications, as you can distinguish server
side between your usual key and the backup key.
The point of the enclave is to be noncloneable and access
limited. Extracting the key for the backup would negate the
benefits derived from that.
cortesoft wrote 8 hours 1 min ago:
If you are keeping it on disk (encrypted or not), you donât
really gain anything from using the Secure Enclave.
doctorpangloss wrote 9 hours 1 min ago:
yes, you can export keys using this method, and they will be
simlarly secure as password encrypted keys you generate
without the secure enclave with openssh, but with the
convenience that you can decrypt the key using TouchID on
macOS.
Such a setup is marginally more secure than just typing in
the passwords, since it is much harder to intercept the
TouchID chain from touch to decrypting the SSH key compared
to your keyboard to the terminal.
All that said, here are the priorities of a few security
technologies:
TouchID:
#1 environment integrity, that is to say, to protect Apple
services monopolies and fees such as eliminating password
sharing of services accounts, #2 convenience as an
alternative to passwords reducing friction when you buy
stuff, #3 security.
1password:
#1 convenience, #2 security
I cannot tell you really what is "#1" in security among
packaged ready to buy commercial products, Everyone,
practically, makes affordances for convenience ahead of
security. I suppose there isn't really a great product for
normal people that puts security first. Of course, there are
an ad hoc collection of practices that amount to, #1
security. But a product? No. Even Apple Lockdown mode...
well, they can still just push an update that makes it
pretend it is enabled when it is not, so...
Nextgrid wrote 9 hours 56 min ago:
Itâs possible but would not bring you any extra security.
The advantage of non-exportable, HSM-backed keys is that you
are guaranteed that the only way to use that key is to have
online access to the HSM, and you can recover from HSM access
compromise without having to replace the keys.
If you make the key exportable it is no better than if it was
stored on your disk to begin with.
philsnow wrote 13 hours 13 min ago:
> if you don't balance security theory with operational practice,
critical business functions can fail
i.e. people will circumvent the secure-but-onerous path. (I
don't think they can be faulted for trying to get their work done
either, I'm agreeing with you)
eptcyka wrote 13 hours 14 min ago:
In what scenario would you prefer to backup an SSH key in favor
of generating new SSH keys?
jedberg wrote 12 hours 32 min ago:
When I have my pub key in the authorized_keys files of many
machines, especially machines where I don't control the
authorized_keys file.
Nextgrid wrote 9 hours 50 min ago:
In this case you can maintain an offline SSH CA and trust
that on the remote machines, and then sign yourself leaf
certificates against a non-exportable HSM-backed key. In case
of loss you just make a new key and sign a new certificate.
Of course this just moves the key management problem
somewhere else: now you need to protect the CA key, but that
might be easier since you would only need access to it in a
disaster recovery scenario if you replaced the laptop or
otherwise lost access to your HSM-backed key.
As usual, it all depends on your threat model.
lxgr wrote 9 hours 36 min ago:
But how do you revoke any compromised certificate if you
don't control the remote machines?
Nextgrid wrote 9 hours 34 min ago:
Keeping the certificateâs key as non-exportable in the
HSM means you do not need to revoke it as it cannot be
compromised (not permanently at least), once youâve
regained access to the HSM you can assume the bad guys
are out.
Of course the CA key itself is another story, which is
why this merely moves the problem elsewhere (however
since you only need access to the CA during initial
provisioning of a new certificate key, you can better
control access to it).
lxgr wrote 9 hours 19 min ago:
> Keeping the certificateâs key as non-exportable in
the HSM means you do not need to revoke it as it cannot
be compromised (not permanently at least), once
youâve regained access to the HSM you can assume the
bad guys are out.
How so? I can still lose my Yubikey, and even if the
attacker can't export the private key corresponding to
a CA-signed SSH certificate, they can still use it, no?
How would I "regain access" in this scenario?
Nextgrid wrote 8 hours 30 min ago:
I was thinking the HSM in this case is your Macbook
and its TPM/Secure Enclave, in which case you'd
either recover it or assume the attacker is unable to
use it due to biometrics/PIN. I guess the Yubikey has
a PIN too with a limited number of tries.
Either way, you either recover the HSM and then don't
need to rotate the keys, or you don't in which case
you either use OpenSSH's key revocation mechanism
(which I believe involves distributing some some sort
of CRL to every server), use time-limited SSH
certificates and wait out the expiry of the
compromised key, or scrap the whole CA and start
fresh.
Again this depends on your threat model. The somewhat
uncommon requirement where you can't manage your own
`authorized_keys` on the remote host complicates
things a lot; if you could, then you'd use your
existing access (sign yourself a new certificate
using your SSH CA) to rotate the whole CA... or just
keep two keys in there (primary and backup) and skip
the whole CA dance, since it's purely a workaround
for the hard requirement of only being able to put
one key in authorized_keys.
pi-rat wrote 13 hours 31 min ago:
You can use more than one key you know.
Keep the private key you actively use in the secure enclave. The
system you actively use is most at risk.
Keep a secondary offline private key as backup. You can generate
and store it in a secure location, and never move it around.
Airgapped even if you want. You could even use a yubikey or other
hardware for the secondary key giving you two hard to export
keys.
Distribute pub keys for both of them.
Best of both worlds?
lxgr wrote 9 hours 40 min ago:
That can work really well for systems where you don't need to
share your key material very often, or where sharing is
optimized for n-key scenarios.
SSH isn't always that. For example, ssh-copy-id by default does
not copy over multiple identities.
For that reason, I'd personally prefer to import my (otherwise
airgapped) key into my secure hardware exactly once and mark it
as non-exportable in the SSH scenario.
vlovich123 wrote 12 hours 26 min ago:
Itâs important to remember that over time systems develop
complexities that can be hard to recover from scratch because
by definition air gapped data arenât ones you are regularly
exercising. Hereâs an example of this in action from
Googleâs history
URI [1]: https://google.github.io/building-secure-and-reliable-...
sunaookami wrote 3 hours 18 min ago:
>It took an additional hour for the team to realize that the
green light on the smart card reader did not, in fact,
indicate that the card had been inserted correctly. When the
engineers flipped the card over, the service restarted and
the outage ended.
This is some good read!
morshu9001 wrote 13 hours 1 min ago:
Yeah but if you get a new device, you have to go add its pubkey
to every server you ever use. I wish there were an easier way,
otherwise it's understandable that people copy privkeys.
miki123211 wrote 6 hours 46 min ago:
There is an easier way, it's called TLS certificates, it's
just that SSH decided not to use it for some reason.
Other systems of this nature have figured out long ago that
you should be able to have one personal certificate (stored
securely in an airgapped environment), from which you'd
generate leaf certificates for your devices every year.
5d41402abc4b wrote 3 hours 54 min ago:
or FreeIPA?
notpushkin wrote 5 hours 55 min ago:
SSH CA is what youâre looking for. Itâs a thing
apparently (but I havenât tried it yet).
ikiris wrote 5 hours 58 min ago:
ssh has supported signed certs for literal years
QuantumNomad_ wrote 9 hours 56 min ago:
> if you get a new device, you have to go add its pubkey to
every server you ever use
Itâs not too bad, if the number of servers is not too high.
I have different client pub keys on my phone, multiple
laptops and desktop computers and manage my authorized keys
to be able to ssh into my servers from the devices, as well
as from one laptop to another or from my phone to one of the
laptops, etc.
Because I already have several client devices I donât
really need any backup ssh keys. The fact that each device
has a different key means that if one laptop breaks or my
phone is stolen, I can still ssh into everything from one of
the remaining devices and remove the pub key of the broken or
stolen device from authorized keys and generate new keys on
new devices and then using one of the existing devices to add
the pub key of the new device to the authorized keys of the
servers and other devices.
For me itâs manageable to do it manually. But if you have
very many servers youâd probably want to use a
configuration management tool like Chef, Ansible, Puppet or
Saltstack. Presumably if you have a very high number of
servers youâd already be using a configuration management
tool like one of those for other configs and setup anyways.
Nextgrid wrote 9 hours 59 min ago:
If youâre operating at the scale this is too cumbersome to
do manually surely you already have a configuration
management system in place to automate this no?
morshu9001 wrote 7 hours 56 min ago:
I have keys tied to several random things, including home
servers, GitHub, and AWS. Wouldn't call this scale exactly,
but when I got a new laptop, it was way easier to just copy
.ssh onto it rather than hunting everything down.
yjftsjthsd-h wrote 12 hours 21 min ago:
There is an easier way: Create a SSH CA, add that to your
authorized_keys everywhere, use it to sign the individual
public keys.
lxgr wrote 9 hours 38 min ago:
But now you need to worry about revocation or at least key
lifetimes.
yjftsjthsd-h wrote 6 hours 37 min ago:
I would argue that doing both of those is still less work
than maintaining authorized_keys in many places.
arianvanp wrote 11 hours 47 min ago:
Yep that's what I do! I have two ssh-ca's stored on two
Yubikeys. And both are trusted by my servers.
If I lose one I can still sign new certs with the other.
URI [1]: https://github.com/arianvp/nixos-stuff/blob/master...
arianvanp wrote 14 hours 5 min ago:
Check out `man sc_auth`. There's also an exportable variant where the
private key is encrypted using the secure enclave as opposed to
generated on the secure enclave:
% sc_auth create-ctk-identity -l ssh-exportable -k p-256 -t bio
% sc_auth list-ctk-identities
p-256 A581E5404ED157C4C73FFDBDFC1339E0D873FCAE bio
ssh-exportable ssh-exportable 23.11.26, 19:50 YES
% sc_auth export-ctk-identity -h
A581E5404ED157C4C73FFDBDFC1339E0D873FCAE -f ssh-exportable.pem
Enter a password which will be used to protect the exported
items:
Verify password:
You can then re-import it on another device
% sc_auth import-ctk-identities -f ssh-exportable.pem.p12 -t bio
Enter PKCS12 file password:
I'll add this to the guide
ggm wrote 4 hours 38 min ago:
Can you explain which keys in the secure enclave make this work
because it has at least two keysets: a public-private keypair
locked to the root key Apple instantiated in hardware as fused
links in the chip and so in theory this could include private keys
common to all the devices in this chipset generation, and the
locally generated unique keys which are tied to this specific
device.
Using the first pair or products of the first pair, means in
principle your private key is protected by the goodwill of Apple
only: if you allow it to exist at rest in a form only this shroud
protects, then Apple can read the private key unless the symmetric
algorithm used to "unlock this private key with your password" is a
good one, and you chose a password wisely. I haven't used the
function so I can't comment how they constrain what you put in as a
personal lock on these blobs.
I am not a cryptographer.
lxgr wrote 9 hours 55 min ago:
Is there a way to import an existing (compatible) key and still
mark it as non-exportable?
That seems more useful for the SSH key scenario: Generate a key in
memory and back it up to offline storage once, and otherwise only
use it in a way totally non-exportable by any malware.
This sentence
> The exportable private key is encrypted with Elliptic Curve
Encryption Standard Variable IVX963 algorithm which is backed by a
Secure Enclave key.
makes it sound like exportable keys might inherently not be Secure
Enclave resident in Apple's implementation, which would be
unfortunate, as anything else can still be accessed by malware with
kernel-level privileges.
(GPG, and I believe also PIV, allow importing externally-generated
keys without necessarily marking them exportable; they'll just,
correctly, lack any attestation statement about having been
generated in secure hardware.)
awaikour wrote 5 hours 29 min ago:
Another option is to generate a key and put it on an offline
storage, and have a second key only in the SE. This means you'll
need to upload two public keys to places to have a backup instead
of one, but I think would otherwise achieve the same thing.
The nice thing with this is you can keep your backup public key
easily accessible. I try to keep a primary and backup Yubikey on
everything important, but you have to physically get the backup
Yubikey in order to add it to a site.
cyberax wrote 6 hours 4 min ago:
No. There is no way to import an existing key into the Secure
Enclave. Only Apple is allowed to do that.
The best you can do is use the SE to decrypt the key and then use
the clear text key for encryption/decryption.
This also means that passkeys on macOS/iOS are (at some point)
exposed as clear text.
big-and-small wrote 23 min ago:
> The best you can do is use the SE to decrypt the key and then
use the clear text key for encryption/decryption.
AFAIK this is what "secretive" was doing all the time.
rjdj377dhabsn wrote 13 hours 40 min ago:
How is this method any different from encrypting the private key
without any secure enclave?
Isn't it just using a password derived key?
arianvanp wrote 13 hours 30 min ago:
The key is stored encrypted with a unique symmetric key that
only your secure enclave knows until the point that you export
it. It then re-encrypts it with the password.
Until you export it it's just as strong as an enclave-generated
one.
Obviously don't keep the exported password encrypted key around
and don't use a weak password for export.
gruez wrote 13 hours 27 min ago:
>The key is stored encrypted with a unique symmetric key that
only your secure enclave knows until the point that you export
it. It then re-encrypts it with the password.
But what's the security benefit of this compared to having a
keyfile? So far as I can tell from the commands you provided,
there's no real difference, aside from a hacker having to
modify their stealer script slightly.
conradev wrote 9 hours 57 min ago:
Unlike a TPM and like a YubiKey, you can configure the secure
enclave to require presence (via Touch ID) so that a stealer
script would be stopped with a prompt.
lxgr wrote 9 hours 14 min ago:
Until the next time you touch your Touch ID for any other
operation. It seems realistic for an attacker script to
anticipate that and open its own prompt at the right moment
(i.e. with your finger already on the way to the button).
arianvanp wrote 13 hours 18 min ago:
Why is it more secure: a key file on disk is decrypted into
memory every time you enter your passphrase. It means the key
is around in plain text in the memory of ssh or ssh-agent.
Which means it's extractable by an attacker.
An exportable key does all the signing inside the secure
enclave and never exposes the decrypted key to OS memory.
The exported key you can keep in a safe for disaster
recovery. You shouldn't keep it on your computer of course.
gruez wrote 12 hours 57 min ago:
>It means the key is around in plain text in the memory of
ssh or ssh-agent. Which means it's extractable by an
attacker. An exportable key does all the signing inside the
secure enclave and never exposes the decrypted key to OS
memory.
But malware can just tell the secure enclave to export the
key? Yes, they'll have to write new code to do that, but
it's not particularly hard (it's 1 line code from your
example above), and it's security through obscurity.
epistasis wrote 10 hours 24 min ago:
As a user I prefer a single touch to typing a passphrase
every time. A passphrase also has other attack vectors
like keylogging, etc., which would allow replays.
But even if security was exactly the same, I'd prefer the
touch to the typing.
arianvanp wrote 12 hours 46 min ago:
The export operation is guarded by TouchID. So the
malware needs to trick you into performing the TouchID
gesture.
But yeh the malware only needs to trick you to hit
TouchID once. Instead of on each sign operation. So if
that's in your threat model don't make the key
exportable.
gruez wrote 12 hours 36 min ago:
> So the malware needs to trick you into performing the
TouchID gesture.
That's not meaningfully more difficult than tricking
you into revealing your key file password.
>Instead of on each sign operation.
But from your video each sign operation also requires a
touchid prompt?
palata wrote 9 hours 35 min ago:
> That's not meaningfully more difficult than
tricking you into revealing your key file password.
No, but that's meaningfully more difficult to do
without an intervention from the user. Say your
computer is infected, the malware won't silently do
it: it will have to interact with you.
And an important part is that you apparently don't
have to make the key exportable:
> So if that's in your threat model don't make the
key exportable.
Which now makes it meaningfully more difficult to
extract.
I would personally not export it, just like I don't
export (and can't export) the key from a security
key. That's a feature.
__turbobrew__ wrote 1 hour 5 min ago:
I hit my touchid probably 10 times a day, seems
pretty easy for me to be tricked into hitting
touchid thinking that okta forgot my session or
something like that.
Nextgrid wrote 8 hours 14 min ago:
> Say your computer is infected, the malware won't
silently do it: it will have to interact with you.
MacOS is so needy about all kinds of
fingerprint/password-related things (and has no
context of secure desktop) that it is trivial for
malware to simulate and no way for the user to tell
whether it's genuine, so it's not a real barrier at
all.
monocularvision wrote 12 hours 47 min ago:
The malware would have to prompt for biometric
authentication before exporting.
Nextgrid wrote 10 hours 3 min ago:
So it just has to wait until youâre about to do a
legitimate operation requiring authentication,
intercept that to export the key, and cancel the real
one with a bogus error (and youâll just try again
without any second thoughts).
MacOS has also no concept of secure desktop/etc where
the OS can use some privileged UI to explicitly tell
you what you are signing and prompt for PIN/biometrics.
Itâs in fact a well-known problem where legitimate
dialogs for system/Apple ID password have no
distinguishing features from fake ones.
grosswait wrote 7 hours 3 min ago:
Couldnât any type of dialogue be faked? What are
you suggesting is possible but not implemented?
Nextgrid wrote 5 hours 58 min ago:
Generally dialogs that require sensitive input
provide some way for the user to ensure they are
issued by the OS and not a random program. Windows
historically used the Secure Attention Key (that's
why domain-linked machines used to require pressing
Ctrl+Alt+Del to login, to train users to only enter
credentials in secure contexts) which is a key
combo that the OS always intercepts and thus once
pressed you can be assured you are typing into a
trusted UI and not a piece of malware emulating the
trusted UI.
Of course, this was back in the day when computers
were primarily a productivity tool and not an ad
delivery vehicle, so it's unlikely this problem
will ever be solved.
traceroute66 wrote 13 hours 0 min ago:
> The exported key you can keep in a safe for disaster
recovery.
No. Your "disaster recovery" should be either a second
device with a Secure Enclave, or a Yubikey.
Making it exportable from the Secure Enclave defeats the
whole purpose.
sroussey wrote 13 hours 40 min ago:
â This is might be considered secure but is convenient for key
backup.â
Might want to clean up that sentence.
comprev wrote 14 hours 11 min ago:
Inability to export the private key is no different from using an
YubiKey? You can't "backup" the private key they generate either.
nothrabannosir wrote 13 hours 51 min ago:
Which makes yubikey impossible to use with geographically
distributed backups. You need the backup available at all times for
when you want to register with any new service.
This is why you should use a device which allows exporting the
seed, like e.g. multi purpose hardware crypto wallets.
lxgr wrote 9 hours 28 min ago:
> You need the backup available at all times for when you want to
register with any new service.
Not for SSH (at least using the OpenSSH sk implementation).
Nextgrid wrote 9 hours 42 min ago:
This is true for passkeys/webauthn/u2f, which is why itâs trash
and a completely flawed and not fit for purpose standard (of
course the primary purpose is vendor lock-in, not reliable and
disaster-proof authentication).
But SSH allows you to export the public key and then you can
enroll it on as many hosts as you want without needing access to
the private key, so the backup key can remain in a safe, ideally
forever as you should never need it.
lxgr wrote 9 hours 22 min ago:
I agree that it's inconvenient in many cases, but what vendor
am I being locked into, exactly? My primary hardware key can be
from a completely different vendor than the backup one, so I
don't quite buy the conspiracy angle.
There's also no technical obstacle preventing anyone from
creating "paired" hardware authenticators that share the same
internal root derivation key and can as such authenticate to
all services (at least if they don't demand resident
credentials) that were registered to any of the keys in the
set.
The fact that these keys don't exist on the market (I believe
Yubikey looked into them a while ago) more is evidence for the
lack of demand, and less for the existence of a cabal, in my
view.
Nextgrid wrote 9 hours 3 min ago:
Being locked into a set of a handful of vendors who offer
"secure" sync (of course, this is not a true PKI and actual
key material is being synced, meaning it's only as secure as
the syncing protocol and your authentication to it).
Authenticator implementations who allow exports outside of
the vendor cartel are threatened to be blacklisted: [1] > My
primary hardware key can be from a completely different
vendor than the backup one, so I don't quite buy the
conspiracy angle.
The fundamental flaw is that enrolling an authenticator
requires it to be present, making a backup strategy much less
resilient as it means your secondary device needs to be
constantly present and thus exposed to the same
local/environmental risks the primary one is
(theft/fire/faulty USB port that fries everything plugged in
and you only realize after nuking both your keys). It makes
an offline backup scenario like with SSH (where you copy a
public key and otherwise leave the authenticator out of reach
in a safe place) impossible.
Making it hard/impractical to maintain a reliable backup
yourself sure makes those proprietary sync-based services
attractive, which also doubles as reducing security since key
material is being synced and can potentially be extracted
(impossible with a true HSM + PKI implementation).
> preventing anyone from creating "paired" hardware
authenticators
Don't certain types of keys involve writing something to the
authenticator, fundamentally preventing this (as the backup
authenticator won't get this written value)?
> cabal
It doesn't have to be explicit coordinated action like
intentionally wanting to prevent people from self-managing
passkeys (in fact any hint of it being intentional would be a
liability in a potential anti-trust situation, so that's a
big no-no); it can be done by simply omitting this scenario,
by accident or for "security" purposes, or deprioritizing it
to hell. In fact the Credential Migration spec is still a
draft and appears quite recent, despite passkeys being
heavily promoted for a while: [2] - you'd think that such as
basic feature would be sorted before the push to switch to
passkeys no?
In fact you see this exact strategy playing out: [3] > For
the initial delivery of Credential Exchange, we focused on
the most wide use case [emphasis mine]
"Initial" delivery focuses on the most widespread use-case
(how convenient it also happens to be the most
corporation-friendly use-case), with everything else coming
"later", meaning never. I'm sure it'll rot in some Jira
backlog as a liability shield so they can promise they did
plan for it and just never got around to it, but everyone
understands it will never actually get implemented.
URI [1]: https://github.com/keepassxreboot/keepassxc/issues/1...
URI [2]: https://fidoalliance.org/specs/cx/cxp-v1.0-wd-202410...
URI [3]: https://github.com/keepassxreboot/keepassxc/issues/1...
lxgr wrote 8 hours 58 min ago:
How can the "cartel" "blacklist" anyone? The only thing the
FIDO alliance can do is not include a vendor's attestation
key as trusted in their vendor database, and software
solutions aren't on that list to begin with.
> The fundamental flaw is that enrolling an authenticator
requires it to be present [...]
Yes, but that doesn't mean you can't backup the full
authenticator state.
Here's a toy WebAuthN implementation that is backed by a
passphrase that you remember or write on a piece of paper
which works on many websites supporting passkeys and not
enforcing attestation (which is the vast majority, since
Apple, Google, 1Password, and Bitwarden all don't support
attestation for synchronized credentials a.k.a. passkeys):
[1] > Making it hard/impractical to maintain a reliable
backup yourself sure makes those proprietary sync-based
services attractive
It's also completely open source and can be backed up :)
(But again, it's a toy demo â don't use it for anything
sensitive!)
URI [1]: https://github.com/lxgr/brainchain
Nextgrid wrote 8 hours 43 min ago:
> How can the "cartel" "blacklist" anyone?
All they have to do is publish a "best practices"
statement or some RP certification program mandating
attestation to be used (and some PR around how only
"certified" RPs are secure) and job done. The only reason
they didn't do that yet is that Apple is refusing to play
ball and support attestation (but this may change).
The threat was clearly there in the original Github
issue, and it's just a temporary inconvenience they can't
currently follow through on it.
> Yes, but that doesn't mean you can't backup the full
authenticator state.
Having the secondary authenticator present in the same
vicinity as the primary one exposes it to risks. Having
to dump authenticator state at regular intervals now
means your backup authenticator must be reachable for
writing online, so it can't be a simple "cold storage"
backup like a Yubikey in a safe anymore. This also opens
up security concerns since you're now dumping and syncing
private keys left and right over a network and you lose
the peace of mind of using an HSM-backed non-exportable
private key where the HSM being unplugged guarantees
nobody is currently using your keys.
Seems like a shit ton of complexity and effort to work
around a problem OpenSSH elegantly solved 30 years ago.
> Here's a toy WebAuthN implementation
Thanks, I will check it out and read up on it. I'd be
genuinely happy to move to WebAuthn if I could build my
own hardware authenticators that allow the backup one to
remain fully offline in a safe, and not have private keys
flying around (if I'm doing that, it's not much of an
improvement over syncing passwords - except those I can
at least type or tell over the phone in an emergency when
I need someone else to act on my behalf).
Edit: so it seems like I am mostly right? Only
discoverable credentials count as "passkeys", and those
generate per-site private keys, meaning offline,
cold-storage backups are impossible. I guess I'm sticking
to my password manager then since passkeys would provide
no improvement in this case.
traceroute66 wrote 13 hours 2 min ago:
> Which makes yubikey impossible to use with geographically
distributed backups.
Huh ?
You do know you can wrap a symmetric key with multiple asymmetric
keys, right ?
epistasis wrote 13 hours 44 min ago:
Are you talking about SSH or a different setting?
With SSH, you can always share the primary and backup pub keys,
even if you don't have the backup key handy.
nothrabannosir wrote 13 hours 39 min ago:
No I got distracted by the word yubikey. Arguably not the same
subject. :)
epistasis wrote 13 hours 34 min ago:
Nonetheless I'm glad to hear about it. I don't yet use
YubiKeys for FIDO, because I was concerned a bit about this
enrollment process, and hadn't bothered to figure out what
others do.
johnisgood wrote 14 hours 3 min ago:
Yeah, that is why you should not [always (depends on your use
case)] generate it on a YubiKey.
You need to have:
- an offline master private key backup (air-gapped)
- primary YubiKey (daily use)
- backup YubiKey (locked away)
- revocation certificate (separate storage) (it is your
kill-switch)
Having a second YubiKey enrolled is the standard practice.
What people do wrong is:
- They generate directly on YubiKey
- They only use one device
- They do not create a revocation certificate
- They have no offline backups
You generate your GPG keys on a secured system, load the subkeys
(not the master because it is not used for daily cryptography) into
the YubiKeys, and then remove the secret keys from this system
where you generated the keys.
lxgr wrote 9 hours 33 min ago:
Does OpenSSH's `sshd` even support GPG key revocation? (Assuming
you're talking about using the GnuPG card application of
Yubikeys, since the newer "native" FIDO security key
implementation of OpenSSH does not support importing existing
keys to my knowledge.)
johnisgood wrote 2 hours 2 min ago:
I elaborated on sshd + GPG key revocation here: [1] Short
answer is that it does not.
URI [1]: https://news.ycombinator.com/item?id=46026415
doublepg23 wrote 11 hours 55 min ago:
Do you have a good guide/video/write up on this?
Iâve been putting off remaking my GPG and SSH keys using a
Yubikey.
atrettel wrote 6 hours 3 min ago:
This guide [1] mostly follows the practices the previous poster
outlined.
URI [1]: https://github.com/drduh/YubiKey-Guide
traceroute66 wrote 13 hours 3 min ago:
> Yeah, that is why you should not generate it on a YubiKey
No. You should ALWAYS generate on the Yubikey. That's the whole
point.
Your backup is one (or more) other keys.
lxgr wrote 9 hours 29 min ago:
A lot of absolutes are being thrown around in the comments
here, unfortunately. It really depends on your scenario.
Generating keys exclusively in (non-backup-able) secure
hardware is great if your scenario readily supports multiple
keys per server/domain you're authenticating in.
Creating an airgapped backup and loading that into a "daily
driver" Yubikey marked as non-exportable can be perfectly fine
if that's not the case and you don't want to notify the world
every time you're adding or retiring a new Yubikey (for reasons
other than key compromise).
johnisgood wrote 12 hours 27 min ago:
Depends on your use case, and you will still have to generate
your master key offline even if you want the subkeys generated
directly on each YubiKey, which then you sign with the master
key.
It is only slightly less secure if you pre-generate subkeys on
an offline machine if you want identical subkeys on multiple
devices (and if you want exact backups). Sometimes this is
exactly what people want.
Ultimately it really depends on your use case.
BTW, please check the parent comments to which I responded.
PS. I think it would be useful for others if you elaborated on
your statements (for educational purposes).
eptcyka wrote 13 hours 13 min ago:
You are talking about GPG keys. The featured article only refers
to SSH keys. Know the difference.
johnisgood wrote 12 hours 20 min ago:
I know the difference, thank you for your concern.
epistasis wrote 13 hours 54 min ago:
I can understand revocation for GPG, but is revocation ever used
for SSH? I could understand it if SSH certificates are used, but
honestly I've never encountered an org using SSH's cert system.
johnisgood wrote 13 hours 41 min ago:
Well, OpenSSH has a built-in key revocation mechanism (KRL
which is just SSH revocation), and there are SSH certificates
(with a CA) and certificate revocation, and there is ad-hoc
"revocation" by removing keys from the "authorized_keys" file.
If you use your GPG key for SSH, the servers that have your
public key do not automatically know that your GPG key was
revoked, and SSH authentication will proceed unless you remove
the public key from the server OR the server uses an SSH CA/KRL
model.
All in all, SSH supports real revocation, but it must be
enforced by the server. It is different from GPG where
revocation follows the key, not the server.
I have not used KRL myself, but I sort of know how it works.
You can generate a new empty KRL, then add keys to revoke, and
then to distribute the KRL to servers by configuring OpenSSH to
use the KRL file, by adding "RevokedKeys
/etc/ssh/revoked_keys.krl" to "/etc/ssh/sshd_config".
The pros of KRL is that they scale better than manual removal
for multiple servers, and you can revoke entire CA ranges
instead of individual keys if using SSH certificates which is
recommended for large setups.
I hope I could clear some things up. Let me know if you have
any questions though!
justincormack wrote 14 hours 13 min ago:
Correct. Set up multiple keys as backups. Thats also a positive, as
nothing can leak the key.
adastra22 wrote 14 hours 17 min ago:
Iâm a bit confused as to why you can export the keys. Can someone
explain this?
lloeki wrote 14 hours 14 min ago:
TFA:
> Note that the "private" key here is just a reference to the FIDO
credential. It does not contain any secret key material.
adastra22 wrote 14 hours 10 min ago:
Ah, ok, I missed that bit. Thank you!
cedws wrote 14 hours 28 min ago:
Secretive is a bit friendlier to set up but I'll probably switch to
this anyway so I have one less app on my computer.
Plugging my blog post for how to achieve this on Windows 11:
URI [1]: https://cedwards.xyz/tpm-backed-ssh-keys-on-windows-11/
smartbit wrote 13 hours 13 min ago:
Is storing ssh-key in tpm possible on Linux?
jeroenhd wrote 16 min ago:
Yes, it's about three to five commands and some configuration to
set it up:
URI [1]: https://www.ledger.com/blog/ssh-with-tpm
agartner wrote 12 hours 50 min ago:
[1] works well for me
URI [1]: https://github.com/Foxboron/ssh-tpm-agent
traceroute66 wrote 14 hours 33 min ago:
Awesome.
Won't be ditching Yubikeys just yet but I can see a number of use-cases
for this already.
redrove wrote 14 hours 39 min ago:
nvm
traceroute66 wrote 14 hours 30 min ago:
> Secretive has been around for a while, I don't see why it's coming
up now through this gist.
Because this is different !
Secretive required installation, which is both friction and
security-sensitive tool written by a third party.
This is native, written by Apple, available out-of-the-box in Tahoe.
simonw wrote 14 hours 32 min ago:
This Gist is about not needing to use Secretive any more.
epistasis wrote 14 hours 39 min ago:
Whoa, that is pretty cool.
I've been using Secretive for years, and prefer it to all the physical
key/card based systems I've tried to get going over the years. I know
exactly when my SSH key is used for any operation, because I need to
hit a button or do a fingerprint scan. I can keep ssh-agent tunnels to
remote boxes so that I can sign git commits remotely without having to
worry about a rogue system getting complete access to key ops without
me knowing what's going on.
However the Tahoe version of secretive is buggy and frequently locks up
on initial key op requests. I don't have the bandwidth to debug it and
file a bug report, and honesty I'm not sure I want to relearn all that
knowledge of SSH to figure it out.
I think the smart card SSH UX is worse than secretive's, IIRC my past
pain, but if it is reliable, worth a shot.
lxgr wrote 9 hours 3 min ago:
> I can keep ssh-agent tunnels to remote boxes so that I can sign git
commits remotely without having to worry about a rogue system getting
complete access to key ops without me knowing what's going on.
I also really like secretive, but at least this part is not exclusive
to it; OpenSSH's `ssh-agent` and `ssh-add` have long supported
confirmation of each private key use with `ssh-askpass` (although it
unfortunately can't distinguish between remote and local key uses).
greatgib wrote 14 hours 40 min ago:
It's a total pain in the ass to try to have password encrypted gpg or
ssh keys in mac. Nothing better that another way to make it even more
painful and complicated, so that people will just store plain text keys
to not be annoyed.
tiltowait wrote 13 hours 17 min ago:
I've used password-encrypted keys on a Mac plenty of times. It was
easy to add them to the SSH agent to not require a password after
initial authorization, if that's what I wanted. What is the issue I'm
not seeing?
newsoftheday wrote 14 hours 13 min ago:
> It's a total pain in the ass to try to have password encrypted gpg
or ssh keys in mac
I'm anti-Mac but for the year recently that I had to use one at work,
no choice...I had no issues, none, using gpg or using a passphrase on
my ssh keys.
manuelabeledo wrote 14 hours 24 min ago:
This looks like the complete opposite, though? Itâs easy and
provides a convenient way to integrate SSH and TouchID.
traceroute66 wrote 14 hours 27 min ago:
> It's a total pain in the ass to try to have password encrypted gpg
or ssh keys in mac.
Who uses password encrypted keys anyway ? No exfiltration
protection, and a sitting duck for unlimited automated password
guessing attempts.
Pre-Tahoe people used Yubikeys or Secretive. But now this native
tool is a better option than Secretive, even if Yubikeys still have
their uses for the power-users.
fpoling wrote 13 hours 28 min ago:
With an ssh agent and time-bounded key expiration one can have very
strong password on the key that is convenient to use.
Also password managers like 1password or Bitwarden support
ssh-agent protocol so one can have a master password that protects
both stored passwords and keys.
johncolanduoni wrote 8 hours 14 min ago:
How short of a time-bound do you use on your SSH keys?
fpoling wrote 6 hours 9 min ago:
It is set to 15 minutes due to specifics of automation scripts
that we use so they can run uninterrupted.
newsoftheday wrote 14 hours 16 min ago:
> Who uses password encrypted keys anyway ?
Edit: I'm not suggesting an ssh key with a passphrase (or password)
is better than what the article suggests; I'm only saying that
adding a passphrase (or password) to an ssh key at least buys time
to address the situation while the attacker is trying to break the
encryption on the stolen key.
I am anti-Mac in every way, but I do use passphrase protected ssh
keys so if someone were to get a copy of my ssh key, they would
have to be able to break the encryption to use the key. I see a lot
of devs using blank passphrases on their ssh keys, smh.
> sitting duck for unlimited automated password guessing attempts.
Using a passphrase on your ssh key has nothing to do with whether
the ssh service is configured to allow or deny passwords.
Xylakant wrote 14 hours 9 min ago:
The parent means that an attacker has unlimited attempts at
breaking the passphrase on an exfiltrated key. Once the key
passphrase is broken, they can log in using the key.
newsoftheday wrote 14 hours 7 min ago:
Right, but my context is that devs often use no passsphrase at
all. If someone can get a copy, they have instant access to
whatever it has access to.
lloeki wrote 14 hours 11 min ago:
> whether the ssh service is configured to allow or deny
passwords.
Given the consistent use of "password" instead of "passphrase", I
think they meant an exfil'ed encrypted key is vulnerable to
no-rate-limit bruteforcing, in contrast with hardware-backed
keys.
newsoftheday wrote 14 hours 5 min ago:
Right, but my context is that devs often use no passsphrase at
all. If someone can get a copy, they have instant access to
whatever it has access to. They don't need to even break
encryption since the key has none if none has been applied. My
stance is simply, at least add a passphrase to the key (though
some call it a password).
lloeki wrote 13 hours 56 min ago:
gotcha, thanks for clarifying!
DIR <- back to front page