diff --git a/README.md b/README.md index 73eaae8..578f74d 100644 --- a/README.md +++ b/README.md @@ -1,62 +1,46 @@ # Making yourself audit-ready with Verae DataCubes -How to **prepare an organization** for HIPAA-aligned, SOC 2, or ISO 27001 -work using Verae DataCubes on **Peergos** (encrypted cryptree + hashed -IPFS) and HPKE on an **untrusted NATS** broker. +**Software alone does not make an organization HIPAA certified, +SOC 2 attested, or ISO 27001 certified.** -**This repository is not a HIPAA, SOC 2, or ISO certificate.** -Peergos’s public pentests are **not** your Type II or ISO registrar -certificate. They are **component security evaluations** you can attach. +The Verae DataCube Solution gives you tools to **store**, +**communicate**, **timestamp**, **verify**, and **audit**. To +obtain those certifications and attestations, the organization +still has to write **policies**, run **procedures**, operate +**internal controls**, and sit with an **independent auditor**. +Verae provides the tools, the background, and the software +infrastructure for the **technical portion** of that work. -## What we verified about Peergos (EU) +A Verae DataCube Server Solution provides secure communications +and storage for **data in transit** and **data at rest**: +point-to-point encryption (routing remains visible), IPFS +content-addressed encryption at rest with Peergos hash +verification, global timestamped receipts, and a write-once +Iceberg archive. -Full sources: [`PEERGOS-VERIFICATION.md`](PEERGOS-VERIFICATION.md). +Peergos was independently evaluated **twice in Europe** (Cure53, +Berlin, 2019; Radically Open Security, Amsterdam, 2024). Those +reports are public component evaluations. They are **not** a +HIPAA, SOC 2, or ISO certificate. -| Fact | Verified? | -|---|---| -| Encrypted client-side filesystem (cryptree); keys not on the storage server | Yes — Peergos book + Cure53 design review | -| IPFS blocks content-addressed; Peergos verifies hashes (tamper-evident restore) | Yes — [trust-free layers](https://book.peergos.org/security/trust.html) | -| Independent **EU** security audits, reports published | **Yes — two:** Cure53 **Berlin** (2019); Radically Open Security **Amsterdam** (2024, NLnet; EU Horizon 2020 NGI-POINTER mentioned on the post) | -| “Peergos is HIPAA/SOC 2/ISO certified” | **No.** Those audits are pentest/code/design reviews, not management-system certificates | +## Document -So: Peergos **was designed as a trust-minimized encrypted filesystem**, -**evaluated in Europe** by two specialist firms, with **public reports**. -That supports the **at-rest / backup** story. It does **not** finish -*your* audit. - -## Architecture (audit interview in one page) +Sphinx sources in `source/`. Each chapter starts on a new page +in the PDF. The Verae wordmark is at the top left of every page; +Verae Inc contact is in the footer. Last chapters are +biographies of James H. Garfinkel (FINRA CRD 5052743), Stuart +Haber, and George Lambert. ``` -Endpoint (keys stay here / HSM) - │ HPKE content (NPE suite) - │ routing: dest + subject in the clear - ▼ -Untrusted NATS (cannot read bodies) - │ - ▼ -Verae DataCube chain (append-only hashes) - │ written through Peergos client - ▼ -Peergos cryptree (encrypted names, sizes, graph) - │ chunks → CID / hash - ▼ -IPFS (distributed, hash-verified ciphertext) +make html +make latexpdf ``` -- **At rest:** Peergos cryptree + IPFS. Hosts with disk/backup see - **opaque hashed ciphertext**, not PHI, if they lack keys. -- **In transit (NATS):** HPKE-Base to directory public keys. Broker is - honest-but-curious: destinations yes, bodies no. -- **Integrity:** cube JSONL chain + dual hash + IPFS CID check on - restore (re-fetch blocks, re-verify hashes — not a plaintext tape). +* HTML: `build/html/index.html` +* PDF: `build/latex/peergos-making-yourself-audit-ready-with-verae-datacubes.pdf` +* Published: https://docs.pfc.georgelambert.org/audit-ready/ -## BAAs / DPAs - -Ciphertext-without-keys **narrows** who is a Business Associate or -GDPR processor for **content**. It does **not** automatically delete -contracts for VMs, usernames, or logs. See [`BAA-DPA.md`](BAA-DPA.md). - -## Pack +## Pack (Markdown companions) | File | Use | |---|---| @@ -66,23 +50,6 @@ contracts for VMs, usernames, or logs. See [`BAA-DPA.md`](BAA-DPA.md). | `HOWTO.md` | How to hand this to an auditor | | `MODULE.md` | Callers / non-runtime | -Live technical surfaces (ns1): https://pfc.georgelambert.org/health · -https://pfc.georgelambert.org/v1/npe/keys · -https://docs.pfc.georgelambert.org/controls.html +## Related -Related: https://git.georgelambert.org/marchon/system-git-sync - -## Sphinx (HTML + LaTeX PDF) - -Sources live in ``source/`` (Sphinx). Build: - -``` -make html -make latexpdf -``` - -* HTML: ``build/html/index.html`` -* PDF: ``build/latex/peergos-making-yourself-audit-ready-with-verae-datacubes.pdf`` - -LaTeX companion links are **relative PDFs** (not Markdown). Live HTML: -https://docs.pfc.georgelambert.org/audit-ready/ +https://www.verae.com · https://git.georgelambert.org/marchon/system-git-sync diff --git a/build/html/_images/VeraeFullLogo.png b/build/html/_images/VeraeFullLogo.png new file mode 100644 index 0000000..4c011e8 Binary files /dev/null and b/build/html/_images/VeraeFullLogo.png differ diff --git a/build/html/_static/VeraeFullLogo.png b/build/html/_static/VeraeFullLogo.png new file mode 100644 index 0000000..4c011e8 Binary files /dev/null and b/build/html/_static/VeraeFullLogo.png differ diff --git a/build/html/_static/alabaster.css b/build/html/_static/alabaster.css index 7e75bf8..8f0f067 100644 --- a/build/html/_static/alabaster.css +++ b/build/html/_static/alabaster.css @@ -11,7 +11,7 @@ body { div.document { - width: 940px; + width: 980px; margin: 30px auto 0 auto; } @@ -21,11 +21,11 @@ div.documentwrapper { } div.bodywrapper { - margin: 0 0 0 220px; + margin: 0 0 0 240px; } div.sphinxsidebar { - width: 220px; + width: 240px; font-size: 14px; line-height: 1.5; } @@ -45,7 +45,7 @@ div.body > .section { } div.footer { - width: 940px; + width: 980px; margin: 20px auto 30px auto; font-size: 14px; color: #888; @@ -502,8 +502,12 @@ a.footnote-reference:hover { a:hover tt, a:hover code { background: #EEE; } +div.sphinxsidebar { + position: fixed; + margin-left: 0; +} -@media screen and (max-width: 940px) { +@media screen and (max-width: 980px) { body { margin: 0; @@ -523,7 +527,8 @@ a:hover tt, a:hover code { display: block; float: none; width: unset; - margin: 50px -30px -20px -30px; + margin: -20px -30px 20px -30px; + position: static; padding: 10px 20px; background: #333; color: #FFF; diff --git a/build/html/_static/documentation_options.js b/build/html/_static/documentation_options.js index 7e4c114..7d7add3 100644 --- a/build/html/_static/documentation_options.js +++ b/build/html/_static/documentation_options.js @@ -1,11 +1,11 @@ const DOCUMENTATION_OPTIONS = { - VERSION: '', + VERSION: '2026.09', LANGUAGE: 'en', COLLAPSE_INDEX: false, BUILDER: 'html', FILE_SUFFIX: '.html', LINK_SUFFIX: '.html', - HAS_SOURCE: true, + HAS_SOURCE: false, SOURCELINK_SUFFIX: '.txt', NAVIGATION_WITH_KEYS: false, SHOW_SEARCH_SUMMARY: true, diff --git a/build/html/_static/verae.css b/build/html/_static/verae.css new file mode 100644 index 0000000..9569f89 --- /dev/null +++ b/build/html/_static/verae.css @@ -0,0 +1,47 @@ +/* Verae branded Sphinx HTML */ +body { + font-family: "Source Serif 4", "Georgia", serif; + color: #111; +} +div.document { + padding-top: 0.5em; +} +div.sphinxsidebar h3, div.sphinxsidebar h4 { + color: #5B2C8B; +} +div.body h1, div.body h2, div.body h3 { + color: #5B2C8B; +} +div.related { + background: #1A0A24; + color: #fff; +} +div.related a { + color: #e8d7f5; +} +div.footer { + background: #1A0A24; + color: #e8d7f5; + padding: 1.1em 1.5em; + margin-top: 2em; +} +div.footer a { + color: #d7b8f0; +} +.verae-page-footer { + border-top: 2px solid #5B2C8B; + margin-top: 2.5em; + padding-top: 0.8em; + font-size: 0.9em; + color: #5B2C8B; +} +div.sphinxsidebarwrapper img.logo, +img.logo { + background: #1A0A24; + padding: 8px; + border-radius: 4px; + max-width: 100%; +} +.admonition.important, .admonition.warning, .admonition.note { + border-left: 4px solid #5B2C8B; +} diff --git a/build/html/architecture.html b/build/html/architecture.html index e199add..a02de18 100644 --- a/build/html/architecture.html +++ b/build/html/architecture.html @@ -5,17 +5,19 @@ - Architecture (audit interview) — Making yourself audit-ready with Verae DataCubes + 10. Architecture for an audit interview — Making yourself audit-ready with Verae DataCubes - - + + + + - - + + @@ -24,58 +26,24 @@ - - -
-
-
- - -
- -
-

Architecture (audit interview)

-
Endpoint (keys stay here / HSM)
-    │  HPKE content (NPE suite)
-    │  routing: dest + subject in the clear
-    ▼
-Untrusted NATS (cannot read bodies)
-    │
-    ▼
-Verae DataCube chain (append-only hashes)
-    │  written through Peergos client
-    ▼
-Peergos cryptree (encrypted names, sizes, graph)
-    │  chunks → CID / hash
-    ▼
-IPFS  (distributed, hash-verified ciphertext)
-
-
-
    -

  • At rest: Peergos cryptree + IPFS. Hosts with disk/backup see -opaque hashed ciphertext, not PHI, if they lack keys.

    • -

  • In transit (NATS): HPKE-Base to directory public keys. Broker is -honest-but-curious: destinations yes, bodies no.

    • -

  • Integrity: cube JSONL chain + dual hash + IPFS CID check on -restore (re-fetch blocks, re-verify hashes — not a plaintext tape).

    • -
-

NATS remains an untrusted router. Production E2E is NPE/HPKE. -Passthrough means destination in the clear; the body is ciphertext.

-

Live: https://pfc.georgelambert.org/v1/npe/keys (public keys only). -Controls: https://docs.pfc.georgelambert.org/controls.html

-
- - -
- -
-
+
+ +
+
+ + +
+ +
+

10. Architecture for an audit interview

+
+

10.1. The picture

+
Endpoint (private keys stay here / HSM)
+    |  HPKE content (point-to-point)
+    |  routing: destination + subject in the clear
+    v
+Untrusted message fabric (honest-but-curious)
+    |  cannot read bodies; can see dest / subject / size
+    v
+Organizational DataCube
+    |  append-only cube chain (prev + new + diff)
+    |  private metadata, attachments, internal chain
+    v
+Peergos cryptree  (encrypted names, sizes, graph)
+    |  chunks -> CID / hash, hashes verified
+    v
+IPFS  (distributed, content-addressed ciphertext)
+    |
+    +-- Verae timestamping
+    |      fingerprint only -> receipt (time + sequence)
+    |      org server linked to central Verae, or direct sync
+    |
+    +-- Iceberg write-once archive
+           snapshot of cube CIDs, not under single-party delete
+
+
+
+
+

10.2. Walkthrough, in the order an examiner usually asks

+

Where are the keys? On the endpoint or in the customer’s +HSM. Not on the storage host. Not in the public-key +directory (that directory holds public keys only). Not in +the NATS payload.

+

What does the network see? Destination, subject, size, +timing. Not the body. Production algorithm is HPKE, not a +lab construction.

+

What does the disk see? Padded encrypted chunks under +random labels. Peergos verifies hashes. A restore re-fetches +CIDs and re-checks them.

+

How do you prove when it existed? A hash is registered +the first time it is seen. A receipt binds hash, time, and +sequence. The organizational chain and the central Verae +chain cross-verify. Verae is not given the object, only the +fingerprint.

+

How do you stop delete? Live cubes replicate as hashed +ciphertext. Committed snapshots go to an external Iceberg +write-once tier that is specified to sit outside any one +party’s delete control.

+

How do you know the software was not quietly reconfigured? +Configuration is Ed25519-signed. Unsigned files are +rejected. Admin-history records previous state, new state, +and a diff.

+

How do you inspect without turning inspect into a leak? +k-of-n officers. The author of a change is not an officer +on that change. Log-before-reveal.

+
+
+

10.3. Identity planes

+

There are two login planes, and they must not be collapsed +in an interview:

+
    +

  • Drive / Peergos identity — unwraps cubes. This is +the cryptographic identity.

    • +

  • Console identity — TOTP (RFC 6238), session cookie, +admin actions. Google SSO, if present, does not unwrap +cubes.

    • +
+

Mixing those planes is how “we have SSO” becomes “SSO is +the master key.” It is not.

+
+
+

10.4. NATS remains untrusted

+

The reference message fabric is NATS. It is an +honest-but-curious broker. Destinations in the clear are +passthrough, not a bug. Bodies are ciphertext, or the +message is rejected. Error responses carry codes and lookup +identifiers, not payloads.

+

A public-edge NATS listener, if enabled, is token-gated and +is not the same socket the internal services use.

+
+
+

10.5. What to hand the examiner

+
    +

  • this document (HTML or PDF);

    • +

  • the two public Peergos reports, labeled as component +evaluations;

    • +

  • a data-flow diagram of this instance;

    • +

  • the public-key listing (public keys only);

    • +

  • a restore-test ticket;

    • +

  • an admin-history excerpt for a dated change;

    • +

  • the organization’s policies, not Verae’s.

    • +
+

Live technical surfaces (reference instance):

+ +
+
+ + +
+ +
+
+
+
+
+ Verae Inc + · https://www.verae.com + · Book a call at verae.com + · app.verae.com +
+
- ©2026, Verae. + ©2026, Verae Inc. - | - Powered by Sphinx 9.1.0 - & Alabaster 1.0.0 - - | - Page source
+ \ No newline at end of file diff --git a/build/html/baa-dpa.html b/build/html/baa-dpa.html index 5008d26..885e3a3 100644 --- a/build/html/baa-dpa.html +++ b/build/html/baa-dpa.html @@ -5,17 +5,19 @@ - BAAs and DPAs when ciphertext has no host keys — Making yourself audit-ready with Verae DataCubes + 11. BAAs, DPAs, and ciphertext without host keys — Making yourself audit-ready with Verae DataCubes - - + + + + - - + + @@ -24,93 +26,24 @@ - - -
-
-
- - -
- -
-

BAAs and DPAs when ciphertext has no host keys

-

This is guidance for an evidence pack, not legal advice.

-
-

The operator statement

-

Data at rest lives in the encrypted Peergos cryptree. Restore uses -distributed, hash-verified, encrypted IPFS blocks. Hosts and backup -media see opaque blobs (and random CHAMP labels), not filenames, not -PHI, not social graph — if keys never leave the client / customer HSM.

-

That is true of the Peergos design (see Peergos verification (what was actually audited)). -It changes the BAA/DPA conversation. It does not auto-delete the -need for contracts.

-
-
-

HIPAA (US) — Business Associate

-

A Business Associate is a person who creates, receives, maintains, or -transmits ePHI for a covered entity.

-

Technical argument you can make (and should document):

-
    -

  1. ePHI is encrypted before it leaves the endpoint (Peergos client / -DataCube writer).

    2. -

  2. The storage node, IPFS, disk, and backup hold ciphertext + hashes.

    3. -

  3. Private keys do not reside on the storage host (customer HSM / -client). Hash verification detects tampering.

    4. -

  4. Therefore the host cannot maintain ePHI in intelligible form.

    5. -
-

HHS distinguishes conduits and parties that never have access to -ePHI. Many programs still sign a BAA when a vendor touches -infrastructure, because misconfiguration, support exports, or logs could -later expose plaintext. OCR looks at your risk analysis.

-

Practical pack: risk analysis memo citing cryptree + IPFS hash checks -+ key custody; BAA or written determination that the vendor is -not a BA because they cannot decrypt; list every party with -disk/backup (ns1, IPFS cluster, offsite replica).

-
-
-

GDPR (EU/UK) — processor vs technical measure

-

Encrypted data can still be personal data if it is reasonably -attributable (usernames, IPs, invoice identity). GDPR Art. 32 lists -encryption as a security measure.

-

Peergos is designed so the server is an adversary for content and -most metadata. EU-based independent pentests (Cure53 DE, ROS NL) -evaluated that design. Processing location for self-host is your -ns1 / customer region, not peergos.net’s Germany hosting, unless you use -peergos.net.

-

You may still need a DPA (Art. 28) with anyone who processes -personal data (usernames, logs, billing). Ciphertext-only storage -narrows the DPA’s technical annex.

-
-
-

NATS operators

-

NATS is an untrusted broker. Content is HPKE; destinations and -subjects are in the clear. A NATS operator cannot read bodies without -endpoint private keys; can see routing metadata; can drop/delay -copy ciphertext. Treat like a transit provider: DPA/BAA depends on -whether routing metadata is personal data in your jurisdiction.

-
-
-

What “making yourself audit-ready” means

-

You are not buying Peergos’s Cure53/ROS reports as your SOC 2. -You are reusing those public evaluations as vendor/component -assurance, then adding your scope, RoPA, key-custody, inspect k-of-n, -admin-history, instance evidence, and contracts that match who can -actually see plaintext.

-
-
- - -
- -
-
+
+
-
-
+
+
+ + +
+ +
+

11. BAAs, DPAs, and ciphertext without host keys

+

This chapter is guidance for an evidence pack. It is not +legal advice. Counsel has to sign the actual determination.

+
+

11.1. The technical fact

+

Data at rest lives in the encrypted Peergos cryptree. +Restore uses distributed, hash-verified, encrypted IPFS +blocks. Hosts and backup media see opaque blobs (and +random CHAMP labels), not filenames, not PHI, not the share +graph — if private keys never leave the client or the +customer’s HSM.

+

That fact is true of the Peergos design and is the design +Cure53 reviewed in Berlin. It changes the Business +Associate and GDPR-processor conversation. It does not +automatically delete the need for contracts.

+
+
+

11.2. HIPAA — Business Associate

+

A Business Associate is a person who creates, receives, +maintains, or transmits ePHI for a covered entity.

+

A technical argument the organization can document:

+
    +

  1. ePHI is encrypted before it leaves the endpoint.

    2. +

  2. The storage node, IPFS, disk, Iceberg archive, and backup +hold ciphertext plus hashes.

    3. +

  3. Private keys do not reside on the storage host. +Hash verification detects substitution.

    4. +

  4. Therefore the host cannot maintain ePHI in intelligible +form.

    5. +
+

HHS has distinguished conduits and parties that never +have access to ePHI. Many programs still sign a BAA +whenever a vendor touches infrastructure, because +misconfiguration, a support export, or a log could later +expose plaintext. OCR will look at the organization’s +risk analysis, not at Verae’s architecture diagram.

+

Practical pack:

+
    +

  • a risk-analysis memo citing cryptree, IPFS hash checks, +key custody, and the two public Peergos evaluations;

    • +

  • a BAA or a written determination that a named vendor +is not a BA because they cannot decrypt;

    • +

  • a list of every party with disk, VM, backup, IPFS, or +Iceberg credentials.

    • +
+
+
+

11.3. GDPR — processor versus technical measure

+

Encrypted data can still be personal data if it is +reasonably attributable (usernames, IPs, invoice identity). +GDPR Article 32 lists encryption as a security measure, not +as an exemption from Article 28.

+

Peergos is designed so the server is an adversary for +content and most metadata. EU-based independent pentests +evaluated that design. Processing location for self-host +is the customer’s region, not peergos.net’s Germany, unless +the customer uses peergos.net.

+

A DPA may still be required with anyone who processes +usernames, logs, or billing. Ciphertext-only storage +narrows the technical annex. It does not always +eliminate the DPA.

+
+
+

11.4. NATS operators

+

NATS is an untrusted broker. Content is HPKE. Destinations +and subjects are in the clear. A NATS operator cannot +read bodies without endpoint private keys. They can see +routing metadata. They can drop, delay, or copy +ciphertext. Treat them like a transit provider: whether a +DPA or BAA is needed depends on whether routing metadata is +personal data in the relevant jurisdiction.

+
+
+

11.5. Verae as timestamping service

+

If Verae receives only fingerprints, Verae’s role for +content is not “stores the records.” Verae’s role is +“registers hashes and issues receipts.” That is a narrower +processing. Counsel still has to decide whether the +fingerprint, plus whatever account data exists (company +name, billing, operator emails), requires a DPA or a BAA. +Do not let a sales sentence skip that memo.

+
+
+

11.6. Component assurance versus the organization’s report

+

Attaching Cure53 2019 and ROS 2024 is vendor / component +assurance. It is appropriate. It is not the +organization’s SOC 2, ISO 27001, or HIPAA program. Those +still require the organization’s scope, Record of +Processing, key-custody, inspect k-of-n, admin-history, +instance evidence, restore tests, and the contracts that +match who can actually see plaintext.

+
+
+ + +
+ +
+
+
+
+
+ Verae Inc + · https://www.verae.com + · Book a call at verae.com + · app.verae.com +
+
- ©2026, Verae. + ©2026, Verae Inc. - | - Powered by Sphinx 9.1.0 - & Alabaster 1.0.0 - - | - Page source
+ \ No newline at end of file diff --git a/build/html/bio-george-lambert.html b/build/html/bio-george-lambert.html new file mode 100644 index 0000000..6f30dd0 --- /dev/null +++ b/build/html/bio-george-lambert.html @@ -0,0 +1,227 @@ + + + + + + + + 16. George Lambert — Making yourself audit-ready with Verae DataCubes + + + + + + + + + + + + + + + + + + + + +
+ + +
+
+ + +
+ +
+

16. George Lambert

+
+

16.1. Role

+

George Lambert is an Internet technical architect and a +New Hampshire public official. Public candidate listings +(BallotReady) identify him as CTO / Chief Architect, Verae +LLC, from 2019. He is the architect of the DataCube +server side of the solution described in this briefing: +the assembly of encrypted storage, point-to-point messaging, +public-key directory, organizational timestamping link, and +write-once archive that an organization actually runs.

+
+
+

16.2. Internet technical architect, from 1994

+

Lambert’s public account of his engineering work begins in +the earliest days of the commercial Internet, when +shipping an application that could speak TCP/IP was still a +specialist task.

+

In 1994–1995 he was moving through senior application +engineering and sales roles (Terralogics; Serif) at the +moment Borland’s developer tools were being connected to +the public network. He then founded NetMasters LLC +(New Hampshire, formed 1996; he describes the product work +from 1995). At NetMasters he personally designed and +built FastNet Tools — the Internet integration +technology that shipped with Borland’s Delphi and C++ +Builder products.

+

Those tools are the historically important fact. They +enabled a generation of Delphi and C++ Builder developers +to Internet-enable applications as a shipped part of +Borland’s commercial toolchain, not as a research demo. +Lambert’s own summary is that FastNet Tools “enabled +millions of developers to internet-enable their +applications in minutes.” That is the beginning of the +through-line that ends, in this briefing, at a DataCube +server: make the hard network problem a product that +other people can operate.

+

He continued as Vice President of Engineering at +GoldenWare / FlightLookup (from 1995, for two decades +on the public listings), building airline-information +systems, and later as founder of PodKey Solutions +(2004–2010) and as an interim/contract CTO.

+
+
+

16.3. New Hampshire public office

+

Lambert is a Republican from Litchfield, New +Hampshire, born 4 September 1968 in Sanford, Maine +(Wikipedia; Vote Smart).

+
    +

  • Litchfield Board of Selectmen, from 2007 (Vote Smart +lists council of town selectmen, Town of Litchfield, +2007–present on the biography page then current).

    • +

  • New Hampshire House of Representatives: +Hillsborough 27th district, December 2010 – December +2012; Hillsborough 44th district, December 2012 – +December 2014.

    • +

  • Subsequent campaigns for the New Hampshire Senate, +District 18 (2014, 2018, 2020, 2022 Republican primary +winner in several of those cycles).

    • +
+

Vote Smart records a diploma from Pelham High School, +1986; family (wife Rhonda, children); home city +Litchfield. He has also served on the National Grange +Strategic Planning Task Force (1999–2004).

+

His public technical site, https://georgelambert.org/, +describes three decades at the intersection of technology, +governance, and sound money, and repeats the FastNet / +Borland fact as the credential for knowing what scalable +architecture looks like.

+
+
+

16.4. Why this biography is in the briefing

+

The DataCube Server Solution is not only a timestamping +API. It is a running system: keys, brokers, cryptree, +replicas, admin-history, Iceberg export. Lambert is the +person whose public career is the implementation of +Internet integration from the Borland era through to this +server stack, and whose public service is New Hampshire +legislative and municipal office. The biography is here so +that a reader who asks “who architected the server side, +and on what history?” has a sourced answer.

+

It is not a substitute for a pentest, a Type II, or a +restore test. Code either runs or it does not; Lambert’s +own stated ethic. This briefing is the description of what +the code is for, and of what it cannot certify by existing.

+
+
+ + +
+ +
+
+
+
+
+ Verae Inc + · https://www.verae.com + · Book a call at verae.com + · app.verae.com +
+ +
+ ©2026, Verae Inc. + +
+ + + + + + + \ No newline at end of file diff --git a/build/html/bio-james-garfinkel.html b/build/html/bio-james-garfinkel.html new file mode 100644 index 0000000..5d8f7ba --- /dev/null +++ b/build/html/bio-james-garfinkel.html @@ -0,0 +1,246 @@ + + + + + + + + 14. James H. Garfinkel — Making yourself audit-ready with Verae DataCubes + + + + + + + + + + + + + + + + + + + + +
+ + +
+
+ + +
+ +
+

14. James H. Garfinkel

+
+

14.1. Name and sources

+

This chapter summarizes James H. Garfinkel (the spelling on +the FINRA BrokerCheck individual report; also styled Garfinkle +in some informal references). Two public sources were used, as +requested:

+
    +

  • FINRA BrokerCheck, CRD number 5052743, +https://files.brokercheck.finra.org/individual/individual_5052743.pdf

    • +

  • verae.com, which names Stuart Haber as co-founder and +describes the DataCube product. As of this writing the public +marketing site does not carry a dedicated biography page +for Garfinkel. The product and company description below is +therefore taken from verae.com’s company narrative plus +Garfinkel’s own public statement of role, not from a +fabricated “about the CEO” page.

    • +
+
+
+

14.2. Role at Verae

+

Public professional listings (including a long-standing +Facebook work listing) identify Garfinkel as CEO of Verae +LLC, from January 2020, based in New York, New York. +In that listing he describes Verae’s technology as +blockchain-authenticated containers called DataCubes, +“which conveniently and securely ensure integrity and enable +selective sharing of digital information and records of all +sorts,” and he quotes Stuart Haber on the original motivation +for timestamping digital objects.

+

That description matches the public verae.com product: records +remain in customer-controlled storage; Verae seals a +fingerprint; the scientific core is Haber-style cryptographic +timestamping, aimed at compliance and examinations rather than +at operating a public chain.

+
+
+

14.3. FINRA BrokerCheck (CRD 5052743)

+

The following facts are from the public BrokerCheck report. +They are registration history, not a Verae claim and not an +endorsement by FINRA.

+
    +

  • Name on the report: James H. Garfinkel

    • +

  • CRD: 5052743

    • +

  • Current registration: this broker is not currently +registered

    • +

  • Disclosed events: the report summary states no +events disclosed about this broker

    • +

  • Examinations recorded on the summary: 0 +principal/supervisory exams; 3 general industry/product +exams; 3 state securities law exams

    • +

  • Investment adviser: BrokerCheck points readers to the +SEC IAPD site for any IAR record

    • +
+

Prior broker registrations listed on the report:

+
    +

  • LPL Financial LLC, CRD 6413, New York, NY, +January 2013 – March 2024, registered representative

    • +

  • Hornor, Townsend & Kent, Inc., CRD 4031, New York, NY, +November 2011 – December 2012

    • +

  • Park Avenue Securities LLC, CRD 46173, New York, NY, +April 2008 – October 2009

    • +
+

Other employment lines that appear in the same public report +family include Abbott Solutions Inc. (insurance advisor, +from November 2009) and MPWM Advisory Solutions LLC +(investment adviser representative, January 2014 – November +2020). Readers should treat the PDF as the living source; +registration status changes.

+
+
+

14.4. Education (public professional listings)

+

Public professional listings state:

+
    +

  • Hamilton College, B.A. Economics, class of 1980

    • +

  • United Nations International School, class of 1975

    • +
+

Other ventures listed on professional-directory sites (not +FINRA, not verae.com) have included Beryl Consulting, Intaglio +Blockchain, and earlier broker-dealer roles. Those directory +sites are secondary; they are noted here only so that a reader +who searches the name is not surprised. They are not used as +primary evidence of Verae corporate structure.

+
+
+

14.5. Why this biography is in the briefing

+

A compliance briefing is not a pitch deck. Garfinkel’s +biography is here because the user of this system is entitled +to know who is on the commercial and regulatory-facing side +of Verae, and because a broker-dealer or RIA CCO will +look the name up on BrokerCheck anyway. The honest +presentation is:

+
    +

  • CEO of Verae LLC (public listing, from 2020);

    • +

  • a long New York securities-industry registration history +ending March 2024 at LPL, not currently registered;

    • +

  • no BrokerCheck disclosed events on the current report;

    • +

  • not given a biography block on verae.com at the time +this document was compiled — Haber is the scientist the +site puts on the homepage.

    • +
+

Do not treat a CRD number as a product certification. Do not +treat a CEO biography as a control.

+
+
+ + +
+ +
+
+
+
+
+ Verae Inc + · https://www.verae.com + · Book a call at verae.com + · app.verae.com +
+ +
+ ©2026, Verae Inc. + +
+ + + + + + + \ No newline at end of file diff --git a/build/html/bio-stuart-haber.html b/build/html/bio-stuart-haber.html new file mode 100644 index 0000000..9591ad9 --- /dev/null +++ b/build/html/bio-stuart-haber.html @@ -0,0 +1,240 @@ + + + + + + + + 15. Stuart Haber — Making yourself audit-ready with Verae DataCubes + + + + + + + + + + + + + + + + + + + + +
+ + +
+
+ + +
+ +
+

15. Stuart Haber

+
+

15.1. Role at Verae

+

Stuart Haber is a co-founder of Verae. The company’s +public site introduces him as one of the creators of +blockchain and as the inventor, in 1991, of cryptographic +timestamping — “the science that lets you prove a record +hasn’t been altered, and the foundation under every +blockchain since.” The site quotes him:

+
+

“I co-founded Verae to make blockchain accessible to +enterprises without having to deal with the complexity of +blockchain.”

+

—Stuart Haber, Co-Founder of Verae; co-inventor of +blockchain timestamping, 1991

+
+

Verae’s product claim is that this is the proof Haber has +been building toward: simple enough for a compliance team, +precise enough for an SEC exam, with the customer’s records +remaining in the customer’s storage and only a fingerprint +being sealed.

+
+
+

15.2. The scientific work

+

Haber is a cryptographer. He worked at Bellcore (Bell +Communications Research) in Morristown, New Jersey, in the +late 1980s and 1990s, in the research culture descended from +Bell Labs. With physicist W. Scott Stornetta he posed a +problem that looks obvious only after it is solved: digital +documents live on media that can be altered without a mark; +how do you certify when the bits existed, without +trusting the disk, and without handing the document to the +timestamping service?

+

1991. Stuart Haber and W. Scott Stornetta, “How to +Time-Stamp a Digital Document,” Journal of Cryptology, +volume 3, number 2, pages 99–111. This is the paper that +introduces computationally practical digital timestamping +so that a user cannot back-date or forward-date a document +even with the collusion of a timestamping service, while +keeping the document itself private. Bitcoin’s white paper +cites it as reference [3].

+

1993. Dave Bayer, Stuart Haber, and W. Scott Stornetta, +“Improving the Efficiency and Reliability of Digital +Time-Stamping,” in Sequences II: Methods in Communication, +Security and Computer Science, pages 329–334. Merkle +trees, efficient certificates, publication of a compact +root. Bitcoin’s white paper cites it as reference [4].

+

1997. Stuart Haber and W. Scott Stornetta, “Secure names +for bit-strings,” Proceedings of the 4th ACM Conference on +Computer and Communications Security, pages 28–35. Bitcoin’s +white paper cites it as reference [5].

+

Those three papers are three of the eight citations in +Satoshi Nakamoto, “Bitcoin: A Peer-to-Peer Electronic Cash +System” (2008). Haber has remarked that this is a .375 +batting average, and that Bitcoin is an application built on +top of the early blockchain rather than the invention of the +data structure itself. That is a historical statement, not a +claim that Verae is Bitcoin.

+
+
+

15.3. Surety, 1994: first commercial blockchain

+

Haber and Stornetta took the research into production as +Surety. Surety hashed customer documents, linked those +hashes in a chain of certificates, and published a weekly +summary hash in the classified section of the Sunday New +York Times. That analog publication is widely described as +the oldest surviving public blockchain: a commitment that +does not depend on Surety’s servers remaining honest or +online, because the Times is independently archived. The +design idea — commit a compact fingerprint to a widely +witnessed record, without revealing the documents — is +the same idea Verae productizes for enterprise compliance.

+
+
+

15.4. Other cryptographic publications

+

Haber’s research record is broader than timestamping. It +includes work on minimum-knowledge interactive proofs, +symmetric public-key encryption, and secure multi-party +protocols (including “Cryptographic Computation: Secure +Fault-Tolerant Protocols and the Public-Key Model”). A +reader who wants the academic trail should start with the +three Bitcoin-cited papers and the 1991 Journal of +Cryptology article, then the ACM CCS 1997 paper.

+
+
+

15.5. Why this biography is in the briefing

+

Timestamping in this document is not a metaphor. It is a +specific scientific object — hash, time, sequence, privacy +of the document from the notary — that Haber defined in +print in 1991, commercialized in 1994, and is now building +into Verae so that a CCO can produce a receipt instead of a +vendor letter. The biography is here as provenance of the +receipt, not as a substitute for the organization’s +controls.

+

The same honesty that applies to Peergos applies here: +Haber co-invented the timestamping chain; he did not issue +the customer’s SOC 2.

+
+
+ + +
+ +
+
+
+
+
+ Verae Inc + · https://www.verae.com + · Book a call at verae.com + · app.verae.com +
+ +
+ ©2026, Verae Inc. + +
+ + + + + + + \ No newline at end of file diff --git a/build/html/checklist.html b/build/html/checklist.html index b2649d2..676331e 100644 --- a/build/html/checklist.html +++ b/build/html/checklist.html @@ -5,17 +5,19 @@ - Audit-ready checklist — Making yourself audit-ready with Verae DataCubes + 12. Audit-ready checklist — Making yourself audit-ready with Verae DataCubes - - + + + + - - + + @@ -24,96 +26,24 @@ - - -
-
-
- - -
- -
-

Audit-ready checklist

-

Use this as a working list. Check items only when evidence exists -(screenshot, log export, signed policy, ticket). This list is not a -certificate.

-
-

A. Scope and data map

-
    -

  • Named legal entity and systems in scope (console, Drive, NATS, IPFS, ns1)

    • -

  • Data-flow diagram: endpoint → HPKE/NATS → cryptree/IPFS

    • -

  • What is PHI / personal data vs ciphertext vs routing metadata

    • -

  • Peergos verification chapter attached (Peergos verification (what was actually audited))

    • -
-
-
-

B. Keys and encryption

-
    -

  • Customer holds Peergos/Drive keys; not on storage host

    • -

  • NPE/HPKE endpoint keys in directory; private 0600; no xor content

    • -

  • Signed Ed25519 config; unsigned rejected; admin-history prev+new+diff

    • -

  • HSM or documented lab-to-HSM path

    • -
-
-
-

C. Access

-
    -

  • Console PFC_REQUIRE_AUTH=1, TOTP; Drive login separate

    • -

  • Inspect k-of-n; author is not an officer; log-before-reveal

    • -

  • Joiner / mover / leaver for console users

    • -

  • Google SSO does not unwrap cubes

    • -
-
-
-

D. Integrity and backup

-
    -

  • Cube chain append-only JSONL; dual hash

    • -

  • Hash registry: first SHA-256 and receipt win

    • -

  • Peergos/IPFS: hash-verified encrypted blocks (restore = re-fetch CIDs)

    • -

  • Restore test: recover a cube from content-addressed ciphertext without -plaintext backup tapes

    • -
-
-
-

E. Logging

-
    -

  • Inspect audit events

    • -

  • SM summaries: codes + lookup_id only (no bodies)

    • -

  • Admin-history cube for config

    • -
-
-
-

F. Contracts (counsel)

-
    -

  • Written BA / not-a-BA determination for disk, VM, backup, IPFS

    • -

  • DPA Art. 28 where usernames/logs/IPs are processed

    • -

  • NATS operator: metadata vs content in the annex

    • -

  • Peergos component assurance: attach Cure53 2019 + ROS 2024 PDFs -(public; not your org’s ISO/SOC report)

    • -
-
-
-

G. Independent audit of you

-
    -

  • SOC 2 Type I/II engagement or ISO 27001 registrar or HIPAA -risk analysis + policies (pick the program you actually need)

    • -

  • Evidence window (Type II / surveillance) if applicable

    • -
-
-
- - -
- -
-
+
+
-
-
+
+
+ + +
+ +
+

12. Audit-ready checklist

+

Use this as a working list. Check an item only when +evidence exists (screenshot, log export, signed policy, +ticket, receipt). This list is not a certificate. Software +having been installed does not tick these boxes.

+
+

12.1. A. Scope and honesty

+
    +

  • Named legal entity and systems in scope (console, Drive, +message fabric, IPFS, timestamping link, Iceberg archive)

    • +

  • Written sentence in the system description: software is +not our HIPAA / SOC 2 / ISO 27001 certificate

    • +

  • Data-flow diagram: endpoint → HPKE → DataCube → +Peergos/IPFS → receipt → Iceberg

    • +

  • PHI / personal data vs ciphertext vs routing metadata, +named

    • +

  • Peergos evaluation chapter attached, labeled component +security evaluation

    • +
+
+
+

12.2. B. Data in transit

+
    +

  • Production algorithm is HPKE (or documented successor), +not a lab construction

    • +

  • Destinations and subjects documented as visible by +design

    • +

  • Error paths carry codes and lookup ids, not bodies

    • +

  • Public-key directory lists public keys only; private keys +mode 0600 or HSM

    • +

  • Broker operator named; metadata vs content in the annex

    • +
+
+
+

12.3. C. Data at rest

+
    +

  • Customer holds Peergos / Drive keys; not on storage host

    • +

  • Peergos hash verification on write and on read, evidenced

    • +

  • Restore test: recover a cube from content-addressed +ciphertext without a plaintext tape

    • +

  • Dual-hash cube chain; first-hash-wins registry

    • +
+
+
+

12.4. D. Timestamping

+
    +

  • First-registration rule documented and tested (second +submit returns original receipt)

    • +

  • Organizational node linked to central Verae, or +direct sync, named in the diagram

    • +

  • Sample bundle: receipt + private metadata + attachment +pointer, redacted for the evidence pack

    • +

  • Verae receives fingerprints, not objects — stated in +the data map

    • +
+
+
+

12.5. E. Write-once archive

+
    +

  • Iceberg (or equivalent) export job exists and has a dated +last-run

    • +

  • Object-lock / dual-control / separate account — evidence +that no single party can delete a committed snapshot

    • +

  • Retention schedule written by records/counsel, not by +engineering folklore

    • +

  • Legal-hold procedure extends retention; ticket example

    • +
+
+
+

12.6. F. Access and change

+
    +

  • Console requires authentication (TOTP or equivalent); +Drive login is a separate plane

    • +

  • Inspect is k-of-n; author is not an officer; log-before-reveal

    • +

  • Joiner / mover / leaver for console users

    • +

  • Signed configuration; unsigned rejected; admin-history +prev + new + diff

    • +

  • HSM or a dated plan to move lab keys to HSM

    • +
+
+
+

12.7. G. Contracts (counsel)

+
    +

  • Written BA / not-a-BA determination for disk, VM, backup, +IPFS, Iceberg

    • +

  • DPA Article 28 where usernames, logs, or IPs are processed

    • +

  • NATS operator: metadata vs content

    • +

  • Verae timestamping: fingerprint-only processing described

    • +

  • Peergos PDFs attached and labeled “not our Type II / ISO”

    • +
+
+
+

12.8. H. Independent examination of this organization

+
    +

  • SOC 2 Type I/II engagement, or ISO 27001 registrar, +or HIPAA risk analysis plus policies — the program +actually chosen, not all three as wallpaper

    • +

  • Evidence window (Type II / surveillance) if applicable

    • +

  • Named internal owner who will sit in the meeting and not +claim the software is the certificate

    • +
+
+
+ + +
+ +
+
+
+ +
+ Verae Inc + · https://www.verae.com + · Book a call at verae.com + · app.verae.com +
+
- ©2026, Verae. + ©2026, Verae Inc. - | - Powered by Sphinx 9.1.0 - & Alabaster 1.0.0 - - | - Page source
+ \ No newline at end of file diff --git a/build/html/contact.html b/build/html/contact.html new file mode 100644 index 0000000..f31ab1d --- /dev/null +++ b/build/html/contact.html @@ -0,0 +1,170 @@ + + + + + + + + 17. Verae Inc — contact — Making yourself audit-ready with Verae DataCubes + + + + + + + + + + + + + + + + + + + +
+ + +
+
+ + +
+ +
+

17. Verae Inc — contact

+

This page is the contact block that also appears in the +footer of every page of the PDF edition and at the bottom +of every HTML chapter.

+

Verae Inc

+

Website: https://www.verae.com

+

Product / activity console: https://app.verae.com

+

Book a conversation: use the “Book a call” path on +https://www.verae.com (the public site states that the +company will be in touch within one business day).

+

API (fingerprint seal, as described on the public site): +https://api.verae.com/v1/seal

+

This briefing (HTML and PDF):

+ +

A street address and telephone number are not invented +here. If a procurement file requires them, take them from +a current Verae engagement letter, W-9, or the form on +verae.com, not from this paragraph.

+
+

17.1. Closing reminder

+

Software alone does not make an organization HIPAA +certified, SOC 2 attested, or ISO 27001 certified.

+

The Verae DataCube Solution gives you tools to store, +communicate, timestamp, verify, and audit. Your +organization still has to write the policies, run the +procedures, operate the internal controls, and sit with an +independent auditor. Verae provides the tools, the +background, and the software infrastructure for the +technical portion of that work.

+

Verae Inc — https://www.verae.com

+
+
+ + +
+ +
+
+
+
+
+ Verae Inc + · https://www.verae.com + · Book a call at verae.com + · app.verae.com +
+ +
+ ©2026, Verae Inc. + +
+ + + + + + + \ No newline at end of file diff --git a/build/html/data-at-rest.html b/build/html/data-at-rest.html new file mode 100644 index 0000000..8192a1a --- /dev/null +++ b/build/html/data-at-rest.html @@ -0,0 +1,270 @@ + + + + + + + + 5. Encryption at rest — IPFS blocks and Peergos — Making yourself audit-ready with Verae DataCubes + + + + + + + + + + + + + + + + + + + + +
+ + +
+
+ + +
+ +
+

5. Encryption at rest — IPFS blocks and Peergos

+
+

5.1. The problem

+

Bytes that are no longer moving still have to live somewhere: a +disk, a replica, a backup, a cold archive. The people who operate +those surfaces — hosting providers, backup operators, someone +with a snapshot credential — are rarely the same people who are +authorized to read the records. A design that stores plaintext on +those surfaces is a design that makes every disk operator a +reader. A design that stores ciphertext, but lets an operator +swap a block without detection, is a design that fails integrity +even if it keeps confidentiality.

+

The Verae DataCube Server Solution stores data at rest as +encrypted, content-addressed IPFS blocks, with Peergos +verifying hashes on the way in and the way out.

+
+
+

5.2. Content-addressed blocks

+

IPFS names a block by a cryptographic hash of its contents (a +Content Identifier, or CID). Two properties follow immediately:

+
    +

  • If the bits change, the name changes. There is no such thing as +“the same CID, different payload” under a collision-resistant +hash.

    • +

  • A client that asked for CID X and received bytes whose hash is +not X knows it was given the wrong object.

    • +
+

That is the definition of a tamper-evident store. It does not +prevent a hostile replica from refusing to serve a block +(availability). It does prevent a hostile replica from silently +serving a substitute and hoping nobody notices (integrity).

+
+
+

5.3. Peergos on top of IPFS

+

Peergos is not “IPFS with a folder UI.” It is an encrypted +filesystem — a cryptree — whose nodes and file chunks are +stored as IPFS blocks. The properties that matter for an +audit-ready DataCube are:

+
    +

  • Client-side encryption. Symmetric keys for chunks live with +the customer, not on the storage host. A host with disk access +sees padded, encrypted chunks and random labels, not filenames, +not sibling names, not a social graph.

    • +

  • Hash verification. Peergos verifies the hash of every +block it reads from or writes to IPFS. A restored cube is not +“whatever was on the tape.” It is a set of CIDs re-fetched and +re-checked.

    • +

  • Signed writes. Updates are signed. An unsigned rewrite is +not a valid Peergos write.

    • +

  • Independent chunk keys. Chunks (up to 5 MiB, padded) are +encrypted with random 256-bit keys (Salsa20-Poly1305 in the +published design), not with convergent encryption that would +leak equality of plaintext across users.

    • +

  • CHAMP places encrypted cryptree nodes under random 32-byte +labels, so the storage host cannot walk the directory tree by +name.

    • +

  • Sharing uses hybrid encryption (X25519 plus ML-KEM-1024 in +current Peergos) so a capability can be given to another user +without placing the chunk key on the server.

    • +
+
+
+

5.4. Tamper-evident restore

+

“Backup” in this architecture does not mean a second plaintext +copy in a different building. It means:

+
    +

  1. the CIDs that constitute a cube are known;

    2. +

  2. the encrypted blocks for those CIDs exist on more than one +replica;

    3. +

  3. a restore re-fetches the blocks and re-verifies the +hashes;

    4. +

  4. the customer, holding keys, decrypts locally.

    5. +
+

If step 3 fails, the restore fails closed. That is the opposite +of a backup product that “helpfully” returns the last good +plaintext it had. Helpfulness of that kind is how silent +corruption and silent substitution enter an evidence set.

+
+
+

5.5. Append-only at the cube layer

+

Peergos itself uses signed updates and immutable blocks. The +Verae DataCube adds an application-level chain: a JSONL +history in which each record hashes the previous record. Dual +hashing (for example SHA-256 plus BLAKE2b or BLAKE3) is used so +that a future weakness in one function does not silently rewrite +history.

+

These two layers must not be conflated in an audit interview:

+
    +

  • IPFS / Peergos prove that the bytes retrieved are the bytes +named by the CID, and that names and sizes are not in the +clear on the host.

    • +

  • The cube chain proves that the organization’s own history +of writes is append-only at the application layer.

    • +
+

Both are needed. Neither is a SOC 2 report.

+
+
+

5.6. What a disk operator sees

+

If keys never leave the client or the customer’s HSM, a disk +operator, a VM snapshot operator, and an offsite replica operator +see opaque hashed ciphertext. They do not see PHI, they do +not see document titles, they do not see the graph of who shared +what with whom.

+

That fact changes the Business Associate / processor +conversation. It does not automatically end it. Usernames, IP +addresses, billing identity, and support logs can still be +personal data. Chapter 11 takes that up.

+
+
+

5.7. What this does, and does not, satisfy

+

For HIPAA encryption of ePHI at rest, for SOC 2 CC6 +encryption of stored data, and for ISO 27001 Annex A cryptography +and storage, this is the technical control: ciphertext on +disk, keys with the customer, hash-checked restore.

+

It does not by itself satisfy:

+
    +

  • a key-custody policy (who can unwrap, where the HSM lives, +how a lost key is declared);

    • +

  • a restore-test procedure with a dated ticket proving +someone actually did it last quarter;

    • +

  • retention and legal-hold rules (those require the +write-once archive in Chapter 9, plus lawyers);

    • +

  • physical security of the machines, which still belongs in +the organization’s ISMS or HIPAA facility controls.

    • +
+
+
+ + +
+ +
+
+
+
+
+ Verae Inc + · https://www.verae.com + · Book a call at verae.com + · app.verae.com +
+ +
+ ©2026, Verae Inc. + +
+ + + + + + + \ No newline at end of file diff --git a/build/html/data-in-transit.html b/build/html/data-in-transit.html new file mode 100644 index 0000000..71f9a27 --- /dev/null +++ b/build/html/data-in-transit.html @@ -0,0 +1,243 @@ + + + + + + + + 4. Secure communications — data in transit — Making yourself audit-ready with Verae DataCubes + + + + + + + + + + + + + + + + + + + + +
+ + +
+
+ + +
+ +
+

4. Secure communications — data in transit

+
+

4.1. The problem

+

A message that leaves one machine and arrives at another crosses +infrastructure the endpoints do not own: routers, load balancers, +message brokers, TLS terminators, packet-capture appliances, and +people with legitimate operational access to those devices. Any of +those parties can copy bits. The honest design question is not +“will anyone see the packet” — they will — but “what will +they see, and what will they be able to do with it.”

+

The Verae DataCube Server Solution answers that question with +point-to-point encryption of content and an explicit admission +that routing must be visible.

+
+
+

4.2. Point-to-point encryption

+

“Best in class” here is not a slogan; it names a concrete choice. +Production content is sealed with HPKE (Hybrid Public Key +Encryption, RFC 9180), in the HPKE-Base mode, using a suite such as +X25519-HKDF-SHA256 with ChaCha20-Poly1305. Each endpoint has a +key pair. The sender looks up the recipient’s public key in a +directory that is visible to every E2E service. The sender seals +the body to that public key. Only the holder of the matching +private key can open it.

+

Consequences that matter in an audit interview:

+
    +

  • The sender cannot reopen the ciphertext after it is sealed +unless the sender is also a recipient or has retained plaintext. +A lookup identifier is enough to talk about the message later +without retaining a second copy of the body.

    • +

  • The broker cannot open the body. Possession of the wire +image is possession of ciphertext.

    • +

  • A lab XOR construction, if it exists in a codebase for +experiments, is not a production algorithm. Production +configurations reject it.

    • +
+
+
+

4.3. Visible routing

+

A network that cannot see a destination cannot deliver a message. +The DataCube Server Solution therefore does not claim +anonymous, metadata-free messaging. The following remain visible +to the transport, by design:

+
    +

  • destination (the handle or address the router needs);

    • +

  • subject or stream name (so the right service receives the +envelope);

    • +

  • sender handle or lookup identifier, when the protocol carries +them for reply and error handling;

    • +

  • approximate size and timing (any network sees these).

    • +
+

This is the honest-but-curious broker model. Curiosity is +assumed. Honesty is assumed only in the narrow sense that the +broker forwards what it is given; it is not trusted with +content, and it is not trusted not to log destinations.

+
+
+

4.4. Error handling without leaking content

+

Failures have to be reported. A bounce that includes the original +body would undo the encryption. The design therefore returns +error metadata: an error code, a lookup identifier, a +destination class — not the plaintext, and not a replay of the +ciphertext into a log aggregator that is a second, weaker store.

+

Network Error Bundles can carry a sender-visible ciphertext and a +system-visible ciphertext so that the right party can diagnose +without broadcasting the payload to operators who should never see +it.

+
+
+

4.5. The public-key directory

+

Point-to-point encryption is only as good as the lookup of public +keys. The server solution publishes a directory of public keys +so that availability of those keys is visible to all E2E services. +Private keys do not belong in that directory. Private key files +are mode 0600, held on the endpoint or in an HSM, and are +never returned by the public listing API.

+

An examiner can be shown the public listing. An examiner should +never be given a private key.

+
+
+

4.6. What this does, and does not, satisfy

+

For HIPAA Security Rule addressable encryption of ePHI in +transit, for SOC 2 CC6 cryptographic transmission, and for +ISO 27001 Annex A transmission security, this design is the +technical control: content is encrypted to the recipient, the +path is untrusted, keys are endpoint-held.

+

It does not by itself satisfy:

+
    +

  • a rule that requires the organization to inventory every +channel (personal devices, shadow SaaS, unapproved AI tools);

    • +

  • a rule that requires workforce sanctions when someone +bypasses the channel;

    • +

  • a rule that requires agreements with the broker operator +covering metadata that may still be personal data.

    • +
+

Those remain policies, procedures, and contracts. The software +makes the approved channel strong. It cannot stop a person from +using a weak channel instead. That is an organizational control, +not a cryptographic one.

+
+
+ + +
+ +
+
+
+
+
+ Verae Inc + · https://www.verae.com + · Book a call at verae.com + · app.verae.com +
+ +
+ ©2026, Verae Inc. + +
+ + + + + + + \ No newline at end of file diff --git a/build/html/datacube-server.html b/build/html/datacube-server.html new file mode 100644 index 0000000..cf0d9b5 --- /dev/null +++ b/build/html/datacube-server.html @@ -0,0 +1,241 @@ + + + + + + + + 3. The Verae DataCube Server Solution — Making yourself audit-ready with Verae DataCubes + + + + + + + + + + + + + + + + + + + + +
+ + +
+
+ + +
+ +
+

3. The Verae DataCube Server Solution

+
+

3.1. 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.

+
+
+

3.2. 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.

+
+
+

3.3. 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.

+
+
+

3.4. 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.

+
+
+

3.5. 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.

+
+
+ + +
+ +
+
+
+
+
+ Verae Inc + · https://www.verae.com + · Book a call at verae.com + · app.verae.com +
+ +
+ ©2026, Verae Inc. + +
+ + + + + + + \ No newline at end of file diff --git a/build/html/executive.html b/build/html/executive.html new file mode 100644 index 0000000..293c917 --- /dev/null +++ b/build/html/executive.html @@ -0,0 +1,292 @@ + + + + + + + + 1. Executive summary — Making yourself audit-ready with Verae DataCubes + + + + + + + + + + + + + + + + + + + + +
+ + +
+
+ + +
+ +
+

1. Executive summary

+

Software alone does not make an organization HIPAA certified, SOC 2 +attested, or ISO 27001 certified.

+

That sentence is the point of this document. It is also the sentence +that is most often skipped when a vendor, an integrator, or an internal +champion shows encryption, hashing, or a pentest PDF and treats the +conversation as finished. It is not finished. Encryption is a control. +A pentest is an evaluation of a component. A certificate, an attestation, +or a covered-entity determination is a statement about an organization +— its legal entity, its people, its written policies, its operating +procedures, its internal controls, the evidence those controls produce, +and the independent party that examined that evidence.

+

The Verae DataCube Solution gives an organization tools to store, +communicate, timestamp, verify, and audit for compliance. +Those tools are real, they are specific, and they are described in the +chapters that follow. They are still only tools. To obtain HIPAA-aligned +status as a covered entity or business associate with a defensible +program, a SOC 2 Type I or Type II report, or an ISO 27001 certificate, +the organization must still:

+
    +

  • write and live by policies (what the organization says it will do);

    • +

  • operate procedures (how staff actually do it, every day);

    • +

  • design and test internal controls (the checks that catch failure);

    • +

  • retain evidence (logs, tickets, screenshots, signed approvals, +restore tests, training records);

    • +

  • engage an independent auditor, CPA firm, or ISO registrar, as the +chosen program requires.

    • +
+

Verae cannot issue those certificates. Verae cannot sit in the +organization’s chair during an OCR investigation, a SOC 2 fieldwork +week, or an ISO Stage 2 audit. What Verae can do — and what this +briefing is written to make precise — is provide the tools, the +background, and the software infrastructure that make it easier +to implement the technical portion of those programs.

+
+

1.1. What a Verae DataCube Server Solution does

+

A Verae DataCube Server Solution provides secure communications and +storage for two classical information-security states:

+
    +

  • Data in transit — messages, objects, and control traffic while +they move from one endpoint to another.

    • +

  • Data at rest — messages, objects, metadata, and receipts while +they sit on disk, in a replica, or in an archive.

    • +
+

Those two states are not the same problem, and they are not solved by +the same mechanism. This document treats them separately on purpose.

+
+
+

1.2. Data in transit

+

Verae uses best-in-class encryption for messaging from point to +point. The content of a message is sealed so that only the intended +endpoints can open it. Routing, however, must remain visible: a +message that cannot be addressed cannot be delivered. Subjects, +destination handles, and size or timing metadata are therefore +visible to the transport. The transport is treated as +honest-but-curious. It can drop, delay, or copy ciphertext. It +cannot read the body if it does not hold endpoint private keys.

+
+
+

1.3. Data at rest

+

Encryption at rest is performed through IPFS content-addressed +blocks. Each block is named by its hash. Peergos verifies those +hashes on read and on write. A restore is therefore +tamper-evident: if a block was altered, its hash no longer +matches, and the client refuses it. This is not a plaintext tape +backup. It is a re-fetch of hashed ciphertext plus a verification +that the bits are the bits that were stored.

+
+
+

1.4. Global timestamped receipts

+

Independently of who stores the bytes, Verae issues global +timestamped receipts based on document hashes. A receipt is +proof of the time and sequence of the first registration of a +block of digital information — a message, an image, a document, or +any other digital object that can be stored in digital media. The +receipt does not require Verae to see the object. It requires a +fingerprint of the object, registered at a time that can later be +shown to third parties.

+
+
+

1.5. Peergos, evaluated in Europe

+

The offline storage and replication system used with Peergos was +audited twice in Europe, and the protocol was designed under +work that was independently reviewed:

+
    +

  • 2019 — Cure53, Berlin, Germany. Pentest, source-code audit, +and crypto/design review (May–June 2019). No fundamental +architectural or cryptographic problems. Issues found were fixed. +Cure53 stated that the platform passed this evaluation.

    • +

  • 2024 — Radically Open Security B.V., Amsterdam, Netherlands. +Crystal-box pentest plus code audit of the Peergos web UI +(September–November 2024). Zero findings rated extreme, high, +or elevated; two moderate; six low. Peergos states all +were fixed. No data exposure and no integrity compromise (the +issues were mostly UI crashes).

    • +
+

