VaultJS

The Next-Generation 4D Web Security Architecture

A radically hardened, Denuvo-inspired token architecture that fundamentally changes how web sessions are defended against hijacking, cracking, and replay attacks.

Core Concepts (4D) • Deep Dive • System Flow • Roadmap • Quick Start

The Core Concept: The "4D" Cryptographic Landscape

Web security traditionally relies on 1D or 2D security (token entropy + HTTPS). These paradigms assume the environment is safe. VaultJS assumes the environment is actively compromised. We introduce a genuinely novel design space that maps four distinct dimensions to concrete, resilient cryptographic primitives to actively defend session state.

Dimension	Metaphor	Defense Mechanism	Cryptographic Implementation
Length	Key Entropy / Spatial Hardening	Brute-force & Cracking mitigation	256-bit+ token entropy. Client-side PBKDF2 + Server-side Argon2id (Compound KDF)
Width	Context Environmental Binding	Session Hijacking & Theft mitigation	Multi-factor environmental fingerprint bridging userAgent, OS constraints, IP ranges, & native WebGL renderers.
Depth	Layered Cryptographic Obfuscation	Tamper detection & Reverse-engineering mitigation	3-Tier Nested Encryption Envelope (Inspired by DRM shielding layers like Denuvo's VM obfuscation).
Time	Temporal Validity & Decay	Replay attacks & Token permanence mitigation	Epoch-locked key derivation (HKDF with 5-min intervals) combined with silent, background background refreshes.

---

Architecture Deep Dive

Dimension 1: Length — Dual-Layer Password Protection

Traditional systems only hash passwords on the backend. VaultJS introduces asymmetric load balancing between the client and server to stop cracking dead in its tracks.

1. Client-Side Pre-Hashing (Novel implementation)

The raw password never leaves the browser. We derive 256 bits of entropy on the client using the Web Crypto API before the payload ever touches the TLS socket.

// Browser: pre-hash before transmission
async function clientPreHash(password, username) {
  // Uses Web Crypto API: PBKDF2-SHA256 with 150,000 iterations
  // Even if TLS is MITM'd, the attacker extracts a mathematically irreversible digest.
}

2. Server-Side Argon2id (The Compounding Layer)

The server intercepts the pre-hash and applies a tuned, memory-hard KDF.

final_hash = Argon2id(input=clientPreHash, salt=cryptoRandom(32), memory=96MB, time=3, threads=4)

Why it matters: Attacker GPU farms that crack standard bcrypt in hours would take months to conquer the compound complexity of PBKDF2 (150k limit) + Argon2id (96MB limit).

3. Hashcash Proof-of-Work (PoW) Gate

After $N$ login failures, VaultJS activates an invisible PoW challenge. The client device must dynamically calculate a computationally expensive `SHA256(prefix + nonce)` with 20 leading zero bits. It destroys automated bot-nets while remaining completely imperceptible to a human user utilizing browser WebWorkers.

Dimensions 2, 3 & 4: Depth Width Time — The Vault Token

Instead of relying on fragile JSON Web Tokens (JWTs), VaultJS deploys a highly obfuscated nested envelope structure, locking the data dimensionally.

The 3-Layer Token Envelope (Depth)

┌─────────────────────────────────────────────────────────────────┐
│  OUTER: HMAC-SHA256 signed envelope (Tampering Dead-End)        │
│  ┌───────────────────────────────────────────────────────────┐  │
│  │  MIDDLE: AES-256-GCM encrypted (Payload Confidentiality)  │  │
│  │  ┌─────────────────────────────────────────────────────┐  │  │
│  │  │  INNER: plaintext metadata                        │  │  │
│  │  │  + context fingerprint hash (`fp`) - [ WIDTH ]    │  │  │
│  │  │  + rotation counter & `jti`                       │  │  │
│  │  └─────────────────────────────────────────────────────┘  │  │
│  └───────────────────────────────────────────────────────────┘  │
└─────────────────────────────────────────────────────────────────┘

Context Fingerprinting (Width)

Tokens are inextricably bound to the exact hardware hardware state they were issued in.

• We aggregate navigator.userAgent, screen.colorDepth/pixelDepth, timeZone, and native WebGL renderer strings.
• The Guarantee: A hijacked token stolen via XSS, transported to a different network or differing browser version, will intrinsically fail decryption.

Epoch Key Rotation (Time)

AES keys are derived from a time-based master key, shifting strictly in 5-minute epochs.

let epoch       = Math.floor(unixtime / 300); // 5-minute shifting blocks
let epoch_key   = HKDF(masterSecret, salt=epoch, info="session-aes-key");

Tokens are cryptographically dead outside their epoch. The VaultJS Client SDK silently negotiates refreshes in the background, implementing jitter-backoffs for zero API downtime.

---

Denuvo-Inspired Zero-Trust Validation Service

Taking cues from the gaming industry's DRM architectures, validation logic is fundamentally separated from the business application layer.

The validation gateway executes a strict, atomic pipeline:

1. Verify HMAC envelope signature.
2. Derive dynamic epoch_key based strictly on atomic server time.
3. Decrypt the AES-GCM shielding.
4. Re-derive context fingerprint from the incoming network request.
5. Score & Compare the environmental delta (fp) via the internal DecisionEngine.
6. Enforce active state using Redis-backed jti sub-routines (defeating Token Replay).
7. Audit all passes and denials completely synchronously without hanging the Node event loop.

---

Full System Flow

sequenceDiagram
    autonumber

    actor User
    participant Browser as VaultJS Client SDK
    participant API as Vault API Gateway
    participant ValidationVM as Validation Engine (VM)

    rect rgb(30, 41, 59)
      Note over User,ValidationVM: Phase 1: Authentication Length Initialization
      User->>Browser: Enters credentials
      Browser->>Browser: PBKDF2(Password, Username)
      Browser->>API: POST /auth/login (Pre-Hash)
      API->>API: Verify Argon2id(Pre-Hash)
      API-->>Browser: Set-Cookie: 3-Layer Token Encrypted
    end

    rect rgb(15, 23, 42)
      Note over Browser,ValidationVM: Phase 2: Epoch Request Lifecycle
      loop Every Request
          Browser->>API: Secure API Request + HttpOnly Token
          API->>ValidationVM: Send Token + Extracted Request Context
          ValidationVM->>ValidationVM: Validate HMAC (Tamper checks)
          ValidationVM->>ValidationVM: Decrypt via HKDF Epoch Key (Time limits)
          ValidationVM->>ValidationVM: Math.abs(Fingerprint Deltas) (Context traps)
          ValidationVM->>ValidationVM: Evaluate Replay-Guards (Redis)
          ValidationVM-->>API: Status (Allow / Deny + Audit Log)
      end
    end

    rect rgb(30, 41, 59)
      Note over Browser,API: Phase 3: Silent Decay Mitigation
      loop Every 4 Minutes
          Browser->>API: Silently fetch /session/status (Background)
          API-->>Browser: Exchange for new Epoch-Keyed Token
      end
    end

Loading

---

Performance Impact Analysis

Because VaultJS relies exclusively on low-level, highly optimized C/C++ backed cryptographic primitives embedded inside Node's crypto library, the security overhead inside the request lifecycle is near non-existent.

Component	Compute Context	Added Latency	Note
Client PBKDF2	User Browser	~150ms	One-time upon login. Negligible UX impact.
Server Argon2id	Auth Server	~200ms	One-time upon login. Configurable memory cost.
Fingerprint Math	Edge Validation	< 0.5ms	Hardware-accelerated SHA-256 buffer mapping.
AES-GCM Decrypt	Edge Validation	< 0.1ms	Pure AES-NI utilization on all modern CPUs.
HMAC Digest	Edge Validation	< 0.05ms	Negligible buffering.
HKDF Derivation	Edge Validation	< 0.1ms	Negligible hashing.
		TOTAL:
System Overhead	Per API Call	< 0.8ms	The most secure protocol, with zero bottleneck.

---

Roadmap: The Path to Zero-Trust

VaultJS is rolling out in strictly modeled phases to ensure absolute systemic stability.

• Phase 1: Foundation Layer
  • Implement Argon2id + client PBKDF2 pre-hash specifications.
  • Oust existing tokens with the 3-Layer Encrypted JWT Envelope.
• Phase 2: Context Binding
  • Extract and generate the 32-character Hex Context Fingerprinting system.
  • Implement HKDF Temporal Epoch key derivations (5-minute windows).
• Phase 3: Deep Hardening
  • Wire the automated Proof-of-Work (PoW) gateways on authentication failures.
  • Deploy the isolated Validation Decision Engine scoring algorithms.
  • Embed Redis-backed iteration guards (Replay prevention).
• Phase 4: The Hardware Layer (Denuvo-Class) - V2 Upcoming
  • Hard-bind tokens via WebAuthn/FIDO2 tying sessions to physical biometrics.
  • Native Rust WebAssembly (WASM) implementations of the Validation Service.
  • TPM-attested sessions for enterprise government deployments.

---

Project Monorepo Structure

VaultJS/
├── packages/
│   ├── client-sdk/          # Browser helpers: PoW chunks, WebGL f-print, Silent Refresh
│   ├── crypto-core/         # Stateless primitives: constants, HKDF, AES envelope generation
│   ├── token-engine/        # Deep-state orchestration: Factory, Risk-drifting algorithms
│   ├── auth-server/         # Express setup, Rate-limiters, Anomaly Detection & PoW schemas
│   └── validation-service/  # Isolated decision engine and audit-logging pipelines
├── infra/                   # Redis cache adapters & DB persistence stores
├── tests/                   # Strict Integration/Unit suites & Replay-attack modeling
└── scripts/                 # Keygen & Benchmarks

---

Getting Started

Prerequisites

• Node.js v18.0+
• Local Redis instance (Optional, falls back to automated in-memory Maps)

Installation

# 1. Clone the repository
git clone https://github.com/your-org/vaultjs.git
cd vaultjs

# 2. Install monorepo dependencies
npm install

# 3. Quickly verify token integrity via Jest test-suites
npm test

# 4. Boot the VaultJS Reference Auth Server Layer
npm run start:auth

Security Note: In production scenarios, never commit your generated .env. You must supply MASTER_SECRET and HMAC_KEY via a secure Hardware Security Module (HSM), AWS KMS, or Hashicorp Vault.

---

Operator Guide: SIEM Manifest Security

This runbook focuses on three day-2 operations for the admin export pipeline:

• rotating SIEM_MANIFEST_SIGNING_KEY
• verifying replay-protection chains
• incident response when verification fails

1) Rotate SIEM_MANIFEST_SIGNING_KEY

SIEM_MANIFEST_SIGNING_KEY signs manifest payloads used by /admin/audit/export* workflows. If not set, the system falls back to SIEM_EXPORT_SIGNING_KEY.

Recommended rotation cadence: every 60–90 days, plus immediate rotation after suspected key exposure.

Rotation steps (safe + auditable):

1. Generate a new high-entropy key in your secret manager.
2. Deploy it as SIEM_MANIFEST_SIGNING_KEY to all auth-server instances.
3. Trigger a fresh export batch.
4. Verify the new batch via /admin/audit/export/jobs/:batchId/verify.
5. Record rotation metadata in your change log (timestamp, actor, environment, first rotated batchId).

Important behavior note:

• Existing manifests keep their original signature value.
• Signature verification for older batches requires the historical key used at export time.
• Keep retired keys in a protected escrow window for forensic validation of legacy batches.

2) Verify replay chains operationally

Use the admin endpoints as a continuous integrity check:

• GET /admin/audit/export/jobs to enumerate immutable batch snapshots
• GET /admin/audit/export/jobs/:batchId/manifest to retrieve the signed manifest
• GET /admin/audit/export/jobs/:batchId/verify to evaluate replay protection

Treat the following as mandatory success criteria:

• verification.ok === true (manifest hash/signature integrity)
• chainValid === true (previous manifest hash can be resolved)
• replayProtected === true (combined chain + signature verification passes)

