Commit Graph

14 Commits

Author SHA1 Message Date
11929daa78 Merge transit engine branch, resolve conflicts in shared files 2026-03-16 19:50:47 -07:00
cbd77c58e8 Implement transit encryption engine with versioned key management
Add complete transit engine supporting symmetric encryption (AES-256-GCM,
XChaCha20-Poly1305), asymmetric signing (Ed25519, ECDSA P-256/P-384),
and HMAC (SHA-256/SHA-512) with versioned key rotation, min decryption
version enforcement, key trimming, batch operations, and rewrap.

Includes proto definitions, gRPC handlers, REST routes, and comprehensive
tests covering all 18 operations, auth enforcement, and edge cases.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
2026-03-16 19:45:56 -07:00
5ae37da300 Add SSH CA engine with host/user cert signing, profiles, and KRL
Implement the complete SSH CA engine following the CA engine pattern:
- Engine core (initialize, unseal, seal, HandleRequest) with ed25519/ecdsa key support
- Host and user certificate signing with TTL enforcement and policy checks
- Signing profiles with extensions, critical options, and principal restrictions
- Certificate CRUD (list, get, revoke, delete) with proper auth enforcement
- OpenSSH KRL generation rebuilt on revoke/delete operations
- gRPC service (SSHCAService) with all RPCs and interceptor registration
- REST routes for public endpoints (CA pubkey, KRL) and authenticated operations
- Comprehensive test suite (15 tests covering lifecycle, signing, profiles, KRL, auth)

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
2026-03-16 19:43:32 -07:00
64d921827e Add MEK rotation, per-engine DEKs, and v2 ciphertext format (audit #6, #22)
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>
2026-03-16 18:27:44 -07:00
ad167aed9b Checkpoint: grpc auth fix, issuer list/detail, v2 protos, architecture docs
Co-authored-by: Junie <junie@jetbrains.com>
2026-03-15 11:39:13 -07:00
d0b1875dbb Fix all errcheck linter issues
Co-authored-by: Junie <junie@jetbrains.com>
2026-03-15 10:36:35 -07:00
33e71eeee9 Fix gosec, errorlint, and gofmt linter errors in unseal.go and grpc.go
Co-authored-by: Junie <junie@jetbrains.com>
2026-03-15 10:30:18 -07:00
fbaf79a8a0 Fix gosec, govet, and errorlint linter errors
Co-authored-by: Junie <junie@jetbrains.com>
2026-03-15 10:16:28 -07:00
44e5e6e174 Checkpoint: auth, engine, seal, server, grpc updates
Co-authored-by: Junie <junie@jetbrains.com>
2026-03-15 10:15:47 -07:00
cc1ac2e255 Separate web UI into standalone metacrypt-web binary
The vault server holds in-memory unsealed state (KEK, engine keys) that
is lost on restart, requiring a full unseal ceremony. Previously the web
UI ran inside the vault process, so any UI change forced a restart and
re-unseal.

This change extracts the web UI into a separate metacrypt-web binary
that communicates with the vault over an authenticated gRPC connection.
The web server carries no sealed state and can be restarted freely.

- gen/metacrypt/v1/: generated Go bindings from proto/metacrypt/v1/
- internal/grpcserver/: full gRPC server implementation (System, Auth,
  Engine, PKI, Policy, ACME services) with seal/auth/admin interceptors
- internal/webserver/: web server with gRPC vault client; templates
  embedded via web/embed.go (no runtime web/ directory needed)
- cmd/metacrypt-web/: standalone binary entry point
- internal/config: added [web] section (listen_addr, vault_grpc, etc.)
- internal/server/routes.go: removed all web UI routes and handlers
- cmd/metacrypt/server.go: starts gRPC server alongside HTTP server
- Deploy: Dockerfile builds both binaries, docker-compose adds
  metacrypt-web service, new metacrypt-web.service systemd unit,
  Makefile gains proto/metacrypt-web targets

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
2026-03-15 10:15:47 -07:00
Claude
b8e348db03 Add TLS unsealing via gRPC to CLI and server
Implements the SystemService gRPC endpoint (Status, Init, Unseal, Seal)
alongside the existing REST API, secured with the same TLS certificate.

The `metacrypt unseal` CLI command now prefers gRPC when --grpc-addr is
provided, falling back to the REST API via --addr. Both transports require
TLS; a custom CA certificate can be supplied with --ca-cert.

Server changes:
- internal/server/grpc.go: SystemServiceServer implementation with
  StartGRPC/ShutdownGRPC methods; uses the TLS cert from config.
- internal/server/server.go: adds grpcSrv field and grpc import.
- cmd/metacrypt/server.go: starts gRPC goroutine when grpc_addr is set
  in config, shuts it down on signal.

Generated code (from proto/metacrypt/v1/system.proto):
- gen/metacrypt/v1/system.pb.go: protobuf message types
- gen/metacrypt/v1/system_grpc.pb.go: gRPC client/server stubs

Dependencies added to go.mod (run `go mod tidy` to populate go.sum):
- google.golang.org/grpc v1.71.1
- google.golang.org/protobuf v1.36.5
- google.golang.org/genproto/googleapis/rpc (indirect)
- golang.org/x/net (indirect)

https://claude.ai/code/session_013m1QXGoTB4jaPUN5gwir8F
2026-03-15 09:49:48 -07:00
0f1d58a9b8 Persist engine mounts across seal/unseal cycles
- Add Registry.UnsealAll() that rediscovers mounted engines from the
  barrier on unseal, using stored metadata at engine/_mounts/ with a
  fallback discovery scan for pre-existing mounts (migration path)
- Registry.Mount() now persists mount metadata to the barrier;
  Registry.Unmount() cleans it up
- Call UnsealAll() from both REST and web unseal handlers
- Change Unmount() signature to accept context.Context
- Default CA key size changed from P-384 to P-521
- Add build-time version stamp via ldflags; display in dashboard status bar
- Make metacrypt target .PHONY so make devserver always rebuilds
- Redirect /pki to /dashboard when no CA engine is mounted

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
2026-03-15 00:47:48 -07:00
8f77050a84 Implement CA/PKI engine with two-tier X.509 certificate issuance
Add the first concrete engine implementation: a CA (PKI) engine that generates
a self-signed root CA at mount time, issues scoped intermediate CAs ("issuers"),
and signs leaf certificates using configurable profiles (server, client, peer).

Engine framework updates:
- Add CallerInfo struct for auth context in engine requests
- Add config parameter to Engine.Initialize for mount-time configuration
- Export Mount.Engine field; add GetEngine/GetMount on Registry

CA engine (internal/engine/ca/):
- Two-tier PKI: root CA → issuers → leaf certificates
- 10 operations: get-root, get-chain, get-issuer, create/delete/list issuers,
  issue, get-cert, list-certs, renew
- Certificate profiles with user-overridable TTL, key usages, and key algorithm
- Private keys never stored in barrier; zeroized from memory on seal
- Supports ECDSA, RSA, and Ed25519 key types via goutils/certlib/certgen

Server routes:
- Wire up engine mount/request handlers (replace Phase 1 stubs)
- Add public PKI routes (/v1/pki/{mount}/ca, /ca/chain, /issuer/{name})
  for unauthenticated TLS trust bootstrapping

Also includes: ARCHITECTURE.md, deploy config updates, operational tooling.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
2026-03-14 21:57:52 -07:00
4ddd32b117 Implement Phase 1: core framework, operational tooling, and runbook
Core packages: crypto (Argon2id/AES-256-GCM), config (TOML/viper),
db (SQLite/migrations), barrier (encrypted storage), seal (state machine
with rate-limited unseal), auth (MCIAS integration with token cache),
policy (priority-based ACL engine), engine (interface + registry).

Server: HTTPS with TLS 1.2+, REST API, auth/admin middleware, htmx web UI
(init, unseal, login, dashboard pages).

CLI: cobra/viper subcommands (server, init, status, snapshot) with env
var override support (METACRYPT_ prefix).

Operational tooling: Dockerfile (multi-stage, non-root), docker-compose,
hardened systemd units (service + daily backup timer), install script,
backup script with retention pruning, production config examples.

Runbook covering installation, configuration, daily operations,
backup/restore, monitoring, troubleshooting, and security procedures.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
2026-03-14 20:43:11 -07:00