Pairing without entering the PIN

RE: Pairing without entering the PIN

greeneyehawk — Wed, 12 Jan 2022 23:31:31 GMT

Hi Susheel,

I'm having a similar problem using an nRF52840-DK (with Zephyr). I'd like to operate the board as a peripheral which requires a passkey for pairing. Using two different scanner apps on Android, I'm able to see all the characteristics in the services offered before entering the pin. I've tried following the modifications in this thread, but I still can't get hidden characteristics. Would you be able to help me?

Best,

RE: Pairing without entering the PIN

Matej Kupljen — Thu, 22 Apr 2021 06:21:47 GMT

Hi Susheel,

thank you for this.
I tried what you suggested (modified the code for NUS in ncs/nrf/subsys/bluetooth/services/nus.c) and added disconnect call if failing fails.

Now, even if I manage to click on NUS service in the APP, I cannot send any data to it.

It is working as expected now.

Thanks again and BR,
Matej

RE: Pairing without entering the PIN

Susheel Nuguru — Tue, 20 Apr 2021 11:06:28 GMT

Matej,

I have missed to see this basic point about service declaration

A service declaration is an Attribute with the Attribute Type set to the UUID for
«Primary Service» or «Secondary Service». The Attribute Value shall be the
16-bit Bluetooth UUID or 128-bit UUID for the service, known as the service
UUID. A client shall support the use of both 16-bit and 128-bit UUIDs. A client
may ignore any service definition with an unknown service UUID. An unknown
service UUID is a UUID for an unsupported service. The Attribute Permissions
shall be read-only and shall not require authentication or authorization.

The service will always have read permission only and the IOS can discover them even before encryption. It is the central/phone that initiates the service discovery and your product being a slave cannot control this. It need to respond to the service discovery by showing the services but not the contents of it.

I have changed the declaration of the attributes so that the values can be read only after encryption.

/* UART Service Declaration */
BT_GATT_SERVICE_DEFINE(nus_svc,
BT_GATT_PRIMARY_SERVICE(BT_UUID_NUS_SERVICE),
	BT_GATT_CHARACTERISTIC(BT_UUID_NUS_TX,
			       BT_GATT_CHRC_NOTIFY,
			       BT_GATT_PERM_READ_ENCRYPT,
			       NULL, NULL, NULL),
	BT_GATT_CCC(NULL, BT_GATT_PERM_READ_ENCRYPT | BT_GATT_PERM_READ_AUTHEN | BT_GATT_PERM_WRITE_AUTHEN),
	BT_GATT_CHARACTERISTIC(BT_UUID_NUS_RX,
			       BT_GATT_CHRC_WRITE |
			       BT_GATT_CHRC_WRITE_WITHOUT_RESP,
			       BT_GATT_PERM_READ_ENCRYPT | BT_GATT_PERM_WRITE_ENCRYPT,
			       NULL, on_receive, NULL),
);

Also if the connection fails, disconnect as below in ae_bt_conn.c

static void pairing_failed(struct bt_conn *conn, enum bt_security_err reason)
{
  char addr[BT_ADDR_LE_STR_LEN];

  bt_addr_le_to_str(bt_conn_get_dst(conn), addr, sizeof(addr));

  LOG_INF("Pairing failed and hence disconnecting conn: %s, reason %d", log_strdup(addr),
      reason);
  
  bt_conn_disconnect(conn, BT_HCI_ERR_AUTH_FAIL);
}

RE: Pairing without entering the PIN

Susheel Nuguru — Mon, 19 Apr 2021 06:54:20 GMT

Hi,

Thank you for attaching that. I will try to modify the project so that the pairing happens before discovery.

RE: Pairing without entering the PIN

Matej Kupljen — Wed, 14 Apr 2021 15:00:03 GMT

I have removed all not necessary stuff from the project and just left two source files in it.
I have uploaded it here.

If you can have a look and tell us what we need to change so one cannot discover (or send anything) to device if paring is not completed successfully we'd appreciate it.

Thnaks,
Matej

RE: Pairing without entering the PIN

Susheel Nuguru — Tue, 13 Apr 2021 13:13:56 GMT

[quote user="Matej Kupljen"]Probably we need to advertise only dive name in the beginning and only after the paring is done, we should advertise all the services?[/quote]

Yes, This is normally the case when you do not want anyone to view or discover your services on an unencrypted link. The change for this is trivial, that you just need to move the pairing initiate process just after the connection is established.

RE: Pairing without entering the PIN

Matej Kupljen — Tue, 13 Apr 2021 12:22:02 GMT

Hi,

thank you, glad that you were able to reproduce this.

So for you suggestions mentioned above:
1) If you find a configuration option, that would be great
2) If there is an example how to achieve this already in some sample code, than I can check this and fix it. Otherwise, I'll try to make a simple project as possible that will expose this behavior (need to remove some custom files) and will send it to you. But, if there is already available example, I'd prefer that.
Probably we need to advertise only dive name in the beginning and only after the paring is done, we should advertise all the services?

Thanks and BR,
Matej

RE: Pairing without entering the PIN

Susheel Nuguru — Fri, 09 Apr 2021 11:54:59 GMT

I am able to reproduce this. I think the issue here are two things

1) The connection is not disconnected even after pairing failure. Must a simple configurable thing, i should look what configuration needs to be changed here.

2) Pairing is started after discovery is initiated, so even when pairing is failed, the phone has the connection ongoing and you can see the discovered services (which happened on unencrypted link)

You can change the code a bit to start pairing before discovery procedure is started, so that discovery will only be done on the encrypted link and also to disconnect if pairing failed.

If you can attach your project you ported for nRF52833 (the project you used to make those elf and hex file) I can try to make the changes for you and upload here.

RE: Pairing without entering the PIN

Susheel Nuguru — Thu, 08 Apr 2021 07:16:25 GMT

sorry about the late reply, we were very thinly staffed here during Easter and now recovering from it. I will test you elf and hex today

RE: Pairing without entering the PIN

Matej Kupljen — Wed, 31 Mar 2021 10:00:43 GMT

I have build our application for nrf52833dk (using Segger Embedded Studio and selected nrf52833dk_nrf528333 under board name) and I uploaded the elf and hex file here.

Please let us know if this is O.K. with you and you can reproduce the test.

Thanks;
Matej

RE: Pairing without entering the PIN

Susheel Nuguru — Fri, 26 Mar 2021 11:59:11 GMT

[quote user="Matej Kupljen"]I saw that it actually detected two devices with the same MAC and different name:[/quote][quote user="Matej Kupljen"]Could this be a problem?[/quote]

Yes, this seems to be the issue, that the wireshark is somehow locking to the other device with the same MAC address-

[quote user="Matej Kupljen"]What we can also do is that I build the application for your board, please tell me which one, and I can send you the HEX file and you can try it out yourself. What do you think about this idea?[/quote]

That would be great, If you an build it for PCA10056 or PCA10040 and give me the HEX and ELF files so that i can debug, it would be easier for me to test

RE: Pairing without entering the PIN

Matej Kupljen — Thu, 25 Mar 2021 08:57:31 GMT

I checked both pcap files I uploaded and you are right, I do not see any other packets then ADV_IND, SCAN_REQ, SCAN_RESP and 1 (one!) CONNECT_REQ. No data packets.

If I set up everything like described in the nRFSniffer document on Linux, using it from wireshark doesn't capture ANY packet, nothing. Only from command line.

I installed everything (Wireshark, Python, nRFSniffer, ...) on my Windows 10 machine and tried to do a capture there. Now it works O.K. from wireshark, however, I only see those packets mentioned above. Not sure why I don't get any other packets.

One thing I noticed is while testing BT on Linux and did a BT LE scan. I saw that it actually detected two devices with the same MAC and different name:

E3:41:0F:BF:6C:61 Pair Test
E3:41:0F:BF:6C:61 (unknown)
E3:41:0F:BF:6C:61 Pair Test
E3:41:0F:BF:6C:61 (unknown)

Could this be a problem?

I did a screen record of the problem I am trying to explain and I uploaded it here.

What we can also do is that I build the application for your board, please tell me which one, and I can send you the HEX file and you can try it out yourself. What do you think about this idea?

Thanks and BR,
Matej

RE: Pairing without entering the PIN

Susheel Nuguru — Mon, 22 Mar 2021 07:05:17 GMT

I am not so familiar with the command line capture way for the wireshark. Have you tried to open the attachment you did here to see if you can see any transactions that you are referring to? I can only see broadcast capture from couple of devices and no connect or pairing transactions at all. Can you use the wireshark directly to filter the traffic just to your device.

RE: Pairing without entering the PIN

Matej Kupljen — Wed, 17 Mar 2021 12:05:40 GMT

Hi Susheel,

I did a capture again, with the following command:

./nrf_sniffer_ble.sh --capture --fifo capture/ble_cap_2.pcap --extcap-interface /dev/ttyACM1 --baudrate 460800

so no filter was included, If you want me to use different command, please let me know.
I just managed to reproduce this again, so:
1. Clean the entire FLASH
2. Program the device
3. Turn it on
4. Use the phone to connect to it
5. When the paring dialog appears, click cancel and quickly click in NUS TX Chractericistic (UUID 0x2902)
6. Now I can NUS RX Characteristic to send the data to my device

I my application I use NUS and BT update options.

The file is uploaded here.

If you need me to do anything else, or to change the capture option, please let me know.

Thanks,
Matej

RE: Pairing without entering the PIN

Susheel Nuguru — Wed, 17 Mar 2021 07:24:30 GMT

Hi Matej,

I changed the file you attached ble_cap_2 -> ble_cap_2.pcap and i do not see any other activity in the sniffer trace other than just broadcast. This does not look like the activity you mentioned regarding pairing is not captured by this sniffer trace. You need to add filter so that the wireshark only captures the devide you are following.

RE: Pairing without entering the PIN

Susheel Nuguru — Wed, 17 Mar 2021 07:04:54 GMT

sorry for the late reply. I was away few days and have downloaded the files just now. I will take a look at them today and will comeback to you with my observations. Thanks a lot for your patience.

RE: Pairing without entering the PIN

Matej Kupljen — Wed, 03 Mar 2021 11:01:04 GMT

Hi,

sorry for this late reply, but we needed to order nRF52840 dongles and we needed to wait for them to come to the office.
Today I have connected everything, erased the whole Flash in my device and programmed the test application.
Connected the sniffer and captured the traffic. File can be downloaded from here (please note, it will expire in 15 days! Could not find an option to attach the file to this post.)

I tested the application again and I was able to connect to the device without paring.
Like I said, when the pairing dialog appears (the services are already listed in the application) and if I quickly click cancel and send some that over UART service, I can stay connected without the pairng.

If you need anything else, please let us know.

BR,
Matej

RE: Pairing without entering the PIN

Simonr — Tue, 16 Feb 2021 07:04:26 GMT

Susheel is currently out of office, so I have been assigned this case until he's back. What he requests in his first reply is a Sniffer trace, either using an Sniffer tool like the Ellisys sniffer or similar, or our nRFSniffer which lets you use an nRF52 DK or Dongle to see what exactly is going on over the air. This way we should be able to see what exactly happens when you're able to "bypass" the pairing and discover services without doing this process.

Best regards,

Simon

RE: Pairing without entering the PIN

Matej Kupljen — Thu, 11 Feb 2021 16:02:39 GMT

Hi Susheel,

thanks for replying.
One thing that I remembered now is that I use fixed pass key. I just change the configuration that it doesn't use this and the result is the same.

This is the Log I get trough Segger RTT on the BT module:

[00:00:01.838,012] [0m<inf> fs_nvs: 6 Sectors of 4096 bytes[0m
[00:00:01.838,012] [0m<inf> fs_nvs: alloc wra: 0, ff0[0m
[00:00:01.838,012] [0m<inf> fs_nvs: data wra: 0, 0[0m
[00:00:01.838,165] [0m<inf> sdc_hci_driver: SoftDevice Controller build revision: 
cf 5c 0f 11 88 9c d7 02  15 27 c7 c3 ca 60 19 85 |.\...... .'...`..
b7 c4 50 e3                                      |..P.             [0m
[00:00:01.840,911] [0m<inf> bt_hci_core: HW Platform: Nordic Semiconductor (0x0002)[0m
[00:00:01.840,911] [0m<inf> bt_hci_core: HW Variant: nRF52x (0x0002)[0m
[00:00:01.840,911] [0m<inf> bt_hci_core: Firmware: Standard Bluetooth controller (0x00) Version 207.3932 Build 3617359889[0m
[00:00:01.841,247] [0m<inf> bt_hci_core: No ID address. App must call settings_load()[0m
[00:00:01.841,735] [0m<inf> bt_hci_core: Identity: e3:41:0f:bf:6c:61 (random)[0m
[00:00:01.841,766] [0m<inf> bt_hci_core: HCI: version 5.2 (0x0b) revision 0x1123, manufacturer 0x0059[0m
[00:00:01.841,766] [0m<inf> bt_hci_core: LMP: version 5.2 (0x0b) subver 0x1123[0m
[00:00:17.054,870] [0m<inf> app: Connected 4f:5d:b5:e3:b0:5c (random)[0m
[00:00:20.888,214] [1;31m<err> bt_smp: reason 0x9[0m
[00:00:20.888,458] [1;33m<wrn> app: Security failed: 4f:5d:b5:e3:b0:5c (random) level 1 err 6[0m
[00:00:20.888,519] [0m<inf> app: Pairing failed conn: 4f:5d:b5:e3:b0:5c (random), reason 6[0m
[00:00:23.948,974] [0m<inf> app: Disconnected: 4f:5d:b5:e3:b0:5c (random) (reason 19)[0m
[00:00:47.425,659] [0m<inf> app: Connected 47:5e:85:20:f9:9f (random)[0m
[00:01:20.470,092] [0m<inf> app: Disconnected: 47:5e:85:20:f9:9f (random) (reason 19)[0m
[00:01:25.293,395] [0m<inf> app: Connected 47:5e:85:20:f9:9f (random)[0m
[00:01:30.504,821] [1;31m<err> bt_smp: reason 0x9[0m
[00:01:30.505,065] [1;33m<wrn> app: Security failed: 47:5e:85:20:f9:9f (random) level 1 err 6[0m
[00:01:30.505,126] [0m<inf> app: Pairing failed conn: 47:5e:85:20:f9:9f (random), reason 6[0m
[00:01:33.430,267] [0m<inf> app: Disconnected: 47:5e:85:20:f9:9f (random) (reason 19)[0m
[00:01:39.410,064] [0m<inf> app: Connected 47:5e:85:20:f9:9f (random)[0m
[00:01:42.430,114] [1;31m<err> bt_smp: reason 0x9[0m
[00:01:42.430,358] [1;33m<wrn> app: Security failed: 47:5e:85:20:f9:9f (random) level 1 err 6[0m
[00:01:42.430,419] [0m<inf> app: Pairing failed conn: 47:5e:85:20:f9:9f (random), reason 6[0m
[00:01:45.400,543] [0m<inf> app: Disconnected: 47:5e:85:20:f9:9f (random) (reason 19)[0m
[00:01:54.693,176] [0m<inf> app: Connected 47:5e:85:20:f9:9f (random)[0m
[00:01:57.415,527] [1;31m<err> bt_smp: reason 0x9[0m
[00:01:57.415,771] [1;33m<wrn> app: Security failed: 47:5e:85:20:f9:9f (random) level 1 err 6[0m
[00:01:57.415,863] [0m<inf> app: Pairing failed conn: 47:5e:85:20:f9:9f (random), reason 6[0m
[00:03:41.548,126] [0m<inf> app: Received data from: 47:5e:85:20:f9:9f (random)[0m

And this it the log from nRF Connect on the phone:

nRF Connect, 2021-02-11
Inosmart Door Lock (E3:41:0F:BF:6C:61)
I	16:51:46.493	[Server] Server started
V	16:51:46.502	Heart Rate (0x180D)
- Heart Rate Measurement [N] (0x2A37)
   Client Characteristic Configuration (0x2902)
- Body Sensor Location [R] (0x2A38)
- Heart Rate Control Point [W] (0x2A39)
Unknown Service (0000aaa0-0000-1000-8000-aabbccddeeff)
- Unknown Characteristic [N R] (0000aaa1-0000-1000-8000-aabbccddeeff)
   Client Characteristic Configuration (0x2902)
   Unknown Descriptor (0000aab0-0000-1000-8000-aabbccddeeff)
   Characteristic User Description (0x2901)
   Characteristic Presentation Format (0x2904)
- Unknown Characteristic [I W WNR] (0000aaa2-0000-1000-8000-aabbccddeeff)
   Client Characteristic Configuration (0x2902)
User Data (0x181C)
- First Name [R W] (0x2A8A)
- Last Name [R W] (0x2A90)
- Gender [R W] (0x2A8C)
V	16:51:46.741	Connecting to E3:41:0F:BF:6C:61...
D	16:51:46.741	gatt = device.connectGatt(autoConnect = false, TRANSPORT_LE, preferred PHY = LE 1M)
D	16:51:46.787	[Server callback] Connection state changed with status: 0 and new state: CONNECTED (2)
I	16:51:46.787	[Server] Device with address E3:41:0F:BF:6C:61 connected
D	16:51:46.796	[Callback] Connection state changed with status: 0 and new state: CONNECTED (2)
I	16:51:46.796	Connected to E3:41:0F:BF:6C:61
D	16:51:46.834	[Broadcast] Action received: android.bluetooth.device.action.ACL_CONNECTED
D	16:51:46.875	[Broadcast] Action received: android.bluetooth.device.action.BOND_STATE_CHANGED, bond state changed to: BOND_BONDING (11)
D	16:51:46.878	[Broadcast] Action received: android.bluetooth.device.action.PAIRING_REQUEST, pairing variant: PAIRING_VARIANT_CONSENT (3)
I	16:51:47.460	Connection parameters updated (interval: 7.5ms, latency: 0, timeout: 5000ms)
I	16:51:47.776	Connection parameters updated (interval: 45.0ms, latency: 0, timeout: 5000ms)
D	16:51:49.404	[Broadcast] Action received: android.bluetooth.device.action.BOND_STATE_CHANGED, bond state changed to: BOND_NONE (10)
I	16:51:49.404	Bonding failed
V	16:51:49.439	Discovering services...
D	16:51:49.439	gatt.discoverServices()
D	16:51:49.452	[Callback] Services discovered with status: 0
I	16:51:49.452	Services discovered
V	16:51:49.458	Generic Attribute (0x1801)
- Service Changed [I] (0x2A05)
   Client Characteristic Configuration (0x2902)
- Client Supported Features [R W] (0x2B29)
- Database Hash [R] (0x2B2A)
Generic Access (0x1800)
- Device Name [R] (0x2A00)
- Appearance [R] (0x2A01)
- Peripheral Preferred Connection Parameters [R] (0x2A04)
Nordic UART Service (6e400001-b5a3-f393-e0a9-e50e24dcca9e)
- TX Characteristic [N] (6e400003-b5a3-f393-e0a9-e50e24dcca9e)
   Client Characteristic Configuration (0x2902)
- RX Characteristic [W WNR] (6e400002-b5a3-f393-e0a9-e50e24dcca9e)
D	16:51:49.458	gatt.setCharacteristicNotification(00002a05-0000-1000-8000-00805f9b34fb, true)
D	16:51:49.459	gatt.setCharacteristicNotification(6e400003-b5a3-f393-e0a9-e50e24dcca9e, true)
V	16:51:52.053	Reading characteristic 00002a01-0000-1000-8000-00805f9b34fb
D	16:51:52.053	gatt.readCharacteristic(00002a01-0000-1000-8000-00805f9b34fb)
I	16:51:52.188	Read Response received from 00002a01-0000-1000-8000-00805f9b34fb, value: (0x) 41-03
A	16:51:52.188	"[833] Heart Rate Sensor: Heart Rate Belt (Heart Rate Sensor subtype)" received
I	16:51:52.999	Connection parameters updated (interval: 45.0ms, latency: 0, timeout: 420ms)
V	16:51:53.118	Reading characteristic 00002a01-0000-1000-8000-00805f9b34fb
D	16:51:53.118	gatt.readCharacteristic(00002a01-0000-1000-8000-00805f9b34fb)
I	16:51:53.176	Read Response received from 00002a01-0000-1000-8000-00805f9b34fb, value: (0x) 41-03
A	16:51:53.176	"[833] Heart Rate Sensor: Heart Rate Belt (Heart Rate Sensor subtype)" received
V	16:51:53.867	Reading characteristic 00002a01-0000-1000-8000-00805f9b34fb
D	16:51:53.867	gatt.readCharacteristic(00002a01-0000-1000-8000-00805f9b34fb)
I	16:51:53.942	Read Response received from 00002a01-0000-1000-8000-00805f9b34fb, value: (0x) 41-03
A	16:51:53.942	"[833] Heart Rate Sensor: Heart Rate Belt (Heart Rate Sensor subtype)" received
V	16:51:54.552	Reading characteristic 00002a01-0000-1000-8000-00805f9b34fb
D	16:51:54.552	gatt.readCharacteristic(00002a01-0000-1000-8000-00805f9b34fb)
I	16:51:54.616	Read Response received from 00002a01-0000-1000-8000-00805f9b34fb, value: (0x) 41-03
A	16:51:54.616	"[833] Heart Rate Sensor: Heart Rate Belt (Heart Rate Sensor subtype)" received
V	16:51:55.199	Reading characteristic 00002a01-0000-1000-8000-00805f9b34fb
D	16:51:55.199	gatt.readCharacteristic(00002a01-0000-1000-8000-00805f9b34fb)
I	16:51:55.292	Read Response received from 00002a01-0000-1000-8000-00805f9b34fb, value: (0x) 41-03
A	16:51:55.292	"[833] Heart Rate Sensor: Heart Rate Belt (Heart Rate Sensor subtype)" received
V	16:51:57.031	Reading characteristic 00002a04-0000-1000-8000-00805f9b34fb
D	16:51:57.031	gatt.readCharacteristic(00002a04-0000-1000-8000-00805f9b34fb)
I	16:51:57.091	Read Response received from 00002a04-0000-1000-8000-00805f9b34fb, value: (0x) 18-00-28-00-00-00-2A-00
A	16:51:57.091	"Connection Interval: 30.00ms - 50.00ms,
Slave Latency: 0,
Supervision Timeout Multiplier: 42" received
V	16:53:33.563	Writing request to characteristic 6e400002-b5a3-f393-e0a9-e50e24dcca9e
D	16:53:33.563	gatt.writeCharacteristic(6e400002-b5a3-f393-e0a9-e50e24dcca9e, value=0x74657374)
I	16:53:33.660	Data written to 6e400002-b5a3-f393-e0a9-e50e24dcca9e, value: (0x) 74-65-73-74, "test"
A	16:53:33.660	"test" sent

You can see in the log that the bonding failed, but I was still able to send that to UART service.

Did you mean any other logs?
If yes, which one and please explain if I need anything else to turn on.

Thanks,
Matej

RE: Pairing without entering the PIN

Susheel Nuguru — Thu, 11 Feb 2021 13:06:10 GMT

That does not sound secure and does not seem that the pairing has gone through either.

Can you please attach the sniffer trace of the sequence you mentioned in the description? Just want to see how the services are still being accessed without pairing being successful.