IoT Security: Cryptographic Foundations for Robust Device Protection

Editor’s Note: Securing the Internet of Things is essential for preserving the integrity of data streams, firmware, and the enterprise resources they connect to. IoT security is a multifaceted challenge that demands a systematic approach to identify threats and implement effective mitigations.

Adapted from Internet of Things for Architects by Perry Lea.

Chapter 12. IoT Security
By Perry Lea

Cryptography

Encryption and confidentiality are non‑negotiable for IoT deployments. They protect communication, firmware, and authentication processes. In practice, we work with three core cryptographic primitives:

• Symmetric key encryption – The same key encrypts and decrypts data. Common algorithms include RC5, DES, 3DES, and the industry‑standard AES.
• Public key encryption – A publicly shared key encrypts data, while only the holder of the corresponding private key can decrypt it. This asymmetric scheme also enables authentication and non‑repudiation. Widely used protocols such as Elliptic Curve Cryptography, PGP, RSA, TLS, and S/MIME rely on this model.
• Cryptographic hash – One‑way functions that map arbitrary data to a fixed‑size digest. MD5, SHA‑1, SHA‑2, and SHA‑3 fall into this category. Hashes underpin digital signatures, message authentication codes (MACs), and secure firmware validation. When hashing small inputs like passwords, a salt is appended to increase entropy; this is a form of key derivation function (KDF).

click for larger image

Elements of cryptography. Symmetric encryption requires identical keys for both encryption and decryption, while asymmetric encryption uses distinct public/private key pairs. Hash functions provide one‑way integrity checks.

Symmetric cryptography

In symmetric encryption, plaintext is the cleartext input and ciphertext is the encrypted output. The Advanced Encryption Standard (AES) is the global benchmark, superseding older DES algorithms. AES conforms to FIPS 197 and ISO/IEC 18033‑3, and operates on 128‑bit blocks with key sizes of 128, 192, or 256 bits. Longer keys provide stronger security at the cost of additional CPU cycles: 128‑bit keys require 10 rounds, 192‑bit keys 12 rounds, and 256‑bit keys 14 rounds.

// Pseudo‑code for an AES‑128 cipher
// Input: 128‑bit plaintext
// Output: 128‑bit ciphertext
// w: 44 32‑bit words (expanded key)
state = in
w = KeyExpansion(key) // Key expansion phase
AddRoundKey(state, w[0, Nb-1]) // Initial round
for round = 1 to Nr-1
    SubBytes(state)   // Non‑linear substitution
    ShiftRows(state)   // Row permutation
    MixColumns(state) // Column mixing
    AddRoundKey(state, w[round*Nb, (round+1)*Nb-1])
end for
SubBytes(state)   // Final round
ShiftRows(state)
AddRoundKey(state, w[Nr*Nb, (Nr+1)*Nb-1])
out = state

Scroll or drag the corner of the box to expand as needed. ↑

Block ciphers, such as AES, process data in fixed‑size blocks and rely on a block mode of operation to extend the algorithm to larger messages. An Initialization Vector (IV) ensures that identical plaintext blocks produce distinct ciphertexts, thwarting pattern analysis. Common modes include:

• Electronic Codebook (ECB) – The simplest mode; each block is encrypted independently. Identical blocks yield identical ciphertexts, making ECB unsuitable for most applications.
• Cipher Block Chaining (CBC) – Each plaintext block is XORed with the previous ciphertext block before encryption, providing diffusion.
• Cipher Feedback (CFB) – A stream‑like mode that feeds the previous cipher output into the next encryption step. CFB cannot be parallelized, but it allows recovery from lost blocks.
• Output Feedback (OFB) – Similar to CFB but generates a keystream that is XORed with plaintext, enabling error‑correction codes.
• Counter (CTR) – Transforms a block cipher into a stream cipher using a nonce‑counter pair, enabling parallel encryption and fast performance.
• CBC‑MAC – Adds a message authentication code to CBC, enabling integrity verification and source authentication.

These modes originated in the late 1970s and were formalized by NIST in FIPS 81. While they secure confidentiality, they do not prevent tampering. Combining authentication with encryption led to authenticated‑encryption modes such as AES‑CCM (Counter with CBC‑MAC). CCM is integral to protocols like Zigbee, Bluetooth Low Energy, TLS 1.2 (post‑key‑exchange), IPsec, and Wi‑Fi WPA2.

AES‑CCM blends CTR for efficient decryption of the ciphertext stream and CBC for generating an authentication tag. The tag is compared against an expected value derived from the decrypted payload; a mismatch indicates potential tampering.

click for larger image

AES‑CCM mode.

In a fully connected mesh of n nodes, bidirectional communication requires n(n-1)/2 unique keys, scaling quadratically (O(n²)). Efficient key management strategies are therefore critical for large IoT deployments.