Small Business PKI: Who Says You Need to Drop $10,000 for an HSM to run your own CA?
Disclaimer: This article discusses a real-world compromise that seriously deviates from Public Key Infrastructure design best-practices. Use this information at your own risk. This article assumes that you already have some knowledge of Linux administration and networking best-practices
If you’ve spent any time at all around Public Key Infrastructure, you’re undoubtedly going to hear about something called an HSM, or Hardware Security Module. As a matter of fact, the documents surrounding PKI design specs state that if you want to be taken seriously as a PKI provider, an HSM is not merely a suggestion, but a $10,000-$20,000 -requirement– for anyone hoping to run their own security infrastructure. Mic drop.
That kind of dough isn’t play money for most small to medium sized businesses. In fact, it’s a downright kick in the teeth.
I have a question for you: How many businesses do you think are running a Certificate Authority without one? If you’re reading this article, I can think of at least one. I can bet dollars to dimes that businesses who are doing such a thing have probably never been hacked. I can also think of at least one high-profile company who lost everything— and their entire business model was based on the fact that they did have an HSM. Several, in fact.
So, what’s the difference? It starts with policies.
The high-profile security company in question was DigiNotar, and the important distinction here is that the company’s loss was based not on their hardware or lack thereof, but in their lack of defense-in-depth policies. They treated the network edge as an impenetrable fortress, while leaving their core internal network entirely flat, and therefore exposed to anyone who was able to breach the perimeter defense.
So how do we manage such madness without having a piece of hardware that erases itself the second someone breathes on it the wrong way? It starts at the most basic level of hardware: The person designing it.
Full disclosure: Following the advice in this article will not guarantee that you won’t get hacked and have your entire credential chain exposed. But it will make exfiltration so expensive that most people will choose to move on to greener pastures (and less secure networks)
tr -dc '[:graph:]' < /dev/urandom | head -c 32Keep that command sequence burned in your mind. You’ll be using it often. That’s how you generate a password that is cryptographically secure enough that it would take eons to brute-force. Security hygiene is paramount, especially when you’re dealing with encryption. And it starts with a secure password.
Next, you’re going to want to make sure that you set up a network that is difficult to traverse. Not impossible, but difficult. Virtual LANs (VLANs) are non-negotiable. If your firewall/router doesn’t support VLANs, get a better one. It doesn’t have to be a multi-thousand dollar Cisco ASR. A $400 mini-computer with OPNsense is plenty. Don’t have $400? Hop on eBay and search up old VeloCloud appliances. You’re going to want to put your CA on a VLAN that isn’t going to be occupied by anything else. And set up a global rule that blocks cross-VLAN traffic by default.
Let’s get into hierarchy.
Next, you’re going to want to issue yourself a Root CA, and put that on a USB stick including its private key. That’s what you’re going to use to issue the real workhorse– the intermediate, or issuing CA. The Root CA should never touch any machine that will be connected to the network. If it is, make sure to run the shred command instead of rm to remove all traces of it from the network-connected machine.
This is what’s known as a two-tier PKI. SmallStep, by default, uses a simple one-tier setup. There is also a three-tier PKI, which involves a Root CA, Intermediate CA, and Policy CA– but that’s getting more complex than I want to go into at this time.
Let’s also talk about encryption, specifically full-disk encryption.
Remember that “tr -dc ‘[:graph:]’ < /dev/urandom | head -c 32” command we discussed earlier? Run it. Note the password. Store it on a USB stick with a filename that tells you what it’s for. That’s going to be your recovery key for the next step. Go ahead, spin up a Debian VM with a vTPM 2.0 and UEFI using virt-install. Perhaps use sudo if you want to be able to autostart it with the machine.
You’re going to set up an encrypted volume and paste that recovery key right into the box when prompted for a passphrase. It’s okay that you’ll have to enter it for the next boot, because after it boots for the first time, you’re going to install dracut and tpm2-tools+tpm2-tss so that you can bind the decryption key to the vTPM using systemd-cryptenroll. You’re going to want to bind to PCRs 0, 1, 5, and 7 if you’re using the default EFI shim.
Do not install OpenSSH server. I repeat: do not install OpenSSH server. You’re going to use virsh console to manage this VM.
Once you can verify that the VM boots automatically without prompting for a passphrase, you’ll want to use the installation instructions at https://smallstep.com/docs/step-ca/installation/ to set up SmallStep Certificate Authority. Once that’s all squared away, you can easily import the Intermediate CA you signed with the (hopefully offline) Root CA you generated earlier. It’s just a matter of importing it and setting the decryption passphrase you gave your Intermediate into /etc/step-ca/password.txt.
Of course, less expensive alternatives exist if you need a real HSM. Enter the USB HSM or “HSM on a stick.” At a fraction of the cost of a traditional enterprise HSM, it delivers 90% of the functionality, great for if you need FIPS-140-3 compliance or just want the added security. Think of it like a one-way USB stick. Once keys are added, they cannot be extracted or copied, at least not with current technology. Much like a traditional HSM, cryptographic operations happen inside of the unit, and it simply returns a public key or signature to your PKI server. One such device is the YubiHSM 2, available at yubico.com.
Coming soon, more details.
Later we will go into more detail on how to generate your own offline Root CA, use it to sign an Intermediate, and import your Intermediate into step-ca. We will also go more in depth about how to set up step-ca so that it runs in the context of an unprivileged user using setcap.
I hope this article has shifted your mindset from perimeter security to defense-in-depth or inside-out security. Remember, stay safe out there, and call us at 502-694-0307 if you’d like some help setting up your own PKI infrastructure!
