Cryptography · Study deck

E1: Link-Layer Encryption

Picture a locked radio message that is opened by a relay before reaching the cloud.

Shield Shelly is your guide for this deck.

link-layer-encryptionhop-by-hopkey-scope

Shield Shelly, the module guide, in a scene from this chapter.

After studying this chapter

Learning objectives

You will be able to:

Explain: 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.
Explain: 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.
Explain: 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.

Major section

Protect One Local Hop, Then Name the Next Reader

A gateway means the device or service that joins systems and may read data when local protection ends.

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.

E1 protects each local hop, but the node that terminates it (here a router) decrypts and forwards the plaintext, so later boundaries need E2 or E3/E4.

Major section

Protect One Local Hop, Then Name the Next Reader (continued)

Scoped, pairwise, or session keys contain a compromise.

The most important thing to understand about E1 is that it is hop-by-hop, not end-to-end.
That node, a router, border router, bridge, or gateway, sees the plaintext.
Beginner Examples These examples show the limits of link encryption.

Major section

Protect One Local Hop, Then Name the Next Reader (continued)

The road is safe between stops, but every courier at a handover sees the message.

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.
If you only need the intuition, this layer is enough: E1 protects the local radio hop against nearby eavesdropping and frame tampering, but the node that terminates it reads the plaintext.
Key scope sets the blast radius A shared network key lets one extracted device expose the whole group.

Major section

Protect One Local Hop, Then Name the Next Reader (continued)

The One-Minute View Protects the local hop An encrypted, integrity-checked frame stops nearby eavesdropping and rejects tampered or injected frames on the radio link.

E1 is good local access control; it is not end-to-end privacy, it is not proof of a specific application identity, and a shared link key can spread one compromise widely.
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.
A smart-home device on an encrypted local mesh is safe from a neighbour sniffing the air.

Major section

Protect One Local Hop, Then Name the Next Reader (continued)

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 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.

Major section

Review the Hop, Key Scope, and Replay Proof

The most common finding is a shared network key that quietly turns one device's compromise into a group-wide exposure.

The receiver must reject before application action if any check fails.
Key Scope and Blast Radius The central E1 design risk is rarely the cipher; it is key scope.

A useful E1 trace names the protected frame parts, a visible-but-authenticated header, a freshness counter, hidden ciphertext, and an integrity tag, and shows the receiver's accept-or-reject decision.

Major section

Review the Hop, Key Scope, and Replay Proof (continued)

The team says "the mesh is encrypted, so we are covered." The reviewer turns that into findings.

A smaller set of nodes shares a key for a role or area.
Two peers share or derive a key for one direct relationship.
Keys change after pairing, rejoin, or another authenticated exchange.

Major section

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.

The rule is the same as for any authenticated mode: a counter or nonce must never repeat under the same key.

With a shared link key, one weak device can expose the whole key group; scoped or pairwise keys bound a compromise to one relationship, and renewal shrinks it further.

Major section

Frame Counters Make the Hop Trustworthy (continued)

Confidentiality-only link protection accepts modified frames silently.

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.
The architecture decision is always layered against the trust boundaries, not a single switch.
Visible routing metadata cannot be changed without detection.

Major section

Frame Counters Make the Hop Trustworthy (continued)

The hop is confidential and tampered frames are rejected.

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.
Old frames are rejected and nonces never repeat per key.
A reset counter reuses nonces and lets captured frames be replayed.

Major section

Frame Counters Make the Hop Trustworthy (continued)

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.
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.
An unauthenticated header lets an attacker reroute or relabel a frame.

Major section

Frame Counters Make the Hop Trustworthy (continued)

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.

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.
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.
Every plaintext reader on the path is known and intended.

Deck summary

Key takeaways

A gateway means the device or service that joins systems and may read data when local protection ends.

Scoped, pairwise, or session keys contain a compromise.
The road is safe between stops, but every courier at a handover sees the message.
The One-Minute View Protects the local hop An encrypted, integrity-checked frame stops nearby eavesdropping and rejects tampered or injected frames on the radio link.
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.

Retrieval practice

Recall check 1 of 3

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

Q1A sensor mesh has E1 link-layer encryption enabled and packet captures show encrypted frames, but the gateway logs decrypted temperature and occupancy values before forwarding them. What is the correct conclusion?

AE1 is working for the local hop, but

BE1 is broken, because no gateway should ever see plaintext

CNo further encryption is needed, because the captured frames are encrypted

DThe only remaining task is to increase the AES key length

Show answer

Answer: A E1 protects the air interface between adjacent nodes.

Retrieval practice

Recall check 2 of 3

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

Q2Across a building, every sensor shares one network-wide E1 key. A single sensor is physically extracted and its key recovered. What is the blast radius, and the right fix?

AThe recovered network key can decrypt and forge traffic for every node that shares it.

BOnly the extracted sensor is affected, because the attacker touched just one device

CIt is fine because the link still uses AES; the key value is not important

DAdding gateway-to-cloud TLS removes the exposure on the local mesh

Show answer

Answer: A A shared link key makes one extraction a group-wide exposure.

Retrieval practice

Recall check 3 of 3

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

Q3A constrained node keeps the same link key across reboots but resets its frame counter to a low value after every power loss. Why is this unsafe at the link layer?

AThe tag still detects changes, so resetting the counter should affect receiver ordering rather than cryptographic protection

BThe frame counter doubles as the per-frame nonce, so resetting it under the same key reuses nonces.

CThe only effect is slightly higher power use after each reboot

DSwitching to a larger link key removes the problem

Show answer

Answer: B Link AEAD requires a unique counter or nonce per key.

Print reference

Answers

Answer key.

A · E1 protects the air interface between adjacent nodes.
A · A shared link key makes one extraction a group-wide exposure.
B · Link AEAD requires a unique counter or nonce per key.