0

I am developing a Win32 application for a Windows 10 tablet that shall connect to a embedded device via Bluetooth. The embedded device uses the Telit BlueMod+SR as bluetooth module. In Windows, I use the interface from "bluetoothapis.h" for Connection and Pairing and winsock2 for communication.

I have to implement pairing using passkey entry between the devices, initiated by the Windows tablet. The tablet provides passkey entry, the embedded device is display-only.

The way it works at the moment is that:

  1. Windows creats a non-blocking socket and configures it as requiring authentication by setting SO_BTH_AUTHENTICATE.
  2. Windows passes my Authentication Callback to BluetoothRegisterForAuthenticationEx().
  3. Windows calls ConnectEx() on the remote BT device.
  4. If successful, the Authentication Callback is executed, giving me the passkey (which is displayed by the embedded device).
  5. The user is asked to input the passkey on the tablet which then compares the input with the passkey from the Authentication callback.

My problem is, although it works, I think that this is not the way the passkey entry is intended. It doesn't feel like a valid way to establish a secure connection since the embedded device seems to transmit the passkey via Bluetooth to the tablet.

Should the passkey be openly transmitted via Bluetooth from the remote device to the initiating device? Or should the user be the only one that gives the passkey to the tablet?

If the way it is implemented is wrong: Does somebody have an idea why the passkey is available through the Authentication Callback on Windows? I guess there is something wrong with the configuration of the BlueMod module, but I haven't been able to change the behavior.

ben
  • 1
  • Bluetooth has security strategies like secure connections(AES-CCM encryption) etc. you can enable. For example you can select an [authentication requirement](https://learn.microsoft.com/en-us/windows/win32/api/bluetoothapis/ne-bluetoothapis-bluetooth_authentication_method) against a "Man in the Middle" attack. You can see the passkey through the Authentication Callback because you (your Windows 10 tablet) are the one can decrypt the data. – Rita Han Jun 30 '20 at 02:28
  • @RitaHan-MSFT thanks for the answer. As I understood it, the communication will be encrypted using a key that is calculated BASED ON the passkey. And that's why you have to keep the passkey secret to prevent MITM attacks so no attacker can reproduce this calculation. I thought the whole point of passkey-entry is that the user himself reads the passkey from device A and enters it at device B - so no passkey will be transmitted via Bluetooth... Am I wrong? – ben Jun 30 '20 at 07:03
  • *user himself reads the passkey from device A and enters it at device B - so no passkey will be transmitted via Bluetooth* At this time how does device B know if the passkey is correct or not? – Rita Han Jul 01 '20 at 08:29
  • I think device B doesn't have to know if it's correct - I could just transmit the entered passkey to device A and see if device A accepts the connection attempt. That way you can only establish a connection if you've entered the correct passkey - which is the goal of the whole procedure, isn't it? – ben Jul 02 '20 at 06:31
  • From Bluetooth core specification version 5.2, Authentication stage 1: Passkey Entry protocol: *"each side commits to each bit of the Passkey, using a long nonce(128 bits), and sending the hash of the nonce, the bit of the Passkey, and both public keys to the other party. The parties then take turns revealing their commitments until the entire Passkey has been mutually disclosed...This "gradual disclosure" prevents leakage of more than 1 bit of un-guessed Passkey information in the case of a MITM attack...."* It is already deep in protocol implement / drivers. Hope this information helps. – Rita Han Jul 02 '20 at 07:30
  • Oh ok, the thing with the bit-wise exchange is total news to me. But I guess that answers my question. Thank you very much! – ben Jul 02 '20 at 07:52

0 Answers0