# BLE application-layer authentication with ECDSA certificate chains on ESP32-C3

- Version: v1.1, published 20 October 2026, updated 21 October 2026
- Written by: Nanupatruni Mahesh Kumar
- Reviewed by: Ravi Kumar Chintalapudi
- Domains: Connectivity, Security
- Readiness: TRL 4, technology validated in the lab
- Tested on: A Raspberry Pi Zero 2 W hub (BlueZ 5.82) and two ESP32-C3-SuperMini nodes (NimBLE-Arduino 2.x, mbedTLS 3.x); the 35 latency runs used a laptop as the lab central
- Standards: Bluetooth Core Specification 4.2, RFC 5280, ETSI EN 303 645 provision 5.1 and NISTIR 8259A, method only; no accredited testing
- Full paper: [PDF, 26 pages, 2.9 MB](https://dharanova.com/whitepapers/ble-certificate-authentication.pdf)

## Summary

An application-layer mutual authentication handshake, using P-256 ECDSA X.509 certificate chains, runs over BLE GATT between a Python/BlueZ hub on a Raspberry Pi Zero 2 W and two ESP32-C3 nodes. All defined rejection cases are refused, latency averages 7.394 s over 35 runs, and the firmware uses 54.7 % of its partition. LE Secure Connections fails on the hub's onboard adapter and was removed, leaving the link unencrypted. A 41.36 h unattended run lost none of 1649 events through 471 disconnects, which is not yet enough to show the < 0.1 % loss target. A board swap traced one node's instability to the board.

## Key findings

- **Authentication.** Every defined rejection case is refused and an authorized central completes on one connection. Criteria R1, R2 and R4 to R6 are met. R3 (time-token rejection) passed, but the clock check it relies on was made log-only on 2026-10-15 and has not been re-tested as a blocking check.
- **Latency.** 7.394 ± 0.521 s (mean, k = 2), p95 10.303 s, n = 35, measured on an earlier lab central, not on the installed Raspberry Pi hub.
- **Transport.** 0 of 1649 events lost over 41.36 h. With zero losses in 1649 events, the 95 % upper bound on the loss rate is 0.18 %, above the 0.1 % target. About 2995 loss-free events are needed to show < 0.1 %.
- **Security gap.** The BLE link carries no encryption, so payloads are readable by any BLE sniffer in range. Certificate authentication still stops an unauthorized central from operating a node.
- **Per-board instability.** After the two nodes swapped places, C5DA's disconnect rate rose 71 % while 6D1A's stayed within 3 %. The problem follows the C5DA board, not its location.
- **Readiness.** TRL 4, technology validated in the lab.

## Figures shown on the page

- Figure 3: The hub and both ESP32-C3-SuperMini node boards on the bench, each powered over USB. Photo of the bench set-up, numbered: 1, the Raspberry Pi Zero 2 W hub, with a microSD card, powered over micro-USB; 2 and 3, the two ESP32-C3-SuperMini node boards, powered over USB-C.
- Figure 1: The hub, the two nodes and the offline credential chain. Block diagram. An offline issuing machine holds a P-256 ECDSA root CA, issuer CA and leaf certificates, and its private keys never leave it. Credential directories go from it to the hub, a Raspberry Pi Zero 2 W running Raspbian 13, BlueZ 5.82 and Python 3.13.5 with bleak 1.1.1 on its onboard Broadcom BCM43430A1 Bluetooth 4.2 LE adapter, holding the central certificate chain and the time-authority signing key. Each node is provisioned once over USB-CDC serial. The hub talks to two ESP32-C3-SuperMini nodes, 6D1A and C5DA, over unencrypted BLE GATT: the certificate handshake, then events by INDICATE, queued. The hub writes events to a SQLite store.
- Figure 2: The six-message handshake on one connection. Sequence diagram between the central (hub) and the node. 1, TIME_REQUEST from the node, carrying the session nonce. 2, TIME_ATTESTATION from the central, a token signed by the time-authority key; the node checks site_id, nonce, signer key id and signature. 3, HELLO from the central with its certificate chain; the node checks site policy, the chain to its provisioned root, and replay. 4, HELLO_ACK from the node with version, nonce and node certificate chain; the central checks root CA, site_id, capability and epoch. 5, PROOF, an ECDSA signature over the nonce; the node checks the signature and that the key matches the HELLO chain. 6, RESULT, authorized true or false. After an authorized result and subscription, the node sends events by INDICATE from a 32-entry FIFO.
- Figure 6: Distribution of the 35 latency runs. Most runs complete in 6 to 7 s, with a tail to 11.7 s. Dot plot of 35 authentication runs on 2026-10-06, from scan start to authorized, in 0.5 s bins from about 6 to 12 seconds. The largest cluster is just over 6 s. Marked lines: p50 6.58 s, mean 7.39 s, p95 10.30 s, p99 11.59 s.
- Figure 8: Disconnects and successful reconnects per node during the soak run. Every event was delivered on both nodes despite the churn. Bar chart of the 41.36-hour weekend soak run. Node 6D1A: 89 disconnects, 81 successful reconnects, 826 events, 0 lost, 0 gaps. Node C5DA: 382 disconnects, 211 successful reconnects, 823 events, 0 lost, 0 gaps.
- Figure 11: Where this work sits on the EU Horizon TRL scale. Technology readiness ladder from TRL 1 to TRL 9. TRL 1 to 4 are filled in; TRL 4, technology validated in lab, is marked as this work. TRL 5, validated in relevant environment, is marked as next.

## Related reading

- [Bluetooth LE, Wi-Fi and 802.15.4](https://dharanova.com/learn/short-range-radio.md): background on Learn
- [Secure boot and the root of trust](https://dharanova.com/learn/secure-boot.md): background on Learn
- [Security baselines and the law](https://dharanova.com/learn/iot-security-rules.md): background on Learn
- [Mapping the Bluetooth stack](https://dharanova.com/mapping-the-bluetooth-stack.md): an engineering note from our team
- [Device-to-app sync for VAHA: architecture, and the integrity and security of the current build](https://dharanova.com/whitepapers/vaha-device-to-app-sync-integrity-security.md): another whitepaper

This paper documents component-level work in the lab. It is not a product specification.