Both firms are EU-based. Both full reports are public. That +is a security evaluation of the Peergos protocol and +implementation. It is not a HIPAA certificate, a SOC 2 report, +or an ISO 27001 certificate for Peergos, for Verae, or for any +customer.

+
+
+

1.6. Verae global timestamping

+

The Verae Global Timestamping and receipt solution is a +cross-blockchain design. It certifies the time and date stamp of +a digital object and stores that information in a digital bundle +that can carry private metadata, attached files, and an internal +blockchain. That organizational chain is cross-verified either:

+
    +

  • from an organizational server linked to the central Verae +server, or

    • +

  • by directly syncing with Verae’s central timestamping server.

    • +
+

The result is proof of existence of a digital object at a +specific time and date. When the organization wants the object +itself stored — not only its fingerprint — the object can live +inside an encrypted Peergos DataCube.

+
+
+

1.7. Write-once Iceberg archive

+

Those DataCubes are archived into a write-once external Iceberg +file-storage solution for compliance reasons. The archive is +designed to sit outside the deletion control of any single +party. That is a retention and legal-hold property, not a +marketing slogan: once a cube is committed to the write-once tier, +neither the customer operator, nor Verae, nor a hosting vendor +should be able to quietly erase it.

+
+
+

1.8. What this briefing is, and is not

+

This briefing describes the technical portion of a compliance +program that an organization can build with Verae DataCubes. It +indexes each of the points above as its own chapter, in enough +detail that a CISO, a CCO, outside counsel, or an auditor can +distinguish:

+
    +

  • what the software does;

    • +

  • what the independent Peergos evaluations actually said;

    • +

  • what Verae timestamping actually proves;

    • +

  • what the organization must still write, operate, and have +examined.

    • +
+

It does not claim that installing this software finishes HIPAA, +SOC 2, or ISO 27001. Anyone who says otherwise is not describing +this product honestly.

+
+
+ + +
+ +
+
+
+
+
+ Verae Inc + · https://www.verae.com + · Book a call at verae.com + · app.verae.com +
+ +
+ ©2026, Verae Inc. + +
+ + + + + + + \ No newline at end of file diff --git a/build/html/genindex.html b/build/html/genindex.html index ad299bf..74a85f5 100644 --- a/build/html/genindex.html +++ b/build/html/genindex.html @@ -7,10 +7,12 @@ Index — Making yourself audit-ready with Verae DataCubes - - + + + + @@ -21,33 +23,24 @@ - - -
-
-
- - -
- - -

Index

- -
- -
- - -
- -
-
+
+ -
-
+
+
+ + +
+ + +

Index

+ +
+ +
+ + +
+ +
+
+
+
+
+ Verae Inc + · https://www.verae.com + · Book a call at verae.com + · app.verae.com +
+
- ©2026, Verae. - - | - Powered by Sphinx 9.1.0 - & Alabaster 1.0.0 + ©2026, Verae Inc.
+ \ No newline at end of file diff --git a/build/html/global-timestamping.html b/build/html/global-timestamping.html new file mode 100644 index 0000000..5799bfa --- /dev/null +++ b/build/html/global-timestamping.html @@ -0,0 +1,266 @@ + + + + + + + + 8. Verae global timestamping — a cross-blockchain receipt — Making yourself audit-ready with Verae DataCubes + + + + + + + + + + + + + + + + + + + + +
+ + +
+
+ + +
+ +
+

8. Verae global timestamping — a cross-blockchain receipt

+
+

8.1. Lineage

+

The scientific problem Verae is productizing is not new. In +1991, Stuart Haber and W. Scott Stornetta published “How to +Time-Stamp a Digital Document” in the Journal of +Cryptology. They asked how to certify when a digital +document was created or last changed without trusting the +medium and without giving the timestamping service the +document. In 1993, with Dave Bayer, they showed how Merkle +trees make that efficient. In 1997 they published “Secure +names for bit-strings.” Satoshi Nakamoto’s 2008 Bitcoin +white paper cites those three papers as references [3], [4], +and [5] — three of the eight citations in that document.

+

Haber co-founded Surety in 1994, widely described as the +first commercial blockchain: a hash-linked chain of document +certificates, with a weekly summary published in the Sunday +New York Times so that the day’s commitments sat in a +public, widely archived analog record.

+

Haber is a co-founder of Verae. Verae’s public site +states the aim directly: make that proof simple enough for a +compliance team and precise enough for an SEC exam, without +forcing the enterprise to operate a public blockchain. The +quote on verae.com is: “I co-founded Verae to make +blockchain accessible to enterprises without having to deal +with the complexity of blockchain.”

+
+
+

8.2. What “cross-blockchain” means here

+

A single private log, held only by the vendor, is a vendor +assurance letter with extra steps. A single public chain may +be operationally and commercially the wrong place to put an +enterprise’s registration traffic. Verae’s design is +cross-blockchain in the following sense:

+
    +

  • an organizational chain runs at the customer, inside +or beside the DataCube, recording hashes, metadata, and +sequence;

    • +

  • a central Verae chain records fingerprints and issues +receipts;

    • +

  • the two are cross-verified, so that neither side can +rewrite history without the other side’s record disagreeing;

    • +

  • when policy calls for it, commitments can be anchored +further — additional public or consortium chains — so +that proof of existence does not collapse if one operator +disappears.

    • +
+

The customer does not have to become a blockchain operator +to use this. That is the product claim. The examiner does +not have to trust a single vendor’s database to verify a +receipt. That is the scientific claim, inherited from +Haber–Stornetta.

+
+
+

8.3. Two deployment patterns

+

Linked organizational server. The organization runs a +timestamping node next to its DataCube server. That node is +linked to the central Verae timestamping server. Local +registrations are committed locally (low latency, private +metadata stays home) and cross-verified centrally (receipt +the rest of the world can check).

+

Direct sync. An organization that does not want to run +the organizational node can sync registrations directly with +Verae’s central timestamping server. Proof of existence at a +specific date and time still issues. Private metadata and +attached files, if any, remain the organization’s problem to +store — typically in the encrypted Peergos DataCube.

+

Both patterns produce the same external artifact: a receipt +bound to a hash, a time, and a sequence. They differ in +where the organizational metadata lives and in how much +infrastructure the customer operates.

+
+
+

8.4. The digital bundle

+

The unit of production is a digital bundle:

+
    +

  • the receipt (hash, time, sequence, verification path);

    • +

  • private metadata (classification, matter, hold, +internal identifiers) that need not be on a public chain;

    • +

  • attached files that should be produced together;

    • +

  • a pointer or capability to the object in the encrypted +DataCube, when the organization chose to store the object +and not only its fingerprint.

    • +
+

An examiner can be given the bundle, or a redacted bundle, +without being given a login to the production console and +without Verae ever having seen the object bytes.

+
+
+

8.5. Proof of existence versus proof of custody

+

Timestamping answers: did these bits exist by this time?

+

The DataCube answers: does the organization still have +them, encrypted, hash-checkable?

+

The Iceberg write-once tier answers: can anyone quietly +delete them anyway?

+

A complete production to a regulator often needs all three. +Timestamping alone is not an archive. An archive without a +receipt is a pile of files with a clock on the filesystem +that the administrator can set.

+
+
+

8.6. What this does, and does not, satisfy

+

For SEC Rule 17a-4, FINRA books-and-records, and similar +regimes that demand records in a non-rewriteable, +non-erasable form with the ability to produce the +original, timestamped receipts plus write-once archive are +the technical portion of the answer: you can show when +the record was sealed, that the bits match, and that the +archive copy is not under ordinary delete.

+

They do not satisfy:

+
    +

  • the requirement to capture the channel in the first +place (if the team used an unsealed tool, there is +nothing to timestamp);

    • +

  • the requirement to have written procedures for +production, legal hold, and supervision;

    • +

  • the requirement that a named principal own the +recordkeeping obligation.

    • +
+

Software seals what it is shown. The organization must still +show it the right things, on time, under a policy someone +will sign.

+
+
+ + +
+ +
+
+
+
+
+ Verae Inc + · https://www.verae.com + · Book a call at verae.com + · app.verae.com +
+ +
+ ©2026, Verae Inc. + +
+ + + + + + + \ No newline at end of file diff --git a/build/html/howto.html b/build/html/howto.html index 111af52..23bf1d3 100644 --- a/build/html/howto.html +++ b/build/html/howto.html @@ -5,16 +5,19 @@ - How to use this pack — Making yourself audit-ready with Verae DataCubes + 13. How to use this briefing — Making yourself audit-ready with Verae DataCubes - - + + + + - + + @@ -23,51 +26,24 @@ - - -
-
-
- - -
- -
-

How to use this pack

-
    -

  1. Read Peergos verification (what was actually audited) so you do not over-claim Peergos audits.

    2. -

  2. Fill Audit-ready checklist with your instance evidence (ns1, keys, users).

    3. -

  3. Give BAAs and DPAs when ciphertext has no host keys to counsel with the data-flow from Architecture (audit interview).

    4. -

  4. Point auditors at live technical surfaces (do not give them private keys).

    5. -
- -
    -

  1. Attach the two public Peergos pentest PDFs from the Peergos -audits/ tree as vendor security evaluations, labeled “not our -SOC 2 / ISO certificate”.

    2. -
-
- - -
- -
-
+
+
-
-
+
+
+ + +
+ +
+

13. How to use this briefing

+
    +

  1. Read the executive summary aloud in the first five +minutes of any vendor, board, or auditor meeting that +touches this system. If anyone says “so we are certified,” +stop and reread Chapter 1.

    2. +

  2. Read What Verae provides so the five verbs (store, +communicate, timestamp, verify, audit) are not confused +with an ISMS, a Type II, or a HIPAA program.

    3. +

  3. Read the transit, rest, receipts, Peergos +evaluations, timestamping, and Iceberg chapters +in that order. They are the technical portion, in the +order an examiner usually probes: “can the wire read it, +can the disk read it, can you prove when, who looked at +the crypto, can you produce it later.”

    4. +

  4. Fill the checklist with this instance’s evidence. +Empty checkboxes are not a moral failing; they are the +work remaining.

    5. +

  5. Give BAAs and DPAs to counsel with the architecture +diagram. Do not let engineering declare a vendor “not a +BA.”

    6. +

  6. Attach the two public Peergos reports as vendor +security evaluations, with a cover slip that says they +are not the organization’s SOC 2, ISO 27001, or HIPAA +certification.

    7. +

  7. Point auditors at live technical surfaces (health, +public-key listing, Drive). Do not give them private +keys. Do not give them a story that the pentest PDF is +the Type II.

    8. +

  8. Keep the biographies at the back of the PDF for +provenance — who built the timestamping science, who +is building the product, who architected the internet +integration and the DataCube server side — without +substituting biography for controls.

    9. +
+

Reference instance (not a certificate):

+ +
+ + +
+ +
+
+
+ +
+ Verae Inc + · https://www.verae.com + · Book a call at verae.com + · app.verae.com +
+
- ©2026, Verae. + ©2026, Verae Inc. - | - Powered by Sphinx 9.1.0 - & Alabaster 1.0.0 - - | - Page source
+ \ No newline at end of file diff --git a/build/html/iceberg-archive.html b/build/html/iceberg-archive.html new file mode 100644 index 0000000..940e11c --- /dev/null +++ b/build/html/iceberg-archive.html @@ -0,0 +1,260 @@ + + + + + + + + 9. Write-once Iceberg archive — Making yourself audit-ready with Verae DataCubes + + + + + + + + + + + + + + + + + + + + +
+ + +
+
+ + +
+ +
+

9. Write-once Iceberg archive

+
+

9.1. The deletion problem

+

Encryption at rest stops a disk operator from reading. +Hash verification stops a replica from substituting. +Timestamped receipts stop a custodian from back-dating. +None of those, by themselves, stop a person with legitimate +administrative power from deleting.

+

Deletion is the failure mode that turns a recordkeeping +program into a fine. Off-channel messaging cases at +broker-dealers were, at bottom, failures to produce. A +record that existed and was then removed, “cleaned up,” or +rotated out of the only copy is, to an examiner, a record +that cannot be produced.

+

Compliance therefore needs a tier where ordinary +administrative power does not include delete.

+
+
+

9.2. What “write-once Iceberg” means in this solution

+

DataCubes — the encrypted, hash-chained containers — are +archived into an external, write-once file-storage +solution built on the Iceberg table/file model (a +layout of immutable data files plus a metadata log that +records new snapshots rather than rewriting old ones).

+

Properties the solution is specified to have:

+
    +

  • Write once. A committed archive object is not updated +in place. A correction is a new object with a new +receipt. The original remains.

    • +

  • External. The archive is not the same disk as the +live Peergos instance. Compromising the live server should +not confer delete on the archive.

    • +

  • Outside any single party’s deletion control. The +customer operator, Verae, and the hosting vendor are each +insufficient, by themselves, to erase a committed archive +file. Practical implementations of that requirement use +some combination of object-lock / WORM flags, dual-control +hold, independent cloud or tape accounts, and contractual +prohibition on early delete — plus the technical fact +that Iceberg snapshots are new files, not overwrites.

    • +

  • For compliance reasons. This tier exists because +retention schedules, legal holds, and examiner production +require it — not because it is a convenient backup.

    • +
+
+
+

9.3. How cubes move into the archive

+

A live DataCube is an operational object: it receives new +writes, it is replicated as encrypted IPFS blocks, it is +readable by holders of the right capabilities. On a schedule +and on events (legal hold, period close, exam notice), the +server solution exports a cube snapshot:

+
    +

  1. freeze a CID set and cube-chain head;

    2. +

  2. confirm Peergos hash verification of every block in the +set;

    3. +

  3. register that snapshot’s hash with Verae timestamping +(first registration of this snapshot);

    4. +

  4. write the encrypted snapshot into Iceberg as a new +immutable data file (or set of files) under a snapshot +id that never reuses a previous id;

    5. +

  5. record, in admin-history, that the archive job ran, who +authorized it, and which receipt was issued.

    6. +
+

A restore from the archive is the same tamper-evident path +as a restore from IPFS: re-fetch, re-verify hashes, decrypt +only with customer keys.

+

What “outside the control of any party for deletion” is +and is not +——————————————————-

+

It is not a claim that physics forbids destruction of +every copy in a fire, a court order, or a coordinated +malicious act by every holder of every credential. No +storage system honestly claims that.

+

It is a claim that the ordinary delete path — the +button, the rm, the lifecycle rule, the “empty trash,” +the support ticket to “please remove that customer folder” +— is not available to any one party acting alone against a +committed archive object. Dual control, object lock, and +separation of the archive account from the live-server +account are the organizational complements to the file +format.

+

The organization’s retention policy still has to name:

+
    +

  • how long a class of record stays in write-once;

    • +

  • who can place a legal hold that extends that period;

    • +

  • who, under what dual control, may allow a record to +age out after the policy period, if aging out is +legally permitted at all.

    • +
+

Software can refuse a delete API. It cannot write the +retention schedule. Counsel and the records officer do that.

+
+
+

9.4. Relation to classical WORM

+

Broker-dealer Rule 17a-4 and similar texts speak of +non-rewriteable, non-erasable media, originally meaning +optical WORM, later allowing disk with object-lock semantics +and a designated third party. Verae’s public comparison is +that conventional WORM is immutable by policy (a vendor +setting), whereas Verae seals a record with +cryptographic proof. The Iceberg write-once tier is where +those two ideas meet: the file is not overwritten and +the snapshot hash is receipted. An examiner can check the +receipt even if they do not trust the vendor’s “WORM was +on” screenshot.

+
+
+

9.5. What this does, and does not, satisfy

+

This is the technical portion of retention and +production: committed cubes are not under a single delete +key, they are hash-checkable, and they carry a time of +archival.

+

It does not satisfy a retention policy that was never +written, a legal hold that was never placed, or a production +request that the organization answers from a laptop copy +instead of from the archive. Those are procedures.

+
+
+ + +
+ +
+
+
+
+
+ Verae Inc + · https://www.verae.com + · Book a call at verae.com + · app.verae.com +
+ +
+ ©2026, Verae Inc. + +
+ + + + + + + \ No newline at end of file diff --git a/build/html/index.html b/build/html/index.html index 1eb644e..8d7e0f4 100644 --- a/build/html/index.html +++ b/build/html/index.html @@ -8,13 +8,15 @@ Making yourself audit-ready with Verae DataCubes — Making yourself audit-ready with Verae DataCubes - - + + + + - + @@ -23,94 +25,24 @@ - - -
-
-
- - -
- -
-

Making yourself audit-ready with Verae DataCubes

-

How to prepare an organization for HIPAA-aligned, SOC 2, or ISO 27001 -work using Verae DataCubes on Peergos (encrypted cryptree + hashed -IPFS) and HPKE on an untrusted NATS broker.

-

This document is not a HIPAA, SOC 2, or ISO certificate. -Peergos’s public pentests are not your Type II or ISO registrar -certificate. They are component security evaluations you can attach.

-
- -
-
-

What we verified about Peergos (EU)

-

See the full sourced table in Peergos verification (what was actually audited).

-
    -

  • Encrypted client-side filesystem (cryptree); keys not on the storage -server — yes (Peergos book + Cure53 design review).

    • -

  • IPFS blocks content-addressed; Peergos verifies hashes — yes.

    • -

  • Independent EU security audits, reports published — yes, two: -Cure53 Berlin (2019); Radically Open Security Amsterdam (2024).

    • -

  • “Peergos is HIPAA/SOC 2/ISO certified” — no. Those audits are -pentest/code/design reviews, not management-system certificates.

    • -
-

Peergos was designed as a trust-minimized encrypted filesystem, -evaluated in Europe by two specialist firms, with public reports. -That supports the at-rest / backup story. It does not finish -your audit.

-

Live technical surfaces:

- -

Companion system docs (HTML): https://docs.pfc.georgelambert.org/

-
-
- - -
- -
-
+
+ +
+
+ + +
+ +
+

Making yourself audit-ready with Verae DataCubes

+ +

This volume is a technical briefing. It is not a certificate.

+

The table of contents below is the document map. In the PDF edition, +each chapter starts on a new page and the contents list includes +section titles with page numbers. In HTML, each chapter is its own +page with the Verae wordmark in the sidebar and Verae Inc contact +information in the footer.

+
+

Contents

+ +
+
+ + +
+ +
+
+
+
+
+ Verae Inc + · https://www.verae.com + · Book a call at verae.com + · app.verae.com +
+
- ©2026, Verae. + ©2026, Verae Inc. - | - Powered by Sphinx 9.1.0 - & Alabaster 1.0.0 - - | - Page source
+ \ No newline at end of file diff --git a/build/html/objects.inv b/build/html/objects.inv index eac9c8a..8421e8b 100644 Binary files a/build/html/objects.inv and b/build/html/objects.inv differ diff --git a/build/html/peergos-eu-evaluations.html b/build/html/peergos-eu-evaluations.html new file mode 100644 index 0000000..487c8f9 --- /dev/null +++ b/build/html/peergos-eu-evaluations.html @@ -0,0 +1,274 @@ + + + + + + + + 7. Peergos security evaluations in Europe — Making yourself audit-ready with Verae DataCubes + + + + + + + + + + + + + + + + + + + + +
+ + +
+
+ + +
+ +
+

7. Peergos security evaluations in Europe

+
+

7.1. What was evaluated

+

The offline storage and replication system used with Verae +DataCubes is Peergos: an encrypted, peer-to-peer filesystem +whose blocks live on IPFS. Peergos was designed as a +trust-minimized store — the server is treated as an adversary +for content and for most metadata — and that design was +submitted to independent European security firms twice.

+

Those engagements are security evaluations of the Peergos +protocol and implementation. They are pentests, source-code +audits, and (in 2019) a cryptographic and design review. They +are not:

+
    +

  • a HIPAA certification of Peergos, Verae, or any customer;

    • +

  • a SOC 2 Type I or Type II report;

    • +

  • an ISO 27001 certificate of an ISMS;

    • +

  • a government “certified filesystem” designation.

    • +
+

Both firms are EU-based. Both full reports are public. +That combination — independent, European, public, repeat — +is unusual and is worth attaching to a vendor-assurance file, +labeled correctly.

+
+
+

7.2. 2019 — Cure53, Berlin, Germany

+
    +

  • Firm: Cure53

    • +

  • Location: Berlin, Germany

    • +

  • When: May–June 2019

    • +

  • Scope: pentest, source-code audit, and +crypto / design review

    • +

  • Outcome: no fundamental architectural or cryptographic +problems were identified. Issues that were identified were +fixed. Cure53 stated that the platform passed this +evaluation.

    • +
+

A crypto/design review is a stronger statement than a +black-box pentest of a web form. It is an expert reading of +whether the cryptree, the chunk encryption, the identity +model, and the threat model hang together. “Passed” in +Cure53’s language is not an ISO mark. It is a specialist +firm saying: we looked at the cryptography and the +architecture, we did not find a fatal flaw, and the issues we +did find were addressed.

+

Primary sources (public):

+ +
+
+

7.3. 2024 — Radically Open Security B.V., Amsterdam

+
    +

  • Firm: Radically Open Security B.V.

    • +

  • Location: Amsterdam, Netherlands

    • +

  • When: September–November 2024

    • +

  • Scope: crystal-box pentest plus code audit of the +Peergos web UI

    • +

  • Funding context: the 2024 audit post states support +from NLnet (Netherlands) and refers to European Union +Horizon 2020 NGI-POINTER, grant 871528.

    • +

  • Outcome: 0 findings rated extreme, high, or +elevated; 2 moderate; 6 low. Peergos states that +all were fixed. There was no data exposure and no +integrity compromise. The issues were described as +mostly UI crashes.

    • +
+

A crystal-box (clear-box) engagement means the testers had +source. A web-UI scope is narrower than the 2019 +crypto/design review: it is evidence about the interface +that humans actually click, which is where many “encrypted +backend” products fail in practice. Zero high-severity +findings, no data exposure, no integrity compromise, and a +public report are the facts. They are good facts. They are +still not a customer’s Type II.

+

Primary sources (public):

+ +
+
+

7.4. How to present these reports to an auditor

+

Correct:

+
+

“Our at-rest layer is Peergos. Peergos was independently +evaluated in Berlin in 2019 (crypto and design) and in +Amsterdam in 2024 (web UI, crystal box). Both reports are +public. We attach them as component security +evaluations. They are not our SOC 2, not our ISO 27001, +and not a HIPAA certification. Our own controls, our own +period of examination, and our own auditor are separate.”

+
+

Incorrect:

+
+

“We are HIPAA certified because Peergos was audited in +Europe.”

+

“Peergos is ISO 27001.”

+

“The EU certified this filesystem.”

+
+

EU funding is not a certification. NGI-POINTER grant 871528 +is a research-and-innovation funding fact. It is worth +listing under “provenance.” It is not a registrar’s mark.

+
+
+

7.5. Hosted Peergos versus self-hosted DataCubes

+

Peergos’s hosted privacy notice has stated that peergos.net +uses servers in Germany. A self-hosted organizational +DataCube is a different processing location. The +customer’s Record of Processing, BAA pack, and ISO scope +must name that location — the customer’s ns1, region, or +chosen host — not peergos.net’s Germany, unless the +customer actually uses peergos.net.

+

The evaluations still apply to the protocol and +implementation. Location of processing is an +organizational fact on top.

+
+
+

7.6. What “designed under funding from Cure53 / ROS” is not

+

The 2019 Cure53 work and the 2024 ROS work are evaluations +of a system that was designed by the Peergos authors. They +are not a claim that Cure53 or Radically Open Security +designed Peergos. The accurate statement is: the storage and +replication system was independently audited twice in +Europe, by Cure53 in Berlin (2019) and by Radically Open +Security in Amsterdam (2024), with public reports, and the +2019 work included a cryptographic and design review of the +architecture that Verae DataCubes rely on for data at rest.

