Protecting sensitive data does not stop at the boundaries of the processor or a single-chip system. When instructions and data move to external memory such as DRAM, the memory interface becomes part of the attack surface, particularly in space and government systems that may operate in contested environments and remain in service for decades. A technical article published in Semiconductor Engineering, written by Vincent van der Leest and Ajay Kapoor of Rambus, presents an approach to protecting this interface that goes beyond encrypting content to verifying that it has not been altered.
The article was published as a Sponsor Blog on September 3, 2026, so Rambus’s product presentation should be treated as a commercial example of the proposed approach, not as independent evidence of its superiority. The core technical principle is broader than the product itself: external memory needs confidentiality, authentication, and tamper resistance, along with key-lifecycle management.
Encryption Conceals Data but Does Not Prove Its Integrity
Inline Memory Encryption, or embedded memory encryption, encrypts data before it is written to memory connected outside the system-on-chip, then decrypts it when it returns for use. This is usually performed by an encryption engine placed between the processing logic and the memory controller, allowing transparent protection for software while preserving performance and latency requirements.
But data confidentiality is not synonymous with integrity. An attacker may not need to read cryptographic material, sensor data, or executable instructions if they can modify a value associated with a command, coordinates, or a lookup table. The same risk applies to medical and financial data, as well as inputs to or parameters of artificial-intelligence models, where modification could lead to untrustworthy decisions or outputs.
For this reason, the article proposes performing authentication as close to the storage location as possible, before delivering data to the processor, accelerators, or control logic. Reducing the distance traveled by unauthenticated data limits the possibility that corrupted data will spread within the system.
Choosing an AES Mode Depends on Requirements, Not the Algorithm’s Name
AES-XTS is widely used to encrypt storage devices and high-throughput memory. This mode relies on a value associated with the data address, so identical content does not produce identical ciphertext when stored at different addresses, without adding size to the protected data. However, AES-XTS provides confidentiality only and is not an authenticated-encryption mode that combines confidentiality with integrity verification.
By contrast, AES-GCM combines encryption with integrity verification through an authentication tag that is checked before the plaintext is made available. This enables the detection of deliberate modification, but requires authentication tags and nonces or initialization vectors to be stored and managed. This may affect memory capacity, bandwidth, address mapping, caching mechanisms, and the initialization phase.
In practice, the decision should not be limited to the strength of the algorithm. An engineer must balance the threat model, the required assurance level, the acceptable memory overhead, performance objectives, and the architecture of the system as a whole. In sensitive systems, the ability to detect modification may justify the additional cost of metadata and design complexity.
Side-Channel Resistance Is Part of the Design
Even mathematically sound algorithms are insufficient if their implementation exposes their keys through physical leakage. The article notes that analysis of power consumption, electromagnetic radiation, or timing may help an attacker with physical access to equipment infer the keys without breaking AES itself.
Therefore, side-channel countermeasures should be designed into the encryption engine, rather than added later only at the system level. The assurance elements mentioned in the article include secure key handling, predictable behavior under faults, protection of control paths, and the ability to tolerate random faults. It also argues that relying on a field-proven solution and practical expertise in countering tampering may reduce implementation risks and the burden of establishing confidence in the design, particularly in space and government programs.
What Must Be Resolved at the Platform Level?
The article explains that adding an encryption engine to the memory path does not solve every protection problem. The system-design and encryption-engine teams need to address interconnected issues, most notably:
- Data freshness: Verifying the validity of an old value does not prevent it from being replayed. This may require protected counters, version information, or synchronized state, with consequences for metadata, persistence, and recovery.
- Memory initialization: Protected regions may need valid metadata before normal startup begins, while initializing large memories may affect boot time and system availability.
- Root-of-trust integration: Key provisioning, security policies, transitions between lifecycle stages, key erasure, and recovery mechanisms must align with a chain of trust that begins with secure boot and extends to memory protection during operation.
Rambus states that its IME-IP-340 product, designed for FPGA applications, uses AES-GCM to encrypt, decrypt, and authenticate memory transactions, with support for configurable memory management, caching, key management, and options for resisting power-analysis attacks. According to the company’s presentation, these capabilities are intended to help designers balance security, performance, metadata cost, and integration requirements.
Editorial Reading: Boundaries Matter More Than the Encryption Engine
The actual shift emphasized by the article is moving memory protection from the concept of “hiding content” to a broader concept that includes detecting modification and resisting key-extraction techniques. This matters for systems that rely on external data to make decisions or execute commands, because data integrity is no less important than confidentiality.
Nevertheless, the source alone does not establish IME-IP-340’s performance in specific operating environments, nor does it provide detailed figures on latency, metadata size, or the results of independent tests. Authenticated encryption also does not eliminate the need to design replay-prevention, initialization, and lifecycle-management mechanisms. Any solution must therefore be evaluated within the platform’s complete architecture and its specific threat model, rather than regarded as a standalone component that automatically guarantees memory security.