Key storage
The private keys for the self-signed certificates must be protected well. They hold significant power over the ISD, as they are used to sign the TRC updates (voting keys) or sign the CA certificate (root key). With the scion-pki tool, the private keys can be stored in one of multiple secure key-storage backends.
| Type | Description |
|---|---|
| Cloud based KMS | Safely store the private key in a cloud-based KMS (e.g., AWS KMS, Google Cloud KMS, Azure Key Vault) |
| PKCS #11 HSM | Safely store the private key in a PKCS #11 compatible HSM. |
| YubiKey PIV | Safely store the private key in a YubiKey PIV. |
There are tradeoffs between the different key-storage backends. The cloud-based KMS is more convenient and easier to set up. Access can be protected with the familiar IAM policies. We think it is a good choice in most cases, when configured properly.
The cloud-based KMS commonly also support different tiers of key storage: from the very basic software-protected private key to a more advanced HSM-protected private key.
Regardless of the key-storage backend, we leverage the
step-kms-plugin in our
scion-pki tool to use the private keys for signing certificates.
The following table shows the parameters that are required for the three most
common cloud-based KMS. The parameters are passed to the scion-pki tool via
the --kms and --key parameters, e.g., when creating a new certificate using
scion-pki certificate create or creating a signature on a TRC using scion-pki trc sign.
| Type | KMS parameter | Key parameter |
|---|---|---|
| AWS KMS | awskms:region=<region> | awskms:key-id=<key-uuid> |
| Azure Key Vault | azurekms | azurekms:vault=<vault-name>;name=<key-name> |
| Google Cloud KMS | cloudkms: | projects/<p>/locations/<l>/keyRings/<r>/cryptoKeys/<k>/cryptoKeyVersions/1 |
Check out the following guides for more information on how to set up your KMS of choice with the
scion-pki tool.