Content uploaded by Muhammad Usama Sardar
Author content
All content in this area was uploaded by Muhammad Usama Sardar on Apr 21, 2022
Content may be subject to copyright.
Formal Foundations for SCONE Attestation
1st Muhammad Usama Sardar
Faculty of Computer Science
Technische Universit¨
at Dresden
Dresden, Germany
muhammad usama.sardar@tu-dresden.de
2nd Christof Fetzer
Faculty of Computer Science
Technische Universit¨
at Dresden
Dresden, Germany
christof.fetzer@tu-dresden.de
Abstract—One of the essential features of confidential comput-
ing is the ability to attest to an application remotely. Our work
focuses on ensuring correctness of attestation mechanisms and
policies.
Index Terms—confidential computing, remote attestation, for-
mal specification and verification
I. INTRODUCTION
When creating an enclave, bootstrapping trust in the enclave
is a significant challenge. A loader creates this enclave. How
can we establish trust in the loader or the loaded enclave?
Some systems use a trusted loader with a known public key:
each computer has a unique public key. The application owner
could encrypt the content of an enclave with the help of
this public key. The loader can decrypt the content inside its
enclave, create a new enclave, and transfer it via an encrypted
channel.
A trusted loader approach raises some technical challenges.
First, we would need to provide an encryption key for all
trusted loaders. This requirement would limit the use of
generic container images. Moreover, any loader executing on
a server affected by a security advisory could compromise the
encrypted content.
Our general approach is to establish trust in the loaded
enclave instead of the loader. An untrusted loader creates
the enclave. We establish trust in the created enclave using
attestation.
With the help of attestation, we want to ensure the integrity,
confidentiality, and consistency of an application’s data, code,
and secrets. In other words, we want to ensure that we can
trust the output of an application (integrity and consistency)
and that the data was not leaked (confidentiality). Since our
threat model assumes that adversaries might have root access,
we need to verify various conditions (see Fig. 1):
•the code and data initially loaded in the enclave is up-to-
date and not modified,
•the enclave is executed on a CPU with up-to-date hard-
ware and firmware,
•the state of the container image or the volumes is correct
and has not been modified,
•the enclave runs on a specific set of hosts only (option-
ally),
Funded by DFG grants 389792660 as part of TRR 248 – CPEC and
390696704 as part of CeTI.
Fig. 1. To ensure that integrity, confidentiality and consistency in hostile
environments, we need to establish trust into various components using
attestation.
•the enclave is not cloned (optionally)
In the future, we expect that we will attest to additional
components.
II. SCONE ATT ESTATION A ND VERIFICATION
SCONE [1] is a platform that enables the transformation
of native services into confidential services. The policy can
be generated automatically as part of transforming a native
application into a confidential computation. A confidential
service is automatically attested and verified by SCONE. Only
if a service satisfies its security policy, it receives its secrets
(see Fig. 2).
A local attestation service signs the report body as part of
the remote attestation. A report associates a measurement with
some other data. For example, the measurement could be a
secure hash value of the initial enclave state. Typically, the
report contains the hash of the public key of an enclave. An
application owner creates a policy that defines the expected
measurements. The policy defines the initial state of the
enclave. A policy could also require the state of the operating
system, i.e., it could limit what operating systems can be
loaded and what applications can be executed [3]. The policy
can also specify a set of hosts on which the enclave can run.
Fig. 2. Services are automatically attested during startup. After verification
against the service policy, a service gets access to its secrets.
It can define how many of the enclave instances can run at
any point in time.
We have to expect security vulnerabilities for any complex
software and hardware system. Attestation enables us to deal
with security vulnerabilities effectively. If there is any known
security vulnerability on a specific host, we need to mitigate
it before our application is permitted to execute. For example,
we have experienced that in some Kubernetes clusters, not all
servers were running the newest firmware. The confidential
applications cannot run on these servers since they do not
pass the verification. Kubernetes will detect that the startup
failed and eventually restart the service on a different node.
For Intel SGX, a large variety of security vulnerabilities
have been published, e.g., [2]. Some of the vulnerabilities, like
side-channel attacks, are outside of the original threat model
of Intel SGX and need to be mitigated in different ways. For
all known vulnerabilities of Intel SGX, Intel issues security
advisories and issues firmware patches. However, in some
cases, like Load-Value Injection [4] only new CPU hardware
can efficiently fix the issue. We verify during attestation of
an enclave if the underlying platform is affected by a security
advisory. If software mitigations are in place, we can specify
in its policy that we can tolerate this security advisory.
There are various approaches to mitigate side-channel at-
tacks. We can mitigate these attacks using oblivious memory
and/or fine-grain randomization. However, this requires a
recompilation of the binaries. Moreover, oblivious memory
introduces a very high runtime overhead. We support an
attestation-based approach [3] with minimal runtime overhead.
The idea is that we perform a load time and runtime attestation
of the operating system, and only known benign programs are
permitted to be started. Most side-channel attacks require the
execution of a program to perform this attack. The runtime
attestation will detect such an attack and prevent the start of
any unknown program. Also, this will result in the stop of the
enclaves running on this host.
A modern cloud-native application consists of a set of
services. These services communicate via the network with
each other. One can ensure that a service is part of the same
application with the help of implicit attestation. Each service
is provisioned with service and client certificates as part of
the attestation process. The client and service certificates
are issued by a certificate authority that is unique for each
application instance. This ensures that only services belonging
to the same application instance can communicate with each
other via mutual TLS (mTLS).
III. GEN ER AL AP PROACH
Having a large number of policies, it can become quite
complex to ensure that all components of an application are
indeed sufficiently protected. Our research focuses on how to
verify automatically that the policies of an application protect
all data, code, and secrets:
•Can only services - except the ingress service - of the
application communicate only with each other?
•Is data at rest always protected and only accessible by
the application’s services?
•Can administrators of the service see neither any secrets
nor any data?
•Does any change of a policy require approval by the
application owner?
•Can we perform secure software updates?
Our general approach is to be able to answer these questions
automatically using formal methods. Given the complexity of
the problem, one of the major challenges is to select a suitable
level of abstraction for the formal model to ensure practical
runtimes. The formal model is planned to be coupled with
SCONE, but independent of Intel SGX.
IV. CONCLUSION
Since remote attestation bootstraps the trust in remote ap-
plications, any vulnerability in the attestation mechanism can
impact the security of an application. Hence, we investigate
the use of formal methods 1) to ensure the correctness of the
attestation mechanisms and 2) to verify that the policies of an
application sufficiently protect the services, the data, the code,
and the secrets of an application.
REFERENCES
[1] Sergei Arnautov et al. “SCONE: Secure Linux Con-
tainers with Intel SGX”. In: USENIX Symposium on
Operating Systems Design and Implementation. 2016,
pp. 689–703.
[2] Kit Murdock et al. “Plundervolt: Software-based fault
injection attacks against Intel SGX”. In: 2020 IEEE
Symposium on Security and Privacy (SP). IEEE. 2020,
pp. 1466–1482.
[3] Wojciech Ozga, Do Le Quoc, and Christof Fetzer. “A
practical approach for updating an integrity-enforced op-
erating system”. In: Proceedings of the 21st International
Middleware Conference. 2020, pp. 311–325.
[4] Jo Van Bulck et al. “LVI: Hijacking transient execution
through microarchitectural load value injection”. In: 2020
IEEE Symposium on Security and Privacy (SP). IEEE.
2020, pp. 54–72.
