Introduction

This article will introduce how to blacklist nodes from a Bluetooth Mesh network and the related APIs when developing with Silicon Labs Bluetooth Mesh SDK. Blacklisting nodes is an important part of the Bluetooth network management, which prevents the "trash-can-attach" risk. It utilizes the key refresh procedure to remove the nodes whose keys are compromised.

When a node is removed from the network, all remaining nodes would have their keys changed such that the removed node would not have knowledge of the new security credentials being used if that node was compromised after being disposed. This is known as the ”trash-can attack.”

There are 2 ways for Bluetooth Mesh network to remove one or more nodes from the network. The first one is via "Config Node Reset" command, the other way is via key refresh, both ways are supported by Silicon Labs Bluetooth Mesh SDK. Table 1 shows a comparison between these 2 ways.

In addition to blacklist node(s) from the network, the key refresh procedure is also capatible to refresh the application key(s), which results in blacklisting node(s) from some specific group(s) but remaining in the network. One note for refreshing the application keys, it's impossible to refresh only the application keys without refresh the bound network key.

How Key Refresh Works

If you are interested with the detailed information about how the key refresh procedure is designed and how it works, you can look into the chapter 3.10.4 of the Mesh Profile Specification 1.0.

Because the Silabs Bluetooth Mesh SDK has implemented this and packed the procedure to simple API calls, it's OK to just understand the procedure in general, it has 3 phase:

1. Receive the net key.
2. Inform the provisioner that the new key has been received.
3. Use the new key and revoke the old key.

Related APIs In Silabs Bluetooth SDK

Commands

• gecko_cmd_mesh_prov_set_key_refresh_blacklist - this is used to add a node to the blacklist list which is maintained by the stack.
• gecko_cmd_mesh_prov_set_key_refresh_appkey_blacklist - same as the above one but for refreshing appkey.
• gecko_cmd_mesh_prov_get_key_refresh_blacklist - this is used to check if a node is in the blacklist list which is maintained by the stack.
• gecko_cmd_mesh_prov_get_key_refresh_appkey_blacklist - same as the above one but for refreshing appkey.
• gecko_cmd_mesh_prov_key_refresh_start - command to start the key refresh procedure, nodes in the blacklist list will get blacklisted.

Test Class Commands

The test class commands are for developing and testing purpose, it's NOT recommended to use in the production firmware.

• gecko_cmd_mesh_test_update_local_key - this is used to update the key locally by a node.
• gecko_cmd_mesh_test_prov_prepare_key_refresh - this command will set the network key and the application key(s) if any which will be used for the next key refresh procedure.

Events

• gecko_evt_mesh_prov_key_refresh_node_update_id - there are 3 parameters carried in this event, key (network key index), phase (which phase the node has moved into) and uuid (UUID of the node). This event indicates that the node has moved to the specific phase.
• gecko_evt_mesh_prov_key_refresh_phase_update_id - this event indicates that the whole network has moved to the specific phase.
• gecko_evt_mesh_prov_key_refresh_complete_id - this event indicates that the key refresh procedure has completed.

Typical Flow

Below is a pseudo code to demonstrate to blacklist 3 nodes with UUID - uuid1, uuid2 and uuid3.

  #define BLACKLIST 1
  #define UUID_LEN  16
  #define NET_KEY_INDEX 0
  #define APP_KEY_NUM_TO_REFRESH 0
  struct gecko_msg_mesh_prov_set_key_refresh_blacklist_rsp_t *pBgRet = NULL;
  struct gecko_msg_mesh_prov_key_refresh_start_rsp_t *pKeyRefStartRet = NULL;

  pBgRet = gecko_cmd_mesh_prov_set_key_refresh_blacklist(netkey_id,
                                                         BLACKLIST,
                                                         UUID_LEN,
                                                         uuid1);
  check the result value, pBgRet->result.
  pBgRet = gecko_cmd_mesh_prov_set_key_refresh_blacklist(netkey_id,
                                                         BLACKLIST,
                                                         UUID_LEN,
                                                         uuid2);
  check the result value, pBgRet->result.
  pBgRet = gecko_cmd_mesh_prov_set_key_refresh_blacklist(netkey_id,
                                                         BLACKLIST,
                                                         UUID_LEN,
                                                         uuid3);
  check the result value, pBgRet->result.


  pKeyRefStartRet = gecko_cmd_mesh_prov_key_refresh_start(netkey_id,
                                                          NET_KEY_INDEX,
                                                          APP_KEY_NUM_TO_REFRESH,
                                                          NULL);
  check the result value, pKeyRefStartRet->result.

  while(1) {
     check the events from the stack.
    switch(evt_id) {
      case gecko_evt_mesh_prov_key_refresh_node_update_id:
        record any information carried by the event if needed.
        break;

      case gecko_evt_mesh_prov_key_refresh_phase_update_id:
        record any information carried by the event if needed.
        break;

      case gecko_evt_mesh_prov_key_refresh_complete_id:
           check the e->data.evt_mesh_prov_key_refresh_complete.result to see if success?
        record the new network key index
        break;
    }
  }

  ...

Example

The project in KBA_BT_0509: Bluetooth Mesh Host Provisioner implements the blacklisting feature, you can use it to try out blacklisting nodes from the network. If you don't have time to go through and understand the whole project, you can just poll out the stuff in blacklisting_devices.c which contains all the blacklisting related code.