Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Adding initial pkcs#11 support for TLS private key storage #436

Draft
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

JohnLogan
Copy link

@JohnLogan JohnLogan commented Aug 31, 2023

This is an initial commit adding pkcs#11 support for TLS private key storage. This was tested using Intel 'Key Management Reference Architecture (KMRA)' project, which uses SGx enclave to store manage keys, but could be used with other pkcs#11 targets. Moves private keys from local file to remote key management storage.


if ( 0 != access( opensc_pkcs11_so, R_OK ) )
{
ERR(NULL, "Error finding '/usr/local/lib/libpkcs11-proxy.so'");
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

paths cannot be hardcoded like that, not even in error messages

rc = -1;
goto cleanup;
}

if ( 1 != ENGINE_ctrl_cmd_string( pkcs11, "MODULE_PATH", opensc_pkcs11_so, CMD_MANDATORY ) )
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This loads a .so into the process' address space based on a an environment variable. That's effectively an arbitrary code execution vulnerability based on a non-standard variable name.

How does OpenSSL typically solve this?

Also, the README upstream says that the command name is called SO_PATH, not MODULE_PATH.

Comment on lines +553 to +555
ERR(NULL, "Error retrieving 'pkcs11' engine");
rc = -1;
goto cleanup;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This means that the code would hard-fail at runtime when OpenSSL is built without this dynamic engine support. It's better to only request a dynamic engine when needed, i.e., hide this behind some switch to active this new functionality.

The library should continue to work as-is when the user does not opt-in to this new feature (which by definition requires some configuration).

goto cleanup;
}

if ( 1 != ENGINE_ctrl_cmd_string( pkcs11, "PIN", "1234", CMD_MANDATORY ) )
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

a hardcoded PIN?

ERR(NULL, "Loading the server private key failed (%s).", ERR_reason_error_string(ERR_get_error()));
if (privkey_path) {
if (SSL_CTX_use_PrivateKey_file(tls_ctx, privkey_path, SSL_FILETYPE_PEM) != 1) {
ERR(NULL, "1 Loading the server private key failed (%s).", ERR_reason_error_string(ERR_get_error()));
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: extra 1 ?

goto cleanup;
}

if ( 1 != ENGINE_init( pkcs11 ) )
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The documentation says:

This returns zero if the ENGINE was not already operational and couldn't be successfully initialised (e.g. lack of system drivers, no special hardware attached, etc), otherwise it will return nonzero to indicate that the ENGINE is now operational and will have allocated a new functional reference to the ENGINE.

...yet the code checks for 1.

Also everywhere else.

@vjardin
Copy link

vjardin commented Jan 19, 2024

another related merge request is the !454

Since ENGINE is deprecated since OpenSSL 3, PROVIDER shall be used instead.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants