Cryptography and Key Management

Introduction

IoT systems connect sensors, actuators, gateways, mobile applications, cloud platforms and operational technologies. These devices often collect sensitive information, control physical processes, or provide access to safety-critical environments. Their security therefore depends not only on network firewalls and passwords but also on cryptographic mechanisms that protect information and establish trust.

Cryptography provides confidentiality, integrity, authentication and non-repudiation. Key management makes these properties usable throughout the life cycle of an IoT device: manufacturing, commissioning, operation, maintenance, replacement and retirement. In practice, a strong algorithm can still provide weak security if keys are predictable, poorly stored, reused excessively or never revoked.

IoT environments impose special constraints. Many devices have limited memory, processing power, battery capacity and bandwidth. Some operate intermittently or without continuous Internet connectivity. A practical design must therefore balance security strength, computational cost, message size, interoperability, maintainability and long-term resilience.

Learning Objectives

After studying this chapter, the learner should be able to:

1. Explain confidentiality, integrity, authentication and non-repudiation in IoT systems.
2. Distinguish encryption, hashing, message authentication codes and digital signatures.
3. Select suitable symmetric and asymmetric cryptographic methods for constrained devices.
4. Explain random-number generation, entropy and nonce requirements.
5. Describe certificates, certificate authorities and public-key infrastructure.
6. Design a practical key-management life cycle for IoT devices.
7. Identify common implementation failures and evaluate security trade-offs.
8. Apply these ideas to an IoT deployment scenario.

1. Security Services and Threat Model

A security design begins by identifying assets, adversaries and required security services.

Confidentiality prevents unauthorized parties from learning message content. For example, encryption can protect occupancy data transmitted from a smart-building sensor.

Integrity assures that data has not been altered. A temperature reading modified from 20 °C to 80 °C could trigger an unsafe response even if the reading is not confidential.

Authentication establishes the identity or legitimacy of a communicating party. A gateway should be able to determine whether a command originated from an authorized controller.

Authorization determines what an authenticated entity is allowed to do. Authentication alone does not mean that a device may update firmware or operate an actuator.

Non-repudiation provides evidence that a particular key holder generated a message or signature. In IoT, digital signatures are commonly used for firmware authenticity rather than for every telemetry message.

Typical adversaries include:

• A passive eavesdropper observing wireless traffic.
• An active attacker modifying, replaying or injecting messages.
• A compromised gateway impersonating devices.
• A malicious insider with access to provisioning systems.
• An attacker with temporary or permanent physical access to a device.
• A supply-chain attacker who inserts unauthorized firmware or keys.

A useful threat-model distinction is between a software-only attacker and a physical attacker. Encryption may protect traffic against the former, but a device exposed in a public location may require secure boot, tamper resistance, protected key storage and anti-rollback controls as well.

2. Cryptographic Building Blocks

2.1 Symmetric encryption

Symmetric encryption uses the same secret key, or closely related secret keys, for encryption and decryption. Modern authenticated encryption algorithms are preferred because they provide confidentiality and integrity together.

Authenticated encryption with associated data (AEAD) accepts plaintext, a secret key, a nonce and optional associated data. The associated data is authenticated but not encrypted; it may contain a protocol version, device identifier or message type.

Conceptually:

Here, K is the secret key, N is a nonce, P is plaintext, A is associated data, C is ciphertext and T is the authentication tag. Decryption succeeds only when the tag is valid.

AES-GCM and ChaCha20-Poly1305 are widely used AEAD choices. AES-GCM can be efficient when hardware acceleration is available. ChaCha20-Poly1305 is often attractive on processors without efficient AES instructions. AES-CCM is also used in constrained and wireless protocols, including some 802.15.4-based systems.

The nonce is not normally secret, but its uniqueness is critical. Reusing a nonce with the same key in GCM can reveal relationships between plaintexts and may seriously compromise authentication. A robust design uses a counter, a carefully managed unique sequence number, or a protocol mechanism that guarantees uniqueness.

2.2 Block-cipher modes and legacy choices

Electronic Codebook mode should not be used for ordinary structured data because identical plaintext blocks produce identical ciphertext blocks. CBC mode requires padding and separate integrity protection; encryption alone does not prevent modification. CTR mode provides confidentiality but no integrity. These examples illustrate a central rule: confidentiality without authentication is insufficient for IoT commands.

