7 Public-Key Cryptography for IoT
7.1 Start Simple
Prove the Update Came From the Approved Sender
Picture a new device receiving an update from a server it has never contacted before. Firmware means the software stored on a device that controls how it operates.
Name the signed update, public key, protected private key, verification step, version rule, and rejection path. Test an approved image, changed bytes, a wrong signer, and an older valid image.
Keep hashes, signature results, key identity, version, time, and final action. This proves one signing and verification path, not safe key storage or code quality; the deeper sections compare encryption, signing, key agreement, and trust setup.
Imagine a new device meeting the cloud for the first time with no shared secret already installed. Public-key cryptography gives each side a public part it can show and a private part it must guard, so they can set up trust without exposing the secret. Start with two questions: who needs to prove identity or approval, and how will the peers create a fresh session key for the fast symmetric channel?
7.2 Overview: One Key Pair, Several Different Jobs
Symmetric encryption is fast, but it assumes both sides already share the same secret key. Public-key cryptography solves the harder question that comes first: how do two devices that have never met agree on a secret over an open network, and how does a device confirm a firmware image really came from its maker without shipping the maker's secret to every device?
The answer is to split the key into a pair. Each actor holds a public key that is safe to share and a private key that stays secret. The general rule is simple: the public key encrypts data or verifies signatures, and the private key decrypts data or creates signatures. Because the two halves are different, you can publish one without giving away the other.
If you only need the intuition, this layer is enough: public-key cryptography does three separate jobs, namely set up a shared key, prove who sent something, and bind a key to an identity. The operations are heavy, so they are used at the edges to establish trust and keys, while fast symmetric encryption protects the bulk data.
Think of a padlock you can hand out freely. Anyone can take one of your open padlocks (your public key), snap it shut on a box, and send it to you, but only your private key can open it. Signatures flip the idea: you press a unique wax seal that only you can make (your private key) onto a letter, and anyone holding a picture of your seal (your public key) can confirm the letter is yours without being able to forge it.
Inspect Figure 7.1 to separate what the freely shared public key can do from the private operation that must stay inside its owner boundary.
B#, R06/J2.>, Cipher Text, DECRYPT, PRIVATE KEY">
Read Figure 7.1 from plaintext and the public-key operation into ciphertext, then to the private-key operation that recovers the message. Reverse the roles conceptually for signatures: the private key creates the signature and the public key verifies it. The key pair therefore supports distinct jobs rather than one generic asymmetric action, which sets up the chapter’s separation of key agreement, signatures, and identity.
7.2.1 The One-Minute View
Share the public, guard the private
Every actor holds a key pair. The public key can be published; the private key never leaves its owner.
Three distinct jobs
Key agreement, public-key encryption, and digital signatures are separate uses. Do not treat them as one feature.
It sets up, symmetric carries
Public-key work is slow, so it authenticates peers and establishes keys; symmetric AEAD then protects the data. This is the hybrid pattern.
7.2.2 Beginner Examples
These examples separate public-key jobs from algorithm names. A device that checks a firmware signature uses the maker's public key. Only the maker's secret private key could have produced a signature that verifies. Two peers can use key agreement to derive a shared secret over an open link. They never send that secret across the wire. "We use RSA" is not a claim a reviewer can accept. It names a family but not the job, the padding, the key size, or whose key it is.
7.2.3 Overview Knowledge Check
If you can explain why a key pair splits into a public and a private half, and name its three jobs, you can stop here. Continue to Practitioner to walk through a real onboarding and firmware-verification flow.
7.3 Practitioner: Onboard a Peer and Verify a Release
The practical job is turning the three public-key roles into a working flow: validate identity, agree a fresh session key, then hand the data path to symmetric AEAD. In a TLS 1.3 or DTLS 1.3 channel, that separation appears as certificate validation for identity, ECDHE key shares for the fresh secret, HKDF-derived traffic keys, and AEAD records for the data path. Firmware verification runs on a separate signing chain. Each step uses a different key with a different owner, and the most common failure is asking one key to do every role.
7.3.1 Walkthrough: The Hybrid Onboarding and Verification Flow
Follow the sequence from decision to evidence. First, Validate identity. Check the peer's certificate chain to a trusted root, or a pinned public key on constrained devices: expected name or device identity, validity period, and allowed issuer. Parsing a certificate is not the same as validating it. Next, Agree a fresh secret. Use ephemeral key agreement (ECDHE or DHE) through a vetted protocol so each session derives a new shared secret. Ephemeral keys give forward secrecy, so a later compromise of long-term keys does not expose past sessions. Next, Derive scoped keys. Feed the shared secret into the protocol key schedule (a KDF), binding keys to direction, role, and session context, rather than using the raw secret as a payload key. Next, Protect the traffic with symmetric AEAD. The public-key work is finished. Bulk telemetry and commands now use authenticated encryption, which is far cheaper per message. Finally, Verify releases on a separate chain. Firmware arrives with a signed manifest covering version, target device class, package hash, rollback policy, and signing identity. Verify the manifest signature with the firmware trust chain, using a key distinct from device identity, before installing.
Inspect Figure 7.2 to locate where expensive public-key work ends and symmetric protection begins for continuing traffic.
Read Figure 7.2 from certificate validation to ephemeral key agreement and context-bound derivation. Those steps authenticate the peer and create scoped session keys; symmetric AEAD then protects continuing telemetry and commands. Follow the separate firmware branch to signature verification, which uses a distinct trust chain. This order connects onboarding to two independent release claims: an authenticated channel and an authorized artifact.
7.3.2 Public-Key Roles and Evidence
7.3.3 Worked Review: A Sensor Joining the Cloud Through a Gateway
A temperature sensor joins a cloud service through a gateway. The gateway must route traffic but must not be able to impersonate the cloud or install firmware. The team states the channel is safe "because it uses TLS." The reviewer turns that into evidence questions.
What the claim covers
A vetted TLS handshake can authenticate the cloud through certificate validation, set up fresh session keys with ephemeral key agreement, and then protect traffic with symmetric AEAD.
What the claim misses
It says nothing about whether the cloud confirms this device's enrolled identity, whether firmware is verified on a separate signing chain, or whether the gateway is being trusted with more than routing.
Conclusion
Require mutual identity validation, a separate firmware signing chain, ephemeral key agreement for forward secrecy, and negative tests for wrong name, wrong issuer, and bad signatures before accepting the design.
7.3.4 Practitioner Knowledge Check
If you can run the hybrid onboarding flow and keep each key in its own role, you can stop here. Continue to Under the Hood for the mechanisms, algorithm fit, and failure modes.
7.4 Under the Hood: Mechanisms, Algorithm Fit, and Failure Modes
The deeper layer explains how each role actually works and why each is a separate guarantee. The same "key pair" idea supports very different mathematics, and a weakness in padding, randomness, or key custody can undo the rest.
7.4.1 The Key-Pair Idea and Trapdoor Functions
Asymmetric schemes rest on operations that are easy in one direction but hard to reverse without the private key. RSA relies on the difficulty of factoring the product of two large primes; elliptic-curve schemes rely on the hardness of the elliptic-curve discrete-logarithm problem. The public key describes the easy direction (encrypt or verify), and the private key is the secret that makes the hard direction (decrypt or sign) feasible. Because a hard mathematical problem is the only thing protecting the private key, parameters and key sizes must be chosen large enough to keep that problem out of reach.
7.4.2 RSA Key Generation, Concretely
The trapdoor behind RSA is built by a specific recipe. Pick two large prime numbers, multiply them to get the modulus, and compute the Euler totient of that modulus, the product of each prime minus one. From there, choose a public exponent that shares no common factor with the totient, and solve for the one private exponent that undoes it under that modulus. The public key is the exponent-and-modulus pair used to encrypt or verify; the private key is the paired exponent used to decrypt or sign. Only the private exponent can undo the operation efficiently, because recovering it from the public values means factoring the modulus back into its two original primes, the same hard problem named above.
A toy instance makes the arithmetic checkable by hand, though real keys use primes hundreds of digits long so that factoring stays out of reach. Picking the primes 2 and 7 gives a modulus of 14 and a totient of 6. Choosing 5 as the public exponent, since it is the only value in range that shares no factor with 6 or 14, gives the public key (5, 14); solving for the matching private exponent gives 11, so the private key is (11, 14). Encrypting the message "2" raises it to the fifth power and reduces it modulo 14, giving the ciphertext 4; decrypting raises that ciphertext to the eleventh power modulo 14 and recovers the original message, 2. Production key generation swaps the toy primes for ones long enough that this factoring step stays computationally out of reach.
7.4.3 Key Agreement and Forward Secrecy
Diffie-Hellman (DH) lets two peers each combine their own secret with the other side's public value and arrive at the same shared secret, without ever transmitting it; ECDH is the elliptic-curve form. The crucial distinction is static versus ephemeral. When each side uses a fresh, single-use key per session (DHE or ECDHE), the exchange provides forward secrecy: a later compromise of the long-term keys does not expose the earlier sessions. Static key exchange does not give this property. In both cases the shared secret is never used directly as a traffic key; a key derivation function expands it into separate, scoped keys.
7.4.4 Public-Key Encryption and Signatures Need Padding
RSA must be used with standardized padding. Use RSA-OAEP for encryption and RSA-PSS for signatures. "Textbook" RSA, the raw modular exponentiation with no padding, is deterministic and malleable and is not a safe scheme. For signatures, common choices are RSA-PSS, ECDSA, and EdDSA such as Ed25519. A signature provides integrity, authenticity, and non-repudiation at once: only the private-key holder can create it, and anyone with the public key can verify it. One sharp pitfall: ECDSA needs a unique, unpredictable per-signature random value, because a reused or predictable value leaks the private key. Deterministic signing (RFC 6979) and EdDSA avoid that hazard by construction.
7.4.5 ECC and Algorithm Fit for Constrained IoT
Elliptic-curve cryptography reaches security equivalent to RSA with much smaller keys, which is why it suits constrained IoT: smaller keys and signatures mean less RAM, less flash, less bandwidth, and less energy per operation. Common, well-established choices include NIST P-256 for ECDSA and ECDH, and Curve25519 used as X25519 for key agreement and Ed25519 for signatures. RSA-2048 and RSA-3072 remain common where an ecosystem still requires RSA. Treat these as typical selections, not as the only valid ones, and confirm support on the actual device, protocol, and accelerator rather than copying a benchmark from another board.
Before comparing algorithm names, inspect Figure 7.3 to keep key agreement, signatures, ecosystem support, and evidence as separate selection axes.
Read Figure 7.3 by role first: key-establishment mechanisms belong on a different path from signature mechanisms. Next check protocol and implementation support on the target, then key and signature size, protected-key storage, timing, and release tests. The matrix does not declare one universal winner. It connects ECC’s constrained-device advantages to the chapter’s running rule that an approved choice must fit its job and deployed ecosystem.
7.4.6 Certificates and Trust Chains
A public key is only useful once the device knows whose key it is. An X.509 certificate binds an identity to a public key and is signed by a certificate authority (CA). Verification walks the chain from the presented certificate up through any intermediates to a trusted root, checking the signature, name, validity period, and intended purpose at each step. Parsing is not validation: a device must reject wrong-issuer, wrong-name, expired, not-yet-valid, and revoked credentials, and it must fail closed when revocation evidence is unavailable. Constrained devices that cannot carry full PKI may instead provision raw public keys or pre-shared keys with the same discipline.
7.4.7 Post-Quantum Migration
A large-scale quantum computer would undermine RSA and elliptic-curve cryptography by solving the very problems that protect their private keys. To prepare, NIST has standardized ML-KEM for key encapsulation and ML-DSA for digital signatures as quantum-resistant options. Migration across IoT is ongoing rather than finished, and designs increasingly plan hybrid transitions that run a classical and a post-quantum mechanism together, especially for long-lived signing roots whose signatures must stay trusted for many years. Plan the migration path now without inventing parameters or deployment numbers.
7.4.8 Mechanisms and Failure Modes
7.4.9 Common Pitfalls
Follow the sequence from decision to evidence. First, Treating one key pair as a do-everything switch. Key agreement, encryption, and signing are different jobs; reusing one key across roles weakens all of them. Next, Using textbook RSA. Unpadded RSA is unsafe. Use RSA-OAEP for encryption and RSA-PSS for signatures. Next, Skipping forward secrecy. Static key exchange exposes all recorded past traffic once a long-term key leaks; prefer ephemeral ECDHE key agreement. Next, Parsing a certificate instead of validating it. A mathematically valid signature is not enough; check chain, name, validity, purpose, and revocation, and fail closed. Finally, Sharing or exporting private keys. A fleet-wide or extracted private key turns one device into an impersonation path for every device; use per-device keys and keep signing keys off-device.
7.4.10 Under-the-Hood Knowledge Check
At this depth, public-key cryptography is a set of independent guarantees: a key pair whose security rests on a hard mathematical problem, ephemeral key agreement for forward secrecy, padded encryption and signatures, certificates that bind keys to identities and fail closed, and per-role keys with disciplined custody. A trustworthy review names the job for each key and tests that bad inputs are rejected, rather than accepting a single "we use RSA" or "we use TLS" label.
7.5 Verify a Gateway Update With the Public Half
A gateway downloads an update while an attacker controls the local Wi-Fi access point. Figure 7.1 assigns the private and public keys to different jobs. Figure 7.2 follows the release digest into a signature and then into device-side verification, while Figure 7.3 keeps encryption, signatures, and key agreement from being treated as interchangeable.
The release service signs the manifest digest with its protected private key. The gateway stores the matching public key and verifies before installation. Possessing that public key lets the gateway check evidence; it does not let the gateway create a valid release signature. If verification fails, the correct update state is rejected, even when the download completed without a network error.
7.5.1 Predict the Public-Key Job
- Predict: A technician encrypts a manifest with the gateway’s public key. Does that prove the technician approved it? Check: No. Confidentiality for the gateway is not the same as a signature from an authorised release key.
- Predict: An attacker replaces both image and unsigned hash. Will comparing those two values expose the change? Check: No. The expected hash needs authenticated public-key evidence, such as a verified signature.
7.6 Summary
Carry the chapter forward as one connected chain. First, Asymmetric cryptography uses a key pair: a shareable public key and a secret private key. In general the public key encrypts or verifies, and the private key decrypts or signs. Then, It does three distinct jobs: key agreement (DH and ECDH), public-key encryption or key encapsulation (RSA-OAEP, ML-KEM), and digital signatures (RSA-PSS, ECDSA, Ed25519). Then, Ephemeral key agreement (ECDHE or DHE) provides forward secrecy; static key exchange does not. Then, Signatures provide integrity, authenticity, and non-repudiation, because only the private-key holder can produce a valid one. Then, Public-key operations are heavy, so they authenticate peers and set up keys while symmetric AEAD protects the bulk data, which is the hybrid pattern. Then, ECC reaches RSA-equivalent security with much smaller keys (for example P-256 and Curve25519), which suits constrained IoT; RSA-2048 and RSA-3072 remain common where an ecosystem requires RSA. Then, Certificates (X.509) bind an identity to a public key and are verified up a chain to a trusted root; constrained devices may use raw public keys or pre-shared keys instead. Finally, NIST has standardized ML-KEM and ML-DSA as post-quantum options, and IoT migration to them is ongoing.
Use public-key cryptography to establish trust and keys, not to encrypt every payload. Name the job for each key pair (agree, encrypt, or sign), use ephemeral agreement for forward secrecy, padded RSA or modern ECC, certificates that fail closed, and per-role keys with disciplined custody. “We use RSA” is never, by itself, a security claim.
7.7 See Also
Encryption Principles & Crypto Basics
Revisit AEAD, hashes, MACs, signatures, and the four security jobs behind every primitive choice.
Symmetric Encryption
See how the hybrid pattern hands the data path to AES-GCM, AES-CCM, and ChaCha20-Poly1305.
Elliptic-Curve Cryptography
Go deeper on the curves, such as P-256 and Curve25519, that make public-key crypto fit constrained IoT.
TLS and DTLS
Watch certificates, ephemeral key agreement, and signatures combine into a real secure channel.