Break out from bug 8172. We want to be able to sign Windows binaries as a part of our build process with osslsigncode. To do this, osslsigncode requires a pkcs11-engine. One that works for us is available through libp11 [1] (pkcs11.so). In Fedora, it is provided by the openssl-pkcs11 package. [1] https://github.com/OpenSC/libp11
The pkcs11 engine plugin provided by the openssl-pkcs11 package can couple to OpenSSL in at least two ways. One may configure OpenSSL (see [1]), or have the p11-kit-proxy module available. Fortunately, the latter is provided by the p11-kit package which we already install, so there should be no need to configure OpenSSL. There’s a test suggested in [1] where the availability of the pkcs11 engine can be confirmed for an unconfigured openssl, $ openssl engine pkcs11 -t which was done on Fedora39 and RHEL9 with positive results. [1] https://github.com/OpenSC/libp11
Building the openssl-pkcs11 package from the source code [1] in our system will be based on its regular spec file [2] but likely modified to fit our needs and environment. [1] https://github.com/OpenSC/libp11/releases/download/libp11-0.4.12/libp11-0.4.12.tar.gz [2] https://src.fedoraproject.org/rpms/openssl-pkcs11/blob/rawhide/f/openssl-pkcs11.spec
Fedora applies 3 patches in their latest f39 release [1]. These however do not seem to be of crucial importance to us since (1) we are not subject to FIPS constraints, (2) we don’t copy keys, and (3) we specify the engine in the signing process. Thus we exclude them in the build and opt for the vanilla release of libp11. [1] https://src.fedoraproject.org/rpms/openssl-pkcs11/tree/f39
Using the openssl engine availability test (mentioned in comment #1) with cbrun, the pkcs11 engine has been confirmed to be available to openssl in archs win32 and win64. Acceptance criteria: ✅ We must provide a pkcs11 module for signing binaries in the build process ✅ This pkcs11 module must be compatible with openssl
There was a bit of confusion around whether p11-kit is indeed required for building and/or usage of the libp11 engine. It seems to be the case that if the engine should have access to a default pkcs11 module, then we’d require at least pkgconfig(p11-kit-1) to point us to the so-called proxy module [2] -- essentially a symlink to a default pkcs11 module, > /usr/lib/p11-kit-proxy.so → /usr/lib/libp11-kit.so.0.3.0 In this case, it makes sense that p11-kit is also required to run the libp11 engine. However, we’re employing a different pkcs11 module [1], libkmsp11.so, one which is accessible either explicitly by flag as in > osslsigncode -pkcs11module <module> ... or by referring to the environment variable $PKCS11_MODULE_PATH. The latter is picked up by the libp11 engine and seems to be a fairly standardized way of pointing to one’s pkcs11 module of choice. In this case, p11-kit wouldn’t be required neither for building nor running the engine. Note that it should be perfectly possible to set our pkcs11 module as the default module when building libp11 -- as opposed to the proxy module -- but it’s more transparent with an explicit flag path (which also removes the p11-kit build requirement). [1] https://github.com/GoogleCloudPlatform/kms-integrations/blob/master/kmsp11/docs/user_guide.md [2] https://p11-glue.github.io/p11-glue/p11-kit/manual/sharing.html
As mentioned above in comment #6, p11-kit is likely not a hard requirement for our libp11 use case. However, since it's a relatively small package, we might as well include a default pkcs11 module for good measure. Combine that with the fact that p11-kit is currently quite integral in our certificate framework, effectively it makes little difference including or excluding it as a build or run requirement. Reopening to complement the requirement list.
Build and run requirements should be complete now. Furthermore, some quick testing reveals that engine appears to load correctly according to the engine availability test, > cbrun win64 openssl engine pkcs11 -t > (pkcs11) pkcs11 engine > [ available ] and is responsive to command line configuration such as > cbrun win64 openssl engine pkcs11 -pre MODULE_PATH:/opt/cendio-build/arch/win64/usr/lib/libp11-kit.so.0.3.0 > (pkcs11) pkcs11 engine > [Success]: MODULE_PATH:/opt/cendio-build/arch/win64/usr/lib/libp11-kit.so.0.3.0 In addition, the engine may be successfully loaded in a signing and verification process of data using a priv/pub key pair, > cbrun win64 openssl dgst -sha256 -engine pkcs11 -sign rsa.key -out data.txt.sig data.txt > Engine "pkcs11" set. > cbrun win64 openssl dgst -sha256 -engine pkcs11 -verify rsa.pub -signature data.txt.sig data.txt > Engine "pkcs11" set. > Verified OK
I had a look at the manpage for openssl, which states the following under "Engine Options -engine id": > "(...) The engine will be used for key ids specified with -key and similar > options when an option like -keyform engine is given." While running the command > cbrun win64 openssl engine pkcs11 -t looks promising, it would be nice to use the library in a real-world scenario to verify that it works properly. I'm not entirely convinced that the tests conducted in comment #9 actually use any functions from the library. A simple way to test this properly would be to use smart cards and following the example in libp11's README [1], but unfortunately we can't share smart cards to cenbuild. We also don't have access to p11tool in cenbuild to generate new keys. This makes this library difficult to test as of now. As a quick experiment, I tried generating an X.509 certificate for osx64 (which doesn't have libp11): > cbrun osx64 openssl req -x509 -new -engine pkcs11 -keyform engine -subj "/CN=Test/C=SE/ST=LKPG/O=Cendio/" which gave the following error, but still successfully generated a valid certificate: > D088E9F7:error:12800067:DSO support routines:dlfcn_load:could not load the shared library:crypto/dso/dso_dlfcn.c:118:filename(/usr/lib/engines-3/pkcs11.so): /usr/lib/engines-3/pkcs11.so: cannot open shared object file: No such file or directory > D088E9F7:error:12800067:DSO support routines:DSO_load:could not load the shared library:crypto/dso/dso_lib.c:147: > D088E9F7:error:13000084:engine routines:dynamic_load:dso not found:crypto/engine/eng_dyn.c:438: > D088E9F7:error:13000074:engine routines:ENGINE_by_id:no such engine:crypto/engine/eng_list.c:471:id=pkcs11 > D088E9F7:error:12800067:DSO support routines:dlfcn_load:could not load the shared library:crypto/dso/dso_dlfcn.c:118:filename(libpkcs11.so): libpkcs11.so: cannot open shared object file: No such file or directory > D088E9F7:error:12800067:DSO support routines:DSO_load:could not load the shared library:crypto/dso/dso_lib.c:147: > D088E9F7:error:13000084:engine routines:dynamic_load:dso not found:crypto/engine/eng_dyn.c:438: Since we don't actually use the library as of today, but we might do so sometime in the future, I'm content with openssl listing pkcs11 as available to verify that things work at this time. [1] https://github.com/OpenSC/libp11
Found a list of applications that use PKCS11 [1]. There might be something simple we could use from this list for more proper validation. [1] https://en.wikipedia.org/wiki/List_of_applications_using_PKCS_11
Looked through the commits, looks good! > MUST: > > ✅ We must provide a pkcs11 engine for signing binaries in the build process > > ✅ This pkcs11 engine must be compatible with openssl While the library hasn't been thoroughly tested for our intended purposes, with what's written in comment # 10 in mind, I'm OK with closing this bug for now.
