Cryptography · Study deck
E2: Device-to-Gateway Encryption
Picture a sealed sensor message reaching a local controller that must read it before switching a fan.
Shield Shelly is your guide for this deck.
After studying this chapter
Learning objectives
You will be able to:
- Explain exactly where E2 encryption terminates and which component owns plaintext.
- Design an E2 packet envelope with per-device identity, nonce or counter, authenticated metadata, ciphertext, and tag.
- Define replay protection that survives reset, sleep, loss, and gateway restart.
- Decide when a trusted gateway justifies E2 and when an untrusted gateway requires E3.
Major section
In 60 Seconds
A gateway means the trusted device or service that joins systems and, in this design, ends the protected device link.
- E2 protects messages from a device to a trusted gateway.
- Each device has its own credential, the gateway checks replay state and accepts plaintext only after authentication succeeds, and intermediate routers only forward ciphertext.
- E2 is the right fit when the gateway is allowed to read payloads for local control or filtering.
Major section
Choose E2 Only When the Gateway May Read · Plaintext Owner
E2 is not the same thing as end-to-end device-to-cloud encryption.
- In E2, the gateway is trusted to authenticate and decrypt device payloads.
- That final plaintext boundary is what enables local action and creates the gateway-compromise risk.
- In E2, the gateway is an approved plaintext owner.
Major section
Build the Packet So the Gateway Can Prove It
An E2 packet should let the receiver check three facts before it releases plaintext: which enrolled credential authenticated it, whether the message has already been accepted, and whether the protected bytes were modified.
- Unknown device IDs, disabled devices, and swapped device IDs are rejected.
- Separates old and new keys during rotation and recovery.
- This packet structure turns the E2 trust boundary into a reviewable receive procedure rather than a claim that encryption is present.
- Tampering with any authenticated header causes verification failure.
Major section
Build the Packet So the Gateway Can Prove It (continued)
Identity selects the expected device and key scope; freshness state rejects an old envelope; authenticated metadata binds visible routing context to the protected message; and the tag detects modification before plaintext is accepted.
- Old, retired, and future key epochs fail according to policy.
- Replayed, rolled-back, duplicated, and out-of-window packets are rejected.
- Authenticates headers that must remain readable for routing or policy decisions.
Major section
Prefer a Reviewed AEAD Envelope · Make Freshness Survive Reboots and Loss
Replay protection is not just a sequence number field.
- The device, gateway, and recovery process must agree what happens after sleep, reset, packet loss, clock drift, key rotation, and gateway failover.
- Device stores send state Persist enough counter, epoch, or nonce state so reboot does not reuse values under the same key.
- Loss is expected Use a bounded acceptance window only when the protocol can tolerate out-of-order delivery.
Major section
Use DTLS When the Gateway Link Is Datagram-Based
Ordinary TLS expects reliable, ordered bytes, so it is the wrong transport shape for lossy datagram links.
- DTLS is the TLS family protocol adapted for datagrams: it protects records that may be lost, reordered, or retransmitted while still requiring authentication, confidentiality, integrity, and replay handling.
- DTLS can secure the device-to-gateway session, but the gateway is still a plaintext owner once the session terminates there.
- Authenticated session endpoint that receives ordered bytes.
Major section
Use DTLS When the Gateway Link Is Datagram-Based (continued)
If that plaintext ownership is not acceptable, the payload needs E3 object protection even if the local hop also uses DTLS.
- TCP profile, certificate or PSK policy, version policy, and identity validation tests.
- DTLS version, cipher suite, replay window, retransmission behavior, and cookie behavior are tested.
- Payload fields that must survive gateway forwarding without gateway plaintext access.
- Forwarder only, unless the payload is explicitly assigned to E2 plaintext ownership.
Major section
DTLS on Datagram Links · Choose Credentials the Device Can Protect
Certificate-based DTLS can be appropriate when devices can store and validate certificates and the deployment needs PKI-style identity management.
- Very small sensors may instead use raw public keys or a pre-shared key profile.
- The PSK must identify one device or a tightly bounded derivation path, not the whole fleet.
- A good E2 review therefore pairs the authentication mode with key ownership, storage, rotation, and revocation evidence.
Major section
Prove DTLS Survives Spoofing, Sleep, and Rotation · DTLS Cookie Exchange
Sleepy devices should not repeat full handshakes every time they wake if the protocol and risk model allow resumption.
- UDP lets an attacker spoof source addresses more easily than TCP.
- Battery life is the other deployment issue.
- Spoofed-source handshakes fail without creating persistent gateway state or amplification.
Major section
Choose E2, E3, or E4 by Plaintext Ownership
The right answer depends on who may see plaintext, not on which name sounds stronger.
- That comparison connects the layer labels to a concrete review question: name every permitted reader first, then require keys and negative tests for that boundary.
- Payloads that must remain opaque through gateways, brokers, queues, or proxies.
- The E2 path ends at a trusted gateway that verifies and decrypts device data; the E3 path keeps the selected payload opaque until the cloud or application endpoint; and E4 protects an authenticated transport session, which may begin at the gateway after it has already seen plaintext.
Major section
Choose E2, E3, or E4 by Plaintext Ownership (continued)
Gateway key store controls, per-device keys, replay rejection, tag failure tests, and local action policy.
- Forwarder only; it should not have payload keys.
- Gateway cannot decrypt test payloads; cloud rejects tampered objects and wrong device identity.
- Certificate identity validation, version policy, expired/revoked credential behavior, and downgrade tests.
Major section
E2 Is Appropriate When · Treat the Gateway Key Store as the Boundary
The E2 gateway is both a verifier and a key holder.
- Its key store is therefore part of the security boundary, not a normal configuration file.
- Provision Enroll unique device credentials Manufacturing, commissioning, or onboarding should create one device identity and one active E2 key record per device.
- Rotate Support overlap and retry Rotation needs key epochs, rollback-safe activation, and recovery from devices that miss an update window.
Major section
Scenario · Avoid the E2 Mistakes That Expose Plaintext
Gateways run local HVAC safety logic during cloud outages, so they are approved to read operational payloads.
- Visitor-count payloads are sensitive and should remain opaque to the gateway.
- Per-device E2 keys, replay rejection, tag failure tests, and gateway action logs.
- Gateway policy limits storage, logging, and forwarding of decrypted fields.
Major section
Summary · Key Takeaway
Device-to-gateway encryption protects data as it moves from constrained devices into local gateways.
- It must account for local attackers, shared network media, gateway trust, credential storage, and what happens when gateways relay data onward.
- Device-to-gateway security should define both ends of trust.
- Encrypt the link, authenticate the device and gateway, and decide whether the gateway is allowed to see plaintext or only forward protected payloads.
Deck summary
Key takeaways
A gateway means the trusted device or service that joins systems and, in this design, ends the protected device link.
- E2 is not the same thing as end-to-end device-to-cloud encryption.
- An E2 packet should let the receiver check three facts before it releases plaintext: which enrolled credential authenticated it, whether the message has already been accepted, and whether the protected bytes were modified.
- Identity selects the expected device and key scope; freshness state rejects an old envelope; authenticated metadata binds visible routing context to the protected message; and the tag detects modification before plaintext is accepted.
Retrieval practice
Recall check 1 of 4
Shield Shelly says: answer from memory, then check your reasoning.
Q1In E2 device-to-gateway encryption, where does protected payload become plaintext?
Show answer
Answer: C The gateway is the approved plaintext owner in E2.
Q2A sleeping device reboots and its gateway also restarts; what must replay protection define?
Show answer
Answer: B Counters alone fail if reset lets old packets appear fresh.
Retrieval practice
Recall check 2 of 4
Shield Shelly says: answer from memory, then check your reasoning.
Q3Why is DTLS pre-shared-key mode often chosen for very constrained IoT devices?
Show answer
Answer: B PSK mode lowers device storage and computation needs, but the keys still need careful provisioning.
Retrieval practice
Recall check 3 of 4
Shield Shelly says: answer from memory, then check your reasoning.
Q4What problem does the DTLS stateless cookie exchange solve for a UDP gateway?
Show answer
Answer: C The client must echo a gateway-issued cookie before the gateway commits resources.
Q5What rejects duplicate device packets outside the permitted replay window at the gateway?
Show answer
Answer: D It rejects duplicates and packets outside the allowed replay window, while permitted out-of-order packets may still pass.
Retrieval practice
Recall check 4 of 4
Shield Shelly says: answer from memory, then check your reasoning.
Q6Complete the E2 gateway design review gate:
Show answer
Answer: A The gate rejects shared fleet keys, missing replay rejection, missing tag-failure rejection, and sensitive payloads sent to an untrusted gateway.
Print reference
Answers 1 of 2
Answer key.
- C · The gateway is the approved plaintext owner in E2.
- B · Counters alone fail if reset lets old packets appear fresh.
- B · PSK mode lowers device storage and computation needs, but the keys still need careful provisioning.
- C · The client must echo a gateway-issued cookie before the gateway commits resources.
- D · It rejects duplicates and packets outside the allowed replay window, while permitted out-of-order packets may still pass.
Print reference
Answers 2 of 2
Answer key.
- A · The gate rejects shared fleet keys, missing replay rejection, missing tag-failure rejection, and sensitive payloads sent to an untrusted gateway.