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.

encryptiontransport

Shield Shelly, the module guide, in a scene from this chapter.

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.

E3 controls payload plaintext ownership; E4 controls authenticated transport sessions.

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.

E3 lets gateways route useful metadata while sensitive payload fields remain opaque.

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.
Its (EC)DHE modes provide forward secrecy; PSK-only mode does not.
Certificate-based deployments still need certificate validation.

Major section

Keep Old Sessions Safe After Key Theft · Forward Secrecy

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

Manage Trust Roots, Early Data, and Mutual TLS · Certificate Validation Failure

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 · Selection Workflow: 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.

E4 release evidence must prove peer identity, fresh session keys, encrypted records, and fail-closed behavior.

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 sender does not reuse a nonce under the same key.

Major section

Scenario (continued)

The cloud rejects modified ciphertext, modified associated data, a replayed authenticated sequence value, and the wrong key epoch.

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.

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.

Q1An E4 TLS or DTLS session must authenticate its intended peer and keep past recorded traffic secret even if a long-term key later leaks. Beyond record encryption, which evidence pair best supports those requirements?

AForward-secret key exchange and verified peer identity

BLong URLs and high cloud endpoint uptime

CA padlock icon and a familiar port number

DCipher key size with all identity checks skipped

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?

ACertificates never expire during long gateway deployments

BOne reused session key makes every handshake faster

CRecorded old sessions stay sealed after later server-key theft

DServer identity checks can be skipped after encryption

Show answer

Answer: C 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?

AIt builds an encrypted session to an unverified endpoint

BIt upgrades E4 transport security into E3 payload secrecy

CIt only affects expiration checks on otherwise safe links

DIt proves the cipher suite is approved for production

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?

AE4 gateway-to-cloud TLS with gateway decryption.

BServer certificate parsing without hostname validation

CA gateway key shared across all device payloads.

DE3 object or device-to-cloud payload protection

Show answer

Answer: D Use E3 when the gateway should route but not read selected payload fields.

Q5What keeps application content protected beyond transport hops, including through an intermediary?

AE3 Payload Envelope

BVisible Routing Metadata

CE4 TLS/DTLS Session

DOpaque Gateway

Show answer

Answer: A It keeps application content protected beyond transport hops.

Retrieval practice

Recall check 5 of 5

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

Q6Complete the E3-E4 release gate:

Areturn 'REQUIRE_E3_OPAQUE_PAYLOAD'

Breturn 'ALLOW_GATEWAY_PLAINTEXT'

Creturn 'DISABLE_OBJECT_PROTECTION'

Dreturn 'STORE_PAYLOAD_IN_GATEWAY_LOGS'

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.
C · 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.
D · Use E3 when the gateway should route but not read selected payload fields.
A · It keeps application content protected beyond transport hops.

Print reference

Answers 2 of 2

Answer key.

A · The gate checks opaque payloads, TLS service identity, plaintext fallback, and replay-safe early data behavior.