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.
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.