George Lambert
4fcbb9ac95
Some checks are pending
ci / markdown (push) Waiting to run
Open with an executive summary that HIPAA, SOC 2, and ISO 27001 are organizational programs. Verae DataCubes supply store, communicate, timestamp, verify, and audit tools for the technical portion only. Chapters cover transit (HPKE, visible routing), rest (IPFS/Peergos hash-verified restore), receipts, EU Peergos evaluations (Cure53 2019, ROS 2024), cross-blockchain timestamping, and write-once Iceberg archive. PDF is branded with the Verae logo top-left and Verae Inc contact in the footer; last chapters are sourced bios for Garfinkel (FINRA CRD 5052743), Haber, and Lambert.
270 lines
No EOL
14 KiB
HTML
270 lines
No EOL
14 KiB
HTML
<!DOCTYPE html>
|
||
|
||
<html lang="en" data-content_root="./">
|
||
<head>
|
||
<meta charset="utf-8" />
|
||
<meta name="viewport" content="width=device-width, initial-scale=1.0" /><meta name="viewport" content="width=device-width, initial-scale=1" />
|
||
|
||
<title>5. Encryption at rest — IPFS blocks and Peergos — Making yourself audit-ready with Verae DataCubes</title>
|
||
<link rel="stylesheet" type="text/css" href="_static/pygments.css?v=5ecbeea2" />
|
||
<link rel="stylesheet" type="text/css" href="_static/basic.css?v=b08954a9" />
|
||
<link rel="stylesheet" type="text/css" href="_static/alabaster.css?v=2a97f0c7" />
|
||
<link rel="stylesheet" type="text/css" href="_static/verae.css?v=050b9d5b" />
|
||
<script src="_static/documentation_options.js?v=250a654d"></script>
|
||
<script src="_static/doctools.js?v=fd6eb6e6"></script>
|
||
<script src="_static/sphinx_highlight.js?v=6ffebe34"></script>
|
||
<link rel="icon" href="_static/VeraeFullLogo.png"/>
|
||
<link rel="index" title="Index" href="genindex.html" />
|
||
<link rel="search" title="Search" href="search.html" />
|
||
<link rel="next" title="6. Global timestamped receipts" href="timestamped-receipts.html" />
|
||
<link rel="prev" title="4. Secure communications — data in transit" href="data-in-transit.html" />
|
||
|
||
<link rel="stylesheet" href="_static/custom.css" type="text/css" />
|
||
|
||
|
||
|
||
|
||
|
||
</head><body>
|
||
<div class="document">
|
||
|
||
<div class="sphinxsidebar" role="navigation" aria-label="Main">
|
||
<div class="sphinxsidebarwrapper">
|
||
<p class="logo"><a href="index.html">
|
||
<img class="logo" src="_static/VeraeFullLogo.png" alt="Logo of Making yourself audit-ready with Verae DataCubes"/>
|
||
</a></p>
|
||
<p class="logo">
|
||
<a href="index.html">
|
||
<img class="logo" src="_static/VeraeFullLogo.png" alt="Logo" />
|
||
|
||
</a>
|
||
</p>
|
||
|
||
|
||
|
||
<p class="blurb">Tools for storage, communications, timestamping, verification, and audit — not a certificate.</p>
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
<search id="searchbox" style="display: none" role="search">
|
||
<div class="searchformwrapper">
|
||
<form class="search" action="search.html" method="get">
|
||
<input type="text" name="q" aria-labelledby="searchlabel" autocomplete="off" autocorrect="off" autocapitalize="off" spellcheck="false" placeholder="Search"/>
|
||
<input type="submit" value="Go" />
|
||
</form>
|
||
</div>
|
||
</search>
|
||
<script>document.getElementById('searchbox').style.display = "block"</script><h3>Navigation</h3>
|
||
<p class="caption" role="heading"><span class="caption-text">Contents</span></p>
|
||
<ul class="current">
|
||
<li class="toctree-l1"><a class="reference internal" href="executive.html">1. Executive summary</a></li>
|
||
<li class="toctree-l1"><a class="reference internal" href="what-verae-provides.html">2. What Verae provides — and what it does not</a></li>
|
||
<li class="toctree-l1"><a class="reference internal" href="datacube-server.html">3. The Verae DataCube Server Solution</a></li>
|
||
<li class="toctree-l1"><a class="reference internal" href="data-in-transit.html">4. Secure communications — data in transit</a></li>
|
||
<li class="toctree-l1 current"><a class="current reference internal" href="#">5. Encryption at rest — IPFS blocks and Peergos</a><ul>
|
||
<li class="toctree-l2"><a class="reference internal" href="#the-problem">5.1. The problem</a></li>
|
||
<li class="toctree-l2"><a class="reference internal" href="#content-addressed-blocks">5.2. Content-addressed blocks</a></li>
|
||
<li class="toctree-l2"><a class="reference internal" href="#peergos-on-top-of-ipfs">5.3. Peergos on top of IPFS</a></li>
|
||
<li class="toctree-l2"><a class="reference internal" href="#tamper-evident-restore">5.4. Tamper-evident restore</a></li>
|
||
<li class="toctree-l2"><a class="reference internal" href="#append-only-at-the-cube-layer">5.5. Append-only at the cube layer</a></li>
|
||
<li class="toctree-l2"><a class="reference internal" href="#what-a-disk-operator-sees">5.6. What a disk operator sees</a></li>
|
||
<li class="toctree-l2"><a class="reference internal" href="#what-this-does-and-does-not-satisfy">5.7. What this does, and does not, satisfy</a></li>
|
||
</ul>
|
||
</li>
|
||
<li class="toctree-l1"><a class="reference internal" href="timestamped-receipts.html">6. Global timestamped receipts</a></li>
|
||
<li class="toctree-l1"><a class="reference internal" href="peergos-eu-evaluations.html">7. Peergos security evaluations in Europe</a></li>
|
||
<li class="toctree-l1"><a class="reference internal" href="global-timestamping.html">8. Verae global timestamping — a cross-blockchain receipt</a></li>
|
||
<li class="toctree-l1"><a class="reference internal" href="iceberg-archive.html">9. Write-once Iceberg archive</a></li>
|
||
<li class="toctree-l1"><a class="reference internal" href="architecture.html">10. Architecture for an audit interview</a></li>
|
||
<li class="toctree-l1"><a class="reference internal" href="baa-dpa.html">11. BAAs, DPAs, and ciphertext without host keys</a></li>
|
||
<li class="toctree-l1"><a class="reference internal" href="checklist.html">12. Audit-ready checklist</a></li>
|
||
<li class="toctree-l1"><a class="reference internal" href="howto.html">13. How to use this briefing</a></li>
|
||
<li class="toctree-l1"><a class="reference internal" href="bio-james-garfinkel.html">14. James H. Garfinkel</a></li>
|
||
<li class="toctree-l1"><a class="reference internal" href="bio-stuart-haber.html">15. Stuart Haber</a></li>
|
||
<li class="toctree-l1"><a class="reference internal" href="bio-george-lambert.html">16. George Lambert</a></li>
|
||
<li class="toctree-l1"><a class="reference internal" href="contact.html">17. Verae Inc — contact</a></li>
|
||
</ul>
|
||
|
||
<div class="relations">
|
||
<h3>Related Topics</h3>
|
||
<ul>
|
||
<li><a href="index.html">Documentation overview</a><ul>
|
||
<li>Previous: <a href="data-in-transit.html" title="previous chapter"><span class="section-number">4. </span>Secure communications — data in transit</a></li>
|
||
<li>Next: <a href="timestamped-receipts.html" title="next chapter"><span class="section-number">6. </span>Global timestamped receipts</a></li>
|
||
</ul></li>
|
||
</ul>
|
||
</div>
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
</div>
|
||
</div>
|
||
<div class="documentwrapper">
|
||
<div class="bodywrapper">
|
||
|
||
|
||
<div class="body" role="main">
|
||
|
||
<section id="encryption-at-rest-ipfs-blocks-and-peergos">
|
||
<h1><span class="section-number">5. </span>Encryption at rest — IPFS blocks and Peergos<a class="headerlink" href="#encryption-at-rest-ipfs-blocks-and-peergos" title="Link to this heading">¶</a></h1>
|
||
<section id="the-problem">
|
||
<h2><span class="section-number">5.1. </span>The problem<a class="headerlink" href="#the-problem" title="Link to this heading">¶</a></h2>
|
||
<p>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.</p>
|
||
<p>The Verae DataCube Server Solution stores <strong>data at rest</strong> as
|
||
<strong>encrypted, content-addressed IPFS blocks</strong>, with <strong>Peergos</strong>
|
||
verifying hashes on the way in and the way out.</p>
|
||
</section>
|
||
<section id="content-addressed-blocks">
|
||
<h2><span class="section-number">5.2. </span>Content-addressed blocks<a class="headerlink" href="#content-addressed-blocks" title="Link to this heading">¶</a></h2>
|
||
<p>IPFS names a block by a cryptographic hash of its contents (a
|
||
Content Identifier, or CID). Two properties follow immediately:</p>
|
||
<ul class="simple">
|
||
<li><p>If the bits change, the name changes. There is no such thing as
|
||
“the same CID, different payload” under a collision-resistant
|
||
hash.</p></li>
|
||
<li><p>A client that asked for CID X and received bytes whose hash is
|
||
not X <strong>knows</strong> it was given the wrong object.</p></li>
|
||
</ul>
|
||
<p>That is the definition of a <strong>tamper-evident</strong> 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).</p>
|
||
</section>
|
||
<section id="peergos-on-top-of-ipfs">
|
||
<h2><span class="section-number">5.3. </span>Peergos on top of IPFS<a class="headerlink" href="#peergos-on-top-of-ipfs" title="Link to this heading">¶</a></h2>
|
||
<p>Peergos is not “IPFS with a folder UI.” It is an encrypted
|
||
filesystem — a <strong>cryptree</strong> — whose nodes and file chunks are
|
||
stored as IPFS blocks. The properties that matter for an
|
||
audit-ready DataCube are:</p>
|
||
<ul class="simple">
|
||
<li><p><strong>Client-side encryption.</strong> 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.</p></li>
|
||
<li><p><strong>Hash verification.</strong> Peergos <strong>verifies the hash</strong> 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.</p></li>
|
||
<li><p><strong>Signed writes.</strong> Updates are signed. An unsigned rewrite is
|
||
not a valid Peergos write.</p></li>
|
||
<li><p><strong>Independent chunk keys.</strong> 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.</p></li>
|
||
<li><p><strong>CHAMP</strong> places encrypted cryptree nodes under random 32-byte
|
||
labels, so the storage host cannot walk the directory tree by
|
||
name.</p></li>
|
||
<li><p><strong>Sharing</strong> 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.</p></li>
|
||
</ul>
|
||
</section>
|
||
<section id="tamper-evident-restore">
|
||
<h2><span class="section-number">5.4. </span>Tamper-evident restore<a class="headerlink" href="#tamper-evident-restore" title="Link to this heading">¶</a></h2>
|
||
<p>“Backup” in this architecture does not mean a second plaintext
|
||
copy in a different building. It means:</p>
|
||
<ol class="arabic simple">
|
||
<li><p>the CIDs that constitute a cube are known;</p></li>
|
||
<li><p>the encrypted blocks for those CIDs exist on more than one
|
||
replica;</p></li>
|
||
<li><p>a restore <strong>re-fetches</strong> the blocks and <strong>re-verifies</strong> the
|
||
hashes;</p></li>
|
||
<li><p>the customer, holding keys, decrypts locally.</p></li>
|
||
</ol>
|
||
<p>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.</p>
|
||
</section>
|
||
<section id="append-only-at-the-cube-layer">
|
||
<h2><span class="section-number">5.5. </span>Append-only at the cube layer<a class="headerlink" href="#append-only-at-the-cube-layer" title="Link to this heading">¶</a></h2>
|
||
<p>Peergos itself uses signed updates and immutable blocks. The
|
||
Verae DataCube adds an <strong>application-level chain</strong>: 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.</p>
|
||
<p>These two layers must not be conflated in an audit interview:</p>
|
||
<ul class="simple">
|
||
<li><p><strong>IPFS / Peergos</strong> 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.</p></li>
|
||
<li><p><strong>The cube chain</strong> proves that the organization’s own history
|
||
of writes is append-only at the application layer.</p></li>
|
||
</ul>
|
||
<p>Both are needed. Neither is a SOC 2 report.</p>
|
||
</section>
|
||
<section id="what-a-disk-operator-sees">
|
||
<h2><span class="section-number">5.6. </span>What a disk operator sees<a class="headerlink" href="#what-a-disk-operator-sees" title="Link to this heading">¶</a></h2>
|
||
<p>If keys never leave the client or the customer’s HSM, a disk
|
||
operator, a VM snapshot operator, and an offsite replica operator
|
||
see <strong>opaque hashed ciphertext</strong>. They do not see PHI, they do
|
||
not see document titles, they do not see the graph of who shared
|
||
what with whom.</p>
|
||
<p>That fact <strong>changes the Business Associate / processor
|
||
conversation</strong>. It does not automatically end it. Usernames, IP
|
||
addresses, billing identity, and support logs can still be
|
||
personal data. Chapter 11 takes that up.</p>
|
||
</section>
|
||
<section id="what-this-does-and-does-not-satisfy">
|
||
<h2><span class="section-number">5.7. </span>What this does, and does not, satisfy<a class="headerlink" href="#what-this-does-and-does-not-satisfy" title="Link to this heading">¶</a></h2>
|
||
<p>For HIPAA encryption of ePHI <strong>at rest</strong>, for SOC 2 CC6
|
||
encryption of stored data, and for ISO 27001 Annex A cryptography
|
||
and storage, this is the <strong>technical control</strong>: ciphertext on
|
||
disk, keys with the customer, hash-checked restore.</p>
|
||
<p>It does <strong>not</strong> by itself satisfy:</p>
|
||
<ul class="simple">
|
||
<li><p>a <strong>key-custody policy</strong> (who can unwrap, where the HSM lives,
|
||
how a lost key is declared);</p></li>
|
||
<li><p>a <strong>restore-test procedure</strong> with a dated ticket proving
|
||
someone actually did it last quarter;</p></li>
|
||
<li><p><strong>retention and legal-hold</strong> rules (those require the
|
||
write-once archive in Chapter 9, plus lawyers);</p></li>
|
||
<li><p><strong>physical</strong> security of the machines, which still belongs in
|
||
the organization’s ISMS or HIPAA facility controls.</p></li>
|
||
</ul>
|
||
</section>
|
||
</section>
|
||
|
||
|
||
</div>
|
||
|
||
</div>
|
||
</div>
|
||
<div class="clearer"></div>
|
||
</div>
|
||
<div class="verae-page-footer">
|
||
<strong>Verae Inc</strong>
|
||
· <a href="https://www.verae.com">https://www.verae.com</a>
|
||
· Book a call at <a href="https://www.verae.com">verae.com</a>
|
||
· <a href="https://app.verae.com">app.verae.com</a>
|
||
</div>
|
||
|
||
<div class="footer">
|
||
©2026, Verae Inc.
|
||
|
||
</div>
|
||
|
||
|
||
|
||
|
||
|
||
</body>
|
||
</html> |