Ben Cartwright-Cox has written a blog post about building Yubikey/Smartcard backed TLS/HTTPS servers. Cryptographic hardware tokens such as the Yubikey can hold and verify keys but are set up not to be able to give the key itself back to the system. Although the hardware token's contents can be overwritten, the original key cannot be extracted even if the system it is on gets cracked. Thus moving the keys to the hardware token would make them more or less unstealable. Ben walks through the steps necessary to retrofit a Yubikey to provide for situations roles where keys would normally be in memory such as for an HTTPS server.
A Yubikey is a USB stick that acts like a two factor token, but can also act as a smart card.
Smart cards are neat, since they allow you to store sensitive cryptographic keys on another removable device, and they come with a guarantee that once they are programmed with a key they will not give it back to a system (they can be overwritten though)
This allows someone to separate a cryptographic key from the system it lives on. This is useful for things like SSH, since it means you can have a key that moves on your person, rather than a per machine key in the case that you use multiple machines to access systems.
(Score: 1, Funny) by Anonymous Coward on Monday May 21 2018, @10:05PM (3 children)
Just download a TLS/HTTPS gem for Ruby on Rails and you're done... no hardware necessary, grandpa!
(Score: 2, Touché) by Anonymous Coward on Monday May 21 2018, @10:18PM (1 child)
I fail to see how your proposed action solves the problem of millennials or what this has to do with the article?
(Score: 0) by Anonymous Coward on Tuesday May 22 2018, @08:44AM
I think it's pointing out that for a certain group of IT people (apparently called "millenials"), the answer always seems to be to download something written by other people, without reading the question and without caring about whether the "solution" actually works, as long as it looks like it works.
See 90% of Stackoverflow answers. E.g. someone asking for help with a CSS problem that can be solved with one line of CSS, the first several answers all start out with downloading jQuery. If you're lucky, one person actually posted the one line of CSS that answers the question, but in that case the next post is likely to be that it's not possible to solve.
(Score: 1, Informative) by Anonymous Coward on Tuesday May 22 2018, @09:03AM
(Score: 3, Interesting) by Fnord666 on Monday May 21 2018, @11:08PM (11 children)
(Score: 0) by Anonymous Coward on Monday May 21 2018, @11:28PM (2 children)
>How about if I can't retrieve the private key from the YubiKey, how do I set up the other 665 servers in my web server farm to use the same server certificate?
Easy, get 665 other yubikeys that you set to the same key.
(Score: 3, Funny) by LoRdTAW on Monday May 21 2018, @11:29PM
yubikey marketing department must be the b team.
(Score: 2) by qzm on Tuesday May 22 2018, @09:43AM
Right....... and how do I get the cloud server provider to have those plugged in to my VPS's?
(Score: 4, Funny) by LoRdTAW on Monday May 21 2018, @11:29PM
Duh! It's the web! You like build a framework from ten other frameworks using javascript and stuff.
(Score: 3, Informative) by Knowledge Troll on Monday May 21 2018, @11:34PM
I want to tell that guy to get the hell off my lawn too but I don't think your gripe is legitimate.
You can also load certs into the Yubikey and it still won't let them back out. So what's wrong with this?
(Score: 4, Funny) by driverless on Monday May 21 2018, @11:38PM (1 child)
I'm not absolutely certain, but I think it might involve MongoDB.
(Score: 0) by Anonymous Coward on Tuesday May 22 2018, @12:18PM
Yubikey is webscale.
(Score: 4, Interesting) by forkazoo on Tuesday May 22 2018, @04:27AM
If you can program any cert onto the Yubikey, you'd probably generate it elsewhere and then program it onto multiple keys. So you could do the secure provisioning at the main office, and ship a small box of dongles to the remote site with the data center where you can hire a moderately trusted on-site team to do the physical deploy of the servers.
(Score: 2, Interesting) by Anonymous Coward on Tuesday May 22 2018, @09:22AM (1 child)
You place a machine with the Yubikey in a secure enclave of your network, and have the rest of the machines in your server farm try to communicate to it only when they need to use the private key to do anything, like initiate a TLS connection. The private key is only really required for initiating and negotiating new connections, and that’s really the only bottleneck. So you don’t actually need 665 more Yubikeys, just enough that you can mitigate the connection negotiation bottleneck sufficiently for your load. You could set up the machine(s) with a smartcard to run USBIP [sourceforge.net] and run them over a VPN for added security.
(Score: 1) by nitehawk214 on Tuesday May 22 2018, @04:59PM
Serious question, I am not a security professional. What is the point of having yubikey in this scenario if you have to isolate a server anyhow?
"Don't you ever miss the days when you used to be nostalgic?" -Loiosh
(Score: 2) by fraxinus-tree on Tuesday May 22 2018, @03:14PM
The scalability nightmare of this "solution" starts long before that. YubiKey cannot sign something more than, say, 3 or 10 times a second. This is the rate you will get for new TLS sessions. Hardly a server solution.
(Score: 5, Interesting) by Knowledge Troll on Monday May 21 2018, @11:38PM (3 children)
YubiHSM - hardware security module providing root of trust for servers and computing devices [yubico.com]
One thing that the author really missed is that OpenSSL can interface with a smart card via PKCS#11. What I haven not yet seen is an OpenSSL based web server setup to do that. I suspect the reason is that in the real world the Yubikey isn't fast enough to handle the load of a real web server.
The HSM has a shot though because it can do 16 simultaneous crypto sessions instead of the Yubikey single one.
(Score: 2) by darkfeline on Monday May 21 2018, @11:51PM (2 children)
Yes, this is the sane solution. Having the signing module stored in a secure enclave gives you roughly comparable security and doesn't require you to set up hundreds of hardware keys for a fleet of servers as suggested in another comment. The certs still live on a single machine, you only need to pass a signing request to the signer, and you can revoke certs that are compromised. This is also ignoring the fact that SSL/TLS on a Yubikey is probably a few orders of magnitude slower than on a real server, so not only are you locking yourself to a single machine server, but you can't even use the powerful CPU on that machine for TLS. The number of requests you could serve would be horrible.
To be fair, it's a cool hack, but completely impractical.
Join the SDF Public Access UNIX System today!
(Score: 5, Informative) by Knowledge Troll on Monday May 21 2018, @11:59PM (1 child)
That's not true. PKCS#1 does not require the user to pass all the data into the smartcard - it will do something like sign a digest or perform a single RSA decryption. RSA is too slow to use in the general case anyway, even with our modern CPUs, so TLS is based around using RSA operations only at the start and normal symmetric cipher operations after. PKCS#1 has nothing to do with a symmetric cipher.
The bottleneck would come in connection establishment and SSL negotiation - that's where work on the cert and private key happens. After that the CPU takes the load for symmetric encryption.
(Score: 2) by Fnord666 on Tuesday May 22 2018, @12:13PM
You are correct. An actual HSM such as the YubiHSM2 is much closer to a proper solution although I highly doubt it has been audited or meets PCI-HSM [pcisecuritystandards.org] certification requirements. It also adds an order of magnitude to the cost ($650 US v. $50 US) and probably puts it out of most people's "cool hack, I want to try that this weekend" budget.
In the end this was a cool hack that has a somewhat low cost to replicate but should not be used in any sort of production environment.
(Score: 3, Insightful) by ElizabethGreene on Tuesday May 22 2018, @02:09PM (3 children)
If you didn't need to move the certificate from one system to another then generating it from and storing it in the TPM may be a better option. That's one of the things it's built to do.
(Score: 2) by fraxinus-tree on Tuesday May 22 2018, @03:11PM (1 child)
The point is, you cannot move the private key out of TPM even if you want.
(Score: 2) by ElizabethGreene on Wednesday May 23 2018, @07:15PM
Affirmative. You ask the TPM to encrypt or decrypt things, you don't ask it for the key. It's a nifty piece of kit.
I'd be remiss here if I didn't caveat that with a *.
* That is so long as the TPM manufacturer did their job competently. There has been at least one flaw found in a TPM implementation.
>> https://portal.msrc.microsoft.com/en-us/security-guidance/advisory/ADV170012 [microsoft.com]
(Score: 2) by ElizabethGreene on Wednesday May 23 2018, @07:23PM
On a related note, the last time I looked TPM support was orphaned and possibly broken in OpenSSL on Linux. Any volunteers want to take that on?