Secure Design for Low Energy Bluetooth (BLE) Applications

 Low Energy Bluetooth (BLE) is widely used in various smart devices and IoT scenarios as a low-power, short-range wireless communication technology. However, due to the characteristics of BLE, it is susceptible to various security threats. Therefore, when designing and developing BLE applications, it is crucial to focus on security issues and implement appropriate security measures to protect communication data and user privacy.

Firstly, Security Measures for Bluetooth Pairing

In the pairing process between BLE devices, it is essential to use FIPS-approved algorithms such as AES-CMAC and P-256 elliptic curve to ensure the security of pairing information. Pairing information should be stored in a secure storage location on the device to prevent malicious attackers from stealing it.
For authentication and encryption, FIPS-approved algorithms should also be used to ensure the confidentiality and integrity of communication data. For example, the use of AES-CCM algorithm can encrypt and protect data transmission, while also ensuring the integrity of messages. In healthcare devices, such as a health wristband communicating with a smartphone, the use of AES-CCM algorithm encrypts the user's health data to ensure its confidentiality.
To prevent passive eavesdropping and man-in-the-middle attacks, user-assisted secure simple pairing methods can be used. For instance, using the ECDHE algorithm for Simple Secure Pairing (SSP) to prevent passive eavesdropping attacks, and employing the user-assisted digital method Passkey Entry to prevent man-in-the-middle attacks.
Here is the description of the Bluetooth Simple Secure Pairing (SSP) implementation example:
Device Preparation
• Device A (Initiator): a Bluetooth device, such as a smartphone.
• Device B (Responder): a Bluetooth device, such as a Bluetooth speaker.
Pairing Steps
1. Device A and Device B both support Bluetooth 2.1 or higher and SSP.
2. Device A and Device B are both in discoverable mode, ready to pair.
3. Device A sends a pairing request to Device B, and Device B starts the pairing process upon receiving the request.
Pairing Process
1. Device B generates a random number (Nonce) and sends it to Device A.
2. Device A receives the random number and generates its own random number (Nonce), which is sent to Device B.
3. Device A and Device B both use their own random numbers and the other's random number to calculate a shared secret key (Shared Secret).
4. Device A and Device B both use the shared secret key to calculate a pairing key (Pairing Key).
5. Device A and Device B both use the pairing key to encrypt their identity information (Identity Information) and send it to each other.
6. Device A and Device B both verify each other's identity information, and if the verification is successful, the pairing is complete.
Verification Steps
1. Device A and Device B both compare the other's identity information with their own, and if they match, the verification is successful.
2. Device A and Device B both store the pairing key in their devices for future connections.

Secondly, Security Measures for Bluetooth Privacy

To protect the privacy of BLE devices, address randomization can enhance device security. By frequently changing the Bluetooth device address, it reduces the difficulty for attackers to track BLE devices over a long period. Furthermore, to reconnect known devices, the device's private address must be resolvable by other devices, which requires using the device identity resolution key exchanged during pairing to generate the private address. For example, in a retail store's iBeacon system, changing the iBeacon device's Bluetooth address frequently can prevent malicious tracking of user behavior, thus protecting user privacy.
Here is the implementation example:
Device A (BLE Device)
• Hardware: BLE microcontroller with a random number generator (RNG)
• Software: BLE stack with address randomization and pairing process implementation
Device B (Central Device)
• Hardware: BLE microcontroller with a random number generator (RNG)
• Software: BLE stack with pairing process implementation and device identity resolution key storage
Address Randomization Process
1. Device A generates a new random address (RA) using its RNG.
2. Device A sets the new RA as its Bluetooth address.
3. Device A stores the RA and a corresponding index (e.g., a counter) in its memory.
Pairing Process
1. Device A and Device B initiate a pairing process using a standard BLE pairing protocol (e.g., SMP).
2. During the pairing process, Device A and Device B exchange their respective public keys (PK_A and PK_B).
3. Device A and Device B use their public keys to generate a shared secret key (SSK) using a key agreement protocol (e.g., ECDH).
4. Device A and Device B use the SSK to generate a device identity resolution key (DIRK).
5. Device A and Device B store the DIRK in their respective memories.
Private Address Generation
1. Device A uses its RNG to generate a new private address (PA) based on the RA and the DIRK.
2. Device A sets the PA as its new Bluetooth address.
Reconnection Process
1. When Device B wants to reconnect to Device A, it uses the DIRK to generate the PA.
2. Device B sends a connection request to the PA.
3. Device A receives the connection request and verifies the PA using the DIRK.
4. If the verification is successful, Device A accepts the connection request and the two devices reconnect.
Security Benefits
• The frequent change of the Bluetooth address (RA) makes it difficult for an attacker to track the device for an extended period.
• The use of the DIRK to generate the PA ensures that only authorized devices can resolve the private address and reconnect to the device.
• The private address (PA) is not publicly visible, protecting the device's privacy.
This implementation example demonstrates how address randomization and private address generation using a device identity resolution key can enhance the security and privacy of BLE devices.

