PaperlayerView exact revision on arXiv

Source-linked AI summary

YAVIN: A Unified Architecture for Secure Edge Processing in Memory

Shouzhi Fang, William C. Tegge, Md Omar Faruque, Peipei Zhou, Endadul Hoque, Alex K. Jones

arXiv:2608.13496v1cs.AR

TL;DR

Existing TEEs do not protect trusted computation performed in memory, limiting secure multi-tenant PIM across untrusted memory buses. YAVIN extends the TEE across processor and protected memory regions, achieving 34.2% and 9.3% overhead for INT8 and INT32 edge-class workloads, respectively.

  • Problem

    Existing TEEs trust only processor execution, leaving no trusted path for computation directly within memory across an untrusted memory bus.

  • Method

    YAVIN creates a distributed TEE spanning processor and isolated memory regions, using post-quantum key establishment and DRAM-PIM authenticated encryption for cooperative execution.

  • Results

    34.2% and 9.3% overhead are achieved for edge-class workloads with 8-bit and 32-bit quantization, respectively, relative to plaintext execution.

  • Takeaways & Limitations

    YAVIN provides a foundation for secure multi-tenant PIM systems in edge-class computing environments while preserving PIM performance advantages.

Abstract

from arXiv · show

Secure, private multi-tenant execution spanning processors, memory, and accelerators remains one of the most significant challenges in modern edge computing systems. Simultaneously, processing-in-memory (PIM) has emerged as an effective approach for reducing the Von Neumann bottleneck by moving computation closer to data. Existing trusted execution environments (TEEs) establish trust only within the processor, protecting data while it traverses untrusted resources such as the memory bus. Consequently, trusted computation cannot be performed directly within memory. We present YAVIN, a unified trusted computing base (TCB) that extends the TEE beyond the processor to encompass both processor execution and a dedicated memory region supporting trusted processing-in-memory execution while treating the memory bus as untrusted. Leveraging the dedicated protected memory regions already established by conventional TEE architectures, YAVIN enables data to be decrypted, processed, and re-encrypted by either processor or PIM execution while remaining within the TEE. To realize this unified TCB, YAVIN presents the first PIM implementations of the LightSaber KEM post-quantum cryptosystem and ASCON-128 authenticated encryption, co-designing both algorithms for efficient DRAM execution to establish and maintain shared cryptographic state. Finally, we demonstrate how cryptography-PIM co-design for tensor-based workloads reorganizes computation to satisfy the ordering constraints imposed by authenticated encryption with minimal performance overhead while simultaneously enabling bit-sliced ordering that limits temporary plaintext exposure. Compared to the latest PIM AES implementation, YAVIN achieves more than a 20x speedup while incurring only 34% and 9.3% overhead when executing INT8 and INT32 quantized edge-class LLMs, respectively, relative to plaintext execution.

I. INTRODUCTION

YAVIN extends trusted execution from the processor into a physically isolated memory region for cooperative processor–PIM execution while treating the memory bus as untrusted. It co-designs post-quantum key establishment, authenticated encryption, data organization, and scheduling to support secure in-memory computation with reduced plaintext exposure.

  • YAVIN architecture: YAVIN creates a distributed TEE spanning each tenant’s processor and memory-resident trusted execution environments while treating the memory bus as shared and untrusted.Each tenant receives a physically isolated trusted memory region within the unified TCB.
  • Cryptographic co-design: Both processor and memory decrypt data, compute on plaintext, and locally re-encrypt results so plaintext does not traverse the untrusted memory bus.YAVIN uses Ascon-AEAD for its PIM suitability and built-in authentication capability.
  • Data organization and scheduling: YAVIN uses tensor-index and bit-level scheduling to satisfy Ascon-AEAD’s ordering requirements while limiting temporary plaintext exposure during PIM execution.The threat model places decrypted, processed, and re-encrypted data inside a private memory region, while data outside it remains encrypted.
  • Cryptographic co-design: YAVIN implements LightSaber and Ascon-AEAD for secure in-memory execution using cryptographic primitives suited to bulk-bitwise DRAM execution.The implementations provide approximately 128-bit security and integrate authenticated encryption directly within charge-sharing DRAM.
  • Evaluation: Co-designing cryptography, data organization, and computation scheduling enables trusted PIM execution while minimizing plaintext exposure and cryptographic overhead.The evaluation compares the co-designed architecture with PIM implementations based on conventional AES- and ECC-based schemes.

II. BACKGROUND AND RELATED WORK · A. DRAM-Based Processing-In-Memory

The background introduces the foundations of YAVIN, including TEE memory-encryption limits, cryptographic components, DRAM entropy sources, and charge-based in-DRAM PIM. DRAM-based PIM reduces data movement by exploiting charge-sharing operations within memory arrays.

  • II. BACKGROUND AND RELATED WORK: YAVIN’s foundations include TEE memory-encryption limitations, lattice-based key encapsulation, ASCON, DRAM entropy sources, and charge-based in-DRAM PIM.The section begins by reviewing these concepts before introducing charge-based in-DRAM PIM.
  • A. DRAM-Based Processing-In-Memory: PIM encompasses near-memory and processing-using-memory architectures that reduce data movement bottlenecks in energy- and latency-intensive workloads.YAVIN specifically targets processing-using-memory for bulk-bitwise PIM.
  • A. DRAM-Based Processing-In-Memory: YAVIN’s bulk-bitwise PIM exploits analog charge sharing on DRAM bitlines to perform logic without dedicated computational logic.The approach uses DRAM’s intrinsic electrical behavior rather than adding computational units.
  • A. DRAM-Based Processing-In-Memory: In-DRAM PIM operates primarily within subarrays of open-bitline DRAM, where capacitive cells connect through access transistors to shared bitlines and sense amplifiers.Bitlines are equalized to 1/2VDD before access, and ACTIVATE connects a row’s capacitors to the bitlines.
  • A. DRAM-Based Processing-In-Memory: Simultaneously activating three DRAM rows implements majority logic by resolving shared-bitline charge to the majority value of the three inputs.Stored constant rows, such as all-zeros or all-ones, can extend majority logic into bulk bitwise operations.
  • A. DRAM-Based Processing-In-Memory: Horizontal shifting moves data laterally within a DRAM row through adjacent-bitline charge sharing or dedicated row-buffer logic, enabling in-array rotations and shifts.These operations are critical for cryptographic permutations that use bitwise rotations for diffusion.

B. Trusted Execution Environments and Memory Encryption · C. Lattice-Based Key Encapsulation: Saber · D. ASCON Lightweight Authenticated Encryption

Conventional TEEs protect processor execution but leave memory-bus and DRAM exposure unresolved for trusted PIM, while AES-XTS lacks integrity protections and is costly for PIM. YAVIN addresses these limitations by combining LightSaber and ASCON-AEAD within a unified processor–memory trusted computing base.

  • B. Trusted Execution Environments and Memory Encryption: TEEs isolate sensitive computation, but conventional architectures assume trusted execution occurs inside the processor.Intel SGX protects application enclaves in the EPC, whereas AMD SEV encrypts each virtual machine’s memory with a unique key.
  • B. Trusted Execution Environments and Memory Encryption: Memory-bus and DRAM data remain exposed to physical attacks, motivating processor-to-DRAM encryption through AES-XTS.Intel TME and AMD SME encrypt transferred data, but this CPU-side architecture complicates PIM execution.
  • B. Trusted Execution Environments and Memory Encryption: Secure PIM architectures extend trusted execution into memory while treating the memory bus as untrusted.SecNDP, SSS-DIMM, and MemClave exemplify trusted near-memory or memory-resident execution approaches.
  • B. Trusted Execution Environments and Memory Encryption: AES-based in-memory encryption incurs substantial PIM overhead, while AES-XTS provides confidentiality without integrity, freshness, or replay protection.YAVIN targets both limitations through cryptography-PIM co-design.
  • B. Trusted Execution Environments and Memory Encryption: YAVIN co-designs LightSaber and ASCON-AEAD to establish shared cryptographic state across processor and memory TEEs.This enables authenticated communication over an untrusted memory bus within a unified distributed TCB.
  • C. Lattice-Based Key Encapsulation: Saber: LightSaber matches ML-KEM’s targeted post-quantum security levels while using power-of-two reductions, with q = 8192 = 2^13 and p = 1024 = 2^10.These reductions map to discarding high-order rows, and rounding maps to row-index reordering.
  • C. Lattice-Based Key Encapsulation: Saber: LightSaber uses a rank-2 module and provides KeyGen, Encaps, and Decaps operations for key generation, shared-secret encapsulation, and recovery.Its polynomial-ring construction uses a 2 × 2 public matrix and a 2 × 1 secret vector.
  • D. ASCON Lightweight Authenticated Encryption: ASCON is NIST’s lightweight authenticated-encryption standard, and its bitwise XOR, AND, and NOT permutation operations suit bulk-bitwise DRAM execution better than AES.ASCON also supplies authentication by design, unlike AES-XTS confidentiality alone.

