Avoiding Leaks When Handling Native Memory and Secrets
Handling sensitive data—encryption keys, passwords, tokens—has always been a delicate challenge in Java. Traditionally, you store them in Java heap memory as String or char[]. But this leaves secrets vulnerable:
- They can be inadvertently serialized or logged.
- The JVM can move or copy data during garbage collection, leaving stale copies.
- Memory contents may remain in RAM long after use.
Starting with JDK 17, the Foreign Function & Memory API (JEP 412) (incubated) and the Foreign Memory Access API (JEP 393) (preview) paved the way to safer, explicit memory management in Java. As of JEP 411, the legacy sun.misc.Unsafe API has been deprecated, making this modern approach the preferred method for off-heap memory access.
This article shows how you can use JEP 411 to reduce the risk of sensitive data leaks by:
- Allocating memory outside the Java heap
- Controlling the lifecycle of native memory
- Zeroing out memory explicitly
- Minimizing accidental exposure
1. Why Native Memory Helps Secure Secrets
By default, Java keeps all objects (including secrets) in the heap. Even if you overwrite a char[] or call Arrays.fill(), you can’t guarantee there aren’t stale copies in GC-managed memory.
Native memory allows you to:
✅ Avoid automatic copying or relocation
✅ Manually erase contents after use
✅ Keep secrets out of heap dumps
This pattern is commonly used in cryptography libraries (like libsodium) or when integrating with C APIs handling sensitive material.
2. Introducing the Foreign Function & Memory API
JEP 411 deprecates sun.misc.Unsafe and proposes the modern Foreign Function & Memory API, which provides:
- MemorySegment: A view over a region of memory (on- or off-heap)
- MemorySession: A scope to control memory lifecycle and safety
- MemoryAccess: Utilities to read/write primitive data
- Linker / SymbolLookup: For calling native libraries safely
In this article, we’ll focus on MemorySegment and MemorySession for secure memory management.
3. Example: Storing and Zeroing a Secret in Native Memory
Here’s a step-by-step example of storing a secret encryption key securely.
1. Allocate Off-Heap Memory
import java.lang.foreign.*;
import java.nio.charset.StandardCharsets;
public class SecureMemoryExample {
public static void main(String[] args) {
try (MemorySession session = MemorySession.openConfined()) {
// Allocate 32 bytes (e.g., a 256-bit key)
MemorySegment secretSegment = MemorySegment.allocateNative(32, session);
// Example: Write secret bytes into memory
byte[] secretKey = "my-super-secret-key-12345678".getBytes(StandardCharsets.UTF_8);
secretSegment.asByteBuffer().put(secretKey);
// ... use the secret key (e.g., call native crypto function)
// Zero out the memory before releasing
secretSegment.fill((byte) 0);
}
// Memory is now released and cannot be accessed
}
}
How this helps:
- Memory is not on the Java heap.
MemorySessionensures memory is released automatically.- You explicitly fill with zeros before the segment goes out of scope.
- After
session.close(), access attempts will throw an error.
4. Example: Allocating Memory Without a Session
If you want more manual control, use an arena or manage segments yourself:
MemorySegment segment = MemorySegment.allocateNative(32);
try {
segment.asByteBuffer().put("password123456789".getBytes(StandardCharsets.UTF_8));
// Do sensitive work
} finally {
segment.fill((byte) 0);
segment.close();
}
Note that you must always call close() yourself.
5. Avoiding Common Pitfalls
- Always zero out the memory before releasing it.
If you simply close withoutfill(0), sensitive bytes remain in RAM. - Never leak references to native memory.
Don’t storeMemorySegmentin global state longer than necessary. - Watch for copying:
If you convert to aStringor heapByteBuffer, you’ve lost control. - Beware of logs and debugging tools:
Don’t log the contents of your segments.
6. Comparing With sun.misc.Unsafe
Previously, developers used Unsafe:
Unsafe unsafe = ...;
long address = unsafe.allocateMemory(32);
try {
unsafe.copyMemory(...);
// Use memory
} finally {
unsafe.setMemory(address, 32, (byte) 0);
unsafe.freeMemory(address);
}
While powerful, Unsafe is error-prone, not standardized, and harder to reason about.
JEP 411 encourages you to migrate to MemorySegment and MemorySession instead.
7. Using Foreign Memory With Native Libraries
Another benefit of MemorySegment is passing native pointers to C functions safely:
Linker linker = Linker.nativeLinker();
SymbolLookup lookup = linker.defaultLookup();
MemorySegment key = MemorySegment.allocateNative(32);
key.asByteBuffer().put(secretBytes);
// e.g., pass to native function
FunctionDescriptor fd = FunctionDescriptor.ofVoid(ValueLayout.ADDRESS);
MethodHandle handle = linker.downcallHandle(lookup.find("some_crypto_function").get(), fd);
handle.invoke(key);
This approach avoids unnecessary heap copies while providing memory safety checks.
8. Best Practices for Handling Secrets in Native Memory
✅ Use confined MemorySession so the lifetime is clearly scoped.
✅ Zero memory with fill(0) before release.
✅ Avoid heap intermediaries (String, ByteBuffer.wrap).
✅ Release memory as soon as possible.
✅ Never log or print memory contents.
9. Conclusion
JEP 411 and the Foreign Function & Memory API give Java developers powerful, safer tools to handle sensitive data securely:
- No more reliance on
Unsafe - Full lifecycle control
- Fewer accidental leaks
If your application manages secrets, keys, or credentials, consider adopting native memory with explicit zeroing and confined lifetimes. This is the new, modern approach to securing sensitive data in the JVM.
