Approach (one-line): build an append-only, tamper-evident key-usage ledger tying cryptographic proofs to KMS operations so auditors can verify actions without seeing plaintext or sensitive key material.
Log contents
- Event metadata: timestamp (UTC), operation type (encrypt/decrypt/sign/unwrap), KMS key-id (opaque), request-id, actor-id (principle), operation parameters (ciphertext-hash, algorithm, nonce-hash), client nonce/commitment.
- Outcome: success/failure code, KMS policy version, attestation reference (signature counter, TPM quote id).
- Non-sensitive derivations: HMAC of plaintext-derived value or ciphertext hash (not plaintext).
Signing & Integrity
- KMS signs each log entry with an offline, rotation-backed signing key (KMS-signing-key) and includes key version, signature, and chain-of-trust to root CA.
- Log entries are also appended to a Merkle tree; periodic signed Merkle root anchored to a blockchain or WORM storage for non-repudiation.
- Per-operation TPM/SGX attestation: include enclave quote or TPM PCR quote attested by hardware attestation key.
Access Controls
- Role-based access: auditors get read-only access to log metadata + proofs; separation of duties prevents decryption keys from being accessible.
- Escrowed blinded tokens: auditors can request proof-of-use for specific time ranges; system returns signed proofs without plaintext.
- Logs stored encrypted-at-rest with key-encryption-keys; access to logs requires multi-party authorization (A/B approval) and just-in-time elevation.
Proof-of-action mechanisms
- Verifiable commitments: client sends a nonce-commitment (hash) during operation; log records commitment and operation result hash. Auditor can validate that the same commitment was used.
- Receipt model: KMS returns a signed receipt containing request-id, key-id, operation, ciphertext-hash, timestamp, and KMS attestation. Auditor verifies signature + merkle inclusion proof.
- Replay protection: include monotonic counters and TPM-backed anti-rollback to prevent retroactive fabrication.
Why this works
- No plaintext in logs; auditors validate operations via hashes, signatures, hardware attestations, and Merkle proofs.
- Defense-in-depth: cryptographic signing, hardware attestation, immutable anchoring, strict RBAC and separation of duties provide strong, auditable evidence without exposing sensitive operations.
Trade-offs & considerations
- Performance vs. granularity of logs; choose batching interval for Merkle roots.
- Key-rotation and key compromise plans: include key-revocation events and cross-checks.
- Legal/forensic workflows for controlled plaintext disclosure (escrow with multi-party approval) documented and logged.
