Feature: Semiconductors


Securing the Edge: CHERI and the future of trustworthy embedded systems


By Haydn Povey, Chief Executive Officer, SCI semiconductor I


n the rapidly evolving landscape of Critical National Infrastructure (CNI), embedded systems are ubiquitous, from programmable controllers in energy grids to edge nodes in transport monitoring and


defence systems. Yet, despite their pivotal role, these devices are oſten built on legacy microcontroller architectures that lack fundamental protections against today’s cyber threats. As a result, the vast majority of CNI deployments remain vulnerable, with attackers increasingly targeting the embedded edge to disrupt, surveil, or control mission-critical systems. Most microcontrollers rely on a simple


flat memory model, where code and data coexist with few meaningful boundaries. Tis leaves them vulnerable to Memory Safety attacks such as buffer overflows, use-aſter-free bugs, and return-oriented programming, which typically represent 70 per cent of critical vulnerabilities and exploits (CVE), the foundation of most attack techniques that continue to compromise real-world systems. Furthermore, many embedded platforms provide little to no hardware-enforced compartmentalisation, making privilege escalation trivial once a single soſtware component is compromised. Security solutions typically added later in the design cycle, such as secure


24 June 2025 www.electronicsworld.co.uk


boot or external MTE (memory tagging extensions) on more complex systems, can mitigate some risks, but they don’t solve the root problem: the architecture itself was never designed with modern security in mind. Most modern hardware security evolved from technologies that were created to allow companies to replace multiple minicomputers with a single mainframe. Tey were built to isolate unrelated workloads. Tis is not what a modern system needs - we no longer have unrelated workloads, instead we have closely interacting components that have different security requirements with many coming from different vendors. Tis creates a dangerous mismatch between the risk profile of today’s CNI environments and the capabilities of the embedded platforms on which they depend. Te embedded industry is beginning to


recognise that 'secure-by-default' platforms are essential. Tis means building systems where memory safety, privilege separation, and strong isolation are not optional features but foundational design principles. However, widespread adoption of


secure hardware architectures has been slow. Developers cite concerns over performance, silicon cost, toolchain disruption, and retraining. Tere's also a perception that secure architectures are only suitable for high-end application


processors, not resource-constrained microcontrollers. Te CHERI (Capability Hardware


Enhanced RISC Instructions) model aims to overcome these barriers. Originally developed by University of Cambridge and SRI International, and funded by the US defence research agency DARPA, CHERI introduces a fine-grained, hardware-enforced memory protection model based on capabilities, unforgeable tokens that tightly couple access rights with memory references. Tis model enables both spatial memory safety and strong compartmentalisation, dramatically reducing the exploitability of soſtware bugs. Most prior hardware security features


were designed for operating systems to use. CHERI, in contrast, was designed to be exposed to programmers via language abstractions. Tis allows a tight coupling between the application logic and the programmer model. Today, if you want to pass an object to a third-party library, you pass a pointer to that string as an argument to a function call. With process-based (or similar) isolation, you instead must serialise the object, send it over some inter- process-communication channel, and then wait for a response. In a CHERI system, you simply pass a ‘Capability’, containing the pointer and meta data, to the object,


Page 1  |  Page 2  |  Page 3  |  Page 4  |  Page 5  |  Page 6  |  Page 7  |  Page 8  |  Page 9  |  Page 10  |  Page 11  |  Page 12  |  Page 13  |  Page 14  |  Page 15  |  Page 16  |  Page 17  |  Page 18  |  Page 19  |  Page 20  |  Page 21  |  Page 22  |  Page 23  |  Page 24  |  Page 25  |  Page 26  |  Page 27  |  Page 28  |  Page 29  |  Page 30  |  Page 31  |  Page 32  |  Page 33  |  Page 34  |  Page 35  |  Page 36  |  Page 37  |  Page 38  |  Page 39  |  Page 40  |  Page 41  |  Page 42  |  Page 43  |  Page 44