Technical Document

Security Whitepaper

Comprehensive technical overview of AntiMatter AV's security architecture, threat detection mechanisms, and secure development lifecycle.

Document Details

Version: 1.0
Date: February 2026
Classification: Public
Author: AntiMatter AV Security Team

1. Security Architecture Overview

AntiMatter AV employs a multi-layered security architecture across three platforms (Windows, Android, iOS) with a centralized management server.

Client Layer

  • • Real-time file system watcher
  • • SHA-256 hash-based threat scanner
  • • Smart scan with MTime caching
  • • Network traffic firewall (VPN)
  • • App lock & web guard
  • • Quarantine management

Communication Layer

  • • TLS 1.3 encrypted transport
  • • REST API with JWT authentication
  • • Delta signature updates
  • • Device telemetry (minimal)
  • • License validation
  • • CORS-protected endpoints

Server Layer

  • • Signature definition database
  • • License management & RBAC
  • • Device tracking & activity logs
  • • Admin CRM portal
  • • SBOM & compliance endpoints
  • • Nginx reverse proxy + Let's Encrypt

2. Secure-by-Default Design

Per EU Cyber Resilience Act requirements, AntiMatter AV ships with all security features enabled by default:

  • Real-time protection ON — File system watcher starts at boot
  • Auto-update ON — Definitions sync every 6 hours
  • Web guard ON — Malicious URL blocking active
  • Firewall ON — Network traffic filtering active
  • Quarantine automatic — Threats isolated immediately
  • HTTPS enforced — All API calls use TLS
  • Telemetry minimal — No personal files shared
  • Tray persistence — Application minimizes to tray, not fully closed

3. Threat Detection & Scanning Engine

3.1 Hash-Based Detection

AntiMatter AV uses SHA-256 cryptographic hashing to identify known threats by comparing file hashes against a cloud-synchronized signature database.

// Scanning Algorithm (Simplified)

1. Read file in 1KB chunks

2. Compute SHA-256 hash incrementally

3. Compare against signature database (HashSet lookup — O(1))

4. If match → classify threat by name and severity

5. If no match → mark as clean, cache MTime

3.2 Smart Scan Caching

Files that haven't changed since last scan (based on modification time) are skipped. This dramatically reduces repeated scan times.

O(1)

Hash lookup time per file

100MB

Max file size for scan (skip oversized)

6hrs

Definition update interval

3.3 Real-time File Watcher (EDR)

The Endpoint Detection & Response system monitors file system events in real-time across all drives:

  • Windows: Monitors User Profile, System32, and all mounted drives using OS-native file watchers (ReadDirectoryChangesW)
  • Android: Scans installed applications, monitors downloads folder, provides web/email guard
  • Events tracked: File creation, modification, deletion — immediate scan on create/modify
  • Response: Automatic quarantine (move to isolated directory with .infected extension)

4. Encryption & Data Protection

Data in Transit

  • TLS 1.3 via Let's Encrypt certificates
  • HTTPS-only API communication
  • Certificate pinning for production builds
  • HSTS headers enforced via Nginx

Data at Rest

  • Passwords hashed with bcrypt (12 salt rounds)
  • JWT tokens with configurable expiry
  • PostgreSQL with role-based access
  • Environment variables for secrets (.env)

5. Secure Coding Practices

SQL Injection Prevention

All database interactions use parameterized queries. Example:

// NEVER: `SELECT * FROM users WHERE id = '${id}'`

// ALWAYS: pool.query('SELECT * FROM users WHERE id = $1', [id])

Input Validation

All user inputs validated before processing:

  • • Type checking (string, number, boolean)
  • • Length limits on all text fields
  • • Email format validation
  • • UUID format validation for license keys
  • • Content-Type header enforcement

Authentication & RBAC

  • • JWT tokens for session management
  • • Role-based access: superadmin, admin, reseller, user
  • • Middleware-enforced authorization on all protected routes
  • • Client-side auth guards redirect to login

Dependency Security

  • • SBOM maintained in CycloneDX format
  • • Regular `npm audit` and `cargo audit` scans
  • • Minimal dependency philosophy
  • • Lock files committed for reproducible builds

6. Incident Response & Vulnerability Management

Response Timeline

  • 0–24 hours: Report actively exploited vulnerabilities to ENISA (CRA mandate)
  • 24–72 hours: Develop and test patch
  • 72 hours–7 days: Deploy emergency update to all devices
  • 30 days: Post-incident review and process improvement

Contact Channels

7. Product Lifecycle & End-of-Support

Version Release Date End of Support Status
1.0.0 (Current) February 2026 February 2031 Active

Security patches provided for minimum 5 years from release date. Critical vulnerabilities patched within 72 hours.