DEV Community: jason goose

Emulating USB Protocol over BLE for Data Transfer

jason goose — Sun, 28 Jul 2024 02:12:49 +0000

article from tosdn.com

As the Internet of Things (IoT) continues to grow, the need for efficient and reliable data transfer between devices has become increasingly important. One approach to achieve this is by emulating the Universal Serial Bus (USB) protocol over Bluetooth Low Energy (BLE) technology. In this blog, we will explore the concept of emulating USB protocol over BLE and provide a detailed implementation guide for computer enthusiasts.

Introduction to BLE and USB

BLE is a wireless personal area network technology that allows devices to communicate with each other over short distances. It is commonly used in IoT devices, wearables, and other low-power applications. USB, on the other hand, is a widely used interface standard for connecting devices to a computer.

Emulating USB Protocol over BLE

To emulate the USB protocol over BLE, we need to create a virtual USB device on the BLE device and configure it to communicate with the computer as if it were a physical USB device. This involves creating a BLE service that mimics the USB device's behavior, including its interface, endpoints, and device class.

Hardware and Software Requirements

To implement this project, you will need the following hardware and software components:

A BLE module (e.g., nRF52832 or CC2541)
A microcontroller (e.g., STM32 or Arduino)
A USB device (e.g., USB storage device or USB serial device)
BLE module's SDK (e.g., nRF5 SDK or CC2541 SDK)
Microcontroller's development environment (e.g., Keil µVision or Arduino IDE)
USB device's driver program (e.g., USB storage device driver or USB serial device driver)
Implementation Steps
Step 1: Create a BLE Service

Create a BLE service on the BLE module that mimics the USB device's behavior. This service should include characteristics that emulate the USB device's interface, endpoints, and device class.

Using the nRF5 SDK, you can create a BLE service as follows:

include

define SERVICE_UUID 0x180F // USB device service UUID

define CHARACTERISTIC_UUID 0x2902 // USB device characteristic UUID

void create_service(void)
{
uint16_t service_handle;
uint16_t characteristic_handle;

// Create a BLE service
ble_gap_service_add(&service_handle, &SERVICE_UUID);

// Create a BLE characteristic
ble_gatts_characteristic_add(&characteristic_handle, &CHARACTERISTIC_UUID, BLE_GATT_CHAR_PROPERTIES_READ | BLE_GATT_CHAR_PROPERTIES_WRITE, &service_handle);

}
Step 2: Implement a Virtual USB Device Class

Implement a virtual USB device class on the microcontroller that emulates the behavior of a physical USB device. This class should provide a virtual USB interface and endpoints for data transfer.

Using the Arduino IDE, you can implement a virtual USB storage device class as follows:

include

class USBStorageDevice {
public:
USBStorageDevice() {
// Initialize the USB device
USB.begin();
}

void write_data(uint8_t* data, uint16_t length) {
    // Write data to the virtual USB storage device
    USB.write(data, length);
}

uint16_t read_data(uint8_t* data) {
    // Read data from the virtual USB storage device
    return USB.read(data);
}

};
Step 3: Implement Data Transfer Mechanism

Implement a data transfer mechanism on the BLE module that allows data to be transferred between the BLE device and the computer. This mechanism should use the GATT protocol's write and read operations to transfer data.

Using the nRF5 SDK, you can implement a data transfer mechanism as follows:

void write_data(uint8_t* data, uint16_t length) {
// Write data to the BLE characteristic
ble_gatts_characteristic_write(&characteristic_handle, data, length);
}

uint16_t read_data(uint8_t* data) {
// Read data from the BLE characteristic
return ble_gatts_characteristic_read(&characteristic_handle, data);
}
Step 4: Connect to the Computer

Connect the BLE device to the computer and use the virtual USB device class and data transfer mechanism to transfer data between the devices.

Using the Arduino IDE, you can connect to the computer as follows:

include

USBStorageDevice usb_device;

void setup() {
// Initialize the USB device
usb_device.begin();
}

