Esp-idf: Provisioning Documentation. (IDFGH-2254)

[monkeytronics]

Is there any documentation describing how to provision the SSID and Password over BLE & AP. I know there is an Android and iOS app available for reference. But for those who prefer to work in Ionic, this is not ideal.

Scanning and finding the device (BLE provisioning) is working fine, as expected. From here, it would be great to have a clear list of the steps required, ideally with as much detail as possible, including the expected responses at each stage.

[monkeytronics]

For completeness, here's the details of what I see when I connect.

 [console.log]: {
   "name": "PROV_F00574",
   "id": "24:6F:28:F0:05:76",
   "advertising": {},
   "rssi": -55,
   "services": [
     "1801",
     "1800",
     "12345678-90ab-cdef-fedc-ba0987654321"
   ],
   "characteristics": [
     {
       "service": "1801",
       "characteristic": "2a05",
       "properties": [
         "Indicate"
       ],
       "descriptors": [
         {
           "uuid": "2902"
         }
       ]
     },
     {
       "service": "1800",
       "characteristic": "2a00",
       "properties": [
         "Read"
       ]
     },
     {
       "service": "1800",
       "characteristic": "2a01",
       "properties": [
         "Read"
       ]
     },
     {
       "service": "1800",
       "characteristic": "2aa6",
       "properties": [
         "Read"
       ]
     },
     {
       "service": "12345678-90ab-cdef-fedc-ba0987654321",
       "characteristic": "1234ff50-90ab-cdef-fedc-ba0987654321",
       "properties": [
         "Read",
         "Write"
       ],
       "descriptors": [
         {
           "uuid": "2901"
         }
       ]
     },
     {
       "service": "12345678-90ab-cdef-fedc-ba0987654321",
       "characteristic": "1234ff51-90ab-cdef-fedc-ba0987654321",
       "properties": [
         "Read",
         "Write"
       ],
       "descriptors": [
         {
           "uuid": "2901"
         }
       ]
     },
     {
       "service": "12345678-90ab-cdef-fedc-ba0987654321",
       "characteristic": "1234ff52-90ab-cdef-fedc-ba0987654321",
       "properties": [
         "Read",
         "Write"
       ],
       "descriptors": [
         {
           "uuid": "2901"
         }
       ]
     },
     {
       "service": "12345678-90ab-cdef-fedc-ba0987654321",
       "characteristic": "1234ff53-90ab-cdef-fedc-ba0987654321",
       "properties": [
         "Read",
         "Write"
       ],
       "descriptors": [
         {
           "uuid": "2901"
         }
       ]
     }
   ]
 }

[mahavirj]

@monkeytronics You may find following pointers useful:

https://docs.espressif.com/projects/esp-idf/en/latest/api-reference/provisioning/provisioning.html
https://github.com/espressif/esp-idf/tree/master/tools/esp_prov
https://github.com/espressif/esp-idf/tree/master/examples/provisioning/console_prov

[monkeytronics]

@mahavirj Those are helpful. Unfortunately #3 doesn't run because of:

ImportError: No module named google.protobuf.internal

but never mind that. I've started with the app. I send the first command to write and then read back over BLE from the ff53 characteristic. I am getting this which I don't expect:

"Write Version V0.1"
"OK"
"Reading Version"
"{\n\t\"prov\":\t{\n\t\t\"ver\":\t\"v1.1\",\n\t\t\"cap\":\t[\"wifi_scan\"]\n\t}\n}"

Straight away I can't write & read the characteristic. Which is what I interpreted was done in esp_prov.py.

This is an up hill struggle. The python code is really tough going to follow with clever FSMs to track to find the execution path. The security part is a real can of worms. Is there any more linear documentation for the BLE use case or even pseudo code:

Write xxx to characteristic yyyy.
Read back from yyyy. It should be zzzz or else this thing is wrong. 
Create private / pubic key pair (with details)
etc... 

The console example is fine for debug, but it doesn't really help at all with recreating the application.

[mahavirj]

@monkeytronics I am afraid but beyond phone application source SDKs (for Android/iOS) and host side python tool (which is mentioned above), there are no additional references available (at the time design we thought that this should cover most users and their customization requirements).

[monkeytronics]

@mahavirj That makes sense. Is there anything available that we could use? Maybe a bullet point list showing the sequence of writes, reads, and security functions. It would be hugely helpful in getting us to market quicker.

[monkeytronics]

Some specific questions:

1.a) When I write "V0.1" to char UUID (1234ff53-90ab-cdef-fedc-ba0987654321) it responds "OK". I was expecting "SUCCESS" based on the guide. Possibly a version issue in which case, some guidance on other differences of this version would be great.
1.b) When I read back from that same UUID, I get {\n\t\"prov\":\t{\n\t\t\"ver\":\t\"v1.1\",\n\t\t\"cap\":\t[\"wifi_scan\"]\n\t}\n}. I was expecting it to respond with "V0.1". Any idea what's going on. As per 1a) are the readme notes no longer up to date.

1. The next example step involves sending to characteristic with UUID '0000ff51-0000-1000-8000-00805f9b34fb' payload = '10015a25a201220a20ae6d9d5d1029f8c366892252d2d5a0ffa7ce1ee5829312545dd5f2aba057294d'. I assume that in this step, we create a private and public key pair with curve25519, and send the public key over to the device. But the string is too long (it's 82 bytes instead of 64), so I'm not clear what it actually is. Would perhaps the group that developed the android app care to briefly list the sequence of steps and the packet contents for each one. It would be much more efficient than customers trying to reverse engineer the code.

Sorry to be a pain, but it's in everyone's interest to make it easier to access this product. Thanks guys.

[monkeytronics]

@mahavirj Is there any hope of getting some support on this. What's needed is a break down of the packets as sent and received. In question 2, I'm going to guess that the last 64 hex characters are the client public key. So, my question is really what are the other 18 hex chars. They look like cleartext given that the response contains something very similar, so it's got to be ble control stuff?? A little help or a clue would be great.

And the same for the remaining exchanges. What are the contents of each packet? We could really use some help finishing this, so we can focus on our core application.

Thanks.

[ameyinamdar]

Hi @monkeytronics. The protocol for WiFi provisioning is command-response based and uses Protobufs for data encoding (except for getting version). To make the provisioning work with multiple transports (BLE, SoftAP), it relies on different endpoints and the command-response communication works on specific end-points.

1. "Proto-ver" end-point is used for getting protocol version using JSON encoding. This is always plaintext and user-readable for simplicity.
2. "Prov-session" end-point is used for secure session setup. In case of security method "security0" this becomes optional as no security is used at the protocol level.
3. "Prov-config" is an end-point where all the Wi-Fi configuration related command responses take place.
4. "Prov-scan" end-point provides optional Wi-Fi scan results service.

For BLE transport, these end-points are associated with various BLE characteristics (Please see https://github.com/espressif/esp-idf/blob/master/components/wifi_provisioning/src/manager.c#L1233). Write operation can be used to send command whereas read operation can fetch blocking response. For actual command-responses structure, you can check files present in https://github.com/espressif/esp-idf/tree/master/components/wifi_provisioning/proto. Wi-Fi configuration command-responses are listed in https://github.com/espressif/esp-idf/blob/master/components/wifi_provisioning/proto/wifi_config.proto. You can extend the protocol by adding your own end-point or by adding additional command-response in existing end-point. Then you have to regenerate "C" protobuf files using protoc-c compiler.

I hope this helps. Please let me know if I can help further.

[monkeytronics]

Still working on this. Based on the example in : ble_prov I was epecting to be able to write something like this:

"write_version('prov-session', '10015a25a201220a20ae6d9d5d1029f8c366892252d2d5a0ffa7ce1ee5829312545dd5f2aba057294d')"

that's fed into function:

 if (characteristic === 'prov-session') {
      uuid_frag = 'ff51';
 }

    this.ble.write(
      this.peripheral.id,
      '12345678-90ab-cdef-fedc-ba0987654321', // sevice id uuid
      '1234' + uuid_frag + '-90ab-cdef-fedc-ba0987654321', // characteristic uuid : proto-ver
      write_buffer).then( 
        response => this.setStatus('Write Response = ' + response),
        //() => this.setStatus('Write Successful.'),
        e => console.log('Oh no, ', e )
      );

Whe I do this, I can see the error tripping in the monitor:

E (856888) security1: Unable to unpack setup_req
E (856888) protocomm_ble: Invalid content received, killing connection
E (856898) BT_GATT: GATTS_SendRsp Unknown  conn_id: 3

E (856898) BT_APPL: Sending response failed

which is means the potobuf wasn't decoded successfully. So the provided example string isn't actually right. It would be great if I could get a sample that worked to start with. I've got prototbuf working, but it's not much use to me if I don't know what format to encode...

Console log in my app looks like this:

[ng] [console.log]: {}
[ng] [console.log]: "Write Version 10015a25a201220a20ae6d9d5d1029f8c366892252d2d5a0ffa7ce1ee5829312545dd5f2aba057294d"
[ng] [console.log]: "Oh no, " 133

[ameyinamdar]

@monkeytronics please note that the 'prov-session' endpoint is used only for session establishment as per the security protocol that is pre-defined between the device and the provisioner (python client in your case). I am not sure if you are using this end-point to send some different custom data across. If you wish to send custom data, you can create additional end-point in the device and add support for it in the provisioner. The example for sending the custom data can be found at https://github.com/espressif/esp-idf/tree/master/examples/provisioning/custom_config

The code to add custom endpoint can be found at https://github.com/espressif/esp-idf/blob/master/examples/provisioning/custom_config/main/app_prov.c#L97 and actual custom data handler function can be found at https://github.com/espressif/esp-idf/blob/master/examples/provisioning/custom_config/main/app_prov_handlers.c#L51

The example also contains the proto files and host side python script as well to send the custom data. Essentially, you can use this example and change the custom_config proto https://github.com/espressif/esp-idf/blob/master/examples/provisioning/custom_config/components/custom_provisioning/proto/custom_config.proto to contain data that you wish to send across or get from device.

[monkeytronics]

@ameyinamdar thanks. I am sending the session setup request message. I've created a payload of type Sec1Payload. But it is being rejected by the device with a 133 error.

        var payload = new messages.Sec1Payload();
        payload.setMsg(0);
        payload.setSc0(cmd0); 

        console.log(payload.getMsg());
        console.log(payload.hasSc0());
        console.log(payload.getSc0());
        console.log(payload.hasSc1());
        var bytesOfStuff =  payload.serializeBinary();

The binary packet is like this (as a Uint8Array).

"162,1,34,10,32,251,250,47,97,175,206,247,185,147,253,198,80,121,163,199,213,45,239,76,141,51,27,248,200,238,37,251,23,216,59,49,48"

I notice my packet is significantly shorter than the values in the example below taken from the provisoining example. There are 41 characters there. Am I using the wrong .proto or something?

==== Starting Session ====
BLECLI >> Write following data to characteristic with UUID '0000ff51-0000-1000-8000-00805f9b34fb' :
    >> 10015a25a201220a20ae6d9d5d1029f8c366892252d2d5a0ffa7ce1ee5829312545dd5f2aba057294d
BLECLI >> Enter data read from characteristic (in hex) :
    << 10015a390801aa0134122048008bfc365fad4753dc75912e0c764d60749cb26dd609595b6fbc72e12614031a1089733af233c7448e7d7fb7963682c6d8
BLECLI >> Write following data to characteristic with UUID '0000ff51-0000-1000-8000-00805f9b34fb' :
    >> 10015a270802b2012212204051088dc294fe4621fac934a8ea22e948fcc3e8ac458aac088ce705c65dbfb9
BLECLI >> Enter data read from characteristic (in hex) :
    << 10015a270803ba01221a20c8d38059d5206a3d92642973ac6ba8ac2f6ecf2b7a3632964eb35a0f20133adb
==== Session Established ====

In fact I tried to push the example packets back through the protobuf deserialiser and they didn't register as valid.

What is the sequence?

Write ff51 (cmd0). Sec1Payload with sc0 = 32 byte Key.
Read ff51 (resp0). Expect Sec1Payload with sr0 = status + Key + rand.
Write ff51 (cmd1) ...
Read ff51 (resp1) ...

It's pretty easy on paper, but I just can't seem to get it to work.

UPDATE

There's a layer missing from my protobuf onion. I stumbled upon the session.proto file. It gives a hint that you need to encapsulate your secVer=1 and the actual payload one level more (at which point you really have to question the rationale of using protobufs at all. It's so fiddly and gives you nothing back in this application... But anyway). So, Having done that, the buffer is now the correct length, and looks about right in terms of the contents. When I send it... Drum roll... I get a bad base-64 error, which might be a good pointer!

Added base64 encoding to the binary message and the error in the monitor at last looks like it understands what is going on. Weirdly the base 64 error only occured the first time. It then returned the below errors I'm wondering that might be a red herring. Surely base64 is handled by protobuffers internally?

E (196468) security1: Security version mismatch. Closing connection
E (196468) protocomm_ble: Invalid content received, killing connection

and

E (1026428) security1: Unable to unpack setup_req
E (1026428) protocomm_ble: Invalid content received, killing connection
E (1026438) BT_GATT: GATTS_SendRsp Unknown  conn_id: 3

E (1026438) BT_APPL: Sending response failed

I can see these failures in components/protocomm/src/security/security1.c

If anyone wanted to help out, it would be welcome. A lot of this is new ground for me, so it's taking a long time.

[ameyinamdar]

@monkeytronics I think you need to start with SessionData that wraps Sec1Payload. If you want to send a security1 session request from Python script, there is a python tool available https://github.com/espressif/esp-idf/tree/master/tools/esp_prov that has the relevant code that can be found at https://github.com/espressif/esp-idf/blob/master/tools/esp_prov/security/security1.py#L132

[monkeytronics]

@ameyinamdar Yes. I did all of that already. I can now send data successfully. However, the shared key generation is not working. I have added some hexdumps into the code and enabled debug logging. From this, I can see the PoP SHA265 hashing function matches my implementation. However, the shared key does not. I have grabbed the hex dumps of private and public keys to debug, but as yet cannot successfully recreate the shared key! I've tried reversing the endian-ness of the private, public and shared key (8 combinations) without success (noticing that there is a lot of flip_endian() going on in the code. It really would be helpful if this was better documented.

From the device code:

D (14049) security1: Device pubkey:
D (14059) security1: 1c 9d 55 ef c2 ad 4e 03 97 37 3c f5 5b b1 e1 f5
D (14059) security1: b1 dd de e2 e9 9a b3 e3 93 21 9b 86 2d b0 0c 77
D (14059) security1: Client pubkey:
D (14059) security1: dc 75 7e 8c 7b 7a cc 47 cb 88 f6 59 94 cf 73 2b
D (14069) security1: cc 3e d5 a1 94 69 87 e3 7d 43 77 99 41 69 b1 55
D (14469) security1: Adding proof of possession
D (14469) security1: PoP     =:
D (14469) security1: 61 62 63 64 31 32 33 34
D (14469) security1: SHA PoP =:
D (14479) security1: e9 ce e7 1a b9 32 fd e8 63 33 8d 08 be 4d e9 df
D (14479) security1: e3 9e a0 49 bd af b3 42 ce 65 9e c5 45 0b 69 ae
D (14489) security1: Shared key (no ^ SHA):
D (14489) security1: 21 03 0b 84 be 43 a2 5b 73 7c 04 40 84 be a5 44
D (14499) security1: f8 82 4a 81 91 65 95 2c 7b 4f 53 ce 26 01 35 1e
D (14509) security1: Shared key:
D (14509) security1: c8 cd ec 9e 07 71 5f b3 10 4f 89 48 3a f3 4c 9b
D (14519) security1: 1b 1c ea c8 2c ca 26 6e b5 2a cd 0b 63 0a 5c b0

From my implementation. My code pulls the device public key over the BLE connection, and logs this:

[ng] [console.log]: "device Public = " "1c9d55efc2ad4e0397373cf55bb1e1f5b1dddee2e99ab3e393219b862db00c77"
[ng] [console.log]: "Client Private  = " "684ea2dd64ae40bc46accb8455a9e900c89ec68092ef9b12e3b7fdf0b5fcae51"
[ng] [console.log]: "Shr (noSHA) " "52d3f1e808c935d0008e7a527fd409cc2c462e67144fd5cfb7b9a3f2dcd68263"
[ng] [console.log]: "SHA PoP   = " "e9cee71ab932fde863338d08be4de9dfe39ea049bdafb342ce659ec5450b69ae"
[ng] [console.log]: "Shr(final)= " "bb1d16f2b1fbc83863bdf75ac199e013cfd88e2ea9e0668d79dc3d3799ddebcd"

I've checked the pop & SHA of this. I've also double checked the XOR conversion. Those all look good. It's the calculation of Shared Key (before adding the PoP) that does not tie up ("Shr (noSHA) "). As I' say, I've tried reversing the endianness of everything. This is a standard function. What am I missing that explains why the result of the shared key generation do not match the expected value?

[ameyinamdar]

@monkeytronics It uses Curve25519 to generate the shared secret and it seems to be not matching somehow with the device side implementation. On the device, it uses mbedTLS curve25519 API and the python scripts use "crypography.hazmat" X25519 python package. Please see: https://github.com/espressif/esp-idf/blob/30372f5a4ff2c0dfdaad95f544dc36bcdda30b75/tools/esp_prov/security/security1.py#L115

I suppose the best way to verify this may be to use device private key and client public key hardcoded in your Curve25519 call to ensure that it generates the same shared secret. May I ask which crypto implementation are you using?

[ameyinamdar]

BTW, the security1 scheme documentation is available at https://docs.espressif.com/projects/esp-idf/en/latest/api-reference/provisioning/provisioning.html

[monkeytronics]

OK. So I've managed to establish the session. I can also send a start scan message and it is recognised by the device which shows the results in the console.

D (160609) protocomm_ble: Inside write with session - 0 on attr handle = 42 len = 6, is_prep = 0
D (160609) protocomm_ble: Write to Bluetooth Address sڪ0*
D (160619) protocomm_ble: Payload:
D (160619) protocomm_ble: 0e cc 05 33 d3 05
D (160629) protocomm_ble: is_prep not set
D (160629) proto_wifi_scan: In wifi_prov_scan_cmd_dispatcher Cmd=0
D (160639) wifi_prov_mgr: Scan starting...
W (160639) wifi: Error! Should use default active scan time parameter for WiFi scan when Bluetooth is enabled!!!!!!

D (160649) wifi_prov_mgr: Scan started
D (162229) event: SYSTEM_EVENT_SCAN_DONE, status:0, number:1
D (162229) wifi_prov_mgr: Scan finished
D (162229) wifi_prov_mgr: Scan results :
D (162229) wifi_prov_mgr:       S.N. SSID                             BSSID        RSSI AUTH
D (162239) wifi_prov_mgr:       [ 0] xxxxxx                            xxxxxxxxxxx  -74    3
D (162449) proto_wifi_scan: Response packet size : 4
D (162449) protocomm_ble: Response from  write:
D (162449) protocomm_ble: 46 cd 77 c6

And there's where it stops. The problem I was having before was that the nonce seems to be incrementing by a different number than I expected. Here's 2 observations that I can't account for.

1) If I write to the start scan end point or scan status endpoint, it works fine. If I write a second time, it fails. I increment the nonce by 1 to account for the single block of encrypted payload. But I've tried incrementing by 0, 1, 2, 3, and 4 though just in case. So, I would rule this out as the problem. Why can't I read more than once? Either the nonce is very different, or there's another reason this is disallowed?

D (601309) protocomm_ble: Write to Bluetooth Address sڪ0*
D (601319) protocomm_ble: Payload:
D (601319) protocomm_ble: 86 99 6f 31
D (601319) protocomm_ble: is_prep not set
D (601329) proto_wifi_scan: In wifi_prov_scan_cmd_dispatcher Cmd=2
D (601329) proto_wifi_scan: Response packet size : 8
D (601339) protocomm_ble: Response from  write:
D (601339) protocomm_ble: f4 13 1a 34 3b 3a 0e 5d
D (606139) protocomm_ble: Inside write with session - 0 on attr handle = 42
len = 4, is_prep = 0
D (606139) protocomm_ble: Write to Bluetooth Address sڪ0*
D (606149) protocomm_ble: Payload:
D (606149) protocomm_ble: 68 c0 cd c1
D (606149) protocomm_ble: is_prep not set
E (606159) proto_wifi_scan: Unable to unpack scan message
E (606159) protocomm: Request handler for prov-scan failed
E (606169) protocomm_ble: Invalid content received, killing connection

2) If I read back from the Start Scan Response end point, I can't decode the response for some reason. And the really confusing thing is that if I read it many times, I notice that the encrypted payload isn't changing. Therefore, the nonce isn't incrementing on the device side?! What's going on? I'm expecting the nonce to increment by the number of 16 byte blocks (or parts of). It works during the session establishment step. But it seems to fail afterwards. What's the secret? Why does this not work?

