Valentin MARTINOLI

Embedded security and the threat model associated to it are tightly linked to the possibility for an attacker to physically access the victim. Therefore, is has been thought for long that hardware attacks required a physical contact [1,2,3,4] or at least to be physically close [12,13] to the target, meanwhile software attacks were conducted remotely [5,6,7]. An intermediate class of attacks appeared recently. These new attacks consist in exploiting a hardware mechanism to mount a physical attack by using software means through a network. They enable an attacker to actively induce faults [8,9] or to passively recover a secret [10,11].
The separation between local and remote attacks is therefore blurred. Moreover, the motivation for attackers to carry out such attacks is growing stronger as cloud technologies and the related services keep on evolving [14,15].
Considering logical attacks, it is commonly admitted that software entities with high privileges, operating systems or hypervisors, grant protection to the software entities with lowers privileges such as user applications. Thus, it is part of those supervising entities’ role to provide isolation between applications. However, there is no guarantee regarding the protection of applications against an operating system for example. This can raise an issue if the operating system has been compromised and cannot be trusted.
Intel’s recent SGX technology [16,17] proposes a solution to this issue using the concept of secure hardware enclaves. By construction, these enclaves prohibit any privileged process from compromising the security of processes with lower privileges. Even if Intel does not claim that enclaves protect against physical attacks, software or logical attacks are supposed to be prohibited by construction.
However, recent publications have demonstrated that shared hardware resources, such as caches [18] or internal memories [19], can threaten the model proposed by Intel. It has especially been proven that user processes could spy one another despite SGX’s guarantees. Moreover, having higher privileges enables to carry out stronger attack with a higher success rate.
Several mitigations were proposed. They consisted in updating the processor’s microcode, operating systems, and virtual machines [20,21,22]. These protections require an additional trusted entity to intervene. Besides, once those mitigations are implemented, they mostly reduce the attack’s success rate rather than completely prohibiting it.
Thus, if one considers the example of a user entrusting a Cloud Service Provider (CSP) to execute his software, the theoretically secure data within the enclave is, in the end, not totally protected by SGX. Despite Intel’s initial objective, SGX cannot protect data from a malicious CSP because he decides to update or not the operating systems, the hypervisors and the virtual machines.
One of this thesis’ goals is to provide an in-depth study of the mechanisms involved in microarchitectural attacks in order to understand architecturally what makes them possible and to what extent they are dangerous.
Another objective would be to prove whether purely software solutions could be placed inside the enclave itself to protect it, without resorting to the operating system or any other entity. It would then be necessary to investigate their effectiveness.
The final objective is to imagine a modern processor which would be, by construction, immune to this class of attacks. It would thus be required to evaluate the respective importance of conception and implementation and to understand and estimate what would the consequences be in terms of performance and functionalities. RISC-V [23] seems to be the most appropriate tool to conduct this work, especially through the instantiation of secured enclaves such as Keystone [24].
[1] Paul C. Kocher: Timing Attacks on Implementations of Diffie-Hellman, RSA, DSS, and Other Systems. CRYPTO 1996: 104-113
[2] Paul C. Kocher, Joshua Jaffe, Benjamin Jun: Differential Power Analysis. CRYPTO 1999: 388-397
[3] Markus Kuhn, Oliver Kömmerling: Physical security of smartcards. Inf. Sec. Techn. Report 4(2): 28-41 (1999)
[4] Hagai Bar-El, Hamid Choukri, David Naccache, Michael Tunstall, Claire Whelan: The Sorcerer's Apprentice Guide to Fault Attacks. Proceedings of the IEEE 94(2): 370-382 (2006)
[5] Eric Osterweil, Angelos Stavrou, Lixia Zhang: 20 Years of DDoS: a Call to Action. CoRR abs/1904.02739 (2019)
[6] The Internet Worm Program: An AnalysisPurdue Technical Report CSD-TR-823Eugene H. SpaffordDepartment of Computer SciencesPurdue UniversityWest Lafayette, IN 47907-2004
[7] Guillaume Bouffard and Jean-Louis Lanet. The ultimate control flow transfer in ajava based smart card.Computers & Security, 50 :33–46, 2015.
[8] Adrian Tang, Simha Sethumadhavan, and Salvatore Stolfo. CLKSCREW: Expos ing the perils of security-oblivious energy management. 26th USENIX Security Symposium, 2017.
[9] Yoongu Kim, Ross Daly, Jeremie Kim, Chris Fallin, Ji Hye Lee, Donghyuk Lee, Chris Wilkerson, Konrad Lai, and Onur Mutlu. Flipping bits in memory without accessing them. ACM SIGARCH Computer Architecture News, 42(3):361{372, 2014.
[10] Mark Zhao and G. Edward Suh. FPGA-Based Remote Power Side-Channel At tacks. In IEEE Symposium on Security and Privacy (SP). IEEE, 2018.
[11] 19. Falk Schellenberg, Dennis R. E. Gnad, Amir https://software.intel.com/security-software-guidance/Moradi, and Mehdi B. Tahoori. Re mote inter-chip power analysis side-channel attacks at board-level. Proceedings of the International Conference on Computer-Aided Design, 2018.
[12] Daniel Genkin, Adi Shamir, Eran Tromer: RSA Key Extraction via Low-Bandwidth Acoustic Cryptanalysis. IACR Cryptology ePrint Archive 2013: 857 (2013)
[13] Giovanni Camurati, Sebastian Poeplau, Marius Muench, Tom Hayes, Aurélien Francillon:
Screaming Channels: When Electromagnetic Side Channels Meet Radio Transceivers. ACM Conference on Computer and Communications Security 2018: 163-177
[14] David Pellerin. FPGA Accelerated Computing Using AWS F1 Instances, 2017.
[15] Alibaba Cloud ECS. Deep Dive into Alibaba Cloud F3 FPGA as a Service Instances, 2018.
[16] Intel Corporation.IntelR©64 and IA-32 ArchitecturesSoftware Developer’s Manual, Sep 2015. Reference no.325462-056US.
[17] Intel SGX Explained, Victor Costan and Srinivas Devadasvictorcostan.us (Devadasvictor[at]costan[dot]us), devadasmit.eduComputer (devadas[at]mit[dot]eduComputer) Science and Artificial Intelligence LaboratoryMassachusetts Institute of Technology
[18] Jo Van Bulck, Marina Minkin, Offir Weisse, Daniel Genkin, Baris Kasikci, Frank Piessens, Mark Silberstein, Thomas Wenisch, Yuval Yarom, and Raoul Strackx. FORESHADOW: Extracting the Keys to the Intel SGX Kingdom with Transient Out-of-Order Execution. USENIX Security Symposium, 2018.
[19] RIDL: Rogue In-Flight Data Load Stephan van Schaik, Alyssa Milburn, Sebastian Österlund, Pietro Frigo, Giorgi Maisuradzeyz, Kaveh Razavi, Herbert Bos, and Cristiano Giuffrida
[20] Security findings and mitigations https://software.intel.com/security-software-guidance/
[21] L1 Terminal Fault / CVE-2018-3615 , CVE-2018-3620,CVE-2018-3646 / INTEL-SA-00161, https://software.intel.com/security-software-guidance/software-guidance…
[22] Microarchitectural Data Sampling / CVE-2018-12126 , CVE-2018-12127,CVE-2018-12130,CVE-2019-11091 / INTEL-SA-00233, https://software.intel.com/security-software-guidance/software-guidance…
[23] https://riscv.org/
[24] https://keystone-enclave.org/