Interview: Clémentine Maurice.

Speaker(s) : Clémentine Maurice, chercheuse en Sécurité

      You will find an interview of Clémentine Maurice, Security researcher at Graz University of Technologyin Austria. Clémentine will give her talk about side channels attacks and browsers, in the morning of Tuesday July, 4th 2017.
      Hello Clémentine, you are a security researcher, with a focus on side channels attacks. May you present yourself and explain us how you end working on this very specialized field ?
      Hi! Since high-school, I wanted to work in computer science, without any precise idea of which domain. I first studied at INSA Rennes, an engineering school, where I specialized in computer science. During my last year, I wanted to specialized in security, and I went for a research master, and got a double diploma. I really liked my research internship, on Wi-Fi fingerprinting, and continued with a PhD thesis (with a program called CIFRE, where the PhD is done part time at a company, Technicolor in my case). The thesis subject was quite open - "cloud computing security" - so I began to read a lot of articles to find what would interest me the most. I discovered, among other topics, side-channel attacks on CPU caches. I was completely fascinated by this subject: these attacks are using side effects of the hardware to derive for example secret keys, or to communicate covertly. At this time, my last lectures on hardware architecture was also quite some time ago, and I needed to get back to it. I am now working as a postdoctorate in Austria, at Graz University of Technology, where I am continuing my research on this topic.
      You work in an academic research laboratory, developing particularily this kind of attacks. With your experience of several years in academic reseach, do you think that this kind of public, applied and offensive research is more and more common or is it still exceptional ?
      Yes, I am working on developing these side-channel attacks, in order to understand them better, and so that we can find good countermeasures, addressing the root causes of vulnerabilities. I think that the academic community already realized that applied and offensive research was a necessary step to build secure systems. Today, I don’t think that this type of research is an exception. Generally, this is good news for research as a whole: there are theoretical and formal works, as well as empirical works, that can then allow validating or invalidating more theoretical work.
      Do you think that providing implementation (code) in order to support research papers is currently acknowledged in academic world ? And according to you, code is a requirement to support modern research and has it to be provided uder free software license?
      I think that providing code complementing articles is more and more encouraged, and acknowledged as a good and necessary thing in the academic world - at least in the security domain. Some articles mention links to code repositories, and some conferences also encourage submitting code. I also recently saw the FindResearch [1] initiative by researchers, which should allow cataloging code associated with published articles in the long term. I really support this kind of initiatives, that I find absolutely necessary. The core principle of scientific research and scientific method is based on experimentations, and validation or invalidation of initial hypotheses based on the results of experimentations. To be sure that a result is valid, it is therefore very important that other researchers can replicate experiments. In computer science, we have the chance to not necessarily need expensive equipment to replicate experiments (although some experiments do need a lot of computing power). In theory, anybody, including citizens who are not academic researchers, could replicate experiments. This is where free software is interesting: the computer science community is larger than academic researchers. Opening the code allows having feedback on scientific works, but also transferring research to society (for example progresses in terms of performance or security countermeasures). This is a necessity, because public research is partly financed by citizens. They should therefore be able to freely access results of studies they contributed to finance. The academic community is already fighting so that this is the case for articles, that are most of the time behind a paywall by publishers.
      For code, the issues are different. Having code from researchers is a start, but it is most often the beginning of troubles: code does not always compile, and when it compiles it is most often not documented, and it is not easy to interpret the results. There are less incentives in the academic world for this part, as well as for reproducing experiments. Providing usable code is a tedious task, that is rarely done in the academic world, as there are numerous other concerns: publish more results, teaching, serving the community with peer-reviews, searching for funding...
      In my particular domain, it is moreover not easy to replicate experiments, as attacks strongly depend on hardware, and it is hard to make generic attacks. Another problem is hardware itself, which is often undocumented. All these attacks require a very good understanding of the underlying hardware, so a part of my research consists in reverse-engineering hardware. So in a way, we are also opening hardware :)
      If we speak a little about your talk, its topic is quite complex. May you first explain us the main principles behind side channels attacks ? Then, are browsers particularly vulnerable to them or not really?
      This is a complex subject, but the general ideas are known by each and everyone. The general idea of side-channel attacks is to find a way (a channel) from which secret information is leaking, that is not the main channel. We have all seen a movie in which somebody opens a safe with a stethoscope. The main channel is the logical information "is the safe open?". It is difficult to attack a safe by being only provided this information: an attacker needs to try all combinations. The side channel here is the sound that the safe makes, and that gives information at intermediate stages (for example a "click" sound when it is the correct number). If the safe is vulnerable, then an attacker needs to try less combinations.
      We are not working on safes, but the idea is similar: hardware, on which runs software, is involuntarily giving away a lot of information on software execution. There is for example power consumption, or electromagnetic radiations. These attacks require physical access to hardware. I am interested in attacks that target the computer micro-architecture, i.e., all the internal organization of computers and processors in particular. CPU caches are a small piece of memory that is between CPU cores (that are doing all the computations) and DRAM (that stores data and code in the main memory). CPU cores are faster and faster, but DRAM is too slow, so we need additional memory that is smaller, but faster, and close to the CPU cores, in order to avoid bottlenecks. Cache therefore contains code and data. An attacker seeks to know what operations the victim just performed, in order to derive its secrets.
      The idea of targeting web browsers is that hardware is shared by all applications that are running on it. A web browser is a part of it, and so are virtual machines for example. One particularity of side-channel attacks that use caches is that they are only performing benign operations. It is not possible for an application to just "peer into the cache". An attacker thus only perform regular memory accesses to its own memory, in order to infer the victim’s operations. These are operations that are allowed in all environments, including sandboxes like JavaScript. We are often forgetting that JavaScript is, in practice, code execution on our own machines! Web browsers are vulnerable to these attacks because web pages do not need any authorization or any software installation to execute code. The idea is that, even though the vulnerabilities are present at a very low level (hardware), they are exploitable at a very high level (web browser). This type of attacks are taken seriously by browser developers, who are searching for solutions to avoid them. These are still issues that are hard to patch, as vulnerabilities are coming from hardware optimizations - and that nobody wants to sacrifice performance.
      And, finally, what do you expect from your talk during the Security track, and more generally, from your venue to RMLL?
      I first hope to be able to present our work in an understandable way to the participants!
      I participated (as a spectator and presenter) in several "hacker" conferences like the CCC, but this is my first visit to the RMLL, I am glad to meet this community :)
      Thank you very much for this interview, Clémentine, and see you in St Etienne during 2017 RMLL event :)
      Interview done by email in late May 2017.