On Sun, 2017-10-29 at 17:03 -0400, Selva wrote: > Hi, > > On Sun, Oct 29, 2017 at 12:04 PM, James Bottomley <James.Bottomley@ > hansenpartnership.com> wrote: > > > > > On Sun, 2017-10-29 at 16:24 +0100, Gert Doering wrote: > > > > > > Hi, > > > > > > On Sat, Oct 28, 2017 at 01:02:27PM +0100, James Bottomley wrote: > > > > > > > > > > > > Engine keys are an openssl concept for a key file which can > > > > only be > > > > understood by an engine (usually because it's been wrapped by > > > > the > > > > engine itself). We use this for TPM engine keys, so you can > > > > either > > > > generate them within your TPM or wrap them from existing > > > > private > > > > keys. Once wrapped, the keys will only function in the TPM > > > > that > > > > generated them, so it means the VPN keys are tied to the > > > > physical > > > > platform, which is very useful. Engine keys have to be loaded > > > > via > > > > a specific callback, so use this as a fallback in openvpn if an > > > > engine is specified and if the PEM read of the private key > > > > fails. > > > > > > How does this work in an OpenVPN context, as in, what do I have > > > to do > > > to make TPM keys work on client and server? > > > > If you have an existing private key, you convert it to a TPM key > > using > > the create_tpm[2]_key binary that comes with openssl_tpm[2]_engine. > > The key you create is then locked to the TPM of the system you > > create > > it on (so save an offline copy of the non-TPM private key). > > > > > > > > Do we need a new abstraction layer here somewhere, given that > > > this > > > seems to do something similar to using the windows crypto layer > > > to > > > access "private keys hidden in windows" (--cryptoapicert) and/or > > > pkcs11? > > > > I don't really think so. The engine keys are a bit of an openssl > > brainfart: there's no reason why PEM_read_bio_PrivateKey couldn't > > actually check for engine keys and have the whole thing transparent > > to > > all applications, except that openssl didn't want to do it that > > way. > > > > These keys are real files, so they're not like tokens, which is the > > pkcs11 abstraction. > > > That means, if one has the tpm_engine for openssl installed and > TPM-wrapped keys, this should just work, is it? And, I suppose, the > patch for openvpn is required only because openssl does not > transparently use available engines.
Yes, and no. By the time openssl sees the load request, it has a bio, rather than a file name, so there's a bit of additional glue openssl would need for transparent engine support. I proposed a patch a while ago to the openssl list, but it required an additional engine callback and wasn't very enthusiastically received. > If so, this looks like a easy way to provide TPM support to > openssl users on some platforms. What about Windows? Is there > an openssl TPM engine and tools to convert the key to a wrapped > TSS blob on Windows? No idea, I'm afraid. I would suspect not because windows isn't a great consumer of openssl, so no-one on the windows development side probably thought to write an openssl engine for their TPMs. > I would like to see new features transparently supported on Windows > as well without the need for too much extra code and associated > maintenance burden. Our 'cryptoapicert' implementation is already in > need of a major re-write to support TLS 1.2 and newer. Well, windows supports engines (via dlls), so the engine code will work for Windows, just not for my use case (their being no engine) and MS CryptoAPI is one of the supported engines. > From that point of view, instead of file-based wrapped keys, if a > pkcs11 compatible API can be used to access TPM (that's possible > isn't it?) TPM could be more widely usable without the need of any > additional support in openssl or openvpn. For TPM 1.2 it is possible to load the key into the TPM and then use the TPM as a loaded token via PKCS11 but the usual key format is file based not already present. For TPM 2, the design is different and the key has to be loaded each time from offline storage (the file) because the space in the TPM is so tiny, so treating it as a token is a bit more difficult. Obviously with enough pressure, even a square peg will fit in a round hole, it's just that it won't be elegant. James ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
