How It Works

How It Works

Most sanitization tools ask the drive to erase itself and then walk away.

AAD-50 stays. It watches. It verifies. And it does not move to the next cycle until the hardware confirms the previous one actually completed.

This is the difference between assuming a drive is clean and knowing it.

---

The Problem AAD-50 Solves

NVMe Sanitize — Opcode 0x84 — is asynchronous.

When you issue the command, the drive acknowledges receipt instantly and returns control to the host. The actual erasure happens in the background, on the drive's internal ASIC, at silicon speeds the host cannot directly observe. The host has no way to know whether the operation completed correctly — or at all — unless it actively polls NVMe Log Page 0x81 (the Sanitize Status log page) and reads the SSTAT field.

The standard Linux tooling did not do this polling. It fired the command and returned. If drive firmware silently failed — which UC San Diego researchers documented happening in 3 of 12 drives they tested — the operator had no way to know.

AAD-50 fixes this at the architectural level.

---

The Verification Loop

After every single sanitize cycle, AAD-50 enters a polling loop against Log Page 0x81:

SSTAT Code	Meaning	AAD-50 Action
0x0	Idle - no recent sanitize	Treat as complete, advance
0x1	Completed successfully	Hardware confirmed - advance to next cycle
0x2	Sanitize in progress	Continue polling (2 second interval)
0x3	Completed with errors	Abort - write fault record to audit log

The loop runs on a 2-second poll interval with a 2-hour timeout per cycle. AAD-50 refuses to advance to the next cycle until SSTAT = 0x1 is returned. If SSTAT = 0x3 is returned at any point — the entire operation stops immediately and the fault is recorded in the audit log.

No cycle is assumed complete. Every cycle is confirmed.

---

The Three-Phase Destruction Matrix

AAD-50 executes a deliberate B -> C -> A phase sequence across 50 cycles. The order is not arbitrary — it is a security engineering decision.

Phase B - Physical NAND Cell Overwrite (Cycles 1-40)

NVMe Sanitize Opcode 0x84 | CDW10 = 0x02 | SANITIZE_ACTION_OVERWRITE

Phase B instructs the drive's internal controller to physically overwrite all NAND cells — including over-provisioned zones, bad-block retirement pools, and wear-levelling reserves that are completely invisible to the host operating system.

This is the phase that host-driven software tools like DBAN, nwipe, and DoD 5220.22-M cannot reach. Those tools push sequential writes from the host CPU across the PCIe bus. The drive's Flash Translation Layer intercepts those writes and redirects them to fresh physical blocks — leaving the original data untouched in hidden regions.

NVMe Sanitize with NSID=0xFFFFFFFF broadcasts to the entire drive subsystem. No hidden region is excluded.

The 40-cycle allocation provides redundancy against the class of transient firmware faults Wei et al. documented — where a drive executes a sanitize cycle incompletely without reporting an error. Multiple hardware-confirmed cycles ensure no physical location is missed regardless of firmware queue behaviour.

Phase C - FTL Index Teardown (Cycles 41-45)

NVMe Sanitize Opcode 0x84 | CDW10 = 0x01 | SANITIZE_ACTION_BLOCK_ERASE

Phase C destroys the Flash Translation Layer's internal mapping tables — the index that tells the controller which logical block addresses map to which physical NAND locations.

After 40 cycles of Phase B, the physical cells have been overwritten. Phase C ensures the structural map that would allow reconstruction of the data layout is itself completely erased and rebuilt from a clean state. Read requests to any unallocated LBA after Phase C return a hardware-level Unwritten Block error before any forensic carving tool can scan the address.

Phase A - Cryptographic Key Destruction (Cycles 46-50)

NVMe Sanitize Opcode 0x84 | CDW10 = 0x04 | SANITIZE_ACTION_CRYPTO_ERASE

Phase A forces the drive to regenerate and overwrite its internal Media Encryption Key (MEK) registers — 5 consecutive times.

Phase A executes last. This is deliberate. Destroying the cryptographic key first — before physical overwrite — creates a window of vulnerability: if a hardware fault terminates the sequence mid-way, a state-sponsored adversary with physical chip access could attempt to reconstruct the original key through side-channel analysis before the overwrite completed.

