Arguing Assurance in Trusted Execution Environments using Goal Structuring Notation

Linköpings universitet SE–581 83 Linköping +46 13 28 10 00 , www.liu.se

Linköping University | Department of Computer and Information Science

Master’s thesis, 30 ECTS | Datateknik

21 | LIU-IDA/LITH-EX-A--21/058--SE

Arguing Assurance in Trusted

Ex-ecution Environments using Goal

Structuring Notation

Argumentera assurans i trusted execution environment med

goal structuring notation

Nigel Cole

Supervisor : Felipe Boeira Examiner : Mikael Asplund

Upphovsrätt

Detta dokument hålls tillgängligt på Internet - eller dess framtida ersättare - under 25 år från publicer-ingsdatum under förutsättning att inga extraordinära omständigheter uppstår.

Tillgång till dokumentet innebär tillstånd för var och en att läsa, ladda ner, skriva ut enstaka ko-pior för enskilt bruk och att använda det oförändrat för ickekommersiell forskning och för undervis-ning. Överföring av upphovsrätten vid en senare tidpunkt kan inte upphäva detta tillstånd. All annan användning av dokumentet kräver upphovsmannens medgivande. För att garantera äktheten, säker-heten och tillgängligsäker-heten finns lösningar av teknisk och administrativ art.

Upphovsmannens ideella rätt innefattar rätt att bli nämnd som upphovsman i den omfattning som god sed kräver vid användning av dokumentet på ovan beskrivna sätt samt skydd mot att dokumentet ändras eller presenteras i sådan form eller i sådant sammanhang som är kränkande för upphovsman-nens litterära eller konstnärliga anseende eller egenart.

För ytterligare information om Linköping University Electronic Press se förlagets hemsida http://www.ep.liu.se/.

Copyright

The publishers will keep this document online on the Internet - or its possible replacement - for a period of 25 years starting from the date of publication barring exceptional circumstances.

The online availability of the document implies permanent permission for anyone to read, to down-load, or to print out single copies for his/hers own use and to use it unchanged for non-commercial research and educational purpose. Subsequent transfers of copyright cannot revoke this permission. All other uses of the document are conditional upon the consent of the copyright owner. The publisher has taken technical and administrative measures to assure authenticity, security and accessibility.

According to intellectual property law the author has the right to be mentioned when his/her work is accessed as described above and to be protected against infringement.

For additional information about the Linköping University Electronic Press and its procedures for publication and for assurance of document integrity, please refer to its www home page: http://www.ep.liu.se/.

Abstract

A trusted execution environment (TEE) is an isolated environment used for trusted execu-tion. TEE solutions are usually proprietary and specific for a certain hardware specifica-tion, thereby limiting developers that use those TEEs. A potential solution to this issue is the use of open-source alternatives such as the TEE framework Keystone and the Reduced Instruction Set Computer V (RISC-V) hardware. These alternatives are rather young and are not as well established as the variants developed by ARM and Intel. To this end, the assurance in Keystone and RISC-V are analysed by studying a remote attestation assurance use case using the goal structuring notation (GSN) method. The aim is to investigate how GSN can be utilised to build assurance cases for TEEs on RISC-V. This thesis presents a process of how GSNs can be created to argue assurance for a TEE solution. Furthermore, Keystone operates under a specific threat model with made assumptions that may have a large impact depending on the use case. Therefore, Keystone is analysed to understand whether the framework mitigates existing vulnerabilities in TEEs. It is concluded that GSN is a viable method for arguing assurance in TEEs, providing great freedom in the creation of the GSN model. The freedom is also its weakness since the argument composition has a high impact on the argument. Furthermore, we conclude that Keystone mitigates multi-ple known vulnerabilities primarily through made assumptions in its threat model. These cases need to be considered by developers utilising Keystone to determine whether or not the assumptions are valid for their use case.

Acknowledgments

I would like to thank my supervisor Christian Vestlund at Sectra AB for the constant support and valuable feedback throughout this thesis. Also, I am thankful to Lisa Lindstrand and Sectra AB for providing both the opportunity and the resources during the thesis work. From Linköping University, I would like to thank my examiner Mikael Asplund and my supervisor Felipe Boeira for their help during various stages of the thesis.

I want to give a special thanks to my parents John and Luisa that have supported me through all of life’s obstacles.

Contents

Abstract iii

Acknowledgments iv

Contents v

List of Figures vii

List of Tables viii

1 Introduction 1 1.1 Motivation . . . 1 1.2 Aim . . . 2 1.3 Research questions . . . 3 1.4 Delimitations . . . 3 1.5 Method Overview . . . 3 2 Theory 4 2.1 Trust . . . 4 2.2 Remote Attestation . . . 5 2.3 Separation Kernel . . . 5

2.4 Trusted Execution Environment . . . 5

2.5 Keystone . . . 6

2.6 Keystone threat model . . . 6

2.7 Assurance . . . 8

2.8 Goal Structuring Notation . . . 8

3 Related Work 12 4 Method 14 4.1 Method choice for evaluating the assurance case . . . 14

4.2 Creating assurance cases for GSN . . . 15

4.3 Five principles of remote attestation GSN . . . 16

4.4 Lightweight Remote Attestation for Constrained RISC-V (LIRA-V) GSN . . . . 16

4.5 SRACARE: Secure Remote Attestation with Code Authentication and Re-silience Engine GSN . . . 16

4.6 TEE remote attestation GSN . . . 17

4.7 Isolation TEE GSN . . . 17

4.8 Analysing how Keystone mitigates TEE vulnerabilities . . . 17

5 Results 19 5.1 GSN results . . . 19

6 Discussion 37

6.1 Results . . . 37

6.2 Method . . . 38

6.3 Contributions to the Keystone project . . . 39

6.4 The work in a wider context . . . 39

7 Conclusion 40 7.1 How can the GSN method be utilised to create a remote attestation assurance case for TEEs? . . . 40

7.2 Does Keystone, under its defined threat model, mitigate the vulnerabilities published by Cerdeira et al.? . . . 40

7.3 Future work . . . 41

Bibliography 42

List of Figures

2.1 A representation of the relations between all areas. . . 4

2.2 Keystone overview of the different core components. . . 7

2.3 The elements used in GSN. . . 9

2.4 The elements that the GSN Community Standard added. . . 9

2.5 The recursive six-step process for creating GSNs with the top-down method. . . . 10

2.6 A GSN example. Colouring is added by us and is not part of the GSNCS. . . 11

4.1 Overview of the method and how the different areas are related. . . 14

4.2 The assumed assurance case versus the actual assurance case. . . 15

5.1 Overview of how the GSNs are related. . . 19

5.2 The remote attestation GSN created according to the five principles by Coker et al. 20 5.3 The LIRA-V Article GSN that is an interpretation of the article by Shepherd et al. . 21

5.4 The measurement module for the LIRA-V GSN. . . 22

5.5 The LIRA-V TEE GSN that is derived from the LIRA-V GSNs. . . 23

5.6 The SRACARE GSN that is derived from the article by Dave et al. . . 24

5.7 The TEE GSN that is derived from the GSNs in Figures 5.2, 5.5, and 5.6. . . 25

