ble-nrf51822 Tutorial 5-Static password settings _php tutorial

ble-nrf51822 Tutorial 5-Static password settings

Nordicble Exchange Group 498676838

This talk introduces some relevant theoretical knowledge of pairing, and describes how to implement the "Static password" setting

The program is based on the UART demo under sdk9.0

In addition, the mobile app used in the test is lightblue under iOS.

The exact phrase here should be called the pairing code, not the password. Enter this pairing code as an optional part of the pairing process

Describes how to set up a static password before you introduce the relevant knowledge of pairing (followed by a direct password, not the pairing code)

Two devices that did not initially provide security if you want to do some work that requires security, you must first pair. Pairing involves authentication of two devices, link encryption. If you set the bind location when pairing, there will be a secret key assignment later. The assigned secret key user can be stored in flash so that two devices are re-connected for a second time when the security boot is faster. Instead of needing to start the entire pairing process like the first time.

The first process of pairing is the exchange of pairing information, which is used to determine the authentication method, and whether or not to assign a key and which keys to assign later.

The information exchanged includes:

Both ends of the device input and output capabilities such as: whether there is a display, keyboard and so on.

Whether binding is required (if a bind is set for pairing).

Whether to need MITM, whether to use OOB, etc.

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

Like what:

1: If both ends of the device's input and output capacity is limited, for example, there is no keyboard and display, authentication is just work, which is actually no certification,

2: If the two devices have a display frequency, while the other has a keyboard, and the pairing is set to the MitM protection. Then the authentication method is passkey entery.
A pairing code is displayed at one end and the other needs to be entered. Then the pairing can proceed correctly.

3: If OOB is set, the pairing code is sent by means of another communication (such as NFC), rather than one end of the input as shown above.

The password setting for this is the second case. The displayed password can be random or static. Because the device does not have a monitor. But we can still set the input and output capability to have the monitor, because we are using a static password.

The pairing process does not just enter the pairing code, but it also generates a link key to encrypt the link based on the input pairing code, as well as random numbers exchanged by both ends of the device, and assigns subsequent long-term keys, such as the required keys such as the identity resolution key.

There are more theories about pairing, and the above description is just a general process. The pairing process is described in detail in the Security section of the Bluetooth specification.

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

The function that we need to enter "password" is actually part of the pairing process. The pairing process also needs to exchange the pairing information first, then the protocol stack will decide whether to enter the password based on the information exchanged.

So we have to do the following steps:

1: First set the static password to be entered
2: Set the information exchanged when pairing: according to the above introduction if we need to enter a password, then the pairing will be set to only have a monitor (so that it will be displayed at one end,
One end of the input, although we really do not have a monitor, but set a static password so it is also possible to set the need for MITM attack protection.

3: Trigger pairing.

Here's how to set a static password:

First define the static password, the pairing password can only be 6-digit ASCII string

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

Static password can be set in the structure

staticble_opt_t m_static_pin_option;

After defining these two parameters, we need to set a static password, set the operation needs after the protocol stack initialization, so we put the set password operation at the end of the Gap_params_init () function

As follows:

static void Gap_params_init (void)

{

The previous settings are some device names and some subsequent connection parameters that need to be negotiated

Detailed explanation in the serial port transmission analysis is explained

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

Here's how to set up a static password operation

Uint8_tpasskey[] = Static_passkey; M_static_pin_option.gap_opt.passkey.p_passkey= passkey;

The system calls the set operation that performs the password.

Err_code=sd_ble_opt_set (ble_gap_opt_passkey,&m_static_pin_option)

App_error_check (Err_code);

}

The operation to set a static password here is done.

Then the information to be exchanged when pairing is set:

Here is a macro that defines the information we need to exchange, that is, some macros related to security parameters.

Here is just a static password, no binding required

#define SEC_PARAM_BOND 0

Because to enter the password is a MITM attack protection, so here the MITM

#define SEC_PARAM_MITM 1

This setting only displays the display (actually no, but we use a static password that we know beforehand so we don't//need to show 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 parameters and write a function as follows.

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;

}

The function is placed in the initialization process of the main function conn_params_init (); After the function.

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

Here we set the information that will be exchanged after the pairing is started. But how to give this information to the peer device? After the last step of triggering the pairing problem, the problem of sending pairing information to the peer device is resolved.

The last step triggers a pairing:

There are several scenarios for pairing triggers:

1: Host directly initiated.

2: The slave initiates a security request, and if it has been previously bound, the host will use the saved LTK to encrypt the link directly, if there is no host chance to initiate the pairing request.

There is a concept of safe mode in 3:ble. When a property is set to an encrypted link access that requires authentication, when the host accesses the slave's * * device, if the link is unsafe, it returns an error, and the host initiates a pairing request to implement the security requirement.

We are using the third kind of passive waiting for the host trigger, so the first thing to do is to set some properties to require a secure link to access, then the phone will be in the access to trigger the pairing process.

Because we are based on the Uartdemo under 9.0SDK, we set the CCCD (client configuration descriptor) with the Notify Nature Rx eigenvalue to a secure link that requires authentication and encryption.

Because the phone-side enable notify is required to write CCCD

Then, when the hand is connected to the Board, click on the Notify button of the RX eigenvalue to send a write command to write the RX eigenvalue on the board CCCD, because the initial link is incomplete, then the phone will return to write the error, and then start the pairing process.

Settings are as follows:

In the function to add the RX eigenvalues, do the following simple.

Only part of the code is intercepted here:

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 following line

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

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

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

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

}

This allows the Notify function of the on-board RX eigenvalue to be enabled when the peer-to-peer device (such as a mobile phone)

Because there is no write permission to trigger the pairing, the opportunity to send a pairing request, and then the board reply to the pairing information,

How to reply? This is the last question left in the second step. How to give the pairing information to the peer

(mobile phone).

When the phone sends a pairing request, this is an event for the board, which is the pairing event. Ultimately by

The dispatch distribution function is given to the event handlers of each service or module.

So what we're going to do is to reply to the pairing set in the second step after receiving this pairing request event.

Information is available. The on_ble_evt in the Main.c file is modified 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 to the following pairing 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 has 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 required configurations are set up here. After the program runs. The phone connects to the board and then accesses the RX eigenvalues. Because the eigenvalue is used to pass the board data through the Notify way to the phone, then first click on the Phone Notify button to enable the Notify function of the board. When we click on this button, we will pop up the matching box for entering the password.

http://www.bkjia.com/PHPjc/1074169.html www.bkjia.com true http://www.bkjia.com/PHPjc/1074169.html techarticle ble-nrf51822 Tutorial 5-Static password settings nordicble AC Group 498676838 This lecture introduces some relevant theoretical knowledge of pairing, and describes how to implement a "Static password" setting program is the base ...

