{"id":"36e6a7a9-b1ae-4530-83a9-748ca546739d","arxiv_id":"2501.03118","paper_version":1,"verdict":"CONDITIONAL","confidence":"HIGH","novelty_score":3.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":0,"one_line_summary":"A survey that categorizes SGX-based trusted key-value stores into reusable design modules and classifies them by data structure, security, and communication strategies.","lead":"This paper surveys key-value store systems that use Intel SGX trusted execution environments to protect confidential data. It organizes dozens of systems into a modular architecture so designers can see common strategies for balancing security and performance.","discovery_kind":"review","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Survey's central generalization is only as strong as its unstated search protocol; the ten-system list appears self-selected, so completeness and the 'no SCA mitigations in any surveyed KVS' claim are not independently established.","rationale":"The reader's verdict is CONDITIONAL with high confidence, and my stress-test pass agrees. The most load-bearing premise is indeed the completeness and accuracy of the ten-system corpus. The paper's own text asserts rather than demonstrates this premise: Section 3 says 'All the existing TEE-based KVSs we could survey leverage Intel SGX' but does not describe a systematic search protocol. The architecture in Section 4 and the negative SCA claim in Sections 3 and 7 are induced from that corpus. A missing TrustZone- or SEV-based KVS, or an SGX KVS excluded by the vague 'no optimization' criterion, would not make the modular taxonomy wrong for the systems actually studied, but it would make the title- and abstract-level 'TEE-based KVS' generalization too strong. This is an addressable methodological weakness rather than an internal contradiction, so conditional acceptance with a request for a search protocol and per-system verification is the right posture. The paper does provide a useful modular decomposition and cites concrete systems, but the completeness claim needs independent confirmation before the survey can be read as a comprehensive state of the art.","tokens_in":29920,"tokens_out":8464,"duration_ms":81414,"concrete_test":"Run a reproducible literature search, e.g., TITLE-ABS-KEY(('key-value store' OR 'KV store') AND ('SGX' OR 'TrustZone' OR 'SEV' OR 'TEE' OR 'enclave')) on DBLP and Google Scholar for 2015-2025, filter with the paper's own exclusion criteria, and compare the recall set against Table 3; for any candidate not listed, verify from its primary source whether it is a TEE-based NoSQL KVS and whether it implements SCA mitigations. If such a candidate exists, the Section 3 completeness claim and the 'none of the surveyed KVSs implemented SCA mitigations' claim in Sections 3 and 7 are falsified; if not, the concern is resolved.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The paper's central taxonomy (Section 4) and its negative result that 'none of the surveyed SGX-based KVSs implemented SCA mitigations' (Sections 3 and 7) both rest on a completeness and accuracy premise that the manuscript never tests. Section 3 states 'All the existing TEE-based KVSs we could survey leverage Intel SGX' and then lists ten systems, but there is no systematic search protocol, no database or query description, and no explicit inclusion or exclusion criteria beyond excluding SQL engines and 'general-purpose frameworks' such as Scone, Gramine, Haven, Panoply, and SGX-LKL. Because the definition of a 'novel design' is qualitative, the list is effectively self-selected: any omitted SGX KVS can be rationalized as a framework or out of scope, and any TrustZone or SEV-SNP KVS can be rationalized by the claim that none exist. This matters because Section 4's 'typical architecture' is induced from these ten systems; if even one additional TEE-based KVS exists outside the set, the taxonomy's completeness and the abstract-level generalization to 'TEE-based KVSs' are unestablished. The claim is not internally inconsistent, but it is currently an assertion about the literature rather than a demonstrated survey result.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","summary":"The manuscript is a survey of trusted-execution-environment-based key-value stores, focusing on Intel SGX systems. It provides background on TEEs and SGX, proposes a modular architecture for SGX-based KVSs (data structure, disk access, networking, synchronization, and security modules), classifies ten surveyed systems according to data access, security, and communication criteria, and discusses side-channel attacks and mitigations. The central claims are that all surveyed TEE-based KVSs use Intel SGX, that they share a common modular design strategy, and that none of the surveyed systems implements side-channel mitigations.","tokens_in":30176,"tokens_out":5830,"duration_ms":52160,"significance":"If the survey's coverage is accepted, it is a useful reference: the modular decomposition in Section 4 is a practical organizing device, Tables 4-6 condense the design space of SGX-based KVSs, and the observation that no surveyed system implements SCA mitigations is a sharp, falsifiable statement about the state of the art. The paper is strongest in its accurate, well-cited descriptions of SGX mechanics and of individual systems such as Speicher, Avocado, and ShieldStore. The main limitation is that the completeness of the surveyed set is asserted rather than demonstrated, which tempers the force of the survey-level generalizations.","major_comments":[{"comment":"The survey's central completeness claim is not backed by a systematic method. The text states 'All the existing TEE-based KVSs we could survey leverage Intel SGX' and then lists ten systems, but no search protocol, database names, query terms, date range, or explicit inclusion/exclusion criteria are given. The exclusions named (SQL engines and frameworks such as Scone, Gramine, Haven, Panoply, and SGX-LKL) are qualitative, so the set is effectively self-selected. Since Section 4's 'typical architecture' and Section 7's claim that none of the surveyed KVSs implemented SCA mitigations are inductions over this set, the paper should either add a methodology subsection with reproducible search and screening steps or soften the generality claims accordingly.","section":"Section 3, first paragraph"},{"comment":"The legend of Table 1 is self-contradictory: it defines both 'full support' and 'partial support' with the same symbol (✓). This matters because the prose immediately uses the table to conclude that TrustZone lacks reliable integrity/freshness and built-in remote attestation, while the table's check marks suggest support. Use distinct symbols or a separate column, and ensure the table entries match the prose.","section":"Section 2.1.2, Table 1"},{"comment":"The data-separation classification is inconsistent with Section 4.1.1. Table 5 states that index structures are kept inside the enclave for all systems except VeritasDB [108] and Concerto [10], but Section 4.1.1 says ShieldStore [66] keeps the entire hash table outside the enclave. ShieldStore should be listed as another exception, or Section 4.1.1 should be corrected. This is a concrete accuracy issue in a central classification table.","section":"Section 5.2.1, Table 5"},{"comment":"The synchronization classification needs clarification. Section 4.4 claims that because enclaves prevent misbehavior, only CFT protocols are needed, and Table 6 classifies Tiks [116] under Raft. However, the cited reference [116] is titled 'Engraft: Enclave-guarded Raft on Byzantine faulty nodes,' which indicates the system is explicitly designed for Byzantine node failures. The survey should reconcile the CFT claim with the cited system's Byzantine-fault-tolerance setting, and should use one consistent name for the system (Tiks vs. Engraft).","section":"Section 4.4 / Table 6"}],"minor_comments":[{"comment":"The 'Adaptation to SGX' paragraph for Speicher contains the self-reference 'as described in 4.1.3: Adaptation to SGX'; it should refer to the corresponding discussion for Avocado in Section 4.1.2 or restate the partitioning design explicitly.","section":"Section 4.1.3"},{"comment":"There are several language and typographical issues: 'On the same way than' in Section 4.3, 'TWo' capitalization in Section 4.3, 'Precursor also leverages uses a hash table put prefer to keep' in Section 5.1, and 'physcial' in Section 7. These should be corrected in a thorough copyedit.","section":"Sections 4.3, 5.1, and 7"},{"comment":"The name 'OBFUSCURO' is spelled inconsistently as 'OBFUSCRO' later in the same paragraph; use one spelling consistently.","section":"Section 6.2.2"},{"comment":"The 'Open source' row for SGX is marked ✓, but the text does not clarify whether this refers to the SDK, the driver stack, or the hardware/firmware implementation; a brief clarification would improve the comparison.","section":"Section 2.1.2, Table 1"}],"recommendation":"major_revision","confidential_remarks":"The main revision burden is methodological: the authors need to add a reproducible search protocol and fix the internal inconsistencies in Tables 1 and 5 and in the synchronization classification. I do not see a fundamental flaw in the survey's approach, and I would be willing to review a revised version."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"This survey is worth reading if you work on TEE-backed storage. The modular decomposition—data structure, disk access, networking, synchronization, security—is a genuinely useful way to organize the SGX-based KVS literature, and the classification tables give a quick map of design choices. The authors also do a solid job explaining SGX background, the EPC/page-swap tradeoff, and the side-channel landscape, including volume attacks. I came away with a clear picture of how ShieldStore, Speicher, Avocado, Treaty and the rest differ.\n\nThe main weakness is the completeness claim. Section 3 says \"All the existing TEE-based KVSs we could survey leverage Intel SGX\" and then lists ten systems, but the paper never describes how those ten were found. There is no search protocol, database, query, or explicit inclusion/exclusion criteria beyond excluding SQL engines and \"general-purpose frameworks\" like SCONE and Gramine. Because \"novel design\" is qualitative, the list is effectively self-selected. That matters less for the taxonomy itself—ten systems are enough to induce the modules—but it undermines the stronger statements that all TEE KVSs do X and that none implement SCA mitigations. Those are statements about the surveyed set, not about the literature.\n\nOther issues are smaller. The abstract says TEE-based KVSs, but the body only covers SGX; TrustZone and SEV are mentioned only in the TEE comparison. Table 1's caption says the same checkmark symbol means full and partial support, which is a copy-paste error that should be fixed. The SGX background is mostly accurate, though Table 1's claim that TrustZone has no encryption is a bit peremptory given the variation in TrustZone implementations.\n\nNone of this is load-bearing. A survey can be useful without being exhaustive, and the authors are honest about what they surveyed. A revision with a short methodology paragraph, precise scope claims, and a corrected Table 1 would be solid.\n\nI'd send this to a serious referee. The taxonomy is a real contribution to a small but active subfield, and the SCA discussion gives a fair state of play.","headline":"Useful modular synthesis of SGX-based KVS designs, but the 'all existing TEE KVSs' completeness claim is unsupported by the paper's methodology.","tokens_in":30652,"tokens_out":1886,"would_cite":true,"duration_ms":18915,"reading_group":"maybe","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"Every surveyed TEE key-value store fits one five-module architecture","keywords":["Trusted Execution Environment","Intel SGX","key-value store","enclave","side-channel attack","confidential computing","survey taxonomy"],"falsifier":"Locating a published TEE-based key-value store that runs on ARM TrustZone or AMD SEV, or one whose architecture cannot be mapped onto the five modules (e.g., a system that keeps no trusted integrity root inside the enclave), would refute the survey's central claim; the same holds if a source-level study shows that one of the ten systems actually departs from the described module split.","tokens_in":29763,"feed_emoji":"🔐","tokens_out":8244,"duration_ms":65916,"temperature":0.7,"pith_summary":"This paper surveys ten key-value stores that protect data with a Trusted Execution Environment (TEE), a CPU feature that runs code in an isolated enclave. It argues that, despite different designs, all of them follow the same modular architecture: a data-structure module, a disk-access optimization module, a networking module, a synchronization module, and a security module that spans the others. It further finds that every surveyed system runs on Intel SGX's client version, keeps small sensitive metadata inside the enclave, encrypts bulk data outside, and avoids costly context switches with user-space I/O stacks. The survey also reports that none of the ten implements side-channel attack mitigations, leaving them vulnerable to leakage even with SGX protection. The value of the survey is a shared vocabulary and classification that future TEE-based key-value store designers can use to compare and position their systems.","feed_headline":"Secure key-value stores all fit one five-module design","feed_subtitle":"Metadata stays in the enclave, bulk data is encrypted outside, and none block side-channel leaks.","key_machinery":"The load-bearing object is a five-module reference architecture for TEE-based key-value stores, introduced in Section 4. The modules are: the KVS data structure module, which determines what lives inside versus outside the enclave; the disk access and networking optimization modules, which eliminate enclave-exiting syscalls via user-space drivers; the synchronization module, which runs crash-fault-tolerant consensus inside the enclave so that Byzantine behavior is excluded by construction; and the security module, which extends enclave confidentiality and integrity to external data through encryption, Merkle trees, hash chains, counters, and operation IDs. The architecture does the work of a taxonomy: it enables the paper's classifications by data structure, security method, and communication technique, and it exposes the invariant that all ten systems keep a small trusted core inside the enclave and protect a large untrusted exterior cryptographically.","core_discovery":"The paper's central claim is that TEE-based key-value stores are not one-off designs but instances of a common architecture. Each system can be decomposed into a KVS data structure module (hash table, skip list, or log-structured merge tree), a disk access optimization module, a networking optimization module, a synchronization module for distributed stores, and a transverse security module. Across this sample, the authors observe three recurring strategies: sensitive metadata such as keys, pointers, hashes, and encryption keys stays inside the enclave; bulk data such as values and SSTables is encrypted outside the enclave with integrity rooted in an in-enclave Merkle root or MAC key; and I/O is made exitless through asynchronous syscalls or user-space driver kits (SPDK for storage, DPDK for networking) to avoid the 5.5x cost of SGX context switches. The paper also claims that all surveyed systems rely on the client version of Intel SGX, which offers physical-attack integrity protection but only 128 MB of secure memory, and that none of them applies side-channel mitigations.","pith_inferences":["Editorial inference: the modular architecture may generalize beyond key-value stores; applying the same five-module checklist to TEE-based SQL databases could show whether the pattern is specific to KVSs or common to all enclave-backed storage.","Editorial inference: the absence of side-channel mitigations leaves an obvious design niche: an SGX-based key-value store that layers one of the documented mitigations (e.g., padding query results or data-location randomization) onto the modular architecture while keeping overhead practical.","Editorial inference: the paper's reliance on client SGX suggests a concrete test for the taxonomy's limits: if a production TEE-based key-value store built on ARM TrustZone or AMD SEV appears, the claim that all such stores leverage Intel SGX would need revision.","Editorial inference: the taxonomy predicts that index placement is a central performance-security trade-off; systems that keep the index in the enclave should pay more secure-memory cost but less per-access authentication overhead than systems like VeritasDB that keep it outside."],"forward_implications":["Designers of future TEE-based key-value stores get a ready-made comparison checklist: data structure choice, disk access strategy, networking strategy, synchronization protocol, and security mechanisms.","The finding that all surveyed stores run on client SGX means the field's optimizations are tailored to a 128 MB secure memory; a shift to Scalable SGX or another TEE would change which optimizations matter.","Since none of the ten systems applies side-channel mitigations, the surveyed stores are exposed to page-fault, cache, and volume leakage attacks that can reveal key-value pairs even though the enclave itself is intact.","Enclave-resident consensus in distributed stores turns Byzantine fault tolerance into crash fault tolerance, reducing the required replica count from 3f+1 to 2f+1 nodes.","With Intel deprecating SGX monotonic counters, the freshness of persisted data in future systems will likely depend on software counters, hash chains, or operation IDs, the methods the survey documents."],"supporting_citations":[{"why":"Defines Intel SGX's enclave model, EPC memory layout, Merkle hash tree, and context-switch costs that motivate the surveyed design strategies.","marker":"[34]"},{"why":"ShieldStore supplies the hash-table instance that keeps encrypted KV pairs outside the enclave with a Merkle root and keys inside.","marker":"[66]"},{"why":"Speicher is the pioneering LSMT-based SGX KVS, contributing in-enclave SPDK, per-level Merkle trees, and the asynchronous monotonic counter.","marker":"[18]"},{"why":"Avocado contributes the distributed skip-list design with in-enclave index, DPDK+RDMA networking, operation IDs, and replication-based availability.","marker":"[19]"},{"why":"Treaty extends the architecture to distributed transactions with 2PC and reuses Speicher's security mechanisms.","marker":"[45]"},{"why":"VeritasDB shows an integrity-focused design that keeps the index outside the enclave and uses Merkle trees plus SGX counters.","marker":"[108]"},{"why":"Precursor supplies the hash-table and operation-ID approach for RDMA-based communication and replay protection.","marker":"[81]"},{"why":"Tweezer contributes the hash-chain and per-SSTable MAC key optimization for LSMT-based stores.","marker":"[64]"},{"why":"eLSM demonstrates applying the enclave module split to existing LSMT stores such as RocksDB and LevelDB.","marker":"[73]"},{"why":"Tiks (Engraft) provides the enclave-guarded Raft synchronization and hash-chain log integrity for distributed stores.","marker":"[116]"}],"fun_headline_variants":["All TEE-based key-value stores share a five-module design","Survey reveals one architecture for all TEE key-value stores","TEE key-value stores: metadata in, bulk out, no side-channel fixes","TEE key-value stores: common design, but side-channel leaks remain"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The load-bearing premise is that the ten surveyed systems are a complete and accurate picture of TEE-based key-value stores; if a TEE-based key-value store built on a different TEE exists, or if any one system is mischaracterized, the survey's taxonomy and its 'all use Intel SGX' finding would not hold.","fun_headline_variants_meta":{"raw":{"variants":["All TEE-based key-value stores share a five-module design","Survey reveals one architecture for all TEE key-value stores","TEE key-value stores: metadata in, bulk out, no side-channel fixes","TEE key-value stores: common design, but side-channel leaks remain"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000571,"raw_usage":{"total_tokens":2722,"prompt_tokens":991,"completion_tokens":1731,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":607,"completion_tokens_details":{"reasoning_tokens":1654}},"tokens_in":607,"tokens_out":1731,"duration_ms":13279,"temperature":1.0,"reasoning_tokens":1654,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-10T21:52:15.476395+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Locating a published TEE-based key-value store that runs on ARM TrustZone or AMD SEV, or one whose architecture cannot be mapped onto the five modules (e.g., a system that keeps no trusted integrity root inside the enclave), would refute the survey's central claim; the same holds if a source-level study shows that one of the ten systems actually departs from the described module split.","supporting_citations":[{"cited_title":"In: Proceedings of the 22nd International Middleware Conference: Indus- trial Track, p","cited_arxiv_id":null,"evidence_quote":"eLSM demonstrates applying the enclave module split to existing LSMT stores such as RocksDB and LevelDB."},{"cited_title":"In: Proceed- ings of the 2022 ACM SIGSAC Conference on Computer and Communications Security, p","cited_arxiv_id":null,"evidence_quote":"Tiks (Engraft) provides the enclave-guarded Raft synchronization and hash-chain log integrity for distributed stores."}],"review_version":1}