Legacy algorithms such as DES, 3DES and RC4 should not be selected for new systems. Small key sizes and known weaknesses make them unsuitable for contemporary deployments.

2.3 Hash functions

A cryptographic hash maps input data of arbitrary length to a fixed-length digest. A secure hash should make it computationally difficult to find a preimage, a second preimage or two different inputs with the same digest.

In this expression, M is the message, H is the hash function and h is the digest. Hashing is not encryption: a hash is not intended to be reversed using a key.

SHA-256 and SHA-3 are general-purpose modern choices. SHA-1 and MD5 must not be used for collision-sensitive security purposes. A hash can detect accidental changes when the original digest is trusted, but an attacker who can replace both the message and digest can defeat this use. For adversarial integrity, use a MAC or digital signature.

2.4 Message authentication codes

A message authentication code (MAC) uses a shared secret key to provide integrity and authentication to parties that possess that key.

T is the tag, K is the shared key and M is the message. HMAC-SHA-256 is a common general-purpose construction. AEAD modes already include an authentication tag and are usually preferable when confidentiality is also required.

A limitation of a shared MAC is attribution. If two parties share the same key, either party could have generated a valid tag. A MAC therefore does not normally provide non-repudiation.

2.5 Digital signatures

A digital signature uses a private key to sign data and a corresponding public key to verify it. The private key must remain secret; the public key may be distributed.

Signatures are useful for firmware updates, certificates, configuration authorization and offline verification. They are generally more computationally and communication intensive than symmetric authentication, so a constrained device may verify signatures during boot or update installation but use AEAD for frequent telemetry.

Ed25519 provides compact signatures and efficient operations in many software environments. ECDSA is widely deployed, especially where standards or hardware support require it. ECDSA requires careful generation of a unique secret signing nonce; failure can expose the private key. RSA signatures remain important for interoperability but generally require larger keys, larger signatures and more computation than elliptic-curve alternatives.

3. Selecting Algorithms for Constrained IoT Devices

Algorithm selection should consider the complete system rather than isolated benchmark speed. Relevant criteria include:

A typical pattern is:

• AEAD, such as AES-GCM, AES-CCM or ChaCha20-Poly1305, for routine data protection.
• SHA-256 or SHA-3 for hashing and integrity-related processing.
• HMAC when shared-key authentication is sufficient.
• Elliptic-curve signatures or key agreement for bootstrapping, firmware and session establishment.
• Hardware-backed secure storage for long-term device keys.

Security strength should not be confused with key length alone. The security of a system is limited by its weakest component, including random-number generation, protocol design, implementation quality and key protection.

4. Randomness, Nonces and Initialization Values

Cryptographic security depends heavily on unpredictable or unique values. A random number generator (RNG) produces values intended for general purposes, while a cryptographically secure pseudorandom number generator (CSPRNG) produces values that remain unpredictable to an attacker who does not know its internal state.

A CSPRNG normally uses an entropy source to initialize or reseed an internal state. Entropy may come from a hardware noise source, oscillator variation, a trusted security peripheral or another approved source. A timer value, device serial number or sensor reading is not automatically sufficient entropy.

Important distinctions are:

• A secret key must be unpredictable.
• A nonce may be public, but often must be unique for a particular key.
• A salt is usually public and prevents precomputed attacks, especially in password-derived keys.
• A challenge should be fresh enough to prevent replay.

If a device boots before it has reliable entropy, it must not generate long-term keys from predictable startup values. Manufacturing can provision an initial key, or the device can obtain protected entropy from a trusted hardware source or secure commissioning process.

For a counter-based nonce of n bits, a system that allows at most q distinct invocations under one key must ensure that no counter value repeats. Random nonces require a collision analysis and are unsafe if the probability of repetition becomes significant. Counter management must also survive reboot; storing a counter securely or deriving it from a monotonic hardware state may be necessary.

5. Public-Key Cryptography and Key Agreement

Public-key cryptography solves the distribution problem more effectively than giving every device one universal secret. A device can possess a private key while publishing a certificate containing its public key.

In elliptic-curve Diffie–Hellman (ECDH), two parties combine their private keys and the other party’s public key to derive a shared secret. The shared secret should normally be passed through a key-derivation function rather than used directly as an encryption key.

Here, Z is the shared secret, salt is optional salt or protocol randomness, context identifies the purpose and participants, and K_session is the derived session key. The KDF prevents accidental key reuse across protocols or directions.

ECDH by itself does not authenticate the parties. An attacker can conduct a man-in-the-middle attack unless public keys are authenticated through certificates, pre-shared trust anchors, authenticated provisioning or another trusted mechanism.

Session keys should be separate for different directions and purposes where practical. For example, a device-to-gateway key should not also be used for firmware signing or administrative commands.

6. Certificates and Public-Key Infrastructure

A digital certificate binds an identity or device attribute to a public key. A certificate typically contains a subject, public key, issuer, validity period, serial number, permitted uses and a signature from a certificate authority (CA).

A public-key infrastructure (PKI) is the collection of authorities, policies, certificates, repositories and procedures used to create and manage that trust. A common hierarchy is:

1. A root CA is protected as a high-value trust anchor.
2. One or more intermediate CAs issue operational certificates.
3. Device certificates identify individual devices or device groups.
4. Gateways and services validate certificate chains and usage constraints.

Certificate validation should include signature verification, chain building, validity dates, key-usage restrictions, name or device-identity checks and revocation status where applicable. A certificate that is mathematically valid may still be unacceptable if it is expired, revoked or issued for a different purpose.

For constrained networks, full certificate chains may be expensive to transmit. Devices can store a root trust anchor, use compact certificate profiles, cache intermediate certificates or perform certificate validation at a gateway. Such optimizations must not silently remove authentication.

Revocation is particularly difficult for intermittently connected devices. Options include certificate revocation lists, online status protocols, short-lived certificates, gateway-enforced deny lists and device-specific key rotation. The choice depends on connectivity, risk and operational capability.

7. Key-Management Life Cycle

Key management covers generation, registration, distribution, storage, use, rotation, backup, recovery, revocation and destruction. A useful life-cycle model is:

Provisioning: Each device receives a unique identity and initial key material through a protected manufacturing or commissioning process. Avoid universal factory keys.

Activation: The device proves possession of its private key or secret and is associated with an authorized owner, site or tenant.

Operational use: Short-lived session keys protect routine communications. Long-term keys authenticate the device or establish sessions but are used as infrequently as possible.

Rotation: Keys or certificates are replaced before compromise or cryptographic exhaustion becomes likely. Rotation procedures must handle missed connections and partial failure.

Compromise response: A suspected device must be isolated, credentials revoked and replacement credentials issued. Incident records should identify affected devices and data.

Decommissioning: Keys are securely erased, certificates invalidated and the device removed from authorization lists. Physical destruction may be needed for high-value secrets.

A device identity key should be unique per device. If all devices share one key, compromise of one device can expose the entire fleet. Group keys simplify multicast but increase the consequences of compromise and complicate revocation.

Keys should be separated by purpose. Examples include a device identity key, a firmware-verification key, a transport-session key and a local data-encryption key. Key derivation can create subordinate keys, but the derivation context must clearly distinguish purposes.

Secure storage

Software-only storage may be adequate for low-risk devices, but higher-risk devices should use a secure element, trusted execution environment or microcontroller security features. Protection should address extraction, unauthorized use, debug-port access, backup copies and firmware attempts to read the key.

A secure element can perform signing or key agreement without exposing the private key to application memory. However, it introduces cost, supply-chain dependencies and integration requirements. It is not a substitute for correct protocol design.

Key destruction and backup

Key destruction must be realistic. Overwriting ordinary flash memory may not be reliable because of wear leveling, remapping or backups. A device can instead destroy a key-encryption key, render encrypted data unrecoverable and use hardware erase functions where available.

Backups of fleet keys require strict access control, encryption and audit logging. Backing up every device private key may improve recovery but increases the impact of a central compromise. In many designs, device keys are non-exportable and replacement devices receive new identities.

8. Secure Protocol Design

Cryptographic algorithms must be used within a protocol that addresses freshness, identity, authorization and failure handling.

