Ronan Loftus is a Senior Security Analyst at Riscure. Ronan joined us in 2017 when Riscure was a much smaller company. Since then, Ronan has been working on various software security testing and evaluation projects. In this interview, we discussed the connection between scientific and practical security, the security needs of the end-user, and the latest trends in software security.
What is the role of a Senior Security Analyst?
I mainly work on projects and my job varies based on their type. There are broadly two types of projects: software and hardware. Embedded device testing, blackbox testing, and code review are some of the types of software security evaluations we do. For example, these can focus on things like Trusted Execution Environments and DRM solutions. For these evaluations, the goal is to analyze what’s running on the device, find bugs, and try to develop exploits without using any specialized hardware. For the hardware part, using specialized tooling developed by Riscure we apply fault injection to affect the code and change its behaviors and side-channel analysis to extract information about the internal device operation. Even if the code on the device is perfectly secure, by using external means we can for example change the power being given to the device or discharge a coil right beside the chip. Using these techniques, we can affect what code is being executed on the device. Injecting faults can compromise various assets so that as well needs to be evaluated when assessing the overall device security.
In my work, I mainly focus on software and logical attacks when testing solutions mostly from the media and entertainment industry. This covers Trusted Execution environments, operating systems for phones and television, and DRM solutions. Most of the projects I do are about content protection, be that a movie, phone data, music, or any other sort of media. Often enough, we also do blackbox testing projects, which means we have no information about the devices or the code running on them, so we start from the very beginning finding public information and then use our creativity to try and collect information off the devices and build attacks against them. I really enjoy working on these kinds of projects, as regular security testing and evaluations are generally far more structured. But for software and especially blackbox testing, I get freedom and the opportunity to use my creativity. There is no checklist to follow. You also get to work with very knowledgeable people, from whom you can learn all sorts of new things, techniques, and attacks.
What is your most memorable project at Riscure?
One of my favorite projects at Riscure is definitely my most memorable one. As part of the evaluation, we wanted to find ways to compromise a device, so that we could get the root keys that enable the decryption of all content that goes through. It was a blackbox project, so we were looking for any available public information to do hardware modifications. I was working with an ex-colleague, who is a god among mortals when it comes to software and hardware security. So, this project helped me learn a lot from him. We had a bug in the boot flow of this device, and we were trying to compromise the secure boot to get this key. To exploit this bug, we had to physically modify the flash, the external storage from which the bootloader loads the next piece of code. I really liked the project as it was this sort of bridge between two worlds of software and hardware, as we were using hardware methods to exploit a software bug.
How did you join Riscure?
My bachelor’s background is in mathematics and computer science, and my master’s was in system and network engineering with a security focus. That is very software and network focused, rather than embedded devices, which is Riscure’s specialty. My master’s program also has a very good relationship with Riscure in general. Quite often graduates from the program join Riscure. This is supported by yearly workshops hosted at the university by Riscure analysts. It is usually a morning of a guest lecture about hardware attacks, embedded devices, physical attacks, and such things as side channel analysis and fault injection. After lunch, however, it shifts to a hands-on workshop with the students to let them get a feeling of how you actually perform such attacks in practice. When I was a student, I attended such a workshop. As I was always interested in software security. It was a really interesting and motivating lecture. Riscure also sounded like a cool company, so I decided to go for it, and already the next year I was a representative of Riscure at the same workshop.
What is the connection between academia and the security industry?
Broadly speaking, we often use academic research as a resource for possible ways to attack devices and also to stay up-to-date with new developments. However, it is more applicable for hardware projects that involve fault injection and side channel analysis. Often it will be the case that academia comes up with a new theoretical attack, a classical example is Differential Fault Analysis. We then use our tools, like Inspector, to codify security insights, to implement these attacks in our tools. This approach is the most common for cryptographic algorithms. But then of course you can use these sorts of hardware attacks on other things, like secure boot, as a hardware approach to modifying the code’s behavior. There are some papers on such approaches, but these attacks are less formalized than the ones on cryptographic algorithms Differential fault attacks are one of the examples where security theories from academia are being put into practice.
What is the difference between the security needs of the end-user and the security standards and requirements?
Interestingly, different security considerations matter to different stakeholders. For example, the hardware security of devices and chips doesn’t necessarily concern most end-users. For most people on the street, it doesn’t matter what is the hardware behind it as long as it works. At the same time, the software side of devices concerns regular end-users as well as vendors. Lately, more and more research is done in the industry, and at Riscure, on how different phones and devices that store personal information have issues with secure boot, bootloader, and boot ROM, which can give access to all the encryption keys to personal data, like photos, passwords, and anything else that the user wants to protect. These issues are regularly fixed by vendors with software updates. We trust these devices with a big amount of our life, so it is great that we have the freedom at Riscure to do research on such topics.
However, there is a difference between a user’s concern and the real actions they must take to protect their data. While the discussion about security is becoming larger in society, many people are still not aware of what action they as a user need to take to protect their data. For that, we see a new trend of companies starting to consider security earlier in their development rather than as an afterthought. They also use security as a selling point, increasing awareness for the end-user. This way the user doesn’t need to take as much of their own actions to secure their data further, as some of the responsibility is taken on by the development company.
What are some other trends you see appearing in the device security industry?
I see an increased use of exploit mitigation techniques, which are often provided by the compiler, which turns the source code into an actual runnable program. It’s been increasing since the late 90s, but I see it becoming ever more common nowadays. There are many different code security techniques that are becoming more commonly used. Some examples are Address Space Layout Randomization, Shadow stacks, and Control Flow Integrity checking. Address Space Layout Randomization basically ensures the same piece of the program is not put in the exact same place in memory every time making it harder to know where sensitive data is stored in memory. Shadow stacks are a technique that separates return addresses from the rest of the data stored on the call stack. This renders the classical stack-based buffer overflow exploitation techniques obsolete. Another example is something like Control Flow Integrity checking which is used to stop code jumping to arbitrary places in memory and limiting valid jump targets. There are many exploit mitigation techniques that eliminate entire classes of software vulnerabilities that are used these days, which of course is a good thing. But it is also a cat and mouse game. The attack techniques become more advanced, so mitigations need to also continue advancing.