E. DRAM-Intrinsic Entropy Sources · III. THE YAVIN TRUSTED COMPUTING ARCHITECTURE · A. LightSaber design in PIM

YAVIN builds trusted execution across the processor and DRAM by combining DRAM-intrinsic entropy, shared cryptographic state, and PIM implementations of LightSaber and ASCON-128. Its DRAM engine derives LightSaber keys from physical randomness and performs cryptographic polynomial operations using bulk-bitwise processing.

  • E. DRAM-Intrinsic Entropy Sources: DRAM supplies physical randomness for YAVIN’s hardware root of trust through power-up patterns and controlled row conflicts.These mechanisms provide entropy that software cannot predict, clone, or extract.
  • E. DRAM-Intrinsic Entropy Sources: DRAM PUFs derive chip-specific secrets from manufacturing variations in threshold voltage and capacitor geometry.The entropy comes from each chip’s unique power-up initialization pattern.
  • E. DRAM-Intrinsic Entropy Sources: Controlled row conflicts generate TRNG entropy when thermal noise resolves metastable shared-bitline charge states.The resulting secrets are unique to each die and cannot be replicated on another module.
  • III. THE YAVIN TRUSTED COMPUTING ARCHITECTURE: YAVIN extends trusted execution from the processor into memory, enabling charge-sharing PIM for trusted multi-tenant execution without dedicated near-memory processing hardware.The architecture treats processor and memory execution as parts of a unified trusted computing base.
  • III. THE YAVIN TRUSTED COMPUTING ARCHITECTURE: A shared symmetric key lets the CPU and memory decrypt, process, and re-encrypt protected data using Ascon-AEAD with a 128-bit key.The parties agree on the key by running the LightSaber KEM.
  • III. THE YAVIN TRUSTED COMPUTING ARCHITECTURE: Memory seeds its LightSaber private key with a DRAM PUF, while the CPU encapsulates to the public key and memory decapsulates the stored ciphertext.The protocol establishes an identical shared secret across the CPU and memory despite the untrusted bus.
  • A. LightSaber design in PIM: LightSaber key generation, encapsulation, and decapsulation execute directly in DRAM through bulk-bitwise operations and reusable cryptographic building blocks.The implementation uses SHAKE-128 expansion, CBD sampling, and negacyclic polynomial multiplication; decapsulation operates with mod q = 8192 and mod p = 1024.

1) Hardware Root of Trust via DRAM Entropy: · 2) Seed Expansion via Parallel SHAKE-128:

YAVIN establishes a DRAM-originated hardware root of trust from physical cell randomness, then expands a short seed with parallel SHAKE-128 to generate the pseudorandom bits required for CBD10 sampling. Its PIM layout maps Keccak state lanes onto DRAM rows and produces compact signed coefficient representations directly in memory.

  • 1) Hardware Root of Trust via DRAM Entropy:: YAVIN derives its root of trust from physical randomness inherent in DRAM cells, without software-provisioned or processor-transmitted secrets.The mechanism is inspired by QUAC-TRNG.
  • 2) Seed Expansion via Parallel SHAKE-128:: CBD10 sampling consumes 10 bits per coefficient, requiring 5,120 random bits for a 2^1 vector of 256-coefficient polynomials.These bits are generated from SHAKE-128 output.
  • 2) Seed Expansion via Parallel SHAKE-128:: SHAKE-128 expands a short seed into an arbitrarily long pseudorandom stream using the Keccak-f[1600] permutation.Its internal state contains 1600 bits organized as 25 lanes of 64 bits.
  • 2) Seed Expansion via Parallel SHAKE-128:: Each 1600-bit Keccak state is stored across 25 DRAM rows, with each lane position mapped to a row index based on its grid coordinates.Per-lane Keccak operations become operations on individual DRAM rows, while lane-axis operations become horizontal movement within a row.
  • 2) Seed Expansion via Parallel SHAKE-128:: The CBD10 computation uses parallel POPCOUNT5 operations on two five-row groups, subtracts the resulting counts, and emits four output bits including a sign bit.The algorithm expresses the operations with majority, XOR, and AND primitives.

