Praveen originally joined Riscure six years ago as a security analyst. Since then, he has become a principal security analyst, which means that he also coaches junior team members when they join Riscure. Most of his work is related to hardware security, specifically security evaluations that help our customers certify their products and secure their implementations against certain attacks. Apart from that, Praveen is the company’s expert in Fault Injection. In his ‘domain owner’ role, Praveen mentors interns, tracks industry developments related to Fault Injection attacks, and defines potential research problems. Here’s what he told us about his work.
Why did you choose Riscure?
When I started my Ph.D. at the University of Luxemburg, another Ph.D. student was about to start their work at Riscure. I eventually found out that Riscure does the practical part of what I was studying, which made it interesting and aligned with my interests. Therefore, I joined Riscure as an intern, where I learned more about hardware security and the company itself. As soon as I graduated, I applied for a position at Riscure and joined the company.
Even though I’ve been with Riscure for over six years now, I have never done the same thing again and again. Every time there is a new challenge that requires me to do something different. There is an option to choose what you work on at Riscure, which is one of the reasons I’m still here. Also, Riscure has a great open culture and colleagues. Here are a lot of smart people from whom I learn a lot. These are also important factors why I am here.
How would you define device security?
Device Security, for me, is looking at the important assets in the device and developing ways to protect them. More specifically, it is ensuring that the security is implemented properly, starting from the architecture level, continued in the design, and finalized during the implementation of a device. Security considerations need to be translated correctly to development requirements throughout all stages, reflecting on and reviewing assumptions made from the beginning to the end. Device security needs to be reviewed at every stage, sometimes even externally, like with Riscure, to ensure that all assets that need protection are secured within the predefined threat model.
When should companies start to consider security?
While security needs to be reviewed at all stages of the device development, involving external parties like Riscure is especially vital during the implementation stage, where security experts can evaluate the hardware or software of the device to detect vulnerabilities with the use of penetration testing. Nevertheless, sometimes reviewing the device at the implementation stage is problematic as it may be too late. For example, if the device’s keys, a very important asset, can be accessed via the means of a fault injection vulnerability. If it is discovered during the implementation stage, it might be too late to fix it because the chip is already taped out. Therefore, our goal is to help customers realize that they need to involve third-party evaluation earlier in the development cycle. For example, in the pre-silicon offering, we are starting to support development teams already at the design stage. We are able to detect potential vulnerabilities before the chip is taped-out, which gives more time to fix problems. In other words, the earlier customers come to us, the better for them.
What is Riscure’s role in the device security industry?
Riscure is the security pioneer in the media and entertainment market, especially with our experience in evaluating set-top boxes. This security niche helped define certification processes for STBs over the years. Although that is where we started, we are now branching within certification, including doing Common Criteria work, which is very important to ensure that assurance promised by the vendors still holds when an independent review takes place. These are some of the roles that Riscure has in the industry, including the Automotive and IoT industries as well.
On the other hand, we often help our customers earlier in the development and pre-certification so that it is much easier and faster for them to proceed with certification after we have already reviewed the architecture design and parts of the implementation. Therefore there are no or fewer surprises in the evaluation and certification process.
What is your view on Fault Injection?
Fault Injection is basically a technique that tries to make the device work outside its normal conditions. Based on that, an attack can break the security of the device. So if, for example, the device is supposed to operate between certain voltage ranges, certain frequency ranges, that’s normal operation. Any legitimate user will typically use it within these conditions. But with Fault Injection, we are trying to see what happens if you take the device and operate it in extreme conditions, where the device is not supposed to work properly. Because of that, we can see the device misbehave, leading to issues that an attacker can exploit to recover assets from the device. That’s what we do in the Fault Injection domain.
In the last couple of years, there has been a lot of focus on remote Fault Injection, like the classic example of the Clkscrew attack that appeared a couple of years ago. Earlier, Fault Injection was only possible with physical access to the device. But with attacks like Clkscrew, you can do Fault Injection even remotely as you can inject faults from the software itself. These attacks are interesting from the perspective of an attacker as they have a bigger reach and impact. From the developers’ point of view, it becomes also challenging to consider these attacks and prevent them from happening.
Luckily, all these techniques are, in the end, Fault Injection. Therefore, if the device already has mitigations against Fault Injection, then these attacks should also be prevented. The only thing that is different from original Fault Injection attacks is the attacker profile. Earlier, the attacker needed to actually have physical access with certain training to be able to develop or perform these attacks. But with remote Fault Injection, what can happen is someone can look at the device, have these attacks developed, post it on the internet, and someone without too much knowledge of Fault Injection can actually exploit them. In that sense, the barrier becomes lower. But for the seasoned developers already invested in securing their chips against FI, this should not have much impact. But for others, this could be a big challenge.
How has Riscure and its role in the industry changed over the years?
As companies grow, companies change. I mean, it cannot be the same company of 50 people as it is with 200. We are much bigger than when we started. We started working with smart cards and set-top boxes, and now we are working on a much larger scale (e.g., larger teams, bigger projects). We branched into new markets like certification. When I started, certification was not there at all, but now it’s one of the big verticals inside our Services business unit. Furthermore, Riscure has expanded its R&D and innovation, enabling more research and advancement of our knowledge and technologies. Nevertheless, with the growth of the company and the introduction of structure, Riscure still mostly preserved its core.
What are some of the major changes in the device security industry in recent years?
I think the main change is that the barrier is getting lower. For example, earlier, we were mostly focusing on high assurance evaluations like smart cards. But with the evolution of numerous attacks on IoT devices, there is a better understanding of the damage it can cause to reputation or product development, even for others. Obviously, security is a cost, so customers are not necessarily happy to pay for it. But there is a reason why they need security. There is definitely more awareness, leading to the slow growth of more security investment from companies at earlier stages of development.
What kind of evolution do you expect in the industry and for Riscure in the future?
As mentioned, one of the interesting concepts in the future is the development of remote attacks (both fault and side-channel). Therefore, I expect more vulnerabilities that can be exploited from software (e.g., rowhammer, cache-timing) to appear in the future, which is already happening but getting more and more prominent. On the other end, I expect that more companies will consider security during the early stages of development, which will improve the robustness of their products as a result. For Riscure, these developments do not necessarily mean major changes, except further contribution and focus on R&D. We will keep tabs on what’s happening in the industry and will keep improving our expertise. Whenever a new technique or attack happens, our focus is to understand what it is and how to integrate new attacks into our workflow. Furthermore, we also want to continue developing new attacks and contribute to making devices more secure.