On Wed, 2016-12-14 at 09:07 +0000, David Woodhouse wrote: > On Tue, 2016-12-13 at 16:49 -0800, James Bottomley wrote: > > > > So the proposal is to have a TPM specific value for > > PrivateKeyAlgorithm (which would have to be proposed as an OID) and > > use PrivateKeyInfo for the key? That could be made to work. > > Right. > > > The slight fly in the ointment that's worrying me is that I need a > > key format that works for pkcs#11 tokens as well. The problem here > > is that TPM keys don't have an id or a label and that's pretty much > > a requirement of using a pkcs#11 token, so the pkcs#11 code has to > > be able to set these attributes on the key files. I was originally > > thinking of putting them into the PEM header with a pkcs11- prefix. > > I suppose I can do the same with the attributes and some > > manufactured OID prefix with the CKA_ parameters we're interested > > in as a suffix but it's messy. > > Hm, this seems odd. If something is stored in a file then exposing it > through PKCS#11 doesn't make sense at all. Do not attempt to use > PKCS#11 for any file access.
OK, so the horse has already left the stable on that one with TPM enabling gnome-keyring for ssh keys because it exports *every* key over pkcs11. Since it does, I thought I'd play about with it a bit to see how it would work. The below is what I found out playing around. > Seriously, if you have any doubts about that at all, go read nss-pem > and ponder its operation. Then drink until you've forgotten most of > it, but remember that PKCS#11 isn't to be used for accessing stuff > that you have in a file. > > PKCS#11 can sanely be used for keys which are persistently stored > *in* the TPM storage, which *do* have a UUID which can be used as > CKA_ID. (Or maybe as CKA_LABEL since CKA_ID really SHOULD be the > pubkey hash, if we can manage that). So this is the actual problem: the TPM only stores private keys. The public key thing (can be simple, cert or something more fancy) isn't known to it. All pkcs11 searchers find the public key in the public objects and then look for the private key by id and label (this is what the standard recommends). The problem is that the label they use isn't going to be the UUID, so we need the private key to be labelled by what its public counterpart expects to use the TPM for arbitrary keys, like certificate private keys (or even gpg or ssh private keys). The UUID thing works for stuff that expects separate private and public key descriptions, like gnutls and openssl, but not for anything that uses the full pkcs11 protocol (like netscape). The second problem is that C_FindObject expects to be able to search all the keys. Unfortunately, neither the TPM nor Trousers has an enumeration protocol for TPM objects (we could hack trousers to do it, becuase it knows every key it inserted in an internal database, but there's no TSS API for it). Without enumeration, searching fails. Based on this, I think offline keys are a better format for pkcs11 because we have all the data present and can make it searchable. ssh, for instance, internally finds the private key using CKA_MODULUS and CKA_PUBLIC_EXPONENT, which we can't do if the key is inside the TPM, before exporting it by id (md5 fingerprint) and label (ssh comment). Plus there's the unsolved resource issue, of course: we can only fit about 10 keys in the TPM, whereas offline is infinitely expandable. My vision of how this would work is that we probably need a database of attributes. For certificates it's going to look something like the keyring gnome2 one, so there's no way to base any sophisticated pkcs11 implementation on something that doesn't have files at its core (regardless of where the TPM key resides). I'm agnostic over whether we have two files (one for the private and one for the public key) or a single one. I'm actually starting to think that a vanilla private key coupled with an attribute search on CKA_MODULUS,CKA_PUBLIC_EXPONENT is the best thing to do (except it won't work with TPM loaded keys). James > If you're talking about a PKCS#11 token which has its *own* storage > of wrapped keys, then sure — you can keep whatever metadata you like. > But you don't need that to be part of the PKCS#8 standard format. In > fact if you want this you're probably better off extending SoftHSM to > stored wrapped keys and use the TPM for operating them.
smime.p7s
Description: S/MIME cryptographic signature
-- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev