RSSD: defend against ransomware with hardware-isolated network-storage codesign and post-attack analysis

Ransomware encrypts your files and demands payment — and defenses that live in the operating system lose the moment the malware gains kernel privilege, while the clever hardware defenses (SSDs quietly keep old versions of overwritten data) assume ransomware ignores how flash actually works; RSSD first demonstrates three new attacks that weaponize SSD internals to destroy those retained old versions (flood the drive to force garbage collection, encrypt slowly to blend in, or use the TRIM command to physically erase), then rebuilds the SSD firmware to conservatively keep EVERY old version, offload the overflow to the cloud through an Ethernet port wired directly into the drive controller where no compromised OS can reach it, and log every storage operation for tamper-proof forensics — recovering all data with under 1% performance overhead.

The argument in one glance

Problem

The defender and the attacker share the same operating system

Encryption ransomware reads your files, encrypts them, and destroys the originals — then sells the key back to you. A study of 144 recent attacks in this paper found an average of 3.12 weeks of downtime, and industry reports one attack attempt every 11 seconds at roughly $8,100 ransom plus $300,000 in downtime each. The defenses people rely on — intrusion detectors watching file-access patterns, backup software — run inside the operating system. And modern ransomware routinely gains OS kernel privilege, from which it can terminate the detector, overwrite the backups with encrypted versions, and hide in the network for an average of 11 days first. The referee plays for the other team.
What people did

Move the defense into the SSD, below the OS

A cleverer line of work (FlashGuard, TimeSSD, SSD-Insider) hides the defense in the storage controller's firmware, which sits below the block interface and cannot be touched by OS-level malware. It exploits a physical fact: flash cannot overwrite in place, so when a file is "overwritten," the SSD actually writes the new data elsewhere and leaves the OLD version sitting in a now-invalid flash page — recoverable until garbage collection reclaims it. Retain those invalid pages a while, and you can roll back a ransomware attack.
Why it fell short

Those defenses assume ransomware does not understand SSDs

The retained old versions survive only until the SSD needs the space back — and this paper shows an SSD-aware attacker can force that to happen. (1) The GC attack floods the drive with garbage writes; a 1 TB SSD fills in 7.8 minutes, triggering garbage collection that erases the retained originals. (2) The timing attack encrypts slowly, mimicking normal I/O to evade pattern detectors and simply waiting out the retention window (0.9–11.2 days at half capacity, less when fuller). (3) The trimming attack issues the TRIM command — a normal SSD feature that tells the drive "these blocks are free, erase them" — to physically destroy originals within seconds, a pattern no detector even watches for. Each needs under 10 lines of code bolted onto real ransomware. The old defenses retain data for a LIMITED time, and the attacker now controls the clock.
This paper's idea

Keep everything, hide the escape hatch in hardware, log it all

RSSD (UIUC and Penn State) makes three moves. Retain CONSERVATIVELY: keep every invalid flash page, in time order (bloom-filter epochs index versions; delta compression shrinks them), so nothing the attacker wants gone can be reclaimed on their schedule. Expand SECURELY: integrate an Ethernet controller directly into the SSD, so the drive streams its overflow of old versions to remote cloud or servers through a channel the host OS cannot see or sever — NVMe over Ethernet, hardware-isolated. Neutralize TRIM: instead of honoring or disabling it, remap trimmed blocks to fresh pages and retain the "erased" data, giving the attacker the illusion of success. And log every read and TRIM (writes are already timestamped in flash), building a tamper-proof evidence chain for forensics. Built on a real OpenSSD FPGA board: full data recovery, trusted post-attack analysis, and under 1% performance overhead.

Why this problem is worth solving

Ransomware is the rare security threat whose business model guarantees it keeps evolving: attackers profit only when victims cannot recover without paying, so every defense that enables recovery is met with a countermeasure. The paper’s framing turns on

the set of components a security guarantee depends on — the code and hardware that, if compromised, breaks everything. The larger and more exposed the trusted computing base, the weaker the guarantee. An operating-system kernel is enormous and routinely compromised; the firmware inside an SSD controller is small, sits below the generic block interface that even the OS talks through, and cannot be reflashed without authentication — a far smaller and better-isolated trusted base. RSSD’s threat model deliberately distrusts the OS and trusts only the SSD firmware

: the insight that a defense inside the storage device outlives the compromise of everything above it. This is not paranoia — the paper’s study of 144 attacks found 45% of victims HAD software backups and still suffered downtime and data loss, because kernel-level malware reached the backups too.

The prior in-storage defenses had the right instinct and a fatal assumption. They leaned on

the physical quirk that makes SSD versioning possible: NAND flash cannot overwrite a page in place — it must erase first, and erasure works only on large multi-page blocks. So every “overwrite” is actually an out-of-place write: new data goes to a fresh page, the old page is marked invalid, and the flash translation layer remaps the address. The invalid page — the previous version — physically survives until garbage collection (GC) eventually erases its whole block to reclaim space. That window of survival is free version history, and it is exactly what SSD-aware ransomware learns to close

, assuming ransomware would treat an SSD like an old hard disk and never manipulate the retention window itself. RSSD’s first contribution is to demolish that assumption with three working attacks, and its second is a defense that holds even when the attacker knows every detail of how the flash works underneath — because the data’s escape route to safety is wired into hardware the attacker’s code can never reach.

What people did before, and where it broke

Software intrusion detection (Unveil, CryptoDrop, ShieldFS). Watch for the tell-tale read-encrypt-overwrite or read-encrypt-delete I/O pattern. Defeated by kernel-privilege termination, and by the timing attack that simply spreads the pattern thin enough to look normal — and even a successful detection arrives after some files are already encrypted.
Software and cloud backups (CloudBackup, journaling/log file systems). Keep copies to restore from. But kernel-level malware can overwrite them with encrypted versions, and attackers hiding for days ensure the backups themselves are poisoned before detonation.
In-storage versioning (FlashGuard, TimeSSD, SSD-Insider, RBlocker). Retain invalid flash pages in firmware, below the OS — the right layer. But they retain SELECTIVELY (only pages matching known ransomware patterns) and for a LIMITED time (bounded by local capacity), so the GC attack forces reclamation, the timing attack outlasts the window, and none of them retains data the TRIM command erased. All partially recoverable at best; none offers forensics.

How RSSD works

Conservative retention, a hardware escape hatch, and a tamper-proof log

Out-of-place writes leave versions behind

Normal SSD behavior: every write lands on a fresh page, the old page becomes invalid, and the address map is updated. The previous version physically exists until garbage collection erases its block. RSSD builds on this rather than changing it — the raw material for recovery is already there, if only it can be kept long enough.
↓ →
Bloom-filter epochs: retain everything, in time order new

RSSD indexes invalid pages by a chain of bloom filters, each representing one time window. A newly invalidated page's address goes into the current filter; when it fills, a new epoch begins. Because bloom filters have false positives but never false negatives, RSSD may conservatively retain a page it could have dropped — harmless — but NEVER mistakenly reclaims one it should have kept. Version ordering falls out of epoch order, for free.
↓ →
Delta compression during garbage collection new

Keeping every version is expensive, but successive versions of a page usually differ in only a few bytes. During GC, RSSD computes the delta between an old version and the current one (the reference, which time-ordering guarantees still exists), stores only the difference with metadata (a back-pointer to the prior version, a timestamp, the reference address), and chains deltas per logical address. Compression runs on the SSD's own embedded processors, folded into GC.
↓ →
TRIM, redefined as retain-and-remap new

A TRIM command normally tells the SSD to erase named blocks. RSSD instead allocates fresh blocks, remaps the trimmed addresses to them, and retains the original data (inserted into a bloom filter for compression and offload). The host sees TRIM "succeed" and keeps its performance benefit; the attacker sees erasure that did not happen. The trimming attack is neutralized by giving it exactly the illusion it wanted.
↓ →
NVMe over Ethernet, wired into the controller new

Retaining everything overflows local capacity, so RSSD offloads compressed old versions and operation logs to remote cloud/servers — through an Ethernet MAC integrated INTO the SSD controller, not the host's network card. The host OS cannot see or sever this channel; data is AES-encrypted per block before transfer, sent during predicted idle I/O windows, and suspended the instant a real request arrives. Under 5% chip-area and ~6–19% power overhead, per cited industry figures.
↓ →
Hardware-isolated logging for forensics new

RSSD logs every read and TRIM (8 bytes each: timestamp + address) in the firmware; writes are already timestamped in each page's out-of-band metadata, with a back-pointer to the previous version. Because the log lives below the OS and is offloaded to the trusted remote, it forms an evidence chain no malware can alter — reconstructing the exact sequence of operations that led to an attack, anti-forensic actions included.

Threat model: the OS is untrusted (malware may hold kernel privilege); the SSD firmware is trusted (small trusted base, below the block interface, no unauthenticated reflash). Built on a Cosmos+ OpenSSD FPGA board (ARM Cortex-A9, 1 GB DRAM, 1 TB flash) with a real remote server over 1 GigE and Amazon S3. Logging 100 million operations costs 800 MB — 0.076% of a 1 TB drive.

The idea

Put the defense where the attacker cannot follow. Every software defense loses the same way: it shares a trusted computing base with the malware, so kernel privilege ends the game. RSSD’s organizing principle is to relocate both the data’s safety and the audit trail below the block interface, into firmware with a small, reflash-protected trusted base — and then, crucially, to wire the ESCAPE ROUTE (the Ethernet link to remote storage) into that same isolated hardware. Prior in-storage defenses got the location right for the data but still depended on the host to move overflow off the drive; RSSD closes that gap by making the network port part of the SSD, so nothing the compromised OS controls stands between the old versions and their safe, replicated, off-device home.

Refuse the attacker’s knowledge instead of racing it. The three attacks all exploit the same weakness: prior defenses retain data selectively and temporarily, so an SSD-literate attacker can force early reclamation. RSSD removes the selectivity (keep EVERY invalid page, not just pattern-matched ones) and removes the time limit (offload overflow to effectively unlimited remote capacity). Once retention is total and durable, the GC attack frees only space RSSD already copied out, the timing attack outlasts nothing, and knowing the SSD’s internals buys the attacker nothing. This is defense by denying the premise — the same move as designing a system with nothing to leak rather than patching each leak, seen in this site’s speculation-safe hardware page.

Turn the attacker’s own tool into a tripwire, and log the rest. The TRIM redefinition is the paper’s most elegant inversion: a command built for performance, weaponized for destruction, is answered not by disabling it (losing the performance) but by faking its effect while secretly preserving what it tried to erase — the attacker’s exploit becomes a no-op it cannot detect. And RSSD’s insistence on LOGGING everything, in a place malware cannot rewrite, addresses a gap the 144-case study exposed: only 23.6% of victims managed any post-attack analysis, taking 5.72 weeks on average, because the evidence lived where the attacker could destroy it. A trusted evidence chain is how each attack teaches the defense to counter the next.

One attack, defeated three ways

Ransomware meets RSSD

From the paper's proof-of-concept: WannaCry encrypts 128 MB of files on a half-full 1 TB drive, then launches each new attack. On a regular SSD, all three succeed within minutes to hours.

Step 1 of 5

Encryption: the originals become invalid pages

The ransomware reads files and writes encrypted versions. On any SSD, the originals are not overwritten in place — they become invalid flash pages, physically intact, awaiting garbage collection. This is the recovery window every in-storage defense depends on. On a regular SSD it lasts 0.9–11.2 days at half capacity; the attacker's job is to close it.

