| Message ID | 1509192147.3021.6.camel@HansenPartnership.com |
|---|---|
| Headers | show |
| Series | add engine keys keys | expand |
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? 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 see more #ifdef in the code and this is usually a sign of "it will increase testing requirement, and we can't even test the abstraction if none of us has the hardware". But I leave the more specific discussion to Steffan and Antonio :-) gert
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. > I see more #ifdef in the code and this is usually a sign of "it will > increase testing requirement, and we can't even test the abstraction > if none of us has the hardware". > > But I leave the more specific discussion to Steffan and Antonio :-) Testing is possible. If you look at the build repository of openssl_tpm2_engine: https://build.opensuse.org/project/show/home:jejb1:TPM You'll see there are tests in there that fire up a software tpm to run. However, the software TPM is a bit capricious and certainly only runs on openssl 1.0.2, so I can't run the tests on Fedora 26 for instance without rewriting the swtpm2 package. James ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot
Am 29.10.17 um 16:24 schrieb Gert Doering: > 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? > > 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 see more #ifdef in the code and this is usually a sign of "it will > increase testing requirement, and we can't even test the abstraction if > none of us has the hardware". > > But I leave the more specific discussion to Steffan and Antonio :-) As a sidenote, OpenVPN itself implements its own "engine" (with the older pre engine RSA_method) to allow management-external-keys. Unifying that would be nice but is probably a lot of work, especially since OpenVPN engine is not so straightforward to implement. Arne ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot
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 <div dir="ltr">Hi,<br><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Oct 29, 2017 at 12:04 PM, James <span class="" id=":4oy.1" tabindex="-1">Bottomley</span> <span dir="ltr"><<a href="mailto:James.Bottomley@hansenpartnership.com" target="_blank">James.<span class="" id=":4oy.2" tabindex="-1">Bottomley</span>@<wbr><span class="" id=":4oy.3" tabindex="-1">hansenpartnership</span>.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span>On Sun, 2017-10-29 at 16:24 +0100, Gert Doering wrote:<br> > Hi,<br> ><br> > On Sat, Oct 28, 2017 at 01:02:27PM +0100, James Bottomley wrote:<br> > ><br> > > Engine keys are an openssl concept for a key file which can only be<br> > > understood by an engine (usually because it's been wrapped by the<br> > > engine itself). We use this for TPM engine keys, so you can either<br> > > generate them within your TPM or wrap them from existing private<br> > > keys. Once wrapped, the keys will only function in the TPM that<br> > > generated them, so it means the VPN keys are tied to the physical<br> > > platform, which is very useful. Engine keys have to be loaded via<br> > > a specific callback, so use this as a fallback in openvpn if an<br> > > engine is specified and if the PEM read of the private key fails.<br> ><br> > How does this work in an OpenVPN context, as in, what do I have to do<br> > to make TPM keys work on client and server?<br> <br> </span>If you have an existing private key, you convert it to a TPM key using<br> the create_tpm[2]_key binary that comes with openssl_tpm[2]_engine.<br> The key you create is then locked to the TPM of the system you create<br> it on (so save an offline copy of the non-TPM private key).<br> <span><br> > Do we need a new abstraction layer here somewhere, given that this <br> > seems to do something similar to using the windows crypto layer to<br> > access "private keys hidden in windows" (--cryptoapicert) and/or<br> > pkcs11?<br> <br> </span>I don't really think so. The engine keys are a bit of an openssl<br> brainfart: there's no reason why PEM_read_bio_PrivateKey couldn't<br> actually check for engine keys and have the whole thing transparent to<br> all applications, except that openssl didn't want to do it that way.<br> <br> These keys are real files, so they're not like tokens, which is the<br> pkcs11 abstraction.</blockquote><div><br></div><div>That means, if one has the <span class="" id=":4oy.4" tabindex="-1">tpm</span>_engine for <span class="" id=":4oy.5" tabindex="-1">openssl</span> installed and</div><div><span class="" id=":4oy.6" tabindex="-1">TPM</span>-wrapped keys, this should just work, is it? And, I suppose, the</div><div>patch for <span class="" id=":4oy.7" tabindex="-1">openvpn</span> is required only because <span class="" id=":4oy.8" tabindex="-1">openssl</span> does not transparently</div><div>use available engines.</div><div><br></div><div>If so, this looks like a easy way to provide <span class="" id=":4oy.9" tabindex="-1">TPM</span> support to<br></div><div><span class="" id=":4oy.10" tabindex="-1">openssl</span> users on some platforms. What about Windows? Is there</div><div>an <span class="" id=":4oy.11" tabindex="-1">openssl</span> <span class="" id=":4oy.12" tabindex="-1">TPM</span> engine and tools to convert the key to a wrapped</div><div><span class="" id=":4oy.13" tabindex="-1">TSS</span> blob on Windows?</div><div><br></div><div>I would like to see new features transparently supported on Windows</div><div>as well without the need for too much extra code and associated</div><div>maintenance burden. Our 'cryptoapicert' implementation is already in</div><div>need of a major re-write to support <span class="" id=":4oy.14" tabindex="-1">TLS</span> 1.2 and newer.</div><div><br></div><div>From that point of view, instead of file-based wrapped keys, if a pkcs11</div><div>compatible API can be used to access <span class="" id=":4oy.15" tabindex="-1">TPM</span> (that's possible isn't it?) <span class="" id=":4oy.16" tabindex="-1">TPM</span></div><div>could be more widely usable without the need of any additional support</div><div>in <span class="" id=":4oy.17" tabindex="-1">openssl</span> or <span class="" id=":4oy.18" tabindex="-1">openvpn</span>.</div><div><br></div><div><span class="" id=":4oy.19" tabindex="-1">Selva</span></div></div></div></div> ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot
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
Hi James, On 30/10/17 15:09, James Bottomley wrote: > On Sun, 2017-10-29 at 17:03 -0400, Selva wrote: >> 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: >>>> 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. > > I'm quite interested in using a TPM to store keys - do you have a set of instructions on how to load a key into the TPM and then sign data using that key? Most of the implementations I've found using something like trousers , which does NOT encrypt data using the TPM itself, but uses the TPM as a master key to sign other keys with. thx, JJK ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot
Hi, On 29-10-17 22:03, Selva wrote: > 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. Fully agree. Since cryptoapicert is windows-specific, I actually think it would be better to add a 'CNG'[0] implementation to the windows wrapper, and make that use management-external-key. That would probably improve UX a lot too, showing users a drop-down to select a key, etc. We can then remove the whole deprecated cryptoapi implementation from the openvpn core. > 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. Since this one is transparent, and works as long as the user loads the right engine, I don't see any limitations to include this patch. -Steffan [0] https://msdn.microsoft.com/en-us/library/windows/desktop/aa376210(v=vs.85).aspx ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot
Hi, On Wed, Nov 1, 2017 at 2:18 PM, Steffan Karger <steffan@karger.me> wrote: > Hi, > > On 29-10-17 22:03, Selva wrote: > > 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. > > Fully agree. Since cryptoapicert is windows-specific, I actually think > it would be better to add a 'CNG'[0] implementation to the windows > wrapper, and make that use management-external-key. That would probably > improve UX a lot too, showing users a drop-down to select a key, etc. > We can then remove the whole deprecated cryptoapi implementation from > the openvpn core. > > > 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. > > Since this one is transparent, and works as long as the user loads the > right engine, I don't see any limitations to include this patch. > Agreed this is a simple patch that could be used right away. Let's address 'Cryptography Next Gen' (CNG) and general use of management-external-key as a separate topic. I too feel the management interface client and/or plugins is a better place to add support for platform specific cert/key storage etc., instead of polluting openvpn core. Simon was planning to add support for TLS 1.2+ in eduVPN for keys stored in Windows certstore -- I suppose that would involve CNG. Selva <div dir="ltr">Hi,<br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Nov 1, 2017 at 2:18 PM, Steffan Karger <span dir="ltr"><<a href="mailto:steffan@karger.me" target="_blank">steffan@karger.me</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br> <span class=""><br> On 29-10-17 22:03, Selva wrote:<br> > I would like to see new features transparently supported on Windows<br> > as well without the need for too much extra code and associated<br> > maintenance burden. Our 'cryptoapicert' implementation is already in<br> > need of a major re-write to support TLS 1.2 and newer.<br> <br> </span>Fully agree. Since cryptoapicert is windows-specific, I actually think<br> it would be better to add a 'CNG'[0] implementation to the windows<br> wrapper, and make that use management-external-key. That would probably<br> improve UX a lot too, showing users a drop-down to select a key, etc.<br> We can then remove the whole deprecated cryptoapi implementation from<br> the openvpn core.<br> <span class=""><br> > From that point of view, instead of file-based wrapped keys, if a pkcs11<br> > compatible API can be used to access TPM (that's possible isn't it?) TPM<br> > could be more widely usable without the need of any additional support<br> > in openssl or openvpn.<br> <br> </span>Since this one is transparent, and works as long as the user loads the<br> right engine, I don't see any limitations to include this patch.<br></blockquote><div><br></div><div>Agreed this is a simple patch that could be used right away. Let's address </div><div>'Cryptography Next Gen' (CNG) and general use of management-external-key</div><div>as a separate topic.</div><div><br></div><div>I too feel the management interface client and/or plugins is a better place</div><div>to add support for platform specific cert/key storage etc., instead of polluting</div><div>openvpn core.</div><div><br></div><div>Simon was planning to add support for TLS 1.2+ in eduVPN for keys</div><div>stored in Windows certstore -- I suppose that would involve CNG.</div><div><br></div><div>Selva</div></div></div></div> ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot