DS peripheral support in HTTP and MQTT clients

[4rzael]

Motivations

Some chips of the esp32 family include a digital signature peripheral, which can be used to securely store private keys for TLS client/mutual authentication.
I need this feature in both HTTP & MQTT, and am willing to implement it. I'm creating this issue first because I'd like to discuss the API implications, to avoid unnecessary breaking changes, and potentially to get some guidance, as I'm fairly new to this ecosystem.

Solution

The support for the DS peripheral itself is directly integrated in the esp-idf http & mqtt clients.
From my understanding, I would need to first PR to esp-idf-sys, to get the esp_ds.h header included
Then I'll need to write a safe wrapper in esp-idf-hal. A minimal viable wrapper for this use-case (not including the ability to do manual operations) would require the ability to obtain a valid (wrapped)esp_ds_data_ctx_t and the key's corresponding certificate.

Finally, I'll need to update the mqtt/http client config in this repository to take an Option<EspDsDataContext>.
To do so, we could:

• Add it to the configuration, which is breaking for users that don't use ..Default() to create the config.
• Add it to the configuration, behind a feature flag.
• Replace private_key and private_key_password to make a PrivateKeyProvider enum, as they are mutually exclusive with ds_data (and potentially later on use_secure_element). While potentially more idiomatic, this is a big breaking change, so probably not the best idea. We could instead generate an EspError (or panic) when a configuration with those mutually exclusive items is given.

Am I missing something ?

Alternatives

Additional context

Issue #84 : Crypto Support

esp-idf mqtt with DS-based TLS example

DS peripheral API documentation

ESP TLS DS documentation

[ivmarkov]

Overall, what you have in mind sounds like a decent plan!

Comments inline below.

The support for the DS peripheral itself is directly integrated in the esp-idf http & mqtt clients. From my understanding, I would need to first PR to esp-idf-sys, to get the esp_ds.h header included

Correct, this is a necessary, backwards-compatible first step.

Then I'll need to write a safe wrapper in esp-idf-hal. A minimal viable wrapper for this use-case (not including the ability to do manual operations) would require the ability to obtain a valid (wrapped)esp_ds_data_ctx_t and the key's corresponding certificate.

Ideally, we should model this by:

• Having a DS "peripheral" in the Peripherals struct, like every other peripheral
• Having a DS "driver" (DsDriver?) which takes the peripheral
• The driver might even have some basic API, but initially we don't even need that. Just a way to new the driver I guess

Finally, I'll need to update the mqtt/http client config in this repository to take an Option<EspDsDataContext>. To do so, we could:

This sounds like the trickiest part as I'm not 100% sure how that's going to pan out especially if we give a try to my idea of modeling the DS peripheral with an esp-idf-hal peripheral + driver. Perhaps you need to mutably borrow the driver in the MQTT/HTTP clients?

• Add it to the configuration, which is breaking for users that don't use ..Default() to create the config.
• Add it to the configuration, behind a feature flag.
• Replace private_key and private_key_password to make a PrivateKeyProvider enum, as they are mutually exclusive with ds_data (and potentially later on use_secure_element). While potentially more idiomatic, this is a big breaking change, so probably not the best idea. We could instead generate an EspError (or panic) when a configuration with those mutually exclusive items is given.

Perhaps we can have a clearer view of how ^^^ would look like once we have something like a peripheral and a driver in the HAL?

Am I missing something ?

No I think you are pretty much spot-on.