You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm interested in developing an EST-based certificate enrollment infrastructure with TLS-based client authentication with private keys stored in a Hardware Security Module (HSM), Trusted Platform Module (TPM) or similar. This means that the private key for the client authentication certificate will not be directly accessible in the form of a file or memory buffer. Key operations instead need to be performed through "crypto provider" interfaces like Cryptography Next Generation (CNG) on Windows or similar APIs on other platforms. Certificates are then instead referred to by name, like e.g. CurrentUser\My\MyClientAuthCertificate or thumbprint in APIs relying on them for crypto operations.
I'm wondering if usage of memory buffers for client certificate private keys is a fundamental limitation for this project, or if there are plans for also supporting HSM/TPM-stored keys in the future?
Well, libest relies on OpenSSL for crypto and TLS. OpenSSL had an engine interface, which allows anyone to develop a crypto implementation and plug it into their framework. If you have an OpenSSL engine working for your HSM, then achieving your goal is feasible. But you might need some minor changes to libest to direct OpenSSL to use the crypto engine for your HSM.
I'm interested in developing an EST-based certificate enrollment infrastructure with TLS-based client authentication with private keys stored in a Hardware Security Module (HSM), Trusted Platform Module (TPM) or similar. This means that the private key for the client authentication certificate will not be directly accessible in the form of a file or memory buffer. Key operations instead need to be performed through "crypto provider" interfaces like Cryptography Next Generation (CNG) on Windows or similar APIs on other platforms. Certificates are then instead referred to by name, like e.g.
CurrentUser\My\MyClientAuthCertificate
or thumbprint in APIs relying on them for crypto operations.After having taken a quick look at the libest sources, then it seems like the API is currently bound to private keys being loaded into
EVP_PKEY
memory buffers using either theread_private_key
orload_private_key
functions and then passed as arguments toest_client_set_auth(EST_CTX *ctx, const char *uid, const char *pwd, X509 *client_cert, EVP_PKEY *private_key)
.I'm wondering if usage of memory buffers for client certificate private keys is a fundamental limitation for this project, or if there are plans for also supporting HSM/TPM-stored keys in the future?
I don't know if it's relevant, but there seem to be some libcurl dependencies in the sources. I stumbled across a related Support secure enclaves by referencing key-pairs by name instead of passing actual key(s) request in libcurl that as of today does not seem to have been implemented.
The text was updated successfully, but these errors were encountered: