PROTON-2594: Add OpenSSL PKCS#11 PROVIDER support to enable HSM use #430
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Hardware Security Modules (HSMs) are physical computing devices that safeguard secrets and allow performing cryptographic operations like encryption and signing without necessarily divulging the private key material. PKCS#11 is a platform-independent API for cryptographic tokens like HSMs. It defines a scheme for pkcs11: URIs that describe objects on the token as well as an API to interact with them. This commit adds support for transparent use of PKCS#11 URIs: Whenever a certificate or private key path is prefixed with pkcs11: it will be interpreted as PKCS#11 URI instead of a file path and OpenSSL will do all necessary communication with the HSM behind the scenes. For programs like proton that use OpenSSL, this could have been realized in two ways: - OpenSSL ENGINE: Introduced in OpenSSL 0.9.6 and deprecated in 3.0 - OpenSSL PROVIDER: Introduced in OpenSSL 3.0 to replace ENGINE While both are supported in recent OpenSSL versions, it's more future proof to use the PROVIDER API, even if this comes at the cost of having to add an #ifdef to the code. This has been tested on Linux/x86_64 with softhsm and Linux/arm32 with OP-TEE, both with v0.5 of https://github.com/latchset/pkcs11-provider. As everything is loaded dynamically, we do not link against any PKCS#11-related shared libraries. It's expected that PKCS#11 provider will already be loaded via OPENSSL_CONF if it's to be used.
The error message unconditionally mentions tserver-private-key.pem, which is not applicable to Windows, where tserver-full.p12 is used instead. Fix this by using a new PRIVATEKEY macro that expands to the correct file name depending on whether we compile for Windows or not. This prepares us for adding a third PKCS#11 #ifdef branch in the follow-up commit, which is also why we are moving SSL_FILE specific into the existing #ifdef branches.
The broker hardcodes the name of the files used at compile time, depending on whether it's built for Windows or not. Add a third option by checking whether PKCS11_URI is defined: If it is, it will use it to reference a "tserver" certificate and private key that should be used instead of the keys in the ssl-certs/ directory. This allows an easy manual test of the PKCS#11 functionality.
|
This looks good to me - is there any way of testing this functionality in the CI job? (Rather than just testing that nothing regressed!) |
How about we apply this patch and then run the test twice once with PEM files and once with PKCS#11 or would you prefer I duplicate the relevant parts into a new test? PKCS#11 test would use SoftHSM like done here, but I haven't attempted to do this in CI yet. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Hardware Security Modules (HSMs) are physical computing devices that
safeguard secrets and allow performing cryptographic operations like
encryption and signing without necessarily divulging the private key
material.
PKCS#11 is a platform-independent API for cryptographic tokens like
HSMs. It defines a scheme for pkcs11: URIs that describe objects on the
token as well as an API to interact with them.
This commit adds support for transparent use of PKCS#11 URIs: Whenever a
certificate or private key path is prefixed with pkcs11: it will be
interpreted as PKCS#11 URI instead of a file path and OpenSSL will do
all necessary communication with the HSM behind the scenes.
For programs like proton that use OpenSSL, this could have been
realized in two ways:
While both are supported in recent OpenSSL versions, it's more future
proof to use the PROVIDER API, even if this comes at the cost of having
to add an #ifdef to the code.
This has been tested on Linux/x86_64 with softhsm and Linux/arm32 with
OP-TEE, both with v0.5 of https://github.com/latchset/pkcs11-provider.
As everything is loaded dynamically, we do not link against any
PKCS#11-related shared libraries. It's expected that PKCS#11 provider
will already be loaded via OPENSSL_CONF if it's to be used.