Cryptography · Study deck

The Layered Encryption Model

Picture a health sensor sending a private reading through a home bridge to a care service.

Shield Shelly is your guide for this deck.

encryption-architecturee1-e5trust-boundaries
Shield Shelly, the module guide, in a scene from this chapter.
iotclass.org

After studying this chapter

Learning objectives

You will be able to:

  • Explain: 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.
  • Explain: 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.
  • Explain: 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.
  • Distinguish E2 gateway decryption from E3 object protection
Map every hop, name the plaintext owner, match E1–E4, plan E5 key lifecycle and run negative tests. Select protection by trust boundary, then prove the wrong party is rejected.
Each level answers a trust question along the path, and the release gate requires a negative test for every level that is selected.
iotclass.org

Major section

Start by Asking Who May Read the Plaintext · Map the Path and Name the Plaintext Owners

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.
  • The first panel starts with a private reading.
  • A payload means the useful data inside one message.

Key terms

Transport layer security
Transport layer security means protection for a network stream; it is called TLS.

Why it matters

The most common confusion is between E2 and E3, because both protect application payloads; the difference is where decryption is allowed to happen.

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

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

  • Understanding termination is what separates real end-to-end protection from a chain of hop-by-hop sessions that merely looks end-to-end.

Key terms

Levels
Levels are complementary because they protect different boundaries, not because more is always better.

Why it matters

Defense in Depth, by Boundary Levels are complementary because they protect different boundaries, not because more is always better.

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

Major section

Termination Points Decide Who Can Read (continued)

E5 Is Part of the Architecture, Not an AfterthoughtEvery level above depends on keys, and keys age.

  • E4 TLS or DTLS protects a session between its configured endpoints, which need not be adjacent network nodes.
  • Provisioning gives one device its first key, identity, and owner.
  • Revocation removes trust after loss or abuse.
iotclass.org

Major section

Termination Points Decide Who Can Read (continued)

Evidence beside each stage lets a reviewer check the change.

  • 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.
  • Protected use applies that key only to its allowed task.
  • Omitting it lets any terminating intermediary read sensitive data.
iotclass.org

Major section

Termination Points Decide Who Can Read (continued)

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.

  • 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.
  • Recovery brings back an approved device without an accept-anything bypass.
iotclass.org

Major section

Termination Points Decide Who Can Read (continued)

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.

  • Judging Overhead HonestlyEncryption 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.
  • 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.
iotclass.org

Major section

Termination Points Decide Who Can Read (continued)

The release decision should rest on measurements from representative hardware, packet sizes, sleep schedules, and network loss.

  • The local hop is unreadable to non-members of the link.
  • A shared link key gives no per-device accountability or targeted revocation.
  • The device and the gateway, which becomes a plaintext reader.
iotclass.org

Major section

Termination Points Decide Who Can Read (continued)

Defense in Depth, by BoundaryLevels are complementary because they protect different boundaries, not because more is always better.

  • Trusting an untrusted gateway exposes payloads it should never read.
  • Keys can be provisioned, rotated, revoked, and recovered over time.
  • Retrofitting it late leaves a fleet trusting stale or unrevocable keys.
iotclass.org

Deck summary

Key takeaways

A locked radio link helps, but the reading may become plain text again at each stop.

  • 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.
  • E5 Is Part of the Architecture, Not an AfterthoughtEvery level above depends on keys, and keys age.
  • Evidence beside each stage lets a reviewer check the change.
  • 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.
iotclass.org

Retrieval practice

Recall check 1 of 3

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

Q1What is the first question an encryption architecture should answer, before choosing any algorithm?

AWhich cipher has the largest key size available on the device
BFor each hop, which component is actually allowed to read the plaintext.
CHow many encryption layers can be enabled at once
DWhether the cloud provider already encrypts data at rest
Show answer

Answer: B Plaintext ownership is the decision that selects the right level.

iotclass.org

Retrieval practice

Recall check 2 of 3

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

Q2A sensor sends health telemetry through a third-party gateway that should only route messages and must not see payload values. Beyond local link protection and gateway-to-cloud TLS, which level is the key addition?

AE2 device-to-gateway encryption terminating at that gateway
BE3 device-to-cloud or object payload protection beyond the gateway
CE4 gateway-to-cloud TLS terminating at the cloud server
DE5 key renewal alone without any payload confidentiality boundary
Show answer

Answer: B E3 is the level for payloads that must stay protected through a gateway, broker, queue, or proxy that is not allowed to read them.

iotclass.org

Retrieval practice

Recall check 3 of 3

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

Q3A design protects device-to-gateway traffic with E2, has the gateway decrypt it, then opens a separate gateway-to-cloud TLS session (E4), and claims the data is encrypted end-to-end from device to cloud. Why is that claim wrong?

AThe claim is valid because both network legs carry ciphertext and resist passive interception.
BIt is correct as long as both sessions use the same cipher suite
CBoth E2 and E4 are point-to-point and terminate at the gateway.
DIt is wrong only because TLS is weaker than the E2 link encryption
Show answer

Answer: C A chain of hop-by-hop sessions is not end-to-end.

iotclass.org

Print reference

Answers

Answer key.

  1. B · Plaintext ownership is the decision that selects the right level.
  2. B · E3 is the level for payloads that must stay protected through a gateway, broker, queue, or proxy that is not allowed to read them.
  3. C · A chain of hop-by-hop sessions is not end-to-end.
iotclass.org