What outstanding functions will Bluetooth 5.4 bring to us?

The most importation new function is PAwR on Bluetooth 5.4, which is very suitable for application in the field of electronic shelf labels (ESL).

However, in actual application scenarios, only the PAwR feature is not enough.

How to ensure the security of broadcast data and how to dynamically adjust the broadcast Encoding method to achieve optimal power consumption.

This requires the use of several new features of Bluetooth 5.4 that will be introduced in this article.

What outstanding functions will Bluetooth 5.4 bring to us?

Let’s review several new features of Bluetooth 5.4:

Supports Periodic Broadcast with Response (PAwR)

PAwR is a new BLE logical transport layer, which supports connectionless, bidirectional, one-to-many, and a low-power topology technology.

Support for Encrypted Advertisement Data (EAD)

This feature provides a standardized method to encrypt data in broadcast packets, and the encrypted broadcast data can only be decrypted by devices with the same key.

Of course, the encryption of the broadcast packet requires the two devices to establish a gatt connection before generating the key for the encrypted broadcast packet.

LE GATT Security Level Characteristic

Devices can now use the GATT Security Level characteristic to indicate the device’s security mode and security class

Dynamic Broadcast Code Selection (CSSA)

When sending BLE extension broadcasts, you can now choose which Codec encoding method to use to send.

The previous article has introduced the PAwR feature. For those who have not read it, it is recommended to read the previous article first.

This chapter mainly introduces the support for encrypted broadcast data (EAD), LE GATT security level features, and broadcast encoding selection.

Encrypted Broadcast (EAD)

1. Encrypted broadcast background

Bluetooth devices often use broadcast, scan response packets, or classic Bluetooth EIR packets to send application data, so it is necessary to encrypt broadcast data.

Before Bluetooth 5.4, there was no clear standard to meet this part of the requirements.

The connection-based encryption and authentication process was specified in Bluetooth, but this broadcast-based connectionless encryption and authentication was not specified before.

Encryption is to convert unauthenticated third-party data into fixed-coded ciphertext that cannot be directly parsed through algorithms. Encryption prevents eavesdropper attacks.

Encryption algorithms use one or more keys to encrypt and decrypt data. Some algorithms also use an initial IV value as input, this IV value is usually called the key material. Encrypted data should contain this key material so that the recipient can decrypt the data normally. The sharing of key material needs to be done securely so that unauthorized devices cannot obtain it.

CCM is a counter for CBC‑MAC block cipher mode. It is used with a 128-bit block cipher such as AES to encrypt and authenticate messages. Authentication is achieved by including a computed Message Authentication Code (MAC), which the Bluetooth core specification refers to as a MIC (Message Integrity Check).

2. Introduction to encrypted broadcasting

2.1 Advantages of encrypted broadcasting

The encrypted broadcast feature provides a standardized, universally applicable mechanism for transmitting encrypted data in broadcast packets, scan response packets, and EIR packets, and securely sharing associated cryptographic keying material.

This means that connectionless communication can now be used as a secure application data transfer mechanism in one-to-many or one-to-one topologies.

2.2 Technical realization

The implementation of the encrypted broadcast features described below is based on the broadcast channel on BLE, and the classic Bluetooth is similar. For details, please refer to the Bluetooth core specification, which has a detailed introduction.

2.2.1 Shared key material

The transmission of the shared key material requires a broadcaster device that can receive a connection request command and establish a GATT connection.

The broadcaster plays the role of the GAP peripheral device, and the GATT service of the device needs to include the GAP service.

Now Bluetooth 5.4 specifies a new feature called Encrypted Data Key Material , which provides the basis for shared key material for receivers of encrypted broadcast data.

The Encrypted Data Keying Material characteristic contains a 24-byte value consisting of a 16-byte session key and an 8-byte IV value. GATT clients can only read this value over an encrypted and authenticated GATT connection;

therefore, the broadcasting device and all devices intending to be recipients of encrypted broadcast data must already be paired. Writing properties is not allowed. This feature can also support GATT indications, but only over secure links.

After the peripheral device establishes a connection with the central device, when the key material of the device changes, the peripheral device can use the GATT instruction command to notify the central device.

