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:
parent
8b27aa09ee
commit
8dbacc7b42
@ -61,11 +61,12 @@ PKCS#11 crypto plugin
|
|||||||
The PKCS#11 crypto plugin can be used to interface with a Hardware
|
The PKCS#11 crypto plugin can be used to interface with a Hardware
|
||||||
Security Module (HSM) using the PKCS#11 protocol. Secrets are encrypted
|
Security Module (HSM) using the PKCS#11 protocol. Secrets are encrypted
|
||||||
(and decrypted on retrieval) by a project specific Key Encryption Key
|
(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
|
(KEK). The KEK is protected (encrypted) with a Master KEK (MKEK). The MKEK
|
||||||
project, and since the KEKs are stored inside an HSM (instead of in
|
resides in the HSM along with a HMAC. Since the different KEK is used for
|
||||||
plaintext in the configuration file) the PKCS#11 plugin is much more
|
each project, and since the KEKs are stored inside a database in an encrypted
|
||||||
secure than the simple crypto plugin. It is the most popular back end
|
form (instead of a plaintext in the configuration file) the PKCS#11 plugin
|
||||||
amongst Barbican deployments.
|
is much more secure than the simple crypto plugin. It is the most popular
|
||||||
|
back end amongst Barbican deployments.
|
||||||
|
|
||||||
Secret store plugins
|
Secret store plugins
|
||||||
--------------------
|
--------------------
|
||||||
|
Loading…
Reference in New Issue
Block a user