Welcome to SCONE Platform¶
Simplified client interface (2018-11-23)
We demonstrate how SCONE simplifies the encryption of inputs and scripts such that one can implement always encrypted secure remote execution. We introduce this functionality with the help of blender (ray tracer) in our secure remote execution tutorial. We show how to encrypt application code and user input in our advanced blender use case.
Trusted DApps with SCONE and iExec (2018-11-18)
SCONE supports the construction of Trusted DApps (decentralized applications) for the iExec Platform. Read how to securely execute remote applications and how to build trusted DApps with SCONE - both for simple remote execution via ssh and the iExec Platform.
SCONE now supports R (2018-08-18)
The SCONE platform facilitates always encrypted execution: one can run services and applications such that neither the data nor the code is ever accessible in clear text - not even for root users. Only the application code itself can access the unencrypted data and code. SCONE simplifies the task of encrypting the input, executing the service/application in encrypted memory on an untrusted host, transparently encrypting the output and shipping the output back to the client.
SCONE helps to ensure that data, communications, code and the main memory is always encrypted. To do so, SCONE needs to verify (i.e., attest) that the expected application code is running in a trusted execution environment on a potentially untrusted host. Read our secure remote execution tutorial to see how to perform an encrypted remote execution in a single step. In this way, one can even execute encrypted code. We show how to execute encrypted Python scripts in the context of blender.
SCONE can help you to encrypt your input and output data on your local computer. The keys are managed with the help of SCONE CAS (Configuration and Attestation Service). SCONE CAS itself runs, of course, inside an enclave. It can either run on the client side or on a remote host. It can even be operated by an untrusted entity and still be trusted by CAS clients.
Advantages of SCONE¶
SCONE scales better than competing solutions since it uses an advanced thread management and a very efficient way how to perform asynchronous system calls: when an enclave performs a system call, SCONE switches to another application thread while the system call is performed by threads running outside the enclave. This minimizes the need for the threads running inside the enclave to exit the enclave. Minimizing the enclave exits is particularly important looking at recent CPU microcode updates in the context of L1TF: The CPU needs to flush the L1 cache - which is an expensive operation.
SCONE has smaller executables. SCONE is based on a modified C library instead of running a complete library OS inside of an enclave. This does not only reduces the size of the enclaves and hence, the number of software bugs inside the enclave. To see how large typical code sizes are and the defender's dilemma, have a look at our background section. Large code size does not only mean more bugs (expect about 0.61 bugs per 1000 lines) but also negatively impacts performance: SGX CPUs have limited EPC (extended page cache) and larger memory footprints result in general in better performance.
SCONE comes with a toolchain. While SCONE supports binaries compiled for Alpine Linux, we recommend to recompile binaries to minimize code size and to ensure better performance and security of the applications. Also, the crosscompiler ensures that the correct model for thread local variables is used (- i.e., no use of segmentation registers).
SCONE protects the OS interface. SCONE provides shields to protect the interaction with the operating system interface. For example, it provides the transparent encryption of files (example). While the OS interface has more calls than the VMM interface used by a library OS (like Haven), we decided in SCONE to protect the OS interface instead since it provides us with more specific semantics which in turn simplifies the shielding.
SCONE ensures better Linux compatibility. By providing a native OS interface, SCONE reduces compatibility issues of the application. A library OS will most likely not be 100% compatible with the latest Linux kernel.
SCONE transparently attests applications. This ensures that application run indeed inside of an enclave. Only after a successful attestation, the application gets its keys to unlock the file system, its arguments and its environment variables - which all might contain secrets that need to be protected.
SCONE has an integrated secrets and configuration management - simplifying the distribution of secrets without application changes by performing a transparent attestation of applications. The integrated key management is required to ensure that a client can ensure that its data is protected from accesses by other clients and attackers (see an example in the contexted of a trusted DApps).
SCONE is hardware independent. The design of SCONE is such that we can support other TEEs (trusted execution environments) when they become available. In this way, one does not have to port applications to different TEEs.
While SCONE focuses on securing containers and cloud-native applications, SCONE can help you to secure almost any program running on top of Linux.
SCONE is a platform to build and run secure applications with the help of Intel SGX (Software Guard eXtensions)1. In a nutshell, our objective is to run applications such that data is always encrypted, i.e., all data at rest, all data on the wire as well as all data in main memory is encrypted. Even the program code can be encrypted. SCONE helps to protect data, computations and code against attackers with root access.
SCONE can be used on top of Kubernetes and Docker. We provide a tight integration with Docker Swarm. In case you are already using Docker stack files, we provide a simple way to secure your services and applications. We will provide a similar integration with Kubernetes later in 2018.
So, what problems can SCONE help to solve?¶
Secure application configuration¶
SCONE provides applications with secrets in a secure fashion. Why is that a problem? Say, you want to run MySQL and you configure MySQL to encrypt its data at rest. To do so, MySQL requires a key to decrypt and encrypt its files. One can store this key in the MySQL configuration file but this configuration file cannot be encrypted since MySQL would need a key to decrypt the file. SCONE helps developers to solve such configuration issues in the following ways:
secure configuration files. SCONE can transparently decrypt encrypted configuration files, i.e., without the need to modify the application. It will give access to the plain text only to a given program, like, MySQL. No source code changes are needed for this to work.
secure environment variables. SCONE gives applications access to environment variables that are not visible to anybody else - even users with root access or the operating system. Why would I need this? Consider the MySQL example from above. You can pass user passwords via environment variables like MYSQL_ROOT_PASSWORD and MYSQL_PASSWORD to MySQL. We need to protect these environment variables to prevent unauthorized accesses to the MySQL database.
secure command line arguments. Some applications might not use environment variables but command line arguments to pass secrets to the application. SCONE provides a secure way to pass arguments to your application without other privileged parties, like the operating system, being able to see the arguments.
SCONE verifies that the correct code is running before passing any configuration info to the application. To ensure this, SCONE provides a local attestation and configuration service: this service provides only the code with the correct signature (MrEnclave) with its secrets: certificates, arguments, environment variables and keys. It also provides the application with a certificate that shows that the application runs inside an enclave. Note that this can be done completely transparent to the application, i.e., no application source code changes are required: the encrypted certificate can be stored in the file system where the application expects its certificates.
For debugging and development, you can run code inside of enclaves without attestation.
Two applications can ensure that they run inside enclaves via TLS authentication. In this way we can ensure that the client certificate and the server certificate was issued by the SCONE CAS, i.e., both communication partners run inside of enclaves and have the expected MrEnclave.
Secure main memory¶
An adversary with root access can read the memory content of any process. In this way, an adversary can gain access to keys that an application is using, for example, the keys to protect its data at rest. SCONE helps to protect the main memory:
no access by adversaries - even those who have root access,
no access by the operating system - even if compromised,
no access by the hypervisor - even if compromised, and
no access by the cloud provider, and
no access by evil maids - despite having physical access to the host.
Integration with secure key store¶
Encryption keys must be protected. In many installations, one does not want humans to be able to see encryption keys. Hence, one can generate keys and stores in SCONE CAS. SCONE also supports the integration with a keystore like Vault. SCONE can run Vault inside of an enclave to protect Vaults secrets in main memory.
Transparent TLS encryption¶
Some popular applications like memcached or Zookeeper2 do not support TLS out of the box. SCONE can transparently add TLS encryption to TCP connections: the connections are terminated inside of the enclave. In this way, the plain text is never seen by the operating system or any adversary. Note that one should not use an external process for TLS termination3.
Transparent file protection¶
SCONE protects the integrity and confidentiality of files via transparent file protection. This protection does not require any source code changes. A file can either be integrity-protected only (i.e., the file is stored in plain text but modifications are detected) or confidentiality- and integrity-protected (i.e., the file is encrypted and modifications are detected).
Ease of use¶
We plan to support alternative trusted execution environments in future releases of SCONE. ↩
Zookeeper replicates its state amongst a group of servers. Zookeeper does not support protecting the communication between these servers by TLS. SCONE can add transparent support TLS for Zookeeper to ensure that the integrity and confidentiality of the data exchanged between the Zookeeper server is protected. ↩
Memcached could be protected, for example, with the help of a stunnel. The communication between memcached and stunnel is not encrypted and hence, adversaries with root access would see the unencrypted traffic. ↩