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.
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?
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.
>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.
Selva
------------------------------------------------------------------------------
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
