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
This commit is contained in:
Dmitriy Rabotyagov 2021-04-27 15:33:52 +03:00 committed by Dmitriy Rabotyagov
parent 8b27aa09ee
commit 8dbacc7b42
1 changed files with 6 additions and 5 deletions

View File

@ -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
--------------------