If the device needs to accommodate multiple encryption key material values, the encryption data key material characteristics do not need to be included in the GAP service, and can be directly included in the custom service.

2.2.2 Encryption of broadcast data

Any data to be transmitted securely must first be encapsulated in an appropriate AD structure. Supports encryption of multiple AD structures, which is achieved by first connecting the set of AD structures that need to be encrypted into a series of AD structures.

It is this sequence of one or more AD structures that is encrypted.

2.2.3 Transmission of encrypted data

Bluetooth 5.4 adds a new broadcast type for encrypted broadcasts, which can be used to encrypt data that needs to be protected.

One broadcast packet can contain one or more encrypted types of data. The encrypted data AD type is then included in the appropriate packet.

Those encrypted AD types are not included in these packets in their original plain text form. Other unencrypted AD types may be included in packets containing encrypted data AD types.

In addition to the ciphertext payload, the data field of the encrypted data AD structure contains a 40-bit randomizer field and a 32-bit message integrity check (MIC).

The figure below shows a sample broadcast payload that contains two AD types (ESL and local name) encrypted and encapsulated in an encrypted data AD type and one unencrypted AD type (flag).

The Randomizer field contains a 5-byte random number generated according to the random number requirements specified in the Bluetooth Core Specification.

Every time the payload value changes, a new randomizer value must be generated. The Randomizer value is used to formulate the random numbers required by the CCM algorithm.

Assuming random device addresses are used, whenever a device changes its address, the Randomizer field must also change. This causes the content of broadcast packets to change when the device’s address changes, reducing an eavesdropper’s ability to track the device.

Profiles that use the Encrypted Broadcast Data feature define how the encryption keying material consisting of the session key and IV is pre-shared.

As mentioned earlier, the Encrypted Data Keying Material feature is provided for this purpose, and it can be included in the Generic Access Profile GATT service, or in some other service, depending on other profile-related considerations Factors such as device roles.

LE GATT Security Level Features

1. Introduction to GATT related basics

The Generic Attribute Profile (GATT) provides a means by which device data and functionality can be represented in structures consisting of GATT services, characteristics, and descriptors. GATT service, characteristic, descriptor, each of these three types is an attribute, and the attribute is defined in the macro in the attribute table.

Each attribute in the attribute table has a unique identifier. This identifier Called a handle (handle).

Devices use what is known as the Attribute Protocol (ATT) to access attributes in the peer Bluetooth device’s attribute table, following rules defined by various GATT procedures, such as characteristic value reading and characteristic value writing.

GATT defines two roles, GATT client and GATT server.

The GATT client sends ATT commands to the GATT server, and the commands are divided into those that require response and those that do not.

A GATT server accepts and processes commands and requests received from GATT clients.

The GATT server can also send various types of ATT PDUs to the GATT client.

The commands include notifications and instructions. Notifications do not require a response, and instructions require a response confirmation.

Each property in the property sheet contains a set of property permissions.

Attribute permissions define the type of access a client has to that attribute (for example, the ability to read characteristic values) and the conditions that may be required before granting that access.

For example, a property’s permissions might indicate that clients can read its value, but only over authenticated and encrypted connections.

Attribute permissions also apply to ATT servers and their communications with clients using notifications and instructions.

ATT PDUs are transmitted over a GATT connection.

Usually, after the connection is established, the GATT client will first execute the service discovery process to discover the related services, characteristics and descriptors and their related attributes (such as handle value, type and authority) to determine the content of the device attribute table.

It is important to note that attribute permissions do not limit the client’s ability to perform the discovery process.

If a client attempts to access a property but does not meet the conditions of the associated property permission, the property protocol defines several error codes to be returned to indicate to the client device that the access request was denied and the reason for the denial.

Examples include insufficient encryption, insufficient authentication, and insufficient encryption key size

2. GATT Security and User Experience

When a client tries to access the property, the property’s permissions are checked. If the security conditions specified by the attribute permissions are not met, the client is denied access and a response with an error code is returned in the ATT_ERROR_RSP PDU.

When a server denies access to an attribute, it usually does not directly disconnect the GATT connection. At this time, the client usually upgrades the security level to meet the access standard.

For example, if trying to read the characteristic value results in an insufficient encryption error, the client may start the pairing process.

