11  Elliptic Curve Cryptography for IoT

11.1 Learning Objectives

By the end of this chapter, you will be able to:

  • Explain ECC Fundamentals: Describe how elliptic curves provide security equivalent to RSA with dramatically smaller keys
  • Select Appropriate Curves: Choose between secp256r1, Curve25519, and Ed25519 for different IoT use cases
  • Optimize for Constraints: Apply ECC to maximize security while minimizing power, memory, and bandwidth usage
  • Implement ECDH and ECDSA: Configure elliptic curve key exchange and digital signatures in IoT applications
In 60 Seconds

Elliptic Curve Cryptography (ECC) provides strong public-key security with much smaller keys than RSA, making it the preferred asymmetric algorithm for resource-constrained IoT devices.

MVU: Minimum Viable Understanding

If you only have 5 minutes, here’s what you need to know about ECC for IoT:

  1. ECC = RSA security with much smaller keys – A 256-bit ECC key provides ~128-bit security, equivalent to a 3072-bit RSA key
  2. Use Ed25519 for signatures – 64-byte signatures, fast, secure, no random number generator needed
  3. Use Curve25519 for key exchange – Resistant to timing attacks, constant-time operations
  4. Use secp256r1 if hardware accelerated – ESP32, STM32, nRF52 have built-in support

Bottom line: For battery-powered IoT devices, always prefer ECC over RSA. It’s the practical way to get strong cryptography on constrained devices.

In Plain English

Elliptic Curve Cryptography (ECC) provides the same security as RSA with much smaller keys (e.g., 256-bit ECC vs 3072-bit RSA for 128-bit security) and significantly faster signing. This makes it the ideal choice for battery-powered IoT devices with limited memory, bandwidth, and processing power.

Why it matters: A LoRaWAN sensor with 51-byte payload limits cannot fit an RSA-2048 signature (256 bytes), but compact ECC signatures make authenticated messaging feasible on bandwidth-constrained networks.

11.2 Prerequisites

Before diving into this chapter, you should be familiar with:

  • Cryptography Principles: Understanding of basic encryption concepts, symmetric vs asymmetric cryptography, and the role of keys in secure communication
  • Asymmetric Encryption: Knowledge of public-key cryptography fundamentals, RSA concepts, and why key exchange is challenging for IoT
  • Elliptic Curve: A mathematical curve defined by the equation y² = x³ + ax + b; points on the curve form a group suitable for cryptographic operations.
  • ECDH (Elliptic Curve Diffie-Hellman): A key agreement protocol using ECC allowing two parties to derive a shared secret over an insecure channel without transmitting the secret.
  • ECDSA (Elliptic Curve Digital Signature Algorithm): A digital signature scheme using ECC; generates and verifies signatures for message authentication and non-repudiation.
  • Curve P-256: A standardized NIST elliptic curve with 256-bit key size; provides ~128-bit security and is widely supported in TLS and IoT libraries.
  • Curve25519: A modern high-performance elliptic curve by Daniel Bernstein; known for fast implementations and resistance to side-channel attacks.
  • Key Size Comparison: 256-bit ECC provides approximately the same security as 3072-bit RSA, using far fewer CPU cycles and bytes — critical for IoT microcontrollers.
  • Side-Channel Attack: An attack that extracts secret information from physical measurements (timing, power, electromagnetic emissions) during cryptographic operations rather than from the algorithm itself.

11.3 Sensor Squad: Secret Codes for Tiny Devices!

Hey there, future security expert! Let’s learn about ECC with the Sensor Squad!

Sammy the Sensor needs to send a secret message to Cloudy the Cloud. But there’s a problem – Sammy is tiny and can only carry small messages. Regular encryption keys are like carrying a heavy backpack – too big for little Sammy!

Think of it like a secret handshake:

Imagine you and your best friend create a super-secret handshake. Anyone watching can see you do the handshake, but they can’t figure out the secret code hidden in it. That’s how ECC works!

The Sensor Squad Adventure:

  • Sammy wants to prove he sent a message (not an imposter!)
  • Regular RSA keys are like carrying a 256-piece puzzle – too heavy!
  • ECC keys are like carrying only 32 puzzle pieces – but just as secret!
  • Sammy uses his tiny ECC key to sign the message
  • Cloudy checks the signature – “Yep, that’s really Sammy!”

Fun Analogy:

  • RSA is like a big, heavy safe with a huge key
  • ECC is like a tiny lockbox with a magic key that’s just as strong!

Why This Matters for IoT:

