Hello,
im trying to make an inhouse provisioning tool for esp32 wifi provisioning. Im writing this in .net and using Bouncycastle library for implementing security. With the encryption im way out of my league here. My issue arrises with handshake 1 response. The serial log on esp32 tells me that i have established secure session
but when i accept the response in my .net application i cannot match the decryptedDeviceVerifyData with my public key. i checked all status of handshake responses, and they both return ok, as is indicated by the esp itself. im unable to determine how to solve the problem (since i dont understand how this exchange works in the first place)
since i have quite alot of testing code i attached my implementation as a file. I hope someone can provide a clue to this, and thanks anyway
implementing security 1 handshake in .net
-
- Posts: 4
- Joined: Mon May 09, 2022 9:13 am
implementing security 1 handshake in .net
- Attachments
-
- dotnet-security1-implementation.txt
- (8.69 KiB) Downloaded 50 times
-
- Posts: 4
- Joined: Mon May 09, 2022 9:13 am
Re: implementing security 1 handshake in .net
I investigated more into the application
a little more clarification on my part. I am referencing the espressif/esp-idf-provisioning-android implementation. To meet the aes-ctr requirement I use the BouncyCastle.net library, which has aes-ctr . After a little bit of messing around it seems to me that the behavior of bouncycastle algo is different than the one used on java platform,
with my limited understanding i tried the following situations
encode/decode with ProcessBytes seems to work during the handshake, but after that, the logic seems to error because of null references or otherwise wrong logic.
more specific, the null reference seems to be from the ProcessBytes function return. the first encoding/decoding, during the handshake, seems fine. but any other consecutive uses of the cipher are not.
encode/decode with ProcessBytes and then DoFinal. Handshake response 1 fails, due to not being able to match the decoded verification key.
As an experiment, I tried to combine the two situations. I do only ProcessBytes in the handshake. That passes the handshake, after which consecutive encode/decode calls do not error, BUT ultimately, the communication fails with deserialising the responses into protobuffer instance.
i should conclude that my handshake flow is not at fault. But I use the aes cipher in a wrong way. Is there anyone who could say how to use the bouncycastle library correctly ? if it can not reasonably be done with that provider, could anybody suggest an alternative ? or any insight at all, is welcome
a little more clarification on my part. I am referencing the espressif/esp-idf-provisioning-android implementation. To meet the aes-ctr requirement I use the BouncyCastle.net library, which has aes-ctr . After a little bit of messing around it seems to me that the behavior of bouncycastle algo is different than the one used on java platform,
with my limited understanding i tried the following situations
encode/decode with ProcessBytes seems to work during the handshake, but after that, the logic seems to error because of null references or otherwise wrong logic.
more specific, the null reference seems to be from the ProcessBytes function return. the first encoding/decoding, during the handshake, seems fine. but any other consecutive uses of the cipher are not.
encode/decode with ProcessBytes and then DoFinal. Handshake response 1 fails, due to not being able to match the decoded verification key.
As an experiment, I tried to combine the two situations. I do only ProcessBytes in the handshake. That passes the handshake, after which consecutive encode/decode calls do not error, BUT ultimately, the communication fails with deserialising the responses into protobuffer instance.
i should conclude that my handshake flow is not at fault. But I use the aes cipher in a wrong way. Is there anyone who could say how to use the bouncycastle library correctly ? if it can not reasonably be done with that provider, could anybody suggest an alternative ? or any insight at all, is welcome
Who is online
Users browsing this forum: jldesigns and 80 guests