Skip to main content
Defense in Depth

Security is not a feature.
It's the foundation.

Every layer of STL Shield is designed to protect your intellectual property. From encryption at rest to forensic watermarking, your files are guarded at every stage.

Encryption

AES-256-GCMUnique Key Per FileAuthenticated

Every .stlx file is encrypted with AES-256-GCM, the same standard used by governments and financial institutions. Each file receives a unique encryption key, so compromising one file never exposes another.

Algorithm:    AES-256-GCM (Galois/Counter Mode)
Key Length:   256 bits (unique per product)
Nonce:        96 bits (random, never reused)
Auth Tag:     128-bit GCM authentication tag
Integrity:    Tampered ciphertext → immediate rejection
Format:       .stlx (nonce || ciphertext || auth_tag)

Key Management

Master Key WrappingZeroization

Product encryption keys are wrapped with a master key and never stored in plaintext. After every cryptographic operation, key material is immediately zeroized in memory using the Rust zeroize crate, preventing cold-boot and memory-dump attacks.

Key Hierarchy:
  Master Key (env var, never persisted to disk)
  └─ Product Key (AES-256, wrapped with master key)
     └─ File Key (derived per-encryption operation)

Zeroization:
  - Rust `zeroize` crate with Drop trait
  - Key bytes overwritten immediately after use
  - No key material in JavaScript / IPC boundary

Forensic Watermarking

5 MethodsHMAC-SHA256Slicer-Resilient

Each file is embedded with multiple independent watermark layers, making removal practically impossible. Watermark patterns are generated using HMAC-SHA256 keyed to each buyer's identity, surviving slicing, remeshing, and geometric transformations.

Watermark Methods (5 redundant layers):
  1. Vertex micro-displacement (sub-visual)
  2. Face subdivision pattern encoding
  3. Normal vector perturbation
  4. Triangle ordering signature
  5. Boundary edge steganography

Pattern Generation:
  HMAC-SHA256(buyer_token || product_id || timestamp)
  → deterministic, buyer-unique placement
  → survives slicing and re-export

Infrastructure

HTTPS OnlyTLS 1.3Rate Limited

All communication is encrypted in transit with TLS 1.3 via Cloudflare. No HTTP fallback is permitted. Docker containers run as non-root with memory limits, and validation endpoints are rate-limited to prevent abuse.

Transport:
  Protocol:     HTTPS only (no HTTP fallback)
  TLS Version:  1.3 (via Cloudflare)
  Cert Pinning: Enabled in desktop app

Docker:
  User:         non-root (uid 1001)
  Memory:       capped per container
  Ports:        127.0.0.1 binding only

Rate Limiting:
  /api/shield/validate:  10 req/min per IP
  /api/auth/*:           5 req/min per IP

Access Control

Timing-SafeMulti-TenantAudit Logged

All secret comparisons use crypto.timingSafeEqual to prevent timing attacks. Every database query is scoped to the authenticated designer via parameterised queries (Drizzle ORM), ensuring strict multi-tenant isolation. All actions are recorded in an append-only audit log.

Token Validation:
  Format:      SHLD-xxxx (bcrypt cost 12)
  Comparison:  crypto.timingSafeEqual (constant-time)
  Max Uses:    3 activations per token

Multi-Tenant:
  Every query includes `designerId` filter
  Parameterised via Drizzle ORM (no raw SQL)

Audit Log:
  Append-only (no UPDATE or DELETE)
  Records: validations, activations, failures
  Retained: indefinitely

Responsible Disclosure

Report a Vulnerability

We take security reports seriously. If you discover a vulnerability in STL Shield, please contact us responsibly. We will acknowledge receipt within 24 hours and work with you to understand and resolve the issue.

Report security issues to:

[email protected]

Please include a detailed description, steps to reproduce, and any relevant proof-of-concept code. Do not publicly disclose the vulnerability until we have had reasonable time to address it.