Using BLE Advertisement Data to Implement a Low-Power Proximity Keyless Entry System for Automotive Accessories

Modern automotive accessories increasingly demand secure, low-power, and intuitive access mechanisms. Bluetooth Low Energy (BLE) advertisement data provides an ideal foundation for implementing proximity-based keyless entry systems. Unlike traditional passive keyless entry (PKE) systems that rely on LF (Low Frequency) magnetic fields, BLE-based solutions leverage standard smartphone hardware, reduce accessory cost, and enable flexible software-defined security. This article presents a technical deep-dive into designing a low-power proximity keyless entry system using BLE advertisement packets, targeting embedded developers working on automotive accessories such as smart car covers, bike racks, trailer locks, or aftermarket door modules.

System Architecture Overview

A BLE proximity keyless entry system consists of two primary roles: the Accessory (Peripheral) and the Keyfob/Smartphone (Central). The accessory periodically transmits BLE advertisement packets containing a unique identifier and a cryptographic challenge. The central device, upon receiving these packets, calculates the Received Signal Strength Indicator (RSSI) to estimate proximity. If the RSSI exceeds a predefined threshold and the cryptographic handshake is validated, the central device sends a connection request or an authenticated command to unlock/activate the accessory. The entire system must operate with extremely low power consumption on the accessory side, often targeting coin-cell battery life of 1-2 years.

Key design considerations include advertisement interval tuning, payload size optimization, RSSI filtering for reliable proximity detection, and energy-efficient security protocols. The following sections break down each component with technical details and code examples.

BLE Advertisement Payload Design for Proximity and Security

BLE advertisement packets have a maximum payload of 31 bytes per advertisement channel (37, 38, 39). To minimize power consumption, the payload must be as small as possible while still carrying necessary data. A typical proximity keyless entry advertisement packet contains:

• Flags (1 byte): Indicates LE General Discoverable Mode and BR/EDR Not Supported.
• Local Name (variable): Optional, but can be used for device identification. Keep under 8 bytes to save space.
• Manufacturer Specific Data (variable): This is the core. It includes a company identifier (2 bytes), a rolling code or nonce (4-8 bytes), and a Message Authentication Code (MAC) (4-8 bytes).
• Service UUID (optional): A 16-bit or 128-bit UUID to filter for the specific accessory.

For security, we implement a challenge-response mechanism embedded directly in the advertisement data. The accessory generates a random nonce (4 bytes) and computes an AES-128 CMAC (Cipher-based Message Authentication Code) over the nonce and a pre-shared key. The central device receives the advertisement, extracts the nonce, computes the expected CMAC using the same key, and compares it. This prevents replay attacks and ensures only authorized devices can trigger the unlock command. The CMAC is truncated to 4 bytes to fit within the 31-byte advertisement limit while maintaining acceptable security (2^32 brute force effort).

Low-Power Advertisement Scheduling and RSSI Filtering

The accessory must balance advertisement frequency with power consumption. A typical approach uses a dynamic advertisement interval: a fast interval (e.g., 100 ms) when the device is in "discovery" mode, and a slow interval (e.g., 1000 ms) after initial connection or timeout. The transition occurs based on RSSI thresholds. For example:

// Pseudo-code for dynamic advertisement interval
#define FAST_ADV_INTERVAL  100  // ms
#define SLOW_ADV_INTERVAL 1000  // ms
#define RSSI_NEAR_THRESHOLD  -60 // dBm
#define RSSI_FAR_THRESHOLD   -80 // dBm

static uint16_t current_adv_interval = FAST_ADV_INTERVAL;
static int8_t last_rssi = -100;

void update_adv_interval(int8_t rssi) {
    if (rssi > RSSI_NEAR_THRESHOLD) {
        // User is near: fast advertising to reduce latency
        current_adv_interval = FAST_ADV_INTERVAL;
    } else if (rssi < RSSI_FAR_THRESHOLD) {
        // User is far: slow advertising to save power
        current_adv_interval = SLOW_ADV_INTERVAL;
    }
    // If between thresholds, keep previous interval to avoid oscillation
}

// In the BLE stack's event handler:
void on_ble_adv_report(uint8_t* adv_data, uint8_t len, int8_t rssi) {
    // Filter only our accessory's advertisement by checking manufacturer data
    if (is_our_device(adv_data, len)) {
        update_adv_interval(rssi);
        // Apply moving average filter for RSSI
        static float filtered_rssi = -100.0f;
        filtered_rssi = 0.7f * filtered_rssi + 0.3f * rssi;
        if (filtered_rssi > RSSI_NEAR_THRESHOLD) {
            // Trigger proximity event (e.g., send unlock command)
            trigger_unlock();
        }
    }
}

RSSI values are inherently noisy due to multipath fading and human body attenuation. A simple moving average filter (exponential smoothing) significantly improves reliability. The filter coefficient (alpha = 0.3) provides a balance between responsiveness and smoothing. In practice, a more sophisticated adaptive filter may be used, but the exponential filter is lightweight for embedded MCUs.

Secure Proximity Unlock Protocol

The unlock command should only be sent when the central device is within a defined proximity zone (e.g., < 1 meter). However, RSSI alone is insufficient for precise distance estimation. We combine RSSI with a cryptographic handshake to prevent relay attacks. The protocol works as follows:

