Skip to main content
Technical Documentation

Verification Methodology

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

3-Layer Verification System

CertNode uses a defense-in-depth approach with three independent verification layers. Each layer uses different cryptographic primitives and trust anchors, ensuring that even if one system is compromised, the others remain valid.

L1

CertNode Signature

HMAC-SHA256 signature generated instantly upon receipt creation.

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 Signature

When a receipt is created, CertNode immediately generates a cryptographic signature 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
  • Can be verified by anyone with the receipt data and public verification endpoint
// Signature generation (simplified)
signature = 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 legally recognized timestamps in many jurisdictions

TSA Providers

CertNode integrates with multiple TSA providers for redundancy:

  • FreeTSA (freetsa.org)
  • DigiCert Timestamp Authority
  • Sectigo Timestamp Authority

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 layer can be independently verified:

L1 Verification

Recalculate SHA-256 hash of receipt data and compare against stored hash.

L2 Verification

Use OpenTimestamps client to verify OTS proof against Bitcoin blockchain.

L3 Verification

Validate RFC 3161 token signature against 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