25 DRAM Rows · 3) Secret Sampling via Centered Binomial Distribution:

YAVIN maps Keccak’s 5×5×64 state onto 25 DRAM rows and implements its permutation through row-parallel operations, then uses partitioned SHAKE-128 outputs to generate CBD10 samples in parallel.

  • 25 DRAM Rows: The 5×5×64 Keccak state is organized as 25 DRAM rows for PIM execution.The mapping is depicted as a cube-to-row transformation.
  • 25 DRAM Rows: Keccak’s θ step computes column parities and XORs diffusion terms across all five lanes of each column.Each column’s 64-bit parity contributes to a horizontally rotated diffusion term.
  • 25 DRAM Rows: The ρ step rotates each of 25 lanes by a fixed row-specific offset ranging from 0 to 63 bits.Lane rotations use masking and horizontal shift operations, and each permutation contains five steps.
  • 25 DRAM Rows: The π step reorders rows logically without data movement, while χ updates rows using the next two lanes within each plane.These operations preserve the row-oriented PIM layout while applying Keccak’s lane transformations.
  • 25 DRAM Rows: After 24 Keccak permutation rounds, four output blocks are partitioned to supply the centered binomial sampler.The output partitioning provides the sampler’s input material.
  • 3) Secret Sampling via Centered Binomial Distribution:: CBD10 consumes 10 input bits per coefficient and uses three stages of column-parallel computation to produce 256 outputs simultaneously.Four parallel SHAKE-128 outputs are grouped into a1–a5 and b1–b5 across 256 column groups, with unneeded rows discarded.
  • 3) Secret Sampling via Centered Binomial Distribution:: POPCOUNT5 sums five input bits into a 3-bit count, with parallel-reduction logic tuned to minimize PIM operations.The sampler computes X = Sa − Sb through Sa + Sb + 1 and executes CBD10 twice to produce the vector s.

4) Polynomial multiply:

YAVIN implements LightSaber’s polynomial multiplication in DRAM-PIM by combining CPU-precomputed coefficient weights with bit-serial multiply-accumulate, shift-based negacyclic reduction, and rounding. This partitioning keeps secret-polynomial processing in memory while producing the rounded public-key component.

  • Polynomial multiplication: LightSaber’s matrix–vector product requires four polynomial multiplications over Rq = Zq[X]/(X^256 + 1), with q = 8192 and n = 256.Each multiplication combines a public polynomial with 256 coefficients and a secret polynomial whose coefficients lie in [-5, +5].
  • CPU–PIM partitioning: The CPU precomputes four 13-bit coefficient-weight rows for each public-polynomial coefficient and stores them in DRAM.The rows are C0 = x, C1 = 2x mod q, C2 = 4x mod q, and C3 = (q − 8x) mod q.
  • Bit-serial multiply-accumulate: PIM uses row-wide AND operations to select weights for the secret coefficient’s magnitude bits, then accumulates partial products with bit-serial 13-bit addition via MAJ gates.The sign bit is handled separately using the sign-corrected weight C3.
  • Negacyclic reduction via shift-and-accumulate: For each public-polynomial coefficient, PIM shifts the secret polynomial across a 512-column workspace, placing wrapped terms in the negative half for negacyclic reduction.Because X^256 = −1, products at degree 256 or greater are subtracted from the corresponding lower-degree positions.
  • Rounding: The resulting 13-bit product is rounded by adding 4, right-shifting by 3, and reducing modulo p = 1024 = 2^10 to produce b.Logical reindexing discards the three least-significant rows and retains the ten most-significant rows.

B. PIM Ascon-AEAD design

After LightSaber establishes the shared ASCON key, ASCON-AEAD protects all subsequent data crossing the untrusted bus within the unified TEE. Its permutation relies only on bitwise XOR, AND, NOT, and horizontal rotation.

  • ASCON-AEAD protection: ASCON-AEAD protects all subsequent data crossing the untrusted bus after the shared ASCON key is established by LightSaber.This protection applies across the unified TEE.
  • ASCON-AEAD protection: The shared ASCON key is established by LightSaber before subsequent data protection begins.
  • ASCON permutation: ASCON’s permutation uses only bitwise XOR, AND, NOT, and horizontal rotation, like the Keccak primitives described earlier.

1) State layout: · 2) Permutation implementation: · 3) AEAD operation flow:

YAVIN maps the 320-bit Ascon-128 state across five DRAM rows and implements its permutation and AEAD flow directly through PIM operations. The design uses full 12-round permutations for initialization and finalization, cheaper 6-round permutations during data processing, and supports the 128-bit-rate Ascon-128a variant.

  • 1) State layout:: The 320-bit Ascon-128 state comprises five 64-bit words, with each word mapped to one DRAM row in a five-row state block.The words are x0, x1, x2, x3, and x4.
  • 1) State layout:: The state stores the 128-bit session key in x1 and x2 and a 128-bit nonce in x3 and x4, while eight parallel AEAD instances share each row’s session key.The initialization vector specifies k = 128, r = 64, a = 12, and b = 6.
  • 2) Permutation implementation:: Each permutation round executes constant addition, Boolean S-box substitution, and linear diffusion as three sequential PIM layers.The Boolean S-box avoids lookup tables, while diffusion combines each word with two rotated copies.
  • 3) AEAD operation flow:: The AEAD procedure has four phases, using the full 12-round permutation p12 for initialization and finalization and the 6-round permutation p6 between data blocks.Initialization applies p12 to the initial state and reinjects the key through x3 and x4.
  • 3) AEAD operation flow:: Associated data is absorbed in 64-bit blocks through x0, with p6 after each block and a domain-separation bit applied after the final block.Padding completes the final block with one 1 bit followed by zeros; absent associated data skips absorption.
  • 3) AEAD operation flow:: Plaintext encryption XORs each 64-bit block with x0 to produce ciphertext, absorbs the plaintext into x0, and applies p6 before the next block.The last block is padded and is not followed by a permutation.
  • 3) AEAD operation flow:: Ascon-128a doubles the rate to 128 bits using x0 and x1, applies p8 between blocks, and increases permutations by 33% while retaining 128-bit cryptographic strength.Its capacity is reduced to 192 bits across x2, x3, and x4.
  • 3) AEAD operation flow:: Finalization reinjects the key before and after p12, extracts a 128-bit tag from x3 and x4, and detects tampering when tag recomputation mismatches.The first key injection uses x1 and x2; the second uses x3 and x4.

4) Parallelism and nonce management: · C. Threat Model

YAVIN parallelizes ASCON across DRAM rows while enforcing nonce uniqueness through instance identifiers and a shared CPU-maintained counter. Its threat model trusts processor and DRAM components but treats the memory bus and controller as adversarial, allowing only ciphertext traversal.

  • 4) Parallelism and nonce management:: 8ˆ increase in parallelism comes from packing eight independent 64-bit ASCON instances into a 512-bit memory row.The eight instances share one session key K.
  • 4) Parallelism and nonce management:: Nonce uniqueness is enforced by partitioning the 128-bit nonce into an instance-identifier field and a shared block counter.The instance identifier distinguishes the eight parallel ASCON instances, while the CPU maintains the shared counter.
  • 4) Parallelism and nonce management:: The instance identifier prevents nonce collisions among the eight ASCON instances sharing session key K.This organization separates each instance’s nonce space while retaining a common session key.
  • C. Threat Model: YAVIN trusts the processor and DRAM, including trusted-execution logic, isolated tenant regions, and secrets confined within them.These assumptions define the trusted components of YAVIN’s execution environment.
  • C. Threat Model: The memory bus and controller are untrusted, so co-resident tenants, compromised OS or hypervisor software, and physical attackers may observe, inject, or replay bus traffic.The threat model explicitly includes active manipulation of messages traversing the bus.
  • C. Threat Model: Only ciphertext traverses the bus, while LightSaber’s IND-CCA security protects confidentiality during the one-time key exchange.YAVIN additionally assumes a PUF-derived hardware root of trust and manufacturing-time device identity for authenticating the initial public-key exchange.
  • C. Threat Model: Physical side-channel attacks, cold-boot attacks, and denial-of-service attacks are outside YAVIN’s scope under its standard TEE assumptions.These attack classes are explicitly excluded from the threat model.

IV. EXPERIMENTAL EVALUATION … C. PIM ASCON v.s PIM AES

