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 verifies freshness and authenticity before decrypting, 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 make the receiver prove three facts before it releases plaintext: which device sent it, whether the message is fresh, and whether the protected bytes were modified.
- This packet structure turns the E2 trust boundary into a reviewable receive procedure rather than a claim that encryption is present.
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.
- Unknown device IDs, disabled devices, and swapped device IDs are rejected.
- Separates old and new keys during rotation and recovery.
- Old, retired, and future key epochs fail according to policy.
- Tampering with any authenticated header causes verification failure.
Major section
Prefer a Reviewed AEAD Envelope · Make Freshness Survive Reboots and Loss · Use DTLS When the Gateway Link Is Datagram-Based
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.
- Authenticated session endpoint that receives ordered bytes.
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
The stateless cookie exchange does that: the gateway returns a cookie, and the client must echo it before the gateway commits more resources.
- 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.
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
Shared Fleet Keys Break E2 · Build the Trusted Building Gateway Case · Scenario
Visitor-count payloads are sensitive and should remain opaque to the gateway.
- If every device uses the same E2 key, the gateway cannot identify which device really sent a message, and one extraction becomes a fleet compromise.
- E2 depends on per-device accountability.
- E4 identity validation and credential lifecycle tests.
Major section
Avoid the E2 Mistakes That Expose Plaintext · Gateway Trust Decision
Mistake Using one fleet key A shared E2 key removes device accountability and turns one extracted key into a fleet-wide incident.
- Mistake Reusing nonces after reset Sleep and reset behavior must not cause nonce or counter reuse under the same key.
- Mistake Decrypting before verification The gateway should authenticate the envelope and freshness before releasing plaintext to application logic.
- Mistake Ignoring gateway compromise If gateway compromise is in scope, use E3 for sensitive fields or remove plaintext duties from the gateway.
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 make the receiver prove three facts before it releases plaintext: which device sent it, whether the message is fresh, 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.
- Replay protection is not just a sequence number field.
Retrieval practice
Recall check 1 of 5
Shield Shelly says: answer from memory, then check your reasoning.
Q1Why is DTLS commonly used instead of ordinary TLS on constrained device-to-gateway links?
Show answer
Answer: A DTLS adapts TLS-style protection to datagrams that may be lost, reordered, or retransmitted.
Retrieval practice
Recall check 2 of 5
Shield Shelly says: answer from memory, then check your reasoning.
Q2Why is DTLS pre-shared-key mode often chosen for very constrained IoT devices?
Show answer
Answer: A PSK mode lowers device storage and computation needs, but the keys still need careful provisioning.
Retrieval practice
Recall check 3 of 5
Shield Shelly says: answer from memory, then check your reasoning.
Q3What problem does the DTLS stateless cookie exchange solve for a UDP gateway?
Show answer
Answer: A The client must echo a gateway-issued cookie before the gateway commits resources.
Retrieval practice
Recall check 4 of 5
Shield Shelly says: answer from memory, then check your reasoning.
Q4A sensor sends equipment temperature readings to a floor gateway. The gateway is owned by the operator and must run local shutdown logic if the cloud is offline. Which encryption layer is the best fit for that payload?
Show answer
Answer: A E2 is a gateway-trust decision.
Retrieval practice
Recall check 5 of 5
Shield Shelly says: answer from memory, then check your reasoning.
Q5Place each control where it lives so you can trace when a gateway may trust a device message and release its plaintext.
Show answer
Answer: A These regions connect the decision from evidence to action so you can trace when a gateway may trust a device message and release its plaintext.
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.
- A · DTLS adapts TLS-style protection to datagrams that may be lost, reordered, or retransmitted.
- A · PSK mode lowers device storage and computation needs, but the keys still need careful provisioning.
- A · The client must echo a gateway-issued cookie before the gateway commits resources.
- A · E2 is a gateway-trust decision.
- A · These regions connect the decision from evidence to action so you can trace when a gateway may trust a device message and release its plaintext.
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.