void loop() {
// Wait for the computer to connect
if (usb_device.isConnected()) {
// Read data from the computer
uint8_t data[256];
uint16_t length = usb_device.read_data(data);

    // Write data to the BLE device
    write_data(data, length);
}

}
Step 5: Test Data Transfer

Test the data transfer mechanism by writing data to the BLE device and reading data from the computer.

Using the serial terminal, you can test the data transfer as follows:

Write data to the BLE device

echo "Hello, world!" > /dev/ttyUSB0

Read data from the BLE device

cat /dev/ttyUSB0
If everything is working correctly, you should see the data being transferred between the devices.

Conclusion

Emulating the USB protocol over BLE provides a convenient and efficient way to transfer data between devices. By following the implementation guide outlined in this blog, you can create a BLE device that communicates with a computer as if it were a physical USB device. This technology has numerous applications in IoT, wearables, and other low-power devices, and can enable new use cases and possibilities in the field of computer engineering.

Publication Survey: Security Considerations For Bluetooth Smart Devices

jason goose — Sun, 28 Jul 2024 01:54:24 +0000

article from tosdn

Bluetooth Smart is an emerging short range wireless technology aimed for low power devices. Bluetooth 4.2 core specification provides various methods to secure the communication between devices and establish trusted connections. This paper describes the design considerations to secure the Bluetooth smart devices.

Introduction

Bluetooth smart (also known as Bluetooth low energy or BLE) is introduced in the legacy Bluetooth 4.0 specification by Bluetooth special interest group. Bluetooth smart is primarily designed for low power embedded devices with limited computation capabilities. With expeditious growth in the IoT technology, Bluetooth Low Energy Module has become substantiate criterion for the smart devices.

Bluetooth specification supports the asymmetrical architecture of the LE devices. Memory and processing power requirements of peripheral devices are much lower than the central. This will be a great advantage in case of single mode - peripheral only devices. Device that acts always as peripheral can be designed with low memory, longer battery life and low power consumption. Low power smart wearable devices available in market such as Bluetooth heart rate monitors, blood pressure monitors, fitness kit, smart watches etc. run on a small coin cell battery for years.

Low energy, Low security

Like any other wireless technology, BLE is no exception from security threats. While Bluetooth LE beacons bring lots of potential in the IOT design, security threats such as device tracking, eaves dropping, and man in the middle attack are increasing significantly. BLE devices are designed to broadcast MAC, UUID and service information’s at a predefined interval. Due to continuous advertisement, hackers can easily track the device and decode the broadcasting information using a sniffers or even smart phone. Below Figure 1 indicates how a LE device can be tracked by the hacker and steal sensitive data over a period of time across various geographical locations.

With hacking and cybercrime reported enormously all over the world, people are extremely concerned about the privacy. Sensitive data getting in to the hands of the wrong people without user consent may lead to significant damages. For example, if such devices with serious security flaws are deployed in military, it can reveal the secrets to the rivals.

Figure 1 – LE devices without privacy

Threats for Bluetooth Smart

Passive Eavesdropping:

Passive eavesdropping is secretly listening to the private communication between two devices in real-time by un-authenticated third party devices (eavesdropping equipment). Using a 2.4GHZ channel sniffer, one can listen to all the communication between BLE devices without the consent of communicating devices. Since eavesdropping does not affect the normal communication between the devices, chances of user noticing eavesdropping attempt are extremely low. If unencrypted message or unsigned messages are used in communication, hacker can get direct access to all the confidential data exchanged between the devices. Pairing procedures are the well-known techniques to avoid the eavesdropping issues and encrypt the messages before exchange. But, if the attacker is listening to the devices during the pairing process itself, then pairing methods can’t assure the safety against the attack!

Man in the Middle (MITM):

