Yubico with new 4096-bit keys and gpg-agent for ssh authentication(trmm.net)
trmm.net
Yubico with new 4096-bit keys and gpg-agent for ssh authentication
https://trmm.net/Yubikey
50 comments
That looks very nice, but it's rather more expensive than the Yubikey. The latter has NFC+U2F in a stick costing $50, whereas the former costs $50 for a stick that has neither.
What’s the use case for NFC?
Using PGP on your smartphone without giving it access to your PGP key - https://grepular.com/An_NFC_PGP_SmartCard_For_Android - That's how I use it anyway.
For usage with mobile applications, where NFC is typically available but USB Host is not, I would imagine.
On Android, you typically have USB host (at least on any phone that someone interested in this tech would buy). On iOS it's moot since NFC is gimped and can't be used by apps.
Most people don't carry the necessary cable around with them, though. NFC doesn't require any additional hardware.
I use it for generating 2FA codes, Yubico Authenticator works like Google Authenticator except that it requires touching the YubiKey to the phone before it shows the 2FA codes. The codes are computed on the YubiKey: https://github.com/Yubico/yubioath-android/blob/63387c02a39b...
I use it for generating 2FA codes, Yubico Authenticator works like Google Authenticator except that it requires touching the YubiKey to the phone before it shows the 2FA codes. The codes are computed on the YubiKey: https://github.com/Yubico/yubioath-android/blob/63387c02a39b...
My colleague Guillaume Destuynder wrote that blog post. We still use CryptoSticks at Mozilla, with sops[1] to securely store backup keys of some of our secrets files.
[1] https://github.com/mozilla/sops
[1] https://github.com/mozilla/sops
This looks really neat. Anyone also use these? Thoughts? I might get myself one.
Edit: Also, does this have gpg-agent / ssh support?
Edit: Also, does this have gpg-agent / ssh support?
I tried the pro model but went back to the FST-01 as it was too slow for RSA 4096 and doesn't support curve25519 for sign/auth.
But, yes, it does work with gpg-agent with ssh support.
But, yes, it does work with gpg-agent with ssh support.
Can confirm what bruo said. I use my Yubikey Neo with gpg-agent with "--enable-ssh-support" enabled for ssh agent support.
May I offer my article on an excellent password manager complementing the Yubico devices well? https://drupalwatchdog.com/blog/2015/6/yubikey-neo-and-bette...
Is there any way to store an ssh server key in it, or an https server's key? Basically turning this into a mini-HSM ?
Sure! There are a lot of ways you can do this. One is to use PIV mode, which exposes a PKCS#11 interface that can be used by OpenSSL. Yubico has some nice docs on using a Yubikey as an HSM to store CA keys: https://developers.yubico.com/yubico-piv-tool/Certificate_Au...
Note that (at least in the method described in that document), the Yubikey does not _generate_ the private key, it merely stores it securely. You need to generate it on a computer, which should preferably be a brand new laptop, airgapped, purchased from a physical store and not online (continue to layer defenses up to your desired level of paranoia).
Note that (at least in the method described in that document), the Yubikey does not _generate_ the private key, it merely stores it securely. You need to generate it on a computer, which should preferably be a brand new laptop, airgapped, purchased from a physical store and not online (continue to layer defenses up to your desired level of paranoia).
Actually, in PIV mode it's my understanding that you can have the Yubikey generate the private key if you want it to.
Note that the key is intended to be difficult to extract from the device and there is not intended to be an interface for doing so.
If you are using it with RSA key, you need to decide if you trust that it is generating the key properly. Keep in mind Yubikeys are built on GlobalPlatform/JavaCard which is an extremely high value target. There would definitely be the economic incentive for a well-funded adversary to backdoor the RNG system.
If you are using a Yubikey with EC cryptography, the security analysis gets even more complicated. The curve used need to be a safe one.
And, if the RNG has been tampered with or incorrectly designed, EC signatures can actually leak the private key.
Which is to say that if there is a flaw in the Yubikey, JavaCard, GlobalPlatform, or the specific chips they are using, and you are either (A) having it generate the private RSA keys, or (B) using it with elliptic curves, then there is the potential that the device is not at all secure.
Note that backdooring crypto-specific chips is a thing. TPM and other special-purpose crypto chips have been discovered to have been both backdoored and vulnerable to implementation issues.
Which is completely unacceptable - "you had one job".
Note that the key is intended to be difficult to extract from the device and there is not intended to be an interface for doing so.
If you are using it with RSA key, you need to decide if you trust that it is generating the key properly. Keep in mind Yubikeys are built on GlobalPlatform/JavaCard which is an extremely high value target. There would definitely be the economic incentive for a well-funded adversary to backdoor the RNG system.
If you are using a Yubikey with EC cryptography, the security analysis gets even more complicated. The curve used need to be a safe one.
And, if the RNG has been tampered with or incorrectly designed, EC signatures can actually leak the private key.
Which is to say that if there is a flaw in the Yubikey, JavaCard, GlobalPlatform, or the specific chips they are using, and you are either (A) having it generate the private RSA keys, or (B) using it with elliptic curves, then there is the potential that the device is not at all secure.
Note that backdooring crypto-specific chips is a thing. TPM and other special-purpose crypto chips have been discovered to have been both backdoored and vulnerable to implementation issues.
Which is completely unacceptable - "you had one job".
You might want to look at the Nitrokey HSM. I'm using one for a project and I was blown away by the feature set for the cost (as compared with the SafeNet devices I originally looked at). Its signing throughput is too slow to run a website with any significant new connection volume, but for personal applications it could be made to work. As just an HSM I think they're a phenomenal value.
Yubico have a product specifically for that use case: https://www.yubico.com/products/yubihsm/
As best I can tell, the YubiHSM is basically only useful with their Yubico Validation Server for their proprietary 2FA solution.
My mistake, it doesn't appear to support that functionality. I'll have to look into it further.
There is also the non-insignificant issue of the $500 price tag. Wouldn't bat an eyelid if this was for professional/corporate use, but $500 out of my own pocket for my personal home server is a bit steep.
[deleted]
[deleted]
Just so it's clear, the previous Yubikey NEO also supports gpg-agent for SSH authentication, not just the new Yubikey 4. I've been using one for months. It presents a standard smarcard CCID interface and runs an OpenPGP applet.
The source to the actual Javacard applet that implements is available on Github: https://github.com/Yubico/ykneo-openpgp
The source to the actual Javacard applet that implements is available on Github: https://github.com/Yubico/ykneo-openpgp
Buy the one with smaller form factor. the device bends with very nominal pressure and if you are someone as me who works mostly on one device and need to move around a lot with it - unplugging and replugging the key is very cumbersome. You can leave the nano one in port and forget it until you need it in another device. My two cents from using a neo to store production ssh keys.
In the article it's written that the yubikey is tamper proof.
This is not the case. They report their product as tamper evident but not tamper proof.
This is not the case. They report their product as tamper evident but not tamper proof.
Offtopic question:
Is there any FDE software that supports keeping decryption keys on a network server? You would still need to enter user authentication to obtain the decryption key of course.
Use case: We are a HIPAA environment, I want a hard drive to be useless if it is removed from the building.
Is there any FDE software that supports keeping decryption keys on a network server? You would still need to enter user authentication to obtain the decryption key of course.
Use case: We are a HIPAA environment, I want a hard drive to be useless if it is removed from the building.
I recently solved this problem using StrongAuth. We used SED disks instead of FDE software.
http://keyappliance.strongauth.com/
http://keyappliance.strongauth.com/
We use Checkpoint where I work and I am almost certain it does key escrow.
for folks interested in more on yubikeys and gpg I also would suggest these two blog posts
http://viccuad.me/blog/secure-yourself-part-1-airgapped-comp...
http://blog.josefsson.org/2014/06/23/offline-gnupg-master-ke...
http://viccuad.me/blog/secure-yourself-part-1-airgapped-comp...
http://blog.josefsson.org/2014/06/23/offline-gnupg-master-ke...
Are the github keys they sold cheaply compatible with 4096 bit keys? I'm loathe to buy another, considering i've got 3 already...
As far as I'm aware, Yubikey 4 and Yubikey Nano 4 can do 4096; the older ones like the NEO can only do 2048.
Not that 2048 is flawed as such: it's still north of 100 bits workfactor at the moment, as far as I gather. 3072 would be equivalent to about 128 (similar to the EC algorithms secp256r1 or Curve25519), and 4096 is some extra insurance on top. (As a benchmark: Snowden used 4096-bit RSA keys for GnuPG.) Anything bigger than that could introduce OpenPGP compatibility troubles.
All of these are secure when correctly implemented. (Yubikey use NXP chips. I don't have much to say beyond that, I haven't audited them.) All of them will fall to Shor's algorithm on a quantum computer of sufficient size, but we're not likely to have one of those for a good few years, if they're possible.
Not that 2048 is flawed as such: it's still north of 100 bits workfactor at the moment, as far as I gather. 3072 would be equivalent to about 128 (similar to the EC algorithms secp256r1 or Curve25519), and 4096 is some extra insurance on top. (As a benchmark: Snowden used 4096-bit RSA keys for GnuPG.) Anything bigger than that could introduce OpenPGP compatibility troubles.
All of these are secure when correctly implemented. (Yubikey use NXP chips. I don't have much to say beyond that, I haven't audited them.) All of them will fall to Shor's algorithm on a quantum computer of sufficient size, but we're not likely to have one of those for a good few years, if they're possible.
I picked up two of the github keys. Never did get them working under OS X. Plug them in and nothing, not recognized by any of their tools, no new keyboard recognized prompt, nothing. Anyone else have trouble with them on OS X?
Does it light up when you try logging in or registering it with Github/Dropbox/Google in Chrome?
No, because the github / U2F keys don’t have any writeable local storage.
Looked at these last year but opted for smartcard and secure pinpad reader instead.
Can you provide links to what you chose instead?
I dunno about him, but I do something similar on one of my machines. I use an SCM SPR-532 USB reader with pinpad and an OpenPGP v2 smart card. More info and pictures here - https://grepular.com/Smart_Cards_and_SSH_Authentication
Where did you get the PGP card? Did you donate to become a fellow?
I've been thinking about it, but it's a bit confusing figuring out what cards are compatible and donating to the foundation is nice but a bit expensive.
I've been thinking about it, but it's a bit confusing figuring out what cards are compatible and donating to the foundation is nice but a bit expensive.
I got it from kernelconcepts as tokenizerrr said. They seem to have a newer version of the card now which does 4096, so I might have to buy another. Mine only does 2048
You can get them here: http://shop.kernelconcepts.de/
I'm surprised that more folks haven't just gone to 8,192-bit keys, out of an abundance of caution.
4,096 is already an abundance of caution. You might as well say people should go to 32,768 just to be sure. Then somebody else would come along and say, "why not 65,536?"
Indeed. Mostly, it's just a question of whether or not the software will support a key of such size. Typically, I would recommend that, unless you've a good reason to use a smaller key (like support concerns), one should use the biggest key one possibly can use at the time the key is generated. Though, if one is doing key rotation as one should be, one can always adjust up as needed as time goes on.
Not really, especially in the context of RSA keys, because:
1. RSA is a slow algorithm and gets slower as you increase the key size.
2. Increasing the key size gets diminishing returns on the security margin. Given the performance and compatibility issues, the relatively minor improvement in security once you go beyond a certain key size is not worth it (you should switch to a better algorithm instead).
3. Anything over 4096 (possibly anything over 3072) is overkill anyway - if you could break a 4096-bit RSA key, you've probably found a fundamental weakness in RSA that means you should move to a different algorithm entirely.
1. RSA is a slow algorithm and gets slower as you increase the key size.
2. Increasing the key size gets diminishing returns on the security margin. Given the performance and compatibility issues, the relatively minor improvement in security once you go beyond a certain key size is not worth it (you should switch to a better algorithm instead).
3. Anything over 4096 (possibly anything over 3072) is overkill anyway - if you could break a 4096-bit RSA key, you've probably found a fundamental weakness in RSA that means you should move to a different algorithm entirely.
all valid points.
I think the general consensus was not extending RSA key size, but using elliptic curves instead? (But NIST and Brainpool curves aren't completely trustworthy and Curve25519 is not yet standardized for OpenPGP, so we're practically stuck with RSA at the moment)
According to Werner Koch: [0]
"8192 bit keys are horrible insane from all POVs: There is no extra security because the security is based on the weakest link and this is definitely not the length of the RSA modulus, they make encryption really slow and thereby reducing the likeliness of widespread encryption use, they only help spreading FUD about the security of the RSA or other algorithms."
[0]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=137824#10
"8192 bit keys are horrible insane from all POVs: There is no extra security because the security is based on the weakest link and this is definitely not the length of the RSA modulus, they make encryption really slow and thereby reducing the likeliness of widespread encryption use, they only help spreading FUD about the security of the RSA or other algorithms."
[0]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=137824#10
> Encrypting by default is a good idea.
I suspect the author intended to say Signing by default is a good idea.
I suspect the author intended to say Signing by default is a good idea.
[1] https://www.nitrokey.com/
[2] https://blog.mozilla.org/security/2013/02/13/using-cryptosti...