BLE-NRF51822 tutorial 5-static password settings

BLE-NRF51822 tutorial 5-static password settings

NordicBLE Contact Group 498676838

This lecture introduces some related theoretical knowledge about pairing and describes how to set a "static password ".

The program is a uart demo Based on sdk9.0

In addition, the mobile app used for testing is lightblue in IOS.

The correct statement here should be a pair code, not a password. Enter this pair code as an optional part of the pairing process.

Before introducing how to set a static password, we will first introduce the pairing knowledge (the password will be called directly later, rather than the pairing code)

If two devices that do not provide security at first want to do security work, they must be paired first. Pairing involves authentication of two devices and link encryption. If a binding BIT is set during pairing, a key is assigned later. The allocated key can be stored in flash, so that the security boot speed will be faster when two devices are re-connected for the second time. Instead of starting the entire pairing process as before.

The first process of pairing is the exchange of pairing information, which is used to determine the authentication method, as well as whether to allocate and which keys will be allocated in the future.

The information exchanged includes:

The input and output capabilities of the two devices, such as whether the display screen and keyboard are available.

Whether to bind (if bind bit pairs are set ).

Whether MITM is required or OOB is used

This information will allow the BLE protocol stack to determine an authentication method:

For example:

1: If the input and output capabilities of both devices are limited, for example, no keyboard or monitor is available, the authentication method is just work. In fact, there is no authentication,

2: If either side of the device has a display frequency and the other has a keyboard, MITM protection is set in the pairing. The authentication method is passkey entery.
One end will display a pair code, and the other needs to enter this pair code. The matching can be performed correctly.

3: If OOB is set, the pair code is sent through another communication method (such as NFC), instead of displaying one end of input as above.

The password setting is the second case. The displayed password can be random or static. Because the device does not have a monitor. However, we can still set the input and output capabilities to a display, because we use a static password.

The pairing process not only inputs the pairing code, but also generates the link key based on the entered pairing code and random numbers exchanged between the two devices to encrypt the link and allocate the subsequent long-term key, identity resolution key and other required keys

There are many matching theories. The above description is just a rough process. The pairing process is detailed in the bluetooth standard security section.

Based on the above theoretical description, let's summarize:

The "password" function we need is actually part of the pairing process. The pairing process requires the exchange of pairing information first, and the protocol stack determines whether a password is entered Based on the exchanged information.

We have to do the following steps:

1: first set the static password to be entered
2: Set the information that will be exchanged during pairing: according to the above introduction, if we need to enter a password on the mobile phone, we need to set only a display when pairing (this will be displayed at one end,
Input at one end, although we do not have a display, but it is also possible to set a static password), the setting requires MITM attack protection.

3: trigger pairing.

The following describes how to set a static password:

// First define the static password. The password can only be 6-digit ASCII string

# DefineSTATIC_PASSKEY "123456"/** <Static pin .*/

// You can set a static password in the structure.

Staticble_opt_t m_static_pin_option;

After defining these two parameters, we need to set the static password. The setting operation needs to be completed after the Protocol Stack initialization, so we put the password setting operation at the end of the GAP _params_init () function.

As follows:

Static void gap_params_init (void)

{

// Set some device names and connection parameters to be negotiated later.

// Detailed explanation is described in the serial passthrough analysis.

Uint32_t err_code;

Ble_gap_conn_params_tgap_conn_params;

Ble_gap_conn_sec_mode_t sec_mode;

BLE_GAP_CONN_SEC_MODE_SET_OPEN (& sec_mode );

Err_code = sd_ble_gap_device_name_set (& sec_mode,

(Constuint8_t * DEVICE_NAME, trlen (DEVICE_NAME ));

APP_ERROR_CHECK (err_code );

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

Gap_conn_params.min_conn_interval = MIN_CONN_INTERVAL;

Gap_conn_params.max_conn_interval = MAX_CONN_INTERVAL;

Gap_conn_params.slave_latency = SLAVE_LATENCY;

Gap_conn_params.conn_sup_timeout = CONN_SUP_TIMEOUT;

Err_code = sd_ble_gap_ppcp_set (& gap_conn_params );

APP_ERROR_CHECK (err_code );

// Set the static password

Uint8_tpasskey [] = STATIC_PASSKEY; m_static_pin_option.gap_opt.passkey.p_passkey = passkey;

// The system calls the command to set the password.

Err_code = sd_ble_opt_set (BLE_GAP_OPT_PASSKEY, & m_static_pin_option)

APP_ERROR_CHECK (err_code );

}

The static password setting operation is complete.

The information to be exchanged during pairing is set:

The following defines the macros of the information to be exchanged, that is, some macros related to security parameters.

// The static password is only demonstrated here and does not need to be bound.

# Define SEC_PARAM_BOND 0

// Because a password is required, it is a type of MITM attack protection.

# Define SEC_PARAM_MITM 1

// Only the display screen is set here (in fact, no, but we use a known static password, so we do not need to display it)

# Define SEC_PARAM_IO_CAPABILITIES BLE_GAP_IO_CAPS_DISPLAY_ONLY

// Do not use out-of-band data

# Define SEC_PARAM_OOB 0

// The length of the link encryption key

# Define SEC_PARAM_MIN_KEY_SIZE 7

# Define SEC_PARAM_MAX_KEY_SIZE 16

After defining the macro, we need to set the parameter and write the following function.

M_sec_params is a global variable.

Ble_gap_sec_params_t m_sec_params;

Static void sec_params_init (void)

{

M_sec_params.bond = SEC_PARAM_BOND;

M_sec_params.mitm = SEC_PARAM_MITM;

M_sec_params.io_caps = SEC_PARAM_IO_CAPABILITIES;

M_sec_params.oob = SEC_PARAM_OOB;

M_sec_params.min_key_size = SEC_PARAM_MIN_KEY_SIZE;

M_sec_params.max_key_size = SEC_PARAM_MAX_KEY_SIZE;

}

Put this function in conn_params_init () in the initialization process of the main function.

This global variable is used in the information exchange after the pairing starts (because its internal value is the information to be exchanged ).

At this point, we have set the information that will be exchanged after pairing is started. But how can I send this information to the peer device? After reading the last step of triggering pairing, we can solve the problem of sending pairing information to the peer device.

The last step triggers pairing:

The pairing trigger has the following situations:

1: The host is directly initiated.

2: The slave server initiates a security request. If it is previously bound, the host directly uses the stored LTK to encrypt the link. If it is not, the host initiates a pairing request.

3: There is a concept of security mode in BLE. When an attribute is set to an encrypted link access that requires authentication, an error is returned if the link is insecure when the host accesses the slave host's ** server, then, the host initiates a pairing request to meet the security requirements.

We adopt the third method of passively waiting for host triggering. The first thing we need to do is to set some attributes to secure links for access, then the matching process will be triggered when the mobile phone is accessed.

Because we are based on uartdemo in 9.0SDK, we set the cccd (client configuration descriptor) with the RX feature value of ipvy to a secure link that requires authentication and encryption.

Because mobile phone enable y requires CCCD

Then, when the user connects to the board and clicks the "y" button of the rx feature value, the master will send a write command to write the cccd of the rx feature value on the board, because the initial test link is incomplete, then the phone will return a write error and start the pairing process.

The settings are as follows:

In the function that adds the RX feature value, simply do the following.

Here, only part of the code is intercepted:

Static uint32_t rx_char_add (ble_nus_t * p_nus, constble_nus_init_t * p_nus_init)

{

/** @ Snippet [Addingproprietary characteristic to S110 SoftDevice] */

Ble_gatts_char_md_tchar_md;

Ble_gatts_attr_md_tcccd_md;

Ble_gatts_attr_t attr_char_value;

Ble_uuid_t ble_uuid;

Ble_gatts_attr_md_tattr_md;

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

BLE_GAP_CONN_SEC_MODE_SET_OPEN (& cccd_md.read_perm );

// BLE_GAP_CONN_SEC_MODE_SET_OPEN (& cccd_md.write_perm );

// Change the row above to the row below

BLE_GAP_CONN_SEC_MODE_SET_ENC_WITH_MITM (& cccd_md.write_perm );

Cccd_md.vloc = BLE_GATTS_VLOC_STACK;

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

··············

··············

············

}

In this way, when a peer device (such as a mobile phone) enables the feature of the rx feature on the Development Board

If a pairing is triggered because you do not have the write permission, the mobile phone sends a pairing request and the Board replies to the pairing information,

How to reply? This is the last question left in step 2. How to send pairing information to peer settings

Slave (mobile phone ).

When the mobile phone sends a pairing request, this is an event for the board, that is, a pairing event. Final

The dispatch dispatching function is the event processing function assigned to each service or module.

What we need to do is to reply to the pairing set in step 2 after receiving the pairing request event

Information. Modify on_ble_evt in the main. c file as follows:

Staticvoidon_ble_evt (ble_evt_t * p_ble_evt)

{

Uint32_terr_code;

Switch (p_ble_evt-> header. evt_id)

{

CaseBLE_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;

CaseBLE_GAP_EVT_DISCONNECTED:

Err_code = bsp_indication_set (BSP_INDICATE_IDLE );

APP_ERROR_CHECK (err_code );

M_conn_handle = BLE_CONN_HANDLE_INVALID;

Break;

CaseBLE_GAP_EVT_SEC_PARAMS_REQUEST:

// Comment out the original function that does not support pairing and change it to the following paired reply function:

// Err_code = sd_ble_gap_sec_params_reply (m_conn_handle,

// BLE_GAP_SEC_STATUS_PAIRING_NOT_SUPP, NULL, NULL );

Err_code = sd_ble_gap_sec_params_reply (m_conn_handle,

BLE_GAP_SEC_STATUS_SUCCESS, & m_sec_params, NULL );

APP_ERROR_CHECK (err_code );

Break;

CaseBLE_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;

}

}

All the configurations are complete. After the program runs. Connect the phone to the board and then access the rx feature value. Because the feature value is used to transmit the board data to the mobile phone through the "y" method, you must first click the "y" button on the mobile phone to enable the "y" function of the Board. When you click this button, the password pair box is displayed.