After the Q & A recently met several times mentioned the need to implement the phone each time you connect the device, starting immediately paired and asked to enter the function keys. Here to write a separate tutorial for your reference.
Pairing purpose is to encrypt the link. To enhance transport security Bluetooth.
Some knowledge about the pairing of some description in a static password / dynamic random password tutorial. For use, the pairing understand what the relevant processes on the line.
Here are more of a say extra pairs and asked the difference between the binding problem:
About pairing and binding, some people might have been could not tell the difference between them. Pairing is a Bluetooth in order to improve the security of the transmission link. The binding is an optional configuration when paired initiated. The binding process is not an independent existence. Pairing can be understood in two ways, it is not provided a pairing request and the pairing request flag is set the binding of the binding representation.
For not set binding flags pairing request, the pairing process is
1, link information exchange, mainly on both sides of the device i / o capacity, the need for binding MITM protection link is required, if the setting information and the like which bind key distribution.
2, followed by a link-authentication (password previously static, dynamic password, the password authentication process is one way) The pairing information, the last link encryption
3, is the last link encryption.
For pairing set binding site: The difference is more than a process of distributing keys on an encrypted link.
1, link information exchange, mainly on both sides of the device i / o ability to bind flag set, the link need MITM protection, if the setting information and the like which bind key distribution.
2, followed by a link-authentication (password previously static, dynamic password, the password authentication process is one way) The pairing information, the last link encryption
3, a link encryption.
4, and finally the master device from a key distribution device.
Because the matching process is time consuming, every time you need to encrypt links are to perform pairing, then more trouble.
So there will bind this process, if you set a binding pair after storage in a number of encryption keys. If you needed again when the next link encryption, you can use the key binding process of the distribution (for link encryption, the key distribution is not used directly, but rather with the distribution key and then generates a session key for link encryption, under the understanding on the line, for the use of, the underlying details do not need to care about, care about even if you can not see the code, if you really want a closer look directly see the Bluetooth specification). Instead of performing the pairing process time-consuming.
Back to the main purpose of this talk: After realization of the phone each time you connect the device immediately start the pairing and enter key functional requirements.
Improve the static password tutorial too, for pairing fact, there are many trigger.
Tutorial Static and dynamic random password is to set a password security permissions on a characteristic value, when the phone is accessing it, because the link is not encrypted do not meet safety requirements, so the phone will receive such privileges insufficient error return after the end of the phone will perform a pairing request so that the link encryption to meet safety requirements.
But for the requirements here, above the trigger does not meet the requirements. Because this is required after each pair and connected to a key input immediately. The above situation is already connected and found the service and execution of the job after some operations.
This requires additional trigger, there are other ways of pairing:
1 host directly initiate pairing.
2 sent directly from the machine safety request, this time pairing if ever bind off, then saved when paired bound before the phone directly with the long-term key (LTK) to encrypt the link to work. If not then the phone will perform the pairing process.
For every trigger each time you connect this to be achieved, the first way mobile client directly initiate pairing, is the most direct. But there needs nothing more than a pair and password in order to improve safety, such as prevent other people can easily access. It certainly can not rely on the mobile phone side, in order to prevent themselves being even casually, it definitely needs to be made to limit the device side.
Therefore the second approach, i.e. each time the phone is connected after the device, the security device sends a request, since no binding. So mobile terminal binding information is not saved, so they send a pairing request to initiate the pairing process.
PS: This view seems to be made directly to the phone side pairing request this function seems useless.
But consider the case, app and automatically scan certain connection device (such as a particular device name, device address, or the like), and by setting a paired in the pairing request i / o terminal capacity of the mobile phone, the pairing code, and the device pairing code input terminal. If the other device, if such equipment fake name, address or device, even if connected. But immediately after the end of the phone connection directly pairing request, because "other people" see you pairing code on your phone, so pairing it fails, the phone can be allowed to end disconnected.
In summary, to achieve the required pairing immediately connected and an input function of the pairing code, we have to add the security code to send the connection request, and determining whether the pairing procedure is successful, if not successful then disconnect. In order to achieve the purpose of preventing others casual connection. So we need to do the following steps:
1: After connecting the phone to call security immediately request API sd_ble_gap_authenticate .
This phone will be sent upon receipt of a pairing request
2: return phone pairing request, set no binding. (So the phone every safety device requests received will be issued over a pairing request to initiate pairing)
3: After the pairing process will be carried out automatically. We only need to receive BLE_GAP_EVT_AUTH_STATUS event, to determine whether its status is successful, to decide the pairing is not successful, so the decision to shut the open link.
In order to help us on the basis of static passwords, add the code. In order to achieve the required functionality. In order to facilitate the people here have not seen static passwords tutorial to understand whole, it will still require a static password-related settings are also written. Specific details see static password tutorial.
First, the definition of what the relevant parameters
#define STATIC_PASSKEY "123456"
static ble_opt_t m_static_pin_option;
#define IO_CAPS BLE_GAP_IO_CAPS_DISPLAY_ONLY // only display device
#define BOND 0 // do not bind
#define OOB 0
#define MITM 1
Finally, add a static password setting function code gap_params_init
static void gap_params_init(void)
{
uint32_t err_code;
ble_gap_conn_params_t gap_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,
(const uint8_t *) DEVICE_NAME,
strlen(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);
uint8_t passkey[] = STATIC_PASSKEY;
m_static_pin_option.gap_opt.passkey.p_passkey = passkey;
err_code = sd_ble_opt_set(BLE_GAP_OPT_PASSKEY,& m_static_pin_option);
APP_ERROR_CHECK(err_code);
}
A pairing request sent to the phone, the device needs to reply, reply paired to function as follows:
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);
}
The final step is to add the code above said three steps to do.
Modify main.c, on_ble_evt, add code to the red part
static void on_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;
1 // establish a connection request to send security, thus contributing to over the phone to send a pairing request
ble_gap_sec_params_t params;
params.bond = 0;
params.mitm = 1;
sd_ble_gap_authenticate(m_conn_handle, ?ms);
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;
// 2 reply pairing request
case BLE_GAP_EVT_SEC_PARAMS_REQUEST:
printf("receive pair request\n");
resp_pair_request();
break;
// 3 to determine whether the pairing is successful, if unsuccessful disconnected, thereby preventing any connection to others.
case BLE_GAP_EVT_AUTH_STATUS:
if(p_ble_evt->evt.gap_evt.params.auth_status.auth_status == BLE_GAP_SEC_STATUS_SUCCESS){
printf("pair success\r\n");
}else{
sd_ble_gap_disconnect(m_conn_handle, BLE_HCI_REMOTE_USER_TERMINATED_CONNECTION);
}
case BLE_GATTS_EVT_SYS_ATTR_MISSING:
// No system attributes have been stored.
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;
}
}
Finally, comb process.
After the phone connection device, the device will send a security request immediately. Because the phone and the device is not binding, so after receipt of the equipment sent over mobile phone safety pairing request the opportunity to send a request to the device. Device, then respond to the pairing request (binding flag is not set), the device subsequent pairing process by the protocol stack automatically, and ultimately returned to the upper pairing completion event. Determine whether the pairing is successful, if it fails to disconnect, to prevent others to freely connected devices.
Text reproduced from: http: //blog.chinaunix.net/uid-28852942-id-5700019.html