In our demonstration on an AMD Versal AI Edge development board, Linux boots and runs entirely in a gigabyte of memory that StealthMem, the memory encryption IP from StealthCores, encrypts and authenticates on its way to DDR. Anyone probing the memory bus or reading the memory chips sees only ciphertext, whether the data is an AI model, a credential or proprietary code. StealthMem runs on AMD, Microchip and Altera FPGAs and in ASICs. This demonstration uses AMD Versal.
Where StealthMem Sits on Versal
StealthMem is in the programmable logic, attached to the Versal network-on-chip just after the processor's L2 cache. Anything the caches hold runs at full speed. When data goes out to DDR, StealthMem encrypts each block with AES-256-GCM under a fresh nonce and stores it with an authentication tag. When it comes back, StealthMem decrypts and checks it before the processor sees it.
Memory is divided into key regions, and every span within a region gets its own working key, derived in hardware. On the board, 4,096 working keys cover the 1 GiB, each guarding 256 KiB. Linux 6.12 boots into the encrypted memory and runs its applications there unchanged. StealthMem needs no Linux driver.
What We Showed on the Board
Real captureA program puts the StealthCores logo in memory. The processor reads it back intact; the same memory, read straight from DDR, is ciphertext.
Real captureThe same board built without StealthMem: read directly from DDR, the picture is there for anyone who can tap the memory bus or freeze the chips.
Real captureWe flipped a single bit of the picture's ciphertext in DDR. When the program read the picture back, that block failed authentication. StealthMem flagged the error and didn't pass the modified data to the program.
Real captureEvery line leaving the L2 while a program starts up, by kind of memory (instructions, stack, heap, kernel), and the working keys they use.
Address Scrambling
Real captureStealthMem can also scramble where each block lands, region by region. We traced the same 32 MiB copy twice on one bitstream. With scrambling off, the blocks follow the processor's order into DDR: 19.6% of writes land right next to the one before. With it on, none do (0.0%). The blocks are spread across all of DDR, so the memory bus no longer shows how your software uses memory.
Protection Against Physical Memory Attacks
Everything Linux keeps in memory crosses the bus encrypted. A bus probe or interposer sees only ciphertext, and so does anyone who freezes the memory chips to read them later. If a bit is changed, or a block is moved to another address, that block fails authentication and the program doesn't receive it.
StealthMem also defends against side-channel attacks. Advanced protocol countermeasures are combined with leakage-reduction countermeasures built on the foundation of StealthAES, and StealthMem is tested to one billion traces with TVLA.
Performance
| Workload | Plain DDR | FPGA path alone | StealthMem AES-GCM | StealthMem XTS |
|---|---|---|---|---|
| In the caches | ||||
| FFT, 4K points MFLOPS | 1,859 | 1,831 (98 %) | 1,842 (99 %) | 1,832 (99 %) |
| gzip compression MB/s | 4.46 | 4.42 (99 %) | 4.29 (96 %) | 4.30 (96 %) |
| OpenSSL AES-256-GCM MB/s | 651 | 648 (100 %) | 643 (99 %) | 645 (99 %) |
| Applications | ||||
| 7-Zip decompression MIPS | 2,051 | 2,002 (98 %) | 1,652 (81 %) | 1,742 (85 %) |
| 7-Zip compression MIPS | 1,621 | 1,415 (87 %) | 506 (31 %) | 586 (36 %) |
| zstd compression MB/s | 28.9 | 21.1 (73 %) | 4.84 (17 %) | 5.86 (20 %) |
| xz compression MB/s | 0.933 | 0.772 (83 %) | 0.343 (37 %) | 0.398 (43 %) |
| Memory-bound | ||||
| FFT, 1M points MFLOPS | 722 | 581 (81 %) | 252 (35 %) | 270 (37 %) |
| FFT, 2048 × 2048 MFLOPS | 264 | 173 (66 %) | 54.1 (20 %) | 65.5 (25 %) |
| Memory streaming | ||||
| memcpy MiB/s | 3,809 | 2,242 (59 %) | 171 (4.5 %) | 196 (5.1 %) |
| STREAM read MB/s | 4,229 | 2,236 (53 %) | 191 (4.5 %) | 226 (5.3 %) |
| STREAM write MB/s | 2,819 | 1,491 (53 %) | 128 (4.5 %) | 150 (5.3 %) |
| Linux boot, to the login prompt | ||||
| Boot time s | 11.9 | 15.1 | 19.9 | 19.1 |
Measured on the AMD Versal AI Edge development board: Linux on the two Cortex-A72 cores, 1 GiB of memory in every case. Percentages in parentheses are relative to plain DDR. The FPGA path alone is the same programmable-logic route to DDR without encryption. StealthMem runs at 150 MHz with 4,096 working keys, as AES-GCM with countermeasures or as the XTS option without countermeasures. StealthMem's figures are the mean of three boots. Boot time varies by a few seconds from one boot to the next, so its boot times are the mean of six.
Code that runs mostly from the caches is almost unaffected. Memory-heavy programs slow down, and raw memory streaming slows the most.
The configuration we ran on the board, with countermeasures and 64-byte blocks, takes 70,734 LUTs, 66,126 flip-flops and 50 block RAMs (RAMB36) on the AMD Versal AI Edge VE2302 at the -2 speed grade, placed and routed out of context. Its maximum clock there is 245 MHz, and 185 MHz at the development board's -1 speed grade, where this demonstration runs it at 150 MHz. Other configurations are available.
StealthMem can be tuned for your system. Countermeasures add some area and cost a little speed. Authentication tags add 25% to memory use with 128-byte blocks and 50% with 64-byte blocks.
No Memory Overhead With XTS
If memory is tight, StealthMem can be ordered with XTS-AES-256 (IEEE Std 1619, NIST SP 800-38E) instead of AES-GCM. Each 64-byte block is stored in place as 64 bytes of ciphertext, with no nonce and no tag, so a region takes exactly its own size in memory. The board's gigabyte of encrypted memory would need 1 GiB of DDR with XTS, compared with 1.5 GiB using AES-GCM with 64-byte blocks.
XTS provides confidentiality only. With no authentication tags, StealthMem cannot detect a block that has been changed, moved or replayed in memory, and the XTS option is built without the side-channel countermeasures. If you need integrity, replay protection or side-channel resistance, use an AES-GCM configuration.
We ran the same Linux on the board with the XTS option, again with 4,096 working keys at 150 MHz. Its figures are in the last column of the table above. Compared with the AES-GCM build with countermeasures, memory-heavy work ran up to 21% faster, and code that runs from the caches ran at the same speed. Part of that gain comes from leaving out the countermeasures as well as the tags.
The XTS configuration we ran on the board takes 42,848 LUTs, 30,705 flip-flops and 29 block RAMs (RAMB36) on the AMD Versal AI Edge VE2302 at the -2 speed grade, placed and routed out of context, and reaches the same maximum clock as the AES-GCM build, 245 MHz at -2 and 185 MHz at -1. These figures are without countermeasures. The AES-GCM figures above include countermeasures.
Where the Keys Come From
Each region's keys can come from whichever source suits its memory. For non-volatile memory such as flash, fixed keys are stored and loaded in encrypted form, so the data stays readable across power cycles. For RAM, new keys can be generated at every start, either by your own key source or by StealthMem's optional on-chip key generator. The generator implements the NIST SP 800-90A CTR_DRBG with AES-256 and runs on StealthMem's own AES engines. Its algorithm is verified against NIST's test vectors, and it's seeded from a dedicated on-chip entropy source with SP 800-90B health tests. Whichever source you use, StealthMem derives every working key from the region's keys in hardware.
Find out how StealthMem can protect your next critical design. Contact us at info@stealthcores.com for details.