Add hooks for hardware-assisted protection of Vault Master Key to security-secretstore-setup

[bnevis-i]

🚀 Feature Request

Provide hooks into security-secretstore-setup for hardware-assisted protection secret store master key.

Prerequisites / Conditions

In-scope for Geneva is the design of the feature. Assuming the design is accepted, addition of the required hooks to security-secretstore-setup is a stretch goal. Hardware-based implementations using any of the below mechanisms are out-of-scope for Geneva.

Relevant Package

Affects security-secretstore-setup.

Description

The master key that protects the secret store is currently left unencrypted on a docker volume where it could be copied by an attacker and used to decrypt a copy of the encrypted secret store. CWE-313.

This key should be protected by an implementer-defined mechanism that can leverage security hardware such as a PKCS11 token, a TPM, or a TEE running on-device that can provide an device-unique secret.

Describe the solution you'd like

• This is an opt-in feature (must be explicitly enabled)
• Provide a migration option that will encrypt the secret store master key after-the-fact
• Create a salt from a cryptographically secure random number source, and persist it to disk.
• Spawn an executable that provides input key material to an RFC-5689 SHA-256 HKDF.
• Use the HKDF with supplied input key material to derive encryption keys for the master key shards.
• Use random number source to generate per-encryption initialization vectors.
• Encrypt the key shards with AES-256-GCM prior to being saved in persistent storage.

The security of the mechanism relies on keeping the input key private and the secret having sufficient entropy that it cannot be easily guessed. At implementer would also need to mitigate against unauthorized software execution to avoid interception of the secret.

Limitations

• There are no facilities for automatic rotation of any key (input key, derived key, secret store master key, or secret store data encryption key)

Describe alternatives you've considered

• Depend on security hardware directly (rejected: not cross-platform portable)
• Use of go plugins (rejected: EdgeX has not ratified a plugin architecture)
• A pluggable encrypt()/decrypt() API. (rejected: proposed for Edinburgh in 2018 and failed to obtain consensus; technical issues not fully resolved)