8 Elliptic-Curve Cryptography for IoT
8.1 Start Simple
Choose the Job Before the Curve
Picture a small tracker that must prove who sent an update without carrying a large key. A protocol means the agreed rules and message order that let two systems communicate.
Name whether the job is key agreement or signing, then name the peer, approved curve, library, stored key, and failure response. Test a valid peer, a changed signature, a wrong key, and a repeated session.
Keep inputs, selected rules, verification results, timings, and library version. This proves one supported setup, not that a new curve or custom method is safe; the deeper sections explain the mathematics, standard choices, storage, and implementation limits.
Imagine doing the same public-key jobs on a coin-cell sensor with limited flash, RAM, radio airtime, and patience for slow handshakes. ECC keeps the trust setup and signature ideas but makes the keys and signatures small enough for constrained devices. Start with the role first, key agreement or signing, then choose a standard curve and reviewed library that the protocol already supports.
8.2 Overview: Strong Public-Key Security in a Small Package
Elliptic-curve cryptography (ECC) is a way of building the same public-key tools as older systems, key agreement and digital signatures, but with much smaller keys and signatures for the same level of security. That size advantage is exactly what constrained IoT devices need: smaller keys mean less flash and RAM, smaller signatures and public values mean shorter messages and certificates, and the operations cost less CPU time and energy per use.
The common misunderstanding is to treat "use ECC" as a single decision. ECC is a family of primitives, not one feature. A curve such as P-256 or Curve25519 is the underlying mathematics; it is not a protocol, and it does not by itself say which job you are doing. The two jobs people most often mix up are key agreement, which sets up a shared secret between two parties, and signatures, which prove that an artifact came from the holder of a signing key.
If you only need the intuition, this layer is enough: ECC gives RSA-grade security with far smaller keys, which suits constrained devices. Use ECDH (or X25519) to agree on a session key, use ECDSA or EdDSA to sign and verify firmware and certificates, keep those keys separate, and pick a standard curve rather than inventing one.
Think of two padlock styles that are equally hard to pick, but one is the size of a suitcase and the other fits on a keyring. For a battery-powered sensor with a few kilobytes to spare, the small lock that is just as strong is the obvious choice. ECC is the keyring-sized lock: comparable strength, a fraction of the size and cost.
Inspect Figure 8.1 to separate the key-agreement and signature paths before judging curve size or speed.
Read Figure 8.1 from the security role into curve policy and protocol support, then through the private-key generation, storage, and use boundary to release evidence. ECDH or X25519 establishes session material; ECDSA or EdDSA approves artifacts or identities. Keeping those keys and jobs separate prevents a convenient implementation choice from widening authority. This route connects ECC’s compact representation to an evidence-backed lifecycle rather than a benchmark-only decision.
8.2.1 The One-Minute View
Small keys, strong security
ECC reaches RSA-equivalent security with far smaller keys and signatures, so it fits limited flash, RAM, bandwidth, and energy budgets.
Two jobs, not one
Key agreement (ECDH, X25519) sets up a shared secret; signatures (ECDSA, EdDSA) prove origin. They are different roles with different keys.
Use standard curves
Pick a vetted curve such as P-256 or Curve25519 that your protocol supports, and use a reviewed library. Do not invent curves or hand-write the math.
8.2.2 Beginner Examples
These examples show how elliptic-curve keys support constrained devices, key agreement, and signatures. A 256-bit elliptic-curve key targets roughly the same security as an RSA key of about 3072 bits. It is much smaller to store and send, which is why constrained devices favour it. Two devices run ECDH to derive a shared session key over an open link without transmitting the secret. A fast symmetric cipher then protects the traffic. A device verifies a firmware image by checking an ECDSA or Ed25519 signature with the maker's public key. Only the maker's private key could have produced a signature that verifies.
8.2.3 Overview Knowledge Check
If you can explain ECC's size advantage and name its two main jobs, you can stop here. Continue to Practitioner to pick the role, the curve, and the validation a real design needs.
8.3 Practitioner: Pick the Role, the Curve, and the Validation
The practical job is to choose the right ECC role for each feature, select an approved curve the whole system supports, and prove the validation steps that turn a raw result into a safe key or a trusted artifact. The common review failure is approving "we use an elliptic curve" without naming the role, the curve, or the checks that reject bad inputs.
8.3.1 Walkthrough: Establishing a Session Key With ECDH
Follow the sequence from decision to evidence. First, Choose the role and group. For fresh session keys, pick key agreement (ECDH or X25519) on an approved group that both the device and the server support; for artifact approval, pick a signature algorithm instead. Next, Generate the private key in its boundary. Create the private scalar inside the device's protected store with sufficient entropy, and use an ephemeral key per session where forward secrecy is required. Next, Validate the peer's public key. Reject malformed encodings, the wrong group, and invalid or low-order points before doing any computation with them. Next, Derive keys through a KDF. Never use the raw shared secret as a key. Feed it into the protocol's KDF with the transcript, role, algorithm, and endpoint context. Finally, Scope the derived keys. Bind each output to one purpose, such as encryption or integrity for one direction, exactly as the protocol requires.
Inspect Figure 8.2 to follow both peers’ fresh contributions through validation and derivation before any traffic key exists.
Read Figure 8.2 from each endpoint’s private value and public share to peer validation, shared secret material, and the KDF. Validation rejects the wrong group or malformed value before computation; the KDF binds transcript, role, and endpoint context; and separate outputs become scoped session keys. The raw ECDH result is never used directly. This sequence connects the mathematical agreement to the authenticated, purpose-bound channel the system actually needs.
8.3.2 Choosing a Curve and Algorithm
Use the curves your protocol or compliance profile approves, supported by every component in the path: device, gateway, certificate authority, and cloud. In a TLS 1.3, DTLS 1.3, or Matter deployment, for example, the selected group and signature algorithm must match the protocol's named groups, the certificate profile, and any secure element or accelerator support. Treat curve selection as a system contract, not a local coding preference.
8.3.3 Worked Review: A Firmware Update Gate
A product accepts signed firmware. The team says "the signature is verified, so it is safe." The reviewer turns that into evidence questions.
What the claim covers
A valid ECDSA or Ed25519 signature proves the image was not altered after signing and was produced by a holder of the signing private key.
What the claim misses
It does not say whether the public key maps to the real release authority, whether the signature covers the version and product fields, or whether a rollback to an old signed image is blocked.
Conclusion
Require a signature over a canonical manifest (product identity, version, rollback policy, and image digest), a verification key tied to the release authority, key-usage separation from test signing, and negative tests for modified, wrong-line, revoked-key, and rollback cases.
8.3.4 Practitioner Knowledge Check
If you can match each feature to a role, choose an approved curve, and name the validation steps, you can stop here. Continue to Under the Hood for the mathematics, the nonce hazard, and point validation.
8.4 Under the Hood: The Hard Problem, the Curves, and the Sharp Edges
The deeper layer explains why ECC is secure, why its keys can be so small, and where the sharp implementation edges are. Each role is a distinct guarantee, and a weakness in randomness, point validation, or key separation can undo the strength of the curve itself.
8.4.1 The Hard Problem and Why Keys Are Small
ECC builds its keys from points on an elliptic curve. A private key is a secret number (a scalar) and the matching public key is that scalar multiplied by a fixed base point on the curve. Multiplying is easy, but going backwards, recovering the scalar from the resulting point, is the elliptic-curve discrete-logarithm problem, and no efficient classical method to solve it is known. Because that problem is harder per bit than the integer factoring behind RSA, ECC needs far fewer bits for the same strength: a 256-bit elliptic-curve key targets about a 128-bit security level, comparable to RSA at roughly 3072 bits. That ratio is the entire reason ECC fits constrained IoT.
8.4.3 Signatures: ECDSA’s Nonce Hazard and EdDSA’s Fix
ECDSA produces each signature using a secret, single-use random value, often called the nonce or k. This value must be unique and unpredictable for every signature, because a reused or biased k lets an attacker recover the private signing key by solving a simple equation across two signatures. This exact failure has broken real systems. Two defenses exist: deterministic ECDSA (RFC 6979) derives k from the message and the private key so it no longer depends on a runtime random generator, and EdDSA (such as Ed25519) is deterministic by construction and uses curve formulas that also help resist some side-channel attacks. EdDSA removes that one class of randomness failure, but private-key storage, signing the correct canonical bytes, and trusting the right public key still matter.
After controlling signature nonce generation, inspect Figure 8.3 to see what must still be bound and verified before an ECC signature becomes release approval.
Read Figure 8.3 from canonical bytes into the protected signer, then through public-key verification and policy to the release decision. Deterministic nonce generation protects the private-key calculation, but approval also depends on signing the intended bytes, mapping the verification key to the real authority, and enforcing identity, rollback, and expiry. The visual connects the nonce hazard to the complete evidence chain rather than letting one correct signature equation stand in for policy.
8.4.4 Point Validation and Vetted Implementations
ECC has implementation pitfalls that have nothing to do with the curve's strength. If a device accepts a peer public key without checking that it is a valid point on the expected curve and not a small-order point, an attacker can use invalid-curve or small-subgroup inputs to extract information about the private key. So validating the peer's public key is a security step, not a formality. Equally, the arithmetic must be done by a vetted, constant-time library: hand-written ECC code tends to leak the private key through timing or other side channels. Use the protocol's approved curves and a reviewed implementation rather than rolling your own.
8.4.5 Key Separation and Post-Quantum Migration
One private key should not sign firmware, authenticate the device, and derive sessions all at once; separate keys per role contain a compromise and make rotation and audit readable. Looking ahead, a large-scale quantum computer would solve the elliptic-curve discrete-logarithm problem and break ECC, just as it would break RSA. NIST has standardized post-quantum algorithms (ML-KEM for key encapsulation and ML-DSA for signatures), and long-lived devices, especially long-lived signing roots, should plan a migration or hybrid path rather than assume ECC alone will last the full data lifetime.
8.4.6 Mechanisms and Failure Modes
8.4.7 Common Pitfalls
Follow the sequence from decision to evidence. First, Using the raw shared secret. ECDH and X25519 produce key material, not a finished key. Always run it through the protocol KDF with context. Next, Skipping public-key validation. Malformed, wrong-group, or low-order peer keys must be rejected before any computation. Next, Reusing ECDSA nonces. A repeated or biased per-signature value leaks the private key; use deterministic ECDSA or EdDSA. Next, Mixing key purposes. Do not let one key sign firmware, authenticate transport, and derive sessions; separate roles and keys. Next, Trusting any public key. A valid signature only proves possession of the matching private key; identity still needs enrollment, a certificate, or a pinned trust anchor. Finally, No migration path. Long-lived devices need a way to update curves, trust anchors, and algorithms, and a post-quantum plan where the data lifetime demands it.
8.4.8 Under-the-Hood Knowledge Check
At this depth, ECC is a set of independent guarantees on top of one hard problem: a standard curve and vetted library, validated peer keys, a KDF that scopes the shared secret, signatures with safe nonces, and separate keys per role. Get those right and ECC delivers strong public-key security in a footprint a constrained device can afford, with a migration plan ready for the post-quantum era.
8.5 Fit a Signed Update Into the Radio Budget
For elliptic-curve cryptography, a field valve wakes briefly to receive a firmware manifest over a narrow radio link. Figure 8.1 first separates key agreement from signature work. Figure 8.2 then shows two parties deriving shared secret material, while Figure 8.3 follows a signed digest from the approved sender to verification on the valve. The private signing key never needs to travel with the update.
A 256-bit elliptic-curve public key is 32 bytes before its format overhead because (256/8=32\ \text{bytes}). The chapter’s comparison places that curve near a 128-bit security target, while an RSA alternative is roughly 3,072 bits, or (3072/8=384\ \text{bytes}), before its own encoding. The raw RSA key material is therefore (384/32=12) times larger in this simple size comparison. That does not make every ECC implementation safe; curve choice, validation, random numbers, key storage, and protocol use still decide the result.
8.5.1 Predict the Curve Operation
- Predict: The valve needs to prove a manifest came from the release signer. Should it use key agreement alone? Check: No. Signature verification supplies origin and integrity evidence for the manifest.
- Predict: A device accepts any point without validation. Does a strong named curve repair that input mistake? Check: No. ECC security also depends on validating inputs and using the operation correctly.
8.6 Summary
Carry the chapter forward as one connected chain. First, ECC builds key agreement and signatures from points on an elliptic curve, reaching RSA-equivalent security with much smaller keys, which suits constrained IoT. Then, Security rests on the elliptic-curve discrete-logarithm problem; a 256-bit curve key targets about 128-bit security, comparable to RSA at roughly 3072 bits. Then, Key agreement (ECDH, X25519) and signatures (ECDSA, EdDSA) are separate roles that should use separate keys. Then, ECDH output is raw key material: validate the peer’s public key, then derive scoped keys through a context-bound KDF, and use ephemeral keys (ECDHE) for forward secrecy. Then, ECDSA needs a unique, unpredictable per-signature nonce; reuse leaks the private key, so prefer deterministic ECDSA (RFC 6979) or EdDSA (Ed25519). Then, Use standard curves (P-256, Curve25519) and a vetted constant-time library; validate points to block invalid-curve and small-subgroup attacks. Finally, A large-scale quantum computer would break ECC, so long-lived devices should plan a post-quantum or hybrid migration (NIST ML-KEM and ML-DSA).
ECC is the practical default for IoT public-key work because it delivers strong security in a tiny footprint, but the curve’s strength is not enough on its own. Name the role, use a standard curve and a reviewed library, validate peer keys, derive keys through a KDF, keep signing nonces safe, and separate keys by purpose.
8.7 See Also
Public Key Cryptography
Revisit the broader public-key roles, certificates, and the hybrid pattern that ECC implements efficiently.
TLS and DTLS
Watch ECDHE key agreement and ECDSA or EdDSA signatures combine into a real secure session.
Encryption Key Management
Generate, store, separate, and rotate the private keys that ECDH and the signing roles depend on.