Overview

The SCONE Platform is a generic platform to execute applications inside of trusted execution environments like Intel SGX. It can be used in different settings with multiple stakeholders that might not all trust each other: User, Application Provider, Data Owner, and Auditor.

SCONE protects the IP (intellectual property) of multiple stakeholders. In this section, we introduce the different stakeholders and sketch how SCONE can be used to protect the data, code, and secrets not only from attackers but also from other stakeholders. We also give some recommendations - in the form of forward links - on how one could proceed reading about SCONE.

Attacker

In SCONE, we assume a very powerful attacker that has root access on the hosts on which we execute applications. The attacker can hence dump the memory of the application using standard features of the operating system. In this way, the attacker can gain access to the code, the data and all the keys that are stored in main memory.

Note that the attacker can read all files of the application since operating system based access control does not apply to an attacker with root access. Moreover, any operating system based encryption of files does prevent file system accesses by the attacker either. If the application encrypts the files itself, the encryption key has to be stored somewhere in main memory - otherwise, the application would not be able to encrypt and decrypt files. An attacker can dump the main memory to get a hold of this encryption key.

User

A user wants to protect his computations, data and keys from accesses by other parties and in particular, by accesses by attackers with root access rights:

• Protection against read accesses by attackers protects the confidentiality of the data, keys, and code.
• Protection against read accesses by attackers protects the integrity of the data, keys, and code.

SCONE provides a simple CLI (command line interface) to execute applications on remote hosts. This CLI supports to encrypt files on the user's computer and push these files to a remote computer. Only the application itself can access the files: SCONE performs a transparent attestation of the application to ensure that neither the application or the file system has been modified. Only then, SCONE transparently encrypts/decrypts the files. In this way, SCONE ensures the confidentiality and integrity of the user provided files.

Application Provider

An application provider can create container images like, for example, blender, a 3D creation suite. SCONE helps the application provider to run unmodified applications inside of TEEs (trusted execution environments) such that the application is protected from accesses by attackers. SCONE can also transparently encrypt/decrypt the files stored in the file system. The application container image can, for example, be created with the help of a Dockerfile and in some cases, it might need a multistage build. We describe how to build a Go program as part of this tutorial.

An application provider can push its container images to a public repository like Docker hub or some private repository. The application provider can encrypt parts of the files to ensure the confidentiality and integrity of the files. For example, some of the application code might be written in Python and hence, the application provider must protect the integrity and confidentiality of that code:

Actually, the situation is even more difficult. The user might want to give the application access to some encrypted input and output files (as explained above). The application provider should not have the right to access the files since this is the data that the user must protect. The user should not have access to the files provided by the application provider. In particular, SCONE manages the keys such that the SCONE runtime of the application can get access to the keys but neither the application provider nor the user will see these keys. We describe later how to do this for a simple decentralized copy application.

Data Owner

A data owner is another stakeholder. The data owner provides data that can be processed by the application on behalf of the user. The data owner wants to protect its data not only accesses by access by attackers but also by direct access by the user and/or the application provider. The data owner therefore encrypts its data and only permits accesses by some explicitly specified application.

SCONE supports security policies that ensure that the interests of the different stakeholders are satisfied. This is supported by security policies that are defined by the individual stakeholders. Parts of these policies can be exported to and imported from other policies. In this way, one can compose security policies of mutually distrusting stakeholders.

Auditor

In very critical application domains, neither the data owner nor the user might trust neither the application provider nor the SCONE platform sufficiently much, to entrust their data & computations to the application. In these domains, an auditor can help to establish trust in the application. The auditor is an independent entity that can access all source code of the application as well as the SCONE platform. The auditor works typically offline, i.e., it is not involved in any of the computations. Instead, she determines which MrEnclaves together with what file system state (i.e., tag) can be trusted by the data owner and the user.

The auditor will also check the SCONE Configuration and Attestation Service (CAS): SCONE CAS enforces the security policies and manages the secrets on behalf of the SCONE platform. The auditor publishes the trusted MrEnclave and the file system tag of SCONE CAS.

The data owner and the user can specify in their security policies a set of MrEnclaves, each with a specific file system tag, that they trust. Moreover, before submitting a security policy to SCONE CAS, they check that the instance of SCONE CAS has the correct MrEnclave as well as the correct initial file state. This is achieved with the help of the Intel attestation service.