YAVIN’s evaluation measures cryptographic setup, PIM ASCON efficiency, space overhead, scalability, and application performance. It reports compact per-tenant state, measurable LightSaber setup costs, and substantial ASCON-128 advantages over PIM AES.

  • IV. EXPERIMENTAL EVALUATION: YAVIN evaluates LightSaber key establishment, PIM ASCON throughput, latency and energy, multi-tenant scalability, and end-to-end workload performance.The evaluation spans both cryptographic components and application-level behavior.
  • IV. EXPERIMENTAL EVALUATION: Experiments use NVMain-PIM with DDR3-1333 and DDR4-2400 timing parameters, generally executing workloads within a single DRAM bank.Processor-side measurements use a dual-core ARM Cortex-A72 at 1.2 GHz.
  • A. YAVIN’s space overhead: 9,280 bytes (≈9.1 KiB) of protected state are reserved per tenant per subarray for LightSaber and ASCON cryptographic regions.The LightSaber region can be freed after the one-time key exchange, making this a conservative upper bound.
  • A. YAVIN’s space overhead: 120 rows support LightSaber’s PIM key-generation and decapsulation workspace, using all 512 columns for polynomial multiplication.The region stores the PUF-derived root of trust, secret vector, and intermediate polynomial multiplication result.
  • B. Lightsaber KEM: Latency, and Energy: 429 ms and 60.4 mJ are required for LightSaber key generation, with the matrix–vector product accounting for 391 ms and 55.0 mJ.Key generation can execute offline because it is randomized and independent.
  • B. Lightsaber KEM: Latency, and Energy: 670.2 ms and 93.9 mJ are required for LightSaber decapsulation, whose dominant cost is FO-transform re-encryption at 390.9 ms.Decapsulation is critical-path because it provides CCA security.
  • C. PIM ASCON v.s PIM AES: 20.4× latency speedup and 19.2× energy reduction are achieved by PIM ASCON-128 over AES-128 at 1 Mb on DDR4-2400.At 64 b, the corresponding figures are 8.2× latency speedup and 7.7× energy reduction; ASCON-128a reaches 28.8× energy reduction at 1 Mb.
  • C. PIM ASCON v.s PIM AES: ASCON’s advantage remains consistent across DDR3-1333 and DDR4-2400, indicating suitability for PIM rather than dependence on memory configuration.ASCON-128a further benefits from its doubled rate at large data sizes.

D. FHE v.s YAVIN · E. Application Performance: LLM Inference · V. CONCLUSION

YAVIN extends trusted execution into processing-in-memory while treating the memory bus as untrusted, enabling protected-data computation with lightweight cryptography. Across FHE comparisons and LLM inference, it achieves major speedups and practical overheads while preserving PIM performance.

  • D. FHE v.s YAVIN: YAVIN targets protected computation across an untrusted memory bus, addressing multi-tenant confidentiality where processor-centric TEEs have limited computing resources.FHE is identified as the only prior approach offering comparable confidentiality in multi-tenant systems.
  • D. FHE v.s YAVIN: „5ˆ104 speedup at INT8 over CPU FHE makes previously impractical edge inference complete in seconds.YAVIN keeps plaintext inside trusted memory and uses lightweight symmetric encryption, avoiding ciphertext expansion and refresh costs.
  • E. Application Performance: LLM Inference: YAVIN evaluates seven language models spanning 4B to 70B parameters under INT8 and INT32 quantization.The evaluated models include GPT-J-6B, GPT-OSS-20B, LLaMA-3.1-8B, LLaMA-3.3-70B, LLaMA-4-Scout, Mixtral-8x7B, and Qwen3-VL-4B.
  • E. Application Performance: LLM Inference: YAVIN computes GEMM layers in PIM and non-GEMM layers such as ReLU and Softmax on the processor, decrypting and re-encrypting data across that boundary.Overhead is measured against the unencrypted SIMDRAM PIM GEMM latency and includes PIM crypto, processor crypto, and bit-serial/bit-parallel roundtrip costs.
  • E. Application Performance: LLM Inference: „97% of the total additional cost comes from PIM-side cryptography; overhead ranges from 14% to 556% at INT8 and 4.3%–154% at INT32.Higher GEMM proportions amortize fixed PIM encryption costs, while increasing precision lowers overhead because compute scales faster than encryption.
  • V. CONCLUSION: YAVIN unifies trusted processor and memory execution while treating the memory bus as untrusted.Its design combines post-quantum key establishment with lightweight authenticated encryption co-designed for DRAM-PIM execution.
  • V. CONCLUSION: Data can be decrypted, processed, and re-encrypted entirely within trusted processor or memory regions without exposing plaintext on the memory bus.The evaluation reports practical overheads while preserving PIM’s performance advantages, supporting secure multi-tenant PIM for edge computing.
Loading 2608.13496v1…