Closed irtimmer closed 4 years ago
We could probably use the tpm2-pkcs11.so itself to generate a certificate using the OpenSC OSSL to PKCS11 engine. Perhaps we could also look at using the tss2-ossl-engine project as well.
tpm2_ptool cert --label=foo --id=(0|bar) ...
Probably want CSR's as well:
tpm2_ptool csr --gen ...
tpm2_ptool cert --add=<cert> ...
Cert addition should read the cert and find it's private portion and add it. If it doesn't exist and you only want a public object, then it should add all the data so that a public only object can exist.
I think if we can use tpm2-tss-engine we can just use openssl directly, but we need a way to import existing key into their model. This would avoid needing to use opensc ossl-engine-to-pkcs11 and just using openssl + engine directly. Likely making configuration much simpler.
However, it looks like the tool has no way of pulling it in directly.
We'd have to release the object auth and parent auth in the clear.. and I see know way of supporting that in the engine. Ill have to engage with them and see how to do it. The other issue is that ossl might want more friendly "passwords" and our stuff is binary. Might want to hex encode the auth value, and just use hex strings sizeof the tpm auth field.
@AndreasFuchsSIT any ideas?
Would this help ? AndreasFuchsSIT/tpm2-tss-engine@7f35306
I don't see how that helps. Given a TPM keypair we need to be able to generate:
I was hoping I could leverage OSSL engine, but I don't think OSSL engine can load up pkcs11's object model. I could be wrong though.
I think the easiest way, is to load tpm2-pkcs11 library into the ossl to pkcs11 engine provided by p11/opensc (can't recall which one) and generate the cert/csr via ossl command line and then just load that into the sqlite3 db.
But if PKCS11 project goes to FAPI, I don't know if this just gets handled by FAPI and thus doing this work now is pointless.
That's the thing. Using --import you can convert a TPM2B_PUBLIC and a TPM2B_PRIVATE into a tpm2-tss-PEM object that in turn can generate a self-signed X509 or a CSR for that key. After that, just keep using what you're already using and delete the PEM object.
wrt FAPI, I guess we'll have to look at the details, but I'd guess we'll use the tpm2-tss-engine from there as well.
@AndreasFuchsSIT can it load a parent object, and the key object and provide the proper authorizations?
KeyObject yes ParentObject no For parent it only supports "standard storage key" see https://github.com/tpm2-software/tpm2-tss-engine/blob/master/src/tpm2-tss-engine-common.h#L81 according to Section 7.5.1 in https://trustedcomputinggroup.org/wp-content/uploads/TCG-TPM-v2.0-Provisioning-Guidance-Published-v1r1.pdf or a persistent key object in the TPM.
That's what I thought.... The only reason I actually have a parent key between that persistent object and the actual key object is I was told it makes exporting a bunch of keys from the TPM easier. If that's not the case, we can actually kill that off.
It does not make interactions with the TPM easier, because you still have to dup all keys, but it may be easier wrt FAPI, because the old FAPI draft mentions a Fapi_ExportTree function. However, if you export a leaf key it will be exported without the parent. Thus, with the intermediate key exporting only 1 leaf is more complicated than without intermediate.
So which use-case is more common:
Some application which use NSS (like Firefox or Chrome) or gnupg-pkcs11-scd only use the keys in conjunction with the certificate provided by the pkcs#11 interface. Therefore support is needed to store certificates in the tpm2-pkcs11 database so they can be queried by the application.