Re: [openssl-dev] [RFC v2 0/2] Proposal for seamless handling of TPM based RSA keys in openssl
On Wed, 2016-12-14 at 18:03 -0500, James Bottomley wrote: > > I think we're talking about two different things. What I mean is that > > a given application shall never have to deal with files and PKCS#11 > > for a given single object. > > Sure (as in I thought that went without saying). If only :) > Yes ... I was mostly reacting against your statement that the keys > needed to be inside the TPM for PKCS11 use. Ok. I didn't (mean to) say that. > > And you'll note that none of those examples need extensions to the > > PKCS#8 format to store arbitrary PKCS#11 attributes such as > > CKA_LABEL, CKA_PRIVATE, CKA_APPLICATION or anything else. Because > > it's their own database and they can do what they like; they don't > > have to store it in a PKCS#8 or similar file. > > OK, so as long as you're happy with pkcs11 being used on TPM key files > which are then loaded as needed via the pkcs11 interface, I think we're > on the same page. I think so, but *ick*, don't say "files". I'm happy with PKCS#11 being used, where the PKCS#11 provider keeps its own database (completely separate from the application, like NSS softokn, SoftHSM, GNOME Keyring already do it). We don't normally use the word "files" when we talk of high-level concepts involving those three examples, even though SoftHSM actually does use individual files for storage. So let's avoid confusion by not talking about 'files' for the TPM one either. In this usage model, the application never sees a file. The application uses a PKCS#11 token. That token has its own storage which as far as the application is concerned, is magical. There is *another* usage model, where the application actually sees a file akin to the existing -BEGIN TSS KEY BLOB- files (and for which we ought to extend PKCS#8 to do it properly). That usage model should also be supported. > I'm coming to the conclusion that we need the files > in pairs and the public key can supply the attributes ... it's more or > less how gnome keyring currently does it. You want it *exactly* how GKR (or the other examples I gave) do it, with the sole exception that RSA keys can be wrapped by the TPM instead. I had also been talking about using Skylake's SGX software enclaves to do a similar augmentation to software tokens. > > The example you give with GNOME keyring doing SSH keys is a > > *different* special case. There it's automatically discovering the > > files in a known location (~/.ssh/id_*) and has to infer what it can > > from them, but still it's only exposing them over PKCS#11 in a > > standard way. There's none of the horridness for 'here, load *this* > > file into the token', is there? You can do that with ssh-add perhaps, > > but that's mostly orthogonal to what we're talking about here. > > OK, so a token can be writeable as well, but I expect the object to be > loaded into the token to be correctly serialised according to the > protocol and also possibly wrapped. > > > > 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). > > > > Which part of the standard are you referring to? It isn't really that > > prescriptive about how you look things up, as far as I was aware. > > Section 4.8 in the current OASIS base spec: > > The CKA_ID field is intended to distinguish among multiple keys. In > the case of public and private keys, this field assists in handling > multiple keys held by the same subject; the key identifier for a > public key and its corresponding private key should be the same. The > key identifier should also be the same as for the corresponding > certificate, if one exists. > > In practice it seems that most things use CKA_ID and CKA_LABEL if they > both exist. OK, right. So it isn't just NSS; *most* things will automatically try to find a private key once they've already been pointed at the cert, by matching CKA_ID and/or CKA_LABEL. Sure, you *can* explicitly point at separate cert and privkey, but you generally shouldn't need to. > > All of the above is for *wrapped* keys, of course. Not keys stored > > persistently in the TPM. > > I'm starting to think keys permanently loaded into the TPM aren't the > right way to go ... Right, which is why I stopped there at the observation that we weren't talking about that :) -- dwmw2 smime.p7s Description: S/MIME cryptographic signature -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [RFC v2 0/2] Proposal for seamless handling of TPM based RSA keys in openssl
On Wed, 2016-12-14 at 17:05 +, David Woodhouse wrote: > On Wed, 2016-12-14 at 06:58 -0800, James Bottomley wrote: > > > 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. > > I think we're talking about two different things. What I mean is that > a given application shall never have to deal with files and PKCS#11 > for a given single object. Sure (as in I thought that went without saying). > Like the nss-pem horridness, where we create an object whose > CKA_LABEL is the filename, and we want the soft token to > go and load that file. > > You seem to be talking about software-based PKCS#11 tokens which > happen to use their *own* files behind the scenes, but all the > *application* ever knows about is sane PKCS#11 operations. That is > absolutely fine. There's plenty of examples of that — including > SoftHSM, GNOME keyring, and NSS's softokn. Yes ... I was mostly reacting against your statement that the keys needed to be inside the TPM for PKCS11 use. > And you'll note that none of those examples need extensions to the > PKCS#8 format to store arbitrary PKCS#11 attributes such as > CKA_LABEL, CKA_PRIVATE, CKA_APPLICATION or anything else. Because > it's their own database and they can do what they like; they don't > have to store it in a PKCS#8 or similar file. OK, so as long as you're happy with pkcs11 being used on TPM key files which are then loaded as needed via the pkcs11 interface, I think we're on the same page. I'm coming to the conclusion that we need the files in pairs and the public key can supply the attributes ... it's more or less how gnome keyring currently does it. > The example you give with GNOME keyring doing SSH keys is a > *different* special case. There it's automatically discovering the > files in a known location (~/.ssh/id_*) and has to infer what it can > from them, but still it's only exposing them over PKCS#11 in a > standard way. There's none of the horridness for 'here, load *this* > file into the token', is there? You can do that with ssh-add perhaps, > but that's mostly orthogonal to what we're talking about here. OK, so a token can be writeable as well, but I expect the object to be loaded into the token to be correctly serialised according to the protocol and also possibly wrapped. > > 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). > > Which part of the standard are you referring to? It isn't really that > prescriptive about how you look things up, as far as I was aware. Section 4.8 in the current OASIS base spec: The CKA_ID field is intended to distinguish among multiple keys. In the case of public and private keys, this field assists in handling multiple keys held by the same subject; the key identifier for a public key and its corresponding private key should be the same. The key identifier should also be the same as for the corresponding certificate, if one exists. In practice it seems that most things use CKA_ID and CKA_LABEL if they both exist. > > 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). > > Right, you need a full software token for stuff like NSS. But didn't > you already do that in GNOME keyring? It stores the CKO_CERTIFICATE > objects just like it always did, and now it's capable of storing the > actual private key of a CKO_PRIVATE object in TSS-wrapped form, but > the other attributes are still stored in its database just as they > always were? Yes, I can do it, but the TPM private keys are going to have to inherit the certificate CKA_ID, which is usually something like the subject ... they can't be the uuid. > And we could make SofTHSM and NSS support the same things. > > None of *that* needs to touch on the PKCS#8 storage format at all. > That is *only* relevant to the case where the application is given a > *file* with the private key it's supposed to use, and there is no > PKCS#11 in
Re: [openssl-dev] [RFC v2 0/2] Proposal for seamless handling of TPM based RSA keys in openssl
On Wed, 2016-12-14 at 06:58 -0800, James Bottomley wrote: > > 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. I think we're talking about two different things. What I mean is that a given application shall never have to deal with files and PKCS#11 for a given single object. Like the nss-pem horridness, where we create an object whose CKA_LABEL is the filename, and we want the soft token to go and load that file. You seem to be talking about software-based PKCS#11 tokens which happen to use their *own* files behind the scenes, but all the *application* ever knows about is sane PKCS#11 operations. That is absolutely fine. There's plenty of examples of that — including SoftHSM, GNOME keyring, and NSS's softokn. And you'll note that none of those examples need extensions to the PKCS#8 format to store arbitrary PKCS#11 attributes such as CKA_LABEL, CKA_PRIVATE, CKA_APPLICATION or anything else. Because it's their own database and they can do what they like; they don't have to store it in a PKCS#8 or similar file. The example you give with GNOME keyring doing SSH keys is a *different* special case. There it's automatically discovering the files in a known location (~/.ssh/id_*) and has to infer what it can from them, but still it's only exposing them over PKCS#11 in a standard way. There's none of the horridness for 'here, load *this* file into the token', is there? You can do that with ssh-add perhaps, but that's mostly orthogonal to what we're talking about here. > 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). Which part of the standard are you referring to? It isn't really that prescriptive about how you look things up, as far as I was aware. > 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). Right, you need a full software token for stuff like NSS. But didn't you already do that in GNOME keyring? It stores the CKO_CERTIFICATE objects just like it always did, and now it's capable of storing the actual private key of a CKO_PRIVATE object in TSS-wrapped form, but the other attributes are still stored in its database just as they always were? And we could make SofTHSM and NSS support the same things. None of *that* needs to touch on the PKCS#8 storage format at all. That is *only* relevant to the case where the application is given a *file* with the private key it's supposed to use, and there is no PKCS#11 in sight. All of the above is for *wrapped* keys, of course. Not keys stored persistently in the TPM. -- dwmw2 smime.p7s Description: S/MIME cryptographic signature -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [RFC v2 0/2] Proposal for seamless handling of TPM based RSA keys in openssl
On Wed, 2016-12-14 at 09:07 +, 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
Re: [openssl-dev] [RFC v2 0/2] Proposal for seamless handling of TPM based RSA keys in openssl
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. 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). 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. -- dwmw2 smime.p7s Description: S/MIME cryptographic signature -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [RFC v2 0/2] Proposal for seamless handling of TPM based RSA keys in openssl
On Tue, 2016-12-13 at 22:28 +, David Woodhouse wrote: > On Tue, 2016-12-13 at 13:09 +, Dr. Stephen Henson wrote: > > The reason for that is that the PEM forms which contain > > the key algorithm in the PEM header were considered legacy types > > and new methods should use PKCS#8 instead. So there was no way to > > set legacy PEM decoders to discourage their use. > > > > In this case the reason is different: the header doesn't contain > > the algorithm type but a string which an ENGINE can handle. So it > > isn't a "legacy format" but a custom one. > > > > So if we wanted to go down this route all that is needed to get a > > form of this functionality is a function to set the PEM decoder in > > EVP_PKEY_ASN1_METHOD. > > I am not entirely averse to the idea of saying that TPM, at least as > of 2.0, should have a wrapped-key storage format which is based in > PKCS#8 rather than doing its own thing. 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. 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. James smime.p7s Description: S/MIME cryptographic signature -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [RFC v2 0/2] Proposal for seamless handling of TPM based RSA keys in openssl
On Tue, Dec 13, 2016, David Woodhouse wrote: > On Tue, 2016-12-13 at 13:09 +, Dr. Stephen Henson wrote: > > The reason for that is that the PEM forms which contain > > the key algorithm in the PEM header were considered legacy types and new > > methods > > should use PKCS#8 instead. So there was no way to set legacy PEM decoders to > > discourage their use. > > > > In this case the reason is different: the header doesn't contain the > > algorithm > > type but a string which an ENGINE can handle. So it isn't a "legacy format" > > but a custom one. > > > > So if we wanted to go down this route all that is needed to get a form of > > this > > functionality is a function to set the PEM decoder in EVP_PKEY_ASN1_METHOD. > > I am not entirely averse to the idea of saying that TPM, at least as of > 2.0, should have a wrapped-key storage format which is based in PKCS#8 > rather than doing its own thing. > If you go the PKCS#8 route then it would presumably be the unencrypted form. One way to handle things would be to assign an OID for TPM and have an ASN.1 module unwrap the thing and return an EVP_PKEY structure. That would work with any version of OpenSSL without modification if the ENGINE included a TPM ASN.1 EVP_PKEY_ASN1_METHOD. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [RFC v2 0/2] Proposal for seamless handling of TPM based RSA keys in openssl
On Tue, 2016-12-13 at 13:09 +, Dr. Stephen Henson wrote: > The reason for that is that the PEM forms which contain > the key algorithm in the PEM header were considered legacy types and new > methods > should use PKCS#8 instead. So there was no way to set legacy PEM decoders to > discourage their use. > > In this case the reason is different: the header doesn't contain the algorithm > type but a string which an ENGINE can handle. So it isn't a "legacy format" > but a custom one. > > So if we wanted to go down this route all that is needed to get a form of this > functionality is a function to set the PEM decoder in EVP_PKEY_ASN1_METHOD. I am not entirely averse to the idea of saying that TPM, at least as of 2.0, should have a wrapped-key storage format which is based in PKCS#8 rather than doing its own thing. -- dwmw2 smime.p7s Description: S/MIME cryptographic signature -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [RFC v2 0/2] Proposal for seamless handling of TPM based RSA keys in openssl
On Tue, Dec 13, 2016, Dr. Stephen Henson wrote: > > So if we wanted to go down this route all that is needed to get a form of this > functionality is a function to set the PEM decoder in EVP_PKEY_ASN1_METHOD. > Note however that this currently assumes the data between the PEM headers is base64 encoded and it passes the decoded version to the relevant handler. So if the data is of a textual form instead it cannot (currently) be handled but that could be changed. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [RFC v2 0/2] Proposal for seamless handling of TPM based RSA keys in openssl
On Wed, Nov 30, 2016, James Bottomley wrote: > One of the principle problems of using TPM based keys is that there's > no easy way of integrating them with standard file based keys. This > proposal adds a generic method for handling file based engine keys that > can be loaded as PEM files. Integration into the PEM loader requires a > BIO based engine API callback which the first patch adds. The second > patch checks to see if the key can be loaded by any of the present > engines. Note that this requires that any engine which is to be used > must be present and initialised via openssl.cnf. > > I'll also post to this list the patch to openssl_tpm_engine that makes > use if this infrastructure so the integration of the whole can be seen. > It should also be noted that gnutls has had this functionality since > 2012. > > The patch was done against 1.0.2h for easier testing and you can try it > and the openssl_tpm_engine out (if you run openSUSE) here: > I can see a couple of problems with this approach. Firstly the BIO containing the private key may not be seekable: that is BIO_reset() might not rewind it to the start. This could happen with a BIO chain, a socket or a pipe for example. The second problem is that the file might contain multiple private keys so (say) if you're reading the second private key in a file a reset will end up taking you back to the beginning. However the required functionality to support custom PEM key forms actually largely already exists in OpenSSL so significant changes are not required if we want to go down this route. To see what I mean consider an existing format such as an RSA key which has -BEGIN RSA PRIVATE KEY- at the start. When the PEM file is parsed in PEM_read_bio_PrivateKey() it sees that the header ends in "PRIVATE KEY" and then attempts to look up the key string: "RSA" in this case. It then passes the decoded contents of the PEM file to the relavent algorithm ASN.1 method by looking for one that handles the appropriate string. Although all current methods use ASN.1 for the private key data this shouldn't be necessary. So for RSA this is rsa_ameth.c and the function is old_rsa_priv_decode. This takes the encoded data and returns an EVP_PKEY structure containing the key. So in theory if you wanted to handle a key of the form: -BEGIN TPM PRIVATE KEY- -END TPM PRIVATE KEY you just create an almost empty ASN.1 method which handles the string "TPM" and which only contains the PEM decoder. An ENGINE can also contain its own custom methods so you could include an ENGINE which contains the relevant handler. This would require no changes to OpenSSL to work. There is however a snag. The relevant structure (EVP_PKEY_ASN1_METHOD) is opaque and there is currently no way to set the pem decoder for a custom string (the field is called "old_priv_decode"): only methods which are part of OpenSSL can do that. The reason for that is that the PEM forms which contain the key algorithm in the PEM header were considered legacy types and new methods should use PKCS#8 instead. So there was no way to set legacy PEM decoders to discourage their use. In this case the reason is different: the header doesn't contain the algorithm type but a string which an ENGINE can handle. So it isn't a "legacy format" but a custom one. So if we wanted to go down this route all that is needed to get a form of this functionality is a function to set the PEM decoder in EVP_PKEY_ASN1_METHOD. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [RFC v2 0/2] Proposal for seamless handling of TPM based RSA keys in openssl
On Fri, 2016-12-02 at 08:03 -0800, James Bottomley wrote: > > Most likely (and hopefully) the latter keys will be handled over > > PKCS#11 rather than directly. > > I have reservations about scaling pkcs11 into a multi-tenant > environment, but I agree, in principle it is possible. I'm looking at > trying to do it better for TPM now (well, it's the next thing to get to > on my list). There are two problems with PKCS#11 and TPM. Firstly, PKCS#11 only supports one PIN per PKCS#11 provider. If each key can have its *own* PIN, that doesn't work so well. You can play deprecated tricks and have a separate slot for each key, but that quickly gets horrid, and more so when you consider the second problem... Secondly, wrapped keys don't actually exist in the TPM so there's no 'URI' that you can refer to them by; they are ephemeral. The encrypted key is actually *in* the PEM file, and gets loaded into the TPM for it to decrypt and use. So to cope with this through PKCS#11 you'd need some kind of nasty hack where it loads the PEM file and a new token magically "hotplugs" into existence. We already have something that's *almost* this horrid, with the nss-pem abomination that NSS uses to load PEM files; you call the C_CreateObject() method using an object 'label' which is actually a file name it's vile, and it's not really a model we want to follow. I think we really do need native support for loading these PEM files, and not to attempt to make it work through PKCS#11. -- dwmw2 smime.p7s Description: S/MIME cryptographic signature -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [RFC v2 0/2] Proposal for seamless handling of TPM based RSA keys in openssl
On Thu, 2016-12-01 at 12:49 +0100, Nikos Mavrogiannopoulos wrote: > On Wed, 2016-11-30 at 13:59 -0800, James Bottomley wrote: > > > > > The point here is that because there's a pem file > > > representation of the > > > > key, it can be used anywhere a PEM file can be *without* > > > having > > > to tell > > > > openssl what the engine is (the PEM guards being unique to > > > the > > > key > > > > type). > > > > > > Well, I think I can see your point (except for the above > > > question), but frankly I don’t like this approach very much. > > > > It's already a mechanism used by gnutls to load TPM keys, so it > > makes sense from a compatibility point of view that it should just > > work for openssl as well. It doesn't preclude using a pkcs11 token > > approach as well, it's just a different mechanism for handling > > keys. > > Note that gnutls' mechanism relies on the "tpmkey:" URLs to load > them, rather than loading via any other PEM mechanism. The URL > approach has the advantage that it provides a uniformity in handling > similar to PKCS#11 URLs (and it wouldn't matter whether these keys > are in file, in the TPM itself or in some other OS storage area - you > specify them all the same). > > However, neither of URLs or file loading would survive the TPM 2.0 > thing. Actually, I believe it will. The main difference is that TPM2 has multiple SRKs so you need to know which one, plus TSS2 will be different from TSS1 so they can't be handled by the same engine: so the format will have a new guard (TSS2 KEY BLOB probably) and the multiple root can be coped with by specifying the root as a PEM parameter). Incidentally, a similar problem does exist in TPM1: although everything chains up to a single SRK, you can have multiple sub SRK storage keys to which the keys are wrapped. Right at the moment, the current openssl_tpm_engine doesn't contemplate this possibility, but I'm thinking of extending it to do so, because it's useful when doing TPM tenancy (cloud container use case). > Most likely (and hopefully) the latter keys will be handled over > PKCS#11 rather than directly. I have reservations about scaling pkcs11 into a multi-tenant environment, but I agree, in principle it is possible. I'm looking at trying to do it better for TPM now (well, it's the next thing to get to on my list). James -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [RFC v2 0/2] Proposal for seamless handling of TPM based RSA keys in openssl
On Wed, 2016-11-30 at 13:59 -0800, James Bottomley wrote: > > > The point here is that because there's a pem file > > representation of the > > > key, it can be used anywhere a PEM file can be *without* > > having > > to tell > > > openssl what the engine is (the PEM guards being unique to > > the > > key > > > type). > > > > Well, I think I can see your point (except for the above question), > > but frankly I don’t like this approach very much. > > It's already a mechanism used by gnutls to load TPM keys, so it makes > sense from a compatibility point of view that it should just work for > openssl as well. It doesn't preclude using a pkcs11 token approach > as > well, it's just a different mechanism for handling keys. Note that gnutls' mechanism relies on the "tpmkey:" URLs to load them, rather than loading via any other PEM mechanism. The URL approach has the advantage that it provides a uniformity in handling similar to PKCS#11 URLs (and it wouldn't matter whether these keys are in file, in the TPM itself or in some other OS storage area - you specify them all the same). However, neither of URLs or file loading would survive the TPM 2.0 thing. Most likely (and hopefully) the latter keys will be handled over PKCS#11 rather than directly. regards, Nikos -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [RFC v2 0/2] Proposal for seamless handling of TPM based RSA keys in openssl
On Wed, 2016-11-30 at 21:41 +, Blumenthal, Uri - 0553 - MITLL wrote: > >> So why is it better to say “…engine –key > /some/weird/path/weird > >> -file.pem” than “…engine –key pkcs11:id=02” (or such)? > > > > There appears to be some confusion here. pkcs11 is a > representation > > for defined tokens. > > Well, I did not mean *specifically* pkcs11 – just as an example of > something that currently works. > > > > However, for TPM, there's also file representation > > of an unloaded key (it has to be parented or "wrapped" to one > of the > > loaded storage keys, usually the SRK). > > So this PEM wrapping is needed just to load keys into TPM? How do you > refer to those keys when they are already loaded? The keys are TPM volatile, so they're effectively unloaded as soon as you close the TPM connection. The engine code to use them is here https://sourceforge.net/p/trousers/openssl_tpm_engine the TPM connection is from engine init to engine finish and once the key is loaded, it stays in the TPM until engine finish. create_tpm_key is what takes a standard RSA key and wraps it to the SRK as a volatile key for the TPM. > > > The point here is that because there's a pem file > representation of the > > key, it can be used anywhere a PEM file can be *without* having > to tell > > openssl what the engine is (the PEM guards being unique to the > key > > type). > > Well, I think I can see your point (except for the above question), > but frankly I don’t like this approach very much. It's already a mechanism used by gnutls to load TPM keys, so it makes sense from a compatibility point of view that it should just work for openssl as well. It doesn't preclude using a pkcs11 token approach as well, it's just a different mechanism for handling keys. I like it because it's easier than trying to set up and use TPM token, which seems to be very hard without admin privileges (the PEM file approach can be used by any user of the system provided the SRK has a well known authority). James smime.p7s Description: S/MIME cryptographic signature -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [RFC v2 0/2] Proposal for seamless handling of TPM based RSA keys in openssl
>> So why is it better to say “…engine –key /some/weird/path/weird >> -file.pem” than “…engine –key pkcs11:id=02” (or such)? > > There appears to be some confusion here. pkcs11 is a representation > for defined tokens. Well, I did not mean *specifically* pkcs11 – just as an example of something that currently works. > However, for TPM, there's also file representation > of an unloaded key (it has to be parented or "wrapped" to one of the > loaded storage keys, usually the SRK). So this PEM wrapping is needed just to load keys into TPM? How do you refer to those keys when they are already loaded? > The point here is that because there's a pem file representation of the > key, it can be used anywhere a PEM file can be *without* having to tell > openssl what the engine is (the PEM guards being unique to the key > type). Well, I think I can see your point (except for the above question), but frankly I don’t like this approach very much. smime.p7s Description: S/MIME cryptographic signature -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [RFC v2 0/2] Proposal for seamless handling of TPM based RSA keys in openssl
On Wed, 2016-11-30 at 21:18 +, Blumenthal, Uri - 0553 - MITLL wrote: > On 11/30/16, 10:24 AM, "openssl-dev on behalf of James Bottomley" < > openssl-dev-boun...@openssl.org on behalf of > james.bottom...@hansenpartnership.com> wrote: > > > One of the principle problems of using TPM based keys is that > there's > > no easy way of integrating them with standard file based keys. > > Why should token- and/or TPM-based keys be integrated with file-based > keys? OpenSSL and its engines need/should accept URI pointing at the > keys. Pointing them at files containing some proprietary reference to > keys that are kept in hardware does not seem to make sense. > > So why is it better to say “…engine –key /some/weird/path/weird > -file.pem” than “…engine –key pkcs11:id=02” (or such)? There appears to be some confusion here. pkcs11 is a representation for defined tokens. However, for TPM, there's also file representation of an unloaded key (it has to be parented or "wrapped" to one of the loaded storage keys, usually the SRK). There is no URI reference (other than a file one) because any key so described may exist only in the file and don't have to be part of the tpm token infrastructure. To make use of it, the engine first has to load the key into the TPM. It's actually a simpler way of handling keys than loading them into the TPM pkcs11 token infrastructure and naming them by slot and key The point here is that because there's a pem file representation of the key, it can be used anywhere a PEM file can be *without* having to tell openssl what the engine is (the PEM guards being unique to the key type). James smime.p7s Description: S/MIME cryptographic signature -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [RFC v2 0/2] Proposal for seamless handling of TPM based RSA keys in openssl
On 11/30/16, 10:24 AM, "openssl-dev on behalf of James Bottomley" wrote: > One of the principle problems of using TPM based keys is that there's > no easy way of integrating them with standard file based keys. Why should token- and/or TPM-based keys be integrated with file-based keys? OpenSSL and its engines need/should accept URI pointing at the keys. Pointing them at files containing some proprietary reference to keys that are kept in hardware does not seem to make sense. So why is it better to say “…engine –key /some/weird/path/weird-file.pem” than “…engine –key pkcs11:id=02” (or such)? smime.p7s Description: S/MIME cryptographic signature -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
