Technology

Proof you verify yourself. No PriviNet servers or accounts required.

Lumra signs each event the moment it arrives, chains it so tampering is detectable, and exports a ProofPack that anyone can check offline with a standalone tool. Here is exactly how it works, and exactly what it does not claim.

Start free Read the verifier
The three verbs

Sign. Chain. Verify.

Sign, chain, verify pipeline Your systems gate · camera sensor · gps an event happens Signed on arrival ECDSA P-256 · HSM-held key edge devices sign at source (Ed25519) #a91f #4c22 #d08e Hash-chained (SHA-256) server-time ordered alter one byte, it breaks ProofPack manifest-signed · RFC-3161 FRE 902(13)/(14) template inside Verified by anyone standalone verifier offline no PriviNet servers involved The pipeline this page explains, one step at a time.
Sign

The moment it arrives

Every event is signed the moment it arrives. Where the edge device can sign at the source with its own key, Lumra preserves that device signature and re-verifies it independently. The production signing key lives in a hardware security module and never leaves it.

Chain

Ordered by our clock

Signed record digests are linked into a tamper-evident hash chain, ordered by the time the server received them. A backdated payload cannot quietly reorder history.

Verify

Out of our hands

Any record exports as a ProofPack and can be checked later, offline, by anyone, with a standalone verifier that contacts no PriviNet system.

The precise promise: integrity you do not have to trust us for. A ProofPack proves a record was not altered after signing and was signed by PriviNet's published key. It does not claim to prove when the underlying event occurred, and we make no promises about court admissibility.

Signing and key custody

The root of trust is the key.

Who holds which key, and who can check Edge device key Ed25519 · lives on the device signs the payload at capture PriviNet HSM key ECDSA P-256 · FIPS 140-2 L3 non-extractable Application servers can request a signature can never read or copy the key sign this Published directory privinet.net/keys.txt public · out-of-band public keys published Any verifier checks keys against the public list A ProofPack counts as PriviNet-signed only if its key matches the public directory.
Production key

Held in an HSM, non-extractable

Records and ProofPack manifests are signed with ECDSA P-256 (SHA-256), key id kms-1944107aa98ec035, held in a Google Cloud KMS hardware security module, FIPS 140-2 Level 3, non-extractable. Our servers can request a signature. They can never read or copy the private key. A full compromise of the application server yields no signing key.

Fail-closed

Honest about a downgrade

If the HSM is briefly unreachable, production does not silently downgrade. A record signed by the software fallback key is labeled software_key in the record itself, and is never passed off as HSM-signed. The verifier surfaces that distinction to the reader.

Fallback key

Retired, but honored

The prior software key, Ed25519, key id sw-77396abcd4102123, is not compromised. It still verifies every record it signed before the 2026-07-06 cutover, and remains listed as an availability fallback. Old ProofPacks keep verifying.

Published trust root

Confirm the key yourself

Every PriviNet signing key is published out-of-band at privinet.net/keys.txt, machine-readable at /keys.json. A ProofPack counts as signed by PriviNet only if its signing key matches that list, a public directory we cannot alter after the fact.

Provenance

Five signing states, proven by the record, not asserted.

Lumra never claims stronger provenance than the record can prove. Each record carries one of five signing states, and the verifier confirms which applies.

Live today: source-signed, cloud-signed, and unverified are exercised by a live path. Gateway-signed and vendor-preserved are supported by the taxonomy and the verifier, and activate with the relevant gateway or vendor integration. A record without a device signature is never dressed up as if it had one.

Integrity

How records are hashed and chained.

Canonical hashing

Normalized before hashing

Digests are computed over canonical JSON: sorted keys, fixed separators, ensure_ascii false, UTF-8. A reformatted but identical file still verifies. Any change to a meaningful value fails. We describe it that way rather than claiming every raw byte is bound, because canonical whitespace is deliberately normalized.

Composite digest

Domain-separated

Each event hash binds the payload, the analysis, and the evidence window under a domain-separation context string. Digests from one context cannot be replayed into another.

Ordering

Server time, not client time

The hash chain and incident timelines order by the server-assigned receipt time, not the client-supplied timestamp. A backdated payload cannot reorder the ledger.

Timing and retention

An independent clock. Write-once storage.

Redundant RFC-3161 anchoring

Two clocks that are not ours

Each ProofPack seeks independent RFC-3161 trusted timestamps from up to two unrelated third-party authorities, both over the same fingerprint. The primary anchor is bound into the ProofPack manifest and the second is sealed inside the bundle, so a stripped or swapped anchor is caught by the verifier rather than passing silently. Two independent institutions attesting the same fingerprint means disputing when it existed requires claiming both were wrong. Each anchor verifies on its own; an un-anchored pack says so, and re-exporting the pack re-anchors it.

WORM archive

Write once. Read many.

Court exhibits are archived to write-once, read-many Cloud Storage with object versioning and a multi-year retention policy. Once written, an exhibit cannot be silently overwritten or deleted within the retention window.

The bundle

What is inside a ProofPack.

A ProofPack is the portable, self-contained evidence bundle. It includes:

  • A printable HTML court exhibit and a machine-readable JSON record.
  • The signature over the event, plus any preserved device (source) signature.
  • A whole-document manifest signature that binds the display bundle, the signing metadata, the input digests, and the anchor status together, so the human-readable page cannot say one thing while the sealed data says another.
  • The independent RFC-3161 timestamp anchor status.
  • An Evidence Trust Assessment: enumerated, versioned checks recorded as facts, not a score. Because it rides inside the bundle, the manifest signature binds it too.
  • A pre-filled FRE 902(13)/(14) self-authentication certification template.