Thirdly, Security Measures for Bluetooth Denial of Service Attacks

A common form of Bluetooth denial of service attack involves attackers continuously maliciously connecting or pairing with Bluetooth devices, causing the Bluetooth channel to be occupied and therefore unusable. To prevent denial of service attacks, a Bluetooth firewall mechanism can be used. When faced with denial of service attacks, enabling a whitelist mechanism and gradually increasing the delay time for new pairing can prevent continuous brute-force attacks by malicious devices. During the delay period, only devices within the whitelist are allowed to connect, ensuring the availability of Bluetooth services. 

For example, the following is an example of the protection measures inspired by iPhone 6S unlocking attacks prevention using increasing delay times to prevent continuous brute-force attacks that render Bluetooth services unavailable. The attempt number resets after a successful connection or pairing.

ATTEMPT NUMBER	NEW CONNECTION PAIRING EXECUTION DELAY
1-4	None
5-9	1 minute
10-14	10 minutes
15	1 hour
16-∞	1 hour (max delay)

Fourthly, Security Measures for Bluetooth Relay Attacks

Relay attacks are a common Bluetooth security threat where attackers use a relay device to pass communication data between communication parties, aiming to steal sensitive information or execute malicious operations. Limiting the communication distance between BLE devices can effectively prevent relay attacks. By controlling the transmission power of BLE devices or using location technologies, the distance between communication parties can be kept within a controllable range, reducing the likelihood of relay attacks.
Implementation Example:
Device A (BLE Device)
• Hardware: BLE microcontroller with a power amplifier and a distance measurement unit (e.g., RSSI or TOF)
• Software: BLE stack with transmit power control and distance measurement implementation
Device B (BLE Device)
• Hardware: BLE microcontroller with a power amplifier and a distance measurement unit (e.g., RSSI or TOF)
• Software: BLE stack with transmit power control and distance measurement implementation
Distance-based Relay Attack Prevention
1. Device A and Device B are configured to operate at a minimum transmit power level to ensure a maximum communication distance of a given meter.
2. When Device A and Device B are paired, they exchange their respective transmit power levels and distance measurement parameters.
3. During communication, Device A and Device B continuously measure the received signal strength (RSSI) or time of flight (TOF) to estimate the distance between them.
4. If the estimated distance exceeds a predefined threshold (e.g., 2 meters), Device A and Device B will reduce their transmit power levels to minimize the communication distance.
5. If the estimated distance continues to exceed the threshold, Device A and Device B will terminate the connection to prevent a potential relay attack.

In conclusion, the application of secure design for low energy Bluetooth (BLE) needs to comprehensively consider security mechanisms such as pairing, binding, authentication, encryption, message integrity, relay protection, Bluetooth privacy, and firewall to ensure the security and reliability of BLE communication. Only by fully considering security during product design and development can potential security threats be effectively mitigated, safeguarding the security of user data and privacy.

