1429  Elliptic Curve Cryptography for IoT

1429.1 Learning Objectives

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

  • Understand ECC Fundamentals: Explain how elliptic curves provide security equivalent to RSA with 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: Use elliptic curve key exchange and digital signatures in IoT applications
TipIn Plain English

Elliptic Curve Cryptography (ECC) provides the same security as RSA with 10x smaller keys and 10x faster operations. This makes it the ideal choice for battery-powered IoT devices with limited memory and processing power.

Why it matters: A LoRaWAN sensor with 51-byte payload limits can’t fit an RSA-2048 signature (256 bytes), but an Ed25519 signature (64 bytes) fits easily. ECC enables strong cryptography on the most constrained devices.

1429.2 Why ECC for IoT?

Elliptic curve cryptography provides equivalent security to RSA with dramatically smaller key sizes, making it ideal for resource-constrained IoT devices.

1429.2.1 Key Size Comparison

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

1429.2.2 IoT Resource Impact

Metric RSA-2048 ECC-256 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 Similar
Power per Op 10-20 mJ 1-2 mJ 10x less
TipECC: The Smart Choice for IoT

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

  • Battery life: ECC-256 uses ~10x less CPU cycles than RSA-2048
  • 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 security equivalent to RSA-3072

1429.3 How Elliptic Curves Work

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 ECDLP has no known sub-exponential algorithm. 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.

1429.5 ECDH Key Exchange

Elliptic Curve Diffie-Hellman (ECDH) enables two parties to establish a shared secret:

%% fig-alt: "ECDH key exchange showing Alice and Bob computing shared secret using elliptic curve points"
%%{init: {'theme': 'base', 'themeVariables': {'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#16A085', 'secondaryColor': '#E67E22'}}}%%
sequenceDiagram
    participant Alice as IoT Device
    participant Channel as Network
    participant Bob as Server

    Note over Alice,Bob: Public: Curve parameters (G, p, a, b)

    Note over Alice: Choose secret a<br/>Compute A = aG
    Note over Bob: Choose secret b<br/>Compute B = bG

    Alice->>Channel: Send A (public point)
    Channel->>Bob: Forward A

    Bob->>Channel: Send B (public point)
    Channel->>Alice: Forward B

    Note over Alice: Compute S = aB = abG
    Note over Bob: Compute S = bA = abG

    Note over Alice,Bob: Both have same shared secret S<br/>Derive AES key: K = KDF(S)

Figure 1429.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

1429.6 ECDSA Digital Signatures

Elliptic Curve Digital Signature Algorithm provides authentication and non-repudiation:

%% fig-alt: "ECDSA signature process for firmware verification"
%%{init: {'theme': 'base', 'themeVariables': {'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#16A085', 'secondaryColor': '#E67E22'}}}%%
flowchart TB
    subgraph Sign["Manufacturer Signing"]
        Firmware[Firmware Binary]
        Hash1[SHA-256 Hash]
        PrivKey[Private Key d]
        Signature[ECDSA Signature<br/>r, s values<br/>64 bytes]

        Firmware --> Hash1
        Hash1 --> Signature
        PrivKey -.-> Signature
    end

    subgraph Verify["Device Verification"]
        RecvFW[Received Firmware]
        Hash2[SHA-256 Hash]
        PubKey[Public Key Q<br/>Embedded in device]
        Check{Signature Valid?}

        RecvFW --> Hash2
        Hash2 --> Check
        PubKey -.-> Check
        Signature --> Check
    end

    Check -->|Yes| Install[Install Firmware]
    Check -->|No| Reject[Reject Update]

    style Sign fill:#2C3E50,stroke:#16A085,color:#fff
    style Verify fill:#16A085,stroke:#2C3E50,color:#fff
    style Install fill:#27AE60,stroke:#2C3E50,color:#fff
    style Reject fill:#E74C3C,stroke:#2C3E50,color:#fff

Figure 1429.2: ECDSA firmware signing and verification

1429.6.1 Ed25519 vs ECDSA

Feature ECDSA (secp256r1) Ed25519
Signature Size 64-72 bytes 64 bytes
Sign Speed Requires RNG No RNG needed
Verify Speed Fast Very fast
Side-Channel Resistance Implementation-dependent Built-in
Standards FIPS, 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.

1429.7 IoT Implementation Considerations

1429.7.1 Hardware Acceleration

Many IoT microcontrollers include ECC hardware:

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

1429.7.2 Software Libraries

For platforms without hardware ECC:

  • 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

1429.7.3 Bandwidth Optimization

For constrained networks (LoRaWAN, NB-IoT, Sigfox):

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

1429.8 Knowledge Check

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 security equivalent to RSA-3072. RSA-2048 signatures are 256 bytes - far exceeding the 51-byte LoRaWAN payload limit. 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.

1429.9 Best Practices for IoT ECC

  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

1429.10 Summary

  • ECC provides RSA-equivalent security with 10x smaller keys - critical for constrained IoT devices
  • Ed25519 is the recommended choice for digital signatures - fast, secure, deterministic
  • Curve25519 is ideal for key exchange - resistant to timing attacks
  • secp256r1 should be used when hardware acceleration is available
  • ECC enables strong cryptography on battery-powered devices with limited bandwidth
  • Hardware secure elements (ATECC608) provide the strongest private key protection

1429.11 What’s Next

Continue to Hash Functions and Data Integrity to learn how cryptographic hash functions like SHA-256 verify data integrity and authenticate messages in IoT systems.