CC2541 default passkey change

Hello. Yes, this is possible. You should set the default passcode in the application intialization funtion (i.e. simpleBLEPeripheral_init) as such:

uint32 passkey = DEFAULT_PASSCODE;
GAPBondMgr_SetParameter( GAPBOND_DEFAULT_PASSCODE, sizeof ( uint32 ), &passkey );

There is an example of this in the glucose sensor project included with the stack.

Hi Tim,

thank you for the update but i think i was not clear enough with my problem. It does not work for me if i change the DEFAULT_PASSCODE defiinition to some desired passkey, pairing would work even if default passcodes are set to different values for the key fob and receiver device. Here are my settings of relevant parameters:

Receiver device based on SimpleBlePeripheral application:

MITM mode:                              TRUE
Bonding mode:                        TRUE
Pair mode:                                GAPBOND_PAIRING_MODE_WAIT_FOR_REQ
IO capabilities:                         GAPBOND_IO_CAP_DISPLAY_ONLY
Default passkey:                   0u //tested with different default passkey also

Key fob device based on SimpleBleCentral application:

MITM mode:                              TRUE
Bonding mode:                        TRUE
Pair mode:                                GAPBOND_PAIRING_MODE_INITIATE
IO capabilities:                         GAPBOND_IO_CAP_DISPLAY_ONLY
Default passkey:                     0u //tested with different default passkey also

What could be the reason that changing default passkeys has no effect on pairing process?

I hope you have done 'Forget this device' before trying any other option. Also, you can set the required characteristic for Authenticated Read/Write access. Thus it will ask for pairing key when the central device tries to access that characteristic.

Hi Primoz,

In order to use the MITM Passkey Pairing procedure, the initiating device (the keyfob running SimpleBLECentral) must have an IO capability that supports keyboard input. Since the keyfob/initiator only supports Display Only, the BLE protocol specifies that "Just Works" pairing is used. This is why the passkey has no effect in your example.

Refer to the Security Manager Specification in Vol 3, Part H of the BT 4.0 Core Spec for more details.

Best wishes

Hi JXS,

thank you for your update. I've read somewhere in the e2e community that "Just works" pairing is used if both devices have no IO capabilities so that is why my devices have IO capabilities set to GAPBOND_IO_CAP_DISPLAY_ONLY.  I did the following test

1. On the central device (key fob)  i set IO capabilities to GAPBOND_IO_CAP_KEYBOARD_ONLY .

2. On the peripheral device (receiver) i set the properties of the requested characteristics to Authenticated Read/Write access.

3. Devices have DIFFERENT default passwords so pairing should not be successful.

Result: Pairing is successful and i can access the requested characteristics. What can be the cause for this?

Best,

Primoz

Hi Primoz,

The actual pairing method used to generate the STK is determined by the IO capabilities as defined in "2.3.5.1 Selecting STK Generation Method" of Vol 3, Part H of the BT 4.0 Core Spec. As per Table 2.4, if the Initiator (i.e, your Central) has Keyboard Only & the Responder (Peripheral) has Display Only, then Passkey Entry shall be used. This is assuming that both devices have set the MITM option.

Can you capture a sniffer trace of the pairing procedure and attach to this thread? Use the "Insert/Edit Media" button to attach the file. The sniffer will show the IO Capability (IOCap) that each device is reporting.

Best wishes

Hi JXS ,

in my case i am also trying to make secure connection for ble device (cc2541 based), when i change passkey also the device is automatically connecting with central device ( ios app) my settings are
at peripheral side:

#define DEFAULT_PASSCODE 123456
uint32 passkey = DEFAULT_PASSCODE;
uint8 pairMode = GAPBOND_PAIRING_MODE_WAIT_FOR_REQ;
uint8 mitm = TRUE;
uint8 ioCap = GAPBOND_IO_CAP_DISPLAY_ONLY;
uint8 bonding = TRUE;

at central side i ma using lightblue app to test


can you suggest how to resolve the issue?

Hi Kadari,

Since you have set pairMode = GAPBOND_PAIRING_MODE_WAIT_FOR_REQ, the pairing process will only start once the Central initiates the pairing procedure. Typically this will happen if, for example, it attempts to read a Characteristic that requires authentication (e.g. GATT_PERMIT_AUTHEN_READ as is the case for Characteristic Value 5 of the Simple Profile).

Note that connections & security (pairing/bonding/encryption) are different concepts in BLE. A connection is always required, but it can become encrypted following pairing/bonding.

Best wishes

Hi JXS ,

Thanks for reply ... Actually we want to make a secure connection so is there any possibility to give security at connection level. we are looking this security either Peripheral side or Central side.... Please let me know if there is option like that

Hi Kadari,

No problem. In BLE the connection always starts without security, then becomes secure via Link Layer commands. If the devices are not bonded, then pairing is used to exchange the keys needed for bonding. If the devices are bonded, then encryption can start soon after connection begins.

Just because you are in a connection, and it is not secure, you can still limit or prevent data from being exchanged prior to the link becoming encrypted. This is a system design option that effectively requires encryption before you will exchange data. An example of this behavior can be seen in the HidEmuKbd project in the BLE 1.4.0 SDK.

I encourage you to review the aforementioned security section in the BT core spec for more details on BLE security.

Best wishes

Hi JXS,

i've captured a sniff trace between the key fob and receiver when pairing for the first time (no existing bonding info). Please, let me know your findings.

Best,

Primoz

first_time_pairing_bonding.psd

Hi Primoz,

According to your "first_time_pairing_bonding.psd" trace, the Master's IOCap is 0x02 (KeyboardOnly) and the Slave's IOCap is 0x00 (DisplayOnly). Since the MITM bit is set in the AuthReq byte for both devices, Passkey Pairing is used. The trace further shows the paring is successful and the link becomes encrypted with the STK. While encrypted, the LTKs are exchanged as part of the Bonding procedure.

From the trace, it can be concluded that both devices are using the same passkey. If different passkeys were used on each side, then the pairing would have failed and the link would not have been subsequently encrypted.

Best wishes