Closed Chandranshu9 closed 3 years ago
Hello @Chandranshu9
It looks like you are having some issues with the BTLE example. Did you follow the instructions in the readme? Specifically the configuration of wolfSSL:
./configure --enable-ecc --enable-eccencrypt --enable-hkdf && make && sudo make install
Hi @embhorn Yes I followed these steps, The problem seems to be in the code because client and server both are running but when I try to send a message from the client to server, the error encryption failed gets printed.
Thank you. I was able to reproduce the issue. I'll review and update when its fixed. Are there any things in the demo that you would like to see improved (besides it running, of course!)?
There are two things that I would like to see improved, One being that instead of using btle Simulator, can't we make use of Two embedded devices like esp32 having BLE, If yes then how to proceed.
Second, It is mentioned that TLS/SSL can be simulated but would take a lot of time and resources, But suppose if I only need server side authentication as it normally happens in HTTPS, Can you help me simulate it so that I can compare the two methods.
Hi @Chandranshu9 , thanks for your report using this BTLE example with our --enable-eccencrypt
ECIES scheme. I will look into the errors you are seeing. Also thanks for the suggestion for adding an ESP32 example.
As for using TLS instead that would work fine, however the TLS handshake would be quite slow due to the size of the X509 certificates. Using TLS v1.3 with reduced handshake roundtrip would help. Also there are some plans this year to implement certificate compression in TLS possibly based on RFC8879 (https://tools.ietf.org/html/rfc8879).
Not sure you saw it but we did recently add a BTLE example for wolfBoot that you might find interesting. It does not use this ECC encryption scheme, but might be interesting to you. https://github.com/wolfSSL/wolfBoot-examples/pull/5
Thanks, David Garske, wolfSSL
Hello, Thank you for your quick response.
Regarding TLS, Since I am not concerned about the time taken by TLS handshake but instead want to provide maximum security, Can you in such a scenario help me with TLS authentication over BLE?
The main concern would be how to use TLS over BLE? I need your insights on this.
Hi @Chandranshu9 ,
We would be happy to help with a BTLE and TLS v1.3 example. I think it would be helpful to have a quick call to discuss. Would you mind sending a email to facts@wolfssl.com with some information on how to reach you?
Thanks, David Garske, wolfSSL
I have sent a mail, waiting for your reply.
Hi @Chandranshu9 ,
I've put up a pull request to fix this issue here: https://github.com/wolfSSL/wolfssl/pull/3711
The --enable-eccencrypt
feature was missing an RNG context with ECC timing resistance enabled.
We followed up on your email and looking forward to chatting soon.
Thanks, David Garske, wolfSSL
The issue is still not resolved.
Sorry about the close, it was automatic because I said "fixed" in the mention. Are you still having issues with the current example that uses --enable-eccencrypt
?
For the feature request to have a TLS v1.3 version of the BTLE example it is on our feature request list.
Thanks, David Garske, wolfSSL
@dgarske Yes, I am still facing the same issue. Did you try to check it at your end whether it's working or not?
One more thing, Can you guide me on how to send a hash (SHA 2) of some data from one BLE device and verifying it at the other BLE device (Assuming I do have a hash of the data stored on both the devices)? Similarly can we verify the message digest as well?
Hi @Chandranshu9 ,
Yes it was fully tested and working here. Did you include the wolfSSL changes in https://github.com/wolfSSL/wolfssl/pull/3711 for your test?
There is a good example of SHA2-256 hashing here: https://github.com/wolfSSL/wolfssl-examples/blob/master/hash/sha256-hash.c
For a hash check to work you would need to have the same data on each side. Hash it and exchange the 32-byte hash and compare it.
Thanks, David Garske, wolfSSL
I am getting the same wc_ecc_encrypt failed error.
How can I exchange the hash from one BLE to other BLE device? Can you help me with this?
Hi @Chandranshu9,
I have tried reproducing your issue with wolfSSL 4.6.0 and 4.7.0 on Ubuntu 20.04 LTS, but I was unable to reproduce it, the btle example is working for me.
What version of wolfSSL are you using, and what platform are you building for? Can you post the configure flags you are using if they differ from the readme? Can you retry configuring and making the library, then run sudo make install
followed by sudo ldconfig
and see if it helps?
Thanks, Kareem
I am using wolfSSL 4.6.0 on Ubuntu 20.04 LTS with the configuration: ./configure --enable-ecc --enable-eccencrypt --enable-hkdf but still getting the same error.
Hi @Chandranshu9 ,
The fix I made in https://github.com/wolfSSL/wolfssl/pull/3711 is not in v4.6.0. It is in v4.7.0.
You can build and install wolf manually using these steps:
git clone https://github.com/wolfssl/wolfssl
cd wolfssl
./autogen.sh
./configure --enable-ecc --enable-eccencrypt --enable-hkdf
make
sudo make install
sudo ldconfig
Thanks, David Garske, wolfSSL
Thank you so much for the solution. It's working fine now.
There are two things I would want to know:
Hi @Chandranshu9 ,
That's great it is working with my PR.
You'll need wolfSSL built on all targets and use the API's for ECC encrypt/decrypt. Have you read the documentation here? https://github.com/wolfSSL/wolfssl-examples/blob/master/btle/BTLESecureMessageExchange.pdf
Measuring power usage is very specific to each board / platform. You will need to consult ESP32 for those details.
Thanks, David Garske, wolfSSL
Yes, I have read the document, but it doesn't talk about how to build this on different targets.
Let's not talk about esp32, How can I measure it on your platform? I mean your BTLE Simulator.
Hi @Chandranshu9 ,
Here are some useful guides to help with building on different targets: https://www.wolfssl.com/docs/quickstart/ https://www.wolfssl.com/docs/porting-guide/ https://www.wolfssl.com/docs/frequently-asked-questions-faq/
Measuring power consumption for a simulator will not be accurate. It would need to be embedded hardware with real BTLE. Typically that is not something we can help with.
Thanks, David Garske, wolfSSL
Hello @dgarske,
Can you tell me where exactly is the code implemented in the Bluetooth LE stack? Is it being implemented in the security manager layer?
Hi @Chandranshu9 , this example uses a simulation of BTLE. Actual implementation would require a service with characteristic channels for read/write. You might find this BTLE example useful: https://github.com/wolfSSL/wolfBoot-examples/pull/5 Thanks, David Garske, wolfSSL
Thanks for the reply, I have one doubt, How can I perform ECC encryption with the actual device while in the pairing mode? Have you made any example where you are making use of pairing mechanism?
Hi @Chandranshu9 , our customers typically disable the built-in BTLE security and avoid the BTLE pairing process and use clear text characteristics for read/write channels. Those channels either use TLS v1.3 or the ECC encrypt scheme demonstrated in this example.
I understand that the pairing method can be avoided, but what exactly do you mean by "characteristic channels for read/write"? Are you referring GATT services and characteristics? If yes, then you are encrypting the GATT profile using ECC or TLS, right?
Hi @Chandranshu9 ,
Yes that is correct... A GATT service with two characteristics. This allows separate characteristic channels for data read/write. The data exchanged over those is what gets encrypted prior to going over the air. The goal is to use BTLE for a bi-directional pipe instead of a typical socket. Most customers also add a small header for packet information to allow for packet reassembly, since the payload is usually small ~21 bytes per packet.
Thanks, David Garske, wolfSSL
Thank you for the response. Since I don't have any further doubts, I will be closing this issue.