Cryptography · Study deck
E3-E4: Transport Encryption
Picture a meter record crossing a local bridge before it reaches a billing service.
Shield Shelly is your guide for this deck.
After studying this chapter
Learning objectives
You will be able to:
- Separate E3 opaque payload protection from E4 transport session protection.
- Decide whether a gateway should decrypt, forward opaque payloads, or only terminate transport.
- Define object-security evidence for nonce or sequence freshness, associated data, payload integrity, and key ownership.
- Define TLS/DTLS evidence for certificate validation, service identity, mutual authentication, version policy, and downgrade rejection.
Major section
In 60 Seconds
A locked radio hop can still end at a plain-text queue, and a protected connection can still carry a stale reading.
- TLS means protected transport that checks the service identity and can also check the client on a connected exchange.
- DTLS means similar protection for separate datagrams.
- A payload is the useful content carried inside a message.
Major section
In 60 Seconds (continued)
A gateway is the device or service that joins two system paths.
- This runway does not prove the application is safe or that a side effect happened once.
- E4 does not hide data from a gateway that already decrypted it; E3 does.
- E4 locks the mailroom's network connection to the cloud, while E3 seals selected letters so the mailroom can route them but cannot read them.
Major section
Keep Payload Secrecy Separate From Transport Security · Naming Used in This Book
If the gateway must not read the payload, use E3 object or device-to-cloud protection.
- If the gateway is sending data to the cloud over the Internet, use E4 transport protection for that session.
- Many systems use both.
- Layering both protects different boundaries.
Major section
Use E3 When Gateways Should Only Route · Use E4 to Authenticate the Transport Session
E3 is appropriate when an intermediary should route, buffer, translate, or broker messages without reading selected payload fields.
- The important property is key ownership: the gateway does not have the payload decryption key.
- Gateway may read only the approved routing fields.
- E4 protects a session between endpoints.
Major section
Certificate Parsing Is Not Certificate Validation · Prove the TLS Session Has the Right Peer
A gateway that accepts any certificate, ignores the expected service name, disables expiry checks, or trusts a self-signed test certificate in production has lost the main protection that TLS and DTLS are meant to provide.
- "Using TLS" is not one security decision.
- The release evidence needs to show which peer identity was verified, which key exchange created the traffic keys, which authenticated encryption protected the records, and which failure cases were rejected.
- TLS 1.3 or approved ECDHE policy is enforced; obsolete static key transport and downgrade paths are rejected.
Major section
TLS Review Levers · Keep Old Sessions Safe After Key Theft
Certificate validation is the matching identity control.
- Parsing a certificate is only syntax; validation is the decision to accept or reject the endpoint.
- For IoT releases, the proof should include positive configuration evidence and negative tests that obsolete protocol versions, static key transport, wrong names, wrong issuers, and expired certificates fail closed.
- If the server's long-term private key is stolen later, old packet captures should still remain sealed because there is no reusable transport key that decrypts them.
Major section
Forward Secrecy · Manage Trust Roots, Early Data, and Mutual TLS
PKI also has a trust-root problem.
- The hardest E4 failures are often trust failures rather than cipher failures.
- A client that disables certificate validation, accepts any certificate, or trusts an unapproved test root creates an encrypted channel to whoever intercepted the connection.
- TLS 1.3 also changes deployment evidence.
Major section
Select the Layer by Who May Read · Practical Rule
Device-to-gateway messages that the gateway is allowed to inspect.
- Gateway key store controls, per-device keys, replay protection, and local policy logs.
- Gateway cannot decrypt; cloud rejects tampering, replay, wrong key, and wrong epoch.
- TLS/DTLS version policy, certificate validation, mTLS policy, and negative identity tests.
Major section
Check Identity Before Trusting the Session · Build the Third-Party Field Gateway Case
Early data Treat replay as a design issue Session resumption can reduce setup cost, but replayable early data must not carry unsafe commands or non-idempotent actions.
- TLS and DTLS are protocol frameworks.
- Production security depends on the certificate and identity policy you actually enforce.
- Client identity Authenticate gateway or device Mutual TLS can bind a gateway or device certificate to an enrolled identity and authorization policy.
Major section
Scenario
The gateway provider is trusted to route packets and maintain availability, but it should not inspect detailed readings or control commands.
- Operational readings that the gateway does not need to inspect.
- E3 object payload cannot be decrypted by the gateway; cloud rejects tampering and replay.
- Gateway may read only approved routing fields.
- Visible metadata is classified and authenticated where required.
Major section
Scenario (continued)
E4 TLS or DTLS validates service identity and rejects wrong issuer, wrong name, expiry, and downgrade.
- End by Do not rely on E4 alone to hide fields from a gateway that has already received plaintext.
- The gateway cannot decrypt a sample E3 condition report.
- The cloud rejects modified ciphertext, modified associated data, a replayed nonce, and the wrong key epoch.
Major section
Scenario (continued)
The gateway can route only the visible metadata approved by the data classification.
- Gateway-cloud TLS or DTLS rejects the wrong service name, wrong issuer, expired certificate, and obsolete version.
- Plaintext fallback ports and insecure debug endpoints are blocked before release.
- Session resumption and early data policies are tested for replay-safe behavior.
Major section
Avoid the E3-E4 Mistakes That Leak Payloads · Boundary Decision
Mistake Calling TLS end-to-end TLS is end-to-end only between its session endpoints.
- If a gateway terminates TLS and forwards plaintext, the gateway saw the data.
- Mistake Disabling certificate validation Accepting any certificate turns encrypted transport into an encrypted connection to whoever is intercepting the traffic.
- Mistake Leaving plaintext fallback open Blocked TLS configuration is not enough if devices silently retry over an unencrypted port or debug endpoint.
Deck summary
Key takeaways
A locked radio hop can still end at a plain-text queue, and a protected connection can still carry a stale reading.
- A gateway is the device or service that joins two system paths.
- If the gateway must not read the payload, use E3 object or device-to-cloud protection.
- E3 is appropriate when an intermediary should route, buffer, translate, or broker messages without reading selected payload fields.
- A gateway that accepts any certificate, ignores the expected service name, disables expiry checks, or trusts a self-signed test certificate in production has lost the main protection that TLS and DTLS are meant to provide.
Retrieval practice
Recall check 1 of 5
Shield Shelly says: answer from memory, then check your reasoning.
Q1Beyond encrypting records, which evidence pair most determines whether an E4 TLS or DTLS session is safe?
Show answer
Answer: A Transport security depends on fresh session keys and proof that the endpoint is the intended peer.
Retrieval practice
Recall check 2 of 5
Shield Shelly says: answer from memory, then check your reasoning.
Q2What does forward secrecy from ephemeral ECDHE key exchange protect against?
Show answer
Answer: A Fresh per-session keys mean future compromise of a long-term key does not decrypt old captures.
Retrieval practice
Recall check 3 of 5
Shield Shelly says: answer from memory, then check your reasoning.
Q3A gateway uses TLS but accepts any certificate without validation. What has the design actually allowed?
Show answer
Answer: A The channel may be encrypted, but the gateway has not proven that the endpoint is the intended service.
Retrieval practice
Recall check 4 of 5
Shield Shelly says: answer from memory, then check your reasoning.
Q4A device sends sensitive readings through a gateway operated by a third party. The gateway only needs topic and routing metadata. Which protection is required so the gateway cannot read the sensitive payload?
Show answer
Answer: A Use E3 when the gateway should route but not read selected payload fields.
Retrieval practice
Recall check 5 of 5
Shield Shelly says: answer from memory, then check your reasoning.
Q5Place each E3-E4 evidence role where it lives so you can prove both payload ownership and transport-session protection.
Show answer
Answer: A E3 protects the payload envelope, the gateway forwards only visible routing metadata, and E4 protects the endpoint session so you can audit confidentiality at both boundaries.
Q6Complete the E3-E4 release gate:
Show answer
Answer: A The gate checks opaque payloads, TLS service identity, plaintext fallback, and replay-safe early data behavior.
Print reference
Answers 1 of 2
Answer key.
- A · Transport security depends on fresh session keys and proof that the endpoint is the intended peer.
- A · Fresh per-session keys mean future compromise of a long-term key does not decrypt old captures.
- A · The channel may be encrypted, but the gateway has not proven that the endpoint is the intended service.
- A · Use E3 when the gateway should route but not read selected payload fields.
Print reference
Answers 2 of 2
Answer key.
- A · E3 protects the payload envelope, the gateway forwards only visible routing metadata, and E4 protects the endpoint session so you can audit confidentiality at both boundaries.
- A · The gate checks opaque payloads, TLS service identity, plaintext fallback, and replay-safe early data behavior.