I'd still really appreciate some help with this.

[ameyinamdar]

@monkeytronics

1) This appears to be issue with AES-CTR implementation on your client side. In the protocomm (which is the base for Wi-Fi provisioning), once the session is setup, the subsequent communication on all end-points happens with the same context of AES-CTR. Typically, you don't have to manage the nonce value manually and the crypto library should take care of correctly incrementing it internally.
2) Your second observation also points to the same issue probably, that result in failed decoding of response. It is correct that if you read the value multiple times on an end-point (BLE characteristic), you won't see the value changing. Because as per the protocol, the command has to be executed by writing to the endpoint to receive the response. Only reading the response multiple times won't trigger the command automatically. The purpose behind this design is to make the protocol work across different transports like BLE and HTTP.

Essentially mapping the crypto correctly to match the server side implementation is hard. We understand that and that's where we have provided C, Java, Objective-C and Python code. But it looks like you're using a different client. I found that using MbedTLS's AES implementation is easily portable if your platform supports C/C++. Please see if that can work in your case.

[monkeytronics]

@ameyinamdar

1. I agree. My implementation has an issue. When you say communication happens with the same context, does that means the nonce is increased once per 16 byte block? The code I'm using appears to require manual control of the nonce, which is a pain. But my efforts to match up the nonce with the expected seem to fail for some reason.
2. Interesting. I don't suppose you know what behaviour to expect for the nonce on repeated reads.

