I have a specific application requiring legacy (PIN mode) pairing. I was told that the BC127 supported this. I’ve configured the PIN code in the system, but when pairing with the dev board, I’m never prompted for the PIN. I’ve tried all the SSP_CAPS options, which display a PIN code on the phone and expect me to enter that onto the BC127 device. How can I get the BC127 to require a matching PIN from the connecting device?
So the below is from the user guide in the pairing section, I presume you have tried this?
For Bluetooth 2.1 devices and newer Melody support different type of pairing (see SSP_CAPS configuration). By default it will accept any pairing request using the ‘JustWorks’ Bluetooth 2.1 method. This means that the module will accept any connection from Smartphones and other devices. The user of the device will not be required to enter a PIN code.
If SSP_CAPS is not set to 3, you might have to use the PASSKEY command to respond to a pairing request.
For Bluetooth 2.0 devices and older Melody will require a PIN code to accept a connection. The PIN code is set to 0000 by default, but can be reconfigured. This means that the phone user will be required to enter the pin code in order to pair successfully.
I’ve got many requests for application requiring legacy / PIN mode pairing too.
Is that possible to add an option to use SSP pairing or PIN mode pairing in the Melody API … ?
Yes you can do this, if the application you are connecting to does not want to use SPP then you can use the PASSKEY command to use a specific user defined key.
I am dealing with the exact opposite problem:
The user which want to connect to a BC127 on my embedded device has to be asked a pin code on his phone / computer which match with the internal BC127 pin code.
I do not want the user to confirm a random generated SSP key.
Currently, I set SSP_CAPS=2 I’m asked on the BC127 to respond to the PAIR_PASSKEY notification with the PASSKEY command and the key which is displayed on my phone / computer.
That’s why I need to enable Bluetooth legacy pairing.
The BC127 device in my case will not have a keyboard or display. I’ve assumed that I’d need to set SPP_CAPS to 3 to reflect this, however, I don’t want it to operate in “just works” mode.
Using my iPHone to connect, here’s what I see:
SPP_CAPS=0, 1 or 3 - iPhone displays a message "Confirm this code is displayed on " (and the phone displays a code.
SPP_CAPS=2 - iPhone displays a message “Enter this code on to pair”
The documentation mentions a “Man in the middle” (MITM) mode, but this doesn’t appear to work as described. I see the messages (PAIR_PASSKEY, etc), but there is no way for the BC127 to specify the PIN code (passkey) required. Generation of the passkey always seems to take place from the iPhone side of the “conversation”.
Again - my project would require that I can configure the BC127 device to require a specific passkey, and when the remote device attempts to connect, the user is then prompted to enter a passkey, which much match what was set on the BC127.
If you set it to 3 where there is no display or keyboard, then the unit has to set it to ‘just works’ otherwise how is it going to either send a passkey (through a keyboard input or sending a command to it via the serial interface using the PASSKEY command) or confirm a code (showing it on a display) that has been sent to the unit?
Please forgive me if I’m not understanding… I really want to get this working for my client.
What I’m seeing is that the passkey is ALWAYS being generated from the client side of the connection attempt. By that, I mean the iPhone (in my test case). However, this project should work with most any Bluetooth device - iOS, Android, PC, etc. Therefore, I don’t see a way for the installer to specify a passkey when the BC127-based device is installed with the other audio equipment.
Here’s what I’m seeing:
Sierra Wireless Copyright 2018
Melody Audio V7.3 HD
*** SEE VIDEO FROM iPHONE. NOTHING IS GENERATED HERE IN THE SERIAL CONNECTION UNTIL I CLICK “PAIR” ON THE PHONE. YOU’LL SEE THAT THE PHONE GENERATED THE PASSKEY ***
OPEN_OK 11 AVRCP DC56E796A586
OPEN_OK 10 A2DP DC56E796A586
ROLE_OK DC56E796A586 S
ABS_VOL 11 71
ABS_VOL 11 71
ABS_VOL 11 127
iPhoneVideo.zip (320.6 KB)
Here’s what I NEED to see happen:
- The installer configures the SSID name and PIN (PASSKEY) of the BC127 device upon installation. The device is installed in a location that is inaccessible to the end user.
- A user initiates a connection to the BC127 device from a phone, pc, etc.
- That user is then prompted (on THEIR device) to enter the passkey that was programmed into the BC127 device
- Upon successfully entering, the devices are paired.
This is an AUDIO application only - no data. So security is not an issue (which, I understand is a concern with LEGACY pairing.)
Agree with Tommy.
To keep it simple: I would just need to disable SSP pairing and works with PIN pairing even with Bluetooth device which have superior version than 2.1.
Is that possible to obtain such option in next Melody firmware release ?
Yes - another vote for this!
Sorry no new releases for the BC127, its super mature and we are out of memory.
With regards an example showing it working.
Sierra Wireless Copyright 2018 Melody Audio V7.3 Build: 1544637564 Ready CHARGER_DISABLED status STATE CONNECTED CONNECTABLE[ON] DISCOVERABLE[ON] BLE[IDLE] OK list OK config AUDIO=0 0 AUDIO_ANALOG=15 15 1 OFF AUDIO_DIGITAL=0 44100 64 100A00 OFF AUTOCONN=0 AUTO_DATA=OFF OFF BALANCE=100 100 BATT_CONFIG=OFF 145 4250 1500 150 BC_SMART_CONFIG=68E3 28F0 89F7 D93C BEACON_DATA=0 00 11 22 33 44 55 66 77 88 99 AA BB CC DD EE FF 04 D2 16 2E EE BLE_CONFIG=0 OFF 80 ON BLE_CONN_PARAMS=128 12 24 40 0 400 100 400 400 64 400 400 BT_STATE_CONFIG=0 0 BT_VOL_CONFIG=A 60 10 1 CLASS_1=OFF CMD_TO=20 COD=240404 CODEC=0 OFF DEEP_SLEEP=OFF DEVICE_ID=0001 0002 0003 0004 0005 0006 0007 0008 ENABLE_BATT_IND=ON ENABLE_LED=ON ENABLE_SPP_SNIFF=OFF 0 0 0 0 0 GPIO_CONFIG=ON 0 HFP_CONFIG=OFF ON OFF OFF OFF OFF HIGH_SPEED=OFF OFF LOCAL_ADDR=20FABB075D0B 4978E74505B2 MAX_REC=2 MM=OFF OFF 0 OFF OFF OFF OFF OFF MUSIC_META_DATA=OFF MUSIC_OLD_AVRCP=OFF NAME=BC-075D0B NAME_SHORT=BC075D0B PIN=0000 PROFILES=2 0 2 0 2 3 2 1 0 0 2 0 REMOTE_ADDR=000000000000 SPP_UUID=00 00 11 01 00 00 10 00 80 00 00 80 5F 9B 34 FB SSP_CAPS=3 TWS_CONFIG=OFF 1 2 UART_CONFIG=9600 OFF 0 USB_HOST=OFF VREG_ROLE=1 OK set SSP_CAPS=2 OK PAIR_PENDING //Selected the device on my phone PAIR_PASSKEY 04C23E048A70 0 PASSKEY 1 916396 //Entered the passkey that the phone was showing OK PAIR_OK 04C23E048A70 //It then paired successfully OPEN_OK 10 A2DP 04C23E048A70 ROLE_OK 04C23E048A70 S OPEN_OK 11 AVRCP 04C23E048A70 OPEN_OK 13 HFP 04C23E048A70 ROLE_OK 04C23E048A70 S CLOSE_OK 13 HFP 04C23E048A70 ROLE_OK 04C23E048A70 S
Hope that helps.
The misunderstanding that we are having revolves around this section of the trace:
The BC127 device will not have a keyboard or display. In your example, the phone is creating the passkey, which must be entered on the BT device. I need that reversed, where I configure a passkey on the BT device which is then entered on the phone. Make sense?
No don’t think you can do this, you can initiate the connection from the BC127 but not generate the code from it.
set SSP_CAPS=2 OK inquiry 5 PENDING INQUIRY 04C23E048A70 "HTC One A9" 5A020C -51dBm INQUIRY 04C23E048A70 "HTC One A9" 5A020C -53dBm INQUIRY 04C23E048A70 "HTC One A9" 5A020C -51dBm INQUIRY 04C23E048A70 "HTC One A9" 5A020C -55dBm INQUIRY 04C23E048A70 "HTC One A9" 5A020C -54dBm INQU_OK pair 04C23E048A70 //Pairing with HTC one PENDING PAIR_PENDING PAIR_PASSKEY 04C23E048A70 0 PASSKEY 1 237127 //Phone showed this code and was needed to be confirmed OK PAIR_OK 04C23E048A70
Do you have any Bluetooth module that would support the legacy pin code pairing?
No, BC127 is it, the mode you are asking for is quite old and not used that much any more in modern devices as SSP where it ‘just works’ is more secure (less human input).
I would really like to know how ‘just works’ SSP mode is more secure than a PIN pairing.
Yes PIN pairing is not the highest standard of security, but for most of the audio market it’s still better than just works’ SSP which let anyone connecting on the BC127. Other SSP mode can’t apply for our product since it has no physical interface.
A lot of clients are asking me for this security. They own the conference room, when the guest speaker is coming they would like to give them a password so that only the guest speaker can connect, just like a Wi-Fi password.
By sheer virtue of the fact that there is no human interaction, no codes are shown on screen, etc, codes are still exchanged between the two pairing devices, they are just never visible outside of them hence you are cutting a potential attack vector (as the security guys like to say) out.
There’s two “security” concepts at play here. From a data perspective, SPP is more secure (from what I understand, anyway), in that the data transferred (UART) is better encrypted and much less susceptible to snooping.
However, for an audio interface (which is what I need), encrypted “data” (audio in this case) isn’t a necessity.
That’s the issue that I’m seeing. The BT industry is “throwing the baby out with the bathwater”, making audio systems overly complex for the sake of data encryption.
Legacy PIN mode pairing does have “security”, but it’s rudimentary and easily hacked with a sniffer. But, again, this is only applicable for data - not audio.
Here’s a response that I received via email, from another BT expert. Maybe this will (sadly) help to clarify:
1.) PIN Code has been deprecated. This was in the old BT version 1.0b specification and considered broken and high security risk for man-in-the-middle attacks. Therefore no new BT product developed, end product or modules, are allowed to ship and support this. Only the older devices in the field in existence would have this feature. This was deprecated on purpose in 2007 and replaced with more secure method of passkey and confirmation of passkey via user input or display.
a. The insecure part of PIN CODE in the previous practices was that majority of devices with fixed PIN Codes were “0000” or “1234”.
2.) There are no module or product that would support since it is no longer allowed per the depraction of the specification. Bluetooth modules/products require “Bluetooth Certification” and to a minimum specification standard. To make things more complicated, I am confident that even phones/tablet/laptops with later HW/SW won’t support PIN Code method. Therefore break compatibility with smartphones later than 2010.
The good news is that Passkey method has been around for many years now and completely supported/matured by many devices.
Thanks Tommy for sharing this.
Do you know if there is any way or specification to force the passkey entry on a remote BT device with SSP ?