Skip to main content
Technical Documentation

Verification Methodology

How CertNode creates independently verifiable proof using open standards and cryptographic primitives.

3-Layer Timestamp System

CertNode uses a defense-in-depth timestamp stack: an instant internal seal plus two independent, third-party-verifiable layers (RFC 3161 and Bitcoin). Each uses different cryptographic primitives and trust anchors, so the independent layers stand on their own even if one system is compromised.

L1

CertNode Seal

HMAC-SHA256 integrity seal generated instantly on receipt creation — issuer-attested for internal ordering, not independently verifiable on its own.

Latency: <100ms
L2

Bitcoin Anchor

OpenTimestamps proof anchored to Bitcoin blockchain via Merkle tree.

Latency: 1-2 hours (blockchain confirmation)
L3

RFC 3161 TSA

Timestamp from accredited Time Stamping Authority per IETF standard.

Latency: 1-5 seconds

Layer 1: CertNode Seal

When a receipt is created, CertNode immediately generates an integrity seal using HMAC-SHA256[3]. This algorithm combines the receipt data with a secret key to produce a fixed-length 256-bit hash that:

  • Cannot be reverse-engineered to reveal the original data
  • Changes completely if even one bit of the input changes
  • Acts as a server-side integrity seal — issuer-attested for internal ordering (independent, no-trust verification comes from the RFC 3161 and Bitcoin layers below)
// Seal generation (simplified)
seal = HMAC-SHA256(receipt_data, server_key)
hash = SHA256(receipt_data)
timestamp = ISO8601(now())

The SHA-256 hash algorithm is standardized by NIST[2]and is considered cryptographically secure against collision and pre-image attacks with current computing technology.

Layer 2: Bitcoin Blockchain Anchor

CertNode uses OpenTimestamps[4]to anchor receipt hashes to the Bitcoin blockchain[6]. This provides:

  • Immutability - Once confirmed, the timestamp cannot be altered
  • Decentralization - No single entity controls the verification
  • Longevity - Bitcoin has operated continuously since 2009

How It Works

  1. Aggregation: Receipt hashes are collected into a Merkle tree
  2. Commitment: The Merkle root is embedded in a Bitcoin transaction
  3. Confirmation: The transaction is included in a Bitcoin block
  4. Proof Generation: An OTS proof file links the receipt to the block

Note: Bitcoin anchoring is asynchronous. Initial receipts are protected by L1 and L3 immediately. The Bitcoin anchor typically confirms within 1-2 hours and provides the strongest long-term guarantee.

Layer 3: RFC 3161 Timestamp Authority

RFC 3161[1]defines the Internet X.509 Public Key Infrastructure Time-Stamp Protocol, an IETF standard for trusted timestamps. CertNode obtains timestamps from accredited Time Stamping Authorities (TSAs) that:

  • Operate under strict auditing requirements (e.g., ETSI EN 319 421)
  • Use hardware security modules (HSMs) to protect signing keys
  • Provide timestamps recognized under standards like eIDAS in many jurisdictions

TSA Provider

CertNode obtains RFC 3161 timestamps from an independent Time Stamp Authority:

  • FreeTSA (freetsa.org)

Legal Acceptance

RFC 3161 timestamps are widely accepted as evidence. Under the U.S. Federal Rules of Evidence[5], digitally signed records may be self-authenticating when accompanied by certification from a qualified person.

Important: While RFC 3161 timestamps meet technical standards for legal proceedings, actual admissibility depends on jurisdiction, case context, and judicial discretion. CertNode does not provide legal advice.

Independent Verification

A key principle of CertNode's design is that verification does not require trusting CertNode. Each independent layer can be verified by anyone:

L1 Seal

The HMAC seal is issuer-attested (internal ordering); the independent proof is L2 + L3.

L2 Verification

Use OpenTimestamps client to verify the OTS proof against the Bitcoin blockchain.

L3 Verification

Validate the RFC 3161 token signature against the TSA's public certificate.

The /verify page provides a public interface for verifying any CertNode receipt without authentication.

Limitations & Considerations

CertNode's verification system has inherent limitations that users should understand:

Timestamp ≠ Content Validation

Timestamps prove WHEN data was recorded, not WHETHER the data is accurate. A timestamped receipt proves the record existed at that time, not that the underlying event occurred as described.

Input Integrity

Cryptographic verification protects data after it enters CertNode. It cannot detect manipulation that occurred before receipt creation.

Bitcoin Anchor Timing

Bitcoin anchors require blockchain confirmation (typically 1-2 hours). Receipts are protected by L1 and L3 immediately, with L2 added asynchronously.

Legal Interpretation

While CertNode follows legal standards for digital evidence, actual admissibility and evidentiary weight are determined by courts on a case-by-case basis. CertNode does not provide legal advice.

References

  1. [1]
  2. [2]
  3. [3]
  4. [4]
  5. [5]
  6. [6]

Try It Yourself

Verify a sample receipt to see the 3-layer system in action.

Verify a ReceiptAPI Documentation