out-of-place writes are a flash necessity, not a defense feature — RSSD just refuses to let them be reclaimed on the attacker's schedule
RSSD indexes each invalidated page into the current bloom-filter epoch the instant it is invalidated

Why it works

The SSD firmware is a small, reflash-protected trusted base below the OS → relocating the defense there survives the kernel-privilege compromise that defeats every software defense → the referee no longer plays for the attacker’s team.
Bloom filters have false positives but no false negatives → RSSD may keep a page it could have dropped but never drops one it should keep → conservative total retention with epoch ordering, at index cost measured in megabytes.
Successive page versions differ by a few bytes, and time-ordering guarantees the reference version outlives its deltas → delta compression during GC shrinks the history cheaply on the SSD’s own processors → total retention becomes affordable in space and free in extra compute.
The Ethernet port is integrated into the controller, below the host → the OS can neither see nor sever the offload channel, and per-block AES protects it in flight → overflow reaches replicated remote storage that kernel malware cannot poison, giving effectively unlimited, durable retention.
TRIM is answered with remap-and-retain rather than erase or disable → the attacker’s destructive command becomes an undetectable no-op while the host keeps TRIM’s performance → a weaponized feature is neutralized without sacrificing its legitimate use.

What it costs

You must trust the cloud and the offload link. RSSD’s guarantee shifts trust to the remote store and the in-controller network; the design AES-encrypts every block and isolates the port, but the security now rests on those holding, and on an initial configuration done in a safe environment.
Board-level physical attacks are out of scope. The threat model explicitly excludes bus-snooping and side-channel attacks on the SSD hardware itself — reasonable (most ransomware is remote) but a real boundary.
Retention has a hard floor. If the remote link breaks, RSSD compresses and retains locally until full, then REFUSES writes — failing safe, but failing: a determined offline GC attack degrades into denial of service rather than data loss.
Detection is deferred, not solved. RSSD recovers rather than prevents; it retains everything precisely because it cannot tell attack from normal I/O, and the authors flag in-storage learning-based detection (to prune retention) as future work.
Prototype scale. Evaluated on a 1 TB OpenSSD FPGA over 1 GigE with 13 ransomware samples; production drives, faster fabrics, and adversarial offline scenarios are extrapolation.

The evaluation

Built on a Cosmos+ OpenSSD FPGA board against three baselines — a regular SSD, an SSD that retains stale data in time order (LocalSSD), and that plus delta compression — using Microsoft and FIU storage traces, OLTP/IOZone/PostMark benchmarks, and 13 real ransomware samples from VirusTotal.

Ransomware defenses against SSD-aware attacks

Property	Software (detectors, backups)	Prior in-storage versioning (FlashGuard, SSD-Insider)
Survives kernel-privilege malware
GC attack (flood to force reclamation)	Not addressed
Timing attack (slow encrypt) & TRIM attack (erase)
Data recovery & retention time	Partial at best (65% recovered on average when ransom paid; 22% get nothing)	Partially recoverable; 0.9–11.2 days at half capacity
Performance, lifetime, forensics	Varies; no trusted forensics (only 23.6% of victims managed any, ~5.72 weeks)

Cost: expanding local flash to hold the same history costs 85.6× more than RSSD's cloud offload (8.6× vs local SSD+HDD). Network flexibility: swapping the local server for a distant one or Amazon S3 slows RSSD only 3.2% and 6.7%. Chip overhead per cited industry figures: under 5% area, 5.7–19.2% power for the Ethernet controller.Underlined values explain themselves when clicked.

Where this stops working

What to keep in mind

