Google Cloud KMS

The Google Cloud KMS is a cloud-based KMS available in the Google cloud. The table below provides 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 need to create a key ring first (e.g., via the Console or CLI). Then, 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, provide the --kms and --key flags.

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

Example: Create a self-signed certificate

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 access to it does not need to be restricted.

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

tip

You can use the TRC script builder. It generates 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, create signatures for the TRC payload. Use the scion-pki trc sign command with the --kms flag.

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

Example: Create dummy payload

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

Example: Sign dummy payload with Google Cloud KMS

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:' \
    --out /tmp/dummy.pld.sig

note

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

Example: Inspect signed payload

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