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

Support HSM/TPM-stored client certificates #116

Open
forderud opened this issue Oct 14, 2022 · 2 comments
Open

Support HSM/TPM-stored client certificates #116

forderud opened this issue Oct 14, 2022 · 2 comments

Comments

@forderud
Copy link

forderud commented Oct 14, 2022

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 the read_private_key or load_private_key functions and then passed as arguments to est_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.

@jfigus
Copy link
Contributor

jfigus commented Oct 14, 2022

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.

@forderud
Copy link
Author

Thanks for your quick feedback @jfigus. I then guess I'll need to start by taking a look at https://github.com/rticommunity/openssl-cng-engine or similar as OpenSSL engine on Windows.

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

No branches or pull requests

2 participants