Trusted Hart Architecture

• Trusted Hart Architecture is a design that reserves specific hardware threads for secure, isolated execution and verifiable attestation in RISC-V systems.
• It employs hardware-enforced isolation, cryptographic measurement, identifier-based access control, and secure storage to mitigate vulnerabilities and reduce the trusted computing base.
• Practical implementations demonstrate dedicated secure cores and dynamic enclaves, enhancing protection for mobile, cloud, and edge computing applications.

A Trusted Hart Architecture denotes a class of computer system designs—most prominently in the context of RISC-V platforms—where selected hardware threads ("harts") or processor cores are reserved, isolated, and equipped with specialized mechanisms to provide robust Trusted Execution Environments (TEEs). These architectures combine hardware-enforced isolation, cryptographic measurement and attestation, trusted I/O, and secure storage while mitigating side-channel vulnerabilities and constraining the trusted computing base via selective hardware and software modularity. Implementations analyze privileged core design, identifier-tagged access enforcement, fine-grained control-flow integrity, and explicit privilege-level management across both commercial and academic trusted systems.

1. Conceptual Foundations and Architectural Building Blocks

Trusted Hart Architectures are derived from the principle that strong isolation and verifiable execution for security-critical tasks must be implemented by leveraging the distinct properties of individually managed hardware threads or processor cores. The core concepts, as systematized across multiple TEE surveys and proposals (Schneider et al., 2022), include:

• Verifiable Launch: Establishment of a root of trust for measurement (RTM), either static (SRTM) or dynamic (DRTM), which cryptographically measures and attests to the integrity of the software stack at each stage:

$M = H(\text{Component})$

where $H$ is a cryptographic hash.

• Run-Time Isolation: Achieved by temporal partitioning (trusted context-switches and register scrubbing), spatial partitioning (dedicated harts), and logical separation (privilege modes, page tables, and memory protection mechanisms).
• Trusted I/O: Physically and logically enforced communication channels between trusted elements and peripherals, employ either access-control filtering or cryptographic binding.
• Secure Storage: Cryptographically protected ("sealed") storage, which binds secrets to both hardware and attested software measurement:

$C = \text{Enc}(\text{Key}, \text{Data})$

• Fine-Grained Trust Domains: The architecture supports dynamic enclaves, persistent trusted harts, or both, providing isolated domains for trusted application execution and centralized security services.

2. Practical Realizations: Trusted Hart in RISC-V Systems

Multiple research efforts articulate varied instantiations of Trusted Hart Architecture within RISC-V SoCs (Ushakov et al., 2022, Nasahl et al., 2020):

• Dedicated Secure Cores ("Trusted Harts"): One or more cores are permanently reserved at boot as trusted harts, running a minimal, security-hardened operating system (e.g., seL4 microkernel), and providing system-wide attestation, key management, and secure peripheral control. These cores persistently host security services, supporting dynamic enclaves and trusted applications on other, non-secure harts.
• Dynamic Enclaves: Leveraging Keystone-like frameworks, standard harts can instantiate memory-isolated enclaves dynamically through physical memory protection (PMP) and secure monitor (SM) mediation.
• Boot and Attestation Flows: Secure boot sequences cryptographically endorse both the Secure Monitor and Trusted Hart using algorithms such as EdDSA; for example:

$$\text{SGN}_D = \text{EdDSA}(\text{SHA}_{\text{SM}}\, || \, \text{PUB}_{\text{SM}}, \text{PRIV}_D)$$

$$\text{SGN}_{\text{SM}} = \text{EdDSA}(\text{SHA}_{\text{TH}}\, || \, \text{PUB}_{\text{TH}}, \text{PRIV}_{\text{SM}})$$

This ensures that all critical security components are measured and attested before assuming active roles.

3. Isolation and Access Control Mechanisms

Isolation is a central pillar (Nasahl et al., 2020, Ushakov et al., 2022). In advanced variants:

• Physical Separation: Trusted and untrusted domains reside on distinct cores, avoiding shared instruction pipelines, L1/L2 caches, and branch predictors to eliminate cache and transient execution side-channels.
• Identifier-Based Access Control: Every core, process, or peripheral is tagged with a tuple:

$$\text{ID} = (\text{core\_ID}, \text{process\_ID}, \text{peripheral\_ID})$$

This identifier propagates through the address/data interconnect (such as AXI4), governing access based on:

$$\text{Access Granted} \iff \text{ID}_{\text{sent}} = \text{ID}_{\text{stored}}$$

Hardware modules verify these tags against registers, permitting or denying access to resources at the hardware boundary.

