Project topics and materials
Get Complete Project Material File(s) Now! »
Attacks characterization and threat model
In this subsection, the main guarantees to provide when securing a system are first in-troduced. After, possible threats and attacks are presented. Then, the Trusting Computed Base (TCB) as well as the threat model associated to the many-core system, considered in this work, are presented. Secure and reliable systems guarantee the following properties:
• Availability: the availability property guarantees the reliable access to information and to available resources by authorized actors.
• Confidentiality: confidentiality, or privacy, ensures that sensitive information is never reached by unauthorized actors by guaranteeing the respect of a set of rules and access rights.
• Integrity: integrity is the property, that the information is never accessed by an authorized actor. This property guarantees the information is not modified or erased by an unauthorized actor. However, these properties can be attacked through either, physical and logical attacks.
Threat model considered in this thesis work
The TCB defines the trusted, software and hardware, part of the system on which security policies rely. Therefore, in order to minimize the attack surface, it is important to reduce as much as possible the TCB. The TSUNAMY project considers that the TSAR architecture is likely to be remotely used, in a cloud environment for instance. It is thus assumed that potential adversaries do not have any physical access to the hardware and therefore cannot compromise it nor launch any physical attack against it. Consequently, all the hardware components are included in the TCB, and only logical attacks are considered. Applications, external to the system, are always considered as potentially malicious. Moreover, several malicious applications could collaborate in order to attack the system or to attack a concurrent application. Two scenarios according to the definition of the TCB are distinguished. The first scenario considers that the entire OS running on the platform is trusted. In fact, in this case it is assumed that the OS kernel services do not include all the features of an entire OS but are restrained to the services necessary for the dynamic deployment of applications and management of resources. In this scenario, only applications running Spatial Isolation against Logical Cache-based Side-Channel Attacks in Many-Core Architectures Maria Méndez Real 2017 on the platform are considered as potentially malicious. The OS kernel being trusted, a malicious application can launch attacks against another application but cannot tamper with the OS. Security can thus rely on OS secure-enable mechanisms.
In a second scenario, the OS is not entirely part of the TCB. In fact, here it is considered that, in addition to applications, some OS kernel services can be compromised as well. In this case, it is still required that there is a trusted entity, that can include some OS kernel services or a hypervisor, responsible of ensuring the security policies of the platform.
Finally, concerning both scenarios, there have been some efforts in order to reduce the OS kernel code in the TCB by performing some functionalities, traditionally accomplished inside the kernel, in an outside unprivileged service component. For instance Linux provides a standard User I/O framework for developing user-space-based device drivers. Moving the device drivers into the user space can be done in a security purpose in order to reduce the size of the kernel. Recently, in [19], authors explore this approach.
In this work, the first scenario in which the OS kernel is entirely included in the TCB, is considered. Furthermore, this thesis work considers the execution within one VM and assumes that VMs are securely deployed by the hypervisor which guarantees the non inter-ference between them [13]. Moreover, this work focuses on threats on the confidentiality and integrity and relies on the TSAR architecture supporting an MMU per processing core. The MMU prevents the unauthorized direct access to data in memory by reading and writing. Therefore, among other attacks considered in the TSUNAMY project, this thesis work specially focuses on unauthorized indirect access to data through SCAs. These attacks are further explained in the next section.
Hardware cache-based attacks countermeasures Cache isolation
Page coloring: Page coloring is a well known technique offering cache isolation be-tween memory sections belonging to different processes. The main idea of this approach is to assign colors to memory pages and to ensure that same color pages are mapped to a fixed set of cache lines (Figure 2.1). In [67], the author introduced the concept of par-titioned cache as a solution against access-driven cache-base SCAs. In [68], the authors considered page coloring for shared LLC in order to prevent cache sharing. Indeed, this solution prevents a process from influencing or observing the state of cache partitions other than its own partition.
In order to implement cache partitions, the Instruction Set Architecture (ISA) is ex-tended with new instructions able to define a cache partition of a specified size [67]. Page coloring can be implemented both, statically and dynamically. In the static approach, the cache is statically partitioned. A process might not entirely use its partition, entailing a significant number of unused cache lines.
Page locking: To cope with this drawback, the authors in [69] propose to use a similar approach called Partition-Locked cache (PLcache). This approach aims at locking in cache only the cache lines of interest (e.g., AES or RSA tables), in order to prevent cache accesses that do not belong to this locked partition from evicting them. Notice that this solution targets both, internal and external cache locked partition interferences. In order to implement this approach, the authors extend every cache line with a tag indicating if the line is secure and an identifier of the owner of the cache line. The authors propose two methods in order to implement this approach; extending the ISA with new locking, unlocking operations, or letting the OS control the cache lines to be locked and unlocked.
Table of contents :
List of Figures
List of Tables
List of Algorithms
1 Introduction and context
1.1 Introduction
1.1.1 TSUNAMY project
1.2 Context
1.2.1 Considered system
1.2.2 Attacks characterization and threat model
1.2.3 Threat model considered in this thesis work
1.2.4 Introduction to logical cache-based attacks
1.3 Contributions
1.4 Organization of the manuscript
2 State of the art
2.1 Software and hardware cache-based attacks countermeasures
2.1.1 Software cache-based attacks countermeasures
2.1.2 Hardware cache-based attacks countermeasures
2.2 Logical and physical isolation
2.3 Discussion
3 Spatial isolation
3.1 Spatial isolation
3.2 Different deployment strategies for spatial isolation
3.2.1 Static size secure zone approach
3.2.2 Fully dynamic size secure zone approach
3.2.3 Trade-off strategies combining both, static and dynamic approaches
3.3 Summary of the proposed deployment strategies
3.4 Extension of the kernel services for spatial isolation implementation
3.4.1 Threat model and assumptions
3.4.2 ALMOS kernel services and integration of spatial isolation
3.5 Summary of the extensions of the kernel services
3.6 Conclusion
4 Extension and exploration of MPSoCSim
4.1 Motivation
4.2 MPSoCSim
4.2.1 Imperas/Open Virtual Platforms (OVP) technology
4.2.2 Network-on-Chip (NoC) simulator
4.3 Validation
4.3.1 Hardware implementation
4.3.2 Experimental protocol
4.3.3 Evaluation results
4.4 MPSoCSim extension
4.4.1 Clustering the architecture
4.4.2 Dynamic execution capabilities
4.5 Exploration with the extended MPSoCSim version
4.5.1 Exploration protocol
4.5.2 MPSoCSim available results
4.5.3 Exploration results
4.6 Conclusion
5 Spatial isolation evaluation through virtual prototyping
5.1 Experimental protocol
5.2 Cache attacks vulnerability case study
5.3 Deployment strategies comparison results
5.3.1 Considered deployment and execution scenarios
5.3.2 Results organization
5.3.3 Comparison according to each performance indicator
5.3.4 Comparison according to each execution scenario
5.3.5 Comparison summary
5.4 Conclusion
6 Conclusion and future work
6.1 Summary
6.2 Spatial isolation discussion
6.2.1 Back to the state-of-the-art
6.2.2 Further attacks and spatial isolation capabilities
6.3 Possible improvements and leads for future work
6.4 Conclusion
Glossary
List of publications and presentations
Bibliography
