Secure Element & Trusted Execution Environments

• Secure Element and Trusted Execution Environments are fundamental isolation techniques, with SEs using dedicated tamper-resistant chips and TEEs employing virtualized CPU partitions.
• SEs deliver robust physical protection and limited programmability, while TEEs offer high-performance, flexible execution that must address shared resource vulnerabilities.
• Modern implementations combine FPGA-based, dynamic, and composite enclave methods to enhance attestation, secure communication, and scalable isolation.

Secure Elements (SEs) and Trusted Execution Environments (TEEs) are foundational technologies for isolating and protecting security-critical applications and secrets. SEs are physically isolated tamper-resistant chips dedicated to secure cryptographic services and key storage. TEEs, by contrast, are hardware-backed partitions within general-purpose CPUs that run trusted code in isolated enclaves, often co-resident with untrusted processes. The core architectural and security differences between SE and TEE directly influence attack surface, performance, programmability, and applicability across domains ranging from embedded IoT to cloud infrastructure.

1. Definitions and Fundamental Isolation Properties

Secure Elements are dedicated microcontrollers or on-chip security processors—examples include Google Titan, Apple T2, and TPM modules—that implement their own CPU cores, ROM, cryptographic accelerators, and secure storage. SEs are physically separated from the host CPU and defend against local adversaries with complete system and bus access; their hardened die and on-chip secure memory are nearly impervious to typical microarchitectural attacks but susceptible to physical probing, side-channels, or bus fault injection (Pereira et al., 2021).

Trusted Execution Environments are secure, virtualized domains within the main CPU. Architectures such as ARM TrustZone or Intel SGX use hardware privilege rings, MMUs, and cryptographic primitives to create “enclaves” that are isolated from the Rich Execution Environment (REE), even in the presence of a hostile OS or hypervisor. While TEEs enforce confidentiality and integrity of enclave code via access controls and sealing, they share hardware resources (caches, buses, peripherals) with the REE and are thus more exposed to microarchitectural and software side-channels (Schneider et al., 2022).

SEs excel in providing hardware-rooted, physically separated isolation at the expense of limited bandwidth, programmability, and interfacing flexibility; mainstream TEEs offer general-purpose execution contexts and higher bandwidth but inherit greater attack surface from shared microarchitecture and virtualized orchestration (Pereira et al., 2021, Paju et al., 2023).

2. Architectural Paradigms and System Design

SEs are realized as discrete chips or secure on-chip processors. Their architecture prioritizes a minimal Trusted Computing Base (TCB), integrating only essential cryptographic logic and tamper-resistant key stores, tightly bound by fuses and active sensors. SE APIs are intentionally narrow—for key management and primitive crypto routines—and do not permit general-purpose code execution or integration with arbitrary peripherals (Schneider et al., 2022).

Classic TEE designs—such as Arm TrustZone—partition system resources into Secure World (SW) and Normal World (NW) using hardware flags (e.g., NS-bit, TZASC) and monitor mode handlers. TEEs can access both secure and non-secure memory; the non-secure world is strictly forbidden from accessing secure regions. Context switches are handled by Secure Monitor Calls (SMCs), which save/restore CPU state and memory mappings (Amacher et al., 2019, Li et al., 2024). The GlobalPlatform API standardizes the orchestration of Trusted Applications (TAs) in TEEs.

Modern research efforts extend TEE paradigms beyond onboard CPUs. TEE On-Demand (TEEOD) (Pereira et al., 2021) leverages FPGA programmable logic to instantiate per-application enclaves—each with its own soft-processor (e.g., Cortex-M1) and private block-RAM slice—achieving both circuit-level physical isolation and high-bandwidth interconnects (AXI-DMA, mailbox interrupts). BYOTee (Armanuzzaman et al., 2022) pushes this further, enabling dynamic enclave creation with softcore CPUs configured on commodity FPGAs, hardware-rooted attestation of bitstreams and firmware, and full circuit-level isolation, closing all CPU-cache sharing side channels. Composite enclaves (Schneider et al., 2020) generalize TEEs to span disaggregated hardware: a single logical enclave can multiplex unit enclaves over CPUs, FPGAs, accelerators, and I/O devices, each bringing its own hardware and software TCB.

3. Isolation Guarantees, Threat Models, and Attack Surfaces

SEs provide very strong isolation via independent silicon, minimal hardware resource sharing, and tamper-detection mechanisms. Typical attack vectors are physical: power/EM side-channels, bus probing (especially on exposed SPI/I²C lines), and fault-injection. However, their silicon is minimal—resulting in a low microarchitectural attack surface—and they are robust against software compromise on the host (Pereira et al., 2021, Schneider et al., 2022).

TEEs enforce isolation in software by privilege rings, memory protection units, and cryptographic techniques: run-time domain switching, spatio-temporal memory partitioning, and enclave sealing. However, enclave memory often shares DRAM, cache hierarchies, and bus fabrics with REE—vulnerable to speculative execution leaks (Foreshadow, Sgxpectre), cache-timing, off-path DMA, and hypervisor attacks (Pereira et al., 2021, Schneider et al., 2022, Nasahl et al., 2020). Verified launch, run-time isolation, trusted I/O, and attested secure storage are their defining security goals, but practical designs must address side-channels (Prime+Probe, transient execution), cross-enclave leakage, rogue DMA, and bus contention—especially when heterogeneous devices are part of the TCB (Schneider et al., 2020).

