The NCSC research problem book
Pages
Page 9 of 21
Hardware security problems

Introducing the hardware security problems
Processors and microelectronics are now such a common feature of everyday devices that how they behave is foundational to every aspect of our digital lives. This makes it crucial to understand the impact they have on the security of a wider system. This chapter in the problem book sets out to inspire the wider research community and highlight the areas where we think further research can make the most difference.
These problems are hard and each one encompasses specific research questions, with a common thread of physical hardware. They are closely linked to most of the cross-cutting problems described in the cross-cutting chapter, but with a particular focus on the hardware angle.
We have identified the following four problems and justifications:
- 1
How do our devices physically behave, and how do we secure those behaviours?
To address physical attacks, and to establish the behaviour on which the rest of the system builds.
- 2
How do we know that we can trust our devices?
It’s important to understand the amount of trust we have in a device, and the limits of that trust.
- 3
What device architectures help us to improve security further up the stack?
To build devices that meet our security goals by design.
- 4
How do we integrate secure devices, to ensure that the security still holds at the system level?
To make it easy to build a secure system without needing to be an expert in every device used.
What do we mean by hardware security?
It can be difficult to define hardware security. It’s not always clear what the term ‘hardware’ includes, and so this follows through when it comes to its security. In cyber security, ‘hardware’ is commonly paired with ‘embedded systems’ or ‘firmware’.
In the context of the problem book when we say hardware, we mean everything physical that contributes to a computing end product. This includes everything from semiconductor physics up to the design and use of a multi-core processor. We also include the nuances of how software interacts with hardware – whether this is an interface definition, a configurable behaviour such as microcode, or low-level firmware like bootloaders and management engines.
This might seem like a slightly strange definition, since we’re saying that ‘hardware’ actually includes some software. But this is important because ‘software’ here only makes sense in the context of the specific hardware, and it ensures that security in the hardware-software interface is properly considered.
To help consistency and clarity, we provide definitions below for some of the key words that appear frequently in this chapter:
- Device - a single entity that provides a specific function within a system. In most contexts this refers to a single integrated circuit, such as a central processing unit (CPU), graphics processing unit (GPU), or memory chip. This might be in the form of a microchip, or could be a chiplet within a multi-die package.
- System - a set of devices working together as part of a wider computing platform. This could be a PC, mobile, gateway, radio or other custom platform.
Architecture - in this chapter we talk about both device architectures and system architectures.
Device architectures describe the way functional blocks within a device are logically laid down and connected together. These might include a multi-core CPU, the compute units in a GPU, or the digital blocks instantiated on a field programmable gate array (FPGA).
System architectures describe how these devices are connected, what function each device performs, what interfaces/protocols are used, and how the full system is built up.
We’re interested to hear about work that’s happening that contributes to solving these hardware security problems and have set up a form for you to tell us more, including the institution you’re linked with and whether you’ve worked with us before.