11 The Layered Encryption Model

11.1 Start by Asking Who May Read the Plaintext

This section: Start by Asking Who May Read the Plaintext — Picture a health sensor sending a private reading through a home bridge to a care service.

Trace One Secret Through Every Reader

Picture a health sensor sending a private reading through a home bridge to a care service. A locked radio link helps, but the reading may become plain text again at each stop. The design must name every reader and every point where protection ends.

Trace the private health reading through every place that may reveal it.

Read the four panels from the sensor to the home bridge and then to the care service. The first panel starts with a private reading. The next warns that the reading can become plain text whenever protection ends. The third asks the design to name each allowed reader instead of assuming every middle box is safe. The last panel adds a test: reject changed or stale versions while local safe action still works. The story turns encryption from a lock icon into a map of readers, refusal checks, and service needs.

A payload means the useful data inside one message. A gateway means the bridge between local devices and a wider network. A message broker means a service that passes messages between senders and receivers. Transport layer security means protection for a network stream; it is called TLS. Datagram Transport Layer Security (DTLS) protects separate network messages.

Draw the path, then copy the payload, change it, use an old identity, restart the broker, and remove the outside link. Record who can read each version and which check refuses the bad one. Urgent safe action must still work locally.

This runway does not prove a cipher, device, or service secure. The deeper sections compare link, transport, message, and application protection and show where keys, plain text, and release evidence belong.

An IoT message often travels through several hands on its way from a sensor to the cloud: a radio link, a local gateway, a message broker or queue, and finally an application. Encryption architecture is the discipline of deciding, for each of those hops, which component is actually allowed to read the data in the clear. That single question, plaintext ownership, drives every other choice.

The E1-E5 model is a simple map for answering it. E1 protects the local link hop. E2 protects a device-to-gateway message when the gateway is trusted to decrypt and act on it. E3 keeps a payload opaque all the way to the cloud or application, so gateways and brokers only forward ciphertext. E4 protects an authenticated transport session such as gateway-to-cloud TLS or DTLS. E5 keeps the keys behind all of this provisioned, rotated, revoked, and recoverable. The goal is not "more encryption everywhere"; it is encryption matched to trust boundaries.

Think of sending a confidential letter through several couriers. Sealing the envelope so the final recipient alone can open it is end-to-end protection: every courier carries it but none can read it. Handing an open letter to a trusted assistant who reads it, acts on it, then forwards it is a different model: useful when you trust the assistant, but the assistant has seen everything. Encryption architecture is choosing, deliberately, which couriers are sealed out and which are trusted readers.

Inspect Figure 11.1 to place those readers in the E1-E5 model and identify where plaintext appears.

+

Read Figure 11.1 from E1 local-link protection through E2 trusted-gateway protection, E3 opaque device-to-cloud payloads, and E4 authenticated transport sessions; then treat E5 as the key lifecycle beneath every path. At each termination point, ask who receives plaintext and which keys make that possible. The levels are not a strength ranking: each covers a distinct boundary. That guided route connects the opening plaintext-owner question to the chapter’s later selection workflow.

The One-Minute View

Beginner Examples

These examples connect protection levels to what each part of the system can read. A local radio link with a join-controlled key (E1) keeps nearby strangers from reading or joining. Every joined node on a shared key can still read the hop. A gateway running local automation needs sensor values, so device-to-gateway protection (E2) lets it decrypt. A third-party gateway that should only route gets object protection (E3) instead. "We use TLS to the cloud" (E4) protects the internet leg. It says nothing about whether the gateway already saw the data or whether old keys can ever be retired (E5).

Overview Knowledge Check

If you can explain plaintext ownership and the five levels at a glance, you can stop here. Continue to Practitioner to run the selection workflow and choose between E2 and E3.

11.2 Map the Path and Name the Plaintext Owners

This section: Map the Path and Name the Plaintext Owners — The practical job is to turn a stack diagram into a set of boundary decisions, each with evidence.

The practical job is to turn a stack diagram into a set of boundary decisions, each with evidence. You walk the path, name who may decrypt at each step, choose the level that enforces that, then prove the wrong party is rejected. The most common confusion is between E2 and E3, because both protect application payloads; the difference is where decryption is allowed to happen. Read Figure 11.2 in that order.

Walkthrough: The Selection Workflow

1. Map every hop. List the device, local link, gateway, broker or queue, cloud API, storage, update, and recovery paths the data and commands actually take.
2. Name the plaintext owner. For each hop, state which systems may decrypt and which must only forward ciphertext.
3. Choose the level. Apply E1 link security, E2 device-to-gateway protection, E3 object or device-to-cloud protection, or E4 transport, to match each boundary.
4. Plan the lifecycle. Define E5 provisioning, rotation, revocation, ownership transfer, decommission, and recovery for the keys every level depends on.
5. Run negative tests. Prove rejection for the wrong identity, a replay, a modified payload, an expired credential, a revoked key, and a rollback attempt.

Inspect Figure 11.2 to see how plaintext ownership and the selected boundary lead to a matching release test rather than a larger layer count.

+

Read Figure 11.2 from the threat and plaintext reader to E1, E2, or E3. E1 answers a local wireless-hop risk, E2 gives a trusted gateway per-device protection, and E3 keeps the payload opaque to that gateway. At the destination, require the negative test appropriate to the selected claim. This ordered choice connects the chapter’s boundary map to the later layer-fit ledger.

Layer Fit Matrix

The right level is the one that matches the threat boundary. Adding levels without naming the plaintext owner creates complexity without evidence. Read Figure 11.2 in that order.

Worked Review: E2 or E3 for a Third-Party Gateway?

A sensor sends health-related telemetry through a gateway the customer owns and operates, outside your control. The team proposes device-to-gateway encryption (E2). The reviewer turns that into evidence questions.

Practitioner Knowledge Check

If you can map a path, name owners, and choose between E2 and E3, you can stop here. Continue to Under the Hood for why gateway-terminated transport does not protect data end-to-end across intermediaries, how E5 holds the architecture together, and how overhead is judged.

11.3 Termination Points Decide Who Can Read

This section: Termination Points Decide Who Can Read — The deeper layer explains the mechanism that ties the whole model together: every level terminates somewhere, and the component where a protected channel terminates can read the data.

The deeper layer explains the mechanism that ties the whole model together: every level terminates somewhere, and the component where a protected channel terminates can read the data. Understanding termination is what separates real end-to-end protection from a chain of hop-by-hop sessions that merely looks end-to-end.

Why a Chain of Transport Sessions Is Not End-to-End

E1 and E2 end at the next trusted component in this architecture. E4 TLS or DTLS protects a session between its configured endpoints, which need not be adjacent network nodes. A gateway-to-cloud TLS session (E4) is decrypted by the gateway on one side and the cloud on the other, so the gateway holds plaintext. If a design protects the device-to-gateway hop with E2, the gateway decrypts there, then opens a fresh TLS session to the cloud, the data is in the clear inside the gateway between those sessions. This is the crucial distinction: a chain of sessions terminated at a gateway is not end-to-end, because that gateway is a plaintext reader. In this gateway-terminating design, device-to-cloud confidentiality requires E3, where the payload is encrypted to the cloud endpoint and stays opaque as gateways and brokers forward it. The standard mechanisms for E3 are object-security schemes such as OSCORE and COSE, which protect the message itself rather than the link carrying it.

Defense in Depth, by Boundary

Levels are complementary because they protect different boundaries, not because more is always better. E1 stops a nearby outsider on the radio; E2 gives a trusted gateway per-device integrity and replay protection; E3 keeps a sensitive payload private even from that gateway; E4 authenticates the cloud endpoint and protects the internet leg. A sound architecture might use E1 plus E2 plus E4 for operational telemetry, and add E3 only for the sensitive fields that must never appear at the gateway. The test for whether a level earns its place is simple: it must protect a boundary no other selected level already covers.

E5 Is Part of the Architecture, Not an Afterthought

Every level above depends on keys, and keys age. E5 is the lifecycle that keeps the architecture working after devices leave the lab: unique provisioning so no two devices share a starting secret, rotation that supports retry, overlap, and clock uncertainty without an outage, revocation that can stop trusting a lost device or sold gateway without re-keying the fleet, and recovery that restores trust without an "accept anything" bypass. A design that cannot rotate or revoke eventually becomes a design that trusts old secrets forever, so E5 decisions about storage, ownership, and clocks must be made at the start.

Inspect Figure 11.3 to ask what evidence keeps each key state valid after a device leaves the lab.

+

Read Figure 11.3 from setup through final retirement. Provisioning gives one device its first key, identity, and owner. Protected use applies that key only to its allowed task. Rotation replaces an old key without an outage. Revocation removes trust after loss or abuse. Recovery brings back an approved device without an accept-anything bypass. Retirement erases the old link. Evidence beside each stage lets a reviewer check the change. This is how E5 supports E1 through E4: those layers can be trusted only while their keys have a valid and visible state.

Judging Overhead Honestly

Encryption overhead is real but should be measured against the actual radio, payload size, duty cycle, and threat model, not copied from another board's benchmark. AEAD modes add a nonce or counter and an authentication tag, which small payloads feel more than large ones. TLS and DTLS add session setup, record overhead, identity validation, and credential storage. Object security (E3) protects payloads through intermediaries but reduces a gateway's ability to compress, filter, or run safety logic on the data. Rotation adds a management exchange and storage for old and new credentials during overlap. The release decision should rest on measurements from representative hardware, packet sizes, sleep schedules, and network loss.

Mechanisms and Failure Modes

Common Pitfalls

Follow the sequence from decision to evidence. First, Counting layers instead of boundaries. Five named levels do not help if they all terminate at the same compromised component. Next, Treating E4 as end-to-end. TLS protects a session; it is not payload protection once a gateway, broker, or proxy terminates it. Next, One shared device key. A fleet-wide key turns one extraction into a fleet compromise and makes revocation hard. Next, Ignoring replay. Confidentiality does not prove freshness; commands and readings need nonces, counters, or protocol replay protection. Next, Skipping negative tests. A design is not proven until wrong identities, replays, tampered payloads, and revoked credentials are demonstrably rejected. Finally, Retrofitting E5 late. Rotation, revocation, recovery, and clock behavior need storage and ownership decisions from the start.

Under-the-Hood Knowledge Check

At this depth, the E1-E5 model is a discipline about termination points: name who may read on each path, choose the level that enforces it, use E3 for payloads that must stay opaque across intermediaries, authenticate transport with E4, and keep E5 lifecycle in the design from day one. The architecture is complete only when the team can answer, for every protected path, "who can decrypt this?" and "how do we prove the wrong party cannot?"