Your smartwatch, fitness tracker, and home sensors all use ECC because they:

  • Have small batteries (ECC uses much less power for signing!)
  • Have limited memory (ECC keys are 8x smaller!)
  • Need to send small messages (ECC signatures fit better!)

Try This: Next time you see a smart device, remember – it probably uses ECC to keep your data safe while sipping battery power like a hummingbird!

11.4 Why ECC for IoT?

Before diving into the technical details, let’s understand why ECC has become the standard for IoT security. The fundamental challenge in IoT cryptography is providing strong security within severe resource constraints – limited battery, memory, bandwidth, and processing power.

Elliptic curve cryptography solves this challenge by providing equivalent security to RSA with dramatically smaller key sizes, making it ideal for resource-constrained IoT devices.

11.4.1 Key Size Comparison

The following table shows how ECC achieves the same security level as RSA with much smaller keys. This is because the mathematical problem underlying ECC (the Elliptic Curve Discrete Logarithm Problem) is fundamentally harder to solve than RSA’s factoring problem.

Security Level RSA Key Size ECC Key Size Size Reduction
80-bit 1024 bits 160 bits 6.4x
112-bit 2048 bits 224 bits 9.1x
128-bit 3072 bits 256 bits 12x
192-bit 7680 bits 384 bits 20x
256-bit 15360 bits 512 bits 30x

Notice how the size advantage of ECC grows as security requirements increase. For 256-bit security (the highest level), ECC keys are 30x smaller than RSA keys!

11.4.2 IoT Resource Impact

But key size is just one factor. Let’s examine how this translates to real-world IoT metrics:

Metric RSA-2048 ECC-256 (Ed25519) Improvement
Key Size 256 bytes 32 bytes 8x smaller
Signature Size 256 bytes 64 bytes 4x smaller
Sign Time 200-500 ms 20-50 ms 10x faster
Verify Time 10-50 ms 30-60 ms RSA faster (small exponent)
Power per Sign 10-20 mJ 1-2 mJ 10x less

These improvements have profound implications for IoT design. A device that signs 100 messages per day would use roughly 10x less energy for cryptographic signing operations with ECC, potentially extending battery life by weeks or months.

Note on verification speed: RSA verification is actually faster than ECC verification on most platforms because RSA uses a small public exponent (65537). However, ECC’s advantages in key size, signature size, signing speed, and energy consumption far outweigh this single metric for IoT applications.

Bar chart comparing ECC-256 and RSA-2048 across key size, signature size, signing time, and power consumption for IoT devices

ECC vs RSA Resource Comparison for IoT Devices
ECC: The Smart Choice for IoT

For resource-constrained IoT devices, always prefer ECC over RSA:

  • Battery life: ECC-256 signing uses ~10x less CPU cycles than RSA-2048 signing
  • Memory: ECC-256 requires 32-byte keys vs RSA-2048’s 256-byte keys
  • Bandwidth: ECC-256 signatures are 64 bytes vs RSA-2048’s 256 bytes
  • Security: ECC-256 provides 128-bit security, equivalent to RSA-3072

11.5 How Elliptic Curves Work

Understanding the underlying mathematics isn’t required to use ECC effectively, but having an intuition helps you make better design decisions. This section provides a conceptual overview – feel free to skip to the practical sections if you prefer.

Think of ECC like a one-way street:

Imagine you can easily walk from Point A to Point B on a curved path, but finding your way back is incredibly difficult – even if someone watches you make the trip!

The One-Way Property:

  • Easy: Starting from point P, multiply by secret number k to get point Q
  • Hard: Given P and Q, figure out what k was (the secret!)

This “one-way” property is what makes ECC secure. Your public key (Q) can be shared with everyone, but your private key (k) remains secret because it’s computationally infeasible to derive k from Q.

You don’t need to understand the math to use ECC, but here’s the intuition:

The Curve: An elliptic curve is defined by: \(y^2 = x^3 + ax + b\)

The Hard Problem: Given points P and Q on the curve where Q = kP (P added to itself k times), finding k from P and Q is computationally infeasible. This is the Elliptic Curve Discrete Logarithm Problem (ECDLP).

Why it’s secure: Unlike RSA’s factoring problem, the best known algorithms for ECDLP are fully exponential (no sub-exponential shortcut). This is why 256-bit ECC provides security comparable to 3072-bit RSA.

Point Addition: The curve has a special property where you can “add” two points to get a third point. This addition operation forms the basis of all ECC operations.

Conceptual diagram of elliptic curve point addition and scalar multiplication used in ECC key generation

Elliptic Curve Operations Conceptual Overview

11.7 ECDH Key Exchange

Elliptic Curve Diffie-Hellman (ECDH) enables two parties to establish a shared secret over an insecure channel. This is fundamental to IoT security – how can a new device securely communicate with a server if anyone might be listening?

The beauty of ECDH is that even if an attacker observes every message exchanged, they cannot compute the shared secret. Only the two parties with their private keys can derive it.

Sequence diagram showing ECDH key exchange between an IoT device and server. Device generates private key (d) and public key (D=dG), server generates private key (s) and public key (S=sG). They exchange public keys over insecure channel. Both compute identical shared secret: device computes K=dS, server computes K=sD. The mathematics ensures dS=sD, giving both parties the same secret key for encrypted communication.
Figure 11.1: ECDH key exchange for IoT device-server communication

Protocol:

  1. Both parties agree on curve parameters (e.g., Curve25519)
  2. Each generates private key (random scalar) and public key (point on curve)
  3. Exchange public keys over insecure channel
  4. Each computes shared secret: S = private_key * other_public_key
  5. Derive symmetric key from shared secret using KDF (Key Derivation Function)

Step-by-step ECDH key exchange protocol showing key generation, public key exchange, and shared secret derivation between two IoT devices

ECDH Key Exchange Protocol Flow
Security Note: Ephemeral Keys

For maximum security, use ephemeral (one-time) keys for each ECDH session. This provides forward secrecy – even if long-term keys are compromised, past communications remain secure.

11.8 ECDSA Digital Signatures

Elliptic Curve Digital Signature Algorithm provides authentication and non-repudiation. When a device signs data with its private key, anyone with the public key can verify the signature came from that specific device – but cannot forge signatures.

This is critical for IoT scenarios like:

  • Firmware updates: Verify updates come from the legitimate manufacturer
  • Sensor data: Prove readings originated from a specific authenticated device
  • Commands: Verify control messages were not forged by attackers
Diagram showing ECDSA digital signature workflow. Manufacturer uses private key to sign firmware hash, producing a signature. IoT device receives firmware and signature. Device uses manufacturer's public key to verify signature matches firmware hash. If valid, firmware is trusted and installed. If invalid, firmware is rejected as potentially malicious.
Figure 11.2: ECDSA firmware signing and verification

11.8.1 Ed25519 vs ECDSA

When choosing a signature algorithm, Ed25519 offers significant advantages over traditional ECDSA for IoT applications:

Feature ECDSA (secp256r1) Ed25519
Signature Size 64-72 bytes 64 bytes
Signing Requires secure RNG Deterministic (no RNG needed)
Verify Speed Fast Very fast
Side-Channel Resistance Implementation-dependent Built-in (constant-time)
Standards FIPS 186-4, X.509, TLS TLS 1.3, SSH, Signal

Recommendation: Use Ed25519 for new IoT designs. It’s faster, more secure against side-channel attacks, and doesn’t require a secure random number generator for signing – eliminating a common vulnerability where a weak RNG compromises the private key.

Workflow showing firmware signing with private key and verification on IoT device using public key to ensure authenticity

Firmware Signing and Verification with ECDSA/Ed25519

11.9 IoT Implementation Considerations

Selecting the right curve is only part of the equation. Practical IoT implementation requires understanding hardware capabilities, available libraries, and bandwidth constraints.

11.9.1 Hardware Acceleration

Many IoT microcontrollers include ECC hardware that dramatically speeds up cryptographic operations while reducing power consumption:

Platform ECC Support Curves
ESP32 Hardware accelerated secp256r1
STM32 PKA peripheral secp256r1, secp384r1
nRF52 CryptoCell CC310 secp256r1, Curve25519
ATECC608 Secure element secp256r1

When hardware acceleration is available, use it! Hardware ECC is typically 10-50x faster than software implementations and consumes proportionally less power.

11.9.2 Software Libraries

For platforms without hardware ECC, several excellent libraries are available:

  • mbedTLS: Portable, widely used, supports all major curves
  • micro-ecc: Tiny footprint (~8 KB), ideal for 8-bit MCUs
  • libsodium: Modern, secure, easy API (Curve25519/Ed25519)
  • wolfSSL: Commercial-grade, FIPS certified

11.9.3 Bandwidth Optimization

For constrained networks (LoRaWAN, NB-IoT, Sigfox), ECC’s compact key and signature sizes are essential:

Data Type RSA-2048 Ed25519 Savings
Public Key 256 bytes 32 bytes 8x
Signature 256 bytes 64 bytes 4x
Certificate (minimal) ~1000 bytes ~200 bytes 5x

