The CertNode cryptographic stack
Every CertNode product — Reflex, Vault, Recover, Sentinel, AI Provenance — runs on the same three-layer signing and timestamping stack. This is the engine. Products are distribution channels for it.
Why three layers
A single signature is only as trustworthy as the signer. A signature plus a single timestamp is only as trustworthy as the timestamp authority. To make a record defensible against challenge — in court, in front of a regulator, in front of a skeptical buyer — you need independent verification paths.
CertNode chains three independent layers. If any one of them is later disputed or compromised, the other two still hold up. This is a deliberate belt-and-suspenders design, not an over-engineering accident.
Layer 1 — CertNode internal timestamp + ES256 signature
Every signed record produces a JSON Web Signature (JWS) using ES256 (ECDSA over NIST P-256, SHA-256). The signed payload includes the SHA-256 of the content, the content type, the signing time, and any product-specific metadata (model + provider for AI Provenance, dispute ID for Reflex evidence, payment intent for Vault, etc.).
Public verification keys are published at the JWKS endpoint. Anyone can verify a CertNode signature without an account or API key. Verification is always free.
Implementation: lib/crypto/jws.ts using the jose library.
Layer 2 — RFC 3161 independent timestamp
The hash of the signed payload is sent to FreeTSA, an independent public Time Stamping Authority operating under RFC 3161. FreeTSA returns a timestamp token signed by their CA-issued certificate. The token includes the hash, the time, and FreeTSA's signature — proof that this exact content existed at that exact time, witnessed by a third party that has no relationship to CertNode.
RFC 3161 is the established standard for trusted timestamping in legal, financial, and regulatory contexts. Tokens verify against FreeTSA's public certificate without CertNode being in the loop at all.
Implementation: lib/timestamps/unified.ts wraps the FreeTSA HTTP API. Tokens are stored alongside the signed record.
Layer 3 — Bitcoin anchor (optional)
For records where long-term durability matters more than instant confirmation, the signed payload hash is queued for the next OpenTimestamps batch. OpenTimestamps aggregates submissions into a Merkle tree and commits the root to a Bitcoin transaction. Confirmation typically takes 1-2 hours.
Once anchored, the record is provably immutable as long as Bitcoin's chain is. No third party (including CertNode, including OpenTimestamps) can alter the record without invalidating the anchor. This is the strongest tamper-evidence guarantee we can offer.
Implementation: lib/timestamps/bitcoin.ts integrates the OpenTimestamps client. Bitcoin anchoring is queued asynchronously and is optional per product (default enabled).
Verification
A verifier checks all three layers independently:
- Fetch CertNode's public JWKS, verify the ES256 signature on the JWS payload.
- Re-hash the original content, confirm it matches the hash inside the signed payload.
- Verify the RFC 3161 token against FreeTSA's CA certificate (independent of CertNode).
- If a Bitcoin anchor exists, verify the OpenTimestamps proof against a Bitcoin full node or block explorer.
Any single layer failing reduces trust. All three layers passing produces a record that is hard to challenge without challenging Bitcoin itself.
FRE 902 admissibility framing
Records produced by this stack are designed to satisfy Federal Rule of Evidence 902(13) and 902(14) for self-authenticating digital evidence. 902(13) covers records produced by a system that produces accurate results; 902(14) covers records that include a digital signature verified through a trusted certifying authority.
The three-layer stack is intentionally over-built for this standard so records hold up under skeptical examination — particularly relevant for chargeback evidence (Reflex, Vault) and AI provenance disputes (AI Provenance) that may end up in arbitration or litigation.