ESP32 Forum

Hello,

We are developing a product based on ESP32-S3 and IDF 5.0.1 (current stable). There is also a Microchip ATECC680A-TNGTLS on board, though we will be using ATECC608B-TNGTLS in production.

I have the board up and running, and I am able to access the secure element using ESP-CRYPTOAUTHLIB 3.5.1 as a managed component, with functions such as device identification and reading of the device unique id and public key, so the interface is fully functional.

When I go to establish an MQTTS session esp_mqtt_set_ssl_transport_properties() reports the error:

E (13583) mqtt_client: Secure element not enabled for esp-tls in menuconfig

Now, this turns out to be due to a missing configuration option in sdkconfig, specifically: CONFIG_ESP_TLS_USE_SECURE_ELEMENT. I tried to set that option via menuconfig but it simply wasn't there. When I checked the Kconfig for ESP-TLS I found: Clearly the problem is that the Kconfig is preventing the option appearing simply because I am using ESP32-S3, not ESP32.
I edited the Kconfig to: and the error went away (to be replaced with another, but that's one for me to sort out).

A related issue is that when the session is shut down the I2C driver is apparently unloaded, because subsequent accesses to our RTC on the same I2C bus report the error:

E (14338) i2c: i2c_master_cmd_begin(1481): i2c driver not installed

I know we are not the only ones to place an RTC on the same bus as the secure element.

So, what I am asking for is:

• Would it be possible to modify the ESP-TLS Kconfig to not require only ESP32?

• Can ESP-CRYPTOAUTHLIB be modified to install without error if the I2C driver is already loaded at initialisation time, and to leave the driver in place on exit in such a case?

• While I am on the subject, esp_cryptoauthlib_utility has the same ESP32 only problem, so a --chip option would be good

Thank you,
Neil

Hi @ntremble

1) Yes, I will update esp-idf to fix this issue.
2) For now it is a limitation, the i2c interface in esp-cryptoauthlib is not smart enough to figure out if i2c driver has already been installed for the port. This is in discussion phase as to how we can sort the issue, if you have any suggestions then they are most welcome.
3) Sure, I have raised internal tracker, it should be done in a few days.

Thanks,
Aditya

Hi Aditya,

Thank you, fixes for 1 and 3 will be very useful.

I had a quick look at the HAL code and saw there is already support for starting and stopping multiple devices, but only when they are on different I2C buses. Since there is a reference count and an array of configs maybe it would be better to have a linked list of configs, which would allow you to achieve the same thing without a reference count and without the same bus limitation. I cannot imagine the list ever having more than a few nodes, so speed should not be an issue.

The one complicating issue might be if someone were to try to start two devices on the same bus with different characteristics (speed, bit order). It would be possible to scan the list in hal_i2c_init() checking for conflicts, but personally I'd be ok with a "don't do that, it won't work" condition.

Looking forward to a resolution that does not involve me hacking the library to get it to work

Regards,
Neil

Are there any updates.

We are also planning to use the Secure Element with ESP-IDF 5.1 and a ESP32-S3.

I can't see any updated code, is this still planned?

Hi @ntremble and @oedzee,

I use an ESP32S3 (N16R2) and a Microchip ATECC680A-TNGTLS cryptochip (external I2C component). I would like to use the certificate on the chip and perform mutual authentication. It seems to be necessary to enable "secure element" in esp_mqtt.

Have you guys been able to perform mutual authentication using the cryptochip?