New random static bluetooth address after every boot with Matter

We are working on Matter support for our products and we would like to use both Matter and our own protocol using the Nordic NUS bluetooth service. Development is going well, but we are facing the following issue:

The device generates a new random static bluetooth address after every reboot, so also for instance after a firmware update. For our application this is problematic, as we need the address to be fixed during the lifetime of a device. For bluetooth this is allowed (see https://academy.nordicsemi.com/courses/bluetooth-low-energy-fundamentals/lessons/lesson-2-bluetooth-le-advertising/topic/bluetooth-address).

Is there a reason why the address is generated again after every boot for Matter applications? Is there a setting somewhere to make it fixed for the lifetime of a device? So only generate it once, after the first boot?

This is where the address is initialized (https://github.com/nrfconnect/sdk-connectedhomeip/blob/master/src/platform/Zephyr/BLEManagerImpl.cpp): 

CHIP_ERROR InitRandomStaticAddress()
{
    // Generate a random static address for the default identity.
    // This must be done before bt_enable() as after that updating the default identity is not possible.
    int error = 0;
    bt_addr_le_t addr;

    // generating the address
    addr.type = BT_ADDR_LE_RANDOM;
    error     = sys_csrand_get(addr.a.val, sizeof(addr.a.val));
    BT_ADDR_SET_STATIC(&addr.a);

    if (error)
    {
        ChipLogError(DeviceLayer, "Failed to create BLE address: %d", error);
        return System::MapErrorZephyr(error);
    }

    error = bt_id_create(&addr, nullptr);

    if (error < 0)
    {
        ChipLogError(DeviceLayer, "Failed to create BLE identity: %d", error);
        return System::MapErrorZephyr(error);
    }

    ChipLogProgress(DeviceLayer, "BLE address: %02X:%02X:%02X:%02X:%02X:%02X", addr.a.val[5], addr.a.val[4], addr.a.val[3],
                    addr.a.val[2], addr.a.val[1], addr.a.val[0]);
    return CHIP_NO_ERROR;
}

Parents
  • Hi BertL, 

    It's enforced by the spec because of privacy reason. If you take a look at the Matter Specification at section 5.4.2.5.5 you can find this: 

    5.4.2.5.5. Advertising Address
    To ensure privacy, commissionable devices SHALL use LE Random Device Address (see Bluetooth®
    Core Specification 4.2 Vol 6, Part B, Section 1.3.2.1 "Static device address") for BLE Advertising and
    SHALL change it at least on every boot.

    It's a mandatory requirement. 

    If you want to recognize the device even after it reboots you would need to bond with it and get the IRK key so that you can resolve the random address that it generate after each reboot. 

  • Thanks, that's clear. In our case a changed device address would not add a lot of privacy as we always advertise a device id in the manufacturer data. So that can be used to track a device even though the address is changed. Would this be a problem according to the Matter spec?

  • I think it is a problem. If you advertise the device with an unique number that doesn't change over time it's very easy to track the device with any Bluetooth scanner. Imagine a customer buy a wearable device and carry it, the customer can be easily tracked if the data in the advertising packet doesn't change over time. 

    This is just my opinion, I would suggest you to double check it with CSA , the organization that watching over Matter. There will be some requirements you need to pass to be able to pass their certification. 

Reply
  • I think it is a problem. If you advertise the device with an unique number that doesn't change over time it's very easy to track the device with any Bluetooth scanner. Imagine a customer buy a wearable device and carry it, the customer can be easily tracked if the data in the advertising packet doesn't change over time. 

    This is just my opinion, I would suggest you to double check it with CSA , the organization that watching over Matter. There will be some requirements you need to pass to be able to pass their certification. 

Children
Related