+
+
+ + +
+ +
+
+
+
+
+ Verae Inc + · https://www.verae.com + · Book a call at verae.com + · app.verae.com +
+ +
+ ©2026, Verae Inc. + +
+ + + + + + + \ No newline at end of file diff --git a/build/html/peergos-making-yourself-audit-ready-with-verae-datacubes.pdf b/build/html/peergos-making-yourself-audit-ready-with-verae-datacubes.pdf index 97fb5ab..b9d9add 100644 Binary files a/build/html/peergos-making-yourself-audit-ready-with-verae-datacubes.pdf and b/build/html/peergos-making-yourself-audit-ready-with-verae-datacubes.pdf differ diff --git a/build/html/search.html b/build/html/search.html index 978d2e7..3f6cc49 100644 --- a/build/html/search.html +++ b/build/html/search.html @@ -7,13 +7,15 @@ Search — Making yourself audit-ready with Verae DataCubes - + + - + + @@ -28,9 +30,68 @@ - +
+ +
- ©2026, Verae. - - | - Powered by Sphinx 9.1.0 - & Alabaster 1.0.0 + ©2026, Verae Inc.
+ \ No newline at end of file diff --git a/build/html/searchindex.js b/build/html/searchindex.js index e731739..860b101 100644 --- a/build/html/searchindex.js +++ b/build/html/searchindex.js @@ -1 +1 @@ -Search.setIndex({"alltitles":{"A. Scope and data map":[[2,"a-scope-and-data-map"]],"Architecture (audit interview)":[[0,null]],"Audit-ready checklist":[[2,null]],"B. Keys and encryption":[[2,"b-keys-and-encryption"]],"BAAs and DPAs when ciphertext has no host keys":[[1,null]],"C. Access":[[2,"c-access"]],"Claim to check":[[5,"claim-to-check"]],"D. Integrity and backup":[[2,"d-integrity-and-backup"]],"E. Logging":[[2,"e-logging"]],"EU funding / NLnet":[[5,"eu-funding-nlnet"]],"Encrypted filesystem + hashed IPFS (design)":[[5,"encrypted-filesystem-hashed-ipfs-design"]],"F. Contracts (counsel)":[[2,"f-contracts-counsel"]],"G. Independent audit of you":[[2,"g-independent-audit-of-you"]],"GDPR (EU/UK) \u2014 processor vs technical measure":[[1,"gdpr-eu-uk-processor-vs-technical-measure"]],"HIPAA (US) \u2014 Business Associate":[[1,"hipaa-us-business-associate"]],"Hosted instance location":[[5,"hosted-instance-location"]],"How to use this pack":[[3,null]],"Independent security audits (Europe)":[[5,"independent-security-audits-europe"]],"Making yourself audit-ready with Verae DataCubes":[[4,null]],"NATS operators":[[1,"nats-operators"]],"Not verified / do not claim":[[5,"not-verified-do-not-claim"]],"Peergos verification (what was actually audited)":[[5,null]],"The operator statement":[[1,"the-operator-statement"]],"What we verified about Peergos (EU)":[[4,"what-we-verified-about-peergos-eu"]],"What \u201cmaking yourself audit-ready\u201d means":[[1,"what-making-yourself-audit-ready-means"]]},"docnames":["architecture","baa-dpa","checklist","howto","index","verification"],"envversion":{"sphinx":66,"sphinx.domains.c":3,"sphinx.domains.changeset":1,"sphinx.domains.citation":1,"sphinx.domains.cpp":9,"sphinx.domains.index":1,"sphinx.domains.javascript":3,"sphinx.domains.math":2,"sphinx.domains.python":4,"sphinx.domains.rst":2,"sphinx.domains.std":2},"filenames":["architecture.rst","baa-dpa.rst","checklist.rst","howto.rst","index.rst","verification.rst"],"indexentries":{},"objects":{},"objnames":{},"objtypes":{},"terms":{"A":[1,4],"At":0,"Both":5,"Do":5,"How":4,"I":2,"In":0,"It":[1,4,5],"No":5,"Not":4,"That":[1,4,5],"The":[4,5],"They":4,"This":[1,2,4,5],"Those":4,"What":[2,5],"Where":[],"You":1,"access":[1,4],"actual":[1,2,3,4],"add":1,"address":[2,4,5],"admin":[1,2],"adversari":1,"advic":1,"align":4,"amsterdam":[4,5],"analysi":[1,2],"annex":[1,2],"anyon":1,"append":[0,2,5],"applic":[2,5],"architectur":[3,4,5],"argument":1,"art":[1,2],"associ":4,"assur":[1,2],"attach":[2,3,4],"attribut":1,"audit":3,"auditor":3,"author":2,"auto":1,"b":[4,5],"ba":[1,2],"baa":[3,4,5],"backup":[0,1,4,5],"base":[0,1,5],"becaus":1,"befor":[1,2],"berlin":[4,5],"bill":1,"bit":5,"blob":1,"block":[0,1,2,4,5],"bodi":[0,1,2],"book":4,"box":5,"broker":[0,1,4],"busi":4,"buy":1,"byte":5,"c":4,"can":[1,4],"cap":5,"certif":[2,3,4,5],"certifi":[4,5],"chain":[0,2,5],"champ":[1,5],"chang":1,"chapter":[2,5],"check":[0,1,2,4],"checklist":[3,4],"chunk":[0,5],"cid":[0,2],"ciphertext":[0,2,3,4,5],"cite":1,"claim":[3,4],"clear":[0,1],"client":[0,1,4,5],"cluster":1,"code":[2,4,5],"com":5,"companion":4,"complianc":3,"compon":[1,2,4],"compromis":5,"conclus":5,"conduit":1,"config":2,"conflat":5,"consol":2,"content":[0,1,2,4,5],"contract":[1,4],"control":[0,3,4],"converg":5,"convers":1,"copi":1,"counsel":[3,4],"cover":1,"crash":5,"creat":1,"crypto":5,"cryptograph":5,"cryptre":[0,1,2,3,4,5],"crystal":5,"cube":[0,2,5],"cure53":[1,2,4,5],"curious":0,"custodi":[1,3],"custom":[1,2,5],"d":4,"data":[1,3,4,5],"datacub":[0,1,5],"de":[1,5],"decrypt":1,"delay":1,"delet":1,"depend":1,"design":[1,4],"dest":0,"destin":[0,1],"detect":1,"determin":[1,2],"diagram":2,"diff":2,"differ":5,"directori":[0,2],"disk":[0,1,2,5],"distinguish":1,"distribut":[0,1,5],"doc":[0,3,4],"document":[1,2,4,5],"doe":[1,2,4,5],"dpa":[1,2,5],"dpas":[3,4,5],"drive":[2,3],"drop":1,"dual":[0,2],"e":4,"e2e":0,"ed25519":2,"elev":5,"encrypt":[0,1,4],"endpoint":[0,1,2],"engag":2,"entiti":[1,2],"ephi":1,"europ":4,"european":5,"evalu":[1,3,4,5],"event":2,"everi":[1,5],"evid":[1,2,3],"exist":[2,5],"export":[1,2],"expos":1,"exposur":5,"extrem":5,"f":4,"fact":5,"fals":5,"fetch":[0,2],"filenam":1,"filesystem":4,"fill":3,"fine":5,"finish":4,"firm":[4,5],"first":2,"fix":5,"flow":[2,3],"form":1,"free":[],"full":[4,5],"fund":4,"fundament":5,"g":4,"gdpr":4,"georgelambert":[0,3,4],"germani":[1,5],"git":[3,4],"github":5,"give":3,"googl":2,"govern":5,"grain":5,"grant":5,"graph":[0,1],"guidanc":1,"hash":[0,1,2,4],"health":[3,4],"hhs":1,"hidden":5,"high":5,"hipaa":[2,4,5],"histori":[1,2],"hold":[1,2],"honest":0,"horizon":5,"host":[0,2,3,4],"hpke":[0,1,2,4],"hsm":[0,1,2],"html":[0,3,4],"https":[0,3,4,5],"hybrid":5,"ident":1,"ii":[2,4,5],"immut":5,"implement":5,"independ":[1,4],"infrastructur":1,"inspect":[1,2],"instanc":[1,3,4],"integr":[0,4,5],"intellig":1,"interview":[3,4,5],"invoic":1,"ip":[1,2],"ipf":[0,1,2,4],"iso":[2,3,4,5],"issu":5,"item":2,"joiner":2,"jsonl":[0,2,5],"june":5,"jurisdict":1,"k":[1,2],"kem":5,"key":[0,3,4,5],"lab":2,"label":[1,3,5],"lack":0,"later":1,"layer":5,"leav":1,"leaver":2,"legal":[1,2,5],"like":1,"list":[1,2],"live":[0,1,3,4],"locat":[1,4],"log":[1,4],"login":2,"look":1,"lookup_id":2,"low":5,"maintain":1,"manag":[4,5],"mani":1,"map":4,"marchon":[3,4],"master":5,"match":1,"may":[1,5],"mean":[0,4],"measur":4,"media":1,"memo":1,"messag":3,"metadata":[1,2],"mib":5,"minim":4,"misconfigur":1,"ml":5,"moder":5,"mostly":5,"mover":2,"must":5,"n":[1,2],"name":[0,2,5],"narrow":1,"nat":[0,2,4],"need":[1,2,5],"net":[1,5],"netherland":5,"never":[1,5],"new":2,"ngi":5,"nl":1,"nlnet":4,"node":[1,5],"notic":5,"nov":5,"npe":[0,2,3,4],"ns1":[1,2,3,5],"ocr":1,"offic":2,"offsit":1,"onli":[0,1,2,3,5],"opaqu":[0,1],"open":[4,5],"oper":[2,4],"org":[0,2,3,4,5],"organiz":4,"outcom":[],"overst":5,"pack":[1,4,5],"pad":5,"parti":1,"pass":5,"passthrough":0,"path":2,"pdf":5,"pdfs":[2,3],"peergo":[0,1,2,3],"pentest":[1,3,4,5],"person":[1,2],"pfc":[0,3,4],"pfc_require_auth":2,"phi":[0,1,2],"phrase":[],"pick":2,"plaintext":[0,1,2],"platform":5,"point":3,"pointer":5,"polici":2,"poly1305":5,"post":5,"practic":1,"prepar":4,"prev":2,"primari":5,"privaci":5,"privat":[1,2,3],"problem":5,"process":[1,2,5],"processor":4,"product":[0,5],"program":[1,2],"programm":5,"protocol":5,"provid":1,"public":[0,1,2,3,4,5],"publish":[4,5],"radic":[4,5],"random":[1,5],"re":[0,2],"read":[0,1,3,5],"readi":3,"reason":1,"receipt":2,"receiv":[1,5],"record":5,"recov":2,"region":1,"registrar":[2,4,5],"registri":2,"reject":2,"remain":0,"replica":1,"report":[1,2,4,5],"report_peergo":5,"resid":1,"rest":[0,1,4,5],"restor":[0,1,2,5],"reus":1,"reveal":2,"review":[4,5],"risk":[1,2],"ropa":[1,5],"ros":[1,2,5],"rout":[0,1,2],"router":0,"s":[1,2,4,5],"salsa20":5,"scope":[1,4],"screenshot":2,"secur":[1,3,4],"see":[0,1,4,5],"self":[1,5],"sep":5,"separ":2,"server":[1,4,5],"sha":2,"share":5,"shown":5,"sibl":5,"side":4,"sign":[1,2,5],"signatur":5,"size":0,"sm":2,"soc":[1,2,3,4,5],"social":1,"sourc":[4,5],"specialist":4,"sso":2,"standard":5,"state":5,"statement":4,"status":[],"stay":0,"still":1,"storag":[1,2,4],"store":5,"stori":4,"subject":[0,1],"suit":0,"summari":2,"support":[1,4,5],"surfac":[3,4],"surveil":2,"symmetr":5,"sync":3,"system":[2,3,4,5],"tabl":4,"tamper":1,"tape":[0,2],"technic":[3,4,5],"test":2,"therefor":1,"ticket":2,"totp":2,"touch":1,"transit":[0,1],"transmit":1,"treat":1,"tree":[3,5],"true":1,"trust":4,"turn":5,"two":[3,4,5],"type":[2,4,5],"ui":5,"uk":4,"union":5,"unless":1,"unsign":2,"untrust":[0,1,4],"unwrap":2,"updat":5,"us":4,"use":[1,2,4,5],"user":[2,3],"usernam":[1,2],"v":5,"v1":[0,3,4],"vendor":[1,3],"vera":[0,5],"verif":[1,2,3,4],"verifi":[0,1,2],"via":5,"vm":2,"vs":[2,4],"web":5,"whether":1,"win":2,"window":2,"without":[1,2],"work":[2,4,5],"write":5,"writer":1,"written":[0,1,2,5],"x25519":5,"xor":2,"year":[],"yes":[0,4]},"titles":["Architecture (audit interview)","BAAs and DPAs when ciphertext has no host keys","Audit-ready checklist","How to use this pack","Making yourself audit-ready with Verae DataCubes","Peergos verification (what was actually audited)"],"titleterms":{"A":2,"How":3,"Not":5,"The":1,"What":[1,4],"access":2,"actual":5,"architectur":0,"associ":1,"audit":[0,1,2,4,5],"b":2,"baa":1,"backup":2,"busi":1,"c":2,"check":5,"checklist":2,"ciphertext":1,"claim":5,"contract":2,"counsel":2,"d":2,"data":2,"datacub":4,"design":5,"dpas":1,"e":2,"encrypt":[2,5],"eu":[1,4,5],"europ":5,"f":2,"filesystem":5,"fund":5,"g":2,"gdpr":1,"hash":5,"hipaa":1,"host":[1,5],"independ":[2,5],"instanc":5,"integr":2,"interview":0,"ipf":5,"key":[1,2],"locat":5,"log":2,"make":[1,4],"map":2,"mean":1,"measur":1,"nat":1,"nlnet":5,"oper":1,"pack":3,"peergo":[4,5],"processor":1,"readi":[1,2,4],"scope":2,"secur":5,"statement":1,"technic":1,"uk":1,"us":1,"use":3,"vera":4,"verif":5,"verifi":[4,5],"vs":1}}) \ No newline at end of file +Search.setIndex({"alltitles":{"2019 \u2014 Cure53, Berlin, Germany":[[15,"cure53-berlin-germany"]],"2024 \u2014 Radically Open Security B.V., Amsterdam":[[15,"radically-open-security-b-v-amsterdam"]],"A. Scope and honesty":[[5,"a-scope-and-honesty"]],"Append-only at the cube layer":[[7,"append-only-at-the-cube-layer"]],"Architecture for an audit interview":[[0,null]],"Audit-ready checklist":[[5,null]],"B. Data in transit":[[5,"b-data-in-transit"]],"BAAs, DPAs, and ciphertext without host keys":[[1,null]],"Bundles":[[16,"bundles"]],"C. Data at rest":[[5,"c-data-at-rest"]],"Closing reminder":[[6,"closing-reminder"]],"Component assurance versus the organization\u2019s report":[[1,"component-assurance-versus-the-organization-s-report"]],"Content-addressed blocks":[[7,"content-addressed-blocks"]],"Contents":[[14,null]],"D. Timestamping":[[5,"d-timestamping"]],"Data at rest":[[10,"data-at-rest"]],"Data in transit":[[10,"data-in-transit"]],"E. Write-once archive":[[5,"e-write-once-archive"]],"Education (public professional listings)":[[3,"education-public-professional-listings"]],"Encryption at rest \u2014 IPFS blocks and Peergos":[[7,null]],"Error handling without leaking content":[[8,"error-handling-without-leaking-content"]],"Executive summary":[[10,null]],"F. Access and change":[[5,"f-access-and-change"]],"FINRA BrokerCheck (CRD 5052743)":[[3,"finra-brokercheck-crd-5052743"]],"First registration wins":[[16,"first-registration-wins"]],"G. Contracts (counsel)":[[5,"g-contracts-counsel"]],"GDPR \u2014 processor versus technical measure":[[1,"gdpr-processor-versus-technical-measure"]],"George Lambert":[[2,null]],"Global timestamped receipts":[[10,"global-timestamped-receipts"],[16,null]],"H. Independent examination of this organization":[[5,"h-independent-examination-of-this-organization"]],"HIPAA \u2014 Business Associate":[[1,"hipaa-business-associate"]],"Hosted Peergos versus self-hosted DataCubes":[[15,"hosted-peergos-versus-self-hosted-datacubes"]],"How cubes move into the archive":[[13,"how-cubes-move-into-the-archive"]],"How to present these reports to an auditor":[[15,"how-to-present-these-reports-to-an-auditor"]],"How to use this briefing":[[12,null]],"Identity planes":[[0,"identity-planes"]],"Internet technical architect, from 1994":[[2,"internet-technical-architect-from-1994"]],"James H. Garfinkel":[[3,null]],"Lineage":[[11,"lineage"]],"Making yourself audit-ready with Verae DataCubes":[[14,null]],"NATS operators":[[1,"nats-operators"]],"NATS remains untrusted":[[0,"nats-remains-untrusted"]],"Name and sources":[[3,"name-and-sources"]],"New Hampshire public office":[[2,"new-hampshire-public-office"]],"Other cryptographic publications":[[4,"other-cryptographic-publications"]],"Peergos on top of IPFS":[[7,"peergos-on-top-of-ipfs"]],"Peergos security evaluations in Europe":[[15,null]],"Peergos, evaluated in Europe":[[10,"peergos-evaluated-in-europe"]],"Point-to-point encryption":[[8,"point-to-point-encryption"]],"Proof of existence versus proof of custody":[[11,"proof-of-existence-versus-proof-of-custody"]],"Purpose":[[9,"purpose"]],"Relation to classical WORM":[[13,"relation-to-classical-worm"]],"Role":[[2,"role"]],"Role at Verae":[[3,"role-at-verae"],[4,"role-at-verae"]],"Secure communications \u2014 data in transit":[[8,null]],"Sequence":[[16,"sequence"]],"Stuart Haber":[[4,null]],"Surety, 1994: first commercial blockchain":[[4,"surety-1994-first-commercial-blockchain"]],"Tamper-evident restore":[[7,"tamper-evident-restore"]],"The DataCube as a container":[[9,"the-datacube-as-a-container"]],"The Verae DataCube Server Solution":[[9,null]],"The boundary":[[17,"the-boundary"]],"The deletion problem":[[13,"the-deletion-problem"]],"The digital bundle":[[11,"the-digital-bundle"]],"The picture":[[0,"the-picture"]],"The problem":[[7,"the-problem"],[8,"the-problem"]],"The public-key directory":[[8,"the-public-key-directory"]],"The scientific work":[[4,"the-scientific-work"]],"The technical fact":[[1,"the-technical-fact"]],"The tools":[[17,"the-tools"]],"Two deployment patterns":[[11,"two-deployment-patterns"]],"Two information states, one operational picture":[[9,"two-information-states-one-operational-picture"]],"Verae Inc \u2014 contact":[[6,null]],"Verae as timestamping service":[[1,"verae-as-timestamping-service"]],"Verae global timestamping":[[10,"verae-global-timestamping"]],"Verae global timestamping \u2014 a cross-blockchain receipt":[[11,null]],"Visible routing":[[8,"visible-routing"]],"Walkthrough, in the order an examiner usually asks":[[0,"walkthrough-in-the-order-an-examiner-usually-asks"]],"What Verae provides \u2014 and what it does not":[[17,null]],"What a Verae DataCube Server Solution does":[[10,"what-a-verae-datacube-server-solution-does"]],"What a Verae receipt is":[[16,"what-a-verae-receipt-is"]],"What a disk operator sees":[[7,"what-a-disk-operator-sees"]],"What a receipt does not prove":[[16,"what-a-receipt-does-not-prove"]],"What is registered, and what is not":[[16,"what-is-registered-and-what-is-not"]],"What the organization must still do":[[17,"what-the-organization-must-still-do"]],"What the server solution is not":[[9,"what-the-server-solution-is-not"]],"What this briefing is, and is not":[[10,"what-this-briefing-is-and-is-not"]],"What this does, and does not, satisfy":[[7,"what-this-does-and-does-not-satisfy"],[8,"what-this-does-and-does-not-satisfy"],[11,"what-this-does-and-does-not-satisfy"],[13,"what-this-does-and-does-not-satisfy"]],"What to hand the examiner":[[0,"what-to-hand-the-examiner"]],"What was evaluated":[[15,"what-was-evaluated"]],"What \u201ccross-blockchain\u201d means here":[[11,"what-cross-blockchain-means-here"]],"What \u201cdesigned under funding from Cure53 / ROS\u201d is not":[[15,"what-designed-under-funding-from-cure53-ros-is-not"]],"What \u201cserver\u201d means in practice":[[9,"what-server-means-in-practice"]],"What \u201cwrite-once Iceberg\u201d means in this solution":[[13,"what-write-once-iceberg-means-in-this-solution"]],"Why hashes are not enough by themselves":[[16,"why-hashes-are-not-enough-by-themselves"]],"Why the distinction matters in an exam":[[17,"why-the-distinction-matters-in-an-exam"]],"Why this biography is in the briefing":[[2,"why-this-biography-is-in-the-briefing"],[3,"why-this-biography-is-in-the-briefing"],[4,"why-this-biography-is-in-the-briefing"]],"Write-once Iceberg archive":[[10,"write-once-iceberg-archive"],[13,null]]},"docnames":["architecture","baa-dpa","bio-george-lambert","bio-james-garfinkel","bio-stuart-haber","checklist","contact","data-at-rest","data-in-transit","datacube-server","executive","global-timestamping","howto","iceberg-archive","index","peergos-eu-evaluations","timestamped-receipts","what-verae-provides"],"envversion":{"sphinx":66,"sphinx.domains.c":3,"sphinx.domains.changeset":1,"sphinx.domains.citation":1,"sphinx.domains.cpp":9,"sphinx.domains.index":1,"sphinx.domains.javascript":3,"sphinx.domains.math":2,"sphinx.domains.python":4,"sphinx.domains.rst":2,"sphinx.domains.std":2},"filenames":["architecture.rst","baa-dpa.rst","bio-george-lambert.rst","bio-james-garfinkel.rst","bio-stuart-haber.rst","checklist.rst","contact.rst","data-at-rest.rst","data-in-transit.rst","datacube-server.rst","executive.rst","global-timestamping.rst","howto.rst","iceberg-archive.rst","index.rst","peergos-eu-evaluations.rst","timestamped-receipts.rst","what-verae-provides.rst"],"indexentries":{},"objects":{},"objnames":{},"objtypes":{},"terms":{"17a":[11,13],"1980s":4,"1990s":4,"27th":2,"44th":2,"4th":4,"A":[0,1,3,4,6,7,8,9,10,11,13,14,15,16,17],"An":[7,8,11,13],"As":3,"At":[2,9],"Both":[7,10,11,15],"Do":[1,3,12],"Each":[8,9,10],"For":[7,8,11,13,16],"He":[2,4],"His":2,"How":[0,4,11,14,17],"I":[4,5,10,11,15],"If":[1,6,7,12,17],"In":[2,3,9,11,14],"It":[0,1,2,4,7,8,9,10,13,14,15,16,17],"No":[10,13,17],"Not":0,"Off":13,"On":[0,13],"Other":[3,14],"Our":15,"That":[1,2,3,4,7,8,10,11,15,16],"The":[2,3,6,10,14,15,16],"There":[0,7,15],"These":7,"They":[1,2,3,7,9,10,11,12,15,16,17],"This":[0,1,2,3,4,5,6,8,10,13,14,17],"Those":[1,2,3,4,8,10,13,15,17],"To":10,"We":15,"What":[12,14],"When":[10,15],"Where":0,"With":4,"You":[],"Your":6,"abbott":3,"abil":[11,17],"abl":[8,9,10],"abov":10,"academ":4,"accept":17,"access":[1,4,7,8,9,11,14,16,17],"account":[1,2,5,13],"accur":15,"acm":4,"across":7,"act":13,"action":[0,17],"activ":6,"actual":[1,2,5,7,10,15,17],"add":7,"addit":11,"address":[0,5,6,8,9,10,14,15,17],"admin":[0,1,2,5,9,13,17],"administr":[9,11,13,17],"admiss":8,"adversari":[1,15],"advic":1,"advis":3,"advisor":3,"advisori":3,"age":13,"aggreg":8,"agreement":[8,9,17],"ai":[8,9,16],"aicpa":17,"aim":[3,11],"airlin":2,"algorithm":[0,5,8],"align":10,"allow":[13,16],"alon":[6,10,11,13],"along":9,"aloud":12,"also":[2,3,6,8,9,10,16],"alter":[4,10],"alway":1,"amsterdam":[10,14],"analog":[4,11],"analysi":[1,5,9,17],"anchor":11,"ani":[0,3,8,9,10,11,12,13,15,16],"annex":[1,5,7,8],"anonym":8,"anoth":[7,8,10],"answer":[2,8,11,13,17],"anyon":[1,8,10,11,12,16,17],"anyway":[3,11],"api":[2,6,8,13],"app":6,"appear":[3,6],"append":[0,14],"appli":[4,15,16,17],"applianc":8,"applic":[2,4,5,7],"appropri":[1,17],"approv":[8,10,17],"approxim":8,"april":3,"architect":[12,14],"architectur":[1,2,7,9,10,12,14,15,17],"archiv":[0,1,2,4,7,9,11,14,16,17],"argu":16,"argument":1,"around":9,"arriv":8,"art":[],"articl":[1,4,5],"artifact":11,"ask":[2,7,11,14,17],"assembl":[2,9],"assessor":17,"associ":[7,9,10,14,17],"assum":8,"assur":[11,14,15,17],"attach":[0,1,5,9,10,11,12,15,16,17],"attest":[6,10,17],"attribut":1,"audit":[6,7,8,9,10,12,15,17],"auditor":[6,10,12,14,17],"authent":[3,5],"author":[0,5,7,13,15,16,17],"auto":[],"automat":[1,7],"avail":[7,8,13],"avenu":3,"averag":4,"b":[3,10,14],"ba":[1,5,12],"baa":[12,14,15],"back":[4,9,12,13],"backend":15,"background":[6,10,17],"backup":[1,5,7,9,10,13],"balanc":8,"ballotreadi":2,"bare":16,"base":[1,3,8,10,15],"bat":4,"bayer":[4,11],"becaus":[1,3,4,13,15,17],"becom":[0,11,17],"befor":[0,1,5,17],"begin":2,"bell":4,"bellcor":4,"belong":[7,8],"berlin":[1,10,14,17],"beryl":3,"besid":[9,11],"best":[8,10],"bill":[1,7],"binari":9,"bind":0,"biographi":[12,14],"bit":[4,7,8,9,10,11,16,17],"bitcoin":[4,11],"black":15,"blake2b":7,"blake3":7,"blob":1,"block":[1,3,6,9,10,13,14,15,16],"blockchain":[3,9,10,14],"board":[2,12],"bodi":[0,1,5,8,9,10,17],"book":[6,11,16],"borland":2,"born":2,"bottom":[6,13],"bounc":8,"bound":[11,16],"boundari":14,"box":[5,10,15],"brief":[6,14,17],"broadcast":8,"broader":4,"broker":[0,1,2,3,5,8,9,13],"brokercheck":14,"brought":9,"bug":0,"build":[2,4,7,10,12],"builder":2,"built":[2,4,9,12,13,17],"bundl":[5,8,10,14],"busi":[6,7,9,10,14,17],"button":13,"buy":[],"bypass":8,"byte":[7,9,10,11],"c":[2,14],"call":[3,6,11],"campaign":2,"can":[0,1,2,4,5,7,8,9,10,11,12,13,16,17],"candid":2,"cap":[],"capabl":[7,11,13,16],"captur":[8,11],"care":16,"career":2,"carri":[0,3,5,8,9,10,13,16],"case":13,"cash":4,"catch":10,"categori":17,"cc6":[7,8],"cco":[3,4,10],"ccs":4,"central":[0,5,9,10,11,16],"ceo":3,"certif":[3,4,5,10,11,12,14,15,16,17],"certifi":[2,4,6,10,11,12,15,17],"chacha20":8,"chain":[0,3,4,5,7,9,10,11,13,16],"chair":10,"champ":[1,7],"champion":10,"chang":[0,1,3,7,9,11,14,17],"channel":[8,11,13],"chapter":[1,3,5,6,7,9,10,12,14,16,17],"check":[0,1,5,7,10,11,13,16,17],"checkabl":[11,13],"checkbox":12,"checklist":[12,14],"chief":2,"children":2,"choic":8,"chose":11,"chosen":[5,10,15],"chunk":[0,7,15],"cid":[0,7,13],"ciphertext":[0,5,7,8,9,10,14],"ciso":10,"citat":[4,11],"cite":[1,4,11],"citi":2,"claim":[3,4,5,8,10,11,13,15,16,17],"class":[3,8,10,13],"classic":[9,10,14],"classif":[11,16],"classifi":4,"clean":13,"clear":[0,1,7,9,15],"click":15,"client":[1,7,9,10],"clock":[11,16],"close":[7,13,14,16],"cloud":[9,13],"cluster":[],"co":[3,4,11],"code":[0,2,5,8,10,15],"codebas":8,"cold":7,"collaps":[0,11,17],"colleg":3,"collis":7,"collus":4,"com":[3,6,11,12,15],"combin":[13,15],"commerci":[2,3,11,14,16],"commit":[0,4,5,10,11,13,16],"communic":[4,6,10,12,14,17],"compact":4,"compani":[1,3,4,6],"companion":16,"comparison":13,"compil":3,"complement":13,"complet":[9,11,16],"complex":[4,11],"complianc":[3,4,10,11,13,16],"compliant":17,"compon":[0,5,10,14,15,17],"compromis":[10,13,15],"comput":4,"conclus":[],"concret":[8,17],"conduit":1,"confer":[4,13],"confidenti":[7,9],"config":[],"configur":[0,5,8,9,16,17],"confirm":[13,16],"conflat":7,"confus":12,"connect":2,"consequ":8,"consist":9,"consol":[0,5,6,11],"consortium":11,"constitut":7,"construct":[0,5,8],"consult":3,"contact":14,"contain":[3,13,14,17],"content":[0,1,5,9,10,15,16,17],"context":15,"continu":2,"contract":[1,2,8,14],"contractu":13,"control":[0,3,4,5,6,7,8,9,10,12,13,15,16,17],"conveni":[3,13],"convent":[13,16],"converg":7,"convers":[1,6,7,10],"cooki":0,"cooper":9,"coordin":13,"copi":[1,7,8,10,11,13,16,17],"core":3,"corpor":3,"correct":[13,15],"corrupt":7,"council":2,"counsel":[1,10,12,13,14],"court":13,"cover":[1,8,10,12,17],"cpa":[10,17],"crash":[10,15],"crd":14,"creat":[1,11,17],"creator":4,"credenti":[1,2,7,13],"criteria":17,"cross":[0,8,9,10,14,16],"crypto":[10,12,15],"cryptograph":[0,3,7,8,10,13,14,15,16,17],"cryptographi":[7,15],"cryptolog":[4,11],"cryptre":[0,1,2,7,9,15],"crystal":[10,15],"cto":2,"cube":[0,5,9,10,14,17],"cultur":4,"cure53":[1,10,14],"curios":8,"curious":[0,8,9,10],"current":[2,3,6,7],"custodi":[1,7,12,14,17],"custodian":[13,16],"custom":[0,1,3,4,5,7,9,10,11,13,15,16,17],"cycl":2,"d":14,"dark":17,"data":[0,1,4,7,9,13,14,15,16],"databas":11,"datacub":[0,2,3,5,6,7,8,11,12,13,16,17],"date":[0,4,5,7,10,11,13],"dave":[4,11],"day":[2,6,10,11],"de":15,"deal":[4,11],"dealer":[3,13],"decad":2,"decemb":[2,3],"decid":1,"deck":3,"declar":[7,12],"decrypt":[1,7,13],"dedic":3,"defens":10,"defin":4,"definit":7,"delay":[1,10],"delet":[0,1,5,9,10,11,14],"deliv":[8,9,10],"delphi":2,"demand":11,"demo":2,"depend":[1,4],"deploy":[9,14],"deprovis":17,"descend":4,"describ":[2,3,4,5,6,10,11,15],"descript":[2,3,5,9,16,17],"design":[1,2,4,5,7,8,10,11,13,14,16,17],"desir":16,"dest":0,"destin":[0,1,5,8,9,10,17],"destruct":13,"detail":10,"detect":[1,7,9],"determin":[1,5,10],"develop":2,"devic":8,"diagnos":8,"diagram":[0,1,5,12,17],"diff":[0,5,9],"differ":[7,11,15,16],"digit":[3,4,9,10,14,16,17],"diploma":2,"direct":[0,5,10,11],"directori":[0,2,3,5,7,9,14],"disagre":11,"disappear":11,"disclos":3,"disk":[0,1,4,5,9,10,12,13,14,16],"distinct":[14,16],"distinguish":[1,10],"distribut":[0,1],"district":2,"divid":9,"divis":9,"doc":[0,6,12],"document":[0,1,3,4,5,7,9,10,11,14,16,17],"doe":[0,1,2,3,4,5,6,9,14],"dpa":[1,5],"dpas":[12,14],"drawn":9,"drive":[0,5,12],"drop":[1,9,10],"dual":[5,7,13,17],"dure":[10,17],"e":14,"e2e":8,"earli":[4,13],"earlier":[3,16],"earliest":2,"easier":10,"econom":3,"ed25519":0,"edg":0,"edit":[6,14],"educ":14,"effici":[4,11],"eight":[4,11],"either":[2,9,10],"electron":4,"elev":[10,15],"elimin":1,"els":9,"email":1,"employ":3,"empti":[12,13],"enabl":[0,2,3],"encrypt":[0,1,2,4,9,10,11,13,14,15,17],"end":[2,3,7],"endors":3,"endpoint":[0,1,5,8,9,10,17],"engag":[5,6,10,15],"engin":[2,5,12],"enough":[4,8,10,11,14],"ensur":3,"enter":7,"enterpris":[4,11],"entiti":[1,5,10,17],"entitl":3,"entri":9,"envelop":[8,16],"ephi":[1,7,8],"equal":7,"equival":[5,9],"era":2,"eras":[10,11,13],"error":[0,5,14,17],"ethic":2,"eu":[1,10,15,17],"europ":14,"european":[9,15],"evalu":[0,1,5,9,12,14,17],"even":[4,7,13,16],"event":[3,13,17],"ever":11,"everi":[1,4,6,7,8,9,10,13],"evid":[1,3,5,9,10,12,13,14,15,16,17],"evidenc":5,"exact":[16,17],"exam":[3,4,11,13,14],"examin":[3,8,9,10,11,12,13,14,15,16,17],"exampl":[5,7],"excerpt":0,"exchang":17,"execut":[12,14,17],"exempt":1,"exist":[0,1,2,4,5,7,8,9,10,13,14,16,17],"experi":8,"expert":15,"explicit":8,"export":[1,2,5,9,13],"expos":1,"exposur":[10,15],"extend":[5,13],"extern":[0,10,11,13],"extra":11,"extract":9,"extrem":[10,15],"f":14,"fabric":[0,3,5,9],"face":3,"facebook":3,"facil":7,"fact":[2,3,7,13,14,15,16],"fail":[7,12,15],"failur":[8,9,10,13],"faith":9,"fals":16,"famili":[2,3],"fastnet":2,"fatal":15,"fault":4,"fetch":[0,7,10,13],"fieldwork":10,"file":[0,3,6,7,8,9,10,11,13,15,16,17],"filenam":[1,7],"filesystem":[7,11,15],"fill":12,"financi":3,"find":[9,10,15],"fine":13,"fingerprint":[0,1,3,4,5,6,9,10,11,16,17],"finish":10,"finra":[11,14,17],"fire":13,"firm":[10,15,17],"first":[0,5,9,10,11,12,13,14,17],"five":[12,17],"fix":[10,15],"flag":[9,13,16],"flaw":15,"flightlookup":2,"flow":[0,5],"folder":[7,9,13],"folklor":5,"follow":[3,7,8,9,10,11],"footer":[6,14],"forbid":13,"forc":[2,11],"forgeri":16,"form":[1,2,6,11,15],"format":13,"forward":[4,8],"found":[2,4,10,11],"foundat":4,"founder":[2,3,4,11],"four":9,"free":8,"freez":13,"full":[9,10,15],"function":[7,17],"fund":14,"fundament":[10,15],"futur":7,"g":14,"garfinkel":14,"garfinkl":3,"gate":0,"gdpr":[14,16],"general":3,"generat":2,"georg":14,"georgelambert":[0,2,6,12],"germani":[1,10,14],"get":16,"git":[6,12],"github":15,"give":[6,9,10,11,12,17],"given":[0,3,7,8,11],"global":14,"go":0,"goe":16,"goldenwar":2,"good":[7,8,15],"googl":0,"govern":[2,15],"grain":[],"grang":2,"grant":15,"graph":[0,1,7],"guidanc":1,"h":14,"haber":[3,11,14,16],"hamilton":3,"hampshir":14,"hand":[4,14,16,17],"handl":[10,14,17],"hang":15,"happen":[16,17],"hard":2,"hash":[0,1,4,5,7,9,10,11,13,14,17],"hasn":4,"head":13,"health":[0,12],"held":[8,11],"help":7,"hhs":1,"hidden":[],"high":[2,10,15],"hillsborough":2,"hipaa":[5,6,7,8,9,10,12,14,15,16,17],"hire":17,"histor":[2,4],"histori":[0,1,2,3,5,7,9,11,13,17],"hkdf":8,"hold":[0,1,5,7,9,10,11,13,16,17],"holder":[8,13],"home":[2,11],"homepag":3,"honest":[0,3,4,8,9,10,13,16],"honesti":[4,8,14],"hope":7,"horizon":15,"hornor":3,"host":[0,5,7,9,10,13,14,17],"hostil":7,"hour":17,"hous":2,"howev":10,"hpke":[0,1,5,8,9],"hsm":[0,1,5,7,8],"html":[0,6,12,14],"https":[0,2,3,6,12,15],"human":15,"hybrid":[7,8],"iapd":3,"iar":3,"iceberg":[0,1,2,5,9,11,12,14],"icon":9,"id":[5,13,16],"idea":[4,13],"ident":[1,7,14,15,16],"identifi":[0,2,3,7,8,9,11,15,17],"ii":[2,4,5,10,12,15,17],"imag":[8,9,10,16,17],"immedi":7,"immut":[7,13],"implement":[2,9,10,13,15,17],"import":2,"improv":4,"inc":[3,14],"incid":17,"includ":[3,4,8,9,13,14,15],"incorrect":15,"independ":[1,4,6,7,10,13,14,15,17],"index":10,"individu":3,"individual_5052743":3,"industri":3,"inform":[2,3,10,14,16,17],"infrastructur":[1,6,8,10,11,17],"inherit":11,"innov":15,"insid":[10,11,16],"inspect":[0,1,5,17],"inspector":17,"instal":[5,10,17],"instanc":[0,1,9,12,13],"instead":[4,8,13],"insuffici":13,"insur":3,"intaglio":3,"integr":[2,3,7,9,10,12,15],"intellectu":16,"intellig":1,"intend":[10,16],"interact":4,"interfac":15,"interim":2,"internal":[0,5,6,9,10,11,16,17],"internat":3,"internet":[12,14],"intersect":2,"interview":[7,8,9,14],"introduc":4,"invent":[4,6],"inventor":4,"inventori":8,"invest":3,"investig":10,"invoic":1,"ip":[1,2,5,7],"ipf":[0,1,5,9,10,13,14,15,17],"ism":[7,12,15,17],"iso":[1,5,6,7,8,10,12,15,16,17],"issu":[1,4,9,10,11,13,15,16],"item":5,"jame":14,"januari":3,"jersey":4,"job":[5,9,13],"joiner":5,"journal":[4,11],"jsonl":7,"june":[10,15],"jurisdict":1,"k":[0,1,5,17],"keep":[4,7,12],"kem":7,"kent":3,"key":[0,2,4,5,7,9,10,12,13,14,17],"kind":7,"know":[0,2,3,7],"knowledg":4,"known":7,"lab":[0,4,5,8],"label":[0,1,5,7,15,17],"lack":[],"lambert":14,"languag":[15,17],"laptop":13,"last":[5,7,11,16,17],"late":4,"latenc":11,"later":[1,2,8,9,10,12,13,16,17],"law":3,"lawyer":7,"layer":[9,14,15],"layout":13,"leak":[0,7,9,14],"leav":[1,7,8,16,17],"leaver":[5,17],"legal":[1,5,7,9,10,11,13,16,17],"legisl":2,"legitim":[8,13],"less":[9,17],"let":[1,4,7,12],"letter":[4,6,11,17],"level":7,"licens":17,"lifecycl":13,"like":[1,2],"line":[2,3],"lineag":14,"link":[0,2,4,5,9,10,11],"list":[0,1,2,5,8,12,14,15],"listen":0,"litchfield":2,"live":[0,1,3,4,7,10,11,12,13,15],"llc":[2,3],"load":8,"local":[7,11],"locat":[1,15],"lock":[5,13],"log":[0,1,5,7,8,9,10,11,13,16,17],"login":[0,5,11],"long":[3,13],"longer":[7,10],"look":[1,2,3,4,8,12,15],"lookup":[0,5,8],"lookup_id":[],"lost":[7,9],"low":[10,11,15],"lpl":3,"machin":[7,8,16],"machineri":9,"main":2,"maintain":1,"make":[2,4,6,7,8,9,10,11,12,17],"malici":13,"manag":17,"mani":[1,15],"map":[5,14],"march":3,"marchon":[6,12],"mark":[4,15],"market":[3,10],"master":[0,15],"match":[1,3,8,10,11],"matter":[7,8,9,11,14,16],"may":[1,8,10,11,13,15,16],"mean":[7,14,15],"measur":14,"mechan":10,"media":[1,4,9,10,13,16],"medium":[11,16],"meet":[5,12,13,17],"memo":1,"merkl":[4,11,16],"messag":[0,2,5,8,9,10,13,16,17],"metadata":[0,1,5,8,9,10,11,13,15,16],"metaphor":4,"method":4,"mib":7,"million":2,"minim":15,"minimum":4,"minut":[2,12],"mis":9,"misconfigur":1,"mix":0,"ml":7,"mode":[5,8,9,13],"model":[4,8,13,15,16,17],"moder":[10,15],"moment":2,"money":2,"moral":12,"morristown":4,"mostly":[10,15],"motiv":3,"move":[2,5,7,9,10,14],"mover":5,"mpwm":3,"much":11,"multi":4,"municip":2,"must":[0,7,8,9,10,11,14,15],"n":[0,1,5,17],"nakamoto":[4,11],"name":[0,1,4,5,7,8,9,10,11,13,14,15,17],"narrat":3,"narrow":[1,8,15],"nat":[5,9,14],"nation":[2,3],"necessarili":9,"need":[1,7,8,9,11,13,16],"neither":[7,10,11],"net":[1,15],"netherland":[10,15],"netmast":2,"network":[0,2,8,9,17],"never":[1,7,8,13,16],"new":[0,3,4,5,9,11,13,14,16,17],"next":[11,17],"ngi":15,"nice":17,"nl":[],"nlnet":15,"nobodi":[7,17],"node":[1,5,7,9,11],"non":[11,13],"none":13,"notari":[4,16],"note":3,"noth":11,"notic":[7,13,15,17],"nov":[],"novemb":[3,10,15],"now":4,"nowher":9,"npe":[0,12],"ns1":15,"ntp":16,"number":[3,4,6,9,14],"ny":3,"object":[0,3,4,5,7,9,10,11,13,16,17],"oblig":11,"obtain":10,"obvious":4,"occur":17,"ocr":[1,10,17],"octob":3,"offer":9,"offic":[0,5,13,14,17],"offici":2,"offlin":[10,15],"offsit":7,"often":[10,11],"old":[13,16],"oldest":4,"onc":[0,2,7,9,11,14,16],"one":[0,4,6,7,8,10,11,13,14,16,17],"onli":[0,1,2,3,4,5,8,10,11,12,13,14,16,17],"onlin":4,"opaqu":[1,7,9],"open":[8,10,14],"oper":[2,3,5,6,8,10,11,13,14,17],"opinion":17,"opposit":7,"optic":13,"order":[12,13,14,16],"ordinari":[11,13,16,17],"org":[0,2,3,6,12,15],"organiz":[0,2,4,6,7,8,9,10,11,12,13,14,15,16],"origin":[3,5,8,9,11,13,16,17],"otherwis":10,"outcom":15,"output":17,"outsid":[0,10,13],"overst":[],"overwrit":[13,16],"overwritten":13,"owner":5,"pack":[1,5,15],"packet":8,"pad":[0,7],"padlock":9,"page":[2,3,4,6,14],"pain":17,"pair":8,"paper":[4,11],"paragraph":6,"park":3,"part":2,"parti":[0,1,4,5,8,9,10,13],"pass":[10,15],"passthrough":0,"path":[5,6,8,9,11,13,16],"pattern":[14,17],"payload":[0,7,8,17],"pdf":[0,3,6,10,12,14,15],"pdfs":5,"peer":[4,15],"peergo":[0,1,4,5,6,9,11,12,13,14],"pelham":2,"pentest":[1,2,10,12,15,17],"peopl":[2,7,8,10],"perform":[10,17],"perimet":17,"period":[13,15,17],"permit":13,"person":[1,2,5,7,8,13,16],"pfc":[0,6,12],"pfc_require_auth":[],"phi":[1,5,7],"phrase":[],"physic":[7,13],"physicist":4,"pick":[],"pictur":14,"piec":9,"pile":11,"pitch":3,"place":[7,9,11,13,17],"plaintext":[1,5,7,8,10,16],"plan":[2,5],"plane":[5,14],"platform":[10,15],"pleas":13,"plus":[1,3,5,7,10,11,13,15,16],"podkey":2,"point":[0,2,3,9,10,12,14,17],"pointer":[5,11,15],"polici":[0,5,6,7,8,10,11,13,17],"poly1305":[7,8],"portion":[6,10,11,12,13,17],"pose":4,"possess":8,"post":15,"power":13,"practic":[1,4,13,14,15],"preced":16,"precis":[4,10,11],"premis":9,"prepar":[],"present":[0,2,3,14,16],"presid":2,"pretend":17,"prev":[0,5],"prevent":7,"previous":[0,7,9,13],"primari":[2,3,15],"primit":16,"princip":[3,11],"print":4,"prior":3,"privaci":[4,15,17],"privat":[0,1,4,5,8,9,10,11,12,16],"probe":12,"problem":[2,4,9,10,11,14,15,16],"procedur":[5,6,7,8,9,10,11,13,17],"proceed":[4,17],"process":[1,5,15],"processor":[7,14],"procur":6,"produc":[4,10,11,12,13,16,17],"product":[0,2,3,4,5,6,7,8,9,10,11,12,13,15,16,17],"profession":14,"program":[1,5,10,12,13,16,17],"programm":[],"prohibit":13,"prompt":[9,16,17],"proof":[4,10,13,14,16,17],"properti":[7,10,13,16],"protocol":[4,8,10,15],"prove":[0,4,7,9,10,12,14],"proven":[4,12,15],"provid":[1,6,7,10,12,14],"provis":17,"public":[0,1,5,6,9,10,11,12,13,14,15,16,17],"publish":[4,7,8,11],"purpos":[10,14],"put":[3,9,11],"quarter":[7,17],"question":8,"quiet":[0,10,11],"quot":[3,4,11],"radic":[10,14],"ran":[13,16,17],"random":[0,1,7],"rare":7,"rate":[10,15],"rather":[3,4,9,13,17],"re":[0,7,10,13],"read":[0,1,5,7,10,12,13,15,16],"readabl":[9,13],"reader":[2,3,4,7],"readi":[6,7,12],"real":10,"reason":[1,10,13,17],"receipt":[0,1,4,5,9,12,13,14,17],"receiv":[1,5,7,8,13],"recipi":8,"recomput":17,"reconfigur":0,"record":[0,1,2,3,4,5,7,9,10,11,13,15,16,17],"recordkeep":[11,13],"recov":5,"redact":[5,11],"refer":[0,3,4,9,11,12,15],"refus":[7,10,13],"regim":11,"region":[1,15],"regist":[0,1,3,10,13,14,17],"registr":[3,5,10,11,13,14,17],"registrar":[5,10,15,17],"registri":[5,16,17],"regul":[11,17],"regulatori":3,"reject":[0,5,8,17],"relat":[14,16],"relev":1,"reli":15,"reliabl":4,"relianc":9,"remain":[3,4,8,10,11,12,13,14,16,17],"remark":4,"remind":14,"remov":13,"reopen":8,"repeat":[2,15],"replay":8,"repli":8,"replic":[0,9,10,13,15],"replica":[2,7,9,10,13],"report":[0,3,7,8,10,12,14,17],"report_peergo":15,"repres":[2,3],"republican":2,"request":[3,13,17],"requir":[1,5,6,7,8,10,11,13,17],"reread":12,"research":[2,4,15],"resid":1,"resist":7,"respond":17,"respons":[0,17],"rest":[1,9,11,12,13,14,15,17],"restor":[0,1,2,5,9,10,13,14,17],"result":10,"retain":[8,10,16],"retent":[5,7,10,13,16,17],"retriev":7,"return":[5,7,8,16],"reus":13,"reveal":[0,4,5,17],"review":[1,9,10,15],"revis":16,"rewrit":[7,9,11,13,17],"rewritten":[9,16],"rfc":[0,8],"rhetor":9,"rhonda":2,"ria":3,"right":[8,11,13],"risk":[1,5,17],"rm":13,"role":[1,14,17],"root":4,"ropa":[],"ros":[1,14],"rotat":[13,17],"rout":[0,1,5,9,10,14,17],"router":[8,17],"rule":[5,7,8,11,13,16,17],"run":[2,5,6,9,11],"s":[0,2,3,4,7,8,9,10,11,12,13,14,15,16,17],"saa":8,"said":10,"sale":[1,2],"salsa20":7,"sampl":5,"sanction":[8,17],"sanford":2,"sat":11,"satisfi":14,"satoshi":[4,11],"saw":16,"say":[10,12,15,17],"scalabl":2,"schedul":[5,13,16],"school":[2,3],"scienc":[4,12],"scientif":[3,11,14],"scientist":3,"scope":[1,14,15,17],"scott":[4,11],"screenshot":[5,10,13],"seal":[3,4,6,8,9,10,11,13,16,17],"search":3,"sec":[3,4,11,17],"second":[5,7,8,16,17],"secondari":3,"secreci":16,"section":[4,14],"secur":[1,3,4,5,7,9,10,11,12,14,17],"see":[0,1,8,9,10,14,16,17],"seen":[0,11],"segment":16,"select":3,"selectmen":2,"self":[1,14],"sell":17,"semant":13,"senat":2,"send":17,"sender":8,"senior":2,"sens":[8,9,11,17],"sensit":[9,17],"sent":9,"sentenc":[1,5,10],"sep":[],"separ":[5,10,13,15,17],"septemb":[2,10,15],"sequenc":[0,4,10,11,14,17],"serif":2,"serv":[2,7,9],"server":[0,1,2,4,7,8,11,12,13,14,15,16],"servic":[0,2,4,8,9,11,14,16,17],"session":0,"set":[7,9,11,13],"sever":[2,15],"sha":[7,16],"sha256":8,"shadow":8,"shape":16,"share":[1,3,7,9],"ship":2,"show":[9,10,11],"shown":[8,10,11],"sibl":7,"side":[2,3,7,11,12],"sidebar":14,"sign":[0,1,5,7,10,11,17],"signatur":[],"silent":[7,9],"similar":[11,13],"simpl":[4,11],"sinc":4,"singl":[0,5,9,10,11,13],"sit":[0,5,6,9,10,16],"site":[2,3,4,6,11],"six":10,"size":[0,7,8,10],"skip":[1,10],"sku":17,"slip":12,"slogan":[8,10],"sm":[],"smart":2,"snapshot":[0,5,7,13],"soc":[1,4,5,6,7,8,9,10,12,15,16,17],"social":[7,16],"socket":0,"softwar":[0,5,6,8,10,11,13,17],"solut":[2,3,6,7,8,14,17],"solv":[4,10],"someon":[7,8,11],"somewher":7,"sort":3,"sound":2,"sourc":[2,10,14,15],"speak":[2,13],"specialist":[2,15],"specif":[4,10,11],"specifi":[0,13],"speech":17,"spell":3,"spent":17,"split":[9,16],"sso":0,"stack":2,"staff":[10,17],"stage":10,"stamp":[4,10,11,16],"stand":3,"standard":17,"start":[4,14],"state":[0,2,3,5,6,10,11,14,15,17],"statement":[3,4,10,15],"status":[3,10],"statut":17,"stay":[0,9,11,13,17],"steal":16,"step":[7,11],"still":[1,2,6,7,8,9,10,11,13,14,15,16],"stop":[0,8,12,13],"storag":[0,1,2,3,4,5,7,9,10,13,15,17],"store":[1,6,7,8,9,10,11,12,15,16,17],"stori":12,"stornetta":[4,11,16],"strateg":2,"stream":8,"street":6,"string":[4,11],"strong":8,"stronger":15,"structur":[3,4,16],"stuart":[3,11,14],"style":3,"subject":[0,1,5,8,10,17],"submit":[5,15],"subsequ":2,"substitut":[1,2,4,7,9,12,13,17],"substrat":9,"successor":5,"suit":8,"summar":3,"summari":[2,3,4,11,12,14,17],"sunday":[4,11],"supervis":11,"supervisori":3,"support":[1,7,13,15],"sureti":[11,14],"surfac":[0,7,12],"surpris":3,"surveil":5,"surviv":4,"swap":7,"symmetr":[4,7],"sync":[0,5,9,10,11],"system":[2,3,4,5,8,9,10,12,13,15,16,17],"t":4,"tabl":[13,14],"take":[6,7,9],"taken":3,"talk":8,"tamper":[9,10,13,14],"tape":[5,7,10,13],"task":2,"tcp":2,"team":[4,11],"technic":[0,6,7,8,9,10,11,12,13,14,16,17],"technolog":[2,3],"telephon":6,"tell":16,"termin":8,"terralog":2,"test":[0,1,2,5,7,10,17],"tester":15,"text":13,"themselv":[9,13,14],"therefor":[1,3,8,10,13,16],"thing":[7,11],"third":[9,10,13],"threat":15,"three":[2,4,5,11,17],"tick":5,"ticket":[0,5,7,10,13],"tier":[0,10,11,13],"time":[0,3,4,8,9,10,11,13,16,17],"timestamp":[0,2,3,4,6,9,12,13,14,17],"titl":[7,14],"tls":8,"togeth":[11,15,16],"token":0,"toler":4,"tomorrow":16,"took":4,"tool":[2,6,8,10,11,14],"toolchain":2,"top":[4,14,15],"totp":[0,5],"touch":[1,6,12,17],"toward":4,"town":2,"townsend":3,"traffic":[10,11],"trail":[4,17],"train":[9,10,17],"transit":[1,9,12,14],"transmiss":8,"transmit":1,"transport":[8,10],"trash":13,"travel":[9,16],"treat":[1,3,9,10,15],"tree":[4,7,11,15,16],"true":[1,16],"trust":[4,8,11,13,15,16,17],"turn":[0,13],"twice":[10,15],"two":[0,1,2,3,7,10,12,13,14,16],"type":[2,5,10,12,15,17],"typic":[9,11],"ui":[7,10,15],"uk":[],"unapprov":8,"unbroken":16,"undo":8,"union":15,"unit":[3,11,16,17],"unless":[1,8,15],"unpack":9,"unread":17,"unseal":11,"unsign":[0,5,7,17],"untrust":[1,8,9,14],"unusu":15,"unwind":17,"unwrap":[0,7],"updat":[7,13],"us":[],"use":[0,1,3,5,6,7,8,10,11,13,14,15,17],"user":[3,4,5,7],"usernam":[1,5,7],"usual":[12,14],"v":[0,10,14],"v1":[0,6,12],"valid":7,"vendor":[1,4,10,11,12,13,15,17],"ventur":3,"vera":[0,2,5,7,8,12,13,15],"verb":[12,17],"verif":[1,5,7,9,10,11,13,16,17],"verifi":[0,1,6,7,10,11,12,13,16,17],"versus":14,"via":[],"vice":2,"visibl":[5,9,10,14,17],"vm":[1,5,7],"volum":[4,14],"vote":2,"vs":5,"w":[4,6,11],"walk":[7,17],"walkthrough":14,"wall":16,"wallpap":5,"want":[4,10,11],"way":[7,9],"weak":[7,8],"weaker":8,"web":[10,15],"websit":6,"week":[4,10,11],"whatev":[1,7],"whenev":1,"wherea":13,"whether":[1,15],"whi":14,"white":[4,11],"whiteboard":9,"whose":[2,7,15,16],"wide":[4,11],"wife":2,"wikipedia":2,"will":[1,3,5,6,8,10,11,17],"win":[5,14,17],"window":5,"winner":2,"wire":[8,12],"wit":4,"within":[6,17],"without":[0,4,5,7,9,11,12,14,16,17],"word":17,"wordmark":14,"work":[2,3,5,6,10,12,14,15,17],"workforc":[8,9,17],"world":11,"worm":14,"worth":15,"write":[0,2,3,6,7,9,11,14,16,17],"writer":[],"written":[1,5,9,10,11,13,17],"wrong":[7,9,11],"www":[6,12],"x":7,"x25519":[7,8],"xor":8,"year":16,"yes":[],"yet":9,"york":[3,4,11],"zero":[10,15]},"titles":["Architecture for an audit interview","BAAs, DPAs, and ciphertext without host keys","George Lambert","James H. Garfinkel","Stuart Haber","Audit-ready checklist","Verae Inc \u2014 contact","Encryption at rest \u2014 IPFS blocks and Peergos","Secure communications \u2014 data in transit","The Verae DataCube Server Solution","Executive summary","Verae global timestamping \u2014 a cross-blockchain receipt","How to use this briefing","Write-once Iceberg archive","Making yourself audit-ready with Verae DataCubes","Peergos security evaluations in Europe","Global timestamped receipts","What Verae provides \u2014 and what it does not"],"titleterms":{"A":5,"How":[12,13,15],"Not":[],"Other":4,"The":[0,1,4,7,8,9,11,13,17],"What":[0,7,8,9,10,11,13,15,16,17],"access":5,"actual":[],"address":7,"amsterdam":15,"append":7,"architect":2,"architectur":0,"archiv":[5,10,13],"ask":0,"associ":1,"assur":1,"audit":[0,5,14],"auditor":15,"b":[5,15],"baa":1,"backup":[],"berlin":15,"biographi":[2,3,4],"block":7,"blockchain":[4,11],"boundari":17,"brief":[2,3,4,10,12],"brokercheck":3,"bundl":[11,16],"busi":1,"c":5,"chang":5,"check":[],"checklist":5,"ciphertext":1,"claim":[],"classic":13,"close":6,"commerci":4,"communic":8,"compon":1,"contact":6,"contain":9,"content":[7,8,14],"contract":5,"counsel":5,"crd":3,"cross":11,"cryptograph":4,"cube":[7,13],"cure53":15,"custodi":11,"d":5,"data":[5,8,10],"datacub":[9,10,14,15],"delet":13,"deploy":11,"design":15,"digit":11,"directori":8,"disk":7,"distinct":17,"doe":[7,8,10,11,13,16,17],"dpas":1,"e":5,"educ":3,"encrypt":[7,8],"enough":16,"error":8,"eu":[],"europ":[10,15],"evalu":[10,15],"evid":7,"exam":17,"examin":[0,5],"execut":10,"exist":11,"f":5,"fact":1,"filesystem":[],"finra":3,"first":[4,16],"fund":15,"g":5,"garfinkel":3,"gdpr":1,"georg":2,"germani":15,"global":[10,11,16],"h":[3,5],"haber":4,"hampshir":2,"hand":0,"handl":8,"hash":16,"hipaa":1,"honesti":5,"host":[1,15],"iceberg":[10,13],"ident":0,"inc":6,"independ":5,"inform":9,"instanc":[],"integr":[],"internet":2,"interview":0,"ipf":7,"jame":3,"key":[1,8],"lambert":2,"layer":7,"leak":8,"lineag":11,"list":3,"locat":[],"log":[],"make":14,"map":[],"matter":17,"mean":[9,11,13],"measur":1,"move":13,"must":17,"name":3,"nat":[0,1],"new":2,"nlnet":[],"offic":2,"onc":[5,10,13],"one":9,"onli":7,"open":15,"oper":[1,7,9],"order":0,"organiz":[1,5,17],"pack":[],"pattern":11,"peergo":[7,10,15],"pictur":[0,9],"plane":0,"point":8,"practic":9,"present":15,"problem":[7,8,13],"processor":1,"profession":3,"proof":11,"prove":16,"provid":17,"public":[2,3,4,8],"purpos":9,"radic":15,"readi":[5,14],"receipt":[10,11,16],"regist":16,"registr":16,"relat":13,"remain":0,"remind":6,"report":[1,15],"rest":[5,7,10],"restor":7,"role":[2,3,4],"ros":15,"rout":8,"s":1,"satisfi":[7,8,11,13],"scientif":4,"scope":5,"secur":[8,15],"see":7,"self":15,"sequenc":16,"server":[9,10],"servic":1,"solut":[9,10,13],"sourc":3,"state":9,"statement":[],"still":17,"stuart":4,"summari":10,"sureti":4,"tamper":7,"technic":[1,2],"themselv":16,"timestamp":[1,5,10,11,16],"tool":17,"top":7,"transit":[5,8,10],"two":[9,11],"uk":[],"untrust":0,"us":[],"use":12,"usual":0,"v":15,"vera":[1,3,4,6,9,10,11,14,16,17],"verif":[],"verifi":[],"versus":[1,11,15],"visibl":8,"vs":[],"walkthrough":0,"whi":[2,3,4,16,17],"win":16,"without":[1,8],"work":4,"worm":13,"write":[5,10,13]}}) \ No newline at end of file diff --git a/build/html/timestamped-receipts.html b/build/html/timestamped-receipts.html new file mode 100644 index 0000000..4a87db3 --- /dev/null +++ b/build/html/timestamped-receipts.html @@ -0,0 +1,243 @@ + + + + + + + + 6. Global timestamped receipts — Making yourself audit-ready with Verae DataCubes + + + + + + + + + + + + + + + + + + + + +
+ + +
+
+ + +
+ +
+