11.10 Knowledge Check

Test your understanding of ECC concepts with these questions:

You’re designing a LoRaWAN sensor that must send authenticated telemetry with limited bandwidth (51 bytes max payload). Which algorithm should you use for digital signatures?

Options:

    1. RSA-2048 because it’s the industry standard
    1. Ed25519 (ECC) because it produces 64-byte signatures with equivalent security
    1. SHA-256 hash because it’s only 32 bytes
    1. AES-GCM authentication tag because it’s only 16 bytes

Correct: B

Ed25519 produces 64-byte signatures while providing 128-bit security, equivalent to RSA-3072. RSA-2048 signatures are 256 bytes – far exceeding the 51-byte LoRaWAN payload limit. While Ed25519’s 64-byte signature also exceeds a single payload, it can be accommodated with message fragmentation or by using a compact data + signature split across two frames. SHA-256 is a hash (not a signature), and AES-GCM requires a pre-shared key. For proving device identity without pre-shared secrets, Ed25519 is the optimal choice.

Your IoT device uses an STM32 with hardware ECC acceleration for secp256r1, but your security team recommends Curve25519. What should you consider?

Options:

    1. Always use Curve25519 for maximum security
    1. Curve25519 in software may be slower than hardware-accelerated secp256r1
    1. secp256r1 is deprecated and should never be used
    1. The curves are incompatible and can’t interoperate

Correct: B

Hardware-accelerated secp256r1 on STM32 is likely faster and more power-efficient than software Curve25519. Both curves provide excellent security. The decision should consider: (1) performance requirements, (2) power constraints, (3) interoperability needs, and (4) whether timing-attack resistance (a Curve25519 advantage) is critical for your threat model.

Objective: Sign and verify data using Ed25519 (the recommended ECC signature scheme for IoT), then compare key and signature sizes with RSA.

from cryptography.hazmat.primitives.asymmetric.ed25519 import (
    Ed25519PrivateKey, Ed25519PublicKey
)
from cryptography.hazmat.primitives.asymmetric import rsa, padding
from cryptography.hazmat.primitives import hashes, serialization
import time

# Generate Ed25519 key pair (recommended for IoT)
ed_private = Ed25519PrivateKey.generate()
ed_public = ed_private.public_key()

# Generate RSA-2048 key pair (for comparison)
rsa_private = rsa.generate_private_key(public_exponent=65537, key_size=2048)
rsa_public = rsa_private.public_key()

# Firmware data to sign
firmware = b"ESP32_firmware_v3.0_sensor_config_update" * 50

# Ed25519 signing
start = time.time()
for _ in range(1000):
    ed_sig = ed_private.sign(firmware)
ed_sign_time = (time.time() - start) / 1000

# Ed25519 verification
start = time.time()
for _ in range(1000):
    ed_public.verify(ed_sig, firmware)
ed_verify_time = (time.time() - start) / 1000

# RSA signing
start = time.time()
for _ in range(100):
    rsa_sig = rsa_private.sign(firmware, padding.PSS(
        mgf=padding.MGF1(hashes.SHA256()),
        salt_length=padding.PSS.MAX_LENGTH
    ), hashes.SHA256())
rsa_sign_time = (time.time() - start) / 100

# RSA verification
start = time.time()
for _ in range(100):
    rsa_public.verify(rsa_sig, firmware, padding.PSS(
        mgf=padding.MGF1(hashes.SHA256()),
        salt_length=padding.PSS.MAX_LENGTH
    ), hashes.SHA256())
rsa_verify_time = (time.time() - start) / 100

# Compare sizes
ed_pub_bytes = ed_public.public_bytes(
    serialization.Encoding.Raw, serialization.PublicFormat.Raw)
rsa_pub_bytes = rsa_public.public_bytes(
    serialization.Encoding.DER, serialization.PublicFormat.SubjectPublicKeyInfo)

print("ECC (Ed25519) vs RSA-2048 Comparison:")
print(f"{'':30s} {'Ed25519':>12s} {'RSA-2048':>12s} {'Ratio':>8s}")
print("-" * 65)
print(f"{'Public key size':30s} {len(ed_pub_bytes):>10d} B {len(rsa_pub_bytes):>10d} B "
      f"{len(rsa_pub_bytes)/len(ed_pub_bytes):>6.0f}x")
print(f"{'Signature size':30s} {len(ed_sig):>10d} B {len(rsa_sig):>10d} B "
      f"{len(rsa_sig)/len(ed_sig):>6.0f}x")
