Google Cloud Confidential Space API Co-signer Architecture

📘

Learn how to install GCP Confidential Space Co-signer in the following guide


GCP Co-signer can only connect to one workspace at a time

Like other Co-signers, the Google Cloud Confidential Space Co-signer is installed and connected to the workspace through an API user. Once installation is complete, you can manage it via the Console or APIs to add additional API users, configure their Callback Handlers, etc.

Due to Google Cloud's Confidential Space container architecture, the Co-signer can only be commanded through Fireblocks' SaaS. As a result, it is restricted to a single workspace connected to the Co-signer. All operations must be performed within this workspace using the Console or APIs.



Google Cloud resources used by the Co-signer

The Fireblocks GCP Confidential Space API Co-signer leverages Google's Confidential Space technology. It utilizes the following Google Cloud's resources:

  • Workload Container: used to run the enclave.
  • Bucket: used as the Co-signer's persistent storage and holds the encrypted database of the Co-signer.
  • KMS Customer Managed Key: used to securely protect the Co-signer's MPC keyshares, which are stored in the Co-signer's persistent storage within a bucket.
  • IAM/WIP: enables associating identities with Google Cloud's IAM roles to grant only essential permissions to specific resources in use.

🚧

Important: Allocate a separate set of resources for each Co-signer to prevent conflicts and ensure isolation, enhancing security.

The "project" can be common between different Co-signers.


This is illustrated in the block diagram below:



Secure Co-signer database encryption scheme

The following process is implemented to build and secure the Co-signer's database:

  1. The user creates and configures a symmetric Customer Managed Key (CMK) in the KMS.
  2. The Co-signer, upon initialization, asks KMS to generate an additional AES 128-bit CBC key: FBKS-DB-Key
  3. The Co-signer initializes its encrypted database using the key FBKS-DB-KEY
  4. The Co-signer encrypts FBKS-DB-KEY using the CMK.
  5. The Co-signer saves its encrypted database and the encrypted form of FBKS-DB-KEY in the S3 bucket, serving as its persistent storage
  6. Access to KMS, including the CMK, is restricted using a Fireblocks enclave image attestation signature and the IAM role and policies that were created by the user.

This is illustrated in the block diagram below:



GCP Confidential Space Co-signer installation package

The installation package contains an Enclave Image File (EIF) and a set of installation scripts. The EIF is built based on the image containing the common API Co-signer code and the AWS Nitro enclave functionality. This image is scanned for known vulnerabilities, and only then does the build process continue based on the AWS build procedure.