After the pairing is completed, the encrypted link can be used to access, but at this time the user needs to resend the data that failed the last access .

Officially, an error is caused by not satisfying access security permissions.

Even if the client upgrades the security level, the user will need to manually resend the data, which greatly affects the user experience.

However, the Bluetooth core specification until version 5.3 still does not provide this.

Alternatives to safe error handling strategies.

Of course, this is also the significance of Bluetooth 5.4 supporting GATT security level features.

3. About LE Gatt Security Level Features

Version 5.4 of the Bluetooth Core Specification defines a new characteristic called the LE GATT Security Level Characteristic (SLC).

The SLC feature allows a client to determine the GATT server security conditions that must be met if access to all GATT functions is to be granted. More importantly, it allows this to be determined before accessing the attributes used by GATT.

This early check of access requirements provides a better user experience because there is no temporary interruption of application flow due to security level concerns.

3.2.2 Technical implementation The device can include the SLC feature in the GAP service.

When the client finds the feature value when discovering the service, it will select the appropriate security level according to the security conditions of the feature value, such as initiating pairing.

The secure pairing modes and levels of BLE are as follows:

Safe Mode 1

No security (no encryption and no authentication)
Encrypted unauthenticated pairing
Encrypted Authentication Pairing
BLE secure connection, encrypted authentication pairing

Safe Mode 2

Unauthenticated pairing with digital signature
Authenticated pairing with digital signature

Safe Mode 3

No security (no encryption and no authentication)
Use non-authenticated Broadcast_Code
Broadcast_Code using authentication

Clients use the SLC property by reading its value and evaluating the current security mode and level against the value indicated by the Security Level Required field.

If the current security mode and level are found to be insufficient to allow all GATT functionality supported by the server, at this point the client application will take action to resolve the problem, usually by calling a procedure to upgrade the link security.

Dynamic broadcast coding selection (CSSA)

1. Background introduction

The Bluetooth LE physical layer defines three variants, collectively referred to as PHYs. These three PHYs are called LE 1M, LE 2M and LE Coded respectively.

When using the LE Coded PHY, a Forward Error Correction (FEC) algorithm and a pattern mapper are applied to the payload prior to transmission as configured.

This results in additional error correction data being included in the transmitted data packets.

Using the FEC algorithm can ensure that devices that are far away from the transmitter can also receive data correctly (that is, have a lower signal-to-noise ratio).

There are two ways of Coded PHY encoding. According to the configuration S=2 or S=8, you can control how much error correction data is generated and to what extent the communication distance is increased.

The following figure compares the three PHYs:

2. Introduction to dynamic broadcast encoding selection

What is the difference between the new feature of Bluetooth 5.4 update, dynamic broadcast coding selection (CSSA) and the previous one?

Although the Host side has defined how to use the HCI interface to send commands to change the code of the Control side, but before Bluetooth 5.4, when the extended broadcast selects the LE CODEC code, it is not possible to specify whether the value of S is 2 or 8.

Dynamic switching is also not possible. Bluetooth 5.4 changed the HCI command to allow specifying the value of the FEC parameter S when using the LE coded PHY.

The HCI command is as follows:

What outstanding functions will Bluetooth bring to us?

Summary

Version 5.4 of the Bluetooth Core Specification adds an important new two-way connectionless capability to PAwR, making it possible to securely broadcast confidential data in advertising packets.

In addition to these considerable improvements, applications using GATT can now provide a better user experience than before when dealing with attribute security requirements, and devices can perform extended broadcasting of important parameter(s) using the LE Coded PHY.

Generally speaking, the Bluetooth 5.4 version is a small update.

These new features, the clear application scenario is the electronic shelf label, which is also a market that the Bluetooth SIG wants to obtain.

Of course, these features can also be embedded in other Bluetooth products to improve the user experience of the products.

What outstanding functions will Bluetooth 5.4 bring to us?

PBX on Raspberry Pi

PBX on Chromebook

PBX on VPS

PBX on Orange Pi Zero

PBX on Raspberry Pi Zero

Disclaimer of pbxscience.com

Tags: Bluetooth

What outstanding functions will Bluetooth 5.4 bring to us?