5.8 The Isolation GSN that argues that the TEE isolation is acceptably secure. . . 28

5.9 The mitigation results of Keystone. . . 31

List of Tables

2.1 The different attack models that are part of the Keystone threat model. . . 7

4.1 Description of how the each vulnerability is judged. . . 17

5.1 Description of goals and strategies in the TEE GSN. . . 27

5.2 Description of goals and strategies in the Isolation GSN. . . 30

5.3 Relation between found vulnerabilities in the architecture and how Keystone han-dles them. . . 33

5.4 Relation between found vulnerabilities in the implementation and how Keystone handles them. . . 34

5.5 Relation between found vulnerabilities in the hardware and how Keystone han-dles them. . . 35

5.6 Relation between the found vulnerabilities and the Isolation GSN. . . 36

A.1 Vulnerabilities that are specific to architectural issues in TEEs. . . 47

A.2 Vulnerabilities that are specific to implementation issues in TEEs. . . 48

1

Introduction

This chapter presents why using open-source architecture solutions compared to proprietary solutions may be of interest. These solutions are young compared to its established variants and it is interesting to study whether they provide sufficient security for an assurance case.

This thesis was a proposal from Sectra. We were employed by Sectra during the thesis work. The company was interested in RISC-V and how the GSN method can be applied to assurance cases for TEEs.

1.1

Motivation

Trust between individuals can be established through different experiences or through a mu-tually trusted individual. Similarly, trust between entities in a computer system can be es-tablished through different methods. A difficulty lies in determining a root of trust in the system, a source that is always considered trusted by all. Also, determining whether two entities that have performed a trusted action between each other should trust each other for future actions is another difficulty.

A solution to determining whether to trust an entity is using trusted execution environ-ments (TEE) [30]. The purpose of a TEE is to give a tamper-resistant processing environment that ensures that the executed code and the runtime state integrity are protected. It also guar-antees confidentiality and that persistent memory is used when storing the code, data, and runtime states. The TEE typically uses a separation kernel, which isolates parts of a system.

Most of today’s available vendor TEEs are proprietary and specific for certain hardware. This means that users of the TEE are often limited by the design space, impacting the choice of TEE vendor. Usually, changes are only made by the vendor of the TEE, forcing users to either wait for a released update that has the needed functionality or workaround the existing limitations. An alternative to proprietary TEE solutions is the open-source TEE framework named Keystone [20]. What separates it from other TEE frameworks is that it is customisable, allowing developers to optimise the system by choosing hardware that aligns with a specific threat model. Another strength of Keystone, compared to its established ARM competitor TrustZone, is that instead of only having two isolated worlds that represent a secure world and normal world; Keystone allows for multiple isolated secure worlds.

Two of the most common instruction set architectures (ISA) used in microprocessors today are ARM and x86. These ISAs come with pre-packaged features and support that may not

1.2. Aim

always be needed for the tasks they are to perform. This contributes to wasted performance and energy [12]. Licensing is another potential issue with these ISAs. In addition to the royalties that need to be paid, there may be limitations such as not having the right to design a core and only use the design [5]. There are also great limitations to developing on these ISAs since the development process needs to be adjusted to the available features [12].

A solution to these problems is the Reduced Instruction Set Computing V (RISC-V), which is an open-source ISA that has frozen base instructions where all optional approved exten-sions are also frozen [37]. This guarantees that software developed on RISC-V will always be usable on any RISC-V [21] device. Since RISC-V is open-source and uses a reduced ISA that can add extensions, it allows developers to create optimised cores for specific tasks.

While RISC-V seems promising, it is still a young ISA that has gained a lot of traction the past year. It also has to compete with already established ISAs. There is potential though, especially since ARM was bought by NVIDIA [29] which competes with clients of ARM. That is why there are concerns for this take-over by NVIDIA [11], possibly causing clients to look for other providers.

As previously stated, the choice of hardware is affected by the threat models each choice brings. This is important since developers of secure systems usually have specific threat models depending on the product that is being developed. For instance, there may be a significant difference in the threat models for a machine that is in a secure location and a product that is meant to be in the hands of individuals. The software framework in Keystone is used to assemble the TEEs for different use cases since each one of them, for instance an application, may operate on the same platform but under different threat models. The vendor TEE solutions have inflexible specific threat models for specific hardware platforms, while Keystone allows for flexible threat models.

In this thesis we analyse the security assurance of Keystone. The authors of Keystone [20] describe a threat model where attacks such as timing side-channel attacks and transient exe-cution attacks are out of the scope. It also makes claims as to how different security risks can be mitigated by applying methods that the paper refers to. Considering these statements, one may ask what security assurances Keystone itself actually provides. It is therefore interesting to investigate and test the assurances that the framework provides.

There are different possible use cases that can be considered. In this thesis, an analysis of the assurance for remote attestation in Keystone is performed. Remote attestation is a method where an attestator remotely authenticates its state towards a challenger. The challenger then determines the level of trust towards the integrity of the attestator platform [15], an interesting use case to investigate considering the nature of TEEs.

The assurance aspects may be evaluated in different ways but one interesting method is the Goal Structuring Notation (GSN) [16]. This graphical method allows for clearly structured problem statements, useful for identifying important key elements needed to fulfil the goals. It also allows for unambiguous solutions to each goal; further emphasising the usefulness for assurance testing. A traditional requirement list may fulfill its purpose but it may be hard to understand how the requirements are related to each other in complex systems. GSN aims to provide the same requirements but also present the relation between requirements through its structure.

1.2

Aim

The purpose of this thesis is to investigate how one can use the GSN method to create assur-ance cases for TEEs on RISC-V. The assurassur-ance case is based on remote attestation where we focus on the TEE aspects and gives evidence to the isolation goals. It would be interesting to see if Keystone mitigates vulnerability threats since the framework makes assumptions in its threat model and it is therefore analysed to see which vulnerability threats found by Cerdeira et al. [6] (represented as a table in our thesis, based on our analysis of the vulnerabilities)

1.3. Research questions

that it mitigates. Stakeholders may also want to compare TEE solutions, and it is therefore interesting to see how Keystone holds up against an independent reference of vulnerabilities.

1.3

Research questions

1. How can the GSN method be utilised to create a remote attestation assurance case for TEEs?

2. Does Keystone, under its defined threat model, mitigate the vulnerabilities published by Cerdeira et al.?

1.4

Delimitations

No formal proof is given in this thesis. The focus is on TEE aspects in remote attestation, not every element in it. The evidence for the TEE GSN is not completed, instead we focused on the world isolation of the TEE GSN.

1.5

Method Overview

Firstly, we perform a theoretical study into GSN, TEEs, Keystone, and remote attestation. Then, the creation of the remote attestation GSNs is performed. After that, we narrow down the GSNs into a GSN that focuses on elements related to TEEs. The scope is further limited to the isolation aspect of TEEs. The Keystone and its threat model are then analysed to see which of the found vulnerabilities by Cerdeira et al. [6] that it mitigates.

2

Theory

This theory chapter presents the fundamentals of TEE and the GSN method. A representa-tion of how the different subjects are related is presented in Figure 2.1. These subjects are explained in this chapter.

Figure 2.1: A representation of the relations between all areas.

2.1

Trust

A term that is central for TEEs is trust. While it is widely used and understood within social relationships, the term itself may be ambiguous in the context of data security. To be clear about the meaning of trust in this thesis, we use the formal definition of trust made by Gai et al. [10] that states that each entity trusts itself and its relations to other entities if the actions between them are trusted by both. Also, as stated by Akram et al. [4], trust could be based on past experience, but there may be security risks in that statement since a performed trusted action should not implicate that all future actions are trusted. Therefore, we consider trust to

2.2. Remote Attestation

be a relation between entities where each entity trusts each other depending on actions and initialised settings.

2.2

Remote Attestation

For an entity to determine the level of trust it has towards the integrity of another entity’s platform, one could use remote attestation. It is a method where an attestator remotely au-thenticates its state towards a challenger. The challenger then determines the level of trust towards the integrity of the attestator platform [15]. There are two main components for the remote attestation, an architecture for integrity measurement and then a protocol for the remote attestation [15].

The implementation for measuring integrity is quite consistent. It is usually a measure-ment of hardware and software on the platform during the boot up sequence but may differ depending on the architecture of the remote attestation. There is a greater difference between the protocols that can be used [35, 15, 7]. Essentially, there are different protocols used to ensure the integrity of the remote attestation and mitigate security vulnerabilities.

2.3

Separation Kernel

To isolate the environments in a system, a separation kernel is typically used. It is an en-tity that simulates the system as a distributed system by isolating the system into different parts. Separation kernel solutions differ in how much is done by either software or hardware. The ARM TrustZone [27] mainly uses hardware separation that allows for two environments while Keystone [20] mainly uses software to separate environments, but relies on the hard-ware component physical memory protection (PMP) that RISC-V platforms provide as an optional extension. The purpose of a separation kernel is to enable multiple environments that may differ in security level requirements while still existing on the same hardware [30]. It initialises the environments, isolates them and controls the information flow between the environments. There are four main policies for the security requirements given by Sabt et al. [30]:

1. Data separation: Isolated data within its own environment can be neither read or mod-ified by other environments.

2. Sanitisation: Information cannot be leaked into other environments through the shared resources.

3. Information flow control: No unauthorised communications between environments. 4. Fault isolation: Security breach in an environment is isolated from the other

environ-ments.

2.4

Trusted Execution Environment

A TEE is an isolated environment used for trusted execution. It is isolated from other entities in the sense that it can perform secure executions, meaning that the nature and results of the executions are protected, and also have a secure storage for data and cryptography keys [31]. The isolation allows the TEE to only interact upon requests from entities that it trusts.

The TEE is built on a trusted platform, which is essentially a system of components that verifies its own integrity. It performs a secure boot, which can be read in detail in the work by Shepherd et al. [31], that ensures that the system is considered trusted and reliable by comparing hash values. Using virtualisation, a trusted execution environment can be created that allows code to be executed in isolation, thereby separating data from outside entities.

2.5. Keystone

This may be of interest when there is sensitive data that is meant to be hidden from certain entities.

Using the separation kernel, the isolated environments trusts its own integrity and confi-dentiality of the code it executes, the stored data, and the runtime states (a state that imple-ments necessary functionality). It is able to provide remote attestation to prove trustworthi-ness. The TEE is resistant towards software attacks and also physical memory attacks [30].

The exact implementation of a TEE is different depending on framework. Although the goal of protecting a TEE in a normal environment is shared between TEE implementations, there is a difference in how much of the goal is fulfilled by either the hardware or software. For instance, TrustZone [27] is hardware separated into a secure world and a normal world while Keystone [20] uses a physical memory protection hardware component to isolate mem-ory into partitions, allowing for multiple secure worlds.

2.5

Keystone

The open-source Keystone [20, 18] framework is used to create TEEs for RISC-V platforms. It relies on RISC-V features such as the physical memory protection and the software privilege levels (lowest to highest): user-mode (U-mode), supervisor mode (S-mode), and machine mode (M-mode). The PMP is used for isolating memory for each environment while the different modes have varying limits as to what can be done in these modes.

Keystone TEEs have two components, enclave application (eapp) and runtime (RT). The eapp is an application the developer creates and the RT implements necessary functionality such as systems calls. The eapp runs in U-mode and the RT runs in S-mode. Other ap-plications that are not eapps run in U-mode, the same privilege level as the eapp but are considered untrusted. Similarly, the untrusted operating system runs in S-mode, same as RT. The enclaves, i.e. each respective pair of eapp and RT, are considered trusted.

The security monitor (SM) operates in M-mode and is also considered trusted. There are no untrusted environments in M-mode. The SM uses a small trusted computing base (TCB) to provide an interface for managing enclaves while also utilising features that are platform-specific. Most of the security guarantees that Keystone provides is enforced by the SM. It manages the isolation between the TEEs and the untrusted OS.

Keystone relies on trusted hardware that is built by trustworthy vendors. The trusted hardware must use Keystone-compatible standard RISC-V cores and root of trust. This means that the hardware has all privilege modes (Machine-mode, Supervisor-mode, and User-mode) that are used to protect memory and execution. Extensions for hardware may be added but the SM requires platform specific plug-ins in that case. An overview of Key-stone can be seen in Figure 2.2. In the figure, the previously mentioned privilege modes show what exists in each privilege level. The SM uses the PMP to create the different enclaves and handles the permission configuration whenever it initialises secure worlds or transfers con-trol to applications.

2.6

Keystone threat model

Keystone is a modular TEE framework which is intended to be adaptable to different threat models. Nonetheless, Keystone has a threat model that is argued from a security perspective by the Lee et al. Below, the trust relations between the different components in Keystone are described, followed by the attacker models that the threat model has considered.

Trust relations in Keystone

Keystone is designed with a hierarchy of trust levels. Each entity has a trust relation to an-other, i.e. what trusts what. The list below describes what each Keystone entity trusts.

2.6. Keystone threat model

Figure 2.2: Keystone overview of the different core components.

• Keystone relies on RISC-V and trusts that the PMP specification, PMP, and RISC-V hard-ware implementations are bug-free.

• The Keystone user trusts the SM once the SM measurement of the image is correct, signed by trusted hardware and is of the expected version.

• The SM trusts the hardware. • The host trusts the SM. • The RT trusts the SM.

• The eapp trusts both the SM and RT.

Attacker models in the Keystone threat model

Table 2.1 describes the different attack models that the Keystone threat model considers.

Name Assumptions

Physical attacker (APhy) Signals that leave the chip package can be

inter-cepted, modified, or replayed. Components inside the chip package cannot be affected by APhy.

Software attacker (ASW) The attacker can control the host applications, the

un-trusted OS, network communications, launch adver-sarial enclaves, arbitrarily modify any unprotected (by the TEE) memory, and add/drop/replay enclave messages.

Side-channel attacker (ASC) Information can be obtained by observing

interac-tions between the trusted and the untrusted compo-nents through the cache side channel, the timing side channel or the controlled channel.

Denial-of-service attacker (ADoS) The enclave or the host OS can be taken down by the

attacker. Since an OS can refuce services to user ap-plications at any time, Keystone allows the OS to DoS enclaves.

2.7. Assurance

Scope of the Keystone threat model

Lee et al. state that Keystone does not provide certain protections, but can be added through referenced articles. We do not evaluate whether or not the implementation of the referenced articles would provide the required protection.

• Keystone does not protect against speculative execution attacks.

• Keystone does not natively protect the SM or enclaves against timing side-channel at-tacks.

• Off-chip components, such as a memory bus, are out of scope of the paper by Lee et al. [20].

• The limited API of the SM, that the host OS and the enclave have access to, is not guar-anteed to provide non-interference.

• Untrusted system calls into the host OS can optionally be performed by the RT.

• The RT and the eapp are assumed to have checks to detect Iago attacks via the untrusted API.

• Keystone assumes that the SM, RT and eapp are bug-free.

2.7

Assurance

The term assurance in computer security refers to the measure of confidence when determin-ing that a safety claim is true [36]. Assurance in itself is subjective, makdetermin-ing it hard to deter-mine the degree of assurance for a assurance case and its arguments. Therefore, assurance in this thesis will need to be formulated.

For this thesis, which focuses on the assurance aspect of the Keystone framework, the GSN extension described by Kelly et al. [16] is of interest. In the article, Kelly et al. state that the security arguments that are strongest are designed to be both valid and sound. Valid means that the conclusion is true if the assertion is true. Sound means the argument is valid and has assertions that are true. It states that valid and sound arguments are unobtainable and therefore GSN accepts a modified version of the valid and sound arguments. These are called consistent arguments and state that if the assertions are true then the conclusion may be true, which in turn means that the argument is weaker.

The assurance of these arguments lie in the conclusion and the likelihood of assertions being true, and to what degree the assertions affect the conclusion, is what the assurance of the argument is based on. The assurance of the main goal of an argument is considered the overall assurance for that argument.

2.8

Goal Structuring Notation

The goal structuring notation [16] method is used to explicitly define an assurance case, a case that, for a specific environment, provides a convincing argument that a system is acceptably assured. It does this by graphically representing core elements and the relationships between them. These core elements are:

• Goal – A claim about the system. • Strategy – A means to address a goal. • Solution – Evidence to support claims. • Context – The scope or made assertions.

2.8. Goal Structuring Notation

• Undeveloped Goal – A goal that is to be developed further.

They are represented as figures where each relation between two elements is represented as an arrow, see Figure 2.3.

Figure 2.3: The elements used in GSN.

Structuring a security case with these elements creates the Goal structure, see Figure 2.6. Acquiring evidence for the solutions will determine whether or not the sub-goals are accept-ably fulfilled, thereafter determining the outcome of the main goal.

The GSN community standard (GSNCS) [1] further develops the GSN method and adds the core elements:

• Assumption – An intentionally unsubstantiated statement. • Justification – A rationale statement.

• Undeveloped element decorator – Undeveloped argument that can be applied to goals and strategies.

These elements are represented in Figure 2.4.

Figure 2.4: The elements that the GSN Community Standard added.

The relations between the elements are also updated. Instead of a normal arrow for a general relationship, an arrow with a solid arrowhead represents SupportedBy which means that a goal is supported by another goal, strategy or solution. It can also be used for a strategy that is supported by a goal. There is also an arrow with a hollow arrowhead that represents InContextOf which is used to declare a contextual relationship between a goal and context, assumption or justification. It can also be used between a strategy and context, assumption or justification.

The GSNCS focuses on assurance cases. Since assurance is subjective, it may seem to be counter-intuitive to create a GSN that requires evidence to determine the fulfilment of a goal.

2.8. Goal Structuring Notation

As mentioned in the assurance section above, the assurance will be determined based on the likelihood that the assertion is true and to what degree the assertions affect the conclusion.

There are two methods described in the GSNCS, “The GSN Six-Step Method” that is ob-tained from the method given by Kelly [17] and the Bottom-Up Method. “The GSN Six-Step Method” is a top-down method that focuses on creating goals as the starting point. These goals are then supported by strategies, goals and solutions. Figure 2.5 shows the six-step process from the GSNCS. The first step is to identify a goal that is to be added to the GSN.

Figure 2.5: The recursive six-step process for creating GSNs with the top-down method. In the second step the context of this goal needs to be explicitly stated. Then, for the third step there may be a need for a strategy to support the new goal. In step four the strategy needs to be justified similarly to step two. Step five is taken when the goal needs to be further developed since there does not exist a sufficient and detailed goal that can be fulfilled with a solution. If the claim is at a level where a solution can be connected, step six is taken instead where a solution is identified. This does not mean that every goal or strategy needs an added context if it is already understood from the context of higher level goals or through clearly motivated sub-goals. The bottom-up method focuses instead on the available evidence to use as solutions but is not used in this thesis. An example of how a GSN can look like is presented in Figure 2.6.

2.8. Goal Structuring Notation

3

Related Work

A common theme in the articles presented in this chapter [19, 32, 40] is that TEEs are secure and provide high assurance, which in itself is understandable considering that TEEs may not be the main focus of the article. However, assurance in TEEs does not seem to be evaluated. While not directly related to the evaluation of TEE assurance, there exists work that relies on the assurance of TEEs.

Koeberl et al. [19] proposes a TEE-based approach to allow different parties to gain access to computation capabilities and data. It states that the parties agree upon security assurances beforehand. The proposed model is completely reliant on the assumption that TEEs provide good assurance. The article states that the assurance depends on the implementation of the TEE and that the analysis of the security of TEEs needs to be further researched. Further-more, it states that while there exists multiple TEE solutions, their security properties differ, possibly revealing TEE shortcomings when TEE solutions are employed for various usages. This further emphasises the need for evaluating the assurance of TEEs.

Shepherd et al. [32] suggest a protocol design that uses a two way remote attestation be-tween two TEEs to achieve bi-directional trust assurance. This protocol relies on a TEE that follows the GlobalPlatform TEE Protection Profile. The article refers to version 1.2 which has since been updated to version 1.3, the version we possess. Shepherd et al. also compare dif-ferent TEE solutions for the proposed protocol, focusing on what each TEE provides in terms of native security features. These features are considered to be assurances for the design of the bi-directional remote attestation. The authors also state that they assume that the TEE has a secure procedure for key generation, derivation, and random number generation. The issue remains of how to actually evaluate the assurances that each TEE solution provides.

Yan et al. [40] references articles to different challenges in trusted computing. One key challenge area is the evaluation of trust in trusted computing. A couple of the challenges the articles highlights are ensuring trust of trusted computing, and TEE trust verification. The article presents two articles [38][41] that suggests measures for trust evaluation. While these articles do not focus on TEEs, it shows the importance of evaluating trust in trusted computing.

The GSN by Kelly et al. [16] has been added to the D-Case Editor [24], an eclipse extension for crafting graphical notation system, by Matsuno [22, 26]. The articles by Matsuno discuss the importance of assurance case languages and provide formal definitions for GSN. Matsuno

argues that the growing importance of assurance cases requires a designed and implemented assurance case language.

Denney et al. [9] present an assurance case automation tool that is meant to build and transform safety cases. It uses an extended version of GSN to support the tool, and is used to create a safety case in the Swift Unmanned Aircraft System that NASA Ames is developing.

Yamamoto [39] provides a method to add attributes in GSN which are used to denote security. The attributes are given a value ranging from very unsatisfied to very satisfied. Yamamoto also provides a use case for a LAN Device Management System.

There exists other works [23, 14] that either implement GSN assurance cases directly or develop GSN with extensions and other techniques. It is clear that there exists a great interest in building assurance cases with GSN. Matsuno [25] has made a push to spread assurance cases in Japan. There still exists concerns but progress is being made and while, to the best of our knowledge, no GSN TEE assurance cases exists; it is completely possible to build such cases. It gives the confidence that this thesis is possible to perform.

4

Method

This chapter presents how the thesis work was conducted. First, the process of how the GSNs are created is presented. The process involves creating GSNs out of three remote attestation articles that are then used as a base for creating the TEE GSN and the Isolation GSN. Then, the process of analysing how Keystone mitigates known vulnerabilities is presented. Figure 4.1 shows an overview of the method and the relation between the two areas in this thesis.

Figure 4.1: Overview of the method and how the different areas are related.

4.1

Method choice for evaluating the assurance case

The choice of using GSN as the method for the assurance case was made after looking up different methods for assurance cases. There was no significant effort put into researching as-surance case methods. GSN was the recommendation of our supervisor at Sectra and seemed to be an interesting choice since it seems that it is becoming more popular. There exists other similar methods to GSN, such as the Claims Arguments Evidence (CAE) [3] [2] but compared to GSN, there exists no standard for CAE to the best of our knowledge. Also, the structures

4.2. Creating assurance cases for GSN

differ in how a goal or claim is argued. The CAE has an optional argument element while the structuring of the GSN goals is the actual representation of arguments [13]. Since there exists a community standard for GSN, this thesis uses the GSN method.

4.2

Creating assurance cases for GSN

The quote below is taken from the GSNCS. It is what the GSN assurance case should repre-sent.

A reasoned and compelling argument, supported by a body of evidence, that a system, service or organisation will operate as intended for a defined application in a defined environment [1].

Remote attestation may require many measures, and creating a GSN assurance case for that goal is complex. Since the focus of this thesis is assurance in TEEs, the remote attestation assurance case is presented but not evaluated. Instead, a GSN assurance case representing the TEE related goals is created and studied.

As stated, the main goal of the overall assurance case is to perform a remote attestation. This goal is then supported by sub-goals and other GSN elements. As mentioned by Habli et al. [13], there may be a false sense of truthfulness in the use of GSN. They state that there may be a big difference in the assumed safety case and the actual safety case. For an assurance case, there may be arguments that are missing which may lead to the GSN resulting in false assurance. Habli et al. [13] present a figure to represent the scope of assumed safety cases versus the actual safety cases. Figure 4.2 is an assurance case version of that figure.

Figure 4.2: The assumed assurance case versus the actual assurance case.

To mitigate this risk, the GSNCS is studied to understand the process of creating a GSN. While this standard does describe how to develop and evaluate GSNs, it does not aid in the creation of explicit argument elements. To this end, three different remote attestation GSNs are created, from which a TEE GSN is derived. The first one is the five principles for remote attestation described by Coker et al. [7]. This GSN is considered a broad view of remote attestation. The second one is a remote attestation for RISC-V by Shepherd et al. [33]. The GSN is made by first building an assurance case using the articles’ proposed solutions as evidence, and then modifying it so that TEE specific goals can be identified. The third one is also a RISC-V remote attestation by Dave et al. [8] that has derived its security properties from an article by Nunes et al. [28]. Using these three remote attestation GSNs, the TEE GSN aims to fulfil the TEE specific elements in each remote attestation GSN.

The assurance cases are built using the guidelines in GSNCS. They state that goals are to be the logical backbone of the argument. The goals are meant to convince the readers that the argument’s conclusion is acceptable. The claims that the goals represent are ordered in a way that has the most abstract claim at the top-level while the lower goals become more explicit for each level down. The lowest goals have some form of assertion or evidence that supports it. The strategy elements are inserted in different parts of the GSN where it is required.

4.3. Five principles of remote attestation GSN

The first step is choosing which GSN method would work best for the remote attestation assurance case using Keystone. This choice is dependent on what evidence exists. There are security claims made by the Keystone article [20] that uses a specific threat model. Keystone also relies on the RISC-V architecture. These elements are therefore not considered as evi-dence and are instead regarded as assumptions or undeveloped elements that need provided evidence. Therefore, the top-down method (see Section 2.8) is used when creating the remote attestation GSNs.

The GSNCS module extension is used in this thesis to group goals that are to be developed in another GSN. Each remote attestation assurance case has goals that are connected to a TEE module. This TEE module develops these goals further.

4.3

Five principles of remote attestation GSN

The first step is to identify goals from the five principles described by Coker et al. [7]. This is done by structuring up the different issues the principles are meant to mitigate. Coker et al. describe five constraints that are derived from their interpretation of the principles. These constraints are used together with identified goals that we procured from the principles as goal elements in the GSN.

The GSN main goal is to perform an acceptably secure remote attestation, just like the other remote attestation GSNs in this thesis. To ensure that each principle is upheld, a strategy element is added under the main goal. This strategy is meant to ensure that each principle is implemented and it has therefore got five sub-goals, one for each principle. These principles are placed over the identified goals that were mentioned earlier. There are no solutions since the main focus of this thesis is the TEE aspect. Instead, the bottom of the GSN has a TEE module that is meant to provide solutions to the connected goals. There are also undeveloped goals which represent the goals that are out of scope since they are not directly related to TEEs.

4.4

Lightweight Remote Attestation for Constrained RISC-V (LIRA-V)

GSN

Shepherd et al. [33] present a remote attestation solution that leverages the RISC-V PMP. The LIRA-V GSN is created by interpreting the goals, arguments, and proposed solutions that Shepherd et al. provided. We add a strategy node for the communication procedure, but it does not affect the arguments. The solutions are slightly modified (removed in-article references) in the GSN.

Using this LIRA-V GSN, a new LIRA-V TEE GSN is created that represents what goals are considered to be solved by the TEE. The goals in the LIRA-V TEE GSN are meant to be generalised and not explicitly linked to the RISC-V architecture that the article by Shepherd et al. presented, e.g. memory isolation instead of PMP configuration. The goals “Acceptably secure protocol” and “Formal verification” are considered undeveloped since a protocol is not directly related to TEEs, and formal verification is out of scope for this thesis. The rest of the goals are connected to the TEE module where they are developed further.

4.5

SRACARE: Secure Remote Attestation with Code Authentication and

Resilience Engine GSN

Dave et al. [8] present SRACARE which is used as the base for the remote attestation SRACARE GSN. SRACARE presents a remote attestation security model which derived its security properties from an article by Nunes et al. [28]. The goals for the security model were already divided into sub-goals and are therefore only slightly modified to fit into the GSN.

