Current Support for OpenSSL Engine/Provider Integration in MQTT Client

[lorenzopintaldi]

Hello!

I'm seeking clarification regarding the current architectural possibilities for client authentication (mutual TLS) within the MQTT client functionality of the aws-sdk-cpp when connecting to AWS IoT Core.

The context is environments where the client's private key is stored securely in a TEE and is therefore not accessible as a standard PEM file on the local disk (neither via PKCS#11)

In typical C/C++ applications using OpenSSL for TLS, the solution for this involves:

1. Using a custom OpenSSL Engine or Provider to retrieve the key material or perform cryptographic operations.
2. Passing a pre-loaded key structure (like an EVP_PKEY*) to the TLS context (SSL_CTX) instead of file paths.

The goal is to understand if the architecture already permits this kind of secure key management without requiring the key to be physically present as a file.
Thank you in advance for the clarification on the existing capabilities!

[bretambrose]

You can link to OpenSSL's libcrypto, but there isn't support for manipulating internal TLS context or using libssl rather s2n.

HSM support (on Linux) is via PKCS11 only. It seems surprising to have an HSM but no PKCS11 support.

[lorenzopintaldi]

Hi! Thank you for the answer.

Some context: a third party is providing an OpenSSL provider as the interface to the TEE of an embedded device (with no direct PKCS#11 module). For most applications that need to perform mTLS, this works fine.

However, for MQTT client applications using the AWS IoT SDK, I can link against the system’s libcrypto (configured to use the external provider) using the -DUSE_OPENSSL option. But as far as I understand, the only available client-authentication methods are via file paths or PKCS#11.

Since PKCS#11 is not applicable here, the only option would be authentication via file paths. But in this case, I believe the SDK attempts to read the file contents (assuming it’s a PEM file) and derive the EVP_PKEY from those bytes — is that correct? If so, I have no way to retrieve the private key through some sort of OSSL_STORE_* API implemented by the provider.

Sorry if this is a bit confusing — I hope this clarifies the problem.

[bretambrose]

I see; in that case, we can't really offer any support.

[lorenzopintaldi]

Got it, thank you!