> Example 1: OpenSSL often duplicates hash sequences: To hash
sequences A,B,C1 and then A,B,C2 they first hash A,B, then duplicate/fork the hash
sequence and then complete the hash first for C1 and then for C2. This is a great
performance optimization, but when too many dup (forks) are made, the TPM runs out of
Why are we doing hashing with the TPM? If we're in an OpenSSL
provider cant we just use software provided hashing routines? I see hashing is
configurable, but I would imagine off be default is what you want. Do we use validation
tickets or anything like that or just the resulting digest? If all we use are the digests,
I would make TPM not hash and make that option a nop.
Signing by a restricted signing key requires validation tickets, so the hash must be done
by the TPM. The OpenSSL has a combined operation "EVP_DigestSign", which enables
the tpm2 provider to hash, obtain the validation ticket and then immediately sign the hash
using this ticket. This is beautiful, but it needs the TPM hashing.
> Example 2: The CMP key update needs 4 objects to operate (old
client key, new client key, server key and hash sequence), but the kernel RM
(tpm_space.context_tbl) allows only 3 objects. (If I am right.)
It does seem that way, but TPM commands only ever need 3 objects
alive at once, so that's likely why that was chosen.
Yeah, I thought this is so.
Does CMP key really need all 4 of those things in the TPM at once,
because currently today that's not actually happening as abrmd is just swapping them
in and out.
Currently, the tpm2 provider does not do any internal resource management. If someone
loads a public / private key, the provider creates a TPM object for this. This key may be
used for some later TPM operation or even not used at all, for example when a pubkey is
being validated against a privkey. Unfortunately, the provider cannot know in advance if
and how the key being loaded will be used.
(The user is free not to use the TPM provider for loading a pubkey, but if it does a TPM
object is created.)
Typical OpenSSL based implementations are not optimized to reduce the number of
concurrently loaded keys. The code often pre-loads all keys and then uses the keys in
various operations. Even though a single operation never needs more than 3 objects, the
code may prepare more than 3 objects because it is going to invoke more than one operation
Also, doesn't CMP use public objects (x509 certs) for some of it?
Yes, it does. X.509 certs also include pubkeys and CMP sometimes wants to extract a pubkey
from a certificate to match it against a privkey it has. This also consumes two objects
(one for the pubkey and one for the privkey) although no TPM operation can be invoked.
(But it might be and we don't know, as said above.)
Are public key operations implemented in software? In tpm2-pkcs11 we
implement them in software and hash in software and I have yet to have someone hit a limit
but perhaps they are all using abrmd but I thought some were using in-kernel RM.
Yes. Some public key operations are implemented. Applications can use only one RSA/ECC key
management-- if a TPM based RSA (or ECC) key management is loaded in OpenSSL, it will be
used for both sign and validate operations-- a typical OpenSSL application cannot say
"do privkey in the TPM and pubkey in the default provider"; it can choose only
one for both (or create two contexts, but nobody does that). This is OK because TPM can do
public key operations too, but it needs more resources if the app pre-loads everything as
I can see 3 possible solutions how to solve the resource problem:
1) Optimize the code for resource consumption. But then the OpenSSL applications must be
TPM aware, which is what I wanted to avoid.
2) Implement some more intelligent resource (less greedy) usage in the tpm2 provider
itself. But this feels like re-implementing the RM elsewhere.
3) Rely on the RM (abrmd?) to swap the objects as needed and create the illusion of a much
larger object space.
Can the abrmd swap resources from a single user? I thought the purpose is to swap
resources from multiple connections (users), but in this case there is just one greedy
README.md says: The current
implementations are mostly equivalent with a few differences. But if abrmd can swap
resources much better than the in-kernel RM, then I wouldn't call them "mostly