Security concerns regarding hardware and embedded systems are becoming ever more important in our increasingly networked world. Complexity and challenges are growing at the same time, for example, due to a lack of transparency in supply chains, global dependencies and the prospect of powerful quantum computers threatening our current encryption methods. Matthias Hiller, head of the Hardware Security department at Fraunhofer AISEC and his team are dedicated to exploring central issues related to the trustworthiness and resilience of modern hardware platforms. In the interview with FMD, he explains the opportunities and challenges of designing secure hardware and how systems can be effectively protected against attacks and manipulation. He also highlights the importance of hardware security for Europe and Fraunhofer AISEC’s contributions as part of the chiplet security APECS pilot line.
In our department, which I am managing together with my colleague Nisha Jacob-Kabakci, we are concerned with the security of hardware and embedded systems, reaching from chips through to the firmware of systems. We explore, which technologies can be used to increase security and implement these. We also analyze systems to determine any weaknesses and ways of fixing them.
What is your department’s role in the microelectronics value chain?
Fraunhofer AISEC performs applied research in the area of cybersecurity and it recently became part of FMD, too. The focus of our department’s work is on security aspects of integrated circuits, assemblies of multiple chips on printed circuit boards and embedded systems, so we are working on the interface between IT and microelectronics. We are dealing with electronics as a basis for secure systems and we cooperate closely with other departments of the institute, as well as with other FMD partners, working towards integrating security features in chiplet systems as part of APECS, for example.
Do you think that the role hardware security plays in microelectronics has changed in the past ten years?
It has gained relevance, because systems are becoming ever more complex and networked. At the same time, supply chains are hard to trace and there are global dependencies. The challenge is to develop and use secure electronics despite all of this. The moment a system starts to communicate with the outside world, it becomes vulnerable to attacks via communication interfaces. In addition to this, attacks can take place on the hardware itself. A growing number of sensitive tasks are now performed by networked electronics, for example, on smartphones and IoT devices. It is therefore essential to ensure that such electronics are not only reliable but also operate securely.
Open source projects with a high level of technical maturity provide a good basis that can be built upon to address specific customer needs. Another area we are currently focusing on is a safe implementation and integration of post-quantum cryptography. This means that we are working with cryptographic algorithms that can withstand quantum computing analyses.
The Cyber Resilience Act shows that demand for secure products has arrived at the heart of our industry and society. It is, however, hard work to meet these requirements with suitable products.
Designing secure hardware is one of the department’s focus areas. What are the specific topics you are dealing with here?
One of the key aspects when designing secure hardware is that cryptographic methods need to be implemented not only correctly but also in a way that makes them resilient to attacks, and to efficiently integrate them into systems. In the area of open source projects, the OpenTitan project is particularly relevant for us as a basis for further development. OpenTitan is a RISC-V processor that is specifically designed to meet security-related requirements, a hardware trust anchor in other words. It features integrated cryptographic accelerators and extended security mechanisms. This trust anchor is a key component of the secure system-on-chip platform we are developing in the context of the Bavarian Chip Design Center.
RISC-V is an instruction set that acts as an interface between hardware and software and defines the way in which a processor is controlled. Thanks to RISC-V being open source, we are able to flexibly extend the architecture and adjust it to client requirements. This open approach makes RISC-V particularly attractive for research and industry alike.
Our department cooperates closely with colleagues from Fraunhofer IIS in our work on the platform’s hardware and firmware, while other colleagues at Fraunhofer AISEC are taking care of the operating system and a secure software execution on the system. This enables us to jointly develop a secure and adaptable platform that can, for example, be integrated into a wide range of systems as a security chiplet in APECS.
You just used the term hardware trust anchor. What exactly is that?
A trust anchor is a hardware component that serves as a foundation for the system’s security, such as a SIM card in a cell phone.
This is also a key aspect of chiplet systems comprising multiple chiplets. The security chiplet acts as a trust anchor here that safeguards the integrity and origin of the code executed on the chiplet system and acts as a central security device when different chips interact. We are developing this kind of trust anchor for chiplets as part of APECS.
These security chiplets have a modular design and can be used as central trust anchors for various systems. We are in close coordination with other partners here, to ensure that the required interfaces and security functions can be provided accordingly.
Another focus area of your work is to protect systems against manipulation. What are you working on in this field?
If individual components of a system do not meet the required level of protection, a protective barrier can be installed between the system and the outside world, for example for ASICs, processors, storage devices or Field-Programmable Gate Arrays (FPGAs) with lower protection standards. Together with Fraunhofer EMFT we are working on protective films that envelop the system to isolate it from the outside world. If this envelope is intact, you can be sure that the system has not been attacked and is safe for performing sensitive calculations. One special feature of our solution is that we derive a secret from the film’s production variations that can only be reproduced if the film is intact. This is used to encrypt the data on the system. When the system is powered up later on, it is possible to detect whether it was attacked, and that means that it does not need to be monitored permanently over its entire service life.
What other threats is hardware exposed to, apart from attacks via regular interfaces? The term side-channel attacks is used a lot. What is that?
To be able to understand this, we first need to talk about cryptography. In our world, cryptography plays an important role, as it is used to secure many forms of communication. Encryption is a key part of cryptography.
However, in application we are faced with the problem that while a cryptographic algorithm is extremely secure from a mathematical perspective, it cannot be executed on a PC, credit card, payment terminal or IoT device in a single step. This is why it is divided into many smaller calculation steps. And these intermediate steps are vulnerable.
The usual security assumption is that it is impossible to draw any conclusions about an algorithm’s secret key based on what goes into it and what comes out at the end. In real-life, however, attackers can watch hardware and draw conclusions about the calculations that are taking place, for example, based on electricity consumption, duration, electromagnetic radiation, storage device access patterns, or cache access times. This additional information is referred to as side channels.
Some patterns will, for example, only occur when a part of the secret key takes on a particular value. Based on this information, an attacker can draw up hypotheses for different keys and test whether they are correct. If this type of measurement is repeated thousands or even millions of times, the results can be analyzed statistically until clear differences emerge, allowing for information about the secret to be derived. Side-channel attacks therefore comprise two central parts: precise measuring of physical effects or monitoring of the micro-architecture’s behavior and analysis of measured data.
This is why in our cryptographic implementations we attach great importance to taking countermeasures that make such differences as hard to measure or interpret as possible.
How can you test this type of side-channel attack in the laboratory?
My colleagues in the hardware laboratory can perform measurements at different points, such as measuring a chip’s electricity consumption, or more localized measurements in which probes are used to determine magnetic fields around particular parts of a chip. The first step is to identify the areas that are relevant to an analysis. Optimization of these measurements to allow for data to be collected in a targeted manner and for disruptive factors to be minimized, is also one of the objectives of the APECS pilot line, by the way.
Another threat, in addition to side-channel attacks, are fault attacks. How do these differ from the scenario you just described?
While side-channel attacks are based on observations of a system, fault attacks interfere actively to disrupt the operation or state of a chip. They might, for example, block interfaces, such as by deactivating a diagnosis interface. The aim of a fault attack is to remove protective functions, for example, by re-activating an interface, disrupting the signature verification on startup or by changing configurations. Once this has been done successfully, it can also be the case that the attacker’s own malicious code is executed instead of the manufacturer’s software.
There are also fault attacks that target cryptographic calculations. In this case, disruptions are intentionally introduced in order to observe the resulting differences in behavior or results. These deviations allow for conclusions to be drawn about secret keys or internal processes.
How does Fraunhofer AISEC benefit from the APECS cooperation?
APECS allows us to significantly expand our design and analysis capacities, for example, through access to new devices and specialized tools. We also benefit from a strong network and professional exchange with our FMD colleagues, and that helps to sustainably strengthen our expertise and research capabilities. Our goal is to achieve even deeper insights into the underlying technology and to steadily develop our analysis methods further.
Let’s take a look at the bigger picture: what role does hardware security play from a European perspective?
Hardware security is important from a European perspective because of the high degree of complexity of the electronics supply chain and its global nature. A large number of partners are involved in the different steps that range from chip design, production, packaging and testing through to integration into a final product.
For Europe this means that critical components must be secured in a targeted manner and should ideally be provided locally. These include hardware trust anchors such as security chiplets for which it is transparent where they are from and which security standards they comply with. As a Fraunhofer institute we are able to develop such components in cooperation with industry and to adjust these to customer requirements. This reinforces Europe’s technological sovereignty and helps to reduce dependencies. From a European perspective, the issue of hardware security can also be a locational advantage.
Where do you see the greatest threats to the security of complex systems and what trends do you expect to see in the future?
The transition to post-quantum cryptography is an important trend. Powerful quantum computers have so far been able to quickly overcome secure mathematical methods. This is why new, more resistant algorithms are being developed and standardized. Implementing these new methods while exploring how such new algorithms might be attacked, and to use the resulting insights to derive ways in which complex systems can be hardened and secured further, is a fascinating process for us.
One final question: do all of these heightened security measures affect the per-formance of devices and systems?
Security always comes at a price. Developing certain functions is becoming an ever more elaborate process and using systems can become more complex, too. If a processor, for example, is operating and being monitored to see if anything is going wrong, this will give rise to additional hardware and energy costs. The same is true of cryptographic implementations. The better an implementation is secured against attacks, the bigger and more complex it gets. This has an impact on the space needed, on computing power and on development expenses, too.
Another issue are functional goal conflicts. Debug interfaces are essential for fault analysis, allowing us to understand why a device failed. From a security perspective, however, it would be ideal for this type of interfaces to not exist in the first place or to be strictly secured at the very least. These conflict areas give rise to design trade-offs that must be taken into account in development early on.
Do these threat scenarios require different defense strategies and protective measures?
Protective measures should always be geared towards the threat in question. Systems featuring critical functions or sensitive data require more comprehensive protection, while systems that are less relevant to safety aspects may require a lower degree of protection. This is provided for by means of different product classes in the Cyber Resilience Act (CRA), for example. As a general rule, attackers will always choose the most promising attack path. We do not know, what exactly an attack will look like, until it takes place. This means that systems do not need to be protected against only one method, but must feature a good overall level of protection against all types of attack that the attacker in question might choose.
There is no one-size-fits-all solution. Different technologies and measures need to be suitably combined and coordinated instead, and this can be achieved through close cooperation between security experts and the FMD colleagues.
Author
Matthias Hiller
Contact: matthias.hiller@aisec.fraunhofer.de
