The NCSC research problem book
Page 13 of 21
HW4 - How do we integrate secure devices so they contribute to security at the system level?
How do we integrate secure devices so they contribute to security at the system level?
In other problems in this chapter, we’ve outlined the challenges in developing trustable devices. We want the security properties that these devices enforce to add value to a wider system, but the security goals of a system are different to the security goals of a device, and the act of integrating these devices potentially changes the security behaviours. We’re therefore interested in researching the composability of security, and how we can use devices to improve the security of a system.
Strands or sub-problems
-
Understanding the security properties of a device
As things currently stand, understanding what security a device does or doesn’t offer requires wading through marketing material, datasheets or white papers, searching through academic archives, or engaging with device vendors. This doesn’t scale, and is probably the reason behind many of the accidental misconfigurations and misuse of devices that lead to vulnerabilities. With this strand we’re asking if there is a better way to do this and whether one approach is to develop a standard mechanism to describe the security properties of (and the assumptions made by) a device.
-
Interfaces
In some respects, we can treat interfaces as another device in the system. If two devices each guarantees confidentiality of data, but communicate over an interface that doesn’t, it undermines our confidence in the system. Understanding the security properties of an interface is just as important as understanding the devices themselves.
-
Emergent properties
Once we have a way to understand the properties of a device and an interface, we can start to understand the system’s security properties. If we can describe the properties of the components of a system in a standard way, can we automatically report the properties of the system? And once we can do that, what does it show us about how these properties integrate? This problem becomes even more prevalent as the complexity of systems increase, and as heterogeneous integration makes devices even more tightly coupled than before.
-
Using hardware security primitives
As described above, there is a lot of research happening into hardware security primitives, but there is less of a focus on how many of them can be used practically in a system. Understanding the security needs of a system, and the security of the end-to-end protocol in which a primitive is used, could lead to more focused research into the use and design of primitives.
-
Working with the market
How do we incentivise adoption of better hardware security? This includes points already raised around simplifying integration, default behaviours and providing evidence, but also requires understanding of the market. What will incentivise demand for these technologies? How do we design secure hardware to be cheaper and easier to use? An improved understanding of the requirements of particular markets, and the constraints on products within them, will focus hardware security research into areas where there is already demand for their outputs.
Why this is important
“Security analysis is a hard and manual process that often struggles to account for the business and practical requirements. This might never go away, but if we can automate any of the processes, if we can produce systems that can describe, or even maintain their own security, then we’re in a much stronger position.
If our devices and primitives are designed with the rest of the system in mind, or the system can be designed to cope with whatever security properties a device includes, then as with previous problems, we will have a much better idea of what we’re getting from a system, and that transparency will enable better decisions. This could take the form of hardware to enable zero-trust systems, or providing the agility to update security over time.“
Charles Brookson OBE, Chair of the Industry Advisory Board at the Research Institute for Secure Hardware and Embedded Systems