---
title: Trusted Hart Architecture
url: https://www.emergentmind.com/topics/trusted-hart-architecture
type: topic
---

# Trusted Hart Architecture

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 [2205.12742], 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 [2211.10299, 2009.05262]:

- **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 [2009.05262, 2211.10299]. 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) [2009.05262]. 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 [2506.18780], 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 [2205.12742]:

- **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 [2312.00702]).

## 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 [2211.10299].
- **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 [2506.18780].
- **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 [2312.00702].

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 [2506.18780]. 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.

Source: https://www.emergentmind.com/topics/trusted-hart-architecture