11 The Layered Encryption Model

The E1-E5 Model, Plaintext Ownership, and Trust Boundaries

security

cryptography

iot

Keywords

IoT encryption architecture, E1-E5 model, trust boundaries, end-to-end encryption, transport encryption, object security, plaintext ownership

11.1 Start by Asking Who May Read the Plaintext

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.

If you only need the intuition, this layer is enough: pick encryption levels by trust boundary, not by habit. Name who is allowed to decrypt on each hop, then choose the level that enforces it. Adding more layers that all terminate at the same component adds cost without adding protection.

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.

The E1-E5 architecture separates link, device-gateway, device-cloud, transport, and key-lifecycle protection so each encryption choice maps to a distinct trust boundary.

Naming used in this book: E3 means device-to-cloud or object-level protection that stays opaque to gateways, and E4 means session transport such as gateway-to-cloud TLS or DTLS. Keep those two meanings distinct when reading older notes or diagrams that number layers differently.

The One-Minute View

Start from plaintext ownership

For every hop, decide which component may decrypt and which must only forward ciphertext. That decision picks the level.

Levels are boundaries, not a count

E1 link, E2 device-gateway, E3 device-cloud, E4 transport, E5 lifecycle each protect a different boundary. Five labels that all end at one box protect one box.

Transport is not end-to-end

TLS or DTLS (E4) protects a session between two endpoints. If a gateway terminates it, the gateway still sees plaintext unless E3 keeps the payload opaque.

Beginner Examples

A local radio link with a join-controlled key (E1) keeps nearby strangers from reading or joining, but every joined node on a shared key can still read the hop.
A gateway that runs local automation needs to read 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, but 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

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.

Walkthrough: The Selection Workflow

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.
Name the plaintext owner. For each hop, state which systems may decrypt and which must only forward ciphertext.
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.
Plan the lifecycle. Define E5 provisioning, rotation, revocation, ownership transfer, decommission, and recovery for the keys every level depends on.
Run negative tests. Prove rejection for the wrong identity, a replay, a modified payload, an expired credential, a revoked key, and a rollback attempt.

Each level answers a trust question along the path, and the release gate requires a negative test for every level that is selected.

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.

Level

Plaintext Owner

Protects Against

Review Evidence

E1 link

The local link members after a frame is accepted by the radio or network stack.

Nearby passive capture and unauthorized local participation.

Commissioning and join control, link-key policy, and capture showing non-members cannot read.

E2 device-gateway

The device and a trusted gateway or gateway service.

Shared-network exposure, spoofed device messages, and replayed telemetry or commands.

Unique device keys, AEAD or MAC verification, nonce or counter handling, and replay rejection.

E3 device-cloud

The device and the cloud application or object-security endpoint only.

Compromised or third-party gateways, broker inspection, and queue storage exposure.

Gateway cannot decrypt a test payload; cloud rejects a tampered object; intermediaries hold no keys.

E4 transport

The two authenticated session endpoints, often gateway and cloud service.

Internet eavesdropping, man-in-the-middle, wrong service identity, and session tampering.

TLS or DTLS version policy, peer identity validation, trust anchors, and negative certificate tests.

E5 lifecycle

The key owner, device, service, and recovery authority per policy.

Stale keys, lost devices, expired certificates, and unrecoverable rotation failures.

Provisioning records, a rotation owner, a revocation path, a recovery test, and a decommission process.

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.

What E2 would give

E2 protects the link to the gateway and lets the gateway validate and decrypt, which is correct when the gateway is trusted to read and act on the data.

What the requirement demands

The gateway is third-party and should never see health values, so a level that terminates at the gateway exposes exactly the data that must stay private.

Conclusion

Use E3 object or device-to-cloud protection so the gateway forwards an opaque payload it cannot decrypt, keep E4 TLS for the gateway-to-cloud leg, and prove the gateway fails to read a test payload.

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 transport is not end-to-end, how E5 holds the architecture together, and how overhead is judged.

11.3 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. 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 Transport Encryption Is Not End-to-End

E1, E2, and E4 are all point-to-point: they protect a single hop between two adjacent components and terminate at each end. 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 has been in the clear inside the gateway the whole time. This is the crucial distinction: a chain of hop-by-hop sessions is not end-to-end, because every intermediate component that terminates a session is a plaintext reader. True 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.

E5 carries keys through provisioning, use, rotation, revocation, recovery, and retirement, with evidence kept at each step so the architecture survives field operation.

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

Level

What It Guarantees

Terminates At

Failure Mode If Misused

E1 link

The local hop is unreadable to non-members of the link.

The two link endpoints (often via a shared group key).

A shared link key gives no per-device accountability or targeted revocation.

E2 device-gateway

Per-device integrity, authenticity, and replay protection to a trusted gateway.

The device and the gateway, which becomes a plaintext reader.

Trusting an untrusted gateway exposes payloads it should never read.

E3 device-cloud

Payload confidentiality and integrity end-to-end to the cloud endpoint.

The device and the cloud or object-security endpoint only.

Omitting it lets any terminating intermediary read sensitive data.

E4 transport

An authenticated, tamper-resistant session between two endpoints.

Each session endpoint, such as gateway and cloud.

Treating it as end-to-end ignores plaintext at the gateway that terminates it.

E5 lifecycle

Keys can be provisioned, rotated, revoked, and recovered over time.

The key owner, device, and recovery authority per policy.

Retrofitting it late leaves a fleet trusting stale or unrevocable keys.

Common Pitfalls

Counting layers instead of boundaries. Five named levels do not help if they all terminate at the same compromised component.
Treating E4 as end-to-end. TLS protects a session; it is not payload protection once a gateway, broker, or proxy terminates it.
One shared device key. A fleet-wide key turns one extraction into a fleet compromise and makes revocation hard.
Ignoring replay. Confidentiality does not prove freshness; commands and readings need nonces, counters, or protocol replay protection.
Skipping negative tests. A design is not proven until wrong identities, replays, tampered payloads, and revoked credentials are demonstrably rejected.
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 hop, choose the level that enforces it, reserve E3 for true end-to-end payloads, authenticate transport with E4 without mistaking it for end-to-end, 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?”

11.4 Interactive: Trace the E1-E5 Boundaries

11.5 Summary

Encryption architecture starts with plaintext ownership: for each hop, decide which component may read the data and which must only forward ciphertext.
The E1-E5 model maps levels to trust boundaries: E1 link, E2 device-to-gateway, E3 device-to-cloud or object protection, E4 transport session, and E5 key lifecycle.
This book uses E3 for object or device-to-cloud protection that stays opaque to gateways, and E4 for session transport such as TLS or DTLS.
E1, E2, and E4 are point-to-point and terminate at intermediaries; only E3 provides true end-to-end payload confidentiality to the cloud endpoint.
Transport encryption is not end-to-end: a gateway that terminates TLS or decrypts E2 has seen the plaintext, so sensitive payloads need E3.
Choose E2 when a trusted gateway must read and act on data, and E3 when an untrusted or third-party gateway must only route opaque payloads.
E5 is part of the architecture: provisioning, rotation, revocation, and recovery must be designed in, and every selected level needs negative tests.

Key Takeaway

Do not rely on one encryption level, and do not stack levels by habit. Match E1 link, E2 device-to-gateway, E3 device-to-cloud, E4 transport, and E5 lifecycle to the trust boundaries of the data path. For every protected path, be able to answer who may decrypt it and how you prove the wrong party cannot.