Cryptography · Study deck

Public-Key Cryptography for IoT

Picture a new device receiving an update from a server it has never contacted before.

Shield Shelly is your guide for this deck.

asymmetric-cryptographypublic-keykey-agreement
Shield Shelly verifies an update tile before inserting it into an IoT device.
iotclass.org

After studying this chapter

Learning objectives

Public-key jobs must be separated before a device can trust a peer or an update.

  • A public key can be shared while its private half stays protected.The gateway can hold the maker’s public key to verify a firmware signature without gaining the private authority needed to sign another release.
  • Key agreement and signing serve different security jobs.Peers derive a fresh shared secret for a session, while the release service uses its separate private signing key to approve a manifest.
  • Certificates connect public keys with identities the device must validate.A sensor meeting the cloud needs checks for the expected identity, trust chain, and validity rather than simply accepting a readable certificate.
  • The hybrid pattern uses symmetric protection after public-key setup.Certificate validation, ephemeral agreement, and key derivation establish the trusted session before symmetric AEAD protects continuing telemetry and commands.

I am checking an update arriving at a device from an unfamiliar server. I separate the key that verifies the release from the keys that establish and protect its communication channel.

iotclass.org

Major section

Start Simple

An update needs approval evidence even when its download succeeds.

  • The receiving device must connect the update with a trusted signer.The signed manifest, public-key identity, protected private key, version rule, and rejection path define the particular release-verification claim under test.
  • The private key creates signatures that its public half can verify.Keeping the maker’s signing key off the device lets the device check approval without giving every installed unit authority to issue releases.
  • Changed bytes, wrong signers, and old images test different rejection rules.An approved image is only the positive case; the update test also needs signature, identity, and version decisions when the supplied evidence changes.
  • Signature results and version decisions belong in the update record.Hashes, key identity, version, time, and final action make the tested verification path reviewable without claiming that it proves key storage or code quality.

I have a downloaded image but still need evidence that the approved sender signed it. I test changed bytes, a wrong signer, and an older valid image before recording the device’s final update action.

iotclass.org

Major section

Overview: One Key Pair, Several Different Jobs

This diagram follows public-key encryption from readable input to protected recovery.

  • Plaintext enters encryption with the recipient’s public key.The figure starts with readable input and the outward public-key operation, allowing a sender to protect a message for the private-key holder.
  • The middle ciphertext is the protected message on the untrusted path.The encrypted form separates the readable input from the recipient’s later recovery, illustrating confidentiality rather than approval by a firmware signer.
  • The paired private key can decrypt the ciphertext to recover plaintext.The figure ends with the protected private operation, showing why publishing the public half does not give everyone the ability to recover the message.
  • Signing uses the private key to create publicly verifiable evidence.A gateway verifies the maker’s release signature with the public half; encrypting a manifest for the gateway would not prove the sender’s approval.
Asymmetric encryption uses a public key for the outward operation and the corresponding private key for the protected operation.
Asymmetric encryption uses a public key for the outward operation and the corresponding private key for the protected operation.
iotclass.org

Major section

Practitioner: Onboard a Peer and Verify a Release

This workflow separates establishing a trusted channel from approving a firmware release.

  • Certificate validation connects the peer’s public key with an accepted identity.The workflow begins with a trusted chain or pinned key and checks the expected name, validity period, and allowed issuer before accepting the peer.
  • Ephemeral agreement and derivation provide scoped session keys.Fresh key shares provide the shared secret, while the protocol’s KDF binds traffic keys to direction, role, and session context.
  • Symmetric AEAD protects continuing telemetry and commands after setup.The expensive public-key work ends before the ongoing data path, allowing the sensor’s session to use cheaper authenticated encryption for its messages.
  • The firmware branch has a separate signing trust chain.The release manifest covers version, target device class, package hash, rollback policy, and signing identity before installation is allowed to proceed.
Public-key checks create trust and keys; symmetric AEAD then carries the continuing data flow.
Public-key checks create trust and keys; symmetric AEAD then carries the continuing data flow.
iotclass.org

Major section

Under the Hood: Mechanisms, Algorithm Fit, and Failure Modes

This matrix separates algorithm roles before considering their fit on a constrained device.

  • Key-establishment and signature mechanisms have different roles in the matrix.ECDH belongs to shared-secret establishment, while ECDSA and Ed25519 support signatures; an algorithm name alone cannot identify the device’s security claim.
  • Protocol and implementation support determine whether a candidate fits.The actual device, protocol, and accelerator need support evidence rather than a benchmark copied from another board or a familiar algorithm label.
  • Key sizes, signature sizes, storage, and timing affect practical fit.Smaller elliptic-curve keys can suit constrained RAM, flash, bandwidth, and energy budgets, but protected-key custody and target measurements remain part of the review.
  • Release tests must reject invalid evidence for the chosen role.Wrong names, wrong issuers, and bad signatures test different trust failures in the sensor-to-cloud and firmware-verification paths shown by the chapter.
Select algorithms by role, ecosystem support, and evidence, not by name recognition.
Select algorithms by role, ecosystem support, and evidence, not by name recognition.
iotclass.org

Activity 1 · Match

✎ Separate the key jobs

I want you to keep each key inside the boundary it is meant to protect.

