From 8dbacc7b42019e803f4086f192984326558fa024 Mon Sep 17 00:00:00 2001 From: Dmitriy Rabotyagov Date: Tue, 27 Apr 2021 15:33:52 +0300 Subject: [PATCH] Fix Barbican PKCS#11 description Current description is incorrect, since barbican does not store each projects KEK in HSM. As eventually, that would mean having thousand of keys, while Thales Luna Network HSM has limit of 100 keys for DPoD, so it will be unable to use big part of HSM solutions with that approach. Instead only MKEK and HMAC are stored in HSM and used to encrypt/decrypt KEKs. Change-Id: I8c4eaaa42262797632ce4c4296c04a4fe62b8fcf --- security-guide/source/secrets-management/barbican.rst | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/security-guide/source/secrets-management/barbican.rst b/security-guide/source/secrets-management/barbican.rst index bf424607..7e880091 100644 --- a/security-guide/source/secrets-management/barbican.rst +++ b/security-guide/source/secrets-management/barbican.rst @@ -61,11 +61,12 @@ PKCS#11 crypto plugin The PKCS#11 crypto plugin can be used to interface with a Hardware Security Module (HSM) using the PKCS#11 protocol. Secrets are encrypted (and decrypted on retrieval) by a project specific Key Encryption Key -(KEK) which resides in the HSM. Since a different KEK is used for each -project, and since the KEKs are stored inside an HSM (instead of in -plaintext in the configuration file) the PKCS#11 plugin is much more -secure than the simple crypto plugin. It is the most popular back end -amongst Barbican deployments. +(KEK). The KEK is protected (encrypted) with a Master KEK (MKEK). The MKEK +resides in the HSM along with a HMAC. Since the different KEK is used for +each project, and since the KEKs are stored inside a database in an encrypted +form (instead of a plaintext in the configuration file) the PKCS#11 plugin +is much more secure than the simple crypto plugin. It is the most popular +back end amongst Barbican deployments. Secret store plugins --------------------