RSSD moves the trust boundary rather than eliminating it: the guarantee now rests on the remote store, the in-controller network link, and a one-time configuration performed in a safe environment — all of which the design hardens (per-block AES, hardware isolation) but none of which it makes unconditional. Board-level physical attacks (bus snooping, side channels on the SSD itself) are explicitly out of scope. The failure mode when the remote link is severed is denial of service — refuse writes when locally full — which is safe but not free. And RSSD deliberately does not detect; it recovers, retaining everything because it cannot distinguish attack from normal I/O, with smarter in-storage detection left as future work. The evidence is a 1 TB FPGA prototype over 1 GigE against 13 samples — a strong demonstration, not a production drive at datacenter fabric speeds.

Background

Shrinking the trusted base, and inverting the attacker's tool

RSSD sits at the intersection of two clusters this site tracks. It joins the security arc — the speculation-contract fuzzing and hardware-isolation pages covered elsewhere on this site — around one shared move: shrink the trusted computing base and put the defense where the attacker cannot reach, exactly as the in-process-isolation page relocates protection into the datapath and this page relocates it into the SSD controller. And it joins the storage cluster (learned FTLs, zoned RAID, the heterogeneous key-value store) through the append-don’t-update lineage the site keeps finding in flash: out-of-place writes, which those pages treat as a performance and endurance discipline, RSSD reads as a SECURITY primitive — the old version flash leaves behind is free version history. Two smaller rhymes: the predict-idle-time offload scheduling echoes the cheap-proxy and idle-cycle scheduling family, and the TRIM inversion — answer the attacker’s own command with an undetectable no-op — is a defensive cousin of the deception patterns, giving the adversary the illusion of the effect they wanted while quietly preserving what they tried to destroy.

If you remember only three things

1. Ransomware defenses fail at their trust boundary: software detectors and backups share the OS kernel that ransomware seizes, and prior in-storage defenses (which exploit flash retaining overwritten versions in invalid pages) assume the attacker ignores SSD internals — an assumption RSSD breaks with three working attacks (flood-to-force-GC, slow-encrypt-to-outlast-retention, TRIM-to-physically-erase), each needing under 10 lines of code, each destroying the retained originals recovery depends on.
2. RSSD answers by relocating both the retained data and its escape route below the OS: conservative retention of EVERY invalid page (bloom-filter epochs for time order, delta compression during garbage collection to make it affordable), an Ethernet controller wired INTO the SSD to stream overflow to encrypted remote storage the host cannot see or sever, TRIM redefined as remap-and-retain so erasure becomes an undetectable no-op, and hardware-isolated logging of every operation for a tamper-proof forensic evidence chain.
3. On a real OpenSSD FPGA against 13 ransomware samples: full data recovery where prior defenses give partial at best, retention extended from days to 215 days, forensic reconstruction in 2.6–52.5 seconds, and only 0.77% average performance overhead (sometimes beating a regular SSD, since offload frees space) at 85.6× lower cost than expanding local storage — with the honest caveats that trust shifts to the cloud and offload link, physical attacks are out of scope, and the design recovers rather than prevents.

Check yourself

Check your understanding

1. FlashGuard and similar in-storage defenses already run below the OS, in firmware ransomware cannot terminate. Predict why RSSD's authors consider them defeatable anyway — and what the three new attacks share.
2. RSSD integrates an Ethernet port directly into the SSD controller rather than sending overflow through the host's network card. Why is this the load-bearing design choice, not merely a performance tweak?
3. The TRIM command tells an SSD to erase blocks it's told are free — a performance feature ransomware can turn into a fast erase tool. RSSD neither honors nor disables it. Predict what it does and why that's better than either alternative.
4. RSSD retains EVERY invalid page rather than only suspicious ones, and its authors call this "conservative." Predict the cost this creates, how RSSD makes it affordable, and why the bloom filters can tolerate false positives but not false negatives.

Sources

ACM DL: RSSD: Defend against Ransomware with Hardware-Isolated Network-Storage Codesign and Post-Attack Analysis — ASPLOS 2022
arXiv abstract 2206.05821 — 2-page summary (full text via the ACM version)