In MITM, attacker secretly reads and interprets the messages from the sender and delivers the message to the reader after interpreting it. Since the attacker is actively involved in the communication between the devices, this attack is also known as active eavesdropping. During the course of attack, attacker may insert his own messages or corrupt the data before delivering it to the reader. Devices participating in the connection will assume that they are communicating with each other directly. But an intermediate MITM attacker has complete control over the communication of these devices. Public key cryptography can provide needed protection against MITM. But this method will fail, if an active MITM attacker listens to the shared public key during the initial pairing process and shares his own public Key instead of actual public key. A device which received the public key from attacker has no knowledge about the source of the key and hence it will encrypt and send the next message with the public key shared by the attacker. Now, the attacker can easily decrypt the messages and interpret it. Also, he may optionally decide to encrypt the message using the original public key and deliver to the initiator to keep the communication intact. Below figure-2 indicates how a hacker can attack the communication between two devices in MITM.

Figure 2 – MITM

Identity Tracking:

Bluetooth Low Energy 4.0 devices are designed for periodic advertisement of the status or its existence. Advertisement packet contains the MAC address of the broadcaster and unique service formation. It also contains information about the proximity of the device in terms of the signal strength. Using publicly available advertisement data and characteristics, attacker can extract large amount of information which may help him to track the devices based on these unique information.

Duplicate device:

An attacker with the knowledge of MAC address can make a dummy device with the same MAC address, which runs the dummy service. Such kind of attack is more dangerous in business and may lead to huge loss since customers will not be able to get the intended service.

Security architecture:

Security in Host:

Unlike classic Bluetooth, Bluetooth low energy sensors and devices implement the key management and security manager on host instead of controller. All the key generation and distributions of key are taken care by SMP running on host. This approach introduced by Bluetooth specification helps the host to be flexible and reduces the cost and complexity of LE-only controllers. Security manager:

Figure 3 – Security Manager

Bluetooth specification mandates a security manager in the protocol stack implementation. Security manger defines the authentication, pairing, encryption and signing between the Bluetooth low energy devices. This is responsible for all the security and privacy implementations of the BLE stack such as generation and storing various keys, generating random address and address resolution for the privacy feature. Security manager uses the services provided by the L2CAP layer to manage the security. Each device can generate its own key without any external influence and strength of the key is proportional to the algorithm implemented in the device

LE security modes:

Bluetooth Security requirements of the device and services are expressed in terms of security modes and security levels. Each service and device may have separate security requirement. A physical connection between two devices always operates in a single security mode. With wide adoption of 4.2 specifications, secure simple pairing methods have become de-facto requirement for the LE device to ensure security.

LE security mode 1:

Security level-1 and level-2 in these modes supports LE communication without security and encryption without pairing respectively. Level 3 and level 4 provides more security to the system than prior levels. LE secure connection (Level-4) introduced in Bluetooth SIG 4.2 specifications, brings in high security to the LE communication via Elliptic Curve Diffie-Hellman (ECDH) public key cryptography technique.

LE security mode 2:

Devices conform to security mode-2 supports both authenticated and unauthenticated pairing along with mandatory data signing. Data can be signed using various techniques including public key cryptography to ensure the data integrity and security.

Mixed Security mode:

For the devices which need both mode-1 and mode-2 security shall use mixed security mode. This enables the devices to use combination of multiple security modes such as data signing along with ECDH to provide enormous security to the smart devices.

Secure Connection Only mode:

When LE smart devices operates in secure connection only mode they shall use authenticated connection and pairing with encryption. Device shall only accept outgoing and incoming connections for services that use security mode-1, level 4. With this restriction, devices operating in this mode should use ECDH, introduced in 4.2 specifications.

Securing Bluetooth Smart: Pairing:

The association is done in three phases, which includes device capability exchange, LTK generation for secure Connection and transport specific key distribution. For legacy devices, STK is used instead of LTK.

Figure 4 - Pairing Process

Phase-1 (capability exchange):

The first step of pairing process is to exchange the identity and capability information to establish a trusted link between LE devices. Master initiates the pairing procedure by sending a pairing request to slaves. If security procedures are not initiated by the master, slave can request master for initiating it. Once the security requests are received by the slave, master re-initiates the pairing process.

Phase-2 (Secure Key Generation):

Selection of pairing method depends on capabilities exchanged in phase-1. Short Term Keys (STK) are generated based on selected pairing method such as just works, passkey entry and out of band. Generated secure key pairs (STK) will be used to establish a secure channel between the participating devices.

In legacy 2.0 standards, PIN based pairing method was introduced. In this method, users must enter the predefined 4-digit PIN code on both the devices. Devices will be paired on successful authentication of the PIN on both ends. These predefined PINs cannot be changed unless the next firmware upgrade. Since it is a fixed number, it is relatively easy for the hackers to interpret the messages and break the security of the system. Later in 2.1 specifications, Secure Simple Pairing (SSP) methods introduced to ensure both security and simplicity

Just Works:

In Just Work method, no key exchange between the devices and no user interaction required. This method is well suited if at-least one of the devices participating in the communication doesn’t have the user interface. This method provides no MITM protection.

Numeric comparison:

If both devices participating in the BLE connection have a display and at-least has Yes/No Key, then numeric comparison method can be used. A 6-digit randomly generated code will be displayed on each device. User need to press Yes/No after manually verifying the key’s displayed.

Pass Key Entry:

This method may be used for the devices with a display and other with the keypad or both devices with at-least numeric keypad. In first case, one device shows the 6-digit number and other receives the 6-digit input from user and in later case both devices receives 6-digit numeric input from the user. On successful authentication devices will be paired and provides MITM protection.

Out of Band:

Out of band pairing method is adopted by Bluetooth standards for the scenarios where both the devices participating in the communication have enabled out of band communication channel. All secret information’s and cryptographic keys will be exchanged out of the Bluetooth band. With the rapid growth of the NFC technology, NFC has become de-facto technology for Bluetooth OOB communications. Since NFC works at 13.56 MHz, Bluetooth sniffers on 2.4GHz bandwidth can’t listen to the information exchanged in the pairing process. Also, NFC is designed to operate over a very small distance up to 10cm, which makes it more suitable for security critical applications to avoid any MITM attacks.

Phase-3 (Transport Specific Key Distribution):

After STK generation and encrypting the links, transport specific keys are distributed. Keys to be distributed are determined by the parameters of pairing request and response. Keys exchanged in this phase may include LTK, IRK, the signature key etc.

Bonding:

Bonding is the process of creating the long term trusted relationship between the devices based on link key generated during pairing process. Long term key’s (LTK) are generated and stored on both the initiator and responder. These LTK’s must be used for all the subsequent communication between the same devices to ensure the data security.

Key Generation:

Host implements the necessary API’s on LE devices to generate the keys such as STK, LTK, IRK, CSRK etc. Unlike classic Bluetooth, controller is not involved any key generation methods in case of BLE. The host generates Private and Public key pair and secure connection will be created by taking the factors from both the devices participating creating the communication. Master and Slave exchanges Identity resolving Key (IRK) for device Identity and Connection Signature Resolving Key (CSRK) for Authentication of unencrypted data.

Encryption:

LE controller uses the keys generated by the host and encrypts the messages. Legacy controllers are designed to support to FIPS compliant 128-bit AES. Latest 4.2 LE specifications introduce Elliptic Curve Diffie-Hellman (ECDH) cryptography over earlier 128-bit AES. ECDH initially exchanges the keys over public insecure channel and then enables the secure channel communication between the devices participating in the process.

Signed Data:

BLE specification supports sending signed data over an unencrypted channel with trusted relationship. Even though devices are not paired, BLE devices can still maintain the privacy of data by signing it. The sender uses CSRK to sign the data and receiver verifies the signature. On successful verification of the signature, the receiver assumes that a message has arrived from a trusted source.

Privacy feature:

Devices are identified by a 48-bit MAC address compliant to IEEE. It is optional for the devices to implement either or both public address and private address. Public device address is broadcasted by the BLE device and hence increases the risk of security. Bluetooth devices provide the privacy feature to reduce the risk of device tracking based on identifier of the device. In legacy BLE systems, host implements the address generation and resolution. According to BLE 4.2 specification, private address generation and resolution are implemented in the controller. Privacy enabled devices are expected to support at-least one of the static device address or private address.

Static device address:

The static device address is randomly generated 48-bit address compliant to Bluetooth SIG specifications. Static address will be changed on every power cycle, and hence reduced the risk of tracking over power cycles. But the devices which are not power cycled for a long time may face higher security risk.

Private address:

Bluetooth SIG compliant private address is the recommended way of providing security to BLE devices. BLE specification supports resolvable private address and non-resolvable private address. Only requirement to have the non-resolvable private address is address shall not be equal to public address of the device. Non resolvable private addresses are typically used for beacons. To generate resolvable private address, devices needs to be paired, exchange the private address and IRK during the pairing process. Only paired devices can resolve this random address and thus possibilities of tracking the device over period of time is nullified. Private address is changed periodically based on a timer event and only a trusted device can resolve this address.

Directed advertising:

In directed advertising devices indicates both MAC address of the advertising device and MAC address of the devices it is advertising to. Advertiser invites the specific trusted device to re-connect, if required. Address used by the advertiser a special private address called as reconnect address. In legacy Bluetooth standards, reconnect address can be changed only based on user actions such as connect, disconnect, device power cycle etc. Latest 4.2 specifications supports timer based update of the reconnect address.

Authentication over proximity:

Received Signal Strength Indicator (RSSI) is the indication of beacon signal strength observed by the receiver. RSSI is a factor of transmitting power of broadcaster and the distance between broadcaster and receiver. As an additional safety measure for the BLE devices, signal strength monitor can be used to extract the distance between the broadcaster and the receiver and BLE devices with predefined range of RSSI only can be selected for communication. This method will reduce the risk of a being tracked or monitored or misleading by a hacker over a long distance. Since RSSI can vary greatly

depending on the usage conditions and environment, this method is specific to the usage conditions and deployment of the products.

Hidden MAC:

Bluetooth SIG introduced 4.2 standards with improved data exchange rate as well as security. Most of the major security features of the classic Bluetooth are adapted to Low Energy specifications. This specification hides the unique MAC address of the devices. Advertising LE devices need not broadcast their MAC address for identification purpose.

Conclusion

Compared to Legacy LE standards, 4.2 specifications introduce a new security model along with Secure Simple pairing. Security techniques like MAC address hiding, Elliptic Curve Diffie-Hellman based key exchange and LE secure connections ensures industry standards security for the LE device. Thus Bluetooth SIG 4.2 specifications ensured the smarter privacy approaches for the LE devices and now Bluetooth smart is more secure than ever.

Bluetooth Mesh Security Overview

jason goose — Sun, 28 Jul 2024 01:51:57 +0000

article from tosdn

The Criticality of Security
One of the most discussed issues related to the Internet of Things (IoT) is security. From agriculture to hospitals, from residential smart homes to commercial smart buildings, and from power stations to traffic management systems, IoT systems and technologies will touch many parts of the world we live in. Security breaches in IoT systems could have catastrophic consequences.

Bluetooth® mesh networking was designed with security as its number one priority and from the ground up. In this article, you’ll get an overview of the key security features and the security issues addressed. Further articles in the series will examine aspects of Bluetooth mesh networking security in more detail.

Security in Bluetooth Mesh Networking is Mandatory
Bluetooth® Low Energy (LE) GATT devices may implement a range of security measures as defined in the Bluetooth core specification. It’s the responsibility of the product designer to decide what security measures are required and it’s permissible to decide to adopt none of the available security features at all. In other words, security in Bluetooth Low Energy GATT is optional. This makes sense if we’re talking about the security of a single device and its connection with one other device, provided the product designer performs their risk assessment correctly. However, security in Bluetooth mesh networking is concerned with the security of more than individual devices or connections between peer devices; it’s concerned with the security of an entire network of devices and of various groupings of devices in the network.