Empirical evaluation of FPGA-based TEEOD demonstrates zero cross-enclave leakage (mailboxes are strictly per-enclave), per-enclave resource usage formulas (7% LUT, 3.8% FF, 15.3% BRAM per enclave), microsecond-scale context switches, and authenticated loading protocols. Isolation is both physical (distinct BRAM slices) and logical (manager-enforced TA loading/unloading/reset) (Pereira et al., 2021). In RISC-V designs, PMP-enforced regions and on-chip co-processors (e.g., HECTOR-V RVSCP) push isolation policies into hardware, mitigating cache and bus side-channels (Ren et al., 2022, Nasahl et al., 2020).

4. Enclave Lifecycle: Attestation, Resource Management, and Performance

TEE lifecycle management hinges on attestation: secure bootchain, launch measurement, authenticated loading, and runtime integrity. Static roots-of-trust (RTM) validate enclave code; dynamic roots allow arbitrary measurement at runtime; attestation protocols transmit enclave measurements signed by hardware keys to local or remote verifiers (Schneider et al., 2022).

Resources are tightly managed. In TEEOD (Pereira et al., 2021), per-enclave resource usage is formalized:

• $LUT\_usage_i = 0.07 \times Total\_LUTs$
• $FF\_usage_i = 0.038 \times Total\_FFs$
• $BRAM\_usage_i = 0.153 \times Total\_BRAMs$

Context switch and command invocation latencies are characterized (e.g., cold-load OpenSession: 54 ms, hot-open: 31 μs, command invocation: up to 327 μs for 16B exchanges). In composite enclaves (Schneider et al., 2020), context switch overheads rise minimally (e.g., 220 cycles extra, 4.65% latency increase), with attestation reports reflecting the configurable device TCB.

BYOTee (Armanuzzaman et al., 2022) supports hardware-rooted attestation—bitstream signatures, firmware hash chains, and per-enclave application measurements—providing MAD root-of-trust continuity not found in legacy TEEs. Dynamic reconfiguration enables on-demand provision and destruction of enclaves.

5. Comparative Analysis: SEs, TEEs, FPGA-based, and Heterogeneous Architectures

Platform	Isolation Model	Performance/Resource	Attack Surface
Off-chip SE	Physical (separate die, tamper sensors)	Low bandwidth (<20 MB/s), minimal CPU	Side-channel, bus probing, fault-injection
On-chip SE	Dedicated CPU+secure memory	Fast local ops, static single instance	Minimal microarchitectural; exposed bus lines
Classical TEE (TrustZone/SGX)	Virtualized “secure world” on CPU	High bandwidth, flexible, 100 μs context switch	Shared caches, speculative exec, DMA attacks
FPGA-TEE (TEEOD, BYOTee)	PL-based enclaves, circuit-level isolation	Per-enclave usage formulas, scalable, microsecond context switch	No shared caches, minimal cross-enclave leakage
Composite enclave	Distributed across CPU+devices	220 cycles overhead, flexible TCB	Bus/channel attacks, per-device driver TCB

FPGA-based TEEOD and BYOTee demonstrate per-application isolation by creating separate CPUs/BRAM/IP blocks for each enclave, avoiding side-channels and supporting high-bandwidth loads. HECTOR-V (Nasahl et al., 2020) and XINE (Ren et al., 2022) leverage multi-core and privilege arbiters to realize OS-independent isolation and end-to-end control-flow integrity. Composite enclaves extend the TCB to dynamically selected devices, balancing least-privilege against expanded hardware attack surface (Schneider et al., 2020).

6. Practical Implementations and Application Use Cases

TEEOD (Pereira et al., 2021) is prototyped on Ultra96-V2 (Xilinx ZU3EG), running up to six simultaneous enclaves, successfully hosting a legacy Bitcoin wallet TA with full secure storage and ECDSA operations. Use of AXI-DMA for code loading and mailbox-based RPC supports real-world applications demanding high throughput.

PLC security multiplies partitioning across TrustZone-based TEE and SE: OP-TEE hosts logic-only and scan-cycle Trusted Applications, acts directly on control inputs/outputs, and uses secure boot and cryptographic key storage (Li et al., 2024). Overheads scale linearly with complexity (# of slaves), indicating max throughput boundaries for hard real-time industrial devices.

Integration paradigms blend SE and TEE: SEs store long-term keys, while TEEs perform protocol/transaction logic—EMV, biometric authentication, IoT sensor analytics (Schneider et al., 2022). FPGA-based TEEs can provide enclaves for edge analytics, with SE managing attestation roots and key distribution.

7. Open Challenges, Research Directions, and Future Outlook

Persistent open problems include the absence of robust, cross-platform attestation standards, side-channel resilience (TEEs typically lack formal side-channel resistance), and scalable multi-tenant isolation (Schneider et al., 2022, Paju et al., 2023). FPGA-based architectures expose new use-cases but trade off real-time reconfigurability with potential area and BRAM bottlenecks (Armanuzzaman et al., 2022, Pereira et al., 2021). Composite enclaves redefine the trust boundary but invite expanded TCB size and complexity (Schneider et al., 2020).

Formal verification of TEE runtime, attestation modules, and interconnects is essential to ensure correctness and minimize TCB. Research into dynamic partial reconfiguration, programmable access control, and the melding of SE-class physical tamper resistance with programmable TEEs will define next-generation hardware trust (Pereira et al., 2021, Nasahl et al., 2020).

In conclusion, the synthesis of SE and TEE approaches—combining minimal, physically-protected cryptographic roots with high-performance, flexible enclave execution and hardware-rooted attestation—enables robust, scalable, and application-tailored secure computation platforms suitable for embedded, edge, and cloud domains.