Google Cloud KMS¶

The Google Cloud KMS is a cloud based KMS available in the Google cloud. Here is a set of useful documentation links to get started with Google Cloud KMS:

Type	Description
Basic Concepts	Explanation of the basic concepts and terminology of Google Cloud KMS.
Best Practices	Guidance on how to use Google Cloud KMS securely and efficiently.
Access control	Guidance on how to provide access to Google Cloud KMS.
Access control guidelines	Recommendations for managing access to Google Cloud KMS.
Application Default Credentials	Guidance on how to use Application Default Credentials to authenticate to Google Cloud KMS.
step-kms-plugin	Guidance by the `step-kms-plugin` on how to use Google Cloud KMS with the plugin.

Key Creation¶

There are multiple ways to create an asymmetric key in Google Cloud KMS. You will first have to create a key ring (e.g., via the Console or CLI). Then you will have to create a key inside of the key ring (e.g., via the Console or CLI)

Tip

Use meaningful names for the key ring and the keys. Consider whether you want to maintain multiple key rings to grant different access to different users.

Important

The SCION Control Plane PKI currently only supports the following EC curves for the private keys: P-256, P-384, and P-521. Make sure to use one of these curves when creating the private keys.

Currently, Google Cloud KMS does not support the P-521 curve.

Authentication¶

Google recommends to use Application Default Credentials for local development when using the scion-pki tool. There are also other ways to authenticate, e.g., via service accounts.

The method you choose depends on your internal policies and requirements.

Certificate Creation¶

To create a self-signed certificate based on a key stored in Google Cloud KMS, you will need to provide the --kms and --key flags.

For example, to create a sensitive voting certificate, you can use the following command:

scion-pki certificate create <subject-template-file> <certificate-output> \
    --profile sensitive-voting \
    --kms 'cloudkms:' \
    --key 'projects/<project-name>/locations/europe-west6/keyRings/<key-ring-name>/cryptoKeys/<key-name>/cryptoKeyVersions/1' \
    --not-before 2025-04-05T10:16:00.00Z \
    --not-after 5y \
    --common-name "My Common Name"

Note

Make sure to use the appropriate validity period and subject (including common name) for the certificate. The certificate is non-sensitive information and can be stored without extra protection.

For more information on the scion-pki certificate create command, refer to the the scion-pki reference or have a look at the TRC ceremony preparations. You can also use the TRC script builder and amend the commands with the --kms and --key flags.

Tip

If you need help crafting the subject template, you can use the TRC script builder. It will generate a cat command to create the subject template file based on your input.

For example:

cat << EOF > $WORKDIR/subject.tmpl
{
    "state": "CH",
    "isd_as": "1-ff00:0:110"
}
EOF

TRC Signature¶

During the TRC signing ceremony, you will need to create signatures for the TRC payload. To do this, you can use the scion-pki trc sign command with the --kms flag.

To already test the signing process before the ceremony, you can create a dummy payload using the scion-pki trc payload dummy command and sign it with your private key stored in Google Cloud KMS.

scion-pki trc payload dummy > /tmp/dummy.pld

scion-pki trc sign /tmp/dummy.pld <certificate> 'projects/<project-name>/locations/europe-west6/keyRings/<key-ring-name>/cryptoKeys/<key-name>/cryptoKeyVersions/1' \
    --kms 'cloudkms:'

scion-pki trc inspect /tmp/dummy.pld.sig

Note

Contrary to the certificate creation, the key name is provided as an argument rather than through the --key flag.