Consequently, security in Bluetooth mesh networking is mandatory.

Bluetooth Mesh Networking Security Fundamentals
The following fundamental security statements apply to all Bluetooth mesh networks:

Encryption and Authentication

All Bluetooth mesh messages are encrypted and authenticated.

Separation of Concerns

Network security, application security, and device security are addressed independently. See Separation of Concerns below.

Area Isolation

A Bluetooth mesh network can be divided into subnets, each cryptographically distinct and secure from the others.

Key Refresh

Security keys can be changed during the life of the Bluetooth mesh network via a Key Refresh procedure.

Message Obfuscation

Message obfuscation makes it difficult to track messages sent within the network and, as such, provides a privacy mechanism to make it difficult to track nodes.

Replay Attack Protection

Bluetooth mesh security protects the network against replay attacks.

Trashcan Attack Protection

Nodes can be removed from the network securely, in a way which prevents trashcan attacks.

Secure Device Provisioning

The process by which devices are added to the Bluetooth mesh network to become nodes is a secure process.

Separation of Concerns and Security Keys
At the heart of Bluetooth® mesh security are three types of security keys. These keys provide security to different aspects of the Bluetooth mesh network and achieve a critical capability in Bluetooth mesh networking security called a separation of concerns.

Consider a mesh light which acts as a relay. In its capacity as a relay, it may find itself handling messages relating to the building’s Bluetooth mesh door and window security system. A light has no business accessing and processing the details of these messages, but it does need to relay them to other nodes.

To deal with this potential conflict of interest, Bluetooth mesh uses different security keys called AppKeys for securing messages at the network layer from those used to secure data relating to specific applications, such as lighting, physical security, heating, etc.

All nodes in a Bluetooth mesh network possess one or more Network Keys (NetKey), each corresponding to a subnet which may be the primary subnet. It’s possession of a network key which makes a node a member of the network. Network Encryption Keys and Privacy Keys are derived directly from the NetKey.

Being in possession of a NetKey allows a node to decrypt and authenticate up to the Network Layer so that network functions, such as relaying, can be carried out. It does not allow application data to be decrypted.

Each node also has a unique security key called the Device Key or DevKey. The DevKey is used in the provisioning and configuration of the node.

Area Isolation
Possession of the primary NetKey defines membership of and grants access to the Bluetooth® mesh network. But it’s also possible to divide the network into distinct subnets, each with its own subnet key. This means that only devices in possession of a given subnet key can communicate with other devices that are members of that subnet. Subnet keys can be created and assigned on an adhoc basis too. A great example is isolating nodes in different hotel rooms from each other.

Node Removal, Key Refresh, and Trashcan Attacks
As described above, nodes contain various Bluetooth® mesh security keys. Should a node become faulty and need to be disposed of, or if the owner decides to sell the node to another owner, it’s important that the device and the keys it contains cannot be used to mount an attack on the network the node was taken from.

Bluetooth mesh networking ensures devices can be disposed of securely
A procedure for removing a node from a network is defined. The Provisioner application is used to add the node to a reject list and then a Key Refresh Procedure is initiated.

The Key Refresh Procedure issues all nodes in the network, except those which are members of the reject list, new network keys, application keys, and all related, derived data. In other words, the entire set of security keys which form the basis for network and application security are replaced.

As such, a node which was removed from the network, and which contains an old NetKey and old set of AppKeys, is no longer a member of the network and poses no threat.

Privacy
A Privacy Key, derived from the NetKey, is used to obfuscate network PDU header values, such as the source address. Obfuscation ensures that casual, passive eavesdropping cannot be used to track nodes and the people using them. It also makes attacks based upon traffic analysis difficult.

Replay Attacks
In network security, a replay attack is a technique whereby an eavesdropper intercepts and captures one or more messages and simply retransmits them later, with the goal of tricking the recipient into carrying out something which the attacking device is not authorized to do. A commonly cited example is a car’s keyless entry system being compromised by an attacker who intercepts the authentication sequence between the car’s owner and the car, later replaying those messages to gain entry to the car and steal it.

