I recently wrote a different application for YubiKeys - using the YKOATH functionality to sign AWS API requests with HMAC-SHA256 (https://github.com/pyauth/exile). What I found is that Yubikey's protocol documentation is good, but their tools are pretty bad, and none of them should be used. Instead, I recommend talking to the smartcard interface through the lowest level library that's already bundled with the major OSs - winscard/pcsclite/PCSC.framework (three implementations all providing the same API).
I should add, there are other YubiKey modes (like U2F) that use the USB HID protocol instead of the USB PCSC protocol. For those, someone at Google wrote this library: https://github.com/google/pyu2f which provides similar capabilities for HID-based protocols. It similarly interfaces directly with the system-provided HID API using ctypes.
Seconded. It's absolute pain, have to look it up every time I need it (i.e. new computer) but between times it's zero maintenance, and great.
On occasion I've un/re-plugged to convince myself that it really is secured. (I do use a passphrase too, but I've already entered it in a given session I can git/ssh/etc. even to new remotes without re-entering it. I don't think that's configurable to be per-remote, since I've unlocked the 'card' (yubikey) for that session.)
> Hopefully these will be useful to others writing Yubikey-based applications.
Definitely! HMAC-SHA256 is nice and I was wondering if the TOTP feature of Yubikeys can be (ab)used for anything else that also uses HMAC-SHA256 (e.g. Macaroons).
Could you expand a bit more on the threat model that exile targets? Checking out the workflow, my naive concern is that it seems to make physical possession of the yubikey the sole requirement to use the secret key (well, possession + noticing that there’s an AWS key stored in the OATH slot).
Considering the “normal” threat model for AWS IAM keys, where the keys are stored in ~/.aws/credentials, they’re vulnerable to: (1) malicious/compromised apps/scripts on the local workstation, (2) theft of the laptop if it’s unlocked/decrypted. Moving the keys seems to solve (1), but degrades (2) by making it “theft of the yubikey”.
I’ve seen other systems that move the AWS secret keys to the OS keychain (for example https://github.com/99designs/aws-vault ), which seem to harden against (1) without weakening (2).
Is there a mitigation I’m not taking into consideration?
1. YubiKey's OATH application can be protected with a password. If you can't unlock the YubiKey with a password, you can't access any OTPs (or "OTPs" in exile, where they're being used as HMAC keys instead). (Granted, exile does not directly integrate with this yet, nor even mention it - thanks to you, I'll add it to the readme ASAP)
2. The YubiKey is an HSM, which means it can't be duplicated. As soon as you find your laptop/keychain stolen (which is much easier than detecting that the contents of your home directory have been copied) you can revoke the AWS API keys.
3. I consider a hack and theft of my home directory contents to be more likely than physical theft of my YubiKey (which I believe for most people is either permanently inserted into their laptop, or on a physical keychain). This risk calculus may be different for you.
4. As you point out, the attacker would need to know how to make use of this (as yet) fairly obscure use of the YubiKey.
This can't work technically without a new SSH auth method.
The SSH public key auth method goes like this:
1. Client "I want to do SSH public key auth. I can prove I know the corresponding private key for key X"
2. Server (typically checks authorized_keys file to decide) may say "OK, yes, prove that"
3. Client signs per session data with key to prove possession [it may use the proxy technology to have this done by a different client].
But a FIDO2 / CTAP key needs things to go the other way around
1. Client "I want to try FIDO2"
2. Server "OK, here is a Cookie. Can you prove you know the associated private key?"
3. Client uses CTAP protocol to verify that the Yubikey recognises this cookie and gets back a proof, sends it to server.
In the current world SSH clients know which keys they know, so they can begin by telling the server, but in the FIDO world the Security Key is deliberately too dumb to even know this, it has to be prompted with a cookie.
This is because of a correlation attack [edit: maybe that's the wrong word? The attack is a bad guy figures out who you are based on seeing you connect with this key in many places], which was not considered a big threat for SSH but is clearly a problem on the Web. So FIDO SecurityKeys are engineered to resist correlation by being so dumb that even they don't know if they know your Facebook keys, until Facebook says "Hi, do you know the keys that go with this cookie?" when you try to log in as you.
You can somewhat defend against correlation attack in SSH if it worries you by the way, by explicitly configuring a particular public key for each connection and forbidding the client from trying other keys (which it will by default) using IdentitiesOnly and IdentityFile in OpenSSH.
SSH supports multiple methods of authentication, including challenge-response authentication, which is specifically designed for the kind of exchange that FIDO2/CTAP uses.
Blergh. RFC 4256, which I'd guess is what you're thinking about, aka keyboard-interactive - is completely unsuitable for this purpose and certainly wasn't "specifically designed" for it.
In fact RFC 4256 pretty much spells out what it's for, it lets you use PAM to augment your authentication policies by changing what the remote user types into their console. You can add a One Time Password check or whatever.
It is full of requirements like "A command line interface (CLI) client SHOULD print the name and instruction (if non-empty), adding newlines" which have nothing whatsoever to do with the actual problem for Security Keys.
Of course you could _add_ a new SSH authentication method, but the existing RFC 4256 "challenge-response" approach is completely inappropriate.
The app I wrote includes Python ctypes bindings for all three implementations (https://github.com/pyauth/exile/tree/master/exile/scard, and https://github.com/pyauth/exile/blob/master/exile/ykoath contains an example of how to use them). Hopefully these will be useful to others writing YubiKey-based applications.
I should add, there are other YubiKey modes (like U2F) that use the USB HID protocol instead of the USB PCSC protocol. For those, someone at Google wrote this library: https://github.com/google/pyu2f which provides similar capabilities for HID-based protocols. It similarly interfaces directly with the system-provided HID API using ctypes.