
Guide to Using YubiKey as a SmartCard for GPG and SSH - vuln
https://github.com/drduh/YubiKey-Guide
======
EngineerBetter
One of our engineers, Paddy Steed, wrote a series of articles on how we each
use a Yubikey for SSH, UTF 2FA, and access to 1Password on shared machines
when we pair-program. The SSH key is generated on the Yubikey, so it never
touches your machine's filesystem.

[http://www.engineerbetter.com/blog/yubikey-all-the-
things/](http://www.engineerbetter.com/blog/yubikey-all-the-things/)

[http://www.engineerbetter.com/blog/yubikey-
ssh/](http://www.engineerbetter.com/blog/yubikey-ssh/)

[http://www.engineerbetter.com/blog/yubikey-static-
secret/](http://www.engineerbetter.com/blog/yubikey-static-secret/)

[http://www.engineerbetter.com/blog/yubikey-2fa/](http://www.engineerbetter.com/blog/yubikey-2fa/)

~~~
OJFord
> The SSH key is generated on the Yubikey,

Then FYI you should check, if you haven't already, the version of yubikey you
have and replace it if necessary:

[https://www.yubico.com/2017/10/infineon-rsa-key-
generation-i...](https://www.yubico.com/2017/10/infineon-rsa-key-generation-
issue/)

~~~
als0
This flaw only affected generated RSA keys, ECC keys should still be OK.
Yubikey provided an excellent service for replacing their products when I went
through them. However, I hear the story is quite different if you bought one
via Amazon.

~~~
OJFord
> This flaw only affected generated RSA keys,

And only those of 2048b or fewer.

> Yubikey provided an excellent service for replacing their products when I
> went through them. However, I hear the story is quite different if you
> bought one via Amazon.

I bought from Amazon; requested a replacement directly, great service as you
say, it didn't matter where I'd bought it originally.

------
captn3m0
To add to this, couple of good guides on using GPG Agent forwarding:

\- [https://blog.flameeyes.eu/2016/10/gnupg-agent-forwarding-
wit...](https://blog.flameeyes.eu/2016/10/gnupg-agent-forwarding-with-openpgp-
cards/)

\-
[https://www.isi.edu/~calvin/gpgagent.htm](https://www.isi.edu/~calvin/gpgagent.htm)
(Mac OS)

I broke my head recently trying to get this to work recently. The error was in
2 different gpg binaries that ubuntu ships with. Using gpg2 instead of gpg
gets it working.

------
DINKDINK
Other guides and discussion:

[https://rnorth.org/gpg-and-ssh-with-yubikey-for-mac](https://rnorth.org/gpg-
and-ssh-with-yubikey-for-mac)

[https://news.ycombinator.com/item?id=16145586](https://news.ycombinator.com/item?id=16145586)

[https://malcolmsparks.com/posts/yubikey-
gpg.html](https://malcolmsparks.com/posts/yubikey-gpg.html)

[https://spin.atomicobject.com/2014/02/09/gnupg-openpgp-
smart...](https://spin.atomicobject.com/2014/02/09/gnupg-openpgp-smartcard/)

[https://wiki.archlinux.org/index.php/GnuPG#Encrypt_and_decry...](https://wiki.archlinux.org/index.php/GnuPG#Encrypt_and_decrypt)

[https://www.jfry.me/articles/2015/gpg-
smartcard/](https://www.jfry.me/articles/2015/gpg-smartcard/)

[https://www.yubico.com/support/knowledge-
base/categories/art...](https://www.yubico.com/support/knowledge-
base/categories/articles/use-yubikey-openpgp/)

------
dkhenry
I have this exact setup working with a Yubikey and was a very happy user until
I upgraded my mac to HighSierra, it would appear with the new native PIV
integration with OSX that the yubikey is hogged by the OS and gpg can't get
access to read it as a smart card. Every attempt to read it is greeted with

``` gpg: selecting openpgp failed: Operation not supported by device gpg:
OpenPGP card not available: Operation not supported by device ```

and the only solution I found was to remove OSX and replace it with linux
which is now working again.

~~~
goerz
I haven't updated to High Sierra, but this would be very worrying. Can other
people confirm whether or not a Yubikey is working for gpg on High Sierra?

I did find this: [https://www.yubico.com/support/knowledge-
base/categories/art...](https://www.yubico.com/support/knowledge-
base/categories/articles/how-to-use-your-yubikey-with-macos-sierra/)

------
jbboehr
Here are also some guides for instructions specific to NixOS [1] and Windows
[2].

[1] [https://rzetterberg.github.io/yubikey-gpg-
nixos.html](https://rzetterberg.github.io/yubikey-gpg-nixos.html)

[2]
[https://developers.yubico.com/PGP/SSH_authentication/Windows...](https://developers.yubico.com/PGP/SSH_authentication/Windows.html)

------
sonaltr
This is cool!

A few weeks ago I found out about Bloomberg BUnit 4[0] (I was looking at their
keyboards and got distracted).

I think we need something similar for consumers (as in, I don't want to end up
spending 24k for a terminal just for a BUnit).

Basically it's a device that has a light sensor, a fingerprint reader and a
code generator - all used to authenticate the user to Bloomberg services.

The closest I've gotten is using something like Trezor[1] or Ledger S Nano[2]
(no fingerprint reader/light sensor - but it's protected via a passcode).

It's just one more level of protection on top of a hardware key (username +
password + hardware key (protected by a password))

[0]
[https://www.bloomberg.com/professional/support/b-unit/](https://www.bloomberg.com/professional/support/b-unit/)

[1] [https://preorder.trezor.io/](https://preorder.trezor.io/) (the model T)

[2] [https://www.ledgerwallet.com/products/ledger-
nano-s](https://www.ledgerwallet.com/products/ledger-nano-s)

------
sowbug
If someone can confirm that non-RSA (ECC, any curve) keys work with this or
any guide, I'd appreciate hearing it. As far as I can tell, ECC silently and
inexplicably fails at the ssh step. RSA seems to work fine.

This is Ubuntu 16.04, which comes with GnuPG 2.1.11.

~~~
subway
No. You need a token running an OpenPGP Card 3.0+ applet for ECC. The Yubikey,
while capable of doing ECC in other applets (like the PIV applet) only
implements OpenPGP Card 2.1 (maybe 2.2?).

Ledger did an OpenPGP Card 3.0 implementation that looks interesting, though
the token is pricey: [https://github.com/LedgerHQ/blue-app-openpgp-
card](https://github.com/LedgerHQ/blue-app-openpgp-card)

~~~
danieldk
An additional data point:

Some gnuk tokens, such as the Nitrokey Start support Curve25519, also for SSH
authentication (I use this). Of course, gnuk tokens have a different set of
trade-offs:

\- In contrast to Yubikeys, the firmware is open source and can be verified.

\- It uses a curve that is considered safe [1]. Some security experts don't
trust the NIST curves.

\- In contrast to the Yubikey, it does not use tamper-resistant storage, but
just a regular microcontroller. AFAIK it does store the keys encrypted though.

\- There is no physical confirmation for key use, only PIN confirmation (with
a maximum number of tries).

However, gnuk keys are very affordable. E.g. I purchased my Nitrokeys for 29
Euro each.

A completely different approach is to use your phone (and its secure element)
as a crypto token. E.g. using Krypton [2]. Of course, this is only viable if
you trust your phone manufacturer and operating system.

[1] [https://safecurves.cr.yp.to](https://safecurves.cr.yp.to)

[2] [https://krypt.co](https://krypt.co)

~~~
sowbug
Which version of GnuPG are you using?

(BTW re "AFAIK it does store the keys encrypted though," I'd be cautious about
relying on that encryption. The keyspace for PINs is tiny and trivially brute-
forceable. And if you choose to use a strong passphrase for your Gnuk token
that _is_ capable of resisting brute force, you're giving up one of the main
usability benefits of committing a secret to a hardware token. I know they're
working on something called KDF-DO that might offload key stretching to the
host, but it's still going to be the case that PINs will be brute-forceable.)

~~~
danieldk
_Which version of GnuPG are you using?_

Version 2.2.5.

 _The keyspace for PINs is tiny and trivially brute-forceable._

Good point!

~~~
sowbug
Confirmed that 2.2.5 on Ubuntu 16.04 works with NIST P-256 for SSH
authentication.

For future reference, installing GnuPG 2.2.5 turned out to be easier than I
expected. I visited
[http://http.us.debian.org/debian/pool/main/g/gnupg2/](http://http.us.debian.org/debian/pool/main/g/gnupg2/),
downloaded the .deb I wanted, tried installing with dpkg -i, and then
downloaded further dependencies until it worked.

Last time I tried, I built GnuPG from source, which ended up with something
that mostly worked, but it failed my personal sysadmin test of being able to
remember how I did it in case I needed to build a new machine with the same
characteristics.

------
linker3000
Has anyone used Yubikeys in conjunction with Ansible for deploying and
maintaining cloud-based server fleets? I'd love some tips on handling the
authentication; we'e had a brief foray into the matter, but never found a
wholly ideal solution.

~~~
jopsen
Put your key in KMS or something and use yubikey to control access...

Ideally, you don't deployments manually anyways.

------
znpy
Could someone point a broader, general introduction to this topic? I often
would like to adopt this technologies, but i always get stuck because I do not
feel confident in adopting technologies that I do not fully understand.

------
rendaw
As an awesome alternative you can use a Trezor (or KeepKey) with
[https://github.com/romanz/trezor-agent](https://github.com/romanz/trezor-
agent) for GPG and SSH. Unlike the YubiKey, with the Trezor you have have to
enter a scrambled numeric PIN to use it.

------
Dowwie
This work seems as if it could be extended to support a Nitrokey in addition
to Yubikey. Thoughts?

------
Corrado
The last time I tried to set up my YubiKey Nano for SmartCard access the
indicator light flashed incessantly. There is no option to turn it off and it
is very distracting.

Has anyone else had this experience? Is it possible to turn the flashing off?

------
craftyguy
any guides for using a non-proprietary piece of hardware?

~~~
justinjlynn
many, however, effectively all of the smartcard hardware implementations are
proprietary. The most open one I can think of is the OpenPGP card which is
PC/SC standard compatible. It's sold by Free Software Foundation Europe and is
colloquially known as the "foundation" card. However, while the applet source
that runs on the Java card is available, I don't know about the firmware or
runtime libreness.

It's be really great to have an auditable open source processor/soc design
with PC/SC compatible interface and secure enclave implemented in an ISO
standard smartcard form factor. Alas, to my knowledge nothing like that
exists.

Yubikey designs used to be a lot more open than they are currently (you used
to be able to run your own applets, IIRC - with some security compromises, of
course). That said, I would still personally use them for non-critical things
- it's a really handy form factor.

~~~
icebraining
_It 's sold by Free Software Foundation Europe_

Not anymore!
[https://fsfe.org/news/2017/news-20171116-01.en.html](https://fsfe.org/news/2017/news-20171116-01.en.html)

I was surprised, since I still received it, seems like I was one of the last.
I feel like a five-digit /. user :)

------
apas
Can someone ELI5 why Yubikeys are better for 2FA than using, say, 1Password,
which simplifies the process with cmd + \ and automatically pasting the 2F
code? (Even better than Google Authenticator; no need to reach for anything.)

~~~
arachnids
Using 1Password to store your 2fA seed makes it single factor because your
password and second factor are stored in the same place. This is not a good
idea.

Yubikeys in U2F mode are better than any OTP because they protect you against
phishing attacks. 1Password auto-filling arguably has this property too, but
you should disable that sort of password manager behavior:

[https://labs.detectify.com/2016/07/27/how-i-made-lastpass-
gi...](https://labs.detectify.com/2016/07/27/how-i-made-lastpass-give-me-all-
your-passwords/)

~~~
danieldk
_Yubikeys in U2F mode are better than any OTP because they protect you against
phishing attacks. 1Password auto-filling arguably has this property too,_

Not really. The TOTP RFC recommends accepting TOTP tokens from before and
after the current time step to make TOTP work with clock drift. Since most
implementations use time steps of 30 seconds an allow TOTP codes of at least
one past and one future time step, the window in which an TOTP code can be
used is typically 90 seconds.

Consequently, TOTP only works against 'offline phishing' where a phisher
collects data first and tries to take over the accounts later. For any kind of
immediate phising, there is typically no problem to forward re-use the token,
even with a small delay.

As you say, U2F protects against this, by using challenge-reponse and using
the origin selecting the key handle.

~~~
rthille
I don't understand the start-off of "not really". Is that in reference to the
first sentence or the 2nd? I think the "1Password-autofill" protects you
against phishing because if you go to a legit site, the domain will match and
1Password will autofill. If you go to a phishing site that just looks right
(Unicode domain, whatever), but doesn't match exactly then the auto-fill won't
happen and you'll be tipped off.