print(f"{'Sign time':30s} {ed_sign_time*1000:>9.2f} ms {rsa_sign_time*1000:>9.2f} ms "
      f"{rsa_sign_time/ed_sign_time:>6.1f}x")
print(f"{'Verify time':30s} {ed_verify_time*1000:>9.2f} ms {rsa_verify_time*1000:>9.2f} ms "
      f"{rsa_verify_time/ed_verify_time:>6.1f}x")
print(f"\nFor battery-powered IoT: Ed25519 uses ~{len(rsa_pub_bytes)/len(ed_pub_bytes):.0f}x less bandwidth")
print(f"and is ~{rsa_sign_time/ed_sign_time:.0f}x faster at signing.")

What to Observe:

  1. Ed25519 public keys are 32 bytes vs RSA-2048’s ~270 bytes (8x smaller)
  2. Ed25519 signatures are 64 bytes vs RSA’s 256 bytes (4x smaller)
  3. Ed25519 signing is significantly faster than RSA; verification speeds may be comparable
  4. For bandwidth-constrained IoT (LoRaWAN, BLE), these size differences are critical

Objective: Perform an Elliptic Curve Diffie-Hellman key exchange to establish a shared AES session key between two IoT devices.

from cryptography.hazmat.primitives.asymmetric.x25519 import X25519PrivateKey
from cryptography.hazmat.primitives.kdf.hkdf import HKDF
from cryptography.hazmat.primitives import hashes

# Device A (e.g., sensor) generates ephemeral key pair
device_a_private = X25519PrivateKey.generate()
device_a_public = device_a_private.public_key()

# Device B (e.g., gateway) generates ephemeral key pair
device_b_private = X25519PrivateKey.generate()
device_b_public = device_b_private.public_key()

# Key exchange: each device computes the shared secret
# Device A uses B's public key
shared_secret_a = device_a_private.exchange(device_b_public)

# Device B uses A's public key
shared_secret_b = device_b_private.exchange(device_a_public)

print(f"Shared secret A: {shared_secret_a[:16].hex()}...")
print(f"Shared secret B: {shared_secret_b[:16].hex()}...")
print(f"Secrets match: {shared_secret_a == shared_secret_b}")

# Derive AES session key from shared secret
session_key = HKDF(
    algorithm=hashes.SHA256(), length=16,  # AES-128
    salt=None, info=b"iot-aes-session"
).derive(shared_secret_a)

print(f"\nDerived AES-128 session key: {session_key.hex()}")
print(f"Key size: {len(session_key)} bytes ({len(session_key)*8} bits)")
print(f"\nBoth devices now share this key for AES-GCM encryption!")
print(f"Key exchange used only 32-byte public values over the air.")

What to Observe:

  1. X25519 key exchange requires only 32-byte public keys to be transmitted
  2. Both devices independently compute the same shared secret
  3. HKDF derives a proper AES key from the raw shared secret
  4. Ephemeral keys provide forward secrecy – each session uses new key pairs

11.11 Best Practices for IoT ECC

Based on the concepts covered in this chapter, here are the key best practices for implementing ECC in IoT systems:

  1. Use Ed25519 for signatures – Fast, secure, no RNG dependency
  2. Use X25519 for key exchange – Constant-time, resistant to timing attacks
  3. Use secp256r1 if hardware accelerated – Leverage chip capabilities
  4. Never reuse ephemeral keys – Generate new ECDH keys per session
  5. Validate public keys – Check that received points are on the curve
  6. Use established libraries – Don’t implement ECC from scratch
  7. Protect private keys – Store in secure elements when possible
Common Pitfalls to Avoid
  • Don’t roll your own crypto: Even small implementation errors can completely break security
  • Don’t reuse ECDH keys: This compromises forward secrecy
  • Don’t skip public key validation: Invalid points can leak private keys
  • Don’t ignore timing attacks: Use constant-time implementations (Curve25519 has this built-in)

Scenario: Design cryptographic security for a solar-powered air quality sensor that must last 10 years in remote locations with only 4 hours of sunlight per day.

Device Specifications:

  • MCU: ARM Cortex-M0+ @ 48MHz (no hardware crypto)
  • Solar panel: 100mW peak, 400mWh daily average
  • Battery: 500mAh Li-ion (max 1.8Wh)
  • Communication: LoRaWAN (1 message/hour)
  • Security requirement: Digital signatures for data authenticity

Power Budget Analysis:

Daily energy available: 400mWh = 1,440 J Must reserve for: MCU idle, sensor reading, LoRaWAN TX, crypto operations

Component Energy per Hour Daily (24h)
MCU sleep 5 mW x 3,600s = 18 J 432 J (30%)
Sensor reading (1 min/hour) 10 mW x 60s = 0.6 J 14.4 J (1%)
LoRaWAN TX (1/hour) 100 mW x 5s = 0.5 J 12 J (0.8%)
Crypto operations ? ?
Margin (weather, aging) - 30% of total

Available for crypto: 1,440 - 432 - 14.4 - 12 - 432 = 549.6 J/day

Option 1: RSA-2048 Signatures

Per-signature energy:

  • Sign operation: 200ms @ 30mA @ 3.3V = 19.8 mJ
  • Energy per day (24 signatures): 24 x 19.8 mJ = 475.2 mJ = 0.475 J
Energy budget check:
Daily crypto: 0.475 J
Available: 549.6 J
Margin: 549.1 J (99.9%) - Acceptable

Option 2: Ed25519 Signatures

Per-signature energy:

  • Sign operation: 8ms @ 15mA @ 3.3V = 0.396 mJ
  • Energy per day (24 signatures): 24 x 0.396 mJ = 9.5 mJ = 0.0095 J
Energy budget check:
Daily crypto: 0.0095 J
Available: 549.6 J
Margin: 549.6 J (>99.9%) - Excellent

Comparison:

Metric RSA-2048 Ed25519 Advantage
Energy per signature 19.8 mJ 0.396 mJ 50x less with Ed25519
Signature size 256 bytes 64 bytes 4x smaller
LoRaWAN packets needed 5+ (51-byte limit) 2 2.5x fewer transmissions
Sign time 200 ms 8 ms 25x faster
Public key size 256 bytes 32 bytes 8x smaller

Additional Benefits of Ed25519:

  1. Deterministic signing – No need for secure random number generator (saves code space and potential vulnerability)
  2. Constant-time – Resistant to timing side-channel attacks
  3. Small code footprint – ~15KB flash vs ~45KB for RSA

10-Year Lifetime Calculation:

Total signatures over 10 years:
24/day x 365 days x 10 years = 87,600 signatures

RSA energy cost: 87,600 x 19.8 mJ = 1,734,480 mJ = 1,734.5 J
Ed25519 energy cost: 87,600 x 0.396 mJ = 34,690 mJ = 34.7 J

Energy saved: 1,699.8 J

Decision: Use Ed25519 for signatures. The 50x energy savings per operation and 4x smaller signature size make it the clear winner for battery-powered IoT, providing ample margin for cloudy days and battery aging.

Implementation:

#include "ed25519.h"

// Public key embedded in firmware (32 bytes)
const uint8_t manufacturer_pubkey[32] = { /* ... */ };

bool verify_data_signature(const uint8_t *data, size_t len,
                            const uint8_t *signature) {
    // Ed25519 verification: ~4ms on Cortex-M0+
    return ed25519_verify(signature, data, len, manufacturer_pubkey);
}

Use this framework to choose the right elliptic curve:

Step 1: Check Hardware Support

Platform Hardware Acceleration Supported Curves Recommendation
ESP32 Yes (crypto accelerator) secp256r1 Use secp256r1 (10-20x faster)
STM32 Yes (PKA peripheral) secp256r1, secp384r1 Use secp256r1
nRF52840 Yes (CryptoCell-310) secp256r1, Curve25519 Use hardware curve
ARM Cortex-M0/M0+ No Software only Use Ed25519/Curve25519
Arduino Uno (ATmega328) No Software only Use Ed25519 (fastest)

Step 2: Determine Primary Use Case

Use Case Best Curve Reason
Digital signatures Ed25519 Deterministic, no RNG needed, fast verify
Key exchange (ECDH) Curve25519 (X25519) Constant-time, side-channel resistant
TLS/DTLS secp256r1 (if HW) or Curve25519 TLS 1.3 supports both
X.509 certificates secp256r1 Widest compatibility
Legacy interop secp256r1 Required by older systems

Step 3: Evaluate Constraints

Constraint secp256r1 Curve25519 Ed25519
Code size 30-50 KB 15-25 KB 15-20 KB
RAM usage 2-4 KB 1-2 KB 1-2 KB
Sign speed (software) Medium N/A Fast
Verify speed (software) Medium N/A Very fast
Key exchange (software) Slow Fast N/A
Side-channel resistance Implementation-dependent Excellent Excellent

Step 4: Compliance Requirements

