Skip to content

Threat Model

The underlying threat model of SCONE is based on a set of adversary models by Intel. We extend this threat model by a roll-back state adversary, i.e., an adversary that can roll back the state of a system.

We aim to protect an application, say, A that runs in a set of containers, C1, C2..., Ck, which in turn run on a set of VMs, say, VM1, VM2, .. VMl, which in turn run on a set of servers/computers S1, S2, ..., Sn. We aim to protect the integrity, confidentiality, and consistency of the data, the code, and the secrets of the application A. The data, code, and secrets must be protected at rest, in transit, and in use.

Adversary Models

  • AM1) Unprivileged Software Adversary: we assume that an adversary can run user code on the same computer, i.e., on S1, S2, ..., Sn). This includes programs the adversary might run in different virtual machines (VMs) and the same VMs (i.e., VM1, VM2, .. VMl) in which we run the application A. The adversary can run unprivileged code in the same VMs and the same containers as A.

    We sketch potential attacks that might require the adversary to have a specific user ID. Depending on the user ID, an adversary might need to change the user ID, which in turn might require System Software Adversary (AM2 - see below).

    • For example, a system adversary, A1, might run programs in the application containers of A1. For example, A1 might execute programs in user mode in the same Kubernetes cluster (after gaining access to a kubeconfig file):

      kubectl exec -it <Container Ci> -- sh.

    • Protection at Rest: A1 might inspect all files accessible inside a container. We must ensure that such adversaries cannot see confidential files mapped into the container as plain text. SCONE supports a filesystem shield that enables the transparent encryption of

      • Kubernetes volumes with the help of SCONE volumes
      • Files in the root filesystem can be encrypted with the help of the filesystem shield
      • Files in the root filesystem can be integrity protected with the help of the SCONE binaryFS

    • Protection in Transit: Cloud-naive applications often use mTLS implemented by ISTIO. A1 might intercept the unencrypted traffic between a service and an ISTIO sidecar. SCONE addresses this issue with the help of its network shield: all traffic can be transparently encrypted.

    • Protection in Use: An adversary might try to dump the memory of a confidential application. We prevent this by executing enclaves in production mode. Transparent attestation by SCONE ensures that only applications running the correct code in the right environment can access secrets required to decrypt data at rest and in transit.

  • AM2) System Software Adversary: we assume that an adversary might have administrators' credentials with root access to the system software. Or, they might coerce admins into copying or modifying data or code both at the system and the application level.

    • A system software adversary A2 might execute privileged instructions. A2 can change its user ID to any user, including the root user. The adversary can, for example, dump the memory of an application. See our memory dump example for more details.

    • A system software adversary, A2, might also change the behavior of specific or all system calls. For example, A2 might change the random numbers that the operating system provides to application A to be able to predict the keys. Please read random numbers in SCONE for more information.

  • AM3) Startup Code/SMM Software Adversary. We assume that an adversary can modify the code initially booted on the server and change the system management code. This adversary might also try to access the machine via the BMC.

    • This is addressed with the help of Intel SGX. The application code is protected with the help of enclaves. We do not trust the startup code/SMM, the hypervisor, or the operating system. All critical data, code, and secrets are confidentiality, integrity, and consistency protected.

  • AM4) Network Adversary. We assume that an adversary with access to the network can try to communicate with confidential services to gain access or trigger bugs in the confidential services.

    • we ensure with the help of confidential service meshes that only fresh, attested, confidential service instances can communicate with each other. Transparent attestation of service instances ensures that only service instances running the correct, up-to-date code inside of enclaves (i.e., encrypted memory regions) on CPUs with up-to-date firmware without known vulnerabilities can join the mesh.
    • communication between confidential services is protected with the help of the SCONE network shield in case these services do not support mTLS out-of-the-box.
    • all communication with native (i.e., non-confidential) service is mitigated via confidential proxies with Web Application Firewalls (WAF). 

    • AM5) Software Side-Channel/Covert-Channel Adversary: an adversary could try to extract secrets and keys from confidential services using side channels that circumvent the protections of the enclaves.

    • part of the enterprise version - please contact us at info@scontain.com.

  • AM6) Simple Hardware Adversary

    • AM6.1) The adversary can remove DRAMs, has tools for hardware debugging, and can listen to buses.

      • addressed with the help of Intel SGX

    • AM6.2) The adversary gets hold of decommissioned hardware. The adversary recovers a CPU, TPM, and database when the hardware or service is decommissioned. 


      • SCONE supports remote governance of applications, i.e., the application can be switched off

  • AM7) Roll-Back State Adversary:

    • AM7.1) The adversary can roll back the disk state. The disk state might contain an encrypted database with keys that have been updated already.

      • SCONE supports rollback-protected filesystems of applications, i.e., any rollback of files or individual blocks will abort the application.

      • SCONE supports rollback-protected CAS. This is part of the enterprise version - please contact us at info@scontain.com.

    • AM7.2) The adversary can roll back the CPU firmware or the code of a confidential service. The adversary can install an old version of the CPU firmware to exploit known bugs in enclave implementation. An adversary could use this to extract information from, say, an encrypted key database.

      • SCONE protects against firmware rollbacks by attesting the platform

    • AM7.3) The adversary can freeze the state of an existing enclave. This is to keep access to an earlier version of the database.