By executing B first, then C, then A — physical destruction leads and cryptographic destruction seals. Partial execution of B -> C -> A is always safer than partial execution of A -> B -> C.

---

Why Not Just Software Overwrite?

Software overwrite tools operate at the logical boundary layer. They push data from the host CPU, through the operating system storage stack, through the PCIe bus, and into the drive as normal write commands.

The Flash Translation Layer silently intercepts every one of those writes and redirects them to a fresh physical block — leaving the original data in over-provisioned zones, wear-levelling pools, and retired blocks the host can never reach.

Wei et al. (USENIX FAST 2011) proved this empirically. They tested every major government sanitization standard — DoD 5220.22-M, Gutmann 35-pass, German VSITR, British HMG IS5, US Air Force 5020 — against real SSD hardware. Every single one failed. Recoverable data ranged from 40 MB to nearly 1 GB from a 1 GB test file.

AAD-50 uses no software overwrites. Every cycle is a hardware NVMe Sanitize command issued directly to the drive's ASIC via IOCTL passthrough. The host machine is the orchestrator. The drive does the work — on its own internal buses, at silicon speeds, reaching every physical location including the ones the host cannot see.

---

The SHA-256 Audit Chain

After all 50 cycles complete, AAD-50 aggregates every cycle record — timestamp, action code, duration, completion status, and active passthrough tier — into a structured telemetry array.

A SHA-256 hash is computed over the key-sorted JSON serialisation of all 50 cycle records:

Audit Hash = SHA-256( JSON_sorted( CycleRecords[1..50] ) )

This hash is printed at the end of every run, embedded in the JSON audit log, and printed on the PDF Certificate of Destruction. It is tamper-evident — any modification to any cycle record changes the hash. Security auditors can verify the hash independently to confirm all 50 cycles completed cleanly on the hardware.

---

Three-Tier Passthrough Architecture

AAD-50 probes the connected device at runtime and selects the highest available command pathway before the first cycle is issued:

Tier	Linux Interface	Windows Interface	Verification	Coverage
1 - NVMe Direct	NVME_IOCTL_ADMIN_CMD	IOCTL_STORAGE_PROTOCOL_COMMAND	Log Page 0x81 per cycle	M.2/PCIe + UASP enclosures with NVMe passthrough
2 - ATA/SCSI SAT	SG_IO via SCSI ATA PASS-THROUGH	IOCTL_ATA_PASS_THROUGH	Time-based (120s/cycle)	USB enclosures with UASP + SAT support
3 - Block Layer	BLKDISCARD	IOCTL_STORAGE_REINITIALIZE_MEDIA	Time-based (180s/cycle)	USB enclosures blocking NVMe and ATA passthrough

Tier 1 provides the strongest assurance — hardware-confirmed completion via Log Page 0x81 after every cycle. Tiers 2 and 3 use conservative time-based polling because the USB bridge chip intercepts NVMe log page reads. For maximum assurance, direct M.2/PCIe connection is always recommended.

---

What AAD-50 Does Not Protect Against

AAD-50 is transparent about its limitations:

• Deliberate firmware misrepresentation — a drive that lies about both sanitize execution and SSTAT reporting simultaneously cannot be caught by any software-level protocol. Against that threat model, physical destruction is the only reliable method.
• Non-SED drives — Phase A (Crypto Erase) is effective only on Self-Encrypting Drives. On non-SED drives, the protocol's security rests entirely on Phases B and C.
• USB Tier 2 and 3 — time-based polling cannot provide the hardware-level certainty of Tier 1 Log Page 0x81 confirmation.

These limitations are documented in full in the whitepaper: https://doi.org/10.5281/zenodo.20839417

---

Further Reading

• Quick Start — get running in minutes
• Hardware Test Reports — real-world validation results
• FAQ — common questions answered
• Whitepaper — full technical specification
• RFC [#3415] — the original nvme-cli proposal
• PR [#3438] — the merged implementation

---

AAD-50 v1.1 - github.com/yonasabeselom/aad50