Re: running named built with --enable-native-pkcs11 without HSM provider library
On Thu, Jul 30, 2015 at 10:19:49AM -0700, Carl Byington wrote: RHEL7/Centos7 now has softhsm v2 available. What about a new pkcs11 provider that is just an interface into openssl? --enable-native-pkcs11 \ --with-pkcs11=pkcs11-openssl-shim Bind uses native pkcs11, but the default .so it loads just redirects all the calls into openssl. That in fact is exactly what SoftHSMv2 does. Bind will ask it to generate keys, and will assume that that provider will keep the private key part. So we still don't end up with the original /var/named/K*.private files. Technically you still have the files, but instead of the files containing private key material themselves, they have indentifiers to tell the HSM (or pseudo-HSM) which key is to be used. Well, this new provider is *only* used by bind, so it could run under the bind user account, have selinux access to /var/named, and keep its private key data in files, possibly in a new /var/named/pkcs11-openssl- shim directory. With this scheme, we would not need the -pkcs11 rpm subpackages, but could use /etc/sysconfig/named to control the switch between providers. Better than just replicating the behavior of SoftHSMv2 would be a shim that can switch between multiple PKCS#11 providers. You'd build BIND to link to the shim provider. The shim in turn could pass along PKCS#11 calls to either SoftHSM or some other HSM, depending on the key. Then for example, you could use a KeyPer (slow but very secure) for certain high value keys but use software crypto (much faster but less secure) for others. This has been on our to-do list for some time but other items have taken priority. Does redhat want to write (or fund the writing of) such a shim provider? We'd certainly be happy for any assistance. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
running named built with --enable-native-pkcs11 without HSM provider library
Hello. I'm trying to figure out how can named be built with --enable-native-pkcs11 and run without the PKCS#11 provider library. Our use-case is that given how OpenSSL does not support PKCS#11 properly, we would like to use the the native-pkcs11 if using some HSM, but by default run named without the need to have HSM. In case not having HSM, use OpenSSL for example. Right now it is not possible, and when named is built with --enable-native-pkcs11 it can not run without HSM and some PKCS#11 provider library. Would it be possible to make named to operate in a manner described in the previous section? Thanks in advance. Regards, -- Tomas Hozza Software Engineer - EMEA ENG Developer Experience PGP: 1D9F3C2D Red Hat Inc. http://cz.redhat.com ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: running named built with --enable-native-pkcs11 without HSM provider library
Tomas Hozza tho...@redhat.com wrote: Right now it is not possible, and when named is built with --enable-native-pkcs11 it can not run without HSM and some PKCS#11 provider library. Would using SoftHSM solve your problem? http://www.opendnssec.org/softhsm/ http://ftp.isc.org/isc/bind9/9.10.0-P2/doc/arm/Bv9ARM.ch04.html#id2666009 Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Irish Sea: West or southwest, veering northwest for a time, 4 or 5, occasionally 6 at first. Slight or moderate. Showers. Moderate or good. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: running named built with --enable-native-pkcs11 without HSM provider library
On Wed, Aug 06, 2014 at 05:14:53PM +0100, Tony Finch wrote: Right now it is not possible, and when named is built with --enable-native-pkcs11 it can not run without HSM and some PKCS#11 provider library. Would using SoftHSM solve your problem? http://www.opendnssec.org/softhsm/ http://ftp.isc.org/isc/bind9/9.10.0-P2/doc/arm/Bv9ARM.ch04.html#id2666009 SoftHSM version 1 doesn't supply enough of the PKCS#11 API to meet all of BIND's crypto needs, but SoftHSMv2 works beautifully. Last I checked, version 2 hadn't been formally released yet, but it can be cloned from github: https://github.com/opendnssec/SoftHSMv2. The way things are currently set up, BIND can only drive one PKCS#11 provider library at a time. You build with a default provider, and it can be overridden via a command line option, but that's a little cumbersome. I've been thinking about using a shim provider that would pass along PKCS#11 primitives to a back-end according to context, so you could switch seamlessly between providers -- that might be useful, for example, if you wanted to use a proper HSM for your KSK, but SoftHSM for the ZSK because it's faster. It might also enable us to drive an HSM that didn't have a complete PKCS#11 implementation, using SoftHSM to fill in the functional gaps. Haven't done any work on it, though. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: running named built with --enable-native-pkcs11 without HSM provider library
- Original Message - Tomas Hozza tho...@redhat.com wrote: Right now it is not possible, and when named is built with --enable-native-pkcs11 it can not run without HSM and some PKCS#11 provider library. Would using SoftHSM solve your problem? No. We don't want to install SoftHSM by default, only if explicitly chosen by the user. Basically we want to enable user to use native-pkcs11 with SoftHSM if needed. However by default have named running without it. http://www.opendnssec.org/softhsm/ http://ftp.isc.org/isc/bind9/9.10.0-P2/doc/arm/Bv9ARM.ch04.html#id2666009 Yeah, I read the ARM PKCS#11 section, that's why I think it is not possible. However I wanted to hear some opinions from named guys. Thanks. Regards, -- Tomas Hozza Software Engineer - EMEA ENG Developer Experience PGP: 1D9F3C2D Red Hat Inc. http://cz.redhat.com ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: running named built with --enable-native-pkcs11 without HSM provider library
- Original Message - On Wed, Aug 06, 2014 at 05:14:53PM +0100, Tony Finch wrote: Right now it is not possible, and when named is built with --enable-native-pkcs11 it can not run without HSM and some PKCS#11 provider library. Would using SoftHSM solve your problem? http://www.opendnssec.org/softhsm/ http://ftp.isc.org/isc/bind9/9.10.0-P2/doc/arm/Bv9ARM.ch04.html#id2666009 SoftHSM version 1 doesn't supply enough of the PKCS#11 API to meet all of BIND's crypto needs, but SoftHSMv2 works beautifully. Last I checked, version 2 hadn't been formally released yet, but it can be cloned from github: https://github.com/opendnssec/SoftHSMv2. The way things are currently set up, BIND can only drive one PKCS#11 provider library at a time. You build with a default provider, and it can be overridden via a command line option, but that's a little cumbersome. As far as I understand, without native-pkcs11 OpenSSL is used for crypto operations if the provided PKCS#11 library did not support some operation, or if the PKCS#11 provider library was not provided/was not available at all. With native-pkcs11 the the PKCS#11 provider library has to be provided and available all the time. I'm interested if there is any chance to fall-back to OpenSSL in that case OR specify OpenSSL as provider library (however preferably without the needed patch) during the build and if needed, specify e.g. the SoftHSMv2 provider library on the command line using '-E' during the runtime. I've been thinking about using a shim provider that would pass along PKCS#11 primitives to a back-end according to context, so you could switch seamlessly between providers -- that might be useful, for example, if you wanted to use a proper HSM for your KSK, but SoftHSM for the ZSK because it's faster. It might also enable us to drive an HSM that didn't have a complete PKCS#11 implementation, using SoftHSM to fill in the functional gaps. Haven't done any work on it, though. It sound like it would solve use-case I described. Regards, -- Tomas Hozza Software Engineer - EMEA ENG Developer Experience PGP: 1D9F3C2D Red Hat Inc. http://cz.redhat.com ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: running named built with --enable-native-pkcs11 without HSM provider library
On Wed, Aug 06, 2014 at 02:02:33PM -0400, Tomas Hozza wrote: As far as I understand, without native-pkcs11 OpenSSL is used for crypto operations if the provided PKCS#11 library did not support some operation, or if the PKCS#11 provider library was not provided/was not available at all. With native-pkcs11 the the PKCS#11 provider library has to be provided and available all the time. I'm interested if there is any chance to fall-back to OpenSSL in that case OR specify OpenSSL as provider library (however preferably without the needed patch) during the build and if needed, specify e.g. the SoftHSMv2 provider library on the command line using '-E' during the runtime. There are currently three possible ways to provide crypto in BIND. - Link with OpenSSL (this is the default). - PKCS#11 via patched OpenSSL. This requires an alternate version of OpenSSL that originated as part of the OpenSolaris project (which is no more). The patches were never accepted upstream by the OpenSSL maintainers, so ISC has been supporting them: they're included with the BIND source. In this model, BIND calls crypto functions in OpenSSL as usual, but OpenSSL passes along some of the requests as PKCS#11 primitives to an HSM instead of handling them itself. Functions not provided by the HSM are handled by OpenSSL. This works with several HSMs, but it's complex, difficult to debug, and cumbersome to have to use a nonstandard OpenSSL. Also, frankly we'd prefer not to have to maintain the patches forever, so we're hoping to deprecate this model in time. - Native PKCS#11, introduced in BIND 9.10. In this model, BIND speaks directly to a PKCS#11 provider; OpenSSL isn't in the picture at all. For it to work, we need the provider to have a *full* implementation of the PKCS#11 API, because the provider needs to serve *all* of BIND's cryptographic needs -- not just signing but also validation, hashing, random number generation, etc. Currently I only know of two PKCS#11 providers that work: Thales, and SoftHSMv2. There isn't currently any mechanism to have BIND switch back and forth between providers. You can use the -E option to select a provider at runtime, but there's no way to alter that selection except to restart the server. That's what the shim I mentioned would be for. Unfortunately, I can't tell you anything about when such a thing is likely to get written; we've got a lot of other tasks lined up ahead of it, and not enough pairs of hands. Contributed code or offers of sponsorship would be lovely. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
