[Softhsm-develop] Root of trust in SoftHSM

[(Berry) A.W. van Halderen]

Dear Anonymous,

I should wait until later in the week until I take that drink, besides
the pub isn't open still....

On Tue, Apr 06, 2021 at 09:25:05AM -0400, Full Name wrote:
> My questions are to do with how key material that has been generated within (or loade into) SoftHSM is protected when in permanent storage. My guess is that it is encrypted with a symmetric key available to SoftHSM alone, that will be fed to AES - or something similar - to decrypt (or encrypt) the key material as necessary. On this basis my questions are the following:
> 
> 1. Is the mechanism described even close to the approach taken by SoftHSM? Either way, where is the mechanism used described?
Roughly yes this is the mechanism.  Plus the permanent storage is not loaded,
but key material is kept encrypted as much as possible.

> 2. Assuming hereinafter that a root symmetric key is indeed used to protect the key material in permanent storage, where is that symmetric key coming from? 
>From the storage itself, but itself is encrypted using SO and user pin.

> 3. Is the root symmetric key generated based on the SO, or CO, credentials? 
see 2, not generated based on SO, but encrypted using SO/user pin.

> 4. Is the root symmetric key stored somewhere, obfuscated but in the clear? 
See above, plus that the symmetric key is kept in non-paged memory to avoid
it every getting stored and is being obfusticated.

This in fact makes SoftHSMv2 slower than SoftHSM version 1, because for many
actions it needs to decrypt data it already had decrypted earlier.
SoftHSM tries to be as secure possible, but still being software only.

> 5. Does SoftHSM provide the capability to retrieve this root symmetric key from some separate piece of hardware, such as a TPM or a YubiKey?

Not as the moment, but this is a possible feature.  On the other hand this
only really helps security if the actual decryption for which the AES key
is needed is done in the TPM.  This will hurt performance severely I think.

\Berry