4.8. Analysing how Keystone mitigates TEE vulnerabilities

4.6

TEE remote attestation GSN

The TEE GSN is created by using the previously mentioned remote attestation GSNs. When comparing the GSNs, one can see that the levels of the goals are not always the same as their respective remote attestation GSN. Instead, they are moved around where certain goals are placed as sub-goals for others. Some goals are also very similar but worded differently and are therefore merged into a single goal when applicable. Each goal and strategy have an ID which is described in Table 5.1.

4.7

Isolation TEE GSN

The Isolation TEE GSN argues that Keystone is able to perform acceptably secure isolation. It takes the TEE GSN goals that are related to the Isolation module and further develops them by breaking the goals down into sub-goals.

All provided solutions are taken from the Keystone article. Since the top-level goals are derived from three independent articles, we built the GSN by adding goals that could link the solutions to the goals that needed to be fulfilled. The elements of the GSN are described in Table 5.2.

4.8

Analysing how Keystone mitigates TEE vulnerabilities

Cerdeira et al. [6] present security vulnerabilities in TEE systems, specifically TrustZone-assisted TEE solutions. Because of the context of the vulnerabilities, stated as issues, they may or may not be directly applicable to every TEE solution. Nonetheless, they may be anal-ysed to see which vulnerabilities Keystone mitigates through the Keystone threat model, its implementation, and its assumptions. It is important to note that the vulnerabilities are only found vulnerabilities in a certain time span and do not represent all vulnerabilities, since that would be impossible because there is not a finite amount of vulnerabilities and attacks.

The vulnerabilities are mapped to Keystone to see which vulnerabilities the framework mitigates, partially mitigates, does not mitigate, or makes assumptions about. Cerdeira et al. present possible defences to these vulnerabilities while Lee et al. [20] present a security evaluation based on their threat model. These are not the focus of this analysis. Instead, the aim of the analysis is to check whether or not the Keystone threat model and its implemen-tation can be considered acceptably secure, i.e. that Keystone and its threat model are not lacking any threats found by Cerdeira et al. The information that is analysed together with the vulnerabilities are interpretations of the Keystone article [20], made by us.

Criteria for judging issues

Outcome Description

Mitigated Keystone mitigates the related issue either through design, imple-mentation or tests.

Partially mitigated Keystone mitigates parts of the issue but not all aspects.

Not mitigated Keystone neither mitigates nor partially mitigates the issue.

Assumption Keystone has made an assumption that either resigns the issue or has a designed implementation mitigation solution that is built upon assumptions.

4.8. Analysing how Keystone mitigates TEE vulnerabilities

Table 4.1: Description of how the each vulnerability is judged.

The Isolation GSN in relation to the vulnerabilities

The Isolation GSN is analysed to see what vulnerabilities it addresses that were found in the analysis between Keystone and the vulnerabilities. It is done by analysing the goals, strate-gies, and evidence that the Isolation GSN provides to see if the GSN provides the same infor-mation as the analysis of Keystone and the vulnerabilities. Since it focuses on the isolation aspect of Keystone, there may be many vulnerabilities that are not addressed.

5

Results

This chapter presents the acquired results. The GSN results are for the first research ques-tion of how the GSN method can be utilised to create assurance cases for TEEs. The second research question’s results are in the analysis between TEE vulnerabilities and Keystone sec-tion.

5.1

GSN results

This section presents the acquired GSN results. There are three remote attestation GSNs, one TEE GSN and one isolation GSN. Figure 5.1 shows how the different GSNs are connected. Each GSN will be presented with a short description.

5.1. GSN results

Five principles remote attestation GSN

In Figure 5.2 we see the GSN that was created by using the five principles by Coker et al. [7]. This GSN presents a generalised remote attestation that is meant to cover the broader view for the TEE GSN. The goals that are undeveloped are out of scope since it is not solved by TEEs or out of scope (in this case the protocol). The other goals that are connected to the TEE module are goals that are to be argued for by the TEE GSN.

Figure 5.2: The remote attestation GSN created according to the five principles by Coker et al.

5.1. GSN results

Lightweight Remote Attestation for Constrained RISC-V GSN

The LIRA-V [33] GSN is a RISC-V based remote attestation GSN which can be seen in Fig-ure 5.5. It was created by using the GSNs depicted in FigFig-ure 5.3 and FigFig-ure 5.4. The LIRA-V GSN is one of the two RISC-V specific remote attestation solutions. The provided solutions are taken from the article and are not essential for this thesis but are presented for complete-ness.

LIRA-V Article GSN

Figure 5.3: The LIRA-V Article GSN that is an interpretation of the article by Shepherd et al.

LIRA-V Measurement module

5.1. GSN results Figur e 5.4: The measur ement module for the LIRA-V GSN.

5.1. GSN results

LIRA-V TEE GSN

Figure 5.5 is the resulting LIRA-V TEE GSN that is created by using the GSNs depicted in Figure 5.3 and Figure 5.4.

5.1. GSN results

SRACARE: Secure Remote Attestation with Code Authentication and Resilience

Engine GSN

The SRACARE GSN is the second GSN of the two RISC-V specific remote attestation solu-tions.

5.1. GSN results

GSN for the TEE Module

This GSN argues that TEEs can fulfil related remote attestation goals. It is based on the three presented remote attestation GSNs. The elements from the other three TEE GSNs, 5.2, 5.5, and 5.6, have been merged when applicable since certain goals have the same aim but are worded differently. These goals have then been further developed to a point where evidence are needed. They can be further developed to a low level, but for this thesis the scope has been limited to a higher level. Also, the right side of the GSN is considered protocol specific which is out of scope, and therefore marked as undeveloped goals. The goals of interest are connected to the Isolation module which further develops the goals and adds evidence. The elements are described in Table 5.1.

Figure 5.7: The TEE GSN that is derived from the GSNs in Figures 5.2, 5.5, and 5.6.

Goals and strategies in TEE GSN

ID Description

<G0> The top goal of the TEE module is created to give context to the argument that is built using the various goals from the other remote attestation GSNs.

5.1. GSN results

<S1> The reasoning of this strategy is that a TEE would be considered secure if every entity is protected from outside influence where the only way data is transferred in and out of the entity is through a secure communication channel.

<G1> The remote attestation GSNs emphasise the importance of protecting the target, verifier, key, and measurement tools since these provide the fundamental data used to perform the actual remote attestation.

<G2> Since entities are considered to be protected from untrusted outside influence, some form of communication must be established so that data can be shared between entities.

<S2> For TEEs, isolation is used as a means to protect entities from outside influence. This allows for controlled access to the entity, limiting the possibility of compro-mising the integrity and confidentiality of the entity.

<S3> With isolation comes the challenge of communication between entities. There needs to be an established protocol that is followed by all concerned parties.

<G3> The entity that is being measured shall not have access to the measure tool state. This is to ensure the trustworthiness of the measurement. The purpose of <G3> and <G4> is to explicitly define the relation between the measuring entity and the targeted entity.