The analysis inside a ProofPack is framed as decision-support and documentation, not a determination of fact, liability, or medical diagnosis.

Evidence Trust Assessment

Enumerated trust signals, not a verdict.

Every ProofPack carries an Evidence Trust Assessment: a fixed, versioned set of deterministic checks that either fired or did not. It is not a score, not a machine opinion, and not a judgment about what happened. It is a record of which signals were present, so a reader can weigh the evidence rather than take a label on faith.

Read it plainly: when nothing is flagged, the assessment says so by name, listing the checks that ran and did not fire, so silence is explicit rather than assumed. Each check names the ruleset version that produced it. The assessment rides inside each ProofPack's sealed bundle, so the manifest signature binds it and the standalone verifier's manifest check rejects any later edit to it. It is context for a human decision, never a determination of fact or liability.

The standalone verifier

Do not take our word for it. Run it.

The verifier is a single Python file, verify_proofpack.py, that contacts no PriviNet system. It needs Python 3.9+ and one common crypto library, cryptography or pynacl. The digest checks run on the standard library alone. It checks:

  1. the printable bundle matches the sealed canonical inputs, which catches a doctored display;
  2. recomputes component digests over canonical payload, analysis, and evidence window;
  3. recomputes the domain-separated composite event digest;
  4. verifies the record signature, auto-detecting P-256 or Ed25519;
  5. confirms the signing key is on PriviNet's published list, and flags a software-key record as not HSM-custodied;
  6. verifies the manifest binding, re-verifies any device signature against the sealed payload, and confirms the timestamp anchor was not stripped or swapped.
$ python verify_proofpack.py proofpack.json
# recompute every digest, check every signature, no network
Step 1-2  component + composite digests recomputed
Step 3    record signature valid over event_hash
Step 4    key recognized: kms-1944107aa98ec035 (HSM)
Step 5    manifest binds the sealed content
Step 6    independent RFC-3161 timestamp present
✓ RESULT: INTEGRITY VERIFIED, AND SIGNED BY PRIVINET

Try it yourself, no account: download the verifier and a sample ProofPack, confirm the key in the key directory, then pip install cryptography and run it. Change any sealed value and watch it fail.

What "verified" means, plainly: it proves the record was not altered after signing and was signed by PriviNet's published key. It does not prove when the underlying event occurred.

Primitives and standards

Established cryptography, applied end to end.

ECDSA P-256 (SHA-256)Production record and manifest signatures, HSM-held key.
FIPS 140-2 Level 3 HSMCustody of the non-extractable production signing key (Google Cloud KMS).
Ed25519Source-device signatures and the retired-but-honored software fallback key.
SHA-256 over canonical JSONComponent digests and the domain-separated composite event hash.
RFC-3161Independent third-party timestamp anchoring, bound into the manifest.
WORM object storageWrite-once evidence archive with multi-year retention.
FRE 902(13)/(14)Pre-filled self-authentication certification template in each ProofPack.

Established primitives, applied end to end. The value is where they are applied, from the source to independent verification, not in inventing new cryptography.

Honest status

Built today, and what is on the roadmap.

✓ HSM-held production signing (fail-closed) ✓ Five signing states ✓ Canonical-JSON composite hashing ✓ Server-time-ordered chaining ✓ Redundant RFC-3161 anchoring with failover ✓ WORM evidence archive ✓ ProofPack + FRE 902 template ✓ Standalone verifier ✓ Per-tenant keys + audited signing broker ✓ Evidence Trust Assessment sealed in every pack ✓ Sealed multi-source incident assemblies ✓ In-browser drag-and-drop verifier ✓ Source-key registry (Source-signed webhooks) ✓ MyGeotab integration (Geotab exception events) ✓ Patent pending (U.S. provisional filed July 2026) → roadmap: third-party audit letter

Built and live today: HSM-held production signing (fail-closed), the five signing states, canonical-JSON composite hashing, server-time-ordered chaining, RFC-3161 anchoring with failover, WORM archival, the ProofPack with manifest binding and the FRE 902 template, and the standalone verifier. Validated end to end by an external test agent, and reviewed by an authorized red team that concluded records cannot be forged or tampered with without detection.

Also live: per-tenant signing keys with a policy-gated, audited signing broker. A provisioned client's records and manifests sign under that client's own HSM-held key, fail-closed: a revoked or unreachable tenant key stops signing rather than silently borrowing another key, every signing decision lands in an audit trail, and the blast radius of a single tenant's key compromise is capped to that tenant. Each tenant key's identity travels inside the ProofPack as an attestation signed by PriviNet's published attestation root (see keys.txt), so the standalone verifier accepts it offline while pinning a single root, and a forged key still fails loudly. Unprovisioned tenants sign under the shared production HSM key, labeled as exactly that.

Also live: redundant, independent timestamp anchoring. Every exported ProofPack seeks timestamps from two unrelated authorities out of a pool of four; a paid, SLA-backed authority can be placed first in that pool with a configuration change whenever a customer requires a signed service agreement.

Also live: the Evidence Trust Assessment (enumerated, versioned checks sealed into every pack as facts, not a score), sealed multi-source incident assemblies (substituting, omitting, or reordering source packs breaks incident-level verification), the in-browser drag-and-drop verifier on the verify page, the source-key registry (enroll a device or platform key once and signed webhooks come back Source-signed), and a MyGeotab integration that seals Geotab exception events as they arrive. The architecture described on this page is patent pending (U.S. provisional filed July 2026).

On the roadmap, not pretended done: a third-party forensic-audit letter and a converted paying pilot, both of which require outside parties rather than code.

See a real ProofPack, then verify it yourself.

Create a free account, generate a signed record, download the ProofPack, and run the standalone verifier against it. No call required.