A secure message often contains a version, sender identity, sequence number, message type, ciphertext and authentication tag. The sequence number or challenge helps prevent replay. The receiver should reject invalid tags before acting on the plaintext and should fail closed when authentication fails.

Associated data is useful for protecting fields that must remain visible. For example, a gateway may route a message using the device identifier while AEAD authenticates that identifier together with the encrypted payload.

Designers should avoid inventing proprietary cryptographic protocols. Standardized protocols such as TLS, DTLS, OSCORE or a well-reviewed application security profile provide established approaches to negotiation, authentication and key derivation. The selected protocol must still be configured appropriately; obsolete versions, weak cipher suites and unauthenticated fallback options should be disabled.

Firmware updates require a chain of trust. A bootloader verifies a vendor signature, checks the firmware version against an anti-rollback policy and starts the image only if validation succeeds. The update package may be encrypted for confidentiality, but encryption does not replace signature verification.

9. Worked Example: Protected Telemetry

Assume a sensor sends a temperature value to a gateway every minute. During commissioning, the device and gateway establish a session key K_s. Each message uses a monotonically increasing 64-bit sequence number i. The protocol constructs a nonce from a fixed session identifier and i, ensuring that no nonce repeats under K_s.

The visible associated data is:

A = (device ext{-}ID, message ext{-}type, i)

The plaintext is the encoded temperature and timestamp:

P = (temperature, timestamp)

The device computes:

The gateway accepts the message only if the tag verifies and i is fresh according to its replay window. If an attacker changes the temperature, device identifier or sequence number, tag verification fails. If the attacker replays an old valid packet, the freshness check rejects it.

This example demonstrates that encryption alone is not enough. Confidentiality comes from ciphertext; integrity and authenticity come from the tag; replay resistance comes from sequence-number management; and trust in the session key comes from authenticated commissioning.

10. Illustrative Case: Smart Irrigation Network

Background

A municipal irrigation system uses battery-powered soil-moisture sensors, solar-powered valve controllers and cellular gateways. Sensors report readings, while valve controllers accept commands to open or close water valves.

Problem

The initial design uses one shared AES key for all sensors. Messages are encrypted but have no authentication tag, and sequence numbers are not checked. A field technician discovers that captured packets can be replayed to open valves repeatedly. Replacing the shared key would require visiting every device.

Analysis

The shared key creates a fleet-wide failure: compromise of one sensor exposes every sensor and controller. Encryption without integrity permits message modification. Lack of freshness permits replay. The absence of a scalable provisioning and revocation process makes incident response impractical.

Approach and solution

The redesigned system gives every device a unique identity key stored in a secure element. During commissioning, the device certificate is validated by the gateway PKI. An authenticated key exchange establishes separate session keys for telemetry and control. AEAD protects every message, with the device identity, command type and sequence number included as associated data. Valve commands require authorization in addition to authentication: a soil sensor cannot issue a valve-control command.

Firmware images are signed by the irrigation authority. Gateways verify certificates and maintain a revocation list for stolen or compromised devices. Controllers store a monotonic message counter so that reboot does not cause nonce reuse or replay acceptance. Devices that cannot contact the service for a prolonged period receive short-lived credentials with a controlled renewal process.

Outcome

A compromised sensor no longer reveals the keys of other devices. Modified and replayed commands are rejected, and the authority can revoke a device without replacing the entire fleet key. The system incurs additional provisioning and certificate-management costs, but these costs are justified by the physical consequences of unauthorized valve operation.

Learning points

1. Fleet-wide shared secrets create a large blast radius.
2. AEAD should replace unauthenticated encryption for commands.
3. Replay protection requires maintained freshness state.
4. Authentication and authorization are different controls.
5. Key management must be designed before mass deployment.

11. Common Failures and Limitations

Hard-coded keys: Keys embedded in firmware are often extracted through reverse engineering and are difficult to rotate.

Predictable randomness: Time-based or serial-number-based key generation can make supposedly secret keys guessable.

Nonce reuse: Reusing a nonce with the same AEAD key can cause catastrophic failure, especially in GCM.

Unverified certificates: Accepting any certificate, or disabling hostname and identity checks, defeats PKI.