Key2.0: Open Source Bluetooth IoT Door Lock

 

What is Key 2.0?

Key 2.0 (or Key20 for short) is a Bluetooth IoT Door Lock controller. It turns a conventional electric door lock into a smart door lock that can be opened using a smartphone without the need for a physical key. Thus, Key20 is the modern version of a physical key, or, as the name suggests, the key version 2.0 for the Internet of Things (IoT) era.

Key20 consists of two parts:

1. Key20 door lock controller device, which is physically connected to the electric door lock and wirelessly via BLE to the mobile app.
2. Key20 mobile app implementing the user interface to unlock the door and communicating with the door lock controller through BLE.

         [ Mobile Phone w/ ]
         [    Key20 App    ]
               |
               | Bluetooth Low Energy (BLE) Connection
               |
 |---[ Key20 Door Lock Controller ]---[ Electric Door Lock ]---|
 |   [           Device           ]                            |
 |                                                             |
 |                                                             |
 |                                                             |
 |----------------------(Voltage Source)-----------------------|
                        (    12 VAC    )

The following image shows the Key20 door lock controller device and the Key20 app running on a smartphone.

You can get a quick impression on how Key20 works watching the following video:

Key 2.0 Video

The main features of Key20 are:

• Using state-of-the-art security mechanisms (Elliptic Curve Diffie-Hellman Key Exchange (ECDH), HMAC) to protect against attacks.
• Open-source software and hardware, including an open implementation of the security mechanisms. No security by obscurity! Source code for the app and door lock controller as well as Eagle files (schematic and board layout) are provided.
• Maker-friendly: using easily available cheap standard components (nRF51822 BLE chip, standard electronic parts), easy to manufacture circuit board, and open-source software and hardware design.
• Works with BLE-enabled Android 4.3 mobile devices (and of course newer versions). Porting to other mobile operating systems like iOS should be straightforward.
• Liberal licensing of software and hardware under the Apache License 2.0 and the CERN Open Hardware License 1.0, respectively.

Security Concepts

A door lock obviously requires security mechanisms to protect from unauthorized requests to open the door. To this end, Key20 implements the following state of the art security mechanisms.

Authorization of Door Open Requests with HMAC

All door open requests are authorized through a Keyed Hash Message Authentication Code (HMAC). A 16 byte nonce (big random number) is generated by the door lock controller for each door open request as soon as a BLE connection is made to the door lock controller. The nonce is sent to the mobile app. Both, the nonce and the shared secret, are used by the mobile app to calculate a 512 bit HMAC using the SHA-2 hashing algorithm, which is then truncated to 256 bits (HMAC512-256), and sent to the door lock controller. The door lock controller also calculates an HMAC based on the nonce and the shared secret, and only if both HMACs match, the door will be opened.

The nonce is only valid for one door open request and effectively prevents replay attacks, i.e., an attacker sniffing on the radio channel and replaying the sniffed HMAC later. Note that the BLE radio communication is not encrypted, and it actually does not need to be encrypted since a captured HMAC is useless when re-played.

Moreover, each nonce is only valid for 15 s to prevent man-in-the-middle attacks where an attacker intercepts the HMAC and does not forward it immediatelly but waits until the (authorized) user walks away after he is not able to open the door. Later the attacker would then send the HMAC to the door lock controller to open the door. With a time window of only 15 s (which could be reduced further), such attacks are futile since the authorized user will still be at the door.

Note that the whole authentication procedure does not include heavy-weight asymmetric crypto functions, but only light-weight hashing algorithms, which can be performed on the door lock device featuring an nRF51822 micro-controller (ARM Cortex M0) very fast in order not to delay door unlocking.

With respect to the random nonce we would like to note the following. First, the nRF51822 chip includes a random number generator for generating random numbers from thermal noise, so nonces should be of high quality, i.e., truly random. An attack by cooling down the Bluetooth chip to reduce randomness due to thermal noise is not relevant here since this requires physical access to the lock controller installed within the building, i.e., the attacker is then already in your house.

