BLE-NRF51822 tutorial 9-dynamic password (pairing code)

BLE-NRF51822 tutorial 9-dynamic password (pairing code)

NordicBLE technology exchange group 498676838

This tutorial also describes how to modify the dynamic password (actually a pair code) based on the uart example in the sdk. The Uart example is in the following directory:

XXX \ Keil_v5 \ ARM \ Pack \ nordicsemicondu\ nRF_Examples \ 9.0.0 \ ble_peripheral \ ble_app_uart

Some theoretical knowledge about pairing is introduced in the static password tutorial. I will not go into details here.

Because it is a dynamic password, there is no display on the board, so the dynamic password is printed through the serial port, and then the phone is entered correctly before the pairing is successful.

Both static passwords and dynamic passwords (the matching code is also called the password) can be regarded as an authentication method in the pairing process, that is, "I am my ", this prevents others from connecting to your device to a certain extent, because they do not see the matching code displayed on the device, and you can see it on your own.

The input of the pair code is one way to generate TK during the pairing process.Passkey Entry. In additionJust WorksAndOut of BandTwo methods. TK is generated to generate another STK to encrypt the link and then distribute LTK, IRK, and CSRK. (If the pairing information exchange is not binding, the key distribution will not be needed in the future)

Since there are three options available, how does the Protocol decide which one to choose. This is related to the pairing information exchanged during pairing. We usePasskey EntryThat is, if you enter the pairing code, set OOB In the pairing information to 0 and MITM to 1, set bond to 0 (this tutorial only demonstrates that the key distribution process does not need to be followed when the pair code is entered in the pairing), and then set your I/O capability to DisplayOnly.

: For details about the methods that may be selected by a combination of different methods, refer to the detailed comparison table in the Standard Security Management Section.

According to the above description, we first need to configure the pairing information to be exchanged during pairing.

# Define IO_CAPS BLE_GAP_IO_CAPS_DISPLAY_ONLY // only display device

# Define BOND 0 // not bound

# Define OOB 0

# Define MITM 1

Then, the matching information is returned in the program.

Implement the following functions to reply to the pairing request information and pass the matching information to the other party.

Void resp_pair_request (){

Ble_gap_sec_params_t sec_params;

Uint32_t err_code;

Memset (& sec_params, 0, sizeof (ble_gap_sec_params_t ));

Sec_params.bond = BOND;

Sec_params.io_caps = IO_CAPS;

Sec_params.max_key_size = 16;

Sec_params.min_key_size = 7;

Sec_params.oob = BOND;

Sec_params.mitm = MITM;

Err_code = sd_ble_gap_sec_params_reply (m_conn_handle, BLE_GAP_SEC_STATUS_SUCCESS, & sec_params, NULL );

APP_ERROR_CHECK (err_code );

}

Add this function to the BLE_GAP_EVT_SEC_PARAMS_REQUEST Event Processing Section. In this way, when the host requests pairing, the slave can send its own pairing information to the host.

After information exchange, the device's low-layer protocol stack will automatically generate 6 random passwords (pair codes), and the pair codes will be sent to the app through the BLE_GAP_EVT_PASSKEY_DISPLAY event, then, you can print out the password in the app through the serial port.

The above two events are processed in the on_ble_evt event processing function. The red code is a processing function.

Static voidon_ble_evt (ble_evt_t * p_ble_evt)

{

Uint32_t err_code;

Switch (p_ble_evt-> header. evt_id)

{

Case BLE_GAP_EVT_CONNECTED:

Err_code = bsp_indication_set (BSP_INDICATE_CONNECTED );

APP_ERROR_CHECK (err_code );

M_conn_handle = p_ble_evt-> evt. gap_evt.conn_handle;

Break;

Case BLE_GAP_EVT_DISCONNECTED:

Err_code = bsp_indication_set (BSP_INDICATE_IDLE );

APP_ERROR_CHECK (err_code );

M_conn_handle = BLE_CONN_HANDLE_INVALID;

Break;

Case BLE_GAP_EVT_SEC_PARAMS_REQUEST:

Printf ("receive pair request \ n ");

Resp_pair_request ();

Break;

Case BLE_GAP_EVT_PASSKEY_DISPLAY:

Printf ("show passkey :")

For (int I = 0; I <6; I ++) {printf ("% c", p_ble_evt-> evt. gap_evt.params .\

Passkey_display.passkey [I]);

}

Break;

Case BLE_GATTS_EVT_SYS_ATTR_MISSING:

// No system attributes have beenstored.

Err_code = sd_ble_gatts_sys_attr_set (m_conn_handle, NULL, 0, 0 );

APP_ERROR_CHECK (err_code );

Break;

Default:

// No implementation needed.

Break;

}

}

Then add the trigger pairing code. The implementation here is very simple. It is to set the cccd write of the Rx feature value to link encryption and MITM. In this way, when the mobile phone enables ipvy without pairing, the device will reply with insufficient permissions, and then the mobile phone will send a pairing request to encrypt the pairing and link.

Modify the rx_char_add function in the ble_nus.c file.

Static uint32_trx_char_add (ble_nus_t * p_nus,

Constble_nus_init_t * p_nus_init)

{

/** @ Snippet [Adding proprietarycharacteristic to S110 SoftDevice] */

Ble_gatts_char_md_t char_md;

Ble_gatts_attr_md_t cccd_md;

Ble_gatts_attr_t attr_char_value;

Ble_uuid_t ble_uuid;

Ble_gatts_attr_md_t attr_md;

Memset (& cccd_md, 0, sizeof (cccd_md ));

BLE_GAP_CONN_SEC_MODE_SET_OPEN (& cccd_md.read_perm );

// Set permissions

BLE_GAP_CONN_SEC_MODE_SET_ENC_WITH_MITM (& cccd_md.write_perm );

// BLE_GAP_CONN_SEC_MODE_SET_OPEN (& cccd_md.write_perm );

............

............

}

After the program is installed, the matching will be triggered when the mobile phone executes the Enable Notify, and the serial port will print out the random password. After the mobile phone is entered correctly, the matching will be successful.