Rewrite audit-ready briefing: software is not a certificate.
Some checks are pending
ci / markdown (push) Waiting to run
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.
This commit is contained in:
parent
da60402e88
commit
4fcbb9ac95
53 changed files with 6323 additions and 814 deletions
138
source/global-timestamping.rst
Normal file
138
source/global-timestamping.rst
Normal file
|
|
@ -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.
|
||||
Loading…
Add table
Add a link
Reference in a new issue