Source-linked AI summary
ANCHOR: A Vision for Secure Persistent Key-Value Stores in Disaggregated Data Centers
Viraj Thakkar, Dongha Kim, Hokeun Kim, Zhichao Cao
TL;DR
Disaggregated PKVS expand the attack surface and make it difficult to ensure that returned results reflect current logical state rather than stale or manipulated data. ANCHOR presents a semantics-aware design that binds persistent artifacts to version evolution and constrains volatile state through provenance checks in a TEE-backed mediator. The paper’s supported outcome is a vision and set of invariants for preserving confidentiality, integrity, and freshness while retaining disaggregation’s performance and elasticity goals.
Problem
Disaggregated PKVS move data across hosts and services, while existing protections may authenticate individual objects without ensuring current logical-state selection or trustworthy derived state.
Method
ANCHOR co-designs cryptographic protection with PKVS semantics, using a manifest-rooted version timeline for persistent objects and a trusted mediator for provenance-checked in-memory state.
Results
ANCHOR outlines invariants requiring version-bound artifact integrity, authenticated derivation of returned values, restricted trusted state, and batched asynchronous verification.
Takeaways & Limitations
Secure disaggregated PKVS should treat caches, indexes, and filters as untrusted hints and make every query result derivable from authenticated, current state.
Takeaways & Limitations
The vision assumes sound cryptography, key management, and correct TEE-mediated execution, and does not address denial-of-service, leakage, or physical attacks.
Abstract
from arXiv · showhide
Persistent key-value stores (PKVS) are increasingly deployed in disaggregated settings that split compute, memory, and storage across separate server pools. This shift redraws the trust boundary: data that would remain within a single machine is now transported, cached, and rewritten across multiple hosts, expanding exposure to both network attackers and intra-infrastructure adversaries. This paper presents ANCHOR, a vision for end-to-end integrity and freshness in disaggregated PKVS. ANCHOR proposes a two-part semantics-aware architecture: 1) Persistence path: ANCHOR outlines encrypting and authenticating PKVS persistent files and preventing rollback with manifest versioning. 2) Volatile path: ANCHOR treats caches, indexes, and filters as untrusted hints unless accompanied by verifiable provenance, enforced by a TEE-resident policy. Finally, we outline key invariants and discuss enclave-friendly batching and asynchronous I/O to amortize verification without undermining disaggregation's performance and elasticity benefits.
1 Introduction
Disaggregated deployment expands the PKVS trust boundary because data crosses and is modified across multiple hosts, exposing it to network and infrastructure adversaries. ANCHOR proposes semantics-aware protection for persistent and volatile state while preserving elasticity and performance.
- Disaggregation transports, caches, and rewrites PKVS data across multiple hosts, making the network and infrastructure tiers first-class parts of the threat surface.
- The threat model includes active network attackers, untrusted backend storage or memory, and compromised compute-side software up to the OS or hypervisor.
- Naively protecting every layer can add read/write-path work and make limited TEE memory an elasticity bottleneck.The paper specifically identifies repetitive encryption and cache management beyond TEE memory as costs.
- ANCHOR binds persistent objects to PKVS evolution and uses a trusted mediator to control cache admission and verify provenance before values reach applications.The design targets rollback and mix-and-match attacks across WAL/SST histories while treating derived in-memory state as untrusted.
- Its security invariants require contents and evolution binding, authenticated derivation of returned values, small trusted state, and batched asynchronous verification.
2 Background
PKVS expose simple persistence operations while using varied underlying structures; this section focuses on LSM-KVS data flow and its disaggregated deployment across remote storage and memory.
- PKVS provide a high-performance interface for persisting service and user data, with underlying designs such as B+-trees and LSM trees offering different read/write trade-offs.The passage states that B+-tree engines typically demonstrate better read performance, while LSM engines typically demonstrate better write performance.
- In an LSM-KVS, writes enter the WAL and memtable, then flush into SSTables while a manifest records live files and key ranges for reads and recovery.
- Disaggregated LSM-KVS separate compute from state-holding resources, placing WAL and SSTables in remote storage and potentially externalizing caches and read accelerators to remote memory.Flush and compaction continue generating SSTables and manifest updates while artifacts move across hosts and services.
3 Motivation
Disaggregated LSM-KVS place untrusted components on the paths of foreground operations and background maintenance, making freshness and provenance as important as byte-level integrity. Existing protections can authenticate objects yet fail to ensure that the objects used belong to the current logical state.
- The threat model treats untrusted components as present on both foreground read/write paths and background flush/compaction paths.
- Sensitive assets include WALs, SSTables, manifests, caches, compaction working sets, and derived structures because each can affect confidentiality, recovery, or read behavior.
- The model includes active network attackers, untrusted remote storage or memory, and compromised compute-side software that can tamper with data, I/O, caches, or metadata.
- ANCHOR trusts only a TEE-backed mediator holding keys and validating artifact provenance and version evolution; the OS, hypervisor, remote memory, and storage may be adversarial.
- 3.2 Motivation: LSM correctness depends on versioned evolution and derived read state, so stale manifests or poisoned hints can induce rollback, mix-and-match histories, or sticky incorrect results.
- 3.2 Motivation: Authenticating individual persisted objects is insufficient when adversaries can influence object selection or suppress reads without a monotonic version timeline and provenance checks.
- 3.2 Motivation: Transport, storage-layer, and application-layer protections each leave PKVS-specific gaps involving rollback, derived state, freshness, consistency, or server-side indexing.
4 Approach
ANCHOR co-designs cryptographic protection with LSM-KVS semantics, making the manifest the authenticity root and requiring provenance for volatile state. A trusted mediator verifies persistence and asynchronous I/O completions before use while untrusted caches and accelerators remain non-authoritative.
- Version-bound authenticated persistence: The manifest/version set roots authenticity by binding persisted objects and cached bytes to the evolving logical state.An object is valid only when it authenticates as part of the currently installed version.
- Version-bound authenticated persistence: WAL segments use streaming-friendly authentication, while SSTables use block-granular authentication bound to their file and referencing version descriptor.The granularity choice matches append-only WAL writes and block-based SSTable reads.
- Version-bound authenticated persistence: Manifest freshness uses an append-only evolution rule so rollback and forks become detectable violations of the PKVS timeline.The trusted mediator can retain a latest anchor for the version descriptor.
- Constrained in-memory execution: Caches, filters, and indexes are untrusted hints: cache entries require provenance, while unauthenticated filters and indexes may prune nothing.This converts poisoned cache entries into safe misses and prevents false negatives from non-authoritative derived state.
- Performance reconciliation: The OS or helper threads can submit asynchronous I/O, but a trusted mediator alone admits completed data into usable PKVS state.Batching and pipelining are intended to reduce enclave transitions while preserving verify-before-use.
5 Discussion
The discussion identifies open co-design questions for making artifact-aware protection, trusted admission, asynchronous verification, and compaction scalable under partial trust.
- Open co-design questions: ANCHOR needs cost models to choose authentication and commitment granularities under workload skew and compaction intensity.The open choices include per-record versus per-chunk authentication and per-block versus per-file commitments.
- Open co-design questions: Trusted admission must minimize provenance metadata that blocks stale or poisoned derived state without making the mediator an elasticity bottleneck.The question concerns admission at scale rather than merely validating individual cache entries.
- Open co-design questions: Enclave-friendly asynchronous verification must use batching and split-phase I/O to reduce enclave transitions while preserving verify-before-use.This targets the tension between high-throughput asynchronous submission and trusted completion admission.
- Open co-design questions: Compaction may need to be offloaded outside the trusted boundary while still producing files consistent with the version-evolution contract.The unresolved issue is verifiable consistency under partial trust.
6 Conclusion
ANCHOR’s conclusion centers end-to-end security on PKVS evolution: persistent artifacts are version-bound, volatile structures require verified provenance, and a small mediator admits verified state. The vision leaves cost, provenance scaling, enclave-friendly verification, and trusted compaction as next steps.
- Conclusion: ANCHOR binds WAL, SSTable, and manifest integrity to a version-evolution timeline and treats the manifest as the authenticity root.This is the persistence-side basis for detecting rollback and mix-and-match states.
- Conclusion: Caches and derived metadata remain untrusted hints until provenance is verified by the trusted mediator.The mediator enforces verify-before-use while asynchronous I/O supports disaggregated operation.
- Conclusion: Next steps are to quantify protection costs, minimize provenance state, support enclave-friendly verification, and offload compaction without breaking version evolution.These items define the vision’s unresolved implementation and evaluation boundaries.