Stories
Slash Boxes
Comments

SoylentNews is people

posted by janrinok on Monday May 21 2018, @09:52PM   Printer-friendly
from the security-in-your-pocket dept.

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.


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 2) by darkfeline on Monday May 21 2018, @11:51PM (2 children)

    by darkfeline (1030) on Monday May 21 2018, @11:51PM (#682459) Homepage

    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!
    Starting Score:    1  point
    Karma-Bonus Modifier   +1  

    Total Score:   2  
  • (Score: 5, Informative) by Knowledge Troll on Monday May 21 2018, @11:59PM (1 child)

    by Knowledge Troll (5948) on Monday May 21 2018, @11:59PM (#682460) Homepage Journal

    but you can't even use the powerful CPU on that machine for TLS.

    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

      by Fnord666 (652) on Tuesday May 22 2018, @12:13PM (#682607) Homepage

      but you can't even use the powerful CPU on that machine for TLS.

      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.

      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.