Configuring mbedtls options for crypto devices

1

Hello All,

I have a project which utilizes an ECC508 cryptography device to store secrets, including key pairs and device/signer certificates. I am attempting to port this project into the ESP32, but I am having some difficulty in configuring the mbedtls options to support what I need to do.

I need to redirect any mbedtls sign or verify operations through the ECC508 device, because the private key required to perform those operations is stored within and not accessible. (I cannot extract the key and present it to the mbedtls configuration structure for use during run-time.)

The PlatformIO interface provides the ability to set many mbedtls parameters through the menuconfig interface. However, there are some serious limitations with the manner in which this configuration interface is designed - perhaps intentionally, but I would like to know for sure.

One detail in particular is with regard to the option for use of alternate ECP implementations. I have selected the following two options in the menuconfig interface:

  • Enable hardware ECDSA sign acceleration when using ATECC608A
  • Enable hardware ECDSA verify acceleration when using ATECC608A

If I select these options to force the sign and verify functionality to an alternate handler, the compiler gives me the following warning:

#error “MBEDTLS_ECP_RESTARTABLE defined, but it cannot coexist with an alternative ECP implementation”

This restartable option allows non-blocking operation of the TLS handshake process, which is important to prevent the starving of other tasks in the system. The menuconfig interface “hard codes” the restartable option, so it cannot be changed. I believe this makes sense, but I am struggling with how I can implement the redirects of the sign/verify steps to the ECC508 if mbedtls wants these options to be mutually exclusive.

Has anyone had any experience with configuring a project to operate in such a fashion (redirecting mbedtls operations to a crypto device)?

Thanks in advance!
Mark

2

So it’s caused in ESP-IDF. I guess you could manually post-alter the generated sdkconfig.esp32 file to fix that up, but that would be a hack. If it happens in regular ESP-IDF too, which I assume, please file an issue in https://github.com/espressif/esp-idf/issues/.

If mbedTLS is even implementing the blocking wait on the result of the ATCC608A correctly in regards to FreeRTOS or the provided hooks, it should not starve other tasks of CPU time.

3

Thank you so much for your reply…

Yes, I agree, post-altering the sdkconfig file would be a hack, and I am attempting to avoid that at all costs. I am also attempting to avoid any modification to other files pulled from the repository as we stress the importance of being able to recreate our builds for historical integrity.

I concur that mbedtls should be implementing the non-blocking option properly to avoid starving other tasks in the FreeRTOS environment. I was not suggesting that is happening, but merely pointing out that there are configuration options available to select non-blocking operation.

I am attempting to determine what the proper mbedtls configuration would be through menuconfig (or some other method) while using the PlatformIO environment to support my hardware requirements and the redirecting of the sign/verify operations to the ECC508. I was hoping someone else has implemented a hardware configuration such as this and has successfully configured PlatformIO / ESP-IDF to get TLS operations working.

Best Regards,
Mark

4

Here is another thought…

The menuconfig interface currently hard-codes the inclusion of mbedtls for TLS support on a PlatformIO project.

Is there a way I can configure my project to bring in the latest mbedtls source code as a component, provide my own wrapper code and disable all PlatformIO wrapper code?

Mark