IEEE Access · Vol. 13 · 2025 · Interactive explainer

ECC-Based Authentication for the Military Internet of Drones

Every link — soldier to drone, drone to command (CA), drone to drone — gets its own authentication and session key, so a breach on one segment does not spread across the network. This page runs the protocol live in your browser on a real elliptic curve. Based on Hyeon Choe & Dongsu Kang, Korea National Defense University.

Paper (DOI) IEEE Xplore More Spaces
// Architecture

Three segments, three independent keys

Keys are issued by the CA over a private channel before deployment. In the field, each segment authenticates with the method that fits its constraints.

Command · CA CAK · issues GK, SK Drone A Drone B Soldier device ② Drone ↔ CA pre-shared GK · ECDH · UWB ③ Drone ↔ Drone implicit key · GK + nonce · hashes only ① Soldier ↔ Drone trust anchor · CA public key GPS-denied: position via UWB (timestamp · hop · AoA)
① Soldier ↔ Drone · trust anchorBoth sides derive the same session key from ephemeral ECC keys plus keys the CA signed with its private key. Only the CA's public key is needed in the field.
② Drone ↔ CA · group key + ECDHThe pre-shared group key authenticates the exchange; an ECDH step sets a fresh session key. Hop count and timestamp feed UWB position checks where GPS is unavailable.
③ Drone ↔ Drone · implicit keyHash-only authentication with the group key and timestamps — 8 hash operations per link (≈ 0.456 ms), constant as the swarm grows.
Threats addressedReplay, man-in-the-middle, spoofing, key reuse, clogging (DoS), physical capture, GPS spoofing.
// Live protocol run

Run the handshake — or attack it

Each run uses fresh random values on the secp256k1 curve with SHA-256. Pick an attack to see which check stops it.

⚠ adversary
// Security analysis

Security features compared

From the paper's comparison with related IoD schemes (Table 5). ✓ = provided, ✗ = not provided.

Formal verification · ProVerif

Drone ↔ Soldier

not attacker(SEK) is true
inj-event(end_S(SID)) ⇒ inj-event(start_S(SID)) is true
inj-event(end_D(GID)) ⇒ inj-event(start_D(GID)) is true

Drone ↔ CA

not attacker(LK) is true
inj-event(end_CA(CAID)) ⇒ inj-event(start_CA(CAID)) is true
inj-event(end_D(DID)) ⇒ inj-event(start_D(DID)) is true

Drone ↔ Drone

not attacker(GK) is true
inj-event(end_A(DID_A)) ⇒ inj-event(start_A(DID_A)) is true
inj-event(end_B(DID_B)) ⇒ inj-event(start_B(DID_B)) is true

Session keys stay secret and every authentication end-event is preceded by a matching start-event. The paper also derives the same goals with BAN logic.

// Military practicality

Memory, bandwidth and computation

Figures as reported in the paper (Tables 6, 8, 10, 11), assuming 160-bit ECC, SHA-1 and 32-bit IDs / timestamps, with operation times measured on an NXP LPC1788 microcontroller.

Drone memory (bits)

Drone stores RG (320) + GK (160) + GID (32) + DID (32) = 544 bits.

Communication per authentication (bits)
Drone–DroneDrone–CADrone–SoldierCA–Soldier
Computation time (ms)
Drone sideSoldier (mobile) side
Drone-to-drone scaling

Each drone-to-drone link needs only hash operations, about 0.456 ms per link, so cost grows linearly with the number of links and stays constant per link.

Links in the swarm100
Total ≈ 45.6 ms of hashing

Operation times used in the paper: point multiplication 72 ms · point addition 0.3 ms · ECC sign 136 ms · verify 214 ms · SHA 0.057 ms · random number 36 ms.