How to update intermediate device with pre-encrypted firmware (IDFGH-11012)

[law-ko]

Answers checklist.

• I have read the documentation ESP-IDF Programming Guide and the issue is not addressed there.
• I have updated my IDF branch (master or release) to the latest version and checked that the issue is present there.
• I have searched the issue tracker for a similar issue and not found a similar issue.

General issue report

Hello,

How to send pre-encrypted OTA BIN files to non-internet connected ESP32 and perform the pre-encrypted OTA update? The ESP32 will receive pre-encrypted OTA BIN file from UART communication. Previous issue

ESP-IDF: v5.0.1

Thank you.

[mahavirj]

@law-ko

• Please have a look at the esp_encrypted_img component public interface here
• Please have a look at the API usage for the custom data embedded in the application in this test file

Based on the above pointers you should be able to get the decrypted contents stream which can be fed to the OTA update APIs. Please note that the transport for pre encrypted contents could be anything, including UART for the use-case you specified here.

Hope this helps.

[mahavirj]

Closing, please feel to drop a comment if you need any further help.

[law-ko]

@mahavirj In the pre-encrypted example, esp_https_ota_begin includes decryption progress. However, how should we seperate this? We want to have the host ESP32 (which has internet connection) to download the bin file and send to another ESP32.

[law-ko]

@mahavirj Does the encrypted BIN need to be decrypted as an entire BIN file? We are sending small chunks (e.g. 110 bytes) and each chunk needs to be decrypted before feeding into esp_ota_write. However, we received ESP_ERR_NOT_FINISHED error.

/* Decrypt data */
args->data_in = (char *)encrypted_ota_write_data;
args->data_in_len = data_read;

err = esp_encrypted_img_decrypt_data(ctx, args);
ESP_LOGI(TAG, "Decryption error: %s", esp_err_to_name(err));

char *ota_write_data = args->data_out;

err = esp_ota_write( update_handle, (const void *)ota_write_data, data_read);

[mahavirj]

@law-ko

Please have a look at the API documentation for esp_encrypted_img_decrypt_data here:

https://github.com/espressif/idf-extra-components/blob/f115ea488e02e1af54e060fba1b1f06f0ff088ba/esp_encrypted_img/include/esp_encrypted_img.h#L92-L110

• ESP_ERR_NOT_FINISHED indicates that the decryption is on-going, not yet finished (needs more input data). It should not be treated as an error.
• If args->data_out_len is greater than 0 then there is decrypted contents in the args->data_out that you can use (of same length). The buffer must be freed after its usage.

API usage is also shown in the tests of the component here

[law-ko]

@mahavirj

Thank you for your input. We continue to feed in the data and got the following error:

E (74545) esp_encrypted_img: failed
  ! mbedtls_pk_decrypt returned -0x4100

E (74565) esp_encrypted_img: Unable to decipher GCM key

For all the args->data_in, do we need to malloc and not erase before esp_encrypted_img_decrypt_data returns ESP_OK? Or once it is passed into esp_encrypted_img_decrypt_data then the args->data_in will be managed by itself?

In the default OTA examples, 1024 bytes is commonly used, if we use 110 bytes would it cause error or should we consolidate into 1024 bytes before passing into esp_encrypted_img_decrypt_data?

[mahavirj]

E (74565) esp_encrypted_img: Unable to decipher GCM key

Please check if the binary is correctly pre-encrypted for this case. You may try decrypting it using esp_enc_img_gen.py for confirmation.

For all the args->data_in, do we need to malloc and not erase before esp_encrypted_img_decrypt_data returns ESP_OK? Or once it is passed into esp_encrypted_img_decrypt_data then the args->data_in will be managed by itself?

If you are allocating the buffer, then please free it up after the API returns.

In the default OTA examples, 1024 bytes is commonly used, if we use 110 bytes would it cause error or should we consolidate into 1024 bytes before passing into esp_encrypted_img_decrypt_data?

Any input size should work. In-fact the test file I pointed earlier has a test case for feeding 1 byte data at a time. Please have a look.