The Verae DataCube Server Solution ================================== Purpose ------- A Verae DataCube Server Solution is the on-premises or customer-hosted assembly that gives an organization a place to put sensitive digital objects, a way to move them, a way to prove when they first existed, and a way to show an examiner that the bits have not been silently rewritten. It is a **server solution** in the sense that an organization runs (or has run for it) a set of cooperating services: encrypted storage, a message fabric, a public-key directory, a timestamping link to Verae's central service, and an archival export path. It is not a single binary, and it is not a cloud folder with a padlock icon. The DataCube as a container --------------------------- A **DataCube** is a customer-controlled container for digital objects and for the metadata that makes those objects examinable. Typical contents include: * the object bytes (a message body, a document, an image, a log extract, an AI prompt and completion, or any other digital media); * **private metadata** that the organization needs but does not necessarily share (internal identifiers, matter numbers, legal-hold flags); * **attached files** that travel with the object; * an **internal chain** of hashes so that the cube itself has a history --- each new write names the previous write. Verae's public product description is consistent with this split: records stay in **storage the customer controls**; Verae seals a **fingerprint**. The server solution is the machinery that makes that split operational rather than rhetorical. Two information states, one operational picture ----------------------------------------------- Classical security training divides information into **data in transit** and **data at rest**. The DataCube Server Solution is built around that division. **In transit**, the problem is an untrusted network. Messages must be readable at the destination and nowhere else along the path, yet the path must still be able to deliver them. Chapter 4 treats that problem in full: point-to-point encryption, visible routing, honest-but-curious brokers. **At rest**, the problem is an untrusted disk, an untrusted backup operator, and an untrusted replica. Bytes must be stored so that a host who does not hold keys sees opaque blocks, and so that a restore can prove it brought back the same blocks that were written. Chapter 5 treats that problem in full: IPFS content-addressed ciphertext, Peergos hash verification, tamper-evident restore. A third problem sits beside those two: **time**. Storage and transit prove confidentiality and integrity of *what* was stored or sent. They do not, by themselves, prove *when* it first existed, or that a later rewrite is not being offered as the original. Timestamped receipts (Chapter 6) and the cross-blockchain timestamping architecture (Chapter 8) address that. What "server" means in practice ------------------------------- In a typical deployment the organization runs, or links: * a **Peergos** instance (or equivalent cryptree client) that writes encrypted, content-addressed blocks; * an **IPFS** layer that stores and replicates those blocks by hash; * a **message fabric** (NATS in the reference deployment) that carries HPKE-sealed bodies with destinations in the clear; * a **public-key directory** so every endpoint can find every other endpoint's encryption key without a private-key leak; * an **organizational timestamping node** that either syncs with Verae's central timestamping server or is linked to it; * an **admin-history** cube that records configuration changes as previous state, new state, and diff; * an **Iceberg write-once export** that takes cubes out of any single party's delete path (Chapter 9). Each of those pieces can be drawn on a whiteboard in an audit interview. Each of them also has a failure mode that the organization's procedures must name: lost keys, a mis-issued directory entry, a broker that drops messages, a replica that serves a wrong block (detected by hash), a timestamping link that is down, an archive job that did not run. What the server solution is not ------------------------------- It is not a substitute for workforce training. It is not a substitute for a Business Associate Agreement analysis. It is not a substitute for access reviews. It is not, by itself, "the HIPAA control set" or "the SOC 2 system." It is the **technical substrate** on which those controls can be implemented with less faith in honest administrators and more reliance on hashes, receipts, and keys the customer holds. The following four chapters unpack the substrate: transit, rest, receipts, and the European evaluations of the Peergos storage layer.