NearSync Help

Documents

Engineering & Security ArchitCryptography, Audit Infrastructure & Legal Compliance Modern cryptography-first digital execution stack built for legal scrutiny.

"Every Documents signature is mathematically verifiable by any cryptographer worldwide using open standards—no proprietary trust seals, no vendor-specific portals, and no subscription required."

1. Executive Summary

Documents’s security architecture is built on a zero-knowledge, client-side cryptography model that is fundamentally distinct from the server-side signing approaches used by legacy digital signature platforms. Rather than generating signatures on a vendor-controlled server—which requires users to trust the platform's integrity—Documents utilizes the browser’s native Web Crypto API to perform all cryptographic operations client-side. This includes hardware-backed key generation where supported by the device. Signing keys never leave the signer’s environment in a recoverable form, effectively eliminating the private key compromise attack surface inherent in server-side architectures.

The audit infrastructure underpinning every signing event utilizes append-only, cryptographically chained PostgreSQL tables, making retroactive modification of the audit record computationally infeasible. Documents are rendered through a canvas-based PDF generation model that prevents content scraping and unauthorized extraction during the signing ceremony. Forensic metadata is embedded directly into the PDF structure using the XMP standard, ensuring chain-of-custody integrity across transmission, storage, and physical handling.

The entire execution stack adheres to OWASP Top 10 security best practices. The resulting signatures are ECDSA/SHA-256 constructions, verifiable using open standards by any cryptographer, court-appointed expert, or forensic tool worldwide—without requiring access to the Documents platform, a vendor subscription, or a proprietary verification portal.

2. Architecture Overview: Three Security Pillars

  • 01 | Client-Side Cryptography Web Crypto API with ECDSA/SHA-256. Hardware-backed key generation and zero-knowledge architecture. Private keys remain within the client environment.
  • 02 | Immutable Audit Infrastructure Append-only PostgreSQL tables with cryptographic chaining. Each record references the hash of its predecessor, rendering retroactive modification computationally infeasible.
  • 03 | Secure Document Rendering Canvas-based PDF generation prevents content scraping. Forensic metadata is embedded in the PDF structure with OWASP-compliant data controls throughout.

3. Client-Side Cryptography: Web Crypto API and ECDSA/SHA-256

3.1 Why Client-Side Cryptography Matters

The fundamental vulnerability of server-side signing is key custody. When a platform stores signing keys on its own servers, it becomes a single point of failure. A breach of the platform’s infrastructure compromises every signature ever generated. Documents eliminates this risk by moving all cryptographic operations to the client side.

The Web Crypto API is a W3C standard implemented natively in major browsers, providing access to device hardware security without third-party plugins. By using this API, Documents ensures that the platform facilitates the workflow but never possesses the means to forge a signature.

3.2 ECDSA/SHA-256: The Signature Algorithm

Documents employs the Elliptic Curve Digital Signature Algorithm (ECDSA) with SHA-256, the industry standard for modern security systems (including TLS 1.3 and government CAs).

Property Detail
Algorithm ECDSA (Elliptic Curve Digital Signature Algorithm)
Curve P-256 (secp256r1) — NIST-standardized, FIPS 186-4 approved
Hash Function SHA-256 — Collision-resistant to $2^{128}$ operations
Key Length 256-bit EC key — Equivalent to 3072-bit RSA
Key Generation Browser Web Crypto API — Hardware-backed (TPM/Secure Enclave)
Standard RFC 6979 (deterministic ECDSA), ANSI X9.62
Verification Open standard — Verifiable by OpenSSL, BouncyCastle, etc.
Forward Secrecy Ephemeral key pairs prevent historical decryption from future exposure

3.3 Hardware-Backed Key Generation

On supported devices (TPM, Apple Secure Enclave, Android StrongBox), the Web Crypto API routes key generation to hardware security modules.

  • Non-Exportability: The hardware performs signing but never reveals the raw key material to the OS or browser.
  • Physical Tamper Resistance: Keys are destroyed if physical tampering is detected.

3.4 The Signing Operation

  1. Document Hash Computation: A SHA-256 hash of the document is computed client-side.
  2. Key Pair Access: The signer’s ECDSA key pair is accessed via the Web Crypto API.
  3. Signature Generation: The sign() function produces a DER-encoded ECDSA signature.
  4. Public Key Export: The public key is exported in SPKI format and embedded in the PDF.
  5. Signature Embedding: The signature and forensic metadata are embedded in the PDF and transmitted to Documents’s servers for storage.

3.5 Universal Verifiability

Unlike proprietary "trust seals," Documents signatures are universally verifiable. Any party can:

  1. Extract the signer’s public key from the PDF.
  2. Recompute the SHA-256 hash of the document.
  3. Apply the ECDSA verify() operation using standard toolkits (OpenSSL, Python, BouncyCastle).

4. Immutable Audit Logs: Cryptographically Chained PostgreSQL

4.1 Audit Infrastructure Design

Documents uses append-only PostgreSQL tables. Row-Level Security (RLS) and database role restrictions prevent UPDATE and DELETE operations. This is a structural database configuration, not an application-layer convention.

4.2 Cryptographic Chaining

