Learn PKI - Key Management & Hardware Security

#Introduction

In episode 12 you issued certificates through Vault, and in previous episodes the CA keys were stored as files on servers. Episode 13 answers the most fundamental question in PKI: how do you protect the private key itself? Certificates can be shared, but a leaked private key means the CA's identity falls into the wrong hands.

Threats to keys come from many directions: loose file permissions, careless backups, departing employees, and theft of physical devices. The more valuable a key, the more effort is worth spending to protect it. From simple filesystem practices to dedicated hardware called an HSM.

This episode's roadmap: we discuss file-based and passphrase security, then HSM and the PKCS#11 standard with YubiKey PIV and TPM, then the step-ca HSM image, followed by KMS such as AWS KMS and Azure Key Vault, and close with split knowledge.

#File-Based Security

Before talking about expensive devices, make sure the basics are right. Many CA keys have leaked simply because of files with read permissions for all users, or copied to the wrong directory during backup.

#File Permissions and Ownership

A private key should only be readable by its owner. In Unix environments, permission 600 is the minimum, and for keys held by a service, the owner should be a dedicated user that only runs that task.

chown root:ca-ops ca-key.pem
chmod 600 ca-key.pem

Besides permissions, watch how keys are created. Use a strict umask so new files are not created with loose permissions, and make sure the directory holding the key is not accessible to other users. These small habits prevent leaks before they happen.

#Passphrase-Protected Keys

Keeping the key encrypted is the next layer. When a key is stored with passphrase-based encryption, the key is useless without its password.

openssl genrsa -aes256 -out ca-key.pem 4096

openssl genrsa -aes256 asks for a passphrase at creation time and stores the key in encrypted form. Every time it is used, the key holder must enter the passphrase. The weakness is obvious: the passphrase becomes a single point of failure, and the signing process is no longer fully automatic.

#HSM and the PKCS#11 Standard

For stronger protection, keys can be moved from the filesystem to dedicated hardware designed so keys never leave it. This device is called an HSM, short for hardware security module.

#What is an HSM

An HSM stores keys within verified physical boundaries. Operations such as signing happen inside the device, so the private key is never exposed to system memory. Even HSM administrators cannot extract the raw key.

#PKCS#11

How applications talk to an HSM is governed by the PKCS#11 standard. This standard defines an API for loading modules, opening sessions, and performing cryptographic operations. Many modern PKI tools support PKCS#11, including step-ca.

#YubiKey PIV

YubiKey is a small device that can be used as a cheap HSM. Its PIV feature provides key slots that can sign and decrypt. The private key inside a YubiKey cannot be extracted, and every use usually requires the holder's confirmation.

#TPM

The Trusted Platform Module is a chip embedded in almost all modern laptops and servers. A TPM locks keys to a specific device: a key can only be used on the machine where it was created. This makes the TPM an attractive choice for protecting machine keys from physical theft.

#step-ca with HSM

step-ca from episode 9 supports storing keys outside the filesystem through the KMS interface. For HSMs, you use a PKCS#11 module, for example SoftHSM for experimentation or a YubiKey for small production.

The official smallstep image provides a runtime equipped with the PKCS#11 module. Configuration is done via a KMS URI in ca.json.

{
  "kms": {
    "type": "pkcs11",
    "uri": "pkcs11:token=smallstep?module-path=/usr/lib/softhsm/libsofthsm2.so",
    "pin": "1234"
  }
}

With this configuration, step-ca's CA key lives inside the HSM. The key is never written to disk as an ordinary file, so grabbing a backup file alone is not enough to steal the CA.

#KMS for Cloud Scale

CA keys can also be stored in a cloud KMS. This approach is popular because operations are handled by the provider, and access policy is managed through IAM.

#AWS KMS

AWS KMS manages keys with layered protection and full audit. step-ca supports AWS KMS as a backend, so a CA in AWS infrastructure can use keys fully managed by AWS.

#Azure Key Vault

Azure Key Vault offers similar capabilities with deep integration into the Azure ecosystem. The choice between AWS KMS and Azure Key Vault generally follows the cloud provider your team already uses.

The advantages of KMS: no physical devices to buy, identity-based access management, and centralized audit. The main considerations are dependence on the provider and per-request cost.

#Split Knowledge

Protecting a key with a single person is too fragile. Split knowledge divides the ability to use the key among several parties, so no single person can use the key alone.

The M-of-N principle splits the key into N shares, and only M shares are needed to recover or use the key. This technique is known as secret sharing. For example, with a 3-of-5 rule, three of five share holders must be present before the key can be used.

This practice is very suitable for sensitive operations such as unlocking an offline root CA key. No single individual holds full power, and losing one share does not make the key unrecoverable.

#Closing

Episode 13 closes the last protection layer of PKI: the private key. You understood file-based and passphrase security, got to know HSM and the PKCS#11 standard with YubiKey PIV and TPM, configured step-ca with a PKCS#11 module, considered cloud KMS, and applied split knowledge.

Key takeaways:

• A leaked private key means the entire CA falls into the wrong hands.
• File permission 600 and a strict umask are the basics that must not be skipped.
• A passphrase adds an encryption layer, but creates a single point of failure.
• HSM and PKCS#11 keep keys from ever leaving the hardware.
• step-ca supports HSM via a KMS URI with a PKCS#11 module.
• Cloud KMS and split knowledge answer the needs of scale and collective security.

In episode 14 we assemble everything into one flow: the certificate lifecycle. You will learn from enrollment to revocation, expiry monitoring, short-lived certificates of 24 hours to 7 days, SPIFFE and SPIRE for mTLS in a service mesh, and observability with cert-monitor and cert-manager cainjector. See you there!