George Lambert
4fcbb9ac95
Some checks are pending
ci / markdown (push) Waiting to run
Open with an executive summary that HIPAA, SOC 2, and ISO 27001 are organizational programs. Verae DataCubes supply store, communicate, timestamp, verify, and audit tools for the technical portion only. Chapters cover transit (HPKE, visible routing), rest (IPFS/Peergos hash-verified restore), receipts, EU Peergos evaluations (Cure53 2019, ROS 2024), cross-blockchain timestamping, and write-once Iceberg archive. PDF is branded with the Verae logo top-left and Verae Inc contact in the footer; last chapters are sourced bios for Garfinkel (FINRA CRD 5052743), Haber, and Lambert.
110 lines
4.7 KiB
ReStructuredText
110 lines
4.7 KiB
ReStructuredText
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.
|