Secondly, 128 bit nonces provide reasonable security for our purpose. Assume one door open request per millisecond (very pessimistic assumption!) and 100 years of operation, i.e., less than n = 2^42 requests to be protected. With 128 bit nonces, we have m = 2^128 possible nonce values. Then the birthday paradox can be used to calculate the probability p of at least one pair of requests sharing the same nonce, or, inversely, no nonces shared by any pair of requests. An approximation of p for n << m is p(n,m) = 1 - e^((-n2)/(2*m)), which practically evaluates to 0 for n = 2^42 and m = 2^128. Even for n = 2^52 (one request per us; actually not possible with BLE), p(2^52,2128) < 3e-8, which is about the probability to be hit by lightning, which is about 5.5e-8.

Exchanging Keys with Elliptic Curve Diffie Hellman Key Exchange (ECDH)

Obviously, the critical part is the establishment of a shared secret between the door lock controller and the mobile app. Anybody in possession of the shared secret can enter the building, thus, we must ensure that only the lock controller and the Key20 app know the secret. To this end, we use Elliptic Curve Diffie-Hellman (ECDH) key exchange based on Curve 25519. We assume that the door lock controller is installed inside the building that is secured by the lock---if the attacker is already in your home, the door lock is futile anyway. Thus, only the authorized user (owner of the building) has physical access to the door lock controller.

First, the user needs to press a button on the door lock controller device to enter key exchange mode (the red button in the pictures). Then both, the mobile app and the door lock controller calculate different key pairs based on the Elliptic Curve 25519 and exchange their public keys, which anyone can know. Using the public key of the other party and their own private keys, the lock controller and the app can calculate the same shared secret.

Using Curve 25519 and the Curve 25519 assembler implementation optimized for ARM Cortex-M0 from the Micro NaCl project, key pairs and shared secrets can be calculated in sub-seconds on the nRF51822 BLE chip (ARM Cortex M0).

Without further measures, DH is susceptible to man-in-the-middle attacks where an attacker actively manipulates the communication between mobile app and door lock controller. With such attacks, the attacker could exchange his own public key with both, the lock controller and the app to establish two shared secrets between him and the door lock controller, and between him and the mobile app. We prevent such attacks with the following mechanism. After key exchange, the mobile app and the door lock device both display a checksum (hash) of their version of the exchanged shared secret. The user will visually check these checksums to verify that they are the same. If they are the same, no man-in-the-middle attack has happened since the man in the middle cannot calculate the same shared secret as the door lock controller and the mobile app (after all, the private keys of door lock controller and mobile app remain private). Only then the user will confirm the key by pressing buttons on the door lock controller and the mobile app. Remember that only the authorized user has physical access to the door lock controller since it is installed within the building to be secured by the lock.

The following image shows the mobile app and the door lock controller displaying a shared secret checksum after key exchange. The user can confirm this secret by pushing the green button the the lock controller device and the Confirm Key button of the app.

Why not Standard Bluetooth Security?

Actually, Bluetooth 4.2 implements security concepts similar to the mechanisms described above. So it is a valid question why don't we just rely on the security concepts implemented by Bluetooth?

A good overview why Bluetooth might not be as secure as we would like it to be is provided by Francisco Corella. So we refer the interested reader to his page for the technical details and a discussion of Bluetooth security. We also would like to add that many mobile devices still do not implement Bluetooth 4.2 but only Bluetooth 4.0, which is even less secure than Bluetooth 4.2.

So we decided not to rely on Bluetooth security mechanisms, but rather implement all security protocols on the application layer using state of the art security mechanisms as described above.

Bluetooth Door Lock Controller Device

The Door Lock Controller Device needs to be connected to the electric door lock (2 cables). You can simply replace a manual switch by the door lock controller device.

