Skip to content

SCONE CAS Concepts

Objectives

SCONE CAS (Configuration and Attestation Service) helps to address the following questions:

  • How to provide services with secrets that do not yet have any secrets to authenticate themselves? (see how to provision secret GREETING in our Kubernetes Hello World! Tutorial)

  • How to inject secrets inside of files and services without any human ever being able to see these secrets? (see how to inject file /app/key.pem in our Kubernetes Hello World! Tutorial)

  • How to attest and executed encrypted code? (see how to run and attest encrypted Python code in our Kubernetes Hello World! Tutorial)

  • How to share secrets across several SCONE-based services? (see secret sharing)

  • How to manage secrets in case one cannot trust any individuals, i.e., how to protect against insider attacks?

  • How to import external secrets into a system without any human ever being able to see these secrets?

Secrets

Secrets are managed by a security policy. A security policy can generate secrets and can define which programs can access a given secret. Since a security policy can change over time, we use the term session to denote such a sequence of instances of a security policies.

CAS distinguishes between the following kinds of secrets:

  • Internal: An internal secret is generated by CAS on behalf of a CAS security policy. These secrets are created by CAS and the access to these is controlled by the security policy. A security policy could, for example, enforce that a secret is never seen by a human.

  • Imported: A client can import secrets into a session from other local sessions or from remote sessions, i.e., sessions belonging to a remote CAS service. Such secrets are called imported secrets. The security policy associated with an internal secret will still be enforced after the secret was imported.

  • External: External secrets are secrets that have been created by external entities, and that CAS maintains. The external secrets can be securely imported into CAS without them ever being visible by humans.

CAS Features

Protect all secrets from being visible by humans: CAS can help to ensure that secrets are only visible inside trusted execution environments (TEEs), in particular Intel SGX. This is not only true for internal and imported secrets, but CAS also supports secure import of external secrets, such that the external secrets never are visible to humans, neither during nor after the import.

CAS does not require application source code changes: CAS permits injecting secrets into an application, e.g., into its configuration files, into its source files of scripting languages like Python and JavaScript, or into its compiled binaries. Due to this injection of secrets, no changes need to be made to any of the source code of the application. To ensure that the secrets are not exposed during the injection, the secrets are only injected inside of the TEE where the application is executed. The injection is completely transparent to the application.

CAS can be a managed service: One can delegate the operations of CAS to an untrusted cloud provider and still ensure the confidentiality, integrity and freshness of the secrets - despite having a comprehensive threat model.

Comprehensive threat model: CAS does not need to trust root users, it actually does not trust any individual user. Hence, it also cannot trust the operating system or any input or output. However, a session can trust that there exists sufficiently many users with trusted devices. While we do not know in general who to trust, a session might define that it trusts that out of a group of F+1 users, at least one is honest and uses an uncompromised device. We refer to this group as the policy board. Each session can define its policy board and a value of F such that at least F+1 members of the policy board must approve any changes of the security policy of this session.

Advanced Governance: Policy creations and changes must be approved by a policy board. The policy board can consist of humans as well as programs. We refer to these programs as automated policy checkers.

Secure Policy Checking: Policy checkers can be used to, for example, approve simple policy changes automatically or to perform careful checking of a policy change and reject policy mistakes that a human board member (who might have a very limited time budget) might miss. The policy checkers - as well as all other components of CAS - run inside of individual trusted execution environments. If one assumes that the likelihood of wrong executions of such a policy checker is negligible, one can assign these policy checkers the power to approve or alternatively, to reject a policy change single-handedly. Alternatively, one can require that a minimum number of approvals are necessary.

Secure External Extensions: Key store services (e.g., Barbican) provide plugins to support extensions. The issue with plugins is that a plugin might modify the behavior of a key store. Also, plugins would change the code signature of CAS (if they were loaded during startup). Instead of integrating extensions into CAS, we permit external additions, e.g., to import external secrets in a secure way into CAS.