security(spp_key_management): AWS KMS decrypt omits explicit KeyId, allowing key substitution by a key custodian [Severity: Low]

[gonzalesedwin1123]

Follow-up discovered while fixing the Key Management Admin privilege escalation (PR #329).

Severity: Low (in-role, pre-existing)

Problem

models/key_provider_aws_kms.py calls AWS kms.decrypt(CiphertextBlob=...) without passing an explicit KeyId. When KeyId is omitted, AWS resolves the CMK from metadata embedded in the ciphertext blob itself. A holder of the Key Management Admin role (which has model write on spp.encryption.key and, after PR #329, field access to encrypted_key) can therefore replace a stored encrypted_key with a blob wrapped under a different KMS key — including an attacker-controlled cross-account CMK whose key policy grants Decrypt to the server's principal — and the provider will unwrap it without objection. This installs key material the actor already knows, bypassing the audited KeyManager key-issuance path.

Caveats that keep this Low:

• It requires the key-custodian role, which can already obtain plaintext data keys through the sanctioned, audit-logged KeyManager.get_key API.
• The model-write ACL on spp.encryption.key predates PR security(key_management): stop Key Management Admin group from granting system admin #329.
• Before the escalation fix these users were full system admins anyway.

It is a stealth/integrity concern (unaudited key substitution) rather than a new capability.

Proposed fix

Pass an explicit KeyId to kms.decrypt so AWS refuses a blob wrapped under an unexpected key, and reject encrypted_key blobs whose key ARN doesn't match the provider's configured CMK. Best done together with the provider sudo() hardening (companion issue) so encrypted_key write access can also be narrowed.

Related: #329.