Standard Acceptable Curves
FIPS 186-4 secp256r1, secp384r1, secp521r1
NIST SP 800-186 secp256r1, Ed25519, Curve25519 (approved 2023)
RFC 8032 Ed25519, Ed448
TLS 1.3 (RFC 8446) secp256r1, x25519, x448
COSE (RFC 9053) ES256 (secp256r1), EdDSA

Decision Tree:

Does your MCU have hardware ECC acceleration?
+-- YES -> Does it support secp256r1?
|  +-- YES -> **Use secp256r1** (10-20x faster)
|  +-- NO -> Use whatever curve is accelerated
|
+-- NO -> Software implementation required
   +-- Need digital signatures?
   |  +-- **Use Ed25519** (fastest, deterministic)
   |
   +-- Need key exchange (ECDH)?
   |  +-- **Use Curve25519** (side-channel resistant)
   |
   +-- Need both?
      +-- **Use Ed25519 + Curve25519**
         (Same underlying curve, different coordinate systems)

Real-World Example:

Smart lock manufacturer:

  • MCU: STM32L4 (has PKA peripheral for secp256r1)
  • Need: ECDH key exchange for Bluetooth pairing, ECDSA signatures for firmware
  • Compliance: Must support standard Bluetooth security

Decision:

  1. ECDH key exchange: secp256r1 (hardware accelerated, Bluetooth standard)
  2. Firmware signatures: secp256r1 (reuse same hardware, wider tool support)

Why not Curve25519?:

  • Bluetooth spec uses secp256r1 for pairing
  • Hardware acceleration available
  • Single curve simplifies code

Result: 5ms ECDH key exchange (vs 150ms in software), 20ms signature verification (vs 200ms RSA-2048).

Common Mistake: Reusing ECDH Ephemeral Keys

The Mistake: Generating one ECDH key pair and reusing it for multiple sessions to save computation time.

Why This Is Catastrophic:

ECDH (Elliptic Curve Diffie-Hellman) key exchange provides forward secrecy ONLY when keys are ephemeral (one-time use). Reusing keys destroys this critical property.

Attack Scenario:

Device generates ECDH key pair ONCE:
  private_key_A = random()
  public_key_A = private_key_A * G

Session 1 (Day 1):
  Device exchanges public_key_A with Server
  Shared secret S1 = private_key_A * public_key_B1
  -> Encrypted communication

Session 2 (Day 2):
  Device REUSES public_key_A with Server
  Shared secret S2 = private_key_A * public_key_B2
  -> Encrypted communication

Day 100: Attacker compromises device, extracts private_key_A

Attacker can now derive ALL past shared secrets:
  S1 = private_key_A * public_key_B1  (from captured traffic)
  S2 = private_key_A * public_key_B2  (from captured traffic)
  ...
  S99 = private_key_A * public_key_B99

Result: With a single key compromise, attacker decrypts 100 days of captured traffic.

The Correct Approach (Ephemeral Keys):

// CORRECT: Generate fresh keys PER SESSION
void establish_secure_session() {
    // Generate ephemeral key pair
    uint8_t private_key[32];
    uint8_t public_key[32];

    generate_random(private_key, 32);  // New random key
    curve25519_scalarmult_base(public_key, private_key);

    // Exchange public keys
    send_public_key(public_key);
    uint8_t peer_public_key[32] = receive_public_key();

    // Compute shared secret
    uint8_t shared_secret[32];
    curve25519_scalarmult(shared_secret, private_key, peer_public_key);

    // CRITICAL: Erase private key after use
    secure_memzero(private_key, 32);

    // Derive session keys from shared secret
    derive_session_keys(shared_secret);
}

Energy Cost Comparison:

Approach Key Generation Energy per Session Forward Secrecy
Reused keys (WRONG) Once 0 mJ None
Ephemeral keys (CORRECT) Every session 0.5 mJ Full

For a device connecting once per hour:

  • Daily energy cost: 24 x 0.5 = 12 mJ
  • Annual energy cost: 4.38 J
  • 10-year energy cost: 43.8 J (less than one LoRaWAN transmission!)

The savings from reusing keys is negligible, but the security cost is catastrophic.

How to Verify Your Code:

// RED FLAG: Key generation outside session loop
uint8_t device_private_key[32];
curve25519_generate_key(device_private_key);  // Generated once

while (true) {
    connect_to_server(device_private_key);  // WRONG: Reusing key
    sleep(3600);
}

