Bluetooth Low Energy (BLE) provides multiple layers of security designed to ensure that only authorized devices can communicate and exchange data. For XBee 3 BLU devices, security over Bluetooth is primarily managed through the Secure Remote Password (SRP) protocol.

SRP overview

The Secure Remote Password (SRP) protocol is a cryptographic method for authenticating users securely over an insecure network.

The main advantage of SRP is that passwords are never transmitted or stored in plain text. Instead, both the client and the server independently calculate a session key that is derived from shared public information and secret values known only to them. This ensures that even if attackers have access to the exchanged public keys, they cannot derive the private keys or the session key without knowing the password.

Additionally, SRP provides forward secrecy, meaning that even if the session key from a previous connection is compromised, it won’t compromise future connections.

By supporting SRP, XBee 3 BLU devices are protected against common attacks such as brute force, eavesdropping, and man-in-the-middle attacks.

Features

XBee 3 BLU devices that support SRP have the following features:

  • Secure device pairing: When a BLE-capable device pairs with an XBee 3 BLU module, SRP ensures that the connection is secure and that the pairing process cannot be compromised by an attacker.

  • Encrypted data exchange: Once paired, all data exchanged between the devices is encrypted using the session key derived from SRP.

  • Seamless reconnection: SRP enables fast, secure reconnection between devices without requiring re-entry of passwords, making it practical for environments with frequent connections.

Concepts

Here is a collection of key concepts that will prepare you to follow the more technical explanations to come:

Term

Definition

Salt

Random value unique to the user. It is combined with the password to create the verifier and ensures that identical passwords appear and are handled differently.

Verifier

A value derived from the user’s password that allows the server to authenticate users without storing the actual password.

Private Key

A secret value known only to the owner, which is never exchanged between devices. It is used in conjunction with the public key to compute the shared session key.

Public Key

A value derived from the private key and shared with the other device during authentication. Public keys are exchanged to compute the session key.

Session Key

A secret key computed independently by both the client and server. This key is used to encrypt and decrypt data during the session, ensuring secure communication.

Scrambling Parameter

A random value calculated from the public keys that helps ensure that even if an attacker intercepts any of the public keys, they cannot compute the session key.

Authentication process

The SRP authentication process involves a client (the authenticating device) and a server (the device verifying the client). Both, the client and server, exchange public information while keeping private values secret, allowing them to authenticate securely.

Here’s a breakdown of the authentication process:

  • Step 0: Server prepares the user’s verifier: Before authentication, the server generates and stores the salt (s), username (I), and verifier (v). The salt is combined with the username (I) and password to compute an initial private key (x). The verifier is calculated by using a generator (g) value combined with the private key (x) and a large prime number (N).

  • Step 1: Client sends public key to the server: When authentication begins, the client generates a private key (a) and computes a public key (A), which it sends to the server. This public key is derived from a generator value (g) combined with its private key (a) and a large prime number (N).

  • Step 2: Server responds with salt and public key: The server responds with the stored salt and its own public key (B). The server’s public key is computed using the verifier and the server’s randomly generated private key (b).

  • Step 3: Both calculate the scrambling parameter: Both devices compute a scrambling parameter (u) based on their public keys to make it difficult for attackers to guess the session key.

  • Step 4: Client sends the session key to the server: Using the scrambling parameter (u), its private key (a), the salt (s) and the server’s public key (B), the client computes the session key (M1) and sends it to the server.

  • Step 5: Server sends the session key to the client: The server verifies the client’s session key and then, if it is correct, computes its own version of the session key (M2) using the client’s public key (A), the verifier (v), and its private key (b) and sends it back to the client.

Once both parties verify each other’s proofs, they can communicate securely.

Read the SRP protocol design to get more information on the SRP authentication mechanism.

SRP authentication on XBee devices

This section provides a detailed explanation of how to perform SRP-based authentication on XBee devices, the necessary configurations, and the process that takes place between the devices.

Digi’s library to develop mobile applications that communicate with XBee devices over BLE includes built-in support for SRP authentication. This means that you don’t need to worry about implementing the process yourself.
However, keep reading to understand how the process works.

Preconditions

Before starting the SRP authentication process with XBee devices, you need two key components:

  • Client: The authenticating device, typically a smartphone or another BLE-capable device that will initiate communication. It must have support for the SRP authentication process as described in the following section.

  • Server: The XBee 3 BLU device, which acts as the authentication server and must must have the following configurations in place:

    • BLE interface enabled: The device must be able to send and receive Bluetooth frames.

    • Password provisioned: The XBee device should have a pre-set password used during authentication. It is used during the pairing process but never transmitted directly.

      In practice, the password you set is used to generate the salt ($S) and verifier ($V, $W, $X, $Y). When using XBee Studio or any of the libraries provided by Digi, this conversion is handled automatically, so you only need to manage your password without worrying about the underlying settings.

Configure your device

In order to configure your XBee 3 BLU device (server) to be able to communicate with other devices using the Bluetooth interface you can use:

XBee Studio (click to expand)

XBee Studio allows to configure the device very easily as it comes with built-in support for SRP.

To learn how to enable BLE in your XBee 3 BLU device, refer to the Configure the BLE interface page. As part of this process you will enable the BLE interface, set a BLE identifier and provision the password on your device. Also, you should make sure to set your module in API mode.

Normally, the password provisioning process requires you to manually convert the password into a salt ($S) and verifier ($V, $W, $X, $Y) and set these values as the corresponding settings. However, XBee Studio simplifies this by automatically handling the conversion when you set the BLE password, as shown in the earlier example.

Digi libraries (click to expand)

Depending on your architecture and your needs, you can use any of the available libraries that Digi offers which come with SRP support by default to simplify the configuration of your devices.

Check out the Host application development and Bluetooth application development pages to learn which libraries are better suited for your use case and start configuring your devices.

Manually (click to expand)

If you wish to configure your XBee 3 BLU device using your own software, without relying on Digi’s tools and libraries:

  • Refer to the Change device settings using Command mode or API frames section for details on how to configure your device via a serial connection.

  • Note that you won’t be able to set the password directly; instead, you will need to manually configure the salt ($S) and verifier ($V, $W, $X, $Y) AT settings.

    • According to the SRP specification, to calculate the verifier you need to hash the password with the SRP identifying user name. This user name, commonly referred to as I, is fixed to the username apiservice.

  • In case you want to use an external library, the following implementations are known to work with the BLE SRP implementation:

  • Note that you need to modify the hashing algorithm to SAH256 and the values of N (large prime number) and g (generator value) to use the RFC5054 1024-bit group.

Authenticate

The authentication process to communicate with an XBee device is an implementation of the SRP algorithm using the RFC5054 1024-bit group and the SHA-256 hash algorithm.

You need to use the BLE Unlock Request - 0x2C and BLE Unlock Response - 0xAC API frames to exchange information between the client and the XBee device on each step of the authentication process.

The authentication process to enable the secure communication between a client device, such as a smartphone, and the XBee 3 BLU device (server) is the following:

  1. The client connects with the server:

    1. Optional, but recommended: The client should request a larger MTU for the GATT connection.

    2. The client turns on indications for the API Response characteristic.

  2. Start the authentication process:

    Some steps of the authentication process are associated with a phase described in the BLE Unlock Request - 0x2C API frame page. Refer to that page to get complimentary documentation on the authentication process as implemented by the XBee 3 BLU device.

    • Step 0: Right after the device (server) is configured, it generates and stores the salt, username, and verifier based on the user-configured password.

    • Step 1: The client uses the same password internally to calculate its own private and public keys. It sends the public key to the XBee module (Phase 1).

    • Step 2: The XBee device replies with the salt and its public key to the client (Phase 2).

    • Step 3: Both the client and the XBee module compute the session key independently based on the values exchanged during the process.

    • Step 4: The client sends the session key to the XBee device (Phase 3).

    • Step 5: The server verifies the session key of the client and, if correct, the server sends its session key to the client. The server also sends the Tx nonce and RX nonce values to the client to be used to encrypt/decrypt the communication once authentication is successful (Phase 4).

Once the session key is validated on both ends, a secure communication channel is established, allowing the client to communicate with the XBee module without further input. Exchanged data from this point on will be encrypted using AES-256-CTR with the following parameters:

  • Key: The entire 32-byte session key.

  • Counter: 128 bits total, prefixed with the appropriate nonce shared during authentication. Initial remaining counter value is 1.

    The counter for data sent into the XBee API Service is prefixed with the TX nonce value and the counter for data sent by the XBee to the client is prefixed with the RX nonce value.

Communicate

After authentication is successful and both devices verify that the channel is safe to communicate, the process to send data to the XBee 3 BLU device is as follows:

  1. For each frame to send to the XBee, form the API Frame, and encrypt through the stream cipher as described in the authentication procedure.

  2. Write the frame using one or more write operations.

  3. When successful, the response arrives in one or more indications. If your stack does not do it for you, remember to acknowledge each indication as it is received.

    You are expected to process these indications.
    The response data is not available if you attempt to perform a read operation to the characteristic.

  4. Decrypt the stream of content provided through the indications, using the stream cipher as described in the authentication procedure.