The door lock controller needs to be placed in Bluetooth radio range to the door and inside the building. Typical radio ranges are about 10 m. Depending on the walls, the distance might be shorter or longer. In our experience, one concrete wall is no problem, but two might block the radio signal.

Door Lock Controller Hardware

The door lock controller hardware is designed for operating AC (alternating current) electric door locks, which typically run from 6-12 VAC.

The hardware design (schematics and board layout for Eagle) for the door lock controller device can be found in folder pcb/key20-ble.

The following images show the hardware and schematic. The hardware basically concists of one circuit board (PCB). We deliberately used a simple single-sided through-hole design to help makers producing their own boards. An LCD, a power switch, and two push buttons for user interaction are connected to the main PCB. An ob-board voltage regulator provides 3.3 V fed by an external DC power supply (anything between 4 V and 30 V will work). The circuit draws less than 50 mA when the lock is operated, thus, you can use a cheap 5.0 V USB power supply. With a little modification, we could also switch off the LCD when not needed, and the device could run from 4 AA-size batteries most probably for years.

The main part of the hardware is an nRF51822 BLE chip from Nordic Semiconductors. You can buy so-called "Bluetooth 4.0" breakout boards with an nRF51822 (version 3, variant AA w/ 16 kB of RAM and 256 kB flash memory) and two 2x9 connectors (2 mm pitch) for about 6 US$ including shipping. To connect the Bluetooth 4.0 board hosting the nRF51822, the PCB has two 2x9 pin connectors (no SMD soldering required). The nRF51822 features an ARM Cortex M0 micro-controller and a so-called softdevice implementing the Bluetooth stack, which runs together with the application logic on the ARM Cortex M0 processor. Key20 uses the S110 softdevice version 8.0 (see next sub-section on how to flash the softdevice and the Key20 application code).

The nRF51822 operates the electric door lock through a TRIAC. Note that most electric door locks use alternating current (AC), so a transistor will not work. We have added a snubber circuit (capacitor and resistor) to drive the inductive load (electric door lock) since TRIACs are sensitive to sudden voltage jumps possibly leading to unwanted turn-on, i.e., door unlocking. The TRIAC is operated in quadrant 2 and 3 (current flowing out of the gate) to avoid the less sensitive quadrant 4. Since the TRIAC needs about 30 mA to trigger reliably, a transistor is used to drive the TRIAC by the nRF51822, reducing the current on the micro-controller's GPIO to less than 1 mA.

Note that our design is targeting electric door locks using small AC voltages (typically 6-12 V AC). Theoretically, the TRIAC can drive 230 V loads up to 16 A. However, for safe 230 V and higer current operation the design has to be adapted, e.g., X2 snubber capacitor, isolation of the low-voltage part (3.3 V microcontroller) from the 230 V part through an opto-TRIAC, larger trace width and distances, etc.

An LCD is used to implement the secure key exchange procedure described above (visual key verification to avoid man-in-the-middle attacks). We used a common HD44780-compatible LCD display with 2x16 characters (1602A, 2-3 US$ including shipping). The LCD is connected to the main PCB through a ribbon cable. We designed a custom adapter board for connecting and mounting the 1602A LCD (see folder pcb/lcd1602a-connector).

Lock Controller Software

Overview

The software for the door lock controller can be found in folder nrf51.

Keys (shared secrets) are persistently stored in flash. Currently, we store 4 keys, but you can easily increase this number up to the limit of the flash size (nRF51822 version 3, variant AA comes with 256 kB flash, and each key consumes only 32 bytes).

Application events and a state machine approach are used to implement the application logic. Events are handled outside the interrupt context to avoid blocking the softdevice. In particular, actions like calculating keys or hashes can take significant time, although the crypto implementations used by Key20 can also process such compute-heavy tasks in just hundreds of milliseconds.

A lean-and-mean library was implemented for the nRF51822 chip to drive the LCD.

For more details, please have a look at the source code.

Prerequisites for Building the Software

