Recallspection ExactMemory

What this means

ExactMemory commits to its whole store with one MAC and gives every record a tag of its own inside it. An attacker who can write the store, but who holds neither key, cannot get a single record edit past the read path: the container MAC fails and the load refuses. What he can still do is put the whole store back to an earlier copy of itself. In this configuration the anchor holding the high-water mark sits beside the store on the same disk, so the rollback takes the anchor with it, the older store opens as current, and the newest genuine record is gone with no error. The row with the anchor moved off the store refuses that same rollback. One deployment choice separates them. The maintainer asked for this row to be published rather than the anchored one alone.

The 9 verdicts

Detection point: the read path. 8 of the nine edits were refused there, 1 served as genuine, 0 not applicable.

Level L3. What L3 means.

Where the attacker stands

The attacker reads and writes the store directory, which here includes the anchor. He holds neither the container key nor the record keys, so he cannot forge either MAC.

Reproduce this row

Everything runs offline unless the store is a managed cloud service, in which case the row needs a project of your own. The run seeds a fresh store, applies each edit, confirms it landed, reopens the store and records what came back.

pip install agent-memory-integrity
git clone https://github.com/sciencedelicmetatech/exactmemory.recallspection
cd exactmemory.recallspection && git checkout c62ef7ada64928418a7e5d3251a6b65d005599b6
export AGMI_RECALLSPECTION_REPO=<that checkout>
python agmi/full_runner.py --json results/scorecard.json   # every row, this one included
python -m agmi.agent --target recallspection-exact --families at-rest