Privacy and Security are critical issues and should always be top concerns in wireless designs. Bluetooth protocols, version 4.0 and newer, include a Bluetooth Low Energy (BLE) connectivity option for OEMs seeking secure and private connections. BLE makes it possible to add wireless short-range capabilities to devices. Adding these capabilities enables smaller form factors, better power optimization, and the ability to operate on a small power cell for months or even years. BLE also comes equipped with several security and privacy capabilities, and there are BLE modules that can provide additional security and privacy to make the technology an even stronger wireless solution. When choosing a BLE module, it is imperative to choose modules with thoroughly tested and proven security and privacy capabilities. The following provides an overview of addressing and privacy for Laird’s BL600, BL620, and BT900.

General Addressing and Privacy

BLE can use Random Device Addressing to help increase the privacy of connections and prevent “tracking” assuming eavesdropping did not occur during the ‘just works’ pairing process or out of band (OOB) pairing occurred. There are 4 types of addresses defined for BLE:

  • Public IEEE Format– Manufacturer specific IEEE Bluetooth address and company identifiers can be purchased through the IEEE Registration Authority.
  • Random Static– Burned into radio silicon upon shipment or can be randomly generated to a new value at each power cycle.
  • Random Private Resolvable– Used in bonded devices and requires the Identity Resolving Key (IRK) be shared during Phase 3 of the pairing procedure. This changes periodically based on a timer or other method. This is the default use case for iOS devices and for Android devices with Lollipop or newer.
  • Random Private Non-Resolvable– Shared between bonded devices for use during reconnection. This changes with each connection.

As an example of a real use case, iOS devices that use resolvable addresses will change the addresses on a regular basis. This means an iOS device (or latest Android Lollipop devices) picked up one day at a restaurant will not be picked up the next day as it will have changed its identity.

BL6x0 and BT900 Addressing and PrivacyBLE Modules

The BL600 and BL620 does not support transmission of a Random Private Resolvable or Random Private Non-Resolvable address for itself but does support interaction with remote devices that use these addressing schemes. For example, iOS devices that use Random Private Resolvable addressing and the BL600/BL620 supports two of the four types of addressing for itself:

  • Random Static– Burned into the Nordic silicon (nRF51822) at the time of manufacturing. This is an address that is unique to each BL600 and does not change.
  • Public IEEE– An address that can be used in place of the Random Static address and must be purchased through IEEE.

You can add a Public IEEE address to the BL600/BL620/BT900 using a one-time writable command function, AT+MAC. Once the AT+MAC command is used to add an IEEE address (correct or otherwise) you cannot modify it. If entered incorrectly, the only option is to erase the flash memory and start fresh. Laird provides a Windows utility and JLINK programmer (with the development kit) that can be used for this purpose (excluding BT900). Customers should first retrieve and record the license key using AT I 49406 and then use the Windows utility to erase the flash as follows:

erase flash
**Note: The license key will need to be re-entered to restore full operation after this procedure.

Laird recommends recording and storing the responses to the following information commands:

  • AT i 14 – Retrieves Random Static address burned to silicon by Nordic.
  • AT i 49406 – Retrieves the Nordic License Key for the module.

If a Public IEEE address exists, the AT i 4 information commands will return its value. This command will currently return either the Random Static or the Public IEEE address, depending on whether the Public IEEE address has been programmed or not. The response format is TT AAAAAAAAAAAA where TT == 00 for Public IEEE or TT == 01 for Random Static. This information command is also useful in determining if the BL600/620/BT900 has a valid license key from Nordic. If this command returns a value with the word C0FFEE in the address, then the license key is no longer valid and the device’s Random Static address (AT I 14) will need to be provided to Laird Support in order to generate the license key (which can be entered into the device with the AT+LIC command). AT i 24 will return “Laird Technologies, © 2012” if Public IEEE address does not exist.

White List

BLE devices have the option of using a “White List” or Trusted Device Database (TDD) to limit communication access to the local device and lower overall power consumption. The White List is essentially a list of remote devices that are allowed to communicate with the local device. The White List resides in the Link Layer and is used to filter incoming connection requests, scan requests, and advertising packets as designated by the Host
Controller. White List filtering in the Link Layer can lower power consumption by limiting requests and data passed to the higher layers for processing and interaction. Depending on the application, the Host Controller can choose not to use the white list, can add or delete remote devices from the white list as necessary or desired, and/or can allow the white list to be populated during the BONDING phase (Phase 3) of the pairing process. The white list can contain records for a limited set of remote devices (determined by the Host).

For more technical information, download the BLE and Laird’s BL6x0 Series & BT900 Modules: A guide to Security and Privacy white paper.

If you enjoyed this article, please subscribe or leave a comment below!

Tagged with:
 

2 Responses to An Overview of Addressing and Privacy for Laird’s BLE Modules

  1. Brian Reinhold says:

    Are you sure about the use of non-resolvable private address? I cannot find such an explanation in the spec. Can you point me to where that is explained in the spec? Clearly an IRK is useless.

    How is it supposed to work? Does the central scan for that particular address and does the peripheral use a directed advertising using that address?

  2. Hi
    Given the article is written from the perspective of the v4.0 specification, I will explain using that spec as a context.

    I agree that an IRK is useless given a non-resolvable address is used.

    Firstly see section “5.2.5 Privacy Feature” on page 197 (of 2302) of the Core 4.0 specification where the third paragraph says …

    *****
    The privacy feature also defines a reconnection address which allows for bonded device to reconnect while also filtering devices to known devices. The reconnect address is exchanged between the two devices at each connection.
    Since reconnect addresses only change between connections, device filtering can be used to minimize processing of excessive requests.
    *****

    Then on the BT SIG’s developer site search for details of the characteristic “Reconnection Address” which is an optional part of the “Generic Access” Service. That characteristic contains, if it exists in the service, a non-resolvable address

    Then in the 4.0 spec go to page 1708 (of 2302) and view figure 9.3 which shows how the ‘reconnection address’ is used.

    In summary, **a** use of non-resolvable address (as described in the article above) is for reconnecting using directed adverts and the way it works (for bonded devices only) is on connection the central will read the ‘Reconnection Address’ characteristic if the ‘Peripheral Privacy Flag’ characteristic exists and if set and will use that to scan for directed adverts to reconnect should the connection drop for any reason. On each reconnection, the peripheral can change the address if it so chooses. Obviously the peripheral will use the non-resolvable address in the direct advert.

    For what it is worth, in the years since 4.0 was released I have not seen an instance of non-resolvable address being used in this manner, but that does not prove it hasn’t been used :-). I would be very interested to hear of use cases you have come across.

Leave a Reply

Your email address will not be published. Required fields are marked *

Real Time Analytics