Excessive cryptography: Encrypting every field with expensive public-key operations may drain batteries without improving the threat model.

No recovery path: A device that cannot renew credentials or receive security updates becomes a permanent liability.

Debug exposure: Unlocked test interfaces may permit extraction of keys or firmware even when the cryptographic protocol is sound.

Poor error handling: Revealing whether a certificate, tag or identity failed can create information leaks; accepting unauthenticated fallback is worse.

Cryptography also has limits. It cannot correct insecure authorization, compromised endpoints, malicious firmware, stolen administrator credentials or unsafe physical procedures. It must operate as part of defense in depth.

12. Governance, Ethics and Contemporary Practice

IoT operators should document cryptographic choices, key ownership, retention periods, incident responsibilities and decommissioning procedures. Privacy regulations may require protection of personal data, data minimization and breach notification. Device identity data and telemetry should not be retained indefinitely without a legitimate purpose.

Security updates should be supported for a defined period, and manufacturers should provide vulnerability-reporting channels. Supply-chain assurance includes verifying component provenance, build processes, firmware signatures and cryptographic libraries.

Post-quantum cryptography is an emerging consideration because sufficiently capable quantum computers could threaten widely used public-key systems. Symmetric algorithms are generally affected differently from RSA and elliptic-curve systems, but IoT designers should support algorithm agility and avoid protocols that make future migration impossible. Because constrained devices may remain deployed for many years, long-lived confidentiality and update mechanisms deserve particular attention.

Artificial intelligence can assist anomaly detection, certificate inventory and fleet risk analysis, but it should not be trusted as a replacement for cryptographic verification. A machine-learning model may identify unusual traffic; only authenticated protocol checks should authorize a valve command or firmware installation.

Best-Practice Checklist

• Use modern, standardized AEAD rather than unauthenticated encryption.
• Use unique, correctly managed nonces for every key.
• Generate keys with a CSPRNG or approved hardware entropy source.
• Give each device a unique identity and avoid universal factory secrets.
• Separate keys by purpose and derive session keys with explicit context.
• Authenticate public keys through certificates or another trusted mechanism.
• Protect private keys with secure hardware when the threat model justifies it.
• Include replay protection and authorization in command protocols.
• Sign firmware and enforce anti-rollback controls.
• Plan certificate renewal, revocation, recovery and decommissioning before deployment.
• Keep cryptographic libraries and protocol implementations updated.
• Test failure cases, reboot behavior, counter persistence and loss of connectivity.

Chapter Summary

Cryptography provides the mechanisms through which IoT systems protect confidentiality, integrity, authentication and, in suitable cases, non-repudiation. Symmetric AEAD is generally efficient for routine device communication, while hashes, MACs and digital signatures serve different integrity and trust requirements. Public-key cryptography supports scalable identity and key agreement, but it must be authenticated through certificates, provisioning trust or PKI.

Secure randomness, nonce uniqueness and protected key storage are foundational requirements. Key management extends beyond generation: it includes provisioning, use, rotation, revocation, recovery and destruction across the entire device life cycle. Resource constraints require careful selection of algorithms and protocol roles, not the removal of essential security properties. Finally, cryptography cannot compensate for weak authorization, insecure firmware, poor physical protection or absent operational governance.

Key Terms

Cryptography: The practice of protecting information using mathematical techniques.

Confidentiality: Prevention of unauthorized disclosure of information.

Integrity: Assurance that information has not been altered improperly.

Authentication: Verification of an identity or message origin.

Authorization: Determination of permitted actions after authentication.

AEAD: Authenticated encryption with associated data.

Nonce: A value intended to be used once, often required to be unique under a key.

Hash function: A function that maps arbitrary input to a fixed-length digest.

MAC: A keyed tag providing message integrity and authentication.

Digital signature: A private-key-generated value verified with a public key.

CSPRNG: A cryptographically secure pseudorandom number generator.

Entropy: Unpredictability available to a random-generation process.

Certificate: A signed binding between an identity or attribute and a public key.

Certificate authority: An entity that issues and signs certificates.

PKI: The infrastructure and policies used to manage public-key trust.

Session key: A temporary key used for a communication session.

Key rotation: Replacement of a key according to a planned or emergency process.

Secure element: Hardware designed to protect keys and perform sensitive operations.

Replay attack: Reuse of a previously valid message to produce an unauthorized effect.

Secure boot: A process that permits execution only of authenticated software.

Review Questions

Short Answer Questions

1. What is the difference between encryption and hashing?
2. Why is nonce uniqueness important in AEAD?
3. What role does a certificate authority play in PKI?
4. Distinguish authentication from authorization.
5. Name three stages in the key-management life cycle.

Long Answer Questions

1. Explain why AEAD is generally preferable to encryption without integrity protection in IoT systems.
2. Compare symmetric keys, MACs and digital signatures in terms of key distribution and attribution.
3. Describe how a constrained IoT device can use certificates without transmitting a complete certificate chain for every message.
4. Explain the security risks of using one shared key across an entire IoT fleet.
5. Discuss the design requirements for secure firmware updates.

Analytical / Application Questions

1. A battery-powered controller reuses its counter after every reboot while using the same AEAD key. Analyze the risks and propose two corrective designs.
2. Design a trust and key-management architecture for 10,000 environmental sensors managed through regional gateways. Justify your choices for identity, session keys, revocation and firmware signing.
3. A captured command is authentic but five hours old. Explain how a correctly designed protocol should decide whether to accept it, and identify the state needed to make that decision.

Multiple Choice Questions with Answers

Question 1

Which mechanism provides confidentiality and integrity together for an IoT message?

A. Plain SHA-256 hashing

B. Authenticated encryption with associated data

C. A device identifier

D. A certificate serial number

Correct Answer: B. Authenticated encryption with associated data

Question 2

What is the primary security danger of reusing a nonce with the same AES-GCM key?

A. The device identity becomes public by design

B. The certificate expires immediately

C. Confidentiality and authentication may be seriously compromised

D. The message becomes larger

Correct Answer: C. Confidentiality and authentication may be seriously compromised

Question 3

Which statement correctly describes a cryptographic hash?

A. It is designed to be decrypted with a public key

B. It maps arbitrary input to a fixed-length digest

C. It always provides sender authentication by itself

D. It must remain secret to be useful

Correct Answer: B. It maps arbitrary input to a fixed-length digest

Question 4

What is the main purpose of a certificate in PKI?

A. To bind an identity or attribute to a public key

B. To replace all symmetric encryption

C. To store a device’s sensor readings

D. To generate physical entropy

Correct Answer: A. To bind an identity or attribute to a public key

Question 5

Why is a CSPRNG needed when generating long-term IoT keys?

A. It compresses certificates

B. It makes keys unpredictable to attackers

C. It eliminates the need for key rotation

D. It guarantees that authorization is correct

Correct Answer: B. It makes keys unpredictable to attackers

Question 6

Which property distinguishes a digital signature from a shared-key MAC?

A. A signature uses a private key for signing and a public key for verification

B. A signature cannot provide integrity

C. A MAC always requires a certificate authority

D. A MAC is never suitable for IoT communication

Correct Answer: A. A signature uses a private key for signing and a public key for verification

Question 7

Which practice best limits the impact of one compromised IoT device?

A. Use one universal factory key

B. Give every device a unique identity key

C. Disable certificate validation

D. Reuse the firmware-signing key for telemetry

Correct Answer: B. Give every device a unique identity key

Question 8

What does authorization determine?

A. Whether a message was compressed

B. Which actions an authenticated entity is allowed to perform

C. Whether a hash has fixed length

D. Whether a nonce is public

Correct Answer: B. Which actions an authenticated entity is allowed to perform

Question 9

Why should an ECDH shared secret normally be passed through a KDF?

A. To derive context-specific session keys safely

B. To make the public key secret

C. To eliminate the need for authentication

D. To convert ciphertext into plaintext

Correct Answer: A. To derive context-specific session keys safely

Question 10

Which control is most directly intended to prevent installation of unauthorized firmware?

A. A firmware digital signature verified by the bootloader

B. A larger telemetry packet

C. A publicly readable device serial number

D. A non-secret timestamp alone

Correct Answer: A. A firmware digital signature verified by the bootloader