Where Should I Put My Keys?

Published on

Sep 18, 2026

You encrypted the data. You put the key in a vault. But to use that key, something, somewhere, has to turn it back into plaintext in memory. That “somewhere” is now a bigger attack surface than the cipher it protects, and the tools that find it are no longer scarce, expensive, or human. Especially when AI made every hiding place searchable.

Key custody is a hot potato

Three decades of public cryptanalysis have made AES, RSA and ECDSA astonishingly hard to break head-on. Almost nobody loses data because someone factored their modulus. They lose it because the key — the one secret the whole scheme depends on — had to become plaintext to do its job, and it did so in a place an attacker could reach.

Every key has a moment of use. In that moment it lives in ordinary memory: an application heap, a CPU register, a cache line, a DRAM cell, a crash dump, a build runner, a HSM’s firmware. We have spent enormous effort protecting keys at rest and in transit, and almost none protecting them in use. That gap is where the last decade of breaches actually happened.

The threat has walked steadily inward from cold RAM, to the live process, to the crypto hardware, to the CPU core, and in 2025, to the memory bus underneath confidential computing itself. Each step shortened the distance between “your key exists” and “I have your key.”

A decade of keys leaving the building

Read the following cases involving production systems, national governments, and the vault vendors themselves as an escalation of severity.

2008 · Cold boot

Princeton researchers showed DRAM retains its contents for seconds after power loss, long enough to chill a machine, reboot into a scraper, and lift disk-encryption keys out of memory. It’s just physics.

2014 · Heartbleed

A single OpenSSL bug lets a remote attacker read 64KB of process heap at a time. Cloudflare bet private keys couldn’t be pulled that way; but researchers extracted the server’s RSA private key within hours.

2019 · The vault itself

Ledger’s team chained memory-corruption bugs into unauthenticated remote code execution inside an HSM — the appliance whose entire purpose is that keys never leave — and it dumped every secret, as well as installed firmware that survived updates.

2022–2023 · The custody chain

At LastPass, attackers reached the keys guarding customer backups via an engineer’s device. At CircleCI, malware on one laptop led to encryption keys being dumped from a running process. The data was encrypted at rest, but it no longer mattered.

2023 · Storm-0558

A Microsoft signing key ended up in a crash dump it should never have touched, moved to a lower-trust environment, and was used to forge authentication tokens against ~25 organizations including U.S. federal agencies. The CSRB called the intrusion preventable.

2023–2024 · The CPU turns on you

AMD’s Zenbleed leaked registers; Intel’s Downfall extracted AES keys across boundaries; Apple’s GoFetch defeated constant-time cryptography via the M-series prefetcher, pulling RSA, Diffie-Hellman and post-quantum keys. Several are architectural with no clean patch.

2025 · Under confidential computing

Cheap DRAM-bus interposers broke SGX and SEV-SNP on DDR4; TEE.fail then reached DDR5, extracting attestation keys from Intel TDX and AMD SEV-SNP and using them to strip NVIDIA GPU confidential computing. The trust root of CC was physically attacked for under $1,000.

The cost of looking just went to zero

Two things used to make most key-in-memory exposures “not worth it”: finding the bug that exposes the key, and turning a noisy leak into an actual key. Both required scarce, expensive human expertise. Both are exactly what machine intelligence now does cheaply, tirelessly, and at scale.

54 vulnerabilities: found autonomously in ~4 hours across 54M lines of code during DARPA’s AI Cyber Challenge (AIxCC finals) in August 2025.
#1 on HackerOne: an autonomous system (XBOW) topped HackerOne’s U.S. leaderboard, out-hunting every human.
~87% success: for GPT-4-class agents autonomously exploiting one-day vulnerabilities.
12 OpenSSL zero-days: surfaced by one AI system, including a critical flaw dating to 1998.

Google’s Big Sleep agent found a real, exploitable SQLite zero-day known only to attackers, and later caught one about to be used in the wild. And it is no longer defensive-only: Anthropic disrupted a threat actor automating an intrusion end-to-end with an AI model. Every exposure is a silent tax, which requires someone skilled enough to bother. AI removes that tax, turning latent risk into kinetic risk.

Table: where the keys actually are and how to protect them

Below are 21 places where a live encryption or signing key becomes exposable, grouped from the application inward to the silicon and the math. For each, we explore below how it’s extracted, what it costs the business, why the usual fix is partial, whether AI makes it worse, and what a Trusted Execution Environment (TEE)actually changes.

‍

