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.
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"
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
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
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
To reiterate: this is not a security vulnerability. Any slightly invested attacker could easily extract the key with a debugger.
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
The client API is configured via the
api_listen option while the enclave interface is configured through the
[api] enclave_listen = "0.0.0.0:18765" api_listen = "0.0.0.0:8080"
A configuration with an IP address of
0.0.0.0 will make the CAS listen on any available network interface.
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:
- Initial provisioning:
scone cas provision --config-file <...>
- 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 = "firstname.lastname@example.org" [ias] spid = "32C2D32CD4F1C873625BBE65D973A702" linkable_quotes = true sp_key = "1c8b569cffd94a85ad11342bfad5a3ad" base_uri = "https://api.trustedservices.intel.com/sgx/dev/attestation/v3" [dcap] subscription_key = "00000000000000000000000000000000"
Contents of the TLS end-entity server and client certificate presented by CAS can be configured in the
[api.identity] common_name = "cas" alt_names = ["cas", "localhost"] country_name = "DE" org_name = "scontain GmbH" state_or_province = "Saxony" locality = "Dresden" email = "email@example.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
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.
spidhas to be a 32 character or 16 byte long hex string.
Both are provided to you when you enroll with Intel's IAS.
base_urlis 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.identityoption. 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
[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"
We support PKCS#8 encoded private keys.
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