Separate TPM and SW providers?

[nicowilliams]

I see code like this:

255     crypto_op fop;
256     switch(op) {
257     case operation_encrypt:
258         fop = opdata->use_sw ? sw_encrypt : tpm_encrypt;
259         break;
260     case operation_decrypt:
261         fop = opdata->use_sw ? sw_encrypt : tpm_decrypt;
262         break;
263     default:
264         return CKR_GENERAL_ERROR;
265     }
266
267     rv = fop(&opdata->cryptopdata, part, part_len,
268             encrypted_part, encrypted_part_len);

where tpm_*() functions are ones implementing crypto operations backended with a TPM and sw_*() functions implementing crypto operations with a softtoken.

The thought occurs that there could be two completely separate PKCS#11 providers, one that implements a TPM-backended token only, and another that implements a softtoken that uses another PKCS#11 provider (the TPM one) for its internal sealing/unsealing operations.

Not that it's necessary to perform such a separation, but that it's neat. Feel free to close this.

[williamcroberts]

Im not really sure what you mean here. The internals use SW where:

1. We have to synthesize a mechanism that the TPM doesn't support, or has broken support for. If the key supports raw RSA (CKM_X509 IIRC offhand), we can hash/pad in the SW and then call out to raw rsa decrypt (encryption with private key is rsa decrypt in the TPM).
2. Public key operations that don't need to hit the TPM.

If you want a pure software token, SoftHSM is that. So you could just load their pkcs11 library and get a softtoken.

[nicowilliams]

@williamcroberts That brings up something else. Is there a mode of operation (for keys of types supported by the TPM) where the keys in the SW are kept wrapped, and all operations run in the TPM?

I agree that there are pure software tokens. What I really want is a token that stores keys wrapped in a key stored in the TPM, with all crypto operations run in the TPM.

[williamcroberts]

@williamcroberts That brings up something else. Is there a mode of operation (for keys of types supported by the TPM) where the keys in the SW are kept wrapped, and all operations run in the TPM?

All keys don't matter. Only Secret and Private keys need to run in the TPM. The TPM, for non-persistent keys, actually produces a blob that can be stored and loaded into the TPM. That Blob is protected for both confidentiality and integrity by the TPM. So that's how it works currently. These blobs are stored in the sqlite3 db, and loaded into the TPM on demand as they are needed for operations involving the key.

I agree that there are pure software tokens. What I really want is a token that stores keys wrapped in a key stored in the TPM, with all crypto operations run in the TPM.

Well that's very close to what this does. Wrapping keys with a single TPM key means that loading the key itself to the TPM exposes the key material. We keep the keys in the TPM so we never expose that key material. For the auth values for the keys, the userpin unlocks an object with a wrapping key sealed in the TPM (With DA turned on). Thus the userpin is tied directly to the DA or Dictionary Attack protections of the TPM. The pkcs11 library also communicates with the TPM with both encrypted sessions and passwords being HMAC'd, so the password is never exposed outside of the host OS memory. No bus snooping attacks will work to get the auth value to the object.

If an attacker gets the key material, they can run away with it and forge you. If the key material is never compromised and only the auth value is lost to an attacker, they have to have a persistent way to come back to your TPM and use it to forge you. Which increases the risk of detection and complexity of the attack. Additionally, we wish to tether strong policies to the objects in the future.

This is discussed in:

• https://github.com/tpm2-software/tpm2-pkcs11/blob/master/docs/ARCHITECTURE.md

[nicowilliams]

Thanks!