Match five terms to five meanings on paper. Terms: public key; private signing key; certificate; ephemeral agreement; AEAD. Meanings: A protects continuing traffic; B creates release signatures; C binds identity to a key; D verifies a signature; E establishes a fresh session secret.

4 minutes · Pen and paper · Answer: Activity 1

Your answer
iotclass.org

Major section

Verify a Gateway Update With the Public Half

Public-key verification checks approval without giving the gateway authority to sign releases.

  • The release service uses its protected private key to sign the manifest.The gateway-update example keeps the signing authority at the release service even while an attacker controls the local Wi-Fi access point.
  • The gateway’s public key verifies the signature before installation.Possessing that key permits evidence checking but does not let the gateway create a valid release signature for a replacement image.
  • A completed download cannot compensate for failed signature verification.The update state must become rejected when verification fails, even if the network transfer finished successfully without reporting an error.
  • An unsigned replacement hash cannot authenticate an attacker’s changed image.Replacing both image and hash defeats a simple comparison, so the expected digest needs authenticated evidence such as a verified release signature.
Asymmetric encryption uses a public key for the outward operation and the corresponding private key for the protected operation.
Asymmetric encryption uses a public key for the outward operation and the corresponding private key for the protected operation.
iotclass.org

Major section

Summary

Separate keys and validation steps preserve separate security claims.

  • Ephemeral agreement protects past sessions against later long-term key compromise.Fresh single-use key shares provide forward secrecy, while the chapter distinguishes that property from static exchange and from firmware signing.
  • A key derivation function provides keys with defined session roles.The shared secret is input to the protocol key schedule, which binds resulting keys to direction, role, and session context.
  • Certificate validation checks trust beyond successful certificate parsing.Expected identity, chain, validity, and purpose checks are needed before the sensor can accept the cloud’s public key as the intended peer.
  • Firmware approval has a signing chain distinct from channel identity.The gateway may route the sensor’s traffic without receiving the authority to impersonate the cloud or approve firmware installation on the device.

I follow the temperature sensor through its gateway to the cloud. I keep peer identity, fresh session keys, traffic protection, and firmware approval separate so routing access does not become signing authority.

iotclass.org

Deck summary

Key takeaways

A trustworthy design names each key's job and tests its rejection path.

  • Public keys support verification without exposing private signing authority.The installed gateway can check the maker’s signature while the protected private key remains with the release service that approves firmware.
  • Session setup establishes trust before symmetric AEAD carries bulk traffic.Certificate validation, fresh agreement, and scoped derivation prepare the channel used for continuing telemetry and commands in the chapter’s hybrid workflow.
  • Device identity and firmware signing need separate ownership boundaries.A key reused across roles can expand one compromise, while distinct device and off-device signing keys keep the authorities separately reviewable.
  • Wrong identities, changed data, and invalid signatures must cause rejection.Negative tests keep an apparently successful TLS connection or completed download from substituting for the specific identity and release checks the device requires.

I am reviewing the gateway’s update result and the sensor’s trusted channel as separate claims. I keep each key’s owner, permitted job, and rejection tests in the record before accepting either path.

iotclass.org

Retrieval practice

Recall check 1 of 3

Shield Shelly says: answer from memory, then check your reasoning.

Q1A manufacturer publishes a public key so its devices can confirm that firmware really came from it. Which statement is correct?

AThe manufacturer signs each release with its private key, and devices verify the signature with the public key.
BDevices use the public key to decrypt the firmware, and a successful decryption proves it is genuine
CThe public key must be kept secret, or attackers could forge signatures
DBecause the key is public, anyone can sign a release that the devices will accept
Show answer

Answer: A A signature is made with the private key and checked with the public key.

iotclass.org

Retrieval practice

Recall check 2 of 3

Shield Shelly says: answer from memory, then check your reasoning.

Q2A device uses static, long-term key transport (no ephemeral keys) to set up every session. An attacker records months of encrypted traffic, then later steals the device's long-term private key. What is the correct review conclusion?

AThe recorded traffic is safe because it was encrypted at the time it was captured
BBecause the sessions used no ephemeral key agreement, there is no forward secrecy.
CForward secrecy is irrelevant here because the data was already delivered
DA longer RSA key would have prevented this
Show answer

Answer: B Without ephemeral key agreement, the long-term key protects the session secrets, so its later compromise exposes every recorded past session.

iotclass.org

Retrieval practice

Recall check 3 of 3

Shield Shelly says: answer from memory, then check your reasoning.

Q3A design encrypts a short secret with 'textbook' RSA (raw modular exponentiation, no padding) to save code size. Why is this unsafe rather than a harmless simplification?

AUnpadded RSA is deterministic and malleable
BIt is fine, because RSA's security comes only from the key size, not the padding
CTextbook RSA is safe as long as the message is short
DPadding only matters for signatures, not for encryption
Show answer

Answer: A The security of RSA encryption depends on proper padding, not just key size.

iotclass.org

Print reference

Answers

Answer key.

  1. A · A signature is made with the private key and checked with the public key.
  2. B · Without ephemeral key agreement, the long-term key protects the session secrets, so its later compromise exposes every recorded past session.
  3. A · The security of RSA encryption depends on proper padding, not just key size.
iotclass.org

Print reference

Activity 1 answer

Model answer.

Match: Public key → D; private signing key → B; certificate → C; ephemeral agreement → E; AEAD → A. The signing authority stays separate from the continuing traffic keys.

iotclass.org