[HN Gopher] Secretive - macOS native app to store SSH keys in th...
___________________________________________________________________
Secretive - macOS native app to store SSH keys in the Secure
Enclave
Author : guessmyname
Score : 132 points
Date : 2020-06-27 19:46 UTC (3 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| philistine wrote:
| Does this mean that the Secure Enclave is accessible by the user?
| If so, it prompts so many questions. How much disk space is
| available on the Enclave, for example.
| lunixbochs wrote:
| You don't actually need to store Secure Enclave protected data
| in the enclave. Can "wrap" it with the enclave's key and store
| it on your own disk.
| GekkePrutser wrote:
| This is not what it does though. It says the private key
| can't be exported, and this wouldn't be the case if it was
| just a regular SSH keyfile encrypted using the Enclave's key.
| acdha wrote:
| You can ask the Secure Enclave or a smart card to perform
| operations using a key pair which is generated on and never
| leaves the device. In the case of SSH, you can use that
| directly as long as your SSH client and server support that
| algorithm: the client advertises the key fingerprint and
| just passes the server's challenge through without
| modification. Apple has had native support built-in for
| using PIV/CAC tokens for years.
|
| For storing arbitrary sized things, you'd typically use
| that key pair to sign an AES key used to encrypt the actual
| file so your device only needs to store the comparatively
| small keys.
| dchest wrote:
| Unwrapping it puts the private key into memory, from which it
| can be extracted (it's hard, of course, but looking at the
| state of Intel security, everything is possible). Secure
| Enclave is supposed to sign with non-extractable private key
| without putting it into RAM.
| bdcravens wrote:
| Totally a tangent, but it's interesting that we still refer to
| things as "disk space" even in the era of flash storage
| philistine wrote:
| I know! But I wanted to write something very clear, and I
| chose the clearest word in my mind to convey my idea. That
| word is steeped in old tech, it so happens.
|
| Oh and by the way, I was shopping for a cheap laptop for a
| non-profit this week, and I still had to be careful to pick a
| laptop with an SSD. Those spinning horrors are still jammed
| into laptop cases to this day.
| epistasis wrote:
| I wonder what a better term for disk storage would be. Block
| storage, in the way that cloud services refer to it? Just
| plain "storage"?
| jbverschoor wrote:
| Non Volatile Memory
|
| Volatile Memory gets "erased" when powered off
| epistasis wrote:
| Accurate, and in usage in technical circles already. But
| I've always found it awkward, and names based on what
| something is not are always unsettling to me.
| jbverschoor wrote:
| Then just Memory. That's what elderly and nontechies
| usually call it. And it's correct. Even more correct with
| always-on-computing and automatic state saving
| saagarjha wrote:
| Wait until people confuse that with NVRAM.
| trasz wrote:
| "Stable storage", perhaps; I seem to remember the SMTP RFC
| uses that name.
| gumby wrote:
| In the old Multics papers it was just long term storage as
| there was no difference between segments in memory and on
| disk. Which we are finally starting to catch up with 50
| years later.
| smnrchrds wrote:
| That's how language works. We call people "engineers" who
| have never and will never work on any engines.
| dtorres wrote:
| "engineer" comes from ingenium (mind, talent) in Latin.
|
| Engineer in most latin languages would be a completely
| different word to Engine (usually Motor)
| ithkuil wrote:
| engineer
|
| /endZI'nI@/
|
| Origin:
|
| "Middle English (denoting a designer and constructor of
| fortifications and weapons; formerly also as ingineer ): in
| early use from Old French engigneor, from medieval Latin
| ingeniator, from ingeniare 'contrive, devise', from Latin
| ingenium (see engine); in later use from French ingenieur
| or Italian ingegnere, also based on Latin ingenium, with
| the ending influenced by -eer."
| techslave wrote:
| thanks for not saying 'begs'.
|
| no, the secure enclave is not available to the user as such. a
| few crypto primitives are exported. that's what this uses.
| there have been any number of such "agents" over the last few
| years.
| walterbell wrote:
| Could this be possible on iOS devices, which also have a secure
| enclave?
| alibert wrote:
| You could check https://krypt.co
|
| (not affiliated)
| m0dest wrote:
| Note that they were bought by Akamai last year. I wouldn't
| count on the Krypton apps staying around, at least not in
| their current incarnation. A fork could survive, though.
| walterbell wrote:
| Thanks, that reminded me of upcoming iOS 14 support for
| WebAuth/FIDO. Perhaps that can be extended to SSH auth.
| justincormack wrote:
| I have been using sekey for this for a while. Its pretty nice, I
| mean you do need to auth quite a bit if you use git clone over
| ssh a lot, but it does mean you know when keys are used.
| AlexCoventry wrote:
| Is a similar service available for yubikeys connected to linux
| machines?
| g_p wrote:
| Yes - as the other commenter mentioned there are some docs from
| Yubico. Also worth looking at PKCS11, as this lets you do HTTPS
| clent certificate authentication, as well as SSH. And it's all
| standardised too under the PKCS11 standard, which is nice for
| portability or diversity of token providers.
| vladvasiliu wrote:
| There is:
|
| https://www.esev.com/blog/post/2015-01-pgp-ssh-key-on-yubike...
|
| https://developers.yubico.com/PIV/Guides/SSH_with_PIV_and_PK...
|
| The yubikey (at least some models) can work as a smartcard.
| AlexCoventry wrote:
| Thanks.
| Metus wrote:
| For anyone not aware, you can use macOS's keychain to store ssh
| key passwords and have them unlock at login. This way you can
| have the benefits and convenience of password managers in the
| command line for SSH certificates.
|
| https://apple.stackexchange.com/questions/48502/how-can-i-pe...
| mfontani wrote:
| Does it have touch to authorise (doesn't seem to support that),
| or is it just going to send on all of one's currently-loaded
| SSH keys whenever one connects with -A (seems to)?
|
| > You can configure your key so that they require Touch ID (or
| Watch) authentication before they're accessed.
|
| That, to me, would be a key thing to want to have: something
| that tells me "hey, Terminal just wanted to access your Github
| key. Is that okay?"
|
| If I'm git pushing, that's fine. If I just connected to a
| random server... that's not okay. What is that trying to do?
| Deny.
| pqdbr wrote:
| From the FAQ:
|
| > Q: How do I import my current SSH keys, or export my Secretive
| Keys?
|
| > A: The secure enclave doesn't allow import or export of private
| keys. For any new computer, you should just create a new set of
| keys. If you're using a smart card, you might be able to export
| your private key from the vendor's software.
|
| I don't get it. If so, how am I supposed to back up my keys in
| case of a hardware failure or hardware theft?
| GekkePrutser wrote:
| Like the others have said: You just use multiple. You can just
| add multiple keys to the authorized_keys file.
|
| This is actually the perfect scenario because an attacker can
| never get hold of the private key. That means that the key is
| unique: If it's in your hands, it means an attacker doesn't
| have it. Most smart cards work this way, they generate the
| private key inside and it can never leave the hardware, you can
| only prove you have it by using it to sign or encrypt
| something.
|
| This is very different from SSH keyfiles on disk which can be
| stolen in many ways, and as such can be compromised without you
| ever knowing about it.
|
| It's really cool that we can now use this functionality for SSH
| too. I currently use Yubikeys in OpenPGP mode for this but I
| might switch to this once I get a T2-enabled Mac.
| jooize wrote:
| Is there a convenient way to manage and maintain those keys?
| Keeping the public key of each device and easily select which
| ones to place on servers.
| acdha wrote:
| In the case of SSH keys, when you export the key
| fingerprint you can edit the comment. I like the convention
| of email address & hostname to disambiguate the entries in
| a centrally-managed authorized keys list - when you get a
| new device, update the list and push the new version out.
| GekkePrutser wrote:
| Very good question. I've been thinking about a central way
| to manage keys. There doesn't really seem to be one, and it
| would be a big point of attack because an attacker might
| abuse it to add their own key.
|
| Right now what I do is I just log into my servers and copy
| the list :P I don't have that many anyway.
| pqdbr wrote:
| By "you just use multiple", you mean I would have to generate
| extra private keys, add them to authorized_keys, and store
| them somewhere other than my mac, right?
|
| Because just by using multiple keys I would still be locked
| out if all of them were stored in this 'Secretive' app.
| zymhan wrote:
| If you only have a single SSH key as the only method of
| authenticating somewhere, you already have a dangerous
| single point of failure.
| comex wrote:
| Not if you have multiple copies of the private key. But
| yes, there are advantages to having any given key only
| exist in one place.
| GekkePrutser wrote:
| Well, not exactly, I use multiple physical keys. Yubikeys
| and OpenPGP smartcards in my case. I use multiple different
| types too (the OpenPGP cards are quite cheap too).
| Metus wrote:
| You aren't. It is the same with Yubikeys, if you use them. You
| are supposed to generate a certificate per user and device they
| are using for authentication, which is not a big deal at least
| for remote login on servers, as you can set an arbitrary number
| of valid SSH keys.
| corty wrote:
| You are supposed, yes, but it is not necessary with Yubikeys.
| You can still import private keys into your Yubikey. At work
| we are using this for group access to some appliances that
| annoyingly limit the number of SSH authorized keys you can
| teach them.
| drewbug wrote:
| Keep a separate spare set of keys
| g_p wrote:
| For anyone interested in a standardised/Linux-compatible version
| of this, check out PKCS11 tokens. Smartcards can and do implement
| this spec, and if you use PKCS11, the secret is used from the
| token to sign an SSH login (for example), without being revealed.
|
| This means the secret itself stays on the card. You can combine
| this with certificates if needed; the smartcard handles the
| authentication. Using PKCS11 tokens is supported in recent
| openssh versions. You can also use them for client certificate
| authentication in web browsers. For anyone familiar with DoD
| CACs, this is similar - I believe they use a particular card with
| a proprietary PKCS11 driver, but you can use opensc with any card
| running a PKCS11 applet.
|
| Some refs:
|
| https://zerowidthjoiner.net/2019/01/12/using-ssh-public-key-...
|
| https://developers.yubico.com/PIV/Guides/SSH_with_PIV_and_PK...
| krrrh wrote:
| A similar product that works on macs without a secure enclave by
| storing keys on the secure enclave of your iPhone is krypton.
|
| https://krypt.co/developers/
| fehyjn wrote:
| Is is possible to recreate this using Windows Hello and TPM?
| vdfs wrote:
| > Auditable Build Process
|
| > Builds are produced by GitHub Actions with an auditable build
| and release generation process. Each build has a "Document SHAs"
| step, which will output SHA checksums for the build produced by
| the GitHub Action, so you can verify that the source code for a
| given build corresponds to any given release
|
| What will stop an attacker from hard coding code source file
| hashes? I'm not saying they will, just that it's a bad method of
| making binaries auditable
| gruez wrote:
| Nothing. The point is that you can replicate the same steps on
| your local machine and the hashes should be the same. If
| they're not it means either github actions and/or the repo
| owner has been compromised.
___________________________________________________________________
(page generated 2020-06-27 23:00 UTC)