Hardware Root of Trust Implementation in System-on-Chip Design: Architecture and Threat Modelling

Abstract

Software cannot check one thing about itself: whether the layer beneath it has been tampered with. A signature check in the operating system, isolation enforced by a hypervisor, an application sandbox, and each one simply inherits whatever integrity the boot firmware and the silicon underneath already had. The hardware root of trust (HRoT) breaks that circular dependency. It puts a small, fixed set of verification and key-management functions into the silicon itself, where an attacker cannot rewrite them once the part has been fabricated. This article examines how such an anchor is built inside a system-on-chip and what building it actually costs. The analysis is organized around a property-mapped framework that links every HRoT primitive both to the trust roots defined in NIST Special Publication 800-193 and to the area, power, and latency the primitive consumes. Four contributions follow from that framework. The first is a consolidated threat model that ties three adversary tiers to four attack classes, namely hardware Trojan insertion, side-channel leakage, fault injection, and physical probing, together with the countermeasure for each. The second is a description of the HRoT architecture, its building blocks, and the bus-level isolation that keeps them apart from untrusted logic. The third is a secure-boot and key-verification methodology that turns those countermeasures into a concrete boot sequence, resting on an immutable boot ROM, a one-time-programmable verification anchor, a PUF-seeded key ladder, and a fault-resistant verification step. The fourth grounds the cost of each mechanism in representative figures drawn from the published literature, then applies the framework to two very different device profiles. The recurring finding is uncomfortable for designers: protection cost climbs faster than the assurance it buys. That pattern argues against piling on every available defence and in favour of choosing protection to match the value of the asset and the reach of the adversary. This is an analytical review. The quantitative figures are illustrative, and any real design should replace them with synthesis data for its own technology node.