6. Global timestamped receipts

+
+

6.1. Why hashes are not enough by themselves

+

A cryptographic hash of a document proves that two copies are +bit-for-bit the same, or that they are not. It does not prove +when the document first existed. Anyone can hash a file +tomorrow and claim they hashed it last year. Anyone can hash a +rewritten file and present the new hash as if it were the old +one.

+

Compliance programs that care about books and records, legal +holds, intellectual-property precedence, or “produce the original +prompt that the model saw” therefore need a second primitive: +a receipt, issued at the time of first registration, bound to +the hash, that a later examiner can check without trusting the +file’s custodian.

+
+
+

6.2. What a Verae receipt is

+

A Verae global timestamped receipt is proof of:

+
    +

  • the hash of a block of digital information;

    • +

  • the time at which that hash was first registered;

    • +

  • the sequence of that registration relative to other +registrations.

    • +
+

The block of digital information may be a message, an image, a +document, a log segment, an AI prompt, an AI completion, or any +other object that can be stored in digital media. The receipt is +about the bits, not about the medium they happened to sit on +when they were hashed. That is the Haber–Stornetta distinction +from 1991, applied here as a product: time-stamp the data, not +the disk.

+
+
+

6.3. What is registered, and what is not

+

Verae’s public description of sealing is that only a +fingerprint leaves the customer’s systems. The object itself +can remain in the customer’s DataCube. The central service +therefore does not need — and in the intended design does not +get — the plaintext in order to issue a receipt.

+

That split is the difference between a notary who reads the +document and a notary who stamps a sealed envelope whose +contents they never saw. The second notary can still later +confirm that this envelope, with this unbroken seal, was +presented at this time. They cannot tell you what was inside. +For HIPAA, GDPR, and ordinary commercial secrecy, that is the +desired shape.

+
+
+

6.4. First registration wins

+

A hash registry that allowed a later write to overwrite the +timestamp of an earlier write would be a forgery machine. The +rule is: the first SHA-256 (and companion hash) and its +receipt win. A second presentation of the same hash returns +the original receipt. A different hash is a different object — +which is exactly how a revision should be modeled. Revisions +get their own receipts. They do not steal the original’s time.

+
+
+

6.5. Sequence

+

Time on a wall clock is a social convention and a NTP +configuration. Sequence inside a registration service is a +data-structure fact: this hash was committed after that hash, +in this chain, in this Merkle tree, in this cross-chain bundle. +Verae receipts carry sequence so that an examiner can see +order even when two wall-clock stamps are close enough to argue +about.

+
+
+

6.6. Bundles

+

A receipt does not have to travel as a bare timestamp. It can +travel inside a digital bundle that also holds:

+
    +

  • private metadata the organization needs (matter id, hold flag, +classification);

    • +

  • attached files that should be produced together;

    • +

  • an internal chain that cross-verifies the organizational +server against Verae’s central server.

    • +
+

The bundle is the unit an examiner is handed: “here is the +object (or a capability to it), here is the receipt, here is +the metadata we claim goes with it, here is the verification +path.”

+
+
+

6.7. What a receipt does not prove

+

A receipt does not prove that the person who registered the +hash was authorized to do so. That is an access-control and +identity problem.

+

A receipt does not prove that the object is true, only that +those bits existed at that time. A false document can be +timestamped as honestly as a true one.

+

A receipt does not prove that the organization retained the +object. Proof of existence is not proof of retention. Retention +is the write-once archive (Chapter 9) plus the organization’s +retention schedule.

+

A receipt is not a HIPAA, SOC 2, or ISO certificate. It is +evidence that a technical control ran.

+
+
+ + +
+ +
+
+
+
+
+ Verae Inc + · https://www.verae.com + · Book a call at verae.com + · app.verae.com +
+ +
+ ©2026, Verae Inc. + +
+ + + + + + + \ No newline at end of file diff --git a/build/html/what-verae-provides.html b/build/html/what-verae-provides.html new file mode 100644 index 0000000..53c3822 --- /dev/null +++ b/build/html/what-verae-provides.html @@ -0,0 +1,238 @@ + + + + + + + + 2. What Verae provides — and what it does not — Making yourself audit-ready with Verae DataCubes + + + + + + + + + + + + + + + + + + + + +
+ + +
+
+ + +
+ +
+

2. What Verae provides — and what it does not

+
+

2.1. The boundary

+

Verae sells and operates software infrastructure and a +timestamping service. Customers use that infrastructure to store +objects, to send messages, to register hashes, to verify receipts, +and to produce an audit trail of what their own systems did.

+

Verae does not sell a HIPAA certificate. HIPAA is a United +States statute (and implementing regulations), not a product +seal. A covered entity or business associate becomes “HIPAA +compliant” only in the ordinary-language sense that it has performed +a risk analysis, implemented the Security Rule’s required and +addressable controls as reasonable and appropriate, executed +Business Associate Agreements where required, trained its workforce, +and can respond to OCR. No software vendor can substitute for that +work.

+

Verae does not sell a SOC 2 report covering the customer’s +organization. SOC 2 is an attestation by a licensed CPA firm +against the AICPA Trust Services Criteria, for a named entity, over +a named period, with a named system description. The customer’s +auditor must still walk the customer’s controls.

+

Verae does not sell an ISO 27001 certificate covering the +customer’s organization. ISO 27001 is a management-system +standard. A registrar certifies that a named organization operates +an Information Security Management System (ISMS) over a named +scope. Installing a DataCube does not create an ISMS.

+
+
+

2.2. The tools

+

Within that boundary, the Verae DataCube Solution is built to make +the technical work of those programs less painful. Concretely, +it gives the organization the ability to:

+

Store. Digital objects — messages, images, documents, logs, +model prompts, model outputs, attachments — can be written into an +encrypted DataCube. The cube is a customer-controlled container. +Verae is designed so that the contents stay in the customer’s +storage. What leaves the customer’s perimeter for sealing is a +fingerprint (a cryptographic hash), not the object.

+

Communicate. Endpoints exchange messages with point-to-point +encryption. The body is unreadable to the router. Destination and +subject remain visible because a network that cannot see a +destination cannot route.

+

Timestamp. The first time a hash is registered, Verae records +that registration against a time and a sequence. Later, anyone with +the receipt and the object (or the object hash) can check that the +object existed, in that exact bit pattern, no later than that time.

+

Verify. Verification does not require trusting Verae’s word, the +customer’s archive administrator, or a hosting vendor. It requires +recomputing a hash, checking a receipt, and — for stored objects +— checking IPFS content identifiers. A regulator can be handed +proof rather than a vendor assurance letter.

+

Audit. Admin history, inspect events, and message-handling +summaries are written so that an examiner can see that an action +occurred, who authorized it, and which object it touched, +without the log itself becoming a second copy of the sensitive +payload.

+
+
+

2.3. What the organization must still do

+

Those five verbs — store, communicate, timestamp, verify, audit +— are the technical portion. The rest of a certification or +attestation program is organizational:

+

Policies. Acceptable use, encryption, key custody, access +control, retention, legal hold, incident response, vendor +management, change management, and (where HIPAA applies) a +sanctions policy and a named Privacy Officer and Security Officer.

+

Procedures. How a new hire is provisioned, how a leaver is +deprovisioned, how a restore is tested, how a key is rotated, how a +legal hold is placed on a cube, how an inspector is authorized +under k-of-n, how a SOC evidence request is answered.

+

Internal controls. Dual control on inspect. Separation of the +author of a change from the officers who approve it. Signed +configuration so an unsigned file is rejected. Log-before-reveal so +an inspect cannot happen in the dark. Hash-registry “first write +wins” so a later rewrite cannot pretend to be the original.

+

Independent examination. A CPA firm (SOC 2), a registrar +(ISO 27001), OCR or a HIPAA assessor, FINRA or SEC examination +staff, or an internal audit function that is actually independent. +They will ask for evidence that the controls ran during the period, +not that a vendor has a nice architecture diagram.

+
+
+

2.4. Why the distinction matters in an exam

+

Examiners are trained to notice category errors. If a firm says +“we are SOC 2 because our storage vendor was pentested in Berlin,” +the next hour of the meeting is spent unwinding that claim. If a +firm says “we use a component that was independently evaluated in +the EU; here is the public report, labeled as a component +evaluation; here is our system description, our key-custody +procedure, our restore test from last quarter, and our Type II +report,” the meeting can proceed.

+

This chapter exists so that nobody using this briefing makes the +first speech. Verae provides tools, background, and software +infrastructure. The organization provides the program. The auditor +provides the opinion. Those three roles do not collapse into one +product SKU.

+
+
+ + +
+ +
+
+
+
+
+ Verae Inc + · https://www.verae.com + · Book a call at verae.com + · app.verae.com +
+ +
+ ©2026, Verae Inc. + +
+ + + + + + + \ No newline at end of file diff --git a/build/latex/VeraeFullLogo.png b/build/latex/VeraeFullLogo.png new file mode 100644 index 0000000..4c011e8 Binary files /dev/null and b/build/latex/VeraeFullLogo.png differ diff --git a/build/latex/peergos-making-yourself-audit-ready-with-verae-datacubes.pdf b/build/latex/peergos-making-yourself-audit-ready-with-verae-datacubes.pdf index 97fb5ab..b9d9add 100644 Binary files a/build/latex/peergos-making-yourself-audit-ready-with-verae-datacubes.pdf and b/build/latex/peergos-making-yourself-audit-ready-with-verae-datacubes.pdf differ diff --git a/source/_static/VeraeFullLogo.png b/source/_static/VeraeFullLogo.png new file mode 100644 index 0000000..4c011e8 Binary files /dev/null and b/source/_static/VeraeFullLogo.png differ diff --git a/source/_static/verae.css b/source/_static/verae.css new file mode 100644 index 0000000..9569f89 --- /dev/null +++ b/source/_static/verae.css @@ -0,0 +1,47 @@ +/* Verae branded Sphinx HTML */ +body { + font-family: "Source Serif 4", "Georgia", serif; + color: #111; +} +div.document { + padding-top: 0.5em; +} +div.sphinxsidebar h3, div.sphinxsidebar h4 { + color: #5B2C8B; +} +div.body h1, div.body h2, div.body h3 { + color: #5B2C8B; +} +div.related { + background: #1A0A24; + color: #fff; +} +div.related a { + color: #e8d7f5; +} +div.footer { + background: #1A0A24; + color: #e8d7f5; + padding: 1.1em 1.5em; + margin-top: 2em; +} +div.footer a { + color: #d7b8f0; +} +.verae-page-footer { + border-top: 2px solid #5B2C8B; + margin-top: 2.5em; + padding-top: 0.8em; + font-size: 0.9em; + color: #5B2C8B; +} +div.sphinxsidebarwrapper img.logo, +img.logo { + background: #1A0A24; + padding: 8px; + border-radius: 4px; + max-width: 100%; +} +.admonition.important, .admonition.warning, .admonition.note { + border-left: 4px solid #5B2C8B; +} diff --git a/source/_templates/layout.html b/source/_templates/layout.html new file mode 100644 index 0000000..8bafc6b --- /dev/null +++ b/source/_templates/layout.html @@ -0,0 +1,10 @@ +{% extends "!layout.html" %} +{% block footer %} +
+ Verae Inc + · https://www.verae.com + · Book a call at verae.com + · app.verae.com +
+{{ super() }} +{% endblock %} diff --git a/source/architecture.rst b/source/architecture.rst index dff578b..121d8e4 100644 --- a/source/architecture.rst +++ b/source/architecture.rst @@ -1,43 +1,126 @@ -Architecture (audit interview) -============================== +Architecture for an audit interview +=================================== + +The picture +----------- :: - Endpoint (keys stay here / HSM) - │ HPKE content (NPE suite) - │ routing: dest + subject in the clear - ▼ - Untrusted NATS (cannot read bodies) - │ - ▼ - Verae DataCube chain (append-only hashes) - │ written through Peergos client - ▼ - Peergos cryptree (encrypted names, sizes, graph) - │ chunks → CID / hash - ▼ - IPFS (distributed, hash-verified ciphertext) + Endpoint (private keys stay here / HSM) + | HPKE content (point-to-point) + | routing: destination + subject in the clear + v + Untrusted message fabric (honest-but-curious) + | cannot read bodies; can see dest / subject / size + v + Organizational DataCube + | append-only cube chain (prev + new + diff) + | private metadata, attachments, internal chain + v + Peergos cryptree (encrypted names, sizes, graph) + | chunks -> CID / hash, hashes verified + v + IPFS (distributed, content-addressed ciphertext) + | + +-- Verae timestamping + | fingerprint only -> receipt (time + sequence) + | org server linked to central Verae, or direct sync + | + +-- Iceberg write-once archive + snapshot of cube CIDs, not under single-party delete -* **At rest:** Peergos cryptree + IPFS. Hosts with disk/backup see - **opaque hashed ciphertext**, not PHI, if they lack keys. -* **In transit (NATS):** HPKE-Base to directory public keys. Broker is - honest-but-curious: destinations yes, bodies no. -* **Integrity:** cube JSONL chain + dual hash + IPFS CID check on - restore (re-fetch blocks, re-verify hashes — not a plaintext tape). +Walkthrough, in the order an examiner usually asks +-------------------------------------------------- -NATS remains an untrusted router. Production E2E is NPE/HPKE. -Passthrough means destination in the clear; the body is ciphertext. +**Where are the keys?** On the endpoint or in the customer's +HSM. Not on the storage host. Not in the public-key +directory (that directory holds public keys only). Not in +the NATS payload. + +**What does the network see?** Destination, subject, size, +timing. Not the body. Production algorithm is HPKE, not a +lab construction. + +**What does the disk see?** Padded encrypted chunks under +random labels. Peergos verifies hashes. A restore re-fetches +CIDs and re-checks them. + +**How do you prove when it existed?** A hash is registered +the first time it is seen. A receipt binds hash, time, and +sequence. The organizational chain and the central Verae +chain cross-verify. Verae is not given the object, only the +fingerprint. + +**How do you stop delete?** Live cubes replicate as hashed +ciphertext. Committed snapshots go to an external Iceberg +write-once tier that is specified to sit outside any one +party's delete control. + +**How do you know the software was not quietly reconfigured?** +Configuration is Ed25519-signed. Unsigned files are +rejected. Admin-history records previous state, new state, +and a diff. + +**How do you inspect without turning inspect into a leak?** +k-of-n officers. The author of a change is not an officer +on that change. Log-before-reveal. + +Identity planes +--------------- + +There are two login planes, and they must not be collapsed +in an interview: + +* **Drive / Peergos identity** --- unwraps cubes. This is + the cryptographic identity. +* **Console identity** --- TOTP (RFC 6238), session cookie, + admin actions. Google SSO, if present, does **not** unwrap + cubes. + +Mixing those planes is how "we have SSO" becomes "SSO is +the master key." It is not. + +NATS remains untrusted +---------------------- + +The reference message fabric is NATS. It is an +honest-but-curious broker. Destinations in the clear are +**passthrough**, not a bug. Bodies are ciphertext, or the +message is rejected. Error responses carry codes and lookup +identifiers, not payloads. + +A public-edge NATS listener, if enabled, is token-gated and +is not the same socket the internal services use. + +What to hand the examiner +------------------------- + +* this document (HTML or PDF); +* the two public Peergos reports, labeled as component + evaluations; +* a data-flow diagram of *this* instance; +* the public-key listing (public keys only); +* a restore-test ticket; +* an admin-history excerpt for a dated change; +* the organization's policies, not Verae's. .. only:: html - Live: https://pfc.georgelambert.org/v1/npe/keys (public keys only). - Controls: https://docs.pfc.georgelambert.org/controls.html + Live technical surfaces (reference instance): + + * https://pfc.georgelambert.org/health + * https://pfc.georgelambert.org/v1/npe/keys + * https://docs.pfc.georgelambert.org/controls.html .. only:: latex - See companion ``peergos-for-compliance.pdf`` (same folder) for - controls, custody, and variables chapters. + Companion PDFs, same folder as this file (relative PDF + hrefs, not Markdown): .. raw:: latex - \href{peergos-for-compliance.pdf}{peergos-for-compliance.pdf} + \begin{itemize} + \item \href{peergos-for-compliance.pdf}{peergos-for-compliance.pdf} + \item \href{nats-service-endpoints.pdf}{nats-service-endpoints.pdf} + \item \href{secure-messaging.pdf}{secure-messaging.pdf} + \end{itemize} diff --git a/source/baa-dpa.rst b/source/baa-dpa.rst index 125a3ee..a6e9c67 100644 --- a/source/baa-dpa.rst +++ b/source/baa-dpa.rst @@ -1,76 +1,104 @@ -BAAs and DPAs when ciphertext has no host keys -============================================== +BAAs, DPAs, and ciphertext without host keys +============================================ -This is **guidance for an evidence pack**, not legal advice. +This chapter is **guidance for an evidence pack**. It is not +legal advice. Counsel has to sign the actual determination. -The operator statement ----------------------- +The technical fact +------------------ -Data at rest lives in the **encrypted Peergos cryptree**. Restore uses -**distributed, hash-verified, encrypted IPFS blocks**. Hosts and backup -media see **opaque blobs** (and random CHAMP labels), not filenames, not -PHI, not social graph — if keys never leave the client / customer HSM. +Data at rest lives in the **encrypted Peergos cryptree**. +Restore uses **distributed, hash-verified, encrypted IPFS +blocks**. Hosts and backup media see **opaque blobs** (and +random CHAMP labels), not filenames, not PHI, not the share +graph --- **if** private keys never leave the client or the +customer's HSM. -That is **true of the Peergos design** (see :doc:`verification`). -It **changes the BAA/DPA conversation**. It does **not** auto-delete the -need for contracts. +That fact is true of the Peergos design and is the design +Cure53 reviewed in Berlin. It **changes** the Business +Associate and GDPR-processor conversation. It does **not** +automatically delete the need for contracts. -HIPAA (US) — Business Associate -------------------------------- +HIPAA --- Business Associate +---------------------------- -A Business Associate is a person who **creates, receives, maintains, or -transmits ePHI** for a covered entity. +A Business Associate is a person who **creates, receives, +maintains, or transmits ePHI** for a covered entity. -**Technical argument you can make (and should document):** +A technical argument the organization can document: -1. ePHI is encrypted **before** it leaves the endpoint (Peergos client / - DataCube writer). -2. The storage node, IPFS, disk, and backup hold **ciphertext + hashes**. -3. Private keys **do not** reside on the storage host (customer HSM / - client). Hash verification detects tampering. -4. Therefore the host **cannot maintain ePHI in intelligible form**. +1. ePHI is encrypted **before** it leaves the endpoint. +2. The storage node, IPFS, disk, Iceberg archive, and backup + hold **ciphertext plus hashes**. +3. Private keys **do not** reside on the storage host. + Hash verification detects substitution. +4. Therefore the host **cannot maintain ePHI in intelligible + form**. -HHS distinguishes **conduits** and parties that never have access to -ePHI. Many programs still **sign a BAA** when a vendor touches -infrastructure, because misconfiguration, support exports, or logs could -later expose plaintext. OCR looks at **your** risk analysis. +HHS has distinguished **conduits** and parties that never +have access to ePHI. Many programs still **sign a BAA** +whenever a vendor touches infrastructure, because +misconfiguration, a support export, or a log could later +expose plaintext. OCR will look at **the organization's** +risk analysis, not at Verae's architecture diagram. -**Practical pack:** risk analysis memo citing cryptree + IPFS hash checks -+ key custody; BAA **or** written determination that the vendor is -**not** a BA because they cannot decrypt; list every party with -disk/backup (ns1, IPFS cluster, offsite replica). +Practical pack: -GDPR (EU/UK) — processor vs technical measure ---------------------------------------------- +* a risk-analysis memo citing cryptree, IPFS hash checks, + key custody, and the two public Peergos evaluations; +* a BAA **or** a written determination that a named vendor + is **not** a BA because they cannot decrypt; +* a list of every party with disk, VM, backup, IPFS, or + Iceberg credentials. -Encrypted data can still be **personal data** if it is reasonably -attributable (usernames, IPs, invoice identity). GDPR **Art. 32** lists -encryption as a security measure. +GDPR --- processor versus technical measure +------------------------------------------- -Peergos is designed so the **server is an adversary** for content and -most metadata. EU-based **independent pentests** (Cure53 DE, ROS NL) -evaluated that design. Processing location for **self-host** is *your* -ns1 / customer region, not peergos.net’s Germany hosting, unless you use -peergos.net. +Encrypted data can still be **personal data** if it is +reasonably attributable (usernames, IPs, invoice identity). +GDPR Article 32 lists encryption as a security measure, not +as an exemption from Article 28. -You may still need a **DPA (Art. 28)** with anyone who **processes** -personal data (usernames, logs, billing). Ciphertext-only storage -**narrows** the DPA’s technical annex. +Peergos is designed so the **server is an adversary** for +content and most metadata. EU-based independent pentests +evaluated that design. Processing location for **self-host** +is the customer's region, not peergos.net's Germany, unless +the customer uses peergos.net. + +A DPA may still be required with anyone who **processes** +usernames, logs, or billing. Ciphertext-only storage +**narrows** the technical annex. It does not always +eliminate the DPA. NATS operators -------------- -NATS is an **untrusted broker**. Content is HPKE; destinations and -subjects are in the clear. A NATS operator **cannot** read bodies without -endpoint private keys; **can** see routing metadata; **can** drop/delay -copy **ciphertext**. Treat like a transit provider: DPA/BAA depends on -whether routing metadata is personal data in your jurisdiction. +NATS is an untrusted broker. Content is HPKE. Destinations +and subjects are in the clear. A NATS operator **cannot** +read bodies without endpoint private keys. They **can** see +routing metadata. They **can** drop, delay, or copy +ciphertext. Treat them like a transit provider: whether a +DPA or BAA is needed depends on whether routing metadata is +personal data in the relevant jurisdiction. -What “making yourself audit-ready” means ----------------------------------------- +Verae as timestamping service +----------------------------- -You are **not** buying Peergos’s Cure53/ROS reports as *your* SOC 2. -You are **reusing** those public evaluations as **vendor/component -assurance**, then adding your scope, RoPA, key-custody, inspect k-of-n, -admin-history, instance evidence, and contracts that match who can -actually see plaintext. +If Verae receives **only fingerprints**, Verae's role for +**content** is not "stores the records." Verae's role is +"registers hashes and issues receipts." That is a narrower +processing. Counsel still has to decide whether the +fingerprint, plus whatever account data exists (company +name, billing, operator emails), requires a DPA or a BAA. +Do not let a sales sentence skip that memo. + +Component assurance versus the organization's report +---------------------------------------------------- + +Attaching Cure53 2019 and ROS 2024 is **vendor / component +assurance**. It is appropriate. It is **not** the +organization's SOC 2, ISO 27001, or HIPAA program. Those +still require the organization's scope, Record of +Processing, key-custody, inspect k-of-n, admin-history, +instance evidence, restore tests, and the contracts that +match who can actually see plaintext. diff --git a/source/bio-george-lambert.rst b/source/bio-george-lambert.rst new file mode 100644 index 0000000..afae9cb --- /dev/null +++ b/source/bio-george-lambert.rst @@ -0,0 +1,96 @@ +George Lambert +============== + +Role +---- + +**George Lambert** is an Internet technical architect and a +New Hampshire public official. Public candidate listings +(BallotReady) identify him as **CTO / Chief Architect, Verae +LLC**, from **2019**. He is the architect of the DataCube +**server** side of the solution described in this briefing: +the assembly of encrypted storage, point-to-point messaging, +public-key directory, organizational timestamping link, and +write-once archive that an organization actually runs. + +Internet technical architect, from 1994 +--------------------------------------- + +Lambert's public account of his engineering work begins in +the **earliest days of the commercial Internet**, when +shipping an application that could speak TCP/IP was still a +specialist task. + +In **1994--1995** he was moving through senior application +engineering and sales roles (Terralogics; Serif) at the +moment Borland's developer tools were being connected to +the public network. He then founded **NetMasters LLC** +(New Hampshire, formed 1996; he describes the product work +from 1995). At NetMasters he **personally designed and +built FastNet Tools** --- the **Internet integration +technology that shipped with Borland's Delphi and C++ +Builder** products. + +Those tools are the historically important fact. They +enabled a generation of Delphi and C++ Builder developers +to Internet-enable applications as a shipped part of +Borland's commercial toolchain, not as a research demo. +Lambert's own summary is that FastNet Tools "enabled +millions of developers to internet-enable their +applications in minutes." That is the beginning of the +through-line that ends, in this briefing, at a DataCube +server: **make the hard network problem a product that +other people can operate**. + +He continued as **Vice President of Engineering** at +GoldenWare / **FlightLookup** (from 1995, for two decades +on the public listings), building airline-information +systems, and later as founder of PodKey Solutions +(2004--2010) and as an interim/contract CTO. + +New Hampshire public office +--------------------------- + +Lambert is a **Republican** from **Litchfield, New +Hampshire**, born **4 September 1968** in Sanford, Maine +(Wikipedia; Vote Smart). + +* **Litchfield Board of Selectmen**, from 2007 (Vote Smart + lists council of town selectmen, Town of Litchfield, + 2007--present on the biography page then current). +* **New Hampshire House of Representatives**: + Hillsborough 27th district, December 2010 -- December + 2012; Hillsborough 44th district, December 2012 -- + December 2014. +* Subsequent campaigns for the New Hampshire Senate, + District 18 (2014, 2018, 2020, 2022 Republican primary + winner in several of those cycles). + +Vote Smart records a diploma from **Pelham High School, +1986**; family (wife Rhonda, children); home city +Litchfield. He has also served on the **National Grange +Strategic Planning Task Force** (1999--2004). + +His public technical site, https://georgelambert.org/, +describes three decades at the intersection of technology, +governance, and sound money, and repeats the FastNet / +Borland fact as the credential for knowing what scalable +architecture looks like. + +Why this biography is in the briefing +------------------------------------- + +The DataCube Server Solution is not only a timestamping +API. It is a **running system**: keys, brokers, cryptree, +replicas, admin-history, Iceberg export. Lambert is the +person whose public career is the **implementation** of +Internet integration from the Borland era through to this +server stack, and whose public service is New Hampshire +legislative and municipal office. The biography is here so +that a reader who asks "who architected the server side, +and on what history?" has a sourced answer. + +It is not a substitute for a pentest, a Type II, or a +restore test. Code either runs or it does not; Lambert's +own stated ethic. This briefing is the description of what +the code is for, and of what it cannot certify by existing. diff --git a/source/bio-james-garfinkel.rst b/source/bio-james-garfinkel.rst new file mode 100644 index 0000000..a527a51 --- /dev/null +++ b/source/bio-james-garfinkel.rst @@ -0,0 +1,110 @@ +James H. Garfinkel +================== + +Name and sources +---------------- + +This chapter summarizes **James H. Garfinkel** (the spelling on +the FINRA BrokerCheck individual report; also styled Garfinkle +in some informal references). Two public sources were used, as +requested: + +* **FINRA BrokerCheck**, CRD number **5052743**, + https://files.brokercheck.finra.org/individual/individual_5052743.pdf +* **verae.com**, which names Stuart Haber as co-founder and + describes the DataCube product. As of this writing the public + marketing site does **not** carry a dedicated biography page + for Garfinkel. The product and company description below is + therefore taken from verae.com's company narrative plus + Garfinkel's own public statement of role, not from a + fabricated "about the CEO" page. + +Role at Verae +------------- + +Public professional listings (including a long-standing +Facebook work listing) identify Garfinkel as **CEO of Verae +LLC**, from **January 2020**, based in **New York, New York**. +In that listing he describes Verae's technology as +blockchain-authenticated containers called **DataCubes**, +"which conveniently and securely ensure integrity and enable +selective sharing of digital information and records of all +sorts," and he quotes Stuart Haber on the original motivation +for timestamping digital objects. + +That description matches the public verae.com product: records +remain in customer-controlled storage; Verae seals a +fingerprint; the scientific core is Haber-style cryptographic +timestamping, aimed at compliance and examinations rather than +at operating a public chain. + +FINRA BrokerCheck (CRD 5052743) +------------------------------- + +The following facts are from the public BrokerCheck report. +They are **registration history**, not a Verae claim and not an +endorsement by FINRA. + +* **Name on the report:** James H. Garfinkel +* **CRD:** 5052743 +* **Current registration:** this broker is **not currently + registered** +* **Disclosed events:** the report summary states **no** + events disclosed about this broker +* **Examinations recorded on the summary:** 0 + principal/supervisory exams; 3 general industry/product + exams; 3 state securities law exams +* **Investment adviser:** BrokerCheck points readers to the + SEC IAPD site for any IAR record + +**Prior broker registrations** listed on the report: + +* **LPL Financial LLC**, CRD 6413, New York, NY, + **January 2013 -- March 2024**, registered representative +* **Hornor, Townsend & Kent, Inc.**, CRD 4031, New York, NY, + **November 2011 -- December 2012** +* **Park Avenue Securities LLC**, CRD 46173, New York, NY, + **April 2008 -- October 2009** + +Other employment lines that appear in the same public report +family include **Abbott Solutions Inc.** (insurance advisor, +from November 2009) and **MPWM Advisory Solutions LLC** +(investment adviser representative, January 2014 -- November +2020). Readers should treat the PDF as the living source; +registration status changes. + +Education (public professional listings) +---------------------------------------- + +Public professional listings state: + +* **Hamilton College**, B.A. Economics, class of **1980** +* **United Nations International School**, class of **1975** + +Other ventures listed on professional-directory sites (not +FINRA, not verae.com) have included Beryl Consulting, Intaglio +Blockchain, and earlier broker-dealer roles. Those directory +sites are secondary; they are noted here only so that a reader +who searches the name is not surprised. They are not used as +primary evidence of Verae corporate structure. + +Why this biography is in the briefing +------------------------------------- + +A compliance briefing is not a pitch deck. Garfinkel's +biography is here because the user of this system is entitled +to know **who is on the commercial and regulatory-facing side +of Verae**, and because a broker-dealer or RIA CCO will +**look the name up on BrokerCheck anyway**. The honest +presentation is: + +* CEO of Verae LLC (public listing, from 2020); +* a long New York securities-industry registration history + ending March 2024 at LPL, **not currently registered**; +* **no** BrokerCheck disclosed events on the current report; +* **not** given a biography block on verae.com at the time + this document was compiled --- Haber is the scientist the + site puts on the homepage. + +Do not treat a CRD number as a product certification. Do not +treat a CEO biography as a control. diff --git a/source/bio-stuart-haber.rst b/source/bio-stuart-haber.rst new file mode 100644 index 0000000..b33dac2 --- /dev/null +++ b/source/bio-stuart-haber.rst @@ -0,0 +1,110 @@ +Stuart Haber +============ + +Role at Verae +------------- + +**Stuart Haber** is a **co-founder of Verae**. The company's +public site introduces him as one of the creators of +blockchain and as the inventor, in 1991, of cryptographic +timestamping --- "the science that lets you prove a record +hasn't been altered, and the foundation under every +blockchain since." The site quotes him: + + "I co-founded Verae to make blockchain accessible to + enterprises without having to deal with the complexity of + blockchain." + + --- Stuart Haber, Co-Founder of Verae; co-inventor of + blockchain timestamping, 1991 + +Verae's product claim is that this is the proof Haber has +been building toward: simple enough for a compliance team, +precise enough for an SEC exam, with the customer's records +remaining in the customer's storage and only a fingerprint +being sealed. + +The scientific work +------------------- + +Haber is a cryptographer. He worked at **Bellcore** (Bell +Communications Research) in Morristown, New Jersey, in the +late 1980s and 1990s, in the research culture descended from +Bell Labs. With physicist **W. Scott Stornetta** he posed a +problem that looks obvious only after it is solved: digital +documents live on media that can be altered without a mark; +how do you certify **when the bits existed**, without +trusting the disk, and without handing the document to the +timestamping service? + +**1991.** Stuart Haber and W. Scott Stornetta, "How to +Time-Stamp a Digital Document," *Journal of Cryptology*, +volume 3, number 2, pages 99--111. This is the paper that +introduces computationally practical digital timestamping +so that a user cannot back-date or forward-date a document +even with the collusion of a timestamping service, while +keeping the document itself private. Bitcoin's white paper +cites it as reference **[3]**. + +**1993.** Dave Bayer, Stuart Haber, and W. Scott Stornetta, +"Improving the Efficiency and Reliability of Digital +Time-Stamping," in *Sequences II: Methods in Communication, +Security and Computer Science*, pages 329--334. Merkle +trees, efficient certificates, publication of a compact +root. Bitcoin's white paper cites it as reference **[4]**. + +**1997.** Stuart Haber and W. Scott Stornetta, "Secure names +for bit-strings," *Proceedings of the 4th ACM Conference on +Computer and Communications Security*, pages 28--35. Bitcoin's +white paper cites it as reference **[5]**. + +Those three papers are **three of the eight** citations in +Satoshi Nakamoto, "Bitcoin: A Peer-to-Peer Electronic Cash +System" (2008). Haber has remarked that this is a .375 +batting average, and that Bitcoin is an application built on +top of the early blockchain rather than the invention of the +data structure itself. That is a historical statement, not a +claim that Verae is Bitcoin. + +Surety, 1994: first commercial blockchain +----------------------------------------- + +Haber and Stornetta took the research into production as +**Surety**. Surety hashed customer documents, linked those +hashes in a chain of certificates, and published a weekly +summary hash in the classified section of the Sunday *New +York Times*. That analog publication is widely described as +the oldest surviving public blockchain: a commitment that +does not depend on Surety's servers remaining honest or +online, because the *Times* is independently archived. The +design idea --- **commit a compact fingerprint to a widely +witnessed record, without revealing the documents** --- is +the same idea Verae productizes for enterprise compliance. + +Other cryptographic publications +-------------------------------- + +Haber's research record is broader than timestamping. It +includes work on minimum-knowledge interactive proofs, +symmetric public-key encryption, and secure multi-party +protocols (including "Cryptographic Computation: Secure +Fault-Tolerant Protocols and the Public-Key Model"). A +reader who wants the academic trail should start with the +three Bitcoin-cited papers and the 1991 *Journal of +Cryptology* article, then the ACM CCS 1997 paper. + +Why this biography is in the briefing +------------------------------------- + +Timestamping in this document is not a metaphor. It is a +specific scientific object --- hash, time, sequence, privacy +of the document from the notary --- that Haber defined in +print in 1991, commercialized in 1994, and is now building +into Verae so that a CCO can produce a receipt instead of a +vendor letter. The biography is here as **provenance of the +receipt**, not as a substitute for the organization's +controls. + +The same honesty that applies to Peergos applies here: +Haber co-invented the timestamping chain; he did not issue +the customer's SOC 2. diff --git a/source/checklist.rst b/source/checklist.rst index 5c7efaa..58c95d2 100644 --- a/source/checklist.rst +++ b/source/checklist.rst @@ -1,62 +1,96 @@ Audit-ready checklist ===================== -Use this as a working list. Check items only when **evidence exists** -(screenshot, log export, signed policy, ticket). This list is not a -certificate. +Use this as a working list. Check an item only when +**evidence exists** (screenshot, log export, signed policy, +ticket, receipt). This list is not a certificate. Software +having been installed does not tick these boxes. -A. Scope and data map +A. Scope and honesty +-------------------- + +* Named legal entity and systems in scope (console, Drive, + message fabric, IPFS, timestamping link, Iceberg archive) +* Written sentence in the system description: **software is + not our HIPAA / SOC 2 / ISO 27001 certificate** +* Data-flow diagram: endpoint → HPKE → DataCube → + Peergos/IPFS → receipt → Iceberg +* PHI / personal data vs ciphertext vs routing metadata, + named +* Peergos evaluation chapter attached, labeled **component + security evaluation** + +B. Data in transit +------------------ + +* Production algorithm is HPKE (or documented successor), + not a lab construction +* Destinations and subjects documented as **visible by + design** +* Error paths carry codes and lookup ids, not bodies +* Public-key directory lists public keys only; private keys + mode 0600 or HSM +* Broker operator named; metadata vs content in the annex + +C. Data at rest +--------------- + +* Customer holds Peergos / Drive keys; not on storage host +* Peergos hash verification on write and on read, evidenced +* Restore test: recover a cube from content-addressed + ciphertext **without** a plaintext tape +* Dual-hash cube chain; first-hash-wins registry + +D. Timestamping +--------------- + +* First-registration rule documented and tested (second + submit returns original receipt) +* Organizational node **linked** to central Verae, **or** + direct sync, named in the diagram +* Sample bundle: receipt + private metadata + attachment + pointer, redacted for the evidence pack +* Verae receives fingerprints, not objects --- stated in + the data map + +E. Write-once archive --------------------- -* Named legal entity and systems in scope (console, Drive, NATS, IPFS, ns1) -* Data-flow diagram: endpoint → HPKE/NATS → cryptree/IPFS -* What is PHI / personal data vs ciphertext vs routing metadata -* Peergos verification chapter attached (:doc:`verification`) +* Iceberg (or equivalent) export job exists and has a dated + last-run +* Object-lock / dual-control / separate account --- evidence + that no **single** party can delete a committed snapshot +* Retention schedule written by records/counsel, not by + engineering folklore +* Legal-hold procedure extends retention; ticket example -B. Keys and encryption ----------------------- +F. Access and change +-------------------- -* Customer holds Peergos/Drive keys; not on storage host -* NPE/HPKE endpoint keys in directory; private 0600; no xor content -* Signed Ed25519 config; unsigned rejected; admin-history prev+new+diff -* HSM or documented lab-to-HSM path - -C. Access ---------- - -* Console ``PFC_REQUIRE_AUTH=1``, TOTP; Drive login separate -* Inspect k-of-n; author is not an officer; log-before-reveal +* Console requires authentication (TOTP or equivalent); + Drive login is a separate plane +* Inspect is k-of-n; author is not an officer; log-before-reveal * Joiner / mover / leaver for console users -* Google SSO does **not** unwrap cubes +* Signed configuration; unsigned rejected; admin-history + prev + new + diff +* HSM or a dated plan to move lab keys to HSM -D. Integrity and backup ------------------------ - -* Cube chain append-only JSONL; dual hash -* Hash registry: first SHA-256 and receipt win -* Peergos/IPFS: hash-verified encrypted blocks (restore = re-fetch CIDs) -* Restore test: recover a cube from content-addressed ciphertext without - plaintext backup tapes - -E. Logging ----------- - -* Inspect audit events -* SM summaries: codes + lookup_id only (no bodies) -* Admin-history cube for config - -F. Contracts (counsel) +G. Contracts (counsel) ---------------------- -* Written BA / not-a-BA determination for disk, VM, backup, IPFS -* DPA Art. 28 where usernames/logs/IPs are processed -* NATS operator: metadata vs content in the annex -* Peergos component assurance: attach Cure53 2019 + ROS 2024 PDFs - (public; not your org’s ISO/SOC report) +* Written BA / not-a-BA determination for disk, VM, backup, + IPFS, Iceberg +* DPA Article 28 where usernames, logs, or IPs are processed +* NATS operator: metadata vs content +* Verae timestamping: fingerprint-only processing described +* Peergos PDFs attached and labeled "not our Type II / ISO" -G. Independent audit of *you* ------------------------------ +H. Independent examination of *this* organization +------------------------------------------------- -* SOC 2 Type I/II engagement **or** ISO 27001 registrar **or** HIPAA - risk analysis + policies (pick the program you actually need) +* SOC 2 Type I/II engagement, **or** ISO 27001 registrar, + **or** HIPAA risk analysis plus policies --- **the program + actually chosen**, not all three as wallpaper * Evidence window (Type II / surveillance) if applicable +* Named internal owner who will sit in the meeting and not + claim the software is the certificate diff --git a/source/conf.py b/source/conf.py index 8cbe628..61eade9 100644 --- a/source/conf.py +++ b/source/conf.py @@ -1,24 +1,141 @@ +# Sphinx configuration — Making yourself audit-ready with Verae DataCubes +# Logo on every page: https://www.verae.com/Assets/VeraeFullLogo.png + project = "Making yourself audit-ready with Verae DataCubes" -copyright = "2026, Verae" -author = "Verae / George Lambert" +copyright = "2026, Verae Inc" +author = "Verae Inc" +release = "2026.09" +version = "2.0" + extensions = [] templates_path = ["_templates"] -exclude_patterns = [] +exclude_patterns = ["verification.rst"] + html_theme = "alabaster" html_static_path = ["_static"] html_title = project +html_logo = "_static/VeraeFullLogo.png" +html_favicon = "_static/VeraeFullLogo.png" +html_css_files = ["verae.css"] +html_copy_source = False +html_show_sourcelink = False +html_theme_options = { + "logo": "VeraeFullLogo.png", + "logo_name": False, + "description": "Tools for storage, communications, timestamping, verification, and audit — not a certificate.", + "fixed_sidebar": True, + "page_width": "980px", + "sidebar_width": "240px", + "show_powered_by": False, +} + latex_engine = "pdflatex" latex_documents = [ ( "index", "peergos-making-yourself-audit-ready-with-verae-datacubes.tex", - "Making yourself audit-ready with Verae DataCubes", - "Verae", + r"Making yourself audit-ready with Verae DataCubes", + r"Verae Inc", "manual", ), ] +latex_additional_files = ["_static/VeraeFullLogo.png"] +latex_show_pagerefs = False +latex_show_urls = "footnote" +latex_toplevel_sectioning = "chapter" + +_PREAMBLE = r""" +\usepackage{graphicx} +\usepackage{xcolor} +\usepackage{fancyhdr} +\usepackage{needspace} +\DeclareUnicodeCharacter{2014}{---} +\DeclareUnicodeCharacter{2013}{--} +\DeclareUnicodeCharacter{201C}{``} +\DeclareUnicodeCharacter{201D}{''} +\DeclareUnicodeCharacter{2018}{`} +\DeclareUnicodeCharacter{2019}{'} +\DeclareUnicodeCharacter{25BC}{v} +\definecolor{veraepurple}{HTML}{5B2C8B} +\definecolor{veraedark}{HTML}{1A0A24} +\definecolor{veraeink}{HTML}{111111} + +% Extra headroom so the logo never collides with body text. +\setlength{\headheight}{44pt} +\addtolength{\topmargin}{-14pt} + +\newcommand{\VeraeLogo}{\includegraphics[height=0.92cm]{VeraeFullLogo.png}} +\newcommand{\VeraeFooter}{% + \footnotesize\color{veraepurple}% + Verae Inc \textbullet\ https://www.verae.com \textbullet\ + Book a call at verae.com \textbullet\ app.verae.com} + +\fancypagestyle{normal}{ + \fancyhf{} + \fancyhead[L]{\colorbox{veraedark}{\VeraeLogo}} + \fancyhead[R]{\small\color{veraepurple}Audit-ready with Verae DataCubes} + \fancyfoot[L]{\VeraeFooter} + \fancyfoot[R]{\footnotesize\color{veraepurple}\thepage} + \renewcommand{\headrulewidth}{0.6pt} + \renewcommand{\footrulewidth}{0.4pt} + \renewcommand{\headrule}{\hbox to\headwidth{\color{veraepurple}\leaders\hrule height \headrulewidth\hfill}} + \renewcommand{\footrule}{\hbox to\headwidth{\color{veraepurple}\leaders\hrule height \footrulewidth\hfill}} +} +\fancypagestyle{plain}{ + \fancyhf{} + \fancyhead[L]{\colorbox{veraedark}{\VeraeLogo}} + \fancyfoot[L]{\VeraeFooter} + \fancyfoot[R]{\footnotesize\color{veraepurple}\thepage} + \renewcommand{\headrulewidth}{0.6pt} + \renewcommand{\footrulewidth}{0.4pt} +} +\pagestyle{normal} + +% Each Sphinx chapter already starts a new page in the manual class. +% Keep first-page headers branded as well. +\makeatletter +\let\sphinx@originalchapter\chapter +\renewcommand{\chapter}{\clearpage\thispagestyle{plain}\sphinx@originalchapter} +\makeatother +""" + latex_elements = { "papersize": "letterpaper", "pointsize": "11pt", - "preamble": r"\usepackage{hyperref}", + "preamble": _PREAMBLE, + "fncychap": r"\usepackage[Sonny]{fncychap}", + "printindex": "", + "maketitle": r""" +\begin{titlepage} +\thispagestyle{empty} +\vspace*{1.4cm} +\begin{flushleft} +\colorbox{veraedark}{\includegraphics[width=7.2cm]{VeraeFullLogo.png}} +\end{flushleft} +\vspace{1.6cm} +{\color{veraepurple}\rule{\textwidth}{1.6pt}} +\vspace{0.7cm} +{\Huge\bfseries Making yourself audit-ready\\[0.25em] with Verae DataCubes\par} +\vspace{0.55cm} +{\Large Software is not a HIPAA, SOC 2, or ISO 27001 certificate.\par} +\vspace{0.35cm} +{\large A technical briefing on what the Verae DataCube Server Solution +provides for data in transit and data at rest --- and what every +organization must still do itself.\par} +\vspace{0.9cm} +{\color{veraepurple}\rule{\textwidth}{0.6pt}} +\vspace{0.7cm} +{\large Verae Inc\\[0.2em] +https://www.verae.com\\[0.2em] +Book a call at verae.com\\[0.2em] +app.verae.com\par} +\vfill +{\small September 2026 \textbullet\ Document version 2.0\par} +\end{titlepage} +\clearpage +""", + "tableofcontents": r""" +\tableofcontents +\clearpage +""", } diff --git a/source/contact.rst b/source/contact.rst new file mode 100644 index 0000000..e003320 --- /dev/null +++ b/source/contact.rst @@ -0,0 +1,45 @@ +Verae Inc --- contact +===================== + +This page is the contact block that also appears in the +footer of every page of the PDF edition and at the bottom +of every HTML chapter. + +**Verae Inc** + +Website: https://www.verae.com + +Product / activity console: https://app.verae.com + +Book a conversation: use the "Book a call" path on +https://www.verae.com (the public site states that the +company will be in touch within one business day). + +API (fingerprint seal, as described on the public site): +https://api.verae.com/v1/seal + +This briefing (HTML and PDF): + +* https://docs.pfc.georgelambert.org/audit-ready/ +* https://git.georgelambert.org/marchon/peergos-making-yourself-audit-ready-with-verae-datacubes + +A street address and telephone number are **not invented +here**. If a procurement file requires them, take them from +a current Verae engagement letter, W-9, or the form on +verae.com, not from this paragraph. + +Closing reminder +---------------- + +Software alone does not make an organization HIPAA +certified, SOC 2 attested, or ISO 27001 certified. + +The Verae DataCube Solution gives you tools to store, +communicate, timestamp, verify, and audit. Your +organization still has to write the policies, run the +procedures, operate the internal controls, and sit with an +independent auditor. Verae provides the tools, the +background, and the software infrastructure for the +**technical portion** of that work. + +Verae Inc --- https://www.verae.com diff --git a/source/data-at-rest.rst b/source/data-at-rest.rst new file mode 100644 index 0000000..ec041ea --- /dev/null +++ b/source/data-at-rest.rst @@ -0,0 +1,136 @@ +Encryption at rest --- IPFS blocks and Peergos +============================================== + +The problem +----------- + +Bytes that are no longer moving still have to live somewhere: a +disk, a replica, a backup, a cold archive. The people who operate +those surfaces --- hosting providers, backup operators, someone +with a snapshot credential --- are rarely the same people who are +authorized to read the records. A design that stores plaintext on +those surfaces is a design that makes every disk operator a +reader. A design that stores ciphertext, but lets an operator +swap a block without detection, is a design that fails integrity +even if it keeps confidentiality. + +The Verae DataCube Server Solution stores **data at rest** as +**encrypted, content-addressed IPFS blocks**, with **Peergos** +verifying hashes on the way in and the way out. + +Content-addressed blocks +------------------------ + +IPFS names a block by a cryptographic hash of its contents (a +Content Identifier, or CID). Two properties follow immediately: + +* If the bits change, the name changes. There is no such thing as + "the same CID, different payload" under a collision-resistant + hash. +* A client that asked for CID X and received bytes whose hash is + not X **knows** it was given the wrong object. + +That is the definition of a **tamper-evident** store. It does not +prevent a hostile replica from refusing to serve a block +(availability). It does prevent a hostile replica from silently +serving a substitute and hoping nobody notices (integrity). + +Peergos on top of IPFS +---------------------- + +Peergos is not "IPFS with a folder UI." It is an encrypted +filesystem --- a **cryptree** --- whose nodes and file chunks are +stored as IPFS blocks. The properties that matter for an +audit-ready DataCube are: + +* **Client-side encryption.** Symmetric keys for chunks live with + the customer, not on the storage host. A host with disk access + sees padded, encrypted chunks and random labels, not filenames, + not sibling names, not a social graph. +* **Hash verification.** Peergos **verifies the hash** of every + block it reads from or writes to IPFS. A restored cube is not + "whatever was on the tape." It is a set of CIDs re-fetched and + re-checked. +* **Signed writes.** Updates are signed. An unsigned rewrite is + not a valid Peergos write. +* **Independent chunk keys.** Chunks (up to 5 MiB, padded) are + encrypted with random 256-bit keys (Salsa20-Poly1305 in the + published design), not with convergent encryption that would + leak equality of plaintext across users. +* **CHAMP** places encrypted cryptree nodes under random 32-byte + labels, so the storage host cannot walk the directory tree by + name. +* **Sharing** uses hybrid encryption (X25519 plus ML-KEM-1024 in + current Peergos) so a capability can be given to another user + without placing the chunk key on the server. + +Tamper-evident restore +---------------------- + +"Backup" in this architecture does not mean a second plaintext +copy in a different building. It means: + +1. the CIDs that constitute a cube are known; +2. the encrypted blocks for those CIDs exist on more than one + replica; +3. a restore **re-fetches** the blocks and **re-verifies** the + hashes; +4. the customer, holding keys, decrypts locally. + +If step 3 fails, the restore fails closed. That is the opposite +of a backup product that "helpfully" returns the last good +plaintext it had. Helpfulness of that kind is how silent +corruption and silent substitution enter an evidence set. + +Append-only at the cube layer +----------------------------- + +Peergos itself uses signed updates and immutable blocks. The +Verae DataCube adds an **application-level chain**: a JSONL +history in which each record hashes the previous record. Dual +hashing (for example SHA-256 plus BLAKE2b or BLAKE3) is used so +that a future weakness in one function does not silently rewrite +history. + +These two layers must not be conflated in an audit interview: + +* **IPFS / Peergos** prove that the bytes retrieved are the bytes + named by the CID, and that names and sizes are not in the + clear on the host. +* **The cube chain** proves that the organization's own history + of writes is append-only at the application layer. + +Both are needed. Neither is a SOC 2 report. + +What a disk operator sees +------------------------- + +If keys never leave the client or the customer's HSM, a disk +operator, a VM snapshot operator, and an offsite replica operator +see **opaque hashed ciphertext**. They do not see PHI, they do +not see document titles, they do not see the graph of who shared +what with whom. + +That fact **changes the Business Associate / processor +conversation**. It does not automatically end it. Usernames, IP +addresses, billing identity, and support logs can still be +personal data. Chapter 11 takes that up. + +What this does, and does not, satisfy +------------------------------------- + +For HIPAA encryption of ePHI **at rest**, for SOC 2 CC6 +encryption of stored data, and for ISO 27001 Annex A cryptography +and storage, this is the **technical control**: ciphertext on +disk, keys with the customer, hash-checked restore. + +It does **not** by itself satisfy: + +* a **key-custody policy** (who can unwrap, where the HSM lives, + how a lost key is declared); +* a **restore-test procedure** with a dated ticket proving + someone actually did it last quarter; +* **retention and legal-hold** rules (those require the + write-once archive in Chapter 9, plus lawyers); +* **physical** security of the machines, which still belongs in + the organization's ISMS or HIPAA facility controls. diff --git a/source/data-in-transit.rst b/source/data-in-transit.rst new file mode 100644 index 0000000..4d6afed --- /dev/null +++ b/source/data-in-transit.rst @@ -0,0 +1,111 @@ +Secure communications --- data in transit +========================================= + +The problem +----------- + +A message that leaves one machine and arrives at another crosses +infrastructure the endpoints do not own: routers, load balancers, +message brokers, TLS terminators, packet-capture appliances, and +people with legitimate operational access to those devices. Any of +those parties can copy bits. The honest design question is not +"will anyone see the packet" --- they will --- but "**what** will +they see, and **what** will they be able to do with it." + +The Verae DataCube Server Solution answers that question with +**point-to-point encryption of content** and an explicit admission +that **routing must be visible**. + +Point-to-point encryption +------------------------- + +"Best in class" here is not a slogan; it names a concrete choice. +Production content is sealed with **HPKE** (Hybrid Public Key +Encryption, RFC 9180), in the HPKE-Base mode, using a suite such as +X25519-HKDF-SHA256 with ChaCha20-Poly1305. Each endpoint has a +key pair. The sender looks up the recipient's **public** key in a +directory that is visible to every E2E service. The sender seals +the body to that public key. Only the holder of the matching +**private** key can open it. + +Consequences that matter in an audit interview: + +* The **sender cannot reopen** the ciphertext after it is sealed + unless the sender is also a recipient or has retained plaintext. + A lookup identifier is enough to talk about the message later + without retaining a second copy of the body. +* The **broker cannot open** the body. Possession of the wire + image is possession of ciphertext. +* A **lab XOR** construction, if it exists in a codebase for + experiments, is not a production algorithm. Production + configurations reject it. + +Visible routing +--------------- + +A network that cannot see a destination cannot deliver a message. +The DataCube Server Solution therefore does **not** claim +anonymous, metadata-free messaging. The following remain visible +to the transport, by design: + +* destination (the handle or address the router needs); +* subject or stream name (so the right service receives the + envelope); +* sender handle or lookup identifier, when the protocol carries + them for reply and error handling; +* approximate size and timing (any network sees these). + +This is the **honest-but-curious broker** model. Curiosity is +assumed. Honesty is assumed only in the narrow sense that the +broker forwards what it is given; it is **not** trusted with +content, and it is **not** trusted not to log destinations. + +Error handling without leaking content +-------------------------------------- + +Failures have to be reported. A bounce that includes the original +body would undo the encryption. The design therefore returns +**error metadata**: an error code, a lookup identifier, a +destination class --- not the plaintext, and not a replay of the +ciphertext into a log aggregator that is a second, weaker store. + +Network Error Bundles can carry a sender-visible ciphertext and a +system-visible ciphertext so that the right party can diagnose +without broadcasting the payload to operators who should never see +it. + +The public-key directory +------------------------ + +Point-to-point encryption is only as good as the lookup of public +keys. The server solution publishes a **directory of public keys** +so that availability of those keys is visible to all E2E services. +Private keys do not belong in that directory. Private key files +are mode ``0600``, held on the endpoint or in an HSM, and are +never returned by the public listing API. + +An examiner can be shown the public listing. An examiner should +never be given a private key. + +What this does, and does not, satisfy +------------------------------------- + +For HIPAA Security Rule addressable encryption of ePHI **in +transit**, for SOC 2 CC6 cryptographic transmission, and for +ISO 27001 Annex A transmission security, this design is the +**technical control**: content is encrypted to the recipient, the +path is untrusted, keys are endpoint-held. + +It does **not** by itself satisfy: + +* a rule that requires the organization to **inventory** every + channel (personal devices, shadow SaaS, unapproved AI tools); +* a rule that requires **workforce sanctions** when someone + bypasses the channel; +* a rule that requires **agreements** with the broker operator + covering metadata that may still be personal data. + +Those remain policies, procedures, and contracts. The software +makes the approved channel strong. It cannot stop a person from +using a weak channel instead. That is an organizational control, +not a cryptographic one. diff --git a/source/datacube-server.rst b/source/datacube-server.rst new file mode 100644 index 0000000..4c7c0b7 --- /dev/null +++ b/source/datacube-server.rst @@ -0,0 +1,110 @@ +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. diff --git a/source/executive.rst b/source/executive.rst new file mode 100644 index 0000000..a01b8a5 --- /dev/null +++ b/source/executive.rst @@ -0,0 +1,159 @@ +Executive summary +================= + +Software alone does not make an organization HIPAA certified, SOC 2 +attested, or ISO 27001 certified. + +That sentence is the point of this document. It is also the sentence +that is most often skipped when a vendor, an integrator, or an internal +champion shows encryption, hashing, or a pentest PDF and treats the +conversation as finished. It is not finished. Encryption is a control. +A pentest is an evaluation of a component. A certificate, an attestation, +or a covered-entity determination is a statement about **an organization** +--- its legal entity, its people, its written policies, its operating +procedures, its internal controls, the evidence those controls produce, +and the independent party that examined that evidence. + +The Verae DataCube Solution gives an organization tools to **store**, +**communicate**, **timestamp**, **verify**, and **audit** for compliance. +Those tools are real, they are specific, and they are described in the +chapters that follow. They are still only tools. To obtain HIPAA-aligned +status as a covered entity or business associate with a defensible +program, a SOC 2 Type I or Type II report, or an ISO 27001 certificate, +the organization must still: + +* write and live by **policies** (what the organization says it will do); +* operate **procedures** (how staff actually do it, every day); +* design and test **internal controls** (the checks that catch failure); +* retain **evidence** (logs, tickets, screenshots, signed approvals, + restore tests, training records); +* engage an **independent auditor**, CPA firm, or ISO registrar, as the + chosen program requires. + +Verae cannot issue those certificates. Verae cannot sit in the +organization's chair during an OCR investigation, a SOC 2 fieldwork +week, or an ISO Stage 2 audit. What Verae can do --- and what this +briefing is written to make precise --- is provide the **tools**, the +**background**, and the **software infrastructure** that make it easier +to implement the **technical portion** of those programs. + +What a Verae DataCube Server Solution does +------------------------------------------ + +A Verae DataCube Server Solution provides **secure communications and +storage** for two classical information-security states: + +* **Data in transit** --- messages, objects, and control traffic while + they move from one endpoint to another. +* **Data at rest** --- messages, objects, metadata, and receipts while + they sit on disk, in a replica, or in an archive. + +Those two states are not the same problem, and they are not solved by +the same mechanism. This document treats them separately on purpose. + +Data in transit +--------------- + +Verae uses best-in-class encryption for messaging **from point to +point**. The content of a message is sealed so that only the intended +endpoints can open it. Routing, however, **must remain visible**: a +message that cannot be addressed cannot be delivered. Subjects, +destination handles, and size or timing metadata are therefore +visible to the transport. The transport is treated as +**honest-but-curious**. It can drop, delay, or copy ciphertext. It +cannot read the body if it does not hold endpoint private keys. + +Data at rest +------------ + +Encryption at rest is performed through **IPFS content-addressed +blocks**. Each block is named by its hash. Peergos verifies those +hashes on read and on write. A restore is therefore +**tamper-evident**: if a block was altered, its hash no longer +matches, and the client refuses it. This is not a plaintext tape +backup. It is a re-fetch of hashed ciphertext plus a verification +that the bits are the bits that were stored. + +Global timestamped receipts +--------------------------- + +Independently of who stores the bytes, Verae issues **global +timestamped receipts** based on **document hashes**. A receipt is +proof of the **time and sequence of the first registration** of a +block of digital information --- a message, an image, a document, or +any other digital object that can be stored in digital media. The +receipt does not require Verae to see the object. It requires a +fingerprint of the object, registered at a time that can later be +shown to third parties. + +Peergos, evaluated in Europe +---------------------------- + +The offline storage and replication system used with Peergos was +**audited twice in Europe**, and the protocol was designed under +work that was independently reviewed: + +* **2019 --- Cure53, Berlin, Germany.** Pentest, source-code audit, + and **crypto/design review** (May--June 2019). No fundamental + architectural or cryptographic problems. Issues found were fixed. + Cure53 stated that the platform **passed this evaluation**. +* **2024 --- Radically Open Security B.V., Amsterdam, Netherlands.** + Crystal-box pentest plus code audit of the Peergos web UI + (September--November 2024). **Zero** findings rated extreme, high, + or elevated; **two** moderate; **six** low. Peergos states all + were fixed. No data exposure and no integrity compromise (the + issues were mostly UI crashes). + +Both firms are **EU-based**. Both full reports are **public**. That +is a **security evaluation of the Peergos protocol and +implementation**. It is **not** a HIPAA certificate, a SOC 2 report, +or an ISO 27001 certificate for Peergos, for Verae, or for any +customer. + +Verae global timestamping +------------------------- + +The Verae Global Timestamping and receipt solution is a +**cross-blockchain** design. It certifies the time and date stamp of +a digital object and stores that information in a **digital bundle** +that can carry private metadata, attached files, and an internal +blockchain. That organizational chain is **cross-verified** either: + +* from an organizational server **linked to the central Verae + server**, or +* by **directly syncing** with Verae's central timestamping server. + +The result is **proof of existence** of a digital object at a +specific time and date. When the organization wants the object +itself stored --- not only its fingerprint --- the object can live +inside an **encrypted Peergos DataCube**. + +Write-once Iceberg archive +-------------------------- + +Those DataCubes are archived into a **write-once external Iceberg +file-storage solution** for compliance reasons. The archive is +designed to sit **outside the deletion control of any single +party**. That is a retention and legal-hold property, not a +marketing slogan: once a cube is committed to the write-once tier, +neither the customer operator, nor Verae, nor a hosting vendor +should be able to quietly erase it. + +What this briefing is, and is not +--------------------------------- + +This briefing describes the **technical portion** of a compliance +program that an organization can build with Verae DataCubes. It +indexes each of the points above as its own chapter, in enough +detail that a CISO, a CCO, outside counsel, or an auditor can +distinguish: + +* what the software **does**; +* what the independent **Peergos evaluations** actually said; +* what **Verae timestamping** actually proves; +* what the organization **must still write, operate, and have + examined**. + +It does not claim that installing this software finishes HIPAA, +SOC 2, or ISO 27001. Anyone who says otherwise is not describing +this product honestly. diff --git a/source/global-timestamping.rst b/source/global-timestamping.rst new file mode 100644 index 0000000..f1b1caf --- /dev/null +++ b/source/global-timestamping.rst @@ -0,0 +1,138 @@ +Verae global timestamping --- a cross-blockchain receipt +======================================================== + +Lineage +------- + +The scientific problem Verae is productizing is not new. In +1991, Stuart Haber and W. Scott Stornetta published "How to +Time-Stamp a Digital Document" in the *Journal of +Cryptology*. They asked how to certify when a digital +document was created or last changed **without trusting the +medium** and **without giving the timestamping service the +document**. In 1993, with Dave Bayer, they showed how Merkle +trees make that efficient. In 1997 they published "Secure +names for bit-strings." Satoshi Nakamoto's 2008 Bitcoin +white paper cites those three papers as references [3], [4], +and [5] --- three of the eight citations in that document. + +Haber co-founded **Surety** in 1994, widely described as the +first commercial blockchain: a hash-linked chain of document +certificates, with a weekly summary published in the Sunday +*New York Times* so that the day's commitments sat in a +public, widely archived analog record. + +Haber is a **co-founder of Verae**. Verae's public site +states the aim directly: make that proof simple enough for a +compliance team and precise enough for an SEC exam, without +forcing the enterprise to operate a public blockchain. The +quote on verae.com is: "I co-founded Verae to make +blockchain accessible to enterprises without having to deal +with the complexity of blockchain." + +What "cross-blockchain" means here +---------------------------------- + +A single private log, held only by the vendor, is a vendor +assurance letter with extra steps. A single public chain may +be operationally and commercially the wrong place to put an +enterprise's registration traffic. Verae's design is +**cross-blockchain** in the following sense: + +* an **organizational chain** runs at the customer, inside + or beside the DataCube, recording hashes, metadata, and + sequence; +* a **central Verae chain** records fingerprints and issues + receipts; +* the two are **cross-verified**, so that neither side can + rewrite history without the other side's record disagreeing; +* when policy calls for it, commitments can be **anchored + further** --- additional public or consortium chains --- so + that proof of existence does not collapse if one operator + disappears. + +The customer does not have to become a blockchain operator +to use this. That is the product claim. The examiner does +not have to trust a single vendor's database to verify a +receipt. That is the scientific claim, inherited from +Haber--Stornetta. + +Two deployment patterns +----------------------- + +**Linked organizational server.** The organization runs a +timestamping node next to its DataCube server. That node is +linked to the central Verae timestamping server. Local +registrations are committed locally (low latency, private +metadata stays home) and cross-verified centrally (receipt +the rest of the world can check). + +**Direct sync.** An organization that does not want to run +the organizational node can sync registrations directly with +Verae's central timestamping server. Proof of existence at a +specific date and time still issues. Private metadata and +attached files, if any, remain the organization's problem to +store --- typically in the encrypted Peergos DataCube. + +Both patterns produce the same external artifact: a receipt +bound to a hash, a time, and a sequence. They differ in +where the organizational metadata lives and in how much +infrastructure the customer operates. + +The digital bundle +------------------ + +The unit of production is a **digital bundle**: + +* the **receipt** (hash, time, sequence, verification path); +* **private metadata** (classification, matter, hold, + internal identifiers) that need not be on a public chain; +* **attached files** that should be produced together; +* a pointer or capability to the object in the encrypted + DataCube, when the organization chose to store the object + and not only its fingerprint. + +An examiner can be given the bundle, or a redacted bundle, +without being given a login to the production console and +without Verae ever having seen the object bytes. + +Proof of existence versus proof of custody +------------------------------------------ + +Timestamping answers: **did these bits exist by this time?** + +The DataCube answers: **does the organization still have +them, encrypted, hash-checkable?** + +The Iceberg write-once tier answers: **can anyone quietly +delete them anyway?** + +A complete production to a regulator often needs all three. +Timestamping alone is not an archive. An archive without a +receipt is a pile of files with a clock on the filesystem +that the administrator can set. + +What this does, and does not, satisfy +------------------------------------- + +For SEC Rule 17a-4, FINRA books-and-records, and similar +regimes that demand records in a non-rewriteable, +non-erasable form **with the ability to produce the +original**, timestamped receipts plus write-once archive are +the **technical portion** of the answer: you can show when +the record was sealed, that the bits match, and that the +archive copy is not under ordinary delete. + +They do not satisfy: + +* the requirement to **capture the channel in the first + place** (if the team used an unsealed tool, there is + nothing to timestamp); +* the requirement to have **written procedures** for + production, legal hold, and supervision; +* the requirement that a **named principal** own the + recordkeeping obligation. + +Software seals what it is shown. The organization must still +show it the right things, on time, under a policy someone +will sign. diff --git a/source/howto.rst b/source/howto.rst index e6d2452..ed9dc8e 100644 --- a/source/howto.rst +++ b/source/howto.rst @@ -1,30 +1,65 @@ -How to use this pack -==================== +How to use this briefing +======================== -1. Read :doc:`verification` so you do not over-claim Peergos audits. -2. Fill :doc:`checklist` with **your** instance evidence (ns1, keys, users). -3. Give :doc:`baa-dpa` to counsel with the data-flow from :doc:`architecture`. -4. Point auditors at live technical surfaces (do not give them private keys). +1. Read the **executive summary** aloud in the first five + minutes of any vendor, board, or auditor meeting that + touches this system. If anyone says "so we are certified," + stop and reread Chapter 1. + +2. Read **What Verae provides** so the five verbs (store, + communicate, timestamp, verify, audit) are not confused + with an ISMS, a Type II, or a HIPAA program. + +3. Read the **transit**, **rest**, **receipts**, **Peergos + evaluations**, **timestamping**, and **Iceberg** chapters + in that order. They are the technical portion, in the + order an examiner usually probes: "can the wire read it, + can the disk read it, can you prove when, who looked at + the crypto, can you produce it later." + +4. Fill the **checklist** with **this instance's** evidence. + Empty checkboxes are not a moral failing; they are the + work remaining. + +5. Give **BAAs and DPAs** to counsel with the architecture + diagram. Do not let engineering declare a vendor "not a + BA." + +6. Attach the two **public** Peergos reports as **vendor + security evaluations**, with a cover slip that says they + are not the organization's SOC 2, ISO 27001, or HIPAA + certification. + +7. Point auditors at **live technical surfaces** (health, + public-key listing, Drive). Do not give them private + keys. Do not give them a story that the pentest PDF is + the Type II. + +8. Keep the **biographies** at the back of the PDF for + provenance --- who built the timestamping science, who + is building the product, who architected the internet + integration and the DataCube server side --- without + substituting biography for controls. .. only:: html + Reference instance (not a certificate): + * https://pfc.georgelambert.org/health * https://pfc.georgelambert.org/v1/npe/keys (public keys only) * https://docs.pfc.georgelambert.org/controls.html * https://docs.pfc.georgelambert.org/custody.html - * Peergos Drive (cryptree) on your host - * https://git.georgelambert.org/marchon/peergos-for-compliance - * https://git.georgelambert.org/marchon/system-git-sync - * https://git.georgelambert.org/marchon/secure-messaging - -5. Attach the two **public** Peergos pentest PDFs from the Peergos - ``audits/`` tree as **vendor security evaluations**, labeled “not our - SOC 2 / ISO certificate”. + * https://git.georgelambert.org/marchon/peergos-making-yourself-audit-ready-with-verae-datacubes + * https://www.verae.com .. only:: latex - Companion system PDF (same folder): + Companion system PDFs in the same folder: .. raw:: latex - \href{peergos-for-compliance.pdf}{peergos-for-compliance.pdf} + \begin{itemize} + \item \href{peergos-for-compliance.pdf}{peergos-for-compliance.pdf} + \item \href{nats-service-endpoints.pdf}{nats-service-endpoints.pdf} + \item \href{secure-messaging.pdf}{secure-messaging.pdf} + \end{itemize} diff --git a/source/iceberg-archive.rst b/source/iceberg-archive.rst new file mode 100644 index 0000000..177699b --- /dev/null +++ b/source/iceberg-archive.rst @@ -0,0 +1,131 @@ +Write-once Iceberg archive +========================== + +The deletion problem +-------------------- + +Encryption at rest stops a disk operator from **reading**. +Hash verification stops a replica from **substituting**. +Timestamped receipts stop a custodian from **back-dating**. +None of those, by themselves, stop a person with legitimate +administrative power from **deleting**. + +Deletion is the failure mode that turns a recordkeeping +program into a fine. Off-channel messaging cases at +broker-dealers were, at bottom, failures to **produce**. A +record that existed and was then removed, "cleaned up," or +rotated out of the only copy is, to an examiner, a record +that cannot be produced. + +Compliance therefore needs a tier where **ordinary +administrative power does not include delete**. + +What "write-once Iceberg" means in this solution +------------------------------------------------ + +DataCubes --- the encrypted, hash-chained containers --- are +**archived** into an **external, write-once file-storage +solution** built on the **Iceberg** table/file model (a +layout of immutable data files plus a metadata log that +records new snapshots rather than rewriting old ones). + +Properties the solution is specified to have: + +* **Write once.** A committed archive object is not updated + in place. A correction is a **new** object with a **new** + receipt. The original remains. +* **External.** The archive is not the same disk as the + live Peergos instance. Compromising the live server should + not confer delete on the archive. +* **Outside any single party's deletion control.** The + customer operator, Verae, and the hosting vendor are each + insufficient, by themselves, to erase a committed archive + file. Practical implementations of that requirement use + some combination of object-lock / WORM flags, dual-control + hold, independent cloud or tape accounts, and contractual + prohibition on early delete --- plus the technical fact + that Iceberg snapshots are new files, not overwrites. +* **For compliance reasons.** This tier exists because + retention schedules, legal holds, and examiner production + require it --- not because it is a convenient backup. + +How cubes move into the archive +------------------------------- + +A live DataCube is an operational object: it receives new +writes, it is replicated as encrypted IPFS blocks, it is +readable by holders of the right capabilities. On a schedule +and on events (legal hold, period close, exam notice), the +server solution **exports** a cube snapshot: + +1. freeze a CID set and cube-chain head; +2. confirm Peergos hash verification of every block in the + set; +3. register that snapshot's hash with Verae timestamping + (first registration of *this* snapshot); +4. write the encrypted snapshot into Iceberg as a new + immutable data file (or set of files) under a snapshot + id that never reuses a previous id; +5. record, in admin-history, that the archive job ran, who + authorized it, and which receipt was issued. + +A restore from the archive is the same tamper-evident path +as a restore from IPFS: re-fetch, re-verify hashes, decrypt +only with customer keys. + +What "outside the control of any party for deletion" is +and is not +------------------------------------------------------- + +It is **not** a claim that physics forbids destruction of +every copy in a fire, a court order, or a coordinated +malicious act by every holder of every credential. No +storage system honestly claims that. + +It **is** a claim that the **ordinary** delete path --- the +button, the ``rm``, the lifecycle rule, the "empty trash," +the support ticket to "please remove that customer folder" +--- is not available to any one party acting alone against a +committed archive object. Dual control, object lock, and +separation of the archive account from the live-server +account are the organizational complements to the file +format. + +The organization's retention policy still has to name: + +* how long a class of record stays in write-once; +* who can place a legal hold that **extends** that period; +* who, under **what dual control**, may allow a record to + age out **after** the policy period, if aging out is + legally permitted at all. + +Software can refuse a delete API. It cannot write the +retention schedule. Counsel and the records officer do that. + +Relation to classical WORM +-------------------------- + +Broker-dealer Rule 17a-4 and similar texts speak of +non-rewriteable, non-erasable media, originally meaning +optical WORM, later allowing disk with object-lock semantics +and a designated third party. Verae's public comparison is +that conventional WORM is **immutable by policy** (a vendor +setting), whereas Verae **seals** a record with +cryptographic proof. The Iceberg write-once tier is where +those two ideas meet: the file is not overwritten **and** +the snapshot hash is receipted. An examiner can check the +receipt even if they do not trust the vendor's "WORM was +on" screenshot. + +What this does, and does not, satisfy +------------------------------------- + +This is the **technical portion** of retention and +production: committed cubes are not under a single delete +key, they are hash-checkable, and they carry a time of +archival. + +It does not satisfy a retention **policy** that was never +written, a legal hold that was never placed, or a production +request that the organization answers from a laptop copy +instead of from the archive. Those are procedures. diff --git a/source/index.rst b/source/index.rst index 6482344..f0023b0 100644 --- a/source/index.rst +++ b/source/index.rst @@ -1,61 +1,40 @@ Making yourself audit-ready with Verae DataCubes ================================================ -How to **prepare an organization** for HIPAA-aligned, SOC 2, or ISO 27001 -work using Verae DataCubes on **Peergos** (encrypted cryptree + hashed -IPFS) and HPKE on an **untrusted NATS** broker. +.. only:: html -**This document is not a HIPAA, SOC 2, or ISO certificate.** -Peergos’s public pentests are **not** your Type II or ISO registrar -certificate. They are **component security evaluations** you can attach. + .. image:: _static/VeraeFullLogo.png + :width: 280px + :alt: Verae + :class: logo + +This volume is a technical briefing. It is **not** a certificate. + +The table of contents below is the document map. In the PDF edition, +each chapter starts on a new page and the contents list includes +**section titles with page numbers**. In HTML, each chapter is its own +page with the Verae wordmark in the sidebar and Verae Inc contact +information in the footer. .. toctree:: :maxdepth: 2 + :numbered: + :caption: Contents - verification + executive + what-verae-provides + datacube-server + data-in-transit + data-at-rest + timestamped-receipts + peergos-eu-evaluations + global-timestamping + iceberg-archive architecture baa-dpa checklist howto - -What we verified about Peergos (EU) ------------------------------------ - -See the full sourced table in :doc:`verification`. - -* Encrypted client-side filesystem (cryptree); keys not on the storage - server — **yes** (Peergos book + Cure53 design review). -* IPFS blocks content-addressed; Peergos verifies hashes — **yes**. -* Independent **EU** security audits, reports published — **yes, two:** - Cure53 Berlin (2019); Radically Open Security Amsterdam (2024). -* “Peergos is HIPAA/SOC 2/ISO certified” — **no.** Those audits are - pentest/code/design reviews, not management-system certificates. - -Peergos **was designed as a trust-minimized encrypted filesystem**, -**evaluated in Europe** by two specialist firms, with **public reports**. -That supports the **at-rest / backup** story. It does **not** finish -*your* audit. - -.. only:: html - - Live technical surfaces: - - * https://pfc.georgelambert.org/health - * https://pfc.georgelambert.org/v1/npe/keys - * https://docs.pfc.georgelambert.org/controls.html - * https://git.georgelambert.org/marchon/peergos-making-yourself-audit-ready-with-verae-datacubes - - Companion system docs (HTML): https://docs.pfc.georgelambert.org/ - -.. only:: latex - - Companion PDFs in the **same directory** as this file (relative PDF - links, not Markdown): - - .. raw:: latex - - \begin{itemize} - \item \href{peergos-for-compliance.pdf}{peergos-for-compliance.pdf} - \item \href{nats-service-endpoints.pdf}{nats-service-endpoints.pdf} - \item \href{secure-messaging.pdf}{secure-messaging.pdf} - \end{itemize} + bio-james-garfinkel + bio-stuart-haber + bio-george-lambert + contact diff --git a/source/peergos-eu-evaluations.rst b/source/peergos-eu-evaluations.rst new file mode 100644 index 0000000..3e51c6c --- /dev/null +++ b/source/peergos-eu-evaluations.rst @@ -0,0 +1,140 @@ +Peergos security evaluations in Europe +====================================== + +What was evaluated +------------------ + +The offline storage and replication system used with Verae +DataCubes is **Peergos**: an encrypted, peer-to-peer filesystem +whose blocks live on IPFS. Peergos was designed as a +trust-minimized store --- the server is treated as an adversary +for content and for most metadata --- and that design was +submitted to independent European security firms **twice**. + +Those engagements are **security evaluations of the Peergos +protocol and implementation**. They are pentests, source-code +audits, and (in 2019) a cryptographic and design review. They +are **not**: + +* a HIPAA certification of Peergos, Verae, or any customer; +* a SOC 2 Type I or Type II report; +* an ISO 27001 certificate of an ISMS; +* a government "certified filesystem" designation. + +Both firms are **EU-based**. Both full reports are **public**. +That combination --- independent, European, public, repeat --- +is unusual and is worth attaching to a vendor-assurance file, +**labeled correctly**. + +2019 --- Cure53, Berlin, Germany +-------------------------------- + +* **Firm:** Cure53 +* **Location:** Berlin, Germany +* **When:** May--June 2019 +* **Scope:** pentest, source-code audit, and + **crypto / design review** +* **Outcome:** no fundamental architectural or cryptographic + problems were identified. Issues that were identified were + fixed. Cure53 stated that the platform **passed this + evaluation**. + +A crypto/design review is a stronger statement than a +black-box pentest of a web form. It is an expert reading of +whether the cryptree, the chunk encryption, the identity +model, and the threat model hang together. "Passed" in +Cure53's language is not an ISO mark. It is a specialist +firm saying: we looked at the cryptography and the +architecture, we did not find a fatal flaw, and the issues we +did find were addressed. + +Primary sources (public): + +* https://peergos.org/posts/security-audit +* https://cure53.de/pentest-report_peergos.pdf +* https://github.com/Peergos/Peergos/tree/master/audits + +2024 --- Radically Open Security B.V., Amsterdam +------------------------------------------------ + +* **Firm:** Radically Open Security B.V. +* **Location:** Amsterdam, Netherlands +* **When:** September--November 2024 +* **Scope:** crystal-box pentest plus code audit of the + Peergos **web UI** +* **Funding context:** the 2024 audit post states support + from **NLnet** (Netherlands) and refers to European Union + Horizon 2020 **NGI-POINTER**, grant **871528**. +* **Outcome:** **0** findings rated extreme, high, or + elevated; **2** moderate; **6** low. Peergos states that + all were fixed. There was **no data exposure** and **no + integrity compromise**. The issues were described as + mostly UI crashes. + +A crystal-box (clear-box) engagement means the testers had +source. A web-UI scope is narrower than the 2019 +crypto/design review: it is evidence about the interface +that humans actually click, which is where many "encrypted +backend" products fail in practice. Zero high-severity +findings, no data exposure, no integrity compromise, and a +public report are the facts. They are good facts. They are +still not a customer's Type II. + +Primary sources (public): + +* https://peergos.org/posts/security-audit-2024 +* https://github.com/Peergos/Peergos/tree/master/audits + +How to present these reports to an auditor +------------------------------------------ + +Correct: + + "Our at-rest layer is Peergos. Peergos was independently + evaluated in Berlin in 2019 (crypto and design) and in + Amsterdam in 2024 (web UI, crystal box). Both reports are + public. We attach them as **component security + evaluations**. They are not our SOC 2, not our ISO 27001, + and not a HIPAA certification. Our own controls, our own + period of examination, and our own auditor are separate." + +Incorrect: + + "We are HIPAA certified because Peergos was audited in + Europe." + + "Peergos is ISO 27001." + + "The EU certified this filesystem." + +EU funding is not a certification. NGI-POINTER grant 871528 +is a research-and-innovation funding fact. It is worth +listing under "provenance." It is not a registrar's mark. + +Hosted Peergos versus self-hosted DataCubes +------------------------------------------- + +Peergos's hosted privacy notice has stated that peergos.net +uses servers in **Germany**. A **self-hosted** organizational +DataCube is a **different processing location**. The +customer's Record of Processing, BAA pack, and ISO scope +must name *that* location --- the customer's ns1, region, or +chosen host --- not peergos.net's Germany, unless the +customer actually uses peergos.net. + +The evaluations still apply to the **protocol and +implementation**. Location of processing is an +organizational fact on top. + +What "designed under funding from Cure53 / ROS" is not +------------------------------------------------------ + +The 2019 Cure53 work and the 2024 ROS work are **evaluations** +of a system that was designed by the Peergos authors. They +are not a claim that Cure53 or Radically Open Security +designed Peergos. The accurate statement is: the storage and +replication system was **independently audited twice in +Europe**, by Cure53 in Berlin (2019) and by Radically Open +Security in Amsterdam (2024), with public reports, and the +2019 work included a cryptographic and design review of the +architecture that Verae DataCubes rely on for data at rest. diff --git a/source/timestamped-receipts.rst b/source/timestamped-receipts.rst new file mode 100644 index 0000000..19f7d07 --- /dev/null +++ b/source/timestamped-receipts.rst @@ -0,0 +1,112 @@ +Global timestamped receipts +=========================== + +Why hashes are not enough by themselves +--------------------------------------- + +A cryptographic hash of a document proves that two copies are +bit-for-bit the same, or that they are not. It does **not** prove +**when** the document first existed. Anyone can hash a file +tomorrow and claim they hashed it last year. Anyone can hash a +rewritten file and present the new hash as if it were the old +one. + +Compliance programs that care about books and records, legal +holds, intellectual-property precedence, or "produce the original +prompt that the model saw" therefore need a second primitive: +**a receipt, issued at the time of first registration, bound to +the hash, that a later examiner can check without trusting the +file's custodian.** + +What a Verae receipt is +----------------------- + +A Verae **global timestamped receipt** is proof of: + +* the **hash** of a block of digital information; +* the **time** at which that hash was first registered; +* the **sequence** of that registration relative to other + registrations. + +The block of digital information may be a message, an image, a +document, a log segment, an AI prompt, an AI completion, or any +other object that can be stored in digital media. The receipt is +about the **bits**, not about the medium they happened to sit on +when they were hashed. That is the Haber--Stornetta distinction +from 1991, applied here as a product: time-stamp the data, not +the disk. + +What is registered, and what is not +----------------------------------- + +Verae's public description of sealing is that **only a +fingerprint leaves the customer's systems**. The object itself +can remain in the customer's DataCube. The central service +therefore does not need --- and in the intended design does not +get --- the plaintext in order to issue a receipt. + +That split is the difference between a notary who reads the +document and a notary who stamps a sealed envelope whose +contents they never saw. The second notary can still later +confirm that *this envelope, with this unbroken seal, was +presented at this time*. They cannot tell you what was inside. +For HIPAA, GDPR, and ordinary commercial secrecy, that is the +desired shape. + +First registration wins +----------------------- + +A hash registry that allowed a later write to overwrite the +timestamp of an earlier write would be a forgery machine. The +rule is: **the first SHA-256 (and companion hash) and its +receipt win**. A second presentation of the same hash returns +the original receipt. A different hash is a different object --- +which is exactly how a revision should be modeled. Revisions +get their own receipts. They do not steal the original's time. + +Sequence +-------- + +Time on a wall clock is a social convention and a NTP +configuration. Sequence inside a registration service is a +data-structure fact: this hash was committed after that hash, +in this chain, in this Merkle tree, in this cross-chain bundle. +Verae receipts carry **sequence** so that an examiner can see +order even when two wall-clock stamps are close enough to argue +about. + +Bundles +------- + +A receipt does not have to travel as a bare timestamp. It can +travel inside a **digital bundle** that also holds: + +* private metadata the organization needs (matter id, hold flag, + classification); +* attached files that should be produced together; +* an internal chain that cross-verifies the organizational + server against Verae's central server. + +The bundle is the unit an examiner is handed: "here is the +object (or a capability to it), here is the receipt, here is +the metadata we claim goes with it, here is the verification +path." + +What a receipt does not prove +----------------------------- + +A receipt does not prove that the person who registered the +hash was authorized to do so. That is an access-control and +identity problem. + +A receipt does not prove that the object is true, only that +**those bits existed at that time**. A false document can be +timestamped as honestly as a true one. + +A receipt does not prove that the organization retained the +object. Proof of existence is not proof of retention. Retention +is the write-once archive (Chapter 9) plus the organization's +retention schedule. + +A receipt is not a HIPAA, SOC 2, or ISO certificate. It is +evidence that a technical control ran. diff --git a/source/what-verae-provides.rst b/source/what-verae-provides.rst new file mode 100644 index 0000000..34ceebd --- /dev/null +++ b/source/what-verae-provides.rst @@ -0,0 +1,115 @@ +What Verae provides --- and what it does not +============================================ + +The boundary +------------ + +Verae sells and operates **software infrastructure** and a +**timestamping service**. Customers use that infrastructure to store +objects, to send messages, to register hashes, to verify receipts, +and to produce an audit trail of what their own systems did. + +Verae does **not** sell a HIPAA certificate. HIPAA is a United +States **statute** (and implementing regulations), not a product +seal. A covered entity or business associate becomes "HIPAA +compliant" only in the ordinary-language sense that it has performed +a risk analysis, implemented the Security Rule's required and +addressable controls as reasonable and appropriate, executed +Business Associate Agreements where required, trained its workforce, +and can respond to OCR. No software vendor can substitute for that +work. + +Verae does **not** sell a SOC 2 report covering the customer's +organization. SOC 2 is an **attestation** by a licensed CPA firm +against the AICPA Trust Services Criteria, for a named entity, over +a named period, with a named system description. The customer's +auditor must still walk the customer's controls. + +Verae does **not** sell an ISO 27001 certificate covering the +customer's organization. ISO 27001 is a **management-system** +standard. A registrar certifies that a named organization operates +an Information Security Management System (ISMS) over a named +scope. Installing a DataCube does not create an ISMS. + +The tools +--------- + +Within that boundary, the Verae DataCube Solution is built to make +the **technical** work of those programs less painful. Concretely, +it gives the organization the ability to: + +**Store.** Digital objects --- messages, images, documents, logs, +model prompts, model outputs, attachments --- can be written into an +encrypted DataCube. The cube is a customer-controlled container. +Verae is designed so that the **contents stay in the customer's +storage**. What leaves the customer's perimeter for sealing is a +**fingerprint** (a cryptographic hash), not the object. + +**Communicate.** Endpoints exchange messages with point-to-point +encryption. The body is unreadable to the router. Destination and +subject remain visible because a network that cannot see a +destination cannot route. + +**Timestamp.** The first time a hash is registered, Verae records +that registration against a time and a sequence. Later, anyone with +the receipt and the object (or the object hash) can check that the +object existed, in that exact bit pattern, no later than that time. + +**Verify.** Verification does not require trusting Verae's word, the +customer's archive administrator, or a hosting vendor. It requires +recomputing a hash, checking a receipt, and --- for stored objects +--- checking IPFS content identifiers. A regulator can be handed +proof rather than a vendor assurance letter. + +**Audit.** Admin history, inspect events, and message-handling +summaries are written so that an examiner can see *that* an action +occurred, *who* authorized it, and *which* object it touched, +without the log itself becoming a second copy of the sensitive +payload. + +What the organization must still do +----------------------------------- + +Those five verbs --- store, communicate, timestamp, verify, audit +--- are the technical portion. The rest of a certification or +attestation program is organizational: + +**Policies.** Acceptable use, encryption, key custody, access +control, retention, legal hold, incident response, vendor +management, change management, and (where HIPAA applies) a +sanctions policy and a named Privacy Officer and Security Officer. + +**Procedures.** How a new hire is provisioned, how a leaver is +deprovisioned, how a restore is tested, how a key is rotated, how a +legal hold is placed on a cube, how an inspector is authorized +under k-of-n, how a SOC evidence request is answered. + +**Internal controls.** Dual control on inspect. Separation of the +author of a change from the officers who approve it. Signed +configuration so an unsigned file is rejected. Log-before-reveal so +an inspect cannot happen in the dark. Hash-registry "first write +wins" so a later rewrite cannot pretend to be the original. + +**Independent examination.** A CPA firm (SOC 2), a registrar +(ISO 27001), OCR or a HIPAA assessor, FINRA or SEC examination +staff, or an internal audit function that is actually independent. +They will ask for evidence that the controls ran during the period, +not that a vendor has a nice architecture diagram. + +Why the distinction matters in an exam +-------------------------------------- + +Examiners are trained to notice category errors. If a firm says +"we are SOC 2 because our storage vendor was pentested in Berlin," +the next hour of the meeting is spent unwinding that claim. If a +firm says "we use a component that was independently evaluated in +the EU; here is the public report, labeled as a component +evaluation; here is *our* system description, *our* key-custody +procedure, *our* restore test from last quarter, and *our* Type II +report," the meeting can proceed. + +This chapter exists so that nobody using this briefing makes the +first speech. Verae provides tools, background, and software +infrastructure. The organization provides the program. The auditor +provides the opinion. Those three roles do not collapse into one +product SKU.