<G4> The entity that is performing the measurement should have access to the targeted entity. The purpose of <G3> and <G4> is to explicitly define the relation between the measuring entity and the targeted entity.

<G5> The key should be protected and kept secret. For the case of TEE, the confiden-tiality is accomplished through isolation or ROM.

<G6> The purpose of this goal is to ensure that the measuring entity is not be able to compromise the integrity of the targeted entity.

<G7> Since the RISC-V is based on a privileged hierarchy, privilege escalation needs to be mitigated. This is a goal for <G1> through <S2> and also a goal for <G2> through <S3>. The reasoning is that the isolation should protect against un-trusted influence and that the protocol does not lead to unwanted outcomes.

<G8> On demand information is for acquiring fresh information.

<G9> Communication needs to be secure between concerned entities.

<G10> Most of the goals are reliant on the isolation that TEEs provide but this goal is added to clarify that <G3> and <G4> are solved using the domain isolation.

<G11> This goal is meant to protect against privilege escalation.

<G12> This goal is meant to prevent code interruption. It is not further developed since it is considered to be part of the protocol which is out of scope.

5.1. GSN results

<G13> The execution of submodules should be error free. This is is not specific for the isolation functionality and is therefore an undeveloped goal that needs to be further developed and validated through proof such as testing.

<G14> This goal is added for completeness. It is meant to explicitly state that both the TEE and related entities are working as intended, that they are bug-free.

<G15> The protocol must be secure for the use case but is out of scope for this thesis.

<G16> This goal is meant to protect against attacks such as Distributed Denial of Service (DDoS) attacks and Denial of Service (DoS) attacks.

<G17> The entities should protect against wiretapping and eavesdropping.

<S4> There needs to be some form of assurance of the isolation. TEEs on RISC-V, in the cases that have been studied in this thesis, utilise the PMP to isolate memory. The connected sub-goal <G22> is meant to ensure that the hardware, e.g. PMP, is working as intended.

<G18> The key is used to sign the encrypted data. This is depended on chosen protocol, which is out of scope.

<G19> The encryption of the data that is to be transferred follows the chosen protocol.

<G20> This goal is a part of the protocol which determines what to do depending on the outcome of the remote attestation.

<G21> There needs to be some sort of root of trust for the remote attestation. Usually a trusted measurement. Since the basis of the presented RISC-V remote attestation is heavily reliant on the PMP, it is very important that this module works as intended. <G22> focuses on the hardware itself while this goal, <G21>, can be considered a measurement of a target state or some secure and controlled configuration of the entity during boot up.

<G22> This goal is meant to ensure that the hardware, e.g. PMP, is working as intended. Table 5.1: Description of goals and strategies in the TEE GSN.

5.1. GSN results

GSN for the Isolation Module focused on Keystone

This GSN argues that the isolation mechanism in TEEs, specifically the Keystone TEE, fulfills the related remote attestation TEE GSN goals. Using the top TEE goals from the TEE GSN, a new top goal is added whose aim is that TEE isolation is acceptably secure. The elements of the GSN is described in Table 5.2. This GSN is developed based on our knowledge of TEE isolation. It is possible to develop the goals further but the level of depth is sufficient for the level of detail in the evidence that the Keystone article provides.

5.1. GSN results

Goals and strategies in the Isolation GSN

ID Description

<G23> A goal to satisfy the connected TEE GSN goals. The TEE isolation is based on Keystone.

<S5> For the isolation, a root of trust is needed. Also, the entities and keys need to be protected. The root of trust is not hardware related and is based on a secure boot. The protection of entities, including the keys, is protected through isolation.

<S6> The secure boot is meant to give a reliable root of trust, not related to a specific root of trust module or component.

<G24> The protection is based on isolation. Isolating entities allows for putting con-straints on verifiers, mitigating the risk of controlled invocation, and the possi-bility of protecting the key confidentiality by storing it in isolated memory.

<G25> Keystone uses the SM to configure privileges and is the core for Keystone TEEs. This needs to be validated since the Keystone user will not trust the SM unless the measurement is of a correct version that matches the expected hash and is signed by trusted hardware.

<G26> Added for completeness but there needs to be a form of protocol.

<G27> The key secrecy needs to be protected.

<G28> Execution of code needs to be protected to mitigate malicious intentions.

<G29> Memory needs to be protected for the isolation to be considered secure.

<G30> This root of trust goal is not considered a single component. Instead, the goal is meant to give assurance for the measurement of the security monitor. This is to assure that the measured image can be trusted.

<G31> The tools that are used for measurements need to be accurate and valid.

<G32> The protocol for remote attestation needs to be able to generate a fresh attestation key.

<G33> The generated attestation key from <G32> needs to be stored and kept confiden-tial.

<G34> The hardware-visible secret is not specified in the Keystone article but it is a component used for the signing procedure of the communication.

<G35> It should not be possible to bypass the SM and acquire a higher privilege.

<G36> There needs to be constraints on what permissions each entity has in the system. Either isolate information to protect it or grant access to information depending on what privileges the running entity has.

5.2. Analysis between TEE vulnerabilities and Keystone

<G37> <G32>needs a secure source of randomness.

<G38> The PMP needs to be initialised so that the SM is at the highest priority since it is in charge of privilege delegation. Having the highest priority ensures that lower priority entities cannot access the SM memory.

<G39> In the system, entities should be able to access memory if it has the privilege and permission to those memory regions, otherwise it should be denied access.

<G40> PMP can be considered the most import RISC-V feature and needs to be error-free.

<G41> Since there are a lot of privilege restrictions that make up the main part of the isolation; these need to be handled correctly by a trusted entity.

<G42> The configuration of the privilege permissions has to be done securely.

<E1> The described procedure is considered a root of trust since it validates the SM image, which is the core of the Keystone TEE, that configures the PMP to isolate memory. The procedure is executed at each CPU reset, which is meant to ensure that the SM image is both validated and has its own memory isolated, and is therefore considered trusted.

<E2> There needs to be reliable tools that have been validated. We have tested the remote attestation with a valid and faulty SM hash. Attestation was successful with a correct hash and unsuccessful with the faulty SM hash.

<E3> During the SM boot, the PMP isolates the SM memory as the first entry, giv-ing it the highest priority (highest privilege). Storgiv-ing the key in SM memory is therefore considered secure.

<E4> Placing SM at the highest privilege protects the memory of entities since it config-ures the PMP for all TEEs and also the OS, which is placed at the lowest priority. The SM configures the permissions when transferring control to other entities.

<E5> SM is considered trusted by entities in the system and is the core of Keystone. Table 5.2: Description of goals and strategies in the Isolation GSN.

5.2

Analysis between TEE vulnerabilities and Keystone

The analysis between Keystone and the found vulnerabilities (or issues) by Cerdeira et al. [6] (see Appendix A) does not consider the Keystone security analysis, nor the proposed solu-tions to the vulnerabilities. There are many assumpsolu-tions made which are a result of the made assumptions by the Keystone threat model. Therefore, the results have many issues where its “Outcome” is filled as “Assumption”.

