All Research Tracks
R05 · Security & Privacy

Oblivious Query Execution for Multi-Tenant Deployments

Even with proper access controls, access pattern leakage can reveal sensitive cross-tenant information in shared hosting. Traditional ORAM is expensive, but SkeinDB's architecture — ValueStore with content-addressed lookup and LSM organization — may enable more efficient oblivious execution strategies tailored specifically to database workloads.

Research Proposal — Mapped to backlog in docs/RESEARCH_BACKLOG.md

🔬 What's Novel

🔧 Technical Approach

Phase 1 — Threat Model

Formalize the multi-tenant adversary model: an attacker can observe I/O patterns, timing, and memory access patterns (side channels) to infer sensitive information about co-tenant queries.

Phase 2 — Pattern Analysis

Characterize SkeinDB's access patterns per query type. Identify which patterns leak information and which are inherently obfuscated by content-addressing.

Phase 3 — Oblivious Primitives

Build oblivious ValueStore lookup (padding + dummy accesses), oblivious index traversal (oblivious sorting), and oblivious scan operations (deterministic padding).

Phase 4 — Tiered System

Policy-based obliviousness levels per table/column. The system auto-applies the appropriate protection level, from full ORAM for highly sensitive data to minimal padding for public tables.

🧪 Hypotheses

H1

Database-specific access patterns can be protected more efficiently than generic ORAM because they exhibit structural regularity.

H2

ValueStore content-addressing provides inherent obfuscation; targeted padding can achieve formal obliviousness guarantees.

H3

Tiered obliviousness (stronger for sensitive data, weaker for public) provides practical security-performance tradeoffs.

🔗 SkeinDB Integration

ValueID Store
LSM / Compaction
SkeinQL RPC
Multi-Tenant Isolation
Access Control

📚 Key References