Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
bnevis-i opened this issue Oct 15, 2019 · 0 comments 路 Fixed by #2574
Closed

Comments

@bnevis-i
Copy link
Collaborator

bnevis-i commented Oct 15, 2019

馃殌 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)
@bnevis-i bnevis-i self-assigned this Oct 15, 2019
@bnevis-i bnevis-i added this to To do in Security enhancements for Geneva via automation Oct 15, 2019
@bnevis-i bnevis-i moved this from To do to In progress in Security enhancements for Geneva Oct 18, 2019
@jamesrgregg jamesrgregg added this to New Issues in Core WG Oct 18, 2019
@jamesrgregg jamesrgregg added this to New Issues in Security WG Oct 18, 2019
@brandonforster brandonforster added this to the EdgeX Geneva milestone Oct 25, 2019
@bnevis-i bnevis-i added hanoi Hanoi release and removed geneva labels Nov 20, 2019
@bnevis-i bnevis-i removed this from the EdgeX Geneva milestone Nov 20, 2019
@bnevis-i bnevis-i moved this from New Issues to Icebox in Security WG Nov 20, 2019
@michaelestrin michaelestrin moved this from New Issues to Icebox in Core WG Dec 16, 2019
@bnevis-i bnevis-i moved this from Icebox to Release Backlog in Security WG Apr 30, 2020
@bnevis-i bnevis-i added this to the EdgeX Hanoi milestone Apr 30, 2020
@bnevis-i bnevis-i removed the hanoi Hanoi release label Apr 30, 2020
@bnevis-i bnevis-i moved this from Release Backlog to QA/Code Review in Security WG Jun 24, 2020
@bnevis-i bnevis-i linked a pull request Jun 24, 2020 that will close this issue
15 tasks
Core WG automation moved this from Icebox to Done Oct 12, 2020
Security WG automation moved this from QA/Code Review to Done Oct 12, 2020
bnevis-i added a commit that referenced this issue Oct 12, 2020
This commit adds the ability to specify a hook that will be called
when intitializing the EdgeX secret store.  When enabled,
the resp-init.json contents will be encrypted by a set of
keys derived from a user-supplied input key that is
delivered over a process pipe.  The input key is expected to
be protected by some form of security hardware.

Fixes #1919

Signed-off-by: Bryon Nevis <bryon.nevis@intel.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request security-services
Projects
Security WG
  
Done
Development

Successfully merging a pull request may close this issue.

2 participants