Intel SGX Co-signer Architecture

📘

Learn how to install SGX Co-signer in Azure in the following guide

Resources used by the SGX Co-signer

The Fireblocks SGX Co-signer utilizes Intel's SGX enclave and attestation mechanisms. It can be deployed either in cloud service providers that support compatible SGX servers or on-premise using a bare-metal server. Also, an SGX driver must be loaded into the machine. This is the only resource that is required to install and operate the Co-signer on the host machine.

The Co-signer's database is encrypted and stored on the host machine's disk, serving as the Co-signer's persistent storage.

🚧

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

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 Co-signer, upon initialization, connects to the Intel-SGX Remote Attestation server that belongs to the Fireblocks SaaS and retrieves the key that encrypts its database: FBKS-DB-Key
2. The Co-signer initializes its encrypted database using the key FBKS-DB-KEY
3. The Co-signer encrypts FBKS-DB-KEY using the SGX hardware key of the host machine.
4. The Co-signer saves its encrypted database and the encrypted form of FBKS-DB-KEY in the host machine, serving as its persistent storage
5. The Co-signer cannot operate unless it is attested against Fireblocks' Remote Attestation server.

This is illustrated in the block diagram below:

Installation artifacts

The SGX Co-signer is comprised of several components:

1. Installation script: This is the CLI interface for installing and managing the Co-signer. You can retrieve the installation script from the Console. The script includes the path to a Docker image registry for downloading the Co-signer Docker image. It supports downloading images of various versions, with default versions specified if none are explicitly provided. See the SGX Co-signer version history for details on the image version.
2. Docker image: The Co-Signer's executable is wrapped in a Docker image to provide safe, versioned, and consistent installation across different platforms. The Docker image provides all the libraries and dependencies of the main executable.
3. Main loading executable: A slim binary that downloads and verifies the enclave and exposes command line interfaces.
4. Secure SGX enclave: This component contains most of the Co-Signer's code and logic. It is both encrypted and signed by Fireblocks, and it can be downloaded from the Fireblocks server during setup.

• Q: Should I verify the executable's signature?
  If you are using the correct Docker image, as specified by the script, there is no need for any other verification, as it is embedded in the image.
• Q: Why is the enclave encrypted?
  SGX allows for saving the enclave encrypted on disk with a hardware key only available to the specific CPU where the enclave would be executed. Secured enclaves prevent the risk of modification, make it impossible to reverse engineer, and hide any potential secrets embedded within them. This enclave alone is capable of reading the secrets stored by the Co-Signer.
• Q: Should I verify the enclave's signature?
  There is no need for that. The Fireblocks signing key is embedded within the loading executable, which verifies the enclave's signature whenever it is loaded.
• Q: Where do I find the enclave in the docker image?
  The enclave is only downloaded when the Co-signer goes through a setup or upgrade process, so it is omitted from the Docker image. The name of the file is enclave.signed.so.

The chain of trust follows the sequence: script > image > executable > enclave, with Fireblocks ensuring compatibility between these components. During setup or upgrade, the Co-signer downloads the latest enclave version from Fireblocks servers, which is guaranteed to be compatible with the installed executable. To ensure the enclave uses the latest published version, always use the most recent Co-signer Docker image. The safest approach is to install the Co-signer using the latest installation script.