Each record includes a hash of its own content plus the hash of the preceding record, creating a verifiable chain:

Record N-1:
  record_id:      AUD-20260304-0441
  event:          document_viewed
  record_hash:    SHA-256(content + prev_hash) = b7e2f1a4...

Record N (current):
  record_id:      AUD-20260304-0442
  event:          otp_verified
  prev_hash:      b7e2f1a4... (from Record N-1)
  record_hash:    SHA-256(content + b7e2f1a4...) = 9c3d8f2e...

4.3 Tamper Evidence

  • Modification Detection: Any change breaks the prev_hash link in the subsequent record.
  • Deletion Detection: Removing a record creates a missing link in the sequence.
  • Insertion Detection: Fabricating records requires a full re-computation of the chain, detectable via timestamp and computational signatures.

5. Secure Document Rendering: Canvas-Based PDF Generation

5.1 The Content Extraction Risk

Standard PDF viewers render text that can be scraped or indexed by malicious browser extensions. Documents mitigates this via Canvas-Based Rendering.

5.2 Security Properties

  • No Selectable Text: Content is drawn as a visual image, making it inaccessible to the browser’s DOM or automated scraping scripts.
  • Clipboard Access Prevention: Content cannot be highlighted or copied during the ceremony.
  • Print-to-PDF Resistance: Prevents users from bypassing security controls via the browser’s "Print" function.
  • DOM Inspection Shield: Developer tools see a single <canvas> element rather than the contract text.

6. Forensic Metadata Embedding (XMP)

Documents embeds comprehensive forensic data—IP addresses, geolocations, NTP-synchronized timestamps, and device fingerprints—directly into the PDF structure using the ISO 16684-1 (XMP) standard. This ensures the chain-of-custody remains part of the file's binary content, surviving downloads, email forwarding, and long-term archival.

7. Data Governance: Storage & Encryption

  • AES-256 at Rest: All documents are encrypted using AES-256 before reaching persistent storage.
  • Row-Level Security (RLS): PostgreSQL enforces tenant isolation at the data layer, ensuring a session for one client can never access another client's data.
  • S3 Storage Controls: Includes S3 Object Lock for immutability, VPC endpoint restrictions, and mandatory server-side encryption.

8. OWASP Top 10 Compliance

OWASP Category Documents Control Implementation
A01: Access Control RLS at database layer; role-based permissions at API levels.
A02: Crypto Failures AES-256 at rest; TLS 1.3 in transit; ECDSA/SHA-256 for signatures.
A03: Injection Parameterized queries; ORM-enforced construction; schema enforcement.
A04: Insecure Design Zero-knowledge signing; defense-in-depth architecture.
A05: Misconfiguration Infrastructure-as-code; automated configuration scanning.
A06: Vulnerable Comp. Automated dependency scanning (SCA); mandatory patching SLAs.
A07: Authentication Enforced MFA; secure session token rotation.
A08: Integrity Failures Code signing; SRI for CDN assets; cryptographic audit chaining.
A09: Logging/Monitoring Real-time anomaly detection; immutable centralized logs.
A10: SSRF Allowlist-based egress controls; network-layer outbound traffic limits.

9. Cryptographic Non-Repudiation

Non-repudiation ensures a signatory cannot credibly deny their signature. Documents moves beyond "platform declarations" to mathematical proof.

Evidence Stack:

  1. ECDSA Signature: Proves the private key holder signed the specific document.
  2. SHA-256 Hash: Detects any post-signing alterations.
  3. SMS/OTP Record: Provides evidence of possession of a registered device.
  4. Biometric/KBA: Corroborates identity through knowledge or physical traits.
  5. NTP Timestamp: Provides a trusted, server-independent execution time.
Standard Status Relevant Requirement
eIDAS (Advanced) Satisfied Unique signatory linkage and sole control of signing data.
ESIGN Act (US) Satisfied Intent to sign and record integrity.
FIPS 186-4 Compliant Use of approved ECDSA P-256 curve.
GDPR Satisfied Privacy by design; technical measures for data integrity.
SOC 2 Type II Aligned Security, availability, and confidentiality criteria.
PSD2 / SCA Satisfied Two-factor authentication (Possession/Knowledge/Inherence).

11. Why Documents Outperforms Legacy Alternatives

Dimension Documents Legacy Platforms
Architecture Client-side (Zero-Knowledge) Server-side (Key Custody Risk)
Verification Open Standards (Universal) Proprietary (Vendor-Dependent)
Key Security Hardware-backed (TPM) Software-managed (Centralized)
Audit Log Cryptographically Chained Standard Database Tables
Rendering Secure Canvas Rendering Vulnerable HTML/PDF Rendering
Proof Quality Mathematical Evidence Vendor Attestation

12. Summary

Documents’s technical security architecture represents a generational advancement over legacy server-side signing. By leveraging the Web Crypto API, Documents eliminates the structural vulnerability of private key custody. Coupled with an immutable audit infrastructure and secure rendering, the platform provides a level of forensic integrity and independent verifiability that high-stakes agreements in legal, financial, and government sectors demand.

Built for audit. Verifiable by anyone. Owned by you.

5 minUpdated 28 July 2026

Did this answer your question?

No, ask a person