7 Public-Key Cryptography for IoT

Key Agreement, Signatures, Certificates, and Role Separation

security

cryptography

iot

Keywords

IoT public key cryptography, asymmetric encryption, ECDHE forward secrecy, digital signatures, X.509 certificates, ECC for IoT, hybrid cryptography

7.1 Start Simple

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?

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.

Asymmetric Encryption

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.

Beginner Examples

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 run a key agreement to derive a shared secret over an open link without ever sending 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.

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.

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.

Walkthrough: The Hybrid Onboarding and Verification Flow

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

Public-key checks create trust and keys; symmetric AEAD then carries the continuing data flow.

Public-Key Roles and Evidence

Public-Key Job

Common Mechanism

Provides

Review Evidence

Key agreement

DH and ECDH, ideally ephemeral (DHE or ECDHE).

A shared secret both peers derive without sending it; ephemeral use adds forward secrecy.

Fresh ephemeral keys per session, validated peer identity, and protocol-approved key derivation.

Public-key encryption or KEM

RSA with OAEP padding; ML-KEM for post-quantum.

Lets a sender protect a secret that only the private-key holder can recover.

Standardized padding (OAEP), a policy that rejects textbook RSA, and a named parameter set.

Digital signature

RSA-PSS, ECDSA, and EdDSA such as Ed25519.

Integrity, authenticity, and non-repudiation; only the private-key holder can sign.

Approved curve or padding, protected private key, and verification-failure (negative) tests.

Identity binding

X.509 certificate, raw public key, or pre-shared key.

Answers "whose public key is this?" by tying a key to a named identity.

Trust anchor, chain, name, validity, and purpose checks that fail closed on expiry or revocation.

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.

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.

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.

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.

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.

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.

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.

Select algorithms by role, ecosystem support, and evidence, not by name recognition.

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.

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.

Mechanisms and Failure Modes

Mechanism

What It Guarantees

Evidence to Request

Failure Mode If Weak

Ephemeral key agreement

Past sessions stay private even if long-term keys later leak.

Fresh ephemeral keys per session and a protocol-approved KDF.

Static exchange exposes all recorded past traffic after one key compromise.

RSA padding

Encryption and signatures are non-malleable and safe.

RSA-OAEP for encryption, RSA-PSS for signatures, and a policy rejecting textbook RSA.

Unpadded RSA is deterministic and malleable, breaking confidentiality or signatures.

Signature randomness

Each signature is sound and does not reveal the private key.

Approved curve, deterministic signing (RFC 6979) or a vetted RNG, and negative tests.

A reused or predictable ECDSA per-signature value leaks the private key.

Certificate validation

The verified public key really belongs to the expected identity.

Chain, name, validity, purpose, and revocation checks that fail closed.

Accepting any syntactically valid certificate enables impersonation.

Key custody and separation

One key means one authority, so a compromise stays contained.

Per-device keys, an off-device signing service, and a rotation and revocation plan.

A shared or exported private key turns one device into a fleet-wide impersonation path.

Common Pitfalls

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.
Using textbook RSA. Unpadded RSA is unsafe. Use RSA-OAEP for encryption and RSA-PSS for signatures.
Skipping forward secrecy. Static key exchange exposes all recorded past traffic once a long-term key leaks; prefer ephemeral ECDHE key agreement.
Parsing a certificate instead of validating it. A mathematically valid signature is not enough; check chain, name, validity, purpose, and revocation, and fail closed.
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.

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.2 Summary

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.
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).
Ephemeral key agreement (ECDHE or DHE) provides forward secrecy; static key exchange does not.
Signatures provide integrity, authenticity, and non-repudiation, because only the private-key holder can produce a valid one.
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.
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.
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.
NIST has standardized ML-KEM and ML-DSA as post-quantum options, and IoT migration to them is ongoing.

Key Takeaway

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.