No heavy-weight IDE is required to build the code. However, still a few tools are required to build and flash the code (tested with the given version numbers):

• nRF51 SDK, version 10.0.0
• nRF5x Command Line Tools, version 8.2.0
• Softdevice S110, version 8.0.0
• Flashing and debugging hardware, e.g., Segger J-Link EDU (about 50 US$, only for non-commerical use!). The nRF51 Developers Kit (DK) comes with an on-board Segger programmer, but for flashing the Key20 board, you need an external programmer like the J-Link EDU.
• Tool chain (compiler, linker, etc.) for ARM

Building and Flashing the Software

First, adapt the Makefile by defining the following variables:

• NRF51_SDK: path to the nRF51 SDK directory
• CROSS: path to the compiler tools
• CFLAGS: add -DTARGET_BOARD_NRF51DK if you compile for the nRF51 Development Kit (DK); if this definition is not set, you compile for the Key20 board.
• LINKER_SCRIPT: set to nrf51422_ac_s110.ld for the nRF51 DK (nRF51422, variant AC) or to nrf51822_aa_s110.ld for the Key20 board (nRF51822, variant AA).

Compiling the code:

$ cd nrf51
$ make

Flashing the softdevice:

$ nrfjprog --family NRF51 --program s110_nrf51_8.0.0_softdevice.hex --chiperase --verify

Flashing the application:

nrfjprog --family NRF51 --program key20.hex --verify --sectorerase

Rebooting after flashing:

nrfjprog -r

Android App

The source code of the Key20 app for Android can be found in folder android/Key20. The code was developed with Android Studio 2.1.

The app requires a BLE-enabled mobile device running Android version 4.3 "Jelly Bean" (API level 18) or higher.

The following images show the two major tabs of the app: one for opening the door, and the second for exchanging keys between the app and the door lock controller.

Zigbee Technology: A Comprehensive Review of its History, Technology, Applications, and Future Directions

 Zigbee is a low-power, low-data-rate wireless communication technology that has been gaining popularity in recent years due to its ability to enable wireless communication between devices over short distances. In this article, we will delve into the history of Zigbee, its technology, applications, and future directions, providing a comprehensive review of this exciting technology.

History of Zigbee

The concept of Zigbee was first introduced in the late 1990s by a group of companies, including Motorola, Intel, and Philips, who formed the Zigbee Alliance. The goal of the alliance was to develop a wireless communication technology that could enable low-power, low-data-rate communication between devices over short distances. The first Zigbee standard, Zigbee 1.0, was released in 2004, followed by subsequent updates, including Zigbee 1.1, Zigbee 1.2, and Zigbee 3.0.

Zigbee Technology

Zigbee is a wireless communication technology that operates on the 2.4 GHz frequency band, using a mesh networking topology. The technology is designed to enable low-power, low-data-rate communication between devices, making it ideal for applications that require low power consumption and low data transfer rates.

Zigbee devices can operate in one of three modes: coordinator, router, and end device. The coordinator is the central device that manages the network, while routers act as intermediaries to extend the range of the network. End devices are the devices that communicate with the coordinator and routers to exchange data.

Zigbee technology has several advantages, including:

Low power consumption: Zigbee devices can operate for years on a single battery, making them ideal for battery-powered devices.
Low cost: Zigbee devices are relatively inexpensive compared to other wireless communication technologies.
Low data rate: Zigbee technology is designed for low-data-rate applications, making it ideal for applications that require low data transfer rates.

Applications of Zigbee

Zigbee technology has a wide range of applications, including:

Home automation: Zigbee is widely used in home automation systems to enable wireless communication between devices, such as lighting systems, thermostats, and security systems.
Industrial control: Zigbee is used in industrial control systems to enable wireless communication between devices, such as sensors, actuators, and controllers.
IoT devices: Zigbee is used in IoT devices, such as smart sensors, smart meters, and smart locks, to enable wireless communication between devices.
Wearable devices: Zigbee is used in wearable devices, such as fitness trackers and smartwatches, to enable wireless communication between devices.

Future Directions of Zigbee

The future of Zigbee technology looks promising, with several trends and developments expected to shape the industry:

Increased adoption of Zigbee in IoT devices: As the IoT market continues to grow, the demand for low-power, low-data-rate wireless communication technologies like Zigbee is expected to increase.
Development of new Zigbee standards: The Zigbee Alliance is continuously working on developing new standards and updates to the technology, including Zigbee 3.0, which offers improved performance and security.
Integration with other technologies: Zigbee is expected to be integrated with other technologies, such as Wi-Fi, Bluetooth, and NFC, to enable seamless communication between devices.
Increased focus on security: As Zigbee technology becomes more widespread, the need for secure communication protocols and encryption methods will become increasingly important.

In conclusion, Zigbee technology has come a long way since its inception in the late 1990s. With its low power consumption, low cost, and low data rate, Zigbee has become an ideal technology for applications that require wireless communication over short distances. As the technology continues to evolve, we can expect to see new developments and innovations that will shape the future of Zigbee.

Bluetooth Categories: Understanding Classic and Low Energy Bluetooth

 Bluetooth technology has become extremely popular in recent years as a wireless personal area network technology, widely used for data exchange and communication between various devices. Bluetooth technology can be categorized into two main types: Classic Bluetooth and Bluetooth Low Energy (BLE).

Classic Bluetooth

Classic Bluetooth is the early version of Bluetooth technology, released in 1998. Its primary features include high-speed data transfer and real-time voice transmission, making it suitable for applications that require high-speed data transfer and real-time communication. Classic Bluetooth's maximum data transfer rate can reach up to 723KB/s, making it ideal for audio and video streaming.

The applications of Classic Bluetooth are diverse, including:

Wireless headsets and speakers: Classic Bluetooth provides high-quality audio transmission, making it suitable for wireless headsets and speakers.
File transfer between mobile phones and computers: Classic Bluetooth enables fast file transfer, making it ideal for transferring large files between mobile phones and computers.
Game controllers: Classic Bluetooth provides real-time data transmission, making it suitable for game controllers and game consoles.

However, Classic Bluetooth also has some drawbacks, including:

High power consumption: Classic Bluetooth requires relatively high power consumption, which can affect the battery life of devices.
Complex connection process: The connection process of Classic Bluetooth is relatively complex, requiring devices to undergo complex authentication and encryption.

Bluetooth Low Energy (BLE)

Bluetooth Low Energy is the latest version of Bluetooth technology, released in 2010. Its primary features include low power consumption and low cost, making it suitable for applications that require low power consumption and low cost. BLE's maximum data transfer rate can reach up to 1MB/s, making it ideal for small data packet transmission.

The applications of BLE are diverse, including:

Wearable devices: BLE provides low power consumption, making it suitable for wearable devices such as smartwatches and smart rings.
Smart home devices: BLE provides low power consumption and low cost, making it suitable for smart home devices such as smart light bulbs and smart thermostats.
Medical devices: BLE provides low power consumption and low cost, making it suitable for medical devices such as blood glucose monitors and heart rate monitors.

The advantages of BLE include:

Low power consumption: BLE provides extremely low power consumption, making it suitable for devices that require long battery life.
Simple connection process: The connection process of BLE is relatively simple, making it ideal for applications that require fast connection.

However, BLE also has some drawbacks, including:

Low data transfer rate: BLE's data transfer rate is relatively low, making it suitable for small data packet transmission.
Not suitable for real-time voice transmission: BLE is not suitable for real-time voice transmission, making it ideal for small data packet transmission.

In conclusion, Classic Bluetooth and BLE are both important components of Bluetooth technology, each suitable for different application scenarios. Classic Bluetooth is suitable for applications that require high-speed data transfer and real-time voice transmission, while BLE is suitable for applications that require low power consumption and low cost.