- Fix#61: handleRotateKey and handleDeleteUser now zeroize stored
privBytes instead of calling Bytes() (which returns a copy). New
state populates privBytes; old references nil'd for GC.
- Add audit logging subsystem (internal/audit) with structured event
recording for cryptographic operations.
- Add audit log engine spec (engines/auditlog.md).
- Add ValidateName checks across all engines for path traversal (#48).
- Update AUDIT.md: all High findings resolved (0 open).
- Add REMEDIATION.md with detailed remediation tracking.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Web UI: Added browser-based management for all three remaining engines
(SSH CA, Transit, User E2E). Includes gRPC client wiring, handler files,
7 HTML templates, dashboard mount forms, and conditional navigation links.
Fixed REST API routes to match design specs (SSH CA cert singular paths,
Transit PATCH for update-key-config).
Security audit: Conducted full-system audit covering crypto core, all
engine implementations, API servers, policy engine, auth, deployment,
and documentation. Identified 42 new findings (#39-#80) across all
severity levels.
Remediation of all 8 High findings:
- #68: Replaced 14 JSON-injection-vulnerable error responses with safe
json.Encoder via writeJSONError helper
- #48: Added two-layer path traversal defense (barrier validatePath
rejects ".." segments; engine ValidateName enforces safe name pattern)
- #39: Extended RLock through entire crypto operations in barrier
Get/Put/Delete/List to eliminate TOCTOU race with Seal
- #40: Unified ReWrapKeys and seal_config UPDATE into single SQLite
transaction to prevent irrecoverable data loss on crash during MEK
rotation
- #49: Added resolveTTL to CA engine enforcing issuer MaxTTL ceiling
on handleIssue and handleSignCSR
- #61: Store raw ECDH private key bytes in userState for effective
zeroization on Seal
- #62: Fixed user engine policy resource path from mountPath to
mountName() so policy rules match correctly
- #69: Added newPolicyChecker helper and passed service-level policy
evaluation to all 25 typed REST handler engine.Request structs
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Implement a two-level key hierarchy: the MEK now wraps per-engine DEKs
stored in a new barrier_keys table, rather than encrypting all barrier
entries directly. A v2 ciphertext format (0x02) embeds the key ID so the
barrier can resolve which DEK to use on decryption. v1 ciphertext remains
supported for backward compatibility.
Key changes:
- crypto: EncryptV2/DecryptV2/ExtractKeyID for v2 ciphertext with key IDs
- barrier: key registry (CreateKey, RotateKey, ListKeys, MigrateToV2, ReWrapKeys)
- seal: RotateMEK re-wraps DEKs without re-encrypting data
- engine: Mount auto-creates per-engine DEK
- REST + gRPC: barrier/keys, barrier/rotate-mek, barrier/rotate-key, barrier/migrate
- proto: BarrierService (v1 + v2) with ListKeys, RotateMEK, RotateKey, Migrate
- db: migration v2 adds barrier_keys table
Also includes: security audit report, CSRF protection, engine design specs
(sshca, transit, user), path-bound AAD migration tool, policy engine
enhancements, and ARCHITECTURE.md updates.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