ZONE 1Live application memory (the key in use)
Exposure (where the key lives)	Extraction mechanism	Business impact	Traditional mitigation and its limit	AI-amplified?	Protection with a TEE?
Application process heap and stack The key while it's actually encrypting or signing Heartbleed · CVE-2014-0160	Memory-disclosure bug reads live heap; a co-resident or privileged process scrapes the address space. Heartbleed pulled RSA private keys from a running TLS server.	Full decryption and impersonation while "encrypted at rest" stays intact. The key was never at rest when it was taken.	Memory-safe languages, ASLR, guard pages, prompt zeroization. Limit: the key must be plaintext to be used. Any read of that window wins.	HIGH	STRONG
Crash dumps, core dumps, swap and hibernation The key spilled into a file that outlives the process Storm-0558 · 2023	A key lands in a crash/core dump or swap file, later moved to a lower-trust store and read. A stray signing key in a Microsoft crash dump forged tokens into ~25 orgs.	Silent and catastrophic. One leaked signing key forged authentication at national scale, with no malware on victim systems.	Dump scrubbing, disable swap for secret handlers, secret-scanning. Limit: race conditions defeat "shouldn't contain keys"; dumps sprawl to low-trust environments.	HIGH	STRONG
Language runtime / GC heap Keys as immutable strings that can't be wiped	Keys held as immutable objects (JVM, Python, JS) linger in the garbage-collected heap, get copied on relocation, and are recoverable via dump or introspection.	The exposure window stretches from milliseconds to minutes or longer. The keys sit in memory well after last use.	Byte-arrays with explicit wipe, off-heap buffers. Limit: the GC copies and relocates; many libraries force immutable key types.	SOME	PARTIAL

‍

ZONE 2OS, host & virtualization layer
Exposure (where the key lives)	Extraction mechanism	Business impact	Traditional mitigation and its limit	AI-amplified?	Protection with a TEE?
Kernel and privileged-process memory Root reads another process's secrets	An administrator, malicious driver, or post-exploitation tool reads a target process's memory, harvesting live credentials and keys from the system secret store.	Local compromise becomes total key theft and a springboard for lateral movement.	Least privilege, EDR, OS credential protections. Limit: root is game over; EDR detects, it does not prevent the read.	HIGH	STRONG
Hypervisor / VMM The cloud operator, live migration, snapshots	A malicious or compromised hypervisor introspects guest RAM; the key is captured in a memory snapshot or during live migration. No guest bug is required.	The tenant has zero visibility. A provider insider or one hypervisor flaw equals silent, deniable key theft.	Contractual trust, tenant isolation, encryption-at-rest. Limit: you are trusting the entire cloud stack and everyone who operates it.	SOME	STRONG
Container shared kernel and namespaces Co-tenant workloads on one kernel	A container escape or shared-memory access exposes neighbouring workloads' secrets, since they share one kernel as their trust boundary.	A single escape unlocks many tenants' keys, and the blast radius spans every workload on the node.	gVisor / Kata sandboxes, seccomp, strict policy. Limit: the shared kernel is still one failure domain.	HIGH	STRONG
DMA: Thunderbolt / PCIe A peripheral reads RAM directly Thunderclap · Thunderspy · PCILeech	A malicious peripheral performs direct memory access, bypassing CPU and OS to scrape RAM, including keys, with off-the-shelf gear.	Endpoint and server key theft from anyone with brief physical proximity to a port.	IOMMU / VT-d, disable unused ports, pre-boot policy. Limit: IOMMU gaps and pre-boot windows remain exploitable.	LOW	STRONG

‍

ZONE 3Silicon & physical memory: the hardest zone
Exposure (where the key lives)	Extraction mechanism	Business impact	Traditional mitigation and its limit	AI-amplified?	Protection with a TEE?
DRAM remanence Cold-boot key recovery Lest We Remember · 2008	DRAM holds its contents for seconds after power loss; cool the modules, reboot into a scraper, and image RAM to recover AES and disk-encryption keys.	Keys lifted from a powered-off or seized device, including laptops, servers, and appliances in transit.	Memory encryption, fast power-down, no external DMA. Limit: unencrypted DRAM is exposed by physics, not by a fixable bug.	SOME	STRONG
CPU cache & transient execution Speculation and prefetch leak keys Spectre · Downfall · Zenbleed · GoFetch	Cache-timing and transient-execution leaks. Downfall extracts AES keys across boundaries; Zenbleed leaks registers; GoFetch defeats constant-time crypto via the prefetcher.	An unprivileged local process extracts keys even from provably constant-time, correct code. "We did the crypto right" stops being enough.	Microcode, constant-time libraries, core isolation. Limit: many are architectural, mitigations cost performance, and some can't be fully patched.	HIGH	PARTIAL
Memory-bus interposition A physical tap on the DRAM channel WireTap · Battering RAM · TEE.fail · 2025	A sub-$1,000 interposer on the DRAM bus captures or aliases traffic. On DDR4 it broke SGX and SEV-SNP; TEE.fail reached DDR5, extracting attestation keys from TDX and SEV-SNP.	Forged attestation lets an attacker "prove" a fake enclave is genuine and read decrypted confidential-VM memory. The CC trust root, subverted.	Physical security, integrity/freshness (ciphertext hiding, TME-MK). Limit: 2025 work reached DDR5; physical access was always outside the stated threat model.	N/A	BOUNDARY
GPU / accelerator memory The AI-infrastructure surface LeftoverLocals · TEE.fail→GPU CC	Residual GPU memory readable across workloads; extracted CPU-TEE attestation keys can strip NVIDIA GPU confidential computing so "protected" workloads run exposed.	Model weights, training data and keys in AI pipelines are exposed, on the exact surface enterprises are racing onto now.	Buffer clearing, GPU confidential computing. Limit: young ecosystem; GPU CC leans on the same attestation now under attack.	HIGH	PARTIAL

‍

ZONE 4Secrets sprawl and supply chain
Exposure (where the key lives)	Extraction mechanism	Business impact	Traditional mitigation and its limit	AI-amplified?	Protection with a TEE?
Config, env vars and source control Keys pasted where they don't belong	Keys in environment variables, config files or committed to repositories, then harvested on host compromise or straight from a public/leaked repo.	The most common real-world key leak of all: instant, broad, and often found by the attacker first.	Secret-scanning, vault references, pre-commit hooks. Limit: sprawl is endemic; one careless commit or env dump undoes it.	HIGH	PARTIAL
CI/CD build environment Secrets live in the runner's memory CircleCI · 2023	Infostealer on an engineer's device yields a session; the attacker then dumps encryption keys from running build processes. At CircleCI this made "encrypted at rest" decryptable.	Supply-chain-wide. Every customer token and key had to be rotated; blast radius ran downstream to all their systems.	Ephemeral runners, OIDC, short-lived credentials. Limit: at run-time the secret is still live, in memory, on a machine you don't fully control.	HIGH	STRONG
Secrets manager / KMS / vault Decrypted into the app to be used	The vault or KMS protects keys at rest and in transit, then the app pulls the key into ordinary process memory to use it, re-exposing it to every Zone 1 through 3 vector.	A dangerous false comfort: "we use a KMS" reassures the board but does nothing for the key while it is in use.	Envelope encryption, short TTLs, KMS-side crypto operations. Limit: for high-throughput crypto the key still lands in application RAM.	HIGH	STRONG
Backups, VM images & snapshots Keys captured and time-shifted	Key material is swept into a snapshot, machine image or backup and read from a lower-trust store weeks or months later.	Compromise decoupled from the moment of exposure as the keys outlive the controls that guarded them.	Exclude/encrypt secrets, scan images, tight retention. Limit: snapshots are taken indiscriminately and copied widely.	SOME	PARTIAL

‍

ZONE 5Dedicated key hardware
Exposure (where the key lives)	Extraction mechanism	Business impact	Traditional mitigation and its limit	AI-amplified?	Protection with a TEE?
HSM firmware and internal heap The vault of last resort "…this is a robbery" · 2019	Memory-corruption plus a Heartbleed-style heap read inside HSM firmware. Ledger's team reached unauthenticated RCE, dumped all keys, and persisted via signed malicious firmware.	Every key the appliance ever held, plus a backdoor that survives updates. The strongest control in the room, emptied.	FIPS 140-2/3 certification, signed firmware, patching. Limit: certification is not exploit-proof; the firmware is itself the attack surface.	SOME	COMPLEMENT
TPM / secure-element bus and timing The link to the chip, and the chip itself bus sniffing · TPM-Fail	Sniff the low-speed bus between CPU and a discrete TPM to grab keys in transit; timing side channels recover ECDSA keys from the TPM's own computation.	Platform and disk-encryption keys lifted with cheap gear; forged platform attestation.	Firmware TPM, bus encryption, PIN/pre-boot auth. Limit: the discrete-TPM bus is exposed by design; timing flaws need silicon fixes.	SOME	DIFFERS

‍

ZONE 6Key genesis and the math (where custody can't help)
Exposure (where the key lives)	Extraction mechanism	Business impact	Traditional mitigation and its limit	AI-amplified?	Protection with a TEE?
Weak generation / predictable keys Broken before first use Debian OpenSSL · ROCA · CVE-2017-15361	Low-entropy RNG or flawed key generation yields guessable or factorable keys. ROCA made Infineon-generated RSA keys factorable across TPMs, smartcards and national ID cards.	Keys broken with no memory access at all, purely from the public key. Whole populations compromised at once.	Vetted RNGs, entropy health tests, keygen review. Limit: silent until someone runs the math against your public keys.	SOME	NO HELP
Signing / keygen side channels Leakage from observable behaviour Minerva · TPM-Fail · Hertzbleed	Timing, power, electromagnetic or CPU-frequency leakage during signing or key generation lets an observer reconstruct the private key.	Private ECDSA/RSA keys recovered from how the system behaves, never from reading its memory.	Constant-time code, blinding, masking. Limit: hardware effects like frequency scaling slip past software constant-time.	HIGH	PARTIAL
Cryptanalytic / oracle leakage Plaintext falls out and no key is needed FF3 slide · FF3-1 linear · small-domain FPE	The algorithm leaks under mere query access. Small-domain FPE and the FF3 slide / FF3-1 linear attacks recover plaintext from an encrypt/decrypt oracle without touching the key.	Plaintext recovered while the key stays perfectly secret. Every dollar spent on key custody protects nothing here.	Standard modes, adequate domain, per-(key,tweak) query budgets, decrypt authorization. Limit: mode and domain choices are usually locked into the data format.	SOME	NO HELP

Two honest truths about TEEs

01 · What a TEE genuinely fixes: it closes the remote and software column at once.

Run key custody and key use inside an attested TEE and the key never appears in cleartext to the OS, hypervisor, container host, cloud operator, build runner, or a co-resident process. Memory is hardware-encrypted, and the key is released only to a measured, verified runtime that has proven by remote attestation that it is the exact code you expect. This is the one move that addresses key-in-use structurally, instead of bolting on a fifth layer of detection over the same exposed memory. Zones 1, 2 and most of 4 stop being your problem.

02 · What a TEE does not fix: it is a lock on custody, not a cure for the cipher.

The 2025 interposer attacks show a physical adversary on the memory bus can reach even DDR5 TDX and SEV-SNP, so attestation freshness and physical/supply-chain controls still matter. And no TEE rescues a broken mode, a weak RNG, a side channel in your own in-enclave code, or a decrypt API you handed to the attacker: a TEE will faithfully answer every oracle query, including the malicious ones. That is exactly where the FPE small-domain problem lives in plaintext recovered with the key still sealed. Custody protection ends at the math.

The strategy that follows is not “buy one thing.” It is: shrink the surface to silicon, move custody and use into an attested TEE so nearly the entire table collapses, then deliberately defend the residue that silicon can’t move: oracle and query limits, RNG hygiene, attestation freshness, physical and supply-chain controls, and disciplined key ceremonies.

Five tenets to take into the room

01 · The algorithm is not your risk. The moment of use is.

Spend your review budget on where every key becomes plaintext, not on which cipher you picked. Nobody in the timeline lost data to cryptanalysis of AES.

02 · “Encrypted at rest” is a claim about disks, not about attackers.

CircleCI’s data was encrypted at rest. The keys were dumped from a running process. Inventory every point where a key is cleartext in memory, because that list is your real attack surface.

03 · Assume the key will be found.

AI has turned “somewhere in the system” into a solvable search and “a noisy leak” into a recovered key. Design so that finding it isn’t the same as having it.

04 · Move custody and use to attested silicon, then defend the residue.

A TEE collapses most of the map. It does not fix the cipher, the entropy, the oracle, or the physical bus. Name those explicitly and cover them on purpose.

05 · Attestation is the new perimeter and it is now itself a target.

Verify freshness; never treat an attestation quote as forever-true. The 2025 work extracted attestation keys. Trust roots need the same scrutiny as the workloads they vouch for.

Conclusion: if you cannot name, today, every place your signing key becomes plaintext in memory, you don’t have a key management program. You have a key location problem. And the tools that find it are no longer scarce, expensive, or human.

References

Representative of each exposure class, not an exhaustive citation of all published work.

Put custody where the keys can't be found

If you can’t say, right now, where every signing key in your stack turns to plaintext, that’s the gap to close first. See what running key custody and key use inside an attested TEE looks like on your own infrastructure. Start your free trial with Anjuna Seaglass.