For each vulnerability, an outcome will be stated together with a description of how Key-stone handles the issue. The description is an interpretation of the KeyKey-stone article [20]. As stated in the method, each outcome was given the value mitigated, partially mitigated, not mitigated, and/or assumption.

The Keystone threat model (see Section 2.6) which, together with the implementation of Keystone, are analysed to see which of the vulnerabilities found in Tables A.1, A.2, and A.3 are

5.2. Analysis between TEE vulnerabilities and Keystone

mitigated. The analysis is presented in Tables 5.3, 5.4, and 5.5. In Figure 5.9 we see a summary of the amount of vulnerabilities that are mitigated by Keystone. Figure 5.10 shows the amount of assumptions made out of the mitigation results. Each mitigation result is presented in the following subsections.

Figure 5.9: The mitigation results of Keystone.

Figure 5.10: The amount of made assumptions in the Keystone mitigation results.

Architectural issues

Table 5.3 presents the analysis between the architectural issues, or vulnerabilities, that were found by Cerdeira et al. and Keystone.

5.2. Analysis between TEE vulnerabilities and Keystone

ID Name Interpretation of Keystone Outcome TEE Attack Surface

I01 SW drivers run in the TEE kernel space

RT is part of the enclave but is separated from the enclave application.

Partially mitigated

I02 Wide interfaces between TEE system subcomponents

The SM exposes a limited API. RT can optionally per-form untrusted system calls into the host OS.

Mitigated

I03 Excessively large TEE TCBs Modular exemplar RT, Eyrie, reduces TCB and allows en-clave developers to only in-clude what is needed.

Mitigated

Isolation between normal and secure worlds I04 TAs can map physical

mem-ory in the NW

Assumes that the PMP works bug-free. Also assumes that the SM, that uses the PMP for critical isolation, is bug-free.

Assumption Mitigated

I05 Information leaks to NW through debugging chan-nels

SM memory is protected through PMP. Hardware and software stack formal verification is considered an unrelated issue by Keystone.

Assumption Partially mitigated

Memory protection mechanisms I06 Absent or weak Address

space layout randomisation (ASLR) implementations

Not considered in Keystone. Not mitigated

I07 No stack cookies, guard pages, or execution protec-tion

Not considered, except for execution protection that uses the SM and PMP which is based upon the assump-tions that they are working and bug-free.

Assumption Partially mitigated

Trust bootstrapping

I08 Lack of software-independent TEE integrity reporting

Keystone is more dependent on software for the TEE in-tegrity aspect compared to other TEE implementations. It can leverage hardware ex-tensions though, according to the article.

Assumption Partially mitigated

5.2. Analysis between TEE vulnerabilities and Keystone

I09 Ill-supported TA revocation Not considered but may be seen as an assumption made by Keystone that the enclave is protected by correct imple-mentation, PMP and is bug-free.

Assumption Not mitigated

Table 5.3: Relation between found vulnerabilities in the architecture and how Keystone han-dles them.

Implementation issues

Table 5.4 presents the analysis between the implementation issues, or vulnerabilities, that were found by Cerdeira et al. and Keystone.

ID Name Interpretation of Keystone Outcome Validation bugs

I10 Validation bugs within the secure monitor

Keystone assumes that the SM is bug-free but has tests in the SM for testing the en-claves and the PMP.

Assumption Mitigated

I11 Validation bugs within TAs Keystone assumes that the eapp is bug-free but has tests for the enclaves.

Assumption Mitigated

I12 Validation bugs within the trusted kernel

Keystone assumes that the RT is bug-free but has tests for the RT.

Assumption Mitigated

I13 Validation bugs in secure boot loader

Keystone has implemented the SM on top of the Berke-ley Boot Loader (BBL), which is not researched in this the-sis. The secure boot relies on a root of trust which Key-stone simulates for demon-stration. Keystone may be using OpenSBI instead of BBL, according to the GitHub project, but they do not have an updated article as of today (2021-05-10). The OpenSBI version has tests.

Assumption Mitigated

5.2. Analysis between TEE vulnerabilities and Keystone

Functional bugs

I14 Bugs in memory protection The SM, that initialises the PMP and uses it to create isolation environments, is as-sumed to be bug-free. The PMP itself is also assumed to be bug-free. As stated before, it has tests for these compo-nents.

Assumption Mitigated

I15 Bugs in configuration of pe-ripherals

Keystone does not mention configuration of peripherals.

Not mitigated

I16 Bugs in security mecha-nisms

The security mechanisms of Keystone are assumed to be bug-free and there are tests to the different Keystone secu-rity measures.

Assumption Partially mitigated

Extrinsic Bugs

I17 Concurrency bugs Keystone does not guarantee non-interference for the SM API.

Not mitigated

I18 Software side-channels Keystone does not natively protect enclaves or the SM against timing side-channel attacks. Keystone states that existing software solutions and timing side-channel re-sistant hardware should be used to mitigate this. There is some protection towards cache side-channel attacks through the design of en-claves and SM.

Partially mitigated

Table 5.4: Relation between found vulnerabilities in the implementation and how Keystone handles them.

Hardware issues

Table 5.5 presents the analysis between the hardware issues, or vulnerabilities, that were found by Cerdeira et al. and Keystone.

5.2. Analysis between TEE vulnerabilities and Keystone

ID Name Interpretation of Keystone Outcome Architectural Implications

I19 Attacks through reconfig-urable hardware compo-nents

Keystone is built for a RISC-V but can be used on a FPGA and QEMU. Keystone has been tested to work on these platforms but there does not seem to be any specific pro-tection to these types of at-tacks.

Not mitigated

I20 Attacks through energy management mechanisms

Nothing mentioned about software-exposed energy management mechanisms.

Not mitigated

Microarchitectural Side-Channels I21 Leaking information

through caches

Keystone performs cache partitioning.

Mitigated I22 Leaking information

through branch predic-tor

This is dependent on the RISC-V, whether it is in-order or out-of-order execution.

Not mitigated

I23 Leaking information using Rowhammer

Keystone assumes that the framework is bug-free. Software-induced hardware faults should be mitigated by Keystone design that protects entities.

Assumption Partially mitigated

Table 5.5: Relation between found vulnerabilities in the hardware and how Keystone handles them.

The Isolation GSN in relation to the vulnerabilities

Studying the goals in the Isolation GSN, that are not undeveloped, it can be concluded that the GSN does address certain vulnerabilities. In Table 5.6, there are two vulnerabilities that the Isolation GSN addresses. If one were to study the TEE GSN, more vulnerabilities would be addressed but the TEE GSN does not have the needed evidence since they are undeveloped goals.

The first one is I04 which refers to the issue that shared memory between secure and normal worlds needs to be resistant to privilege escalation. This is addressed in goal <G35>, which states that it should not be possible to bypass the SM and acquire a higher privilege. The evidence <E4> aims to mitigate this vulnerability by placing the SM (which handles delegation of permissions) at the highest privilege, utilising the hierarchy in the PMP which entails that it is not possible to gain a privilege level higher than the SM.

The second one is I07 which addresses a couple of different issues but the one in focus is execution protection, the other issues can be read in Table A.1. The Isolation GSN addresses