Bus Encryption

Data is encrypted using the AES-XTS tweakable block cipher mode as it traverses the memory bus. The encryption engine sits directly in the memory controller path, operating at line speed with minimal latency overhead. Each memory block is encrypted with a unique tweak derived from its physical address, ensuring that identical plaintext stored at different locations produces distinct ciphertext. This prevents attackers from correlating memory contents even if they capture raw bus traffic.

A fresh, random Data Encryption Key (DEK) is generated by a hardware random number generator inside the processor at every cold boot. This key never leaves the chip's secure boundary and is stored in on-die SRAM that is zeroized on tamper detection. Because the key is ephemeral, an attacker who physically extracts a memory chip between boots cannot decrypt previously captured bus traces. The DEK is wrapped by a device-unique Key Encryption Key (KEK) derived from a Physically Unclonable Function (PUF) for secure storage across suspend/resume cycles.

Beyond data encryption, the physical address bus is obfuscated using a cryptographic permutation to prevent attackers from inferring data structures by observing access patterns. The scrambling function maps logical addresses to randomized physical locations using a secret seed derived from the boot key. This defeats address-based side-channel attacks where an adversary monitors the bus to identify which memory regions contain model weights versus input buffers. The permutation is computed in a single cycle to avoid adding latency.

Each encrypted cache line is accompanied by a Message Authentication Code (MAC) tag stored in a reserved region of memory. On every read, the memory controller recomputes the MAC and compares it against the stored tag. A mismatch indicates a tampering attempt—such as a physical attacker replacing ciphertext with malicious data to induce misclassification. The system can be configured to raise a security exception, trigger zeroization, or halt execution upon integrity failure. This provides both confidentiality and authenticity guarantees.

The bus encryption engine incorporates masking and hiding countermeasures to prevent Differential Power Analysis (DPA) attacks. Internal operations use randomized secret shares so that the instantaneous power consumption of the encryption datapath is statistically independent of the key material and plaintext. Additionally, the engine employs a constant-time implementation where all cryptographic operations take identical clock cycles regardless of data values, eliminating timing side-channels that could leak information about the model weights being transferred.

Bus encryption operates as a foundational layer within a broader Trusted Execution Environment (TEE) architecture. The memory encryption engine is configured by secure firmware running in a privileged mode inaccessible to the rich OS or application code. This ensures that even a compromised kernel cannot disable encryption or extract the DEK. The TEE uses remote attestation to prove to a provisioning server that bus encryption is active before releasing sensitive model weights, creating a hardware-rooted chain of trust from silicon to application.

A hardware-enforced secure area within the main processor that isolates sensitive computation from the host OS. TEEs decrypt data only inside the CPU package, ensuring plaintext never appears on the external memory bus. This is the foundational hardware primitive that makes bus encryption meaningful—without a TEE, keys used for bus encryption could be extracted from a compromised OS.

• Intel SGX, AMD SEV, Arm TrustZone are common implementations
• Provides confidential computing guarantees even against a compromised kernel
• Measured in Enclave Page Cache (EPC) size, typically 64MB–512MB

Bus encryption protects data in transit, but attackers can still observe physical side effects of computation—timing, power draw, or electromagnetic emanations—to infer secret values. Mitigations include constant-time programming, power trace flattening, and shielding.

• Differential Power Analysis (DPA) correlates power consumption with data values
• Electromagnetic (EM) probing can capture signals from the memory bus even with encryption
• Countermeasures: clock jitter, random noise injection, balanced logic gates

Even with encrypted data on the bus, an attacker monitoring address patterns can infer model architecture—which layers are active, tensor sizes, and execution sequence. Memory access obfuscation randomizes the pattern of reads and writes to hide the true data flow.

• Oblivious RAM (ORAM) protocols hide access patterns at algorithmic cost
• Simpler approaches: dummy accesses, address scrambling, cache-line shuffling
• Critical for protecting model graph topology from bus snooping

An active defense mechanism that immediately and irrevocably erases cryptographic keys, model weights, and sensitive data from memory upon detecting a physical tampering event. When bus encryption is compromised by a probe, zeroization ensures the attacker gets nothing.

• Triggered by: case intrusion switches, voltage anomalies, temperature excursions
• Must complete faster than an attacker can freeze memory (cold-boot attack window)
• Often paired with anti-tamper meshes on the PCB or chip package

A hardware security primitive that derives a unique, device-specific cryptographic key from microscopic manufacturing variations in silicon. PUFs generate the key used for bus encryption on-demand, so the key never exists in non-volatile storage where it could be extracted.

• SRAM PUF: uses power-up state of SRAM cells as a fingerprint
• Ring oscillator PUF: measures frequency variations between identical circuits
• Binds bus encryption keys to that specific physical chip—cloning is impossible

A cryptographic protocol that allows a remote server to verify the integrity and trusted state of an edge device before provisioning decryption keys or model weights. This ensures bus encryption is active and the TEE is genuine before any sensitive data is sent.

• Produces a signed measurement (quote) of the device's software and hardware state
• Verifies against a known-good hash stored in the manufacturer's attestation service
• Prevents man-in-the-middle provisioning attacks where a fake device requests model weights