Toit
#BLE Just Works Encrypted Pairing and Bonding
Thread channel in help
z3ugma 05/01/2024 08:43 PMLearn about how Paring and Bonding with Bluetooth while also taking into account, security implications of these procedures.
Do you know if ble central.connect can handle the encryption bits from Just Works bonding?
https://technotes.kynetics.com/2018/BLE_Pairing_and_bonding/#:~:text=in%20BLE%20legacy-,Pairing%20methods%3A,nonce%20to%20the%20initiating%20device
I have this information from the user manual of my peripheral of interest:
6.2.2 Pairing/Bonding
After connection, the collector should initiate pairing with the PERIPHERAL BLE. The PERIPHERAL BLE uses the Just Works pairing method with bonding support. Upon successful pairing, the collector should initiate bonding, and the PERIPHERAL BLE will save the long term bonding key associated with the collector. The PERIPHERAL BLE requires the collector to be bonded in order to encrypt the connection. When bonding is complete, the collector should encrypt the connection.
If the PERIPHERAL BLE detects that the connection remains unencrypted after four seconds, it will send a slave security request to the collector. The collector should accept the request which will trigger the pairing or encryption sequence. If the connection remains unencrypted four seconds after the PERIPHERAL BLE sends the slave security request, the connection will be considered insecure and the PERIPHERAL BLE will close the connection.
After the collector is bonded with the PERIPHERAL BLE, the collector should encrypt subsequent connections immediately.
If the encryption process fails, it is likely that either the collector or PERIPHERAL BLE has deleted its bond key. When this occurs, the PERIPHERAL BLE will delete its bond key if present. It is recommended that the collector also delete its bond key if present. The subsequent connection will trigger the pairing process, a new bond will be created, and the collector will be able to encrypt the connection.
Note: The PERIPHERAL BLE’s default security mode places further restrictions on bonding. See 6.3.1.3.2 for more information.
https://technotes.kynetics.com/2018/BLE_Pairing_and_bonding/#:~:text=in%20BLE%20legacy-,Pairing%20methods%3A,nonce%20to%20the%20initiating%20device
I have this information from the user manual of my peripheral of interest:
6.2.2 Pairing/Bonding
After connection, the collector should initiate pairing with the PERIPHERAL BLE. The PERIPHERAL BLE uses the Just Works pairing method with bonding support. Upon successful pairing, the collector should initiate bonding, and the PERIPHERAL BLE will save the long term bonding key associated with the collector. The PERIPHERAL BLE requires the collector to be bonded in order to encrypt the connection. When bonding is complete, the collector should encrypt the connection.
If the PERIPHERAL BLE detects that the connection remains unencrypted after four seconds, it will send a slave security request to the collector. The collector should accept the request which will trigger the pairing or encryption sequence. If the connection remains unencrypted four seconds after the PERIPHERAL BLE sends the slave security request, the connection will be considered insecure and the PERIPHERAL BLE will close the connection.
After the collector is bonded with the PERIPHERAL BLE, the collector should encrypt subsequent connections immediately.
If the encryption process fails, it is likely that either the collector or PERIPHERAL BLE has deleted its bond key. When this occurs, the PERIPHERAL BLE will delete its bond key if present. It is recommended that the collector also delete its bond key if present. The subsequent connection will trigger the pairing process, a new bond will be created, and the collector will be able to encrypt the connection.
Note: The PERIPHERAL BLE’s default security mode places further restrictions on bonding. See 6.3.1.3.2 for more information.
floitsch 05/01/2024 08:44 PM
1
I will have a look at it tomorrow.
I'm working on BLE right now anyway.
I'm working on BLE right now anyway.
1z3ugma 05/01/2024 08:45 PM
thanks, Florian. you're very helpful in all this!
z3ugma 05/01/2024 08:45 PM
1
thanks for the PR for handles
1z3ugma 05/01/2024 08:47 PM
Current behavior is that when I do
then it just hangs on
adapter := ble.Adapter
central := adapter.central
address := find_by_name central DEV_NAME
remote_device := central.connect addressthen it just hangs on
connectz3ugma 05/01/2024 08:48 PM
FWIW the same behavior when I attempt to connect using nRFConnect iOS app connecting to the device
floitsch 05/01/2024 08:49 PM
I have in my to-do list to add a timeout to connecting. Even for non-encrypted devices it sometimes fails without any event from the lower layer.
z3ugma 05/01/2024 08:50 PM
yeah I've been using
with_timeoutfloitsch 05/01/2024 08:51 PM
I will look at the code tomorrow, but what happens if you use
connect --securefloitsch 05/01/2024 08:51 PM
Maybe that already uses "just works"
z3ugma 05/01/2024 08:53 PM
same hang. it immediately finds a device matching DEV_NAME and then when it moves on to connect, hangs
floitsch 05/01/2024 08:53 PM
Ok. I will look tomorrow what it does.
z3ugma 05/01/2024 09:10 PMHello - I am excited to find this code available on Arduino. Thank you for the library. For my ESP32, I am attempting to set up a simple secure GATT BLE bonding with the "Just Works" pair... 
https://github.com/h2zero/NimBLE-Arduino/issues/588
Hello, the only thing you need to do for this is to enable bonding:
NimBLEDevice::setSecurityAuth(true, false, true);
Hello, the only thing you need to do for this is to enable bonding:
NimBLEDevice::setSecurityAuth(true, false, true);
z3ugma 05/01/2024 09:10 PM
^^ breadcrumb from NimBLE
floitsch 05/01/2024 09:11 PM
Hehe. I sent the same link to my work email a few minutes ago.
floitsch 05/01/2024 09:12 PM
I think that's what the
--securez3ugma 05/01/2024 09:12 PM
that might be when the ESP32 is acting as the server, not the client
floitsch 05/01/2024 09:14 PM
Hmm. Didn't find any reference to
setSecurityAuthz3ugma 05/01/2024 09:15 PM
another link I'm exploring https://lpccs-docs.renesas.com/Tutorial-DA145x-BLE-Security/ble_security_example_secure_connections.html
floitsch 05/01/2024 09:18 PMProgram your microcontrollers in a fast and robust high-level language. - toitlang/toit 
floitsch 05/01/2024 09:19 PM
The way it's currently implemented: when we get the MTU event and we want a secure connection we
ble_gap_security_exchangez3ugma 05/01/2024 09:19 PM
okay, I think I've got it. The is what was needed. Additionally, my device has a 2-minute window exactly after inserting the batteries that it will attempt new connections
--securefloitsch 05/01/2024 09:20 PM
Nice.
floitsch 05/01/2024 09:20 PM
So that sounds like
I will add documentation
--secureI will add documentation
z3ugma 05/01/2024 09:35 PM
ok, maybe not.
I get /
I get /
z3ugma 05/01/2024 09:35 PM
EXCEPTION error.
Encryption is insufficient.
Encryption is insufficient.
floitsch 05/01/2024 09:37 PMToit package for provisioning. Contribute to toitware/toit-provision development by creating an account on GitHub. 
Have a look here: https://github.com/toitware/toit-provision
floitsch 05/01/2024 09:37 PM
It is using some encryption between the esp and the android app.
z3ugma 05/01/2024 09:38 PM
floitsch 05/01/2024 09:38 PM
I don't know (yet) if their approach is standard or just something that works with their app, but hopefully worth a look.
31 messages in total