Join the early list

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

· Nanupatruni Mahesh Kumar

  • Connectivity
  • Security
  • TRL 4
Read the paper Download

PDF, 26 pages, 2.9 MB · v1.1

The paper's cover: BLE application-layer authentication with ECDSA certificate chains on ESP32-C3

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.

Inside the paper

6 of the paper's 11 figures. Open any of them full size to zoom in.

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. HUB AND BOTH NODES ON THE BENCH 1 2 3 1 Hub: Raspberry Pi Zero 2 W microSD card fitted, powered over micro-USB 2 Node board ESP32-C3-SuperMini, powered over USB-C 3 Node board ESP32-C3-SuperMini, powered over USB-C
Figure 3 The hub and both ESP32-C3-SuperMini node boards on the bench, each powered over USB.
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. SYSTEM UNDER TEST: ONE HUB, TWO NODES Offline issuing machine P-256 ECDSA: root CA → issuer CA → leaf certificates. Private keys never leave it. HUB (BLE CENTRAL) Raspberry Pi Zero 2 W Rev 1.0 Raspbian GNU/Linux 13 (trixie) BlueZ 5.82 Python 3.13.5, bleak 1.1.1 Onboard Broadcom BCM43430A1 Bluetooth 4.2 LE, UART-attached Central certificate chain + key Time-authority signing key NODE (BLE PERIPHERAL) ESP32-C3-SuperMini · 6D1A NimBLE-Arduino 2.x, mbedTLS 3.x, core 3.3.12 NVS: node chain + key, root cert, time pubkey NODE (BLE PERIPHERAL) ESP32-C3-SuperMini · C5DA NimBLE-Arduino 2.x, mbedTLS 3.x, core 3.3.12 NVS: node chain + key, root cert, time pubkey BLE GATT, link unencrypted custom auth + event characteristics Certificate handshake (Figure 2) then events by INDICATE, queued credential directories USB-CDC serial, once per node SQLite event store device_id, boot_id, sequence, grams, count, received_at Node IDs: LC- + BLE MAC. Short IDs 6D1A and C5DA used in text.
Figure 1 The hub, the two nodes and the offline credential chain.
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. APPLICATION-LAYER HANDSHAKE ON ONE BLE CONNECTION Central (hub) Node 1 TIME_REQUEST carries the session nonce 2 TIME_ATTESTATION token signed by the time-authority key site_id, nonce, signer key id, signature clock: log-only since 2026-10-15 3 HELLO central certificate chain site policy, chain to provisioned root, replay (second HELLO) 4 HELLO_ACK version, nonce, node certificate chain root CA, site_id, capability, epoch of the node credential 5 PROOF ECDSA signature over the nonce signature, key matches HELLO chain 6 RESULT authorized = True / False Central checks Node checks After RESULT(authorized = True) and subscription, the node sends sensor events by INDICATE from a 32-entry FIFO
Figure 2 The six-message handshake on one connection.
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. END-TO-END AUTHENTICATION LATENCY, N = 35 RUNS, 2026-10-06 6 7 8 9 10 11 12 Scan start to authorized (s), measured p50 6.58 s mean 7.39 s p95 10.30 s p99 11.59 s One dot per run, 0.5 s bins
Figure 6 Distribution of the 35 latency runs. Most runs complete in 6 to 7 s, with a tail to 11.7 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. WEEKEND SOAK RUN, 41.36 H UNATTENDED, 2026-10-17 TO 2026-10-19 Disconnects Successful reconnects 0 100 200 300 400 Node 6D1A 89 81 826 events 0 lost, 0 gaps Node C5DA 382 211 823 events 0 lost, 0 gaps Count over the run
Figure 8 Disconnects and successful reconnects per node during the soak run. Every event was delivered on both nodes despite the churn.
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. TECHNOLOGY READINESS: WHERE THIS WORK SITS TRL 1 Basic principles observed TRL 2 Technology concept formulated TRL 3 Experimental proof of concept TRL 4 Technology validated in lab TRL 5 Validated in relevant environment TRL 6 Demonstrated in relevant environment TRL 7 Prototype in operational environment TRL 8 System complete and qualified TRL 9 Proven in operational environment This work Next
Figure 11 Where this work sits on the EU Horizon TRL scale.

About this paper

Version
v1.1, published 20 October 2026, updated 21 October 2026
Written by
Nanupatruni Mahesh Kumar
Reviewed by
Ravi Kumar Chintalapudi
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
The paper
26 pages, 2.9 MB, PDF

The full paper has the method, every table, the defects found along the way and what is still needed for the next readiness level.

Read the paper

Related reading