Skip to content

Transparent Attestation of Service Instances

A cloud-native application consists of a set of services. Each service might have one or more service instances. Typically, a service instance is a process running inside a container that provides a REST API.

A service instance executes in an expected environment, i.e.,

  • the file system should be up-to-date and uncorrupted,
  • the service should only compute on a computer that is part of a given cluster, and
  • the hardware and the firmware of the CPUs should be up-to-date without any known vulnerabilities.

We aim to protect an application by ensuring only service instances executing the expected code in the desired environment:

  • can get access to their secrets and their configuration (e.g., arguments, environment variables, and configuration files), and
  • can only then join the confidential service mesh of the application.

A confidential service mesh ensures that only trusted service instances can communicate with each other. Attestation provides this property.

Attesting Service S

The first level of protection against potential attacks on a service instance S is the attestation of S. The attestation ensures that the application code is up-to-date and unmodified, its configuration has not been modified, and the hardware is patched against all known vulnerabilities.

To achieve this, each enclave runs in the context of a security policy: the policy defines the expectation regarding the code and environment of the service instance that executes in the enclave. Only after a successful attestation in which the aspects described in the policy have been attested will service instance S be provisioned with its secrets - like the keys to decrypt the filesystem.

The current version of the security policy is described here. Service instance S runs under the policy SP with a unique policy ID: the policy ID consists of the public key (aka cas_key) of the policy engine, i.e., SCONE CAS identified, and its policy name (aka session). (See details: - One or more MrEnclaves identify the initial state of the service instance running inside an SGX enclave, i.e., a list of permitted hash values of the initial state of the enclave (see details). - A product ID and a minimum security version, and - A public key that needs to sign the binary of S.

In production mode, a service must identify the policy it belongs to, i.e., the policy ID is part of the MrEnclave measurement. We can enforce this property via the SCONE policy. In this way, the code inside of the enclave can only be executed in a context defined by the policy, like for a given environment variables, arguments, and a given filesystem state containing potentially some Python or JavaScript code.

SCONE mitigates reuse attacks in which an adversary uses an enclave; its inner workings change with the help of an initial hostile configuration (e.g., by attesting to a different CAS using a policy under the control of an adversary) before the enclave is reused and reattested in the context of a policy by a different user. SCONE can ensure that an enclave is fresh, i.e., can only be attested to a single policy, i.e., can never be re-attested to a different policy even if the inner workings would of the enclaves would have changed.