By Vincent van der Leest and Ajay Kapoor Security architects devote considerable attention to trusted processing, secure boot, and protected communications. Yet sensitive instructions and data often leave the system-on-chip (SoC) whenever they are written to external (off-chip) memory. That interface can expose mission-critical data like cryptographic material, sensor feeds, executable code, and intermediate processing results to physical probing or modification. For aerospace and government platforms, where systems may operate in contested environments and remain deployed for decades, the memory interface must be treated as part of the attack surface. Inline Memory Encryption (IME) addresses this threat by encrypting data just before it is written to attached off-chip memory and decrypting when it returns for use. This is normally done by placing cryptographic processing directly in the path between processor logic and the memory controller. Because the operation is inline, protection can be transparent to software while keeping pace with the throughput and latency requirements of modern memory systems. Confidentiality is only half of the requirement Encryption prevents an attacker from understanding the data observed on a memory bus or recovered from an external DRAM device. It does not necessarily prove that the data has not been altered. This distinction is critical. A hostile actor may not need to read mission data if blindly changing data associated with a command, coordinate, lookup table, or executable instruction is enough to influence system behavior. The same principle applies beyond aerospace and government systems: manipulated medical or financial data can affect critical decisions, while altered training data, model parameters, or inference inputs can poison an AI system. Confidentiality prevents disclosure and complicates specific edits; authentication determines whether the data can still be trusted. Authentication should therefore occur as close as possible to where data is stored and before that data is consumed. This minimizes the path over which unauthenticated information can travel and helps prevent corrupted data from propagating into processors, accelerators, or downstream control logic. IME should be viewed not only as a confidentiality feature, but as an important contributor to overall system integrity and robustness. Different AES operation modes for IME AES-XTS is widely used for high-throughput storage and memory encryption. Its location-dependent tweak ensures that identical plaintext blocks stored at different addresses produce different ciphertext without increasing the protected data size. However, AES-XTS can protect the data confidentiality only and is not a type of Authenticated Encryption with Associated Data (AEAD), i.e. one that ensures both the confidentiality and authentication of memory contents. AES-GCM combines confidentiality with integrity verification, allowing an authentication tag to be checked before plaintext is released. This provides protection against deliberate tampering. However, it requires storage and management of authentication tags and nonces or initialization vectors, which can affect memory capacity, bandwidth, address mapping, caching, and initialization. The decision is therefore not simply a comparison of cipher strength. Architects must align the mode with the threat model, assurance objective, acceptable memory overhead, performance target, and wider system architecture. For many mission-critical systems, the ability to cryptographically detect modification justifies the additional metadata and design complexity of authenticated encryption. Cryptographic strength requires implementation resilience Secure algorithms still require resilient implementations. Power, electromagnetic, timing, and other physical leakage can enable side-channel analysis to recover secret keys without breaking AES mathematically, especially when adversaries have physical access to equipment. Side-channel countermeasures should be designed into the cipher implementation rather than treated as a later system-level add-on. Secure key handling, predictable error behavior, protected control paths, and robustness against random faults also contribute to the effective assurance of the complete engine. For aerospace and government programs, a field-proven solution and a supplier with practical anti-tamper experience can reduce both implementation risk and the burden of establishing confidence in the design. Meeting requirements for secure off-chip memory The Rambus
IME-IP-340 addresses these requirements with authenticated memory protection, high performance, secure key handling, and field-proven side-channel resistance. Designed for FPGA deployments, it sits between processor logic and the memory controller, using AES-GCM to encrypt, decrypt, and authenticate memory transactions with high throughput and low latency.
Fig. 1: Block diagram of Rambus IME-IP-340. The engine includes configurable memory management, cache support, native key management, and optional power-analysis side-channel attack (“SCA”) countermeasures. These capabilities help designers balance security, performance, memory overhead, and integration requirements while maintaining a dedicated security boundary in the memory path. Extending protection across the system lifecycle There are additional system-level challenges that must be looked at together between system- and IME design teams for a successful IME solution:
- Data freshness: Preventing replay of older, correctly authenticated values may require protected counters, version information, or synchronized state, with implications for metadata, persistence, and recovery.
- Memory initialization: Protected regions may need valid metadata before normal operation, and initializing large memories can affect boot time and system availability.
- Root of Trust integration: Secure key provisioning, security policy, lifecycle transitions, zeroization, and recovery should form part of a coherent chain of trust from secure boot through runtime memory protection.
Beyond providing the cryptographic engine, Rambus helps customers address freshness, initialization, key provisioning, and Root of Trust integration. This system-level support helps balance assurance, performance, boot time, memory, and lifecycle requirements across the wider platform security architecture. Building trust beyond the chip boundary Protecting off-chip memory in mission-critical systems requires more than hiding its contents. Data must remain confidential, unauthorized modifications must be detected before corrupted information is used, and the implementation itself must remain resilient against relevant physical attacks. More broadly, memory protection illustrates an important architectural principle: security cannot stop at the boundary of a trusted processing component. When sensitive information leaves that boundary, the system must determine what protections are required along the path and before the information is consumed. Confidentiality, integrity, authentication, key management, and lifecycle security therefore need to be considered as elements of the broader system security architecture. Authenticated, side-channel-resistant IME applies that principle to a particularly important boundary: the path between processing and external memory and is an important building block for resilient aerospace and government architectures. Links
Ajay Kapoor is senior principal engineer systems architect for Rambus Security IP. He is lead architect and product manager for the Inline Memory Encryption IP product portfolio. He holds more than 25 patents, and his work has been included in more than 15 scientific publications. Kapoor holds a MSc from Twente University and a BTech Electrical Engineering from the Indian Institute of Technology (IIT). The post
Protecting Mission-Critical Data Beyond The SoC: Why Inline Memory Encryption Needs Integrity appeared first on
Semiconductor Engineering.
Source:
https://semiengineering.com/protecting- ... integrity/