Skip to main content
Version: v0.2 (Next)

Hardware-Bound Vault & Cryptography

ActonOS implements a zero-trust credential storage system where sensitive secrets, API keys, bot tokens, and OAuth refresh tokens are encrypted at rest using AES-256-GCM with keys derived cryptographically from physical hardware identifiers and master password salts.

1. Hardware Fingerprinting & Key Derivation​

On Bare-Metal hosts, the Vault derives its root encryption key from:

  1. DMI System UUID: Unique hardware identifier from the motherboard BIOS.
  2. System Machine ID: Pinned CPU and motherboard identifier.
  3. Argon2id KDF: Memory-hard key derivation function (64 MB RAM cost, 4 iterations).
Theft & Drive Cloning Resistance

If an attacker physically extracts the NVMe SSD or clones the disk image to a different machine, the derived hardware key will not match, rendering the contents of /data/config/vault.db completely unreadable.

2. Dynamic Secret Brokering for WASM Plugins​

Plugins never access raw cryptographic master keys or read /data/config/vault.db directly. Instead, secret retrieval operates through a broker pattern:

  • Manifest Declaration: Plugins must explicitly declare requested secret patterns under manifest.permissions.secrets (e.g. ["discord_bot_tokens.*"]).
  • Granular RBAC: Requests for undeclared keys are immediately rejected and logged in the security audit ledger.

3. Cryptographically Chained Audit Ledger (audit.jsonl)​

Every security-sensitive event (tool invocation, approval grant/rejection, token refresh, login attempt) is recorded in an immutable, forward-secure append-only log:

Hash(n) = SHA-256(Hash(n-1) || Timestamp(n) || EventPayload(n))

The system provides an audit verification endpoint (GET /api/system/audit/verify) that checks the entire hash chain from the genesis record to detect any tampering, modification, or record deletion.