Security

Security reviews often contain a sentence like this: “the data is encrypted with AES.”

That is not enough. AES is a block cipher. It defines how a key transforms one 16-byte block into another 16-byte block. Real messages are often longer than 16 bytes, may contain repeated fields, protocol headers, lengths, padding, and multiple packets.

So the practical question is not only “is it AES?” The real questions are:

• which mode is used
• where the IV or nonce comes from
• how non-16-byte-aligned lengths are handled
• whether ciphertext tampering is detected
• whether decryption errors leak information
• whether a counter or nonce can repeat under the same key

The most useful first model is: AES is the basic block transformation. The mode of operation turns it into an encryption scheme for real messages. The mode decides whether repeated blocks leak, whether padding is needed, what IV/nonce rules apply, whether authentication exists, and whether error handling becomes an attack surface.

Device security discussions often include: “The firmware is signed, so it is secure.”

That is only partly true. A firmware signature proves that the firmware was authorized by a trusted private key and was not modified. It does not automatically answer whether the firmware is encrypted, whether old versions can be rolled back, whether every boot stage verifies the next stage, how signing keys are protected, or whether the device can recover after update failure.

When devices connect to a cloud service, they often receive a .crt or .pem file and configure it in a TLS, MQTT, or HTTPS client.

That makes it easy to think a device certificate is just a file. In reality, the certificate is only the visible piece of a trust chain. The real design questions are: how does the device prove who it is, how does the server verify that identity, how is the private key generated and protected, and what happens when the certificate expires or the key leaks.

When a device connects to a server for the first time, they usually do not already share a session key. They need to agree on a symmetric key over an open network.

This is often compressed into: “Use ECDH to compute a key.”

That skips two important boundaries. ECDH/X25519 produces a shared secret, not the final key to feed into AES-GCM. And the whole path depends on randomness and context binding.

Device communication designs often say “encrypt it with AES”. That is too vague.

The real questions are: only encrypt, or also authenticate? Can tampering be detected? Is replay handled? Where does nonce come from? Can the device reuse nonce after power loss?

Modern protocols usually use AEAD instead of raw encryption.

AEAD = Authenticated Encryption with Associated Data
     = encryption + integrity authentication + optional authenticated cleartext context

Common AEAD algorithms include:

A dangerous sentence appears often in device security designs: “We use SHA-256, so it is secure.”

That is usually incomplete. SHA-256 is a hash function. It turns data into a fixed-size digest, but it does not know who computed it and cannot stop an attacker from modifying data and recomputing the digest.

Hashes, MACs, and signatures all output values that look like checksums, but they solve different problems:

Hash: did the data match this fingerprint, assuming the digest itself is trusted
MAC: was this generated by someone holding the same shared key
Signature: was this generated by a private-key holder, verifiable by public key

Mixing them up directly affects firmware verification, device authentication, message integrity, and audit logs.

The log says associated, but the device still cannot send application data. In Wi-Fi, the problem is usually that the security stage has not finished. scan -> authentication -> association only attaches the terminal to a BSS (Basic Service Set). What makes the data plane usable is the key-establishment and key-installation process that follows.

Wi-Fi security ties together password mode, handshake flow, management-frame protection, and compatibility.

The core of Wi-Fi security is establishing a verifiable link, installing keys, and enabling the data plane after basic access is complete.

Where It Sits in the Access Path

In the most common STA -> AP flow, the security stage comes after association and before the data plane:

IoT Cryptography: “Good Enough”

The goal is to use cryptography well enough to understand it and design with it. This article skips heavy mathematics and focuses on the concepts, parameters, and common mistakes that actually matter.

Core Concepts

• Confidentiality: prevent data from being read without permission
• Integrity: prevent data from being changed silently
• Identity: know who is talking to whom
• Symmetric keys: one key encrypts and decrypts, such as AES or ChaCha20-Poly1305
• Asymmetric keys: public/private key pairs, such as ECDSA, Ed25519, ECDH, or X25519
• AEAD: authenticated encryption with associated data, combining encryption and authentication in one step
• MAC: message authentication code, which authenticates but does not encrypt
• KDF: key derivation function, which turns raw secrets into usable keys
• Key formats: SPKI for public keys, PKCS8 for private keys, DER for binary encoding, PEM for text encoding

One Picture

[A private key + B public key] --(ECDH/X25519)--> [shared secret S]
[S] --(HKDF salt, info, L)--> [symmetric key K]
[message M, AAD] --(AEAD: K, nonce)--> [C || tag]
[M] --(HMAC/CMAC: K)--> [tag]
[M] --(signature: private key)--> [signature]

• AEAD always produces ciphertext plus tag, and the tag must be checked before decryption
• MACs and signatures do not encrypt data
• A shared secret is not a final key; it must go through a KDF first

Parameter Cheat Sheet

• Nonce / IV:
  • GCM: 12 bytes
  • ChaCha20-Poly1305: 12 bytes
  • CCM: commonly 13 bytes
  • CBC: 16 bytes
• Key sizes:
  • AES: 16 / 24 / 32 bytes
  • ChaCha20-Poly1305: 32 bytes
• Signature encodings:
  • ECDSA: DER or raw (r || s) form
  • Ed25519: raw form
• Key containers:
  • SPKI for public keys
  • PKCS8 for private keys

When to Use What

• Constrained devices or wireless protocols: AES-CCM for hardware acceleration, or ChaCha20-Poly1305 for software-friendly performance
• Web and general-purpose systems: AES-GCM or ChaCha20-Poly1305
• Integrity only: HMAC-SHA256 or AES-CMAC
• Firmware signing or long messages: Ed25519 or ECDSA P-256
• Session establishment: ECDH P-256 or X25519, then HKDF, then AEAD

Attack and Defense Notes

• Never reuse an AEAD nonce under the same key
• CBC does not authenticate data, so it must be paired with a MAC or replaced by AEAD
• Key exchange must be signed to prevent man-in-the-middle attacks

Quick Start

You can verify these operations quickly in the CryptoBox web page: