Failing to reconnect to a paired, JUST_WORKS BLE device

[MrOneTwo]

I'm having trouble reconnecting to a already paired device. I'm using JUST_WORKS for smp->method.
I'm suspicious about this part in the bt_smp_update_keys:

	/*
	 * store key type deducted from pairing method used
	 * it is important to store it since type is used to determine
	 * security level upon encryption
	 */
	switch (smp->method) {
	case PASSKEY_DISPLAY:
	case PASSKEY_INPUT:
	case PASSKEY_CONFIRM:
	case LE_SC_OOB:
	case LEGACY_OOB:
		conn->le.keys->flags |= BT_KEYS_AUTHENTICATED;
		break;
	case JUST_WORKS:
	default:
		/* unauthenticated key, clear it */
		conn->le.keys->flags &= ~BT_KEYS_AUTHENTICATED;
		break;
	}

This treats JUST_WORKS differently. Actually setting that flag for JUST_WORKS, instead of clearing it, allows reconnecting to the device.

I got here because of the smp_pairing_req which always returns BT_SMP_ERR_AUTH_REQUIREMENTS, when reconnecting, after running update_keys_check.

The smp_pairing_req actually handles smp->method == JUST_WORKS at its bottom, but it never gets there because for JUST_WORKS the BT_KEYS_AUTHENTICATED is always cleared. update_keys_check return BT_SMP_ERR_AUTH_REQUIREMENTS and smp_pairing_req returns early.

Is this a bug? Am I doing something wrong?

[joerchan]

It is intentional, just works is not authenticated, and we don't allow bond overwrites without authentication.
You can disable this behavior, but make sure you understand what you are actually doing and if you are OK with doing that.
Otherwise I would try to find out why you are trying to overwrite the bond, when you should be able to use the existing bond.

config BT_SMP_ALLOW_UNAUTH_OVERWRITE
	bool "Allow unauthenticated pairing for paired device"
	help
	  This option allows all unauthenticated pairing attempts made by the
	  peer where an unauthenticated bond already exists.
	  This would enable cases where an attacker could copy the peer device
	  address to connect and start an unauthenticated pairing procedure
	  to replace the existing bond. When this option is disabled in order
	  to create a new bond the old bond has to be explicitly deleted with
	  bt_unpair.

[MrOneTwo]

@joerchan I tried this option. This made it so I had to pair (press Pair button on iPhone) each time I tried to reconnect to a peripheral device. Is that the intended behavior?

[joerchan]

I would suggest you try to use an authentication method, maybe the phone will use the bond then.
Set the security callbacks, there are samples that demonstrate this.

[MrOneTwo]

Do you mean not using the JUST WORKS? Like a PIN number? I have tried it and it works fine but I want to build a device which can't display the PIN number. Currently I'm reading it via the RTT shell. I want to be able to pair a device the same way you pair a BLE speaker or a keyboard.

[MrOneTwo]

Or do you mean setting pairing_accept and auth_pairing_complete with BT_SMP_ALLOW_UNAUTH_OVERWRITE?

[joerchan]

The problem you are having is that the phone is starting the pairing procedure when the peripheral has bond information for the phone.
We don't allow this when the bond information is unauthenticated, that means just works.

I would expect the phone to keep the bond information from the first pairing procedure, and then start encryption instead of pairing when reconnecting.
I don't know why the phone starts the pairing procedure.
Maybe you deleted the bond?
Maybe the phone deletes the bond if it is Just-works?

In any case, if you want to pair again in this situation you need to either enable BT_SMP_ALLOW_UNAUTH_OVERWRITE, or delete the bond on the peripheral side using bt_unpair. Maybe from a button press on the peripheral.

The other case would be to add an authentication method, PIN input, NFC (oob), PIN comparison (numerical comparison).

[MrOneTwo]

Ok I need to understand this situation a bit more. When pairing with a Linux PC it works better. Maybe there is something specific about iOS.

Anyways your explanation helps a ton, thank you. I'll keep this discussion alive for now and keep on working to understand what's going on.

[MrOneTwo]

Things I didn't know before I started investigating it: I'm using Secure Connection pairing here.

Ok so after some investigation and a lot of help, we established that the problem is with iOS accessing the CCCD characteristic.

> ACL Data RX: Handle 0 flags 0x02 dlen 9                                     #194 [hci0] 12.518916
      ATT: Write Request (0x12) len 4
        Handle: 0x0022
          Data: 0100
< ACL Data TX: Handle 0 flags 0x00 dlen 9                                     #195 [hci0] 12.519016
      ATT: Error Response (0x01) len 4
        Write Request (0x12)
        Handle: 0x0022
        Error: Insufficient Authentication (0x05)

The iPhone attempts to write to a characteristic (looks like it's a subscription to a CCCD), and Zephyr responds with insufficient authentication (on the second connection). That results with iPhone creating a new bond every time.

The workaround is to change this:

    BT_GATT_CCC(input_ccc_changed,
            BT_GATT_PERM_READ_AUTHEN | BT_GATT_PERM_WRITE_AUTHEN),

into

    BT_GATT_CCC(input_ccc_changed,
            BT_GATT_PERM_READ_AUTHEN | BT_GATT_PERM_WRITE_ENCRYPT),

That lowers the write access to CCCD to security lvl 2. After that iPhone should be able to restore connection.