George Lambert
8496ef8338
Some checks are pending
ci / markdown (push) Waiting to run
The cover stays page 1. Numbered chapters now start at What Verae provides. The TOC lists Executive summary at page 2.
242 lines
No EOL
13 KiB
HTML
242 lines
No EOL
13 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>3. Secure communications — data in transit — 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=2d7b7068" />
|
||
<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="4. Encryption at rest — IPFS blocks and Peergos" href="data-at-rest.html" />
|
||
<link rel="prev" title="2. The Verae DataCube Server Solution" href="datacube-server.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="what-verae-provides.html">1. What Verae provides — and what it does not</a></li>
|
||
<li class="toctree-l1"><a class="reference internal" href="datacube-server.html">2. The Verae DataCube Server Solution</a></li>
|
||
<li class="toctree-l1 current"><a class="current reference internal" href="#">3. Secure communications — data in transit</a><ul>
|
||
<li class="toctree-l2"><a class="reference internal" href="#the-problem">3.1. The problem</a></li>
|
||
<li class="toctree-l2"><a class="reference internal" href="#point-to-point-encryption">3.2. Point-to-point encryption</a></li>
|
||
<li class="toctree-l2"><a class="reference internal" href="#visible-routing">3.3. Visible routing</a></li>
|
||
<li class="toctree-l2"><a class="reference internal" href="#error-handling-without-leaking-content">3.4. Error handling without leaking content</a></li>
|
||
<li class="toctree-l2"><a class="reference internal" href="#the-public-key-directory">3.5. The public-key directory</a></li>
|
||
<li class="toctree-l2"><a class="reference internal" href="#what-this-does-and-does-not-satisfy">3.6. What this does, and does not, satisfy</a></li>
|
||
</ul>
|
||
</li>
|
||
<li class="toctree-l1"><a class="reference internal" href="data-at-rest.html">4. Encryption at rest — IPFS blocks and Peergos</a></li>
|
||
<li class="toctree-l1"><a class="reference internal" href="timestamped-receipts.html">5. Global timestamped receipts</a></li>
|
||
<li class="toctree-l1"><a class="reference internal" href="peergos-eu-evaluations.html">6. Peergos security evaluations in Europe</a></li>
|
||
<li class="toctree-l1"><a class="reference internal" href="global-timestamping.html">7. Verae global timestamping — a cross-blockchain receipt</a></li>
|
||
<li class="toctree-l1"><a class="reference internal" href="iceberg-archive.html">8. Write-once Iceberg archive</a></li>
|
||
<li class="toctree-l1"><a class="reference internal" href="architecture.html">9. Architecture for an audit interview</a></li>
|
||
<li class="toctree-l1"><a class="reference internal" href="baa-dpa.html">10. BAAs, DPAs, and ciphertext without host keys</a></li>
|
||
<li class="toctree-l1"><a class="reference internal" href="checklist.html">11. Audit-ready checklist</a></li>
|
||
<li class="toctree-l1"><a class="reference internal" href="howto.html">12. How to use this briefing</a></li>
|
||
<li class="toctree-l1"><a class="reference internal" href="bio-james-garfinkel.html">13. James H. Garfinkel</a></li>
|
||
<li class="toctree-l1"><a class="reference internal" href="bio-stuart-haber.html">14. Stuart Haber</a></li>
|
||
<li class="toctree-l1"><a class="reference internal" href="bio-george-lambert.html">15. George Lambert</a></li>
|
||
<li class="toctree-l1"><a class="reference internal" href="contact.html">16. 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="datacube-server.html" title="previous chapter"><span class="section-number">2. </span>The Verae DataCube Server Solution</a></li>
|
||
<li>Next: <a href="data-at-rest.html" title="next chapter"><span class="section-number">4. </span>Encryption at rest — IPFS blocks and Peergos</a></li>
|
||
</ul></li>
|
||
</ul>
|
||
</div>
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
</div>
|
||
</div>
|
||
<div class="documentwrapper">
|
||
<div class="bodywrapper">
|
||
|
||
|
||
<div class="body" role="main">
|
||
|
||
<section id="secure-communications-data-in-transit">
|
||
<h1><span class="section-number">3. </span>Secure communications — data in transit<a class="headerlink" href="#secure-communications-data-in-transit" title="Link to this heading">¶</a></h1>
|
||
<section id="the-problem">
|
||
<h2><span class="section-number">3.1. </span>The problem<a class="headerlink" href="#the-problem" title="Link to this heading">¶</a></h2>
|
||
<p>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 “<strong>what</strong> will
|
||
they see, and <strong>what</strong> will they be able to do with it.”</p>
|
||
<p>The Verae DataCube Server Solution answers that question with
|
||
<strong>point-to-point encryption of content</strong> and an explicit admission
|
||
that <strong>routing must be visible</strong>.</p>
|
||
</section>
|
||
<section id="point-to-point-encryption">
|
||
<h2><span class="section-number">3.2. </span>Point-to-point encryption<a class="headerlink" href="#point-to-point-encryption" title="Link to this heading">¶</a></h2>
|
||
<p>“Best in class” here is not a slogan; it names a concrete choice.
|
||
Production content is sealed with <strong>HPKE</strong> (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 <strong>public</strong> 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
|
||
<strong>private</strong> key can open it.</p>
|
||
<p>Consequences that matter in an audit interview:</p>
|
||
<ul class="simple">
|
||
<li><p>The <strong>sender cannot reopen</strong> 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.</p></li>
|
||
<li><p>The <strong>broker cannot open</strong> the body. Possession of the wire
|
||
image is possession of ciphertext.</p></li>
|
||
<li><p>A <strong>lab XOR</strong> construction, if it exists in a codebase for
|
||
experiments, is not a production algorithm. Production
|
||
configurations reject it.</p></li>
|
||
</ul>
|
||
</section>
|
||
<section id="visible-routing">
|
||
<h2><span class="section-number">3.3. </span>Visible routing<a class="headerlink" href="#visible-routing" title="Link to this heading">¶</a></h2>
|
||
<p>A network that cannot see a destination cannot deliver a message.
|
||
The DataCube Server Solution therefore does <strong>not</strong> claim
|
||
anonymous, metadata-free messaging. The following remain visible
|
||
to the transport, by design:</p>
|
||
<ul class="simple">
|
||
<li><p>destination (the handle or address the router needs);</p></li>
|
||
<li><p>subject or stream name (so the right service receives the
|
||
envelope);</p></li>
|
||
<li><p>sender handle or lookup identifier, when the protocol carries
|
||
them for reply and error handling;</p></li>
|
||
<li><p>approximate size and timing (any network sees these).</p></li>
|
||
</ul>
|
||
<p>This is the <strong>honest-but-curious broker</strong> model. Curiosity is
|
||
assumed. Honesty is assumed only in the narrow sense that the
|
||
broker forwards what it is given; it is <strong>not</strong> trusted with
|
||
content, and it is <strong>not</strong> trusted not to log destinations.</p>
|
||
</section>
|
||
<section id="error-handling-without-leaking-content">
|
||
<h2><span class="section-number">3.4. </span>Error handling without leaking content<a class="headerlink" href="#error-handling-without-leaking-content" title="Link to this heading">¶</a></h2>
|
||
<p>Failures have to be reported. A bounce that includes the original
|
||
body would undo the encryption. The design therefore returns
|
||
<strong>error metadata</strong>: 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.</p>
|
||
<p>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.</p>
|
||
</section>
|
||
<section id="the-public-key-directory">
|
||
<h2><span class="section-number">3.5. </span>The public-key directory<a class="headerlink" href="#the-public-key-directory" title="Link to this heading">¶</a></h2>
|
||
<p>Point-to-point encryption is only as good as the lookup of public
|
||
keys. The server solution publishes a <strong>directory of public keys</strong>
|
||
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 <code class="docutils literal notranslate"><span class="pre">0600</span></code>, held on the endpoint or in an HSM, and are
|
||
never returned by the public listing API.</p>
|
||
<p>An examiner can be shown the public listing. An examiner should
|
||
never be given a private key.</p>
|
||
</section>
|
||
<section id="what-this-does-and-does-not-satisfy">
|
||
<h2><span class="section-number">3.6. </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 Security Rule addressable encryption of ePHI <strong>in
|
||
transit</strong>, for SOC 2 CC6 cryptographic transmission, and for
|
||
ISO 27001 Annex A transmission security, this design is the
|
||
<strong>technical control</strong>: content is encrypted to the recipient, the
|
||
path is untrusted, keys are endpoint-held.</p>
|
||
<p>It does <strong>not</strong> by itself satisfy:</p>
|
||
<ul class="simple">
|
||
<li><p>a rule that requires the organization to <strong>inventory</strong> every
|
||
channel (personal devices, shadow SaaS, unapproved AI tools);</p></li>
|
||
<li><p>a rule that requires <strong>workforce sanctions</strong> when someone
|
||
bypasses the channel;</p></li>
|
||
<li><p>a rule that requires <strong>agreements</strong> with the broker operator
|
||
covering metadata that may still be personal data.</p></li>
|
||
</ul>
|
||
<p>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.</p>
|
||
</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> |