• Control-Flow Integrity (CFI) Tied to I/O: Integrated cryptographic CFI, such as sponge-based authenticated decryption of instructions, maintains an internal execution state across instructions:

$I'_i = D_K(I_i, S_{i-1})$

I/O is only enabled if the current state matches the predetermined secure entry state $S_{SE}$, thus binding hardware peripheral access to unforgeable software execution paths:

$$\text{CFI State} = S_{SE} \implies \text{Peripheral Identifier} = S_{SE}$$

4. System Security and Trusted Computing Base (TCB) Reduction

Trusted Hart Architectures often minimize the TCB by integrating critical OS functions (multi-tasking, context switching, memory/resource management) in hardware, especially within secure co-processors (e.g., RISC-V Secure Co-Processor, RVSCP) (Nasahl et al., 2020). This approach reduces the reliance on large, potentially vulnerable software stacks inside the TEE. Smaller hardware TCB modules are amenable to formal verification, further strengthening the security posture.

Additionally, hardware-backed secure storage and isolated key material (e.g., via discrete TPMs, quantum RNGs) are foundational components in several proposals (Wang, 23 Jun 2025), ensuring that even compromise at other levels does not expose cryptographic secrets.

5. Trade-offs, Limitations, and Performance

Design alternatives reflect necessary trade-offs between isolation strength, performance, and flexibility (Schneider et al., 2022):

• Resource Allocation: Dedicating hardware threads or cores solely to trusted execution reduces total system concurrency for general-purpose workloads.
• Memory Isolation: Finer-grained MMU-based isolation supports complex workloads but requires trusted management of additional metadata; MPU- or cryptographic controller–based memory protection is simpler but less flexible.
• I/O Latency: Securely routing I/O through trusted harts or identifier-based access checks introduces overhead but is essential for end-to-end security.
• Attestation Overhead: Enhanced attestation flows (such as mutual attestation between brokers and clients in distributed settings) can increase connection latency and message overhead, as measured in empirical evaluations (e.g., a 1.55× decrease in message throughput observed in TEE-assisted publish/subscribe brokers (Ménétrey et al., 2023)).

6. Broader Impact, Applications, and Comparative Analysis

Trusted Hart Architectures have been applied in a variety of contexts:

• Mobile Security: Dedicated trusted harts orchestrate secure storage, key management, and device attestation in RISC-V-based mobile devices, supporting GlobalPlatform TEE APIs and integration with open-source TEE frameworks such as Keystone (Ushakov et al., 2022).
• Cloud and Edge Computing: High-confidence architectures combine trustworthy instruction set design, separated bus topologies, and externalized key management (dTPM), explicitly supporting multi-tenant, virtualized, and distributed scenarios (Wang, 23 Jun 2025).
• Publish/Subscribe Systems: Fully attested brokers running in TEEs (using frameworks like WebAssembly for portability) guarantee the confidentiality and authenticity of distributed message flows, mitigating software supply chain and platform compromise threats (Ménétrey et al., 2023).

Compared with established split-world TEEs (e.g., Arm TrustZone), architectures based on trusted harts demonstrate improved flexibility in resource allocation (static versus dynamic), a distinct model for persistent security services, and minimize dependence on monolithic privileged software by distributing responsibilities between hardware, secure monitors, and dedicated trusted cores.

7. Theoretical and Mathematical Underpinnings

The trustworthiness of a Trusted Hart Architecture is mathematically grounded in:

• Cryptographic Measurement and Attestation: All critical boot and runtime artifacts are measured via cryptographic hash functions, and trust is pinned to signatures over these measurements.
• Control-Flow Integrity via Authenticated Encryption: Instruction stream integrity is enforced through cryptographically chained decryption, where past execution affects the current state, expressed as $I'_i = D_K(I_i, S_{i-1})$, preventing code-reuse or JOP/ROP attacks.
• Computation Models: Foundational models such as the Turing machine ($T = (Q,\Sigma,s,\delta)$) remind that the processor's ISA and state transitions must be mapped securely from high-level policy to hardware action (Wang, 23 Jun 2025). Speculative side effects are confined or eliminated via specifiable barriers at the architectural level.

---

Trusted Hart Architectures systematically extend the state of secure execution by leveraging physical and logical hardware isolation, formalized access and attestation protocols, and co-designed hardware/software primitives. These architectures form a convergent point between the goals of established TEE designs and the specific mechanisms of open, modular platforms such as RISC-V, offering a blueprint for both academic exploration and practical deployment of trusted computing in heterogeneous and distributed environments.