12 E1: Link-Layer Encryption

12.1 Protect One Local Hop, Then Name the Next Reader

Mark Every Place the Message Becomes Readable

Picture a locked radio message that is opened by a relay before reaching the cloud. A gateway means the device or service that joins systems and may read data when local protection ends.

Name the sender, local key, first receiver, plaintext handoff, next hop, and final reader. Test a valid frame, a changed frame, a wrong key, and a trusted relay that should not see the message.

Keep frame results, keys by role, handoff points, and trust decisions. This proves protection on one local hop, not end-to-end privacy; the deeper sections compare E1 with later layers and key-sharing risks.

E1 is encryption at the link or MAC layer: it protects a single wireless hop between two directly adjacent devices, such as a sensor and a nearby router, a peripheral and a central, or a device and a local gateway. When E1 is enabled, a frame on the air is encrypted and carries an integrity check, so a nearby attacker cannot casually read it and a tampered frame is rejected.

The most important thing to understand about E1 is that it is hop-by-hop, not end-to-end. The next node that receives the frame decrypts it, reads the contents, and then forwards the message onward, often re-protecting it on the next hop with a different key. That node, a router, border router, bridge, or gateway, sees the plaintext. This is expected behaviour, not a bug, but it means E1 by itself does not keep data private once it passes the first trusted receiver.

Think of a relay of couriers, each carrying a locked pouch one stretch of road. Each courier unlocks the pouch at the end of their leg, reads the note, then locks it in a fresh pouch for the next courier. The road is safe between stops, but every courier at a handover sees the message. E1 secures the stretches of road; it does not seal the note from the couriers who relay it. Locate that handover in Figure 12.1 before choosing any later protection layer.

Inspect Figure 12.1 from the transmitting device to the first node that terminates protection and becomes a plaintext reader.

Read Figure 12.1 from the originating device to the router and then the gateway. The first radio hop carries an encrypted, integrity-checked frame, but the router terminates that protection, obtains plaintext, and creates protection for the next hop. The diagram therefore proves only local-link confidentiality and integrity. Naming the first plaintext reader connects E1 to the chapter’s running decision: add E2 or E3/E4 whenever the intended trust boundary lies beyond that reader.

The One-Minute View

Beginner Examples

These examples show the limits of link encryption. A smart-home device on an encrypted local mesh is safe from a neighbour sniffing the air. The hub receiving its frames still reads every value before sending them to the cloud. "Link encryption is on" does not say who holds the key. If every sensor in a building shares one network key, one stolen sensor can expose the others' traffic. A captured valid command can be replayed unless the receiver checks a frame counter or packet number. The receiver must reject an old frame before acting on it.

Overview Knowledge Check

If you can explain that E1 protects a hop and that the terminating node reads the plaintext, you can stop here. Continue to Practitioner to review key scope, frame evidence, and when to add another layer.

12.2 Review the Hop, Key Scope, and Replay Proof

An E1 review should never stop at "encryption is enabled." The job is to map which nodes decrypt, name the key scope and the blast radius it creates, capture frame-level evidence, and prove that tampered and replayed frames are rejected. The most common finding is a shared network key that quietly turns one device's compromise into a group-wide exposure. Read Figure 12.2 in that order.

Walkthrough: Reviewing an E1 Link

Follow the sequence from decision to evidence. First, Map every hop and decryptor. List each local hop and each node, router, bridge, or gateway, that terminates link security and therefore reads plaintext. Next, Name the key scope. State whether the key is network-wide, group, pairwise, or session-scoped, and judge whether that scope matches the data's sensitivity. Next, Capture frame evidence. Record the visible header, the freshness field, the ciphertext, and the integrity tag, using key identifiers and fingerprints, never raw keys. Next, Run negative tests. Confirm that a tampered ciphertext, a tampered authenticated header, a wrong-key frame, and a replayed old frame are all rejected before any application action. Finally, Decide on upper layers. Where a gateway must not read the data, or the blast radius is too large, add E2 per-device keys, E3 object protection, E4 transport, or E5 renewal.

Before leaving the walkthrough, inspect Figure 12.2 to turn its review steps into the exact frame fields and receiver decision a capture must prove.

Read Figure 12.2 from the visible authenticated header into the freshness counter, ciphertext, integrity tag, and receiver decision. The header supplies routing context without being silently mutable; the counter proves freshness and supplies a unique nonce under the key; ciphertext hides the payload on that hop; and the tag binds the protected parts. The receiver must reject before application action if any check fails. This frame-level order turns the E1 review checklist into observable evidence.

Key Scope and Blast Radius

The central E1 design risk is rarely the cipher; it is key scope. The broader the scope, the more traffic one extracted key exposes. Match the scope to the sensitivity of the data and the resources of the device.

Worked Review: A Warehouse Sensor Mesh