Operational pattern:

• Run verification on every newly exported batch.
• Run periodic back-checks on recent history (for example, last 24h).
• Alert on any transition from pass to fail for previously valid batches.

3) Incident response when verification fails

When /verify indicates failure, classify first, then contain.

Failure triage:

• hashValid=false: likely manifest or storage tampering/corruption.
• signatureValid=false with hashValid=true: likely key mismatch, drift, or post-rotation legacy batch.
• chainValid=false: missing/altered predecessor manifest or data-retention gap.

Response checklist:

1. Freeze ingestion/replay for impacted batchId values.
2. Preserve evidence:

• manifest file from SIEM_MANIFEST_DIR
• export_jobs row snapshot
• service logs around export + verification windows

3. Re-verify in an isolated environment using the expected signing key for that batch epoch.
4. If tampering is confirmed:

• rotate SIEM_MANIFEST_SIGNING_KEY immediately
• generate a new clean export batch
• mark affected batches as compromised in downstream SIEM tooling

5. Document root cause and attach hashes (manifestHash, checksumSha256, chainSha256) to the incident record.

For high-severity incidents, pair this with your standard credential and token-secret rotation playbook to close parallel attack paths.

Copy/Paste Incident Ticket Template

Title: VaultJS SIEM Manifest Verification Failure

Owner: <owner>
Severity: <severity>

Batch ID: <batchId>
Manifest Hash: <manifestHash>
Chain SHA-256: <chainSha256>

Verification Snapshot:
- hashValid: <true|false>
- signatureValid: <true|false|null>
- chainValid: <true|false>
- replayProtected: <true|false>

Immediate Containment:
- [ ] Ingestion/replay paused for impacted batch(es)
- [ ] Evidence preserved (manifest file, export_jobs snapshot, logs)

Actions Taken:
- <action 1>
- <action 2>

Root Cause Summary:
<summary>

Follow-ups:
- <follow-up 1>
- <follow-up 2>

Built to harden the web against the next generation of threat actors.