Skip to content

Configuration

Due to the ability to securely operate CAS remotely, its configuration is split into two independent parts:

  • An availability configuration, supplied by the CAS operator at startup, and
  • an owner configuration, provisioned by the CAS owner at runtime.

Availability Configuration

The availability configuration encompasses file paths and network interfaces - everything that is necessary in order to start a CAS instance. The configuration is read from a TOML-formatted file.

This part of the configuration is not security-sensitive. It does not take part in remote attestation, is stored unencrypted, and can be changed by the CAS operator at any time.

Example Configuration File

[database]
path = "/etc/cas/cas.db"

[api]
api_listen = "0.0.0.0:8081"
enclave_listen = "0.0.0.0:18765"

Database

CAS stores its data in an SQLite database, the location of which is determined in by the database.path option of the configuration:

database.path = "/etc/cas/database.sqlite"

The database is always encrypted to protected the confidentiality of the contained secrets. The database encryption key is stored as cipher text in a separate file with the same filename, but ending with .key-store.

Note

Note that the key used to encrypt the database encryption key is derived using SGX' seal key derivation feature. Therefore, CAS can only decrypt the database encryption key and access the database if it is executed on the same machine which has created the .key-store file, or the key is explicitly made available to a CAS on another machine with CAS' Backup feature.

In particular, that means if the machine hosting CAS breaks, e.g. due to hardware failure, or is not available anymore, for example, because it was a cloud machine, you'll access to all data stored by CAS is lost!

Security in Debug Mode

In debug mode, SGX generally does not protect your data as the debug interface exposes the enclave's memory. That means one can easily extract the database encryption key from a CAS running in SGX debug mode with our scone-gdb debugger. However, you might not be aware of this. Therefore, to counteract a false sense of security (and help debugging) CAS will dump its database encryption key anytime it does not run in production mode to the console and into a file next to the database file ending with .key.

To reiterate: this is not a security vulnerability. Any slightly invested attacker could easily extract the key with a debugger.

Interfaces

At the moment CAS offers two interfaces:

  • A client REST API with which clients can upload, upgrade and query sessions, and
  • an enclave interface with which enclaves communicate with CAS.

These configuration options will determine on which network interfaces and ports CAS will listen for incoming connection. Interfaces are defined with values satisfying std::net::SocketAddr's FromStr implementation.

The client API is configured via the api_listen option while the enclave interface is configured through the enclave_listen option:

[api]
enclave_listen = "0.0.0.0:18765"
api_listen = "0.0.0.0:8080"

Note

A configuration with an IP address of 0.0.0.0 will make the CAS listen on any available network interface.

Owner Configuration

After its initial start, a new CAS instance remains in an unprovisioned state. In this state, its functionality is severely limited until someone claims ownership and provides a configuration. Since the owner configuration contains security-sensitive information, it is necessary to attest the CAS beforehand. The configuration will be stored encrypted as part of the CAS database.

The SCONE CLI is the primary tool to manage the CAS' owner configuration:

  1. Initial provisioning: scone cas provision --config-file <...>
  2. Later configuration update: scone cas update-config --config-file <...>

Please refer to the SCONE CLI documentation for a full description. The configuration file is usually provided in TOML format.

Example Configuration File

The following file can be used for a development environment:

[api_identity]
common_name = "cas"
alt_names = ["cas", "localhost"]
country_name = "DE"
org_name = "scontain GmbH"
state_or_province = "Saxony"
locality = "Dresden"
email = "info@scontain.com"

[ias]
spid            = "32C2D32CD4F1C873625BBE65D973A702"
linkable_quotes = true
sp_key          = "1c8b569cffd94a85ad11342bfad5a3ad"
base_uri        = "https://api.trustedservices.intel.com/sgx/dev/attestation/v3"

[dcap]
subscription_key = "00000000000000000000000000000000"

API Identity

Contents of the TLS end-entity server and client certificate presented by CAS can be configured in the api.identity section:

[api.identity]
common_name = "cas"
alt_names = ["cas", "localhost"]
country_name = "DE"
org_name = "scontain GmbH"
state_or_province = "Saxony"
locality = "Dresden"
email = "info@scontain.com"

This section is not mandatory. If not specified, default values listed above will be used. In case the section is provided in the configuration file, it must contain at least common_name field.

IAS Client

The IAS client enables CAS to verify enclave EPID quotes using the Intel SGX Attestation Service (IAS). EPID quotes will be used for remote attestation of program enclaves, SCONE Quoting Enclaves, and the CAS itself. IAS client credentials are optional. They are, however, required in case CAS should attest applications running on EPID-only CPUs.

Its configuration consists of the Service Provider ID (SPID), linkability setting and authentication information.

  • spid has to be a 32 character or 16 byte long hex string.
  • linkable_quotes is either true or false.

Both are provided to you when you enroll with Intel's IAS.

  • base_url is the url endpoint at which the client will query Intel's attestation service. This setting is optional and will point towards the development environment endpoint of IAS by default. You have to adapt this setting if you want to use an IAS production identity.

IAS is access-controlled. CAS supports Rev4 and Rev5 IAS authentication (choose either one, not both):

  • You can specify your Rev4 X.509 certificate and private key through the ias.identity option. Refer to the section about private keys information regarding private key encoding.
  • If you're using a Rev5 subscription key to authenticate your account, specify it under the sp_key option.
[ias]
spid = "2EC5BE64E242BCC9E4670D49E5C7091E"
linkable_quotes = true
base_url = "https://test-as.sgx.trustedservices.intel.com:443/attestation/sgx/v3"
identity = """
-----BEGIN PRIVATE KEY-----
...
-----END PRIVATE KEY-----
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
"""

Intel Provisioning Certification Service for ECDSA Attestation Client (DCAP)

The Intel Provisioning Certification Service for ECDSA Attestation Client enables CAS to verify DCAP quotes created by the Intel Quoting Enclave. DCAP quotes can be used as an alternative to EPID quotes for remote attestation of program enclaves. Configuring a DCAP client credential is optional.

The configuration encompasses a subscription key. This key is provided to you when you enroll with Intel's Provisioning Certification Service.

[dcap]
subscription_key = "00000000000000000000000000000000"

Private Keys

We support PKCS#8 encoded private keys. By default, openssl will encode elliptic curve keys in the incompatible format specified in SEC 1: Elliptic Curve Cryptography. You can use the openssl cli to convert these keys into PKCS#8:

openssl pkcs8 -in pkey.pem -topk8 --nocrypt -out pkey.pkcs8.pem

PKCS#1-encoded private keys, e.g. key with ------BEGIN RSA PRIVATE KEY-----, can be converted into PKCS#8 with the following command:

openssl pkcs8 -topk8 -inform PEM -outform PEM -nocrypt -in pkcs1.key -out pkcs8.key