A warehouse runs a low-power mesh of door, motion, and environmental sensors with E1 enabled, and a gateway forwards events to the cloud. The team says "the mesh is encrypted, so we are covered." The reviewer turns that into findings.

Practitioner Knowledge Check

If you can map decryptors, judge key scope, and prove replay rejection, you can stop here. Continue to Under the Hood for the frame mechanics, the counter-reset hazard, and what link authenticity does and does not prove.

12.3 Frame Counters Make the Hop Trustworthy

The deeper layer explains how a protected link frame is built, why a freshness counter is a correctness condition rather than a detail, and why E1 authenticity is weaker than application identity. Each is an independent guarantee, and the link cipher's strength cannot rescue a reset counter or an over-broad key.

How a Protected Link Frame Is Built

Modern link security is authenticated encryption: it pairs encryption of the payload with a message integrity check so a modified frame is rejected. Many IoT link layers use an AEAD construction such as AES-CCM for this. A protected frame typically has four parts: a visible header that must stay readable for routing but is authenticated as associated data so it cannot be changed silently; a freshness value such as a frame counter or packet number; the encrypted payload; and an integrity tag. The receiver recomputes the tag over the header and ciphertext and rejects the frame if it does not match, before passing anything to the application. Protocols including Bluetooth Low Energy, IEEE 802.15.4 meshes, Wi-Fi, and LoRaWAN each define their own profile of these parts.

Freshness, Counters, and the Power-Loss Hazard

That freshness field is what blocks replay, and it doubles as the per-frame nonce for the AEAD. The rule is the same as for any authenticated mode: a counter or nonce must never repeat under the same key. This is where a classic IoT failure appears. If a device loses power, restarts, and resumes counting from a low value while keeping the same link key, it reuses nonces, which can leak the relationship between payloads and undermine the integrity guarantee. Safe designs persist the counter across resets in non-volatile storage, or force a rekey on rejoin so a fresh key starts a fresh counter. A review should test exactly this: capture a baseline frame, confirm the counter advances, then power-cycle and confirm the device does not reuse old values.

Inspect Figure 12.3 to compare the group-wide consequence of one shared key with the narrower consequence of scoped relationships.

Read Figure 12.3 from the shared-key group on the left to the scoped relationships on the right. With one group key, extracting the weakest device exposes traffic and forgery authority across all six nodes; pairwise or narrowly scoped keys confine the same compromise to fewer links. Renewal shortens the remaining exposure in time. The comparison connects the power-loss nonce hazard to its consequence: reused state or an extracted broad key can undermine far more than one restarted device.

What Link Authenticity Does and Does Not Prove

E1 proves that a frame came from a device holding the link key, which is not the same as proving it came from a specific authorized application identity, especially when the key is shared across many nodes. If the receiver needs to know which device or which application sent a command, it needs per-device keys (E2) or an application-layer signature, not just a valid link tag. Two related hazards follow. A temporary join, install, or commissioning secret must not quietly become an indefinite fleet-wide credential; the design should show the transition from join material to scoped operational keys. And visible headers used for routing may still need authentication, because a receiver that trusts unauthenticated metadata can be steered by an attacker who rewrites it.

When E1 Is Enough, and When It Is Not

E1 is a sound local access-control layer: it raises the bar against nearby eavesdroppers and casual frame injection. It is sufficient on its own only for low-sensitivity data on a hop where every terminating node is trusted to read it and the key scope is acceptable. It is not enough when data must stay private past a gateway (add E3 object protection or E4 transport), when sender identity must be specific (add E2 per-device keys), or when a shared key's blast radius is too large (narrow the scope and add E5 renewal). The architecture decision is always layered against the trust boundaries, not a single switch.

Mechanisms and Failure Modes

Common Pitfalls

Follow the sequence from decision to evidence. First, Treating E1 as end-to-end. The terminating node reads plaintext; name every decryptor and add an upper layer where it must not read. Next, Counter reset after power loss. Reusing old freshness values under the same key breaks the link AEAD; persist the counter or rekey on rejoin. Next, Over-broad key scope. A shared network key spreads one compromise across the group; prefer pairwise or session keys for sensitive traffic. Next, Link key as application trust. A valid link tag proves key possession, not a specific sender; use E2 or application signatures when identity matters. Next, Commissioning key left in place. A join or install secret must transition to scoped operational keys, not become a permanent fleet credential. Finally, Unauthenticated metadata. Visible headers that influence the receiver's decision must be authenticated, not merely transmitted.

Under-the-Hood Knowledge Check

At this depth, E1 is a set of independent guarantees on one local hop: an authenticated frame, a freshness counter that never repeats per key, an authenticated header, a key whose scope bounds the blast radius, and a named map of every node that decrypts. Get those right and E1 is solid local access control, but reserve end-to-end privacy and specific sender identity for the upper layers built on top of it.