1. Accessory Advertises: Contains nonce (N) and CMAC(N, K) where K is the pre-shared key.
2. Central Receives: Extracts N and verifies CMAC. If valid, it knows the accessory is legitimate.
3. Central Sends Connection Request: Only if RSSI > threshold AND CMAC is valid. This prevents a distant attacker from triggering a connection.
4. Central Computes Response: After connection, central sends a command encrypted with AES-CCM using a session key derived from K and N. The command includes a timestamp to prevent replay.
5. Accessory Executes: Decrypts command, verifies timestamp freshness (within ±500 ms), and activates the unlock mechanism.

This protocol ensures that even if an attacker captures the advertisement packet, they cannot replay it because the nonce changes each advertisement (generated by a pseudo-random number generator). The use of AES-128 CMAC in the advertisement keeps the computational overhead low on the accessory side (typically < 100 µs on a Cortex-M0+).

Power Consumption Analysis

The dominant power consumer on the accessory is the BLE radio during advertisement transmission and reception. Let's calculate the average current for a typical implementation using a Nordic nRF52832 SoC (a common choice for automotive accessories).

• Advertisement TX (1 byte payload + 31 bytes total): 5.4 mA for 0.8 ms per channel. Three channels (37, 38, 39) are used per advertisement event. Total TX time = 3 * 0.8 ms = 2.4 ms per event.
• RX window (for connection requests): If the accessory listens for a connection request after each advertisement, it must keep the receiver on for ~1.5 ms per channel. Total RX time = 4.5 ms per event.
• MCU active time: ~0.5 ms for processing (generating nonce, computing CMAC, updating state). MCU current ~3 mA.

Total active time per advertisement event = 2.4 ms (TX) + 4.5 ms (RX) + 0.5 ms (MCU) = 7.4 ms. At a 100 ms interval, the number of events per second = 10. Active current = 7.4 ms * 10 * 5.4 mA (radio) + 0.5 ms * 10 * 3 mA (MCU) = 399.6 µA + 15 µA = 414.6 µA average. At a 1000 ms interval, this drops to 41.46 µA average.

For a coin-cell battery (CR2032, 225 mAh), the system can run for approximately 225 mAh / 0.04146 mA = 5426 hours (226 days) at 1-second advertising, or 225 mAh / 0.4146 mA = 542 hours (22 days) at 100 ms advertising. To achieve 1-2 year battery life, the accessory must spend most of its time in slow advertising (e.g., 1 second interval) and only switch to fast advertising when the user is detected nearby (e.g., via a capacitive touch sensor or a low-power wake-up receiver). An alternative is to use a motion sensor (accelerometer) to detect vehicle approach and trigger fast advertising.

Further power savings can be achieved by disabling the RX window after advertisement if the accessory does not expect immediate connection. In a pure proximity unlock system, the central device can send a connection request within the RX window, but if the accessory only needs to detect proximity (not establish a connection), it can skip the RX window entirely, cutting active time by more than half.

Performance Analysis: Proximity Accuracy and Latency

Proximity accuracy is limited by BLE RSSI variance. In an open outdoor environment, RSSI-based distance estimation has an error of ±2-3 meters. In an indoor or garage environment, multipath can cause errors of ±5 meters or more. For automotive accessories, this is often acceptable because the unlock zone is typically within 1-2 meters (e.g., user approaching the car trunk). To improve accuracy, we implement a two-zone approach:

• Far Zone (RSSI < -80 dBm): No action, accessory stays in low-power sleep.
• Near Zone (RSSI between -80 dBm and -60 dBm): Accessory switches to fast advertising, central device begins authentication.
• Unlock Zone (RSSI > -60 dBm): Central sends unlock command, accessory activates mechanism.

Latency from entering the unlock zone to actuation is dominated by the advertisement interval. At 100 ms fast advertising, the worst-case latency is 100 ms (for the next advertisement) plus processing time (~10 ms). At 1-second slow advertising, latency could be up to 1 second, which is acceptable for most automotive accessories (e.g., unlocking a trunk takes ~500 ms physically). If lower latency is required, a dual-mode approach can be used: the accessory also listens for a "wake-up" signal from the central device on a separate low-power channel (e.g., using a dedicated LF antenna, but this adds cost).

Reliability and Security Considerations

Relay attacks are a significant threat for proximity systems. In a relay attack, an attacker captures the BLE signal from the legitimate keyfob and retransmits it to the accessory. Our protocol mitigates this because the nonce changes every advertisement (typically every 100 ms). The attacker must capture and relay a valid advertisement within that 100 ms window, which is difficult but not impossible. To further harden the system, we can add distance bounding using round-trip time (RTT) measurement. BLE 5.1 introduced Angle of Arrival (AoA) and Angle of Departure (AoD) for precise localization, but these require additional antenna arrays. For cost-sensitive automotive accessories, a practical approach is to require both BLE proximity and a secondary trigger (e.g., a capacitive touch sensor on the accessory handle) to initiate unlock. This two-factor approach defeats relay attacks because the attacker cannot simulate the physical touch.

Conclusion

BLE advertisement data provides a viable, low-cost path to implement proximity keyless entry for automotive accessories. By carefully designing the advertisement payload with embedded security (nonce + CMAC), implementing dynamic advertisement intervals based on RSSI filtering, and optimizing power consumption through aggressive sleep scheduling, developers can achieve reliable operation with coin-cell battery life exceeding one year. The code snippet and performance analysis presented here offer a practical starting point for embedded developers. Future improvements may leverage BLE 5.x features like extended advertising (up to 255 bytes) for richer payloads, or coded PHY for longer range. However, even with basic BLE 4.2, a well-designed system can meet the demanding requirements of modern automotive accessories.

💬 欢迎到论坛参与讨论： 点击这里分享您的见解或提问