In Saarbrücken, your reputation as an excellent researcher in their field precedes you. What attracted you to research IT security?
I guess that is where the play instinct in me comes through a bit. As a researcher, you usually try to get past some protective mechanism and thus gain access to things you really should not have access to. That appealed to me even when I was young. In my early days, I may have even tried to bypass the copy protection of video games or turn a demo into the full version. Because I found all this exciting, I then also chose computer science as a subject of study. During my studies in Aachen, I got in touch with the Chaos Computer Club in Cologne and spent much time there. Together with friends, I started to work on the security of wireless networks, for example. Then honeypots became my topic - these are computer systems designed to attract attackers, and I wrote my diploma thesis on this topic. As time went on, I specialized more and more in IT security.
Do you still enjoy what you do today?
Yes, absolutely! After my doctorate, I also had interesting offers from the industry. But I chose science after all, mainly because of the freedom researchers enjoy. And IT security is and remains an exciting and diverse subject. What I was doing five years ago is very different from what I am doing today or what I will be doing in 10 years. Research in this area is not monotonous; it is constantly evolving. However, in the past three or four years, I have also been involved a lot with administrative tasks. I hope to find more time for research again at CISPA.
What are you currently researching?
At the moment, we are mainly working on topics in three areas. The first is software security. Here we are primarily concerned with so-called fuzzing, i.e., the automatic detection of vulnerabilities and corresponding protection mechanisms to make software systems more robust against attacks. One important aspect of this is reverse engineering. This technique is used when you don't have access to the source code - that is, what a programmer has implemented - but can only look at the binary code, that is, what the machine ultimately executes. The second area is the intersection of IT security and machine learning. For example, we have studied so-called "adversarial examples" that can trick ML algorithms for speech recognition. To this end, we studied smart speakers such as Siri or Alexa and wanted to find out whether and how often they "wake up" and listen in, even though their users have not addressed them at all. The third area is the security of cellular systems, especially LTE. In this area, we have found and practically demonstrated different types of security vulnerabilities.
Can you give me an example of a project that used binary code analysis?
One of the most exciting projects in recent years was when we looked at the software of engine control units in the context of the Diesel emissions scandal. Of course, the automotive companies did not give us access to their source code. However, using the binary code, we were able to determine under which conditions exhaust gas after-treatment - i.e., the filtering of the exhaust gases - takes place and whether and at what point this after-treatment is modified or even switched off. We have also developed a tool that can automatically perform such an analysis within a few minutes.
The BASTION project, for which you received an ERC Starting Grant, was also in the field of binary code analysis. The grant expired in February 2020. What was it about, and what did you find out?
We made significant progress in binary code analysis in this project. In particular, we improved analysis methods at the binary level. In doing so, we worked both offensively, i.e., developing methods for finding vulnerabilities, and on the defensive side, designing new protection mechanisms. Originally, we wanted to work primarily on embedded systems, which are not always immediately obvious that they are computers - for example, microcontrollers in car keys. In the end, however, we worked a lot with Linux and Windows systems. The difficulty with binary code analysis is that the instructions look different for different processors. In order to develop an analysis method that works the same for an Intel processor as for one from ARM, for example, we had to find a so-called "intermediate language." A small translator brings the data from the binary level into the intermediate language, and then the analysis works for all processors. In the project, we also pushed the work with such intermediate languages a good bit further.
In March, you were notified by the European Research Council that you will be funded again. You and your team will receive a Consolidator Grant and around 2 million euros for the "Resilient and Sustainable Software Security" project, RS3 for short. What is the project about?
RS3 is a research program that aims to fundamentally improve the security of software systems. To this end, we are developing countermeasures at various levels of the systems. We have two specific goals here: On the one hand, the system must be resistant to entire classes of attack vectors. On the other hand, it must be able to maintain its security throughout its lifetime and possibly even adapt over time. Our project addresses the problem in four ways: First, we develop novel software testing strategies that enable accurate and efficient vulnerability discovery. Second, we design secure compiler chains that embed security properties during the compilation phase - that is, while programming language is being translated into machine language - that can then be enforced at runtime. Third, we develop robust mechanisms that mitigate and patch advanced attacks. Fourth, we are investigating how hardware changes for open source hardware - which may be specific processors, for example - can improve the efficiency and accuracy of all these measures.
Why did you decide to move to CISPA, and what topics do you see as connecting with the researchers here?
What ultimately convinced me was that CISPA is to become a very large center that takes a holistic view of IT security with many facets. But of course, I'm also looking forward to the different environment and the new colleagues. In my research, there are also some overlaps with other CISPA researchers. For example, Andreas Zeller works on software testing, many people work in the area of system security, and Mario Fritz is active in the area of machine learning, just like me. But also in the areas of usable security and web security, there are certainly points of contact with Katharina Krombholz or Ben Stock.
Is there a problem in the field of IT security that you would like to see solved during your active research time or that you would like to solve yourself badly? What do you consider to be the ultimate opponent?
Oh dear, there are many! I think by now, we have a relatively good understanding of how to design algorithms securely, the main problem is the practical implementations. Securely implementing complex software systems is perhaps the greatest challenge of the next ten or 20 years. But there are an incredible number of building blocks on the way to robust systems that are secured against all kinds of vulnerabilities. I do not think any of us will be out of a job any time soon.
translated by Oliver Schedler