// CORRECT: Key generation INSIDE session
while (true) {
    uint8_t ephemeral_key[32];
    curve25519_generate_key(ephemeral_key);  // New key per session
    connect_to_server(ephemeral_key);
    secure_memzero(ephemeral_key, 32);  // Erase after use
    sleep(3600);
}

The Rule: Ephemeral keys MUST be:

  1. Generated fresh for each session
  2. Erased from memory immediately after computing shared secret
  3. Never stored in non-volatile memory
  4. Never reused across sessions

Exception: Long-term device identity keys (for signatures) can be reused, but they serve a different purpose (authentication, not key exchange).

Concept Relationships
Concept Depends On Enables ECC vs RSA
ECC Math Elliptic curve discrete log Smaller keys for same security ECC-256 = RSA-3072 security
Ed25519 Signatures Curve25519 + EdDSA Deterministic signing (no RNG) 64-byte sig vs RSA 256-byte
X25519 Key Exchange Curve25519 + ECDH Constant-time operations Timing attack resistant
secp256r1 (P-256) NIST standardization Hardware acceleration (ESP32) Faster with HW, slower in SW
Key Size Scaling Exponential security growth Manageable key sizes ECC: linear, RSA: exponential
Quantum Threat Shor’s algorithm Need for post-quantum crypto Both ECC and RSA vulnerable

Critical Insight: ECC’s advantage grows with security level. For 256-bit security: ECC-512 vs RSA-15360 (30x difference).

11.12 See Also

Prerequisites:

Related Algorithms:

Implementation:

Hardware:

Advanced Topics:

Elliptic curves over finite fields provide cryptographic security through the Elliptic Curve Discrete Logarithm Problem (ECDLP).

\[y^2 = x^3 + ax + b \pmod{p}\]

Point addition: Given \(P\) and \(Q\) on curve, compute \(R = P + Q\). Scalar multiplication: \(Q = k \times P\) (add \(P\) to itself \(k\) times).

Working through a simplified example:

Given: Curve25519 with base point \(G\), private key \(d = 12\), compute public key \(Q = d \times G\).

Step 1: Curve25519 parameters

  • Prime: \(p = 2^{255} - 19\)
  • Curve equation: \(y^2 = x^3 + 486662x^2 + x \pmod{p}\) (Montgomery form)
  • Base point \(G\): \((x_G = 9, y_G = \ldots)\)

Step 2: Scalar multiplication \(Q = 12 \times G\) (double-and-add)

  • Binary: \(12 = 1100_2 = 2^3 + 2^2\)
  • Compute: \(G\), \(2G\), \(4G\), \(8G\) (doubling)
  • Add: \(Q = 8G + 4G\)

Step 3: Operations count for this tiny example

  • Point doublings: 3 (for bits in 12)
  • Point additions: 1 (combine \(8G + 4G\))
  • Total field operations: ~15 multiplications mod \(p\)

In practice: Real Curve25519 scalar multiplication uses a 255-bit scalar, requiring ~255 point doublings and ~128 additions – thousands of field multiplications. On an ESP32 @ 240 MHz in software, this takes approximately 1-5 ms per scalar multiplication. With hardware acceleration, it drops to 0.1-0.5 ms.

Comparison: RSA-3072’s modular exponentiation takes 50-200 ms on similar hardware – making ECC 50-200x faster for equivalent 128-bit security.

11.13 Summary

Key Takeaways
  1. ECC = Same Security, Much Smaller Keys: 256-bit ECC provides ~128-bit security, equivalent to 3072-bit RSA, with dramatically smaller keys, faster signing, and lower power consumption
  2. Ed25519 for Signatures: The recommended choice for IoT digital signatures – deterministic (no RNG needed), fast, and resistant to implementation errors
  3. Curve25519/X25519 for Key Exchange: Built-in timing attack resistance makes it ideal for software implementations without hardware acceleration
  4. secp256r1 When Hardware Accelerated: Leverage ESP32, STM32, and nRF52 crypto accelerators for maximum performance and power efficiency
  5. Protect Private Keys: Use hardware secure elements (ATECC608) when possible; never expose private keys in firmware

Summary diagram of ECC for IoT covering Ed25519 signatures, Curve25519 key exchange, secp256r1 hardware acceleration, and key protection best practices

ECC for IoT - Key Takeaways Summary

::

::

11.14 What’s Next

Next Chapter Description
Hash Functions and Data Integrity Learn how cryptographic hash functions like SHA-256 verify data integrity and authenticate messages in IoT systems
Key Management Best practices for managing ECC keys across IoT deployments
TLS/DTLS for IoT How ECC is used in transport layer security protocols