Use secure element (ATECC608) with HTTP client (IDFGH-8625)

[LumbirBwut]

Is your feature request related to a problem?

Right now I couldn't find a way to use the secure element with an HTTP client, using esp_http_client_init(&clientConfig); I couldn't find inside the function a reference to esp_transport_ssl_use_secure_element and I couldn't setup in the client configuration the option .use_secure_element = true because it doesn't exist.

Describe the solution you'd like.

I'd like something like MQTT client which actually work like a charm where directly in the configuration you could setup something like this:

esp_mqtt_client_config_t mqttClientConfig;
mqttClientConfig.use_secure_element     = true;

Describe alternatives you've considered.

To make it works, what I did is including http_auth.h, http_header.h which are supposed to be private includes to which user doesn't have have access to. I also created a dedicated file containing different structures such as: esp_http_client, connection_info_t, esp_http_state_t, etc.

Finaly this dirty fix allowed me to call at higher level without modifying esp-idf, just after esp_http_client_init(&clientConfig);the intended function:

esp_transport_ssl_use_secure_element(esp_transport_list_get_transport(_httpClient->transport_list,
                                                                     _httpClient->connection_info.scheme));

Using this the mutual authentification using the secure element (ATECC608) with http client, work like a charm.

Additional context.

I'm using esp-idf 4.3 with an ESP32

[chipweinberger]

Just FYI

The ATECC508A, ATECC608A and ATECC608B have been hacked and are no longer secure.

https://i.blackhat.com/USA21/Wednesday-Handouts/us-21-Defeating-A-Secure-Element-With-Multiple-Laser-Fault-Injections.pdf

[AdityaHPatwardhan]

@LumbirBwut Thanks for the issue, this would be considered as a feature request. Yes, we can add respective support in the HTTP client.

Dear reader, please feel free to ignore the side-discussion part.
Some side-discussion:
@chipweinberger Thanks for sharing the info, Looking at the link I see that the hacker has explained the attack for ATECC608A. I think this was the reason that the ATECC608B chip was released.
I don't see any mention of successful attacks on ATECC608B. Do you know if it is the case for ATECC608B? Anyways this is not related to the issue and I have just mentioned this due to my curiosity.

[AdityaHPatwardhan]

@LumbirBwut can you please check if this patch works in your case?
Thanks
esp_http_client_secure_element.patch.zip

[chipweinberger]

@AdityaHPatwardhan

ATECC608A was released to address his hack for the ATECC508A.

He then also hacked the ATECC608A. In the ATECC608A, they just added another hardware check for tampering, requiring 2 laser faults instead of 1.

https://www.youtube.com/watch?v=Kj1nVJypXPM

The ATECC608B was then released to the address the ATECC608A hack, but they have not given many details.

http://ww1.microchip.com/downloads/en/Appnotes/Migrating-from-the-ATECC608A-to-the-ATECC608B-DS40002237A.pdf

Microchip has not marketed demonstrated that their new chip can circumvent laser attacks. It appears to be a fundamental flaw. The ATECC608B should also be vulnerable to these same attacks.

I'd recommend the STSAFE-A110. As far as I know, it has better fault protections. SpaceX uses it in their Starlink Terminals.

[AdityaHPatwardhan]

Okay, thanks for the info @chipweinberger

[LumbirBwut]

Hello @AdityaHPatwardhan, thanks for your really quick answer.

I just test your patch I can confirm you, without surprise, that it works 👍 (I forget to mention it, but the first fix I did match what you did in your patch however in our case, we didn't want to directly modify esp-idf lib otherwise we should have fork it. That's why I did the dirty tricks I mentionned above)

Concerning the patch in itself, be aware that I couldn't directly git apply patch_name it. I suppose (and I'm almost sure) it's because I'm on esp-idf 4.3 and not on last version (adding manually the changes did the trick though).

Some side-discussion:
@chipweinberger I already know about the security concerns around the ATECC608A, hope that the ATECC608B doesn't suffers from it.

[AdityaHPatwardhan]

@LumbirBwut Thanks for confirming, I will go ahead and merge the patch in the ESP-IDF master branch. But we won't be able to back-port the feature in v4.3 as only critical bug fixes are back-ported.