Bluetooth® mesh networking protects against replay attacks by using two network PDU fields called the Sequence Number (SEQ) and IV Index. Elements increment the SEQ value every time they publish a message. A node which receives a message from an element containing an SEQ value less than or equal to that of the last valid message will discard it since it likely relates to a replay attack. Similarly, IV Index is a separate field considered alongside SEQ. IV Index values within messages from a given element must always be equal to or greater than the last valid message from that element.

Cryptography Toolbox
Most of the security features of Bluetooth mesh networking rely upon industry-standard cryptographic algorithms and procedures. Reference will be made to them in other security-related articles in this series, but we’ll explain the most important ones here.

There are two key security functions used in the Bluetooth mesh stack: AES-CMAC and AES-CCM. These are fundamental encryption and authentication functions, and all other functions used for key generation are based upon them.

AES-CMAC
Cipher-based Message Authentication Code (CMAC) is an algorithm which can generate a fixed length, 128-bit message authentication value for any variable length input. The formula for generating a message authentication code MAC using the AES-CMAC algorithm is written as:

    MAC = AES-CMACk(m)

The inputs to AES-CMAC are:

k – the 128-bit key.
m – the variable length data to be authenticated.

AES-CMAC has excellent error-detection capabilities. Other techniques, involving the verification of a checksum or use of an error-detecting code, may detect only accidental modifications of the data. AES-CMAC is designed to detect intentional, unauthorized modifications of the data, as well as accidental modifications. If you are interested in learning more about this function, please refer to RFC4493 which defines it.

AES-CCM
AES-CCM is a generic, authenticated encryption algorithm, intended for use with cryptographic block ciphers. In the Bluetooth mesh specification, AES-CCM is used as the basic encryption and authentication function in all cases. The formula for its use is as follows:

ciphertext , MIC = AES-CCMk (n,m,a)

There are four inputs to AES-CCM:

          k – the 128-bit key.

          n – a 104-bit nonce.

          m – the variable length data to be encrypted and authenticated.

a – the variable length data to be authenticated but not encrypted, also known as Additional Data. This input parameter may be zero bytes in length.

There are two outputs from AES-CCM:

          ciphertext – the variable length data after it has been encrypted.

          MIC – the Message Integrity Check value of m and a.

Figure 1 shows a plain-text payload, which may be from the Bluetooth® mesh network layer or upper transport layer, being processed by AES-CCM with an input encryption key, nonce, and plaintext payload. An encrypted payload and MIC is output.

Figure 1 – AES-CCM used for packet payload encryption and authentication
SALT Generation
Bluetooth® mesh security defines a SALT generation function known as s1, which uses the AES-CMAC function. As explained above, AES-CMAC has two input parameters: k and m. When used for SALT generation though, only the input parameter m varies. k is always set to the 128-bit value: 0x0000 0000 0000 0000 0000 0000 0000 0000, which is referred to as ZERO in the Bluetooth mesh specification.

Figure 2 – The SALT generation function
The input to the SALT generation function is:

          m – a non-zero length octet array or ASCII encoded string.

The output is a 128-bit MAC value and the s1 formula is written as:

s1(m) = AES-CMACZERO(m)

Other security functions
In the Bluetooth mesh networking specification section 3.8.2, Security Toolbox, you will find other security functions defined, such as various key derivation functions. All of them are based on AES-CMAC and the SALT generation function, s1 (the SALT generation function is also based on AES-CMAC).

Onwards!
Security is an important issue for Bluetooth, and the topic will come up repeatedly in our series on Bluetooth mesh networking. After reading this article, you should have a good understanding of the primary Bluetooth® mesh networking security features and some of the underlying cryptography techniques involved. You’re now ready to take a deeper dive into Bluetooth mesh network security when we cover the subject in future articles.