Perhaps there's a way to get mbedtls to print out the nonce during the encryption / decryption process so I can compare them. I've tried to do this but couldn't figure it out. I set the flag in menuconfig -> mbedtls debug. And the tried to set the debug level to 4 in the code. But I didn't see anything in the console. With your obvious expertise with mbedtls, I don't suppose you know how to do this?

[ameyinamdar]

@monkeytronics Please note that there are two nonce related parameters for AES-CTR - nonce and nonce_offset. Nonce is a 16 byte random (but shared) data that is incremented and nonce_offset keeps track of current offset which is (total_data_len_so_far % 16). I added a print in the AES-CTR encrypt function and performed Wi-Fi scanlist get operation couple of times and this is how I see the nonce and nonce_offset progressing. Please note that the nonce offset and nonce is printed before AES-CTR operation. Nonce value increases by 1 (nonce[15] being least-significant). Please see below log. Hope this helps.

esp_aes_crypt_ctr len 32 nc_offset 0 NC: BB 56 6F 41 C5 13 56 54 F7 AF 61 AD 54 B5 7A A8
esp_aes_crypt_ctr len 32 nc_offset 0 NC: BB 56 6F 41 C5 13 56 54 F7 AF 61 AD 54 B5 7A AA
esp_aes_crypt_ctr len 6 nc_offset 0 NC: BB 56 6F 41 C5 13 56 54 F7 AF 61 AD 54 B5 7A AC
esp_aes_crypt_ctr len 4 nc_offset 6 NC: BB 56 6F 41 C5 13 56 54 F7 AF 61 AD 54 B5 7A AD
esp_aes_crypt_ctr len 4 nc_offset 10 NC: BB 56 6F 41 C5 13 56 54 F7 AF 61 AD 54 B5 7A AD
esp_aes_crypt_ctr len 8 nc_offset 14 NC: BB 56 6F 41 C5 13 56 54 F7 AF 61 AD 54 B5 7A AD
esp_aes_crypt_ctr len 6 nc_offset 6 NC: BB 56 6F 41 C5 13 56 54 F7 AF 61 AD 54 B5 7A AE
esp_aes_crypt_ctr len 182 nc_offset 12 NC: BB 56 6F 41 C5 13 56 54 F7 AF 61 AD 54 B5 7A AE
esp_aes_crypt_ctr len 8 nc_offset 2 NC: BB 56 6F 41 C5 13 56 54 F7 AF 61 AD 54 B5 7A BA
esp_aes_crypt_ctr len 159 nc_offset 10 NC: BB 56 6F 41 C5 13 56 54 F7 AF 61 AD 54 B5 7A BA
esp_aes_crypt_ctr len 8 nc_offset 9 NC: BB 56 6F 41 C5 13 56 54 F7 AF 61 AD 54 B5 7A C4
esp_aes_crypt_ctr len 153 nc_offset 1 NC: BB 56 6F 41 C5 13 56 54 F7 AF 61 AD 54 B5 7A C5
esp_aes_crypt_ctr len 8 nc_offset 10 NC: BB 56 6F 41 C5 13 56 54 F7 AF 61 AD 54 B5 7A CE
esp_aes_crypt_ctr len 81 nc_offset 2 NC: BB 56 6F 41 C5 13 56 54 F7 AF 61 AD 54 B5 7A CF
esp_aes_crypt_ctr len 6 nc_offset 3 NC: BB 56 6F 41 C5 13 56 54 F7 AF 61 AD 54 B5 7A D4
esp_aes_crypt_ctr len 4 nc_offset 9 NC: BB 56 6F 41 C5 13 56 54 F7 AF 61 AD 54 B5 7A D4
esp_aes_crypt_ctr len 4 nc_offset 13 NC: BB 56 6F 41 C5 13 56 54 F7 AF 61 AD 54 B5 7A D4
esp_aes_crypt_ctr len 8 nc_offset 1 NC: BB 56 6F 41 C5 13 56 54 F7 AF 61 AD 54 B5 7A D5
esp_aes_crypt_ctr len 6 nc_offset 9 NC: BB 56 6F 41 C5 13 56 54 F7 AF 61 AD 54 B5 7A D5
esp_aes_crypt_ctr len 187 nc_offset 15 NC: BB 56 6F 41 C5 13 56 54 F7 AF 61 AD 54 B5 7A D5
esp_aes_crypt_ctr len 8 nc_offset 10 NC: BB 56 6F 41 C5 13 56 54 F7 AF 61 AD 54 B5 7A E1
esp_aes_crypt_ctr len 154 nc_offset 2 NC: BB 56 6F 41 C5 13 56 54 F7 AF 61 AD 54 B5 7A E2

[monkeytronics]

That's amazing! Thanks for doing that. I don't suppose you could share the code you added so I can duplicate the output here. It would be so helpful debugging the last few parts of this process.

[ameyinamdar]

@monkeytronics I can indeed provide the debug patch here. Please use:

diff --git a/components/esp32/hwcrypto/aes.c b/components/esp32/hwcrypto/aes.c
index 3bf90a9bc4..1f36f6dde4 100644
--- a/components/esp32/hwcrypto/aes.c
+++ b/components/esp32/hwcrypto/aes.c
@@ -450,6 +450,14 @@ int esp_aes_crypt_ctr( esp_aes_context *ctx,
         return MBEDTLS_ERR_AES_INVALID_KEY_LENGTH;
     }

+    printf("esp_aes_crypt_ctr len %d nc_offset %d ", length, *nc_off);
+    printf("NC: ");
+    for (i = 0; i < 16; i++) {
+        printf("%2X ", nonce_counter[i]);
+    }
+
+    printf("\n");
+
     esp_aes_acquire_hardware();
     ctx->key_in_hardware = 0;

[monkeytronics]

Awesome stuff. Got it all working. Thanks for all your help! I have learned quite a few things in the process! You guys are hardcore.