Cryptography · Study deck
TLS and DTLS for IoT
Picture a water meter that sends a usage reading through a building bridge.
Shield Shelly is your guide for this deck.
After studying this chapter
Learning objectives
You will be able to:
- Explain: DTLS 1.3 record processing rejects duplicate sequence numbers (RFC 9147 §4.5.1), while §3.4 describes replay detection as optional; a sliding anti-replay window is a common implementation.
- Explain: When enabled, a cookie or return-routability exchange makes a client prove it can receive at its claimed source address before the server commits substantial state or sends large responses.
- Explain: None of this makes a state-changing datagram idempotent: if a repeated command would be unsafe, the application still needs command identifiers or a deduplication policy of its own.
Major section
In 60 Seconds · Secure One Verified Connection
Encryption matters only if the right service receives the right reading and a copied message cannot be accepted as new.
- Transmission Control Protocol (TCP) means a stream that checks order and delivery.
- Transport layer security means protection for that stream; it is called TLS.
- Datagram Transport Layer Security (DTLS) protects those separate messages.
Major section
Build Evidence for a TLS or DTLS Deployment
A transport-security review should produce concrete evidence rather than an "encrypted" label.
- Each item is a separate decision, and the common failure is asking the protocol to prove something it was never configured to prove.
- Skipping the name check breaks authentication even when encryption works.
Major section
Build Evidence for a TLS or DTLS Deployment (continued)
The service must authenticate each device with asymmetric credentials.
- Validate the peer correctly: For certificates, check the trust chain, validity period, revocation or status, and the identity (name) match.
- It must never silently downgrade to cleartext or to a weaker version.
- Per-device key in protected storage, plus issuance, renewal, and revocation records.
Major section
Build Evidence for a TLS or DTLS Deployment (continued)
Expected name match, scoped trust anchor, chain plus validity plus revocation check, and a wrong-name rejection test.
- Accepting any valid-looking certificate, or skipping the name check, removes the identity claim.
- Provisioning can distribute scoped secrets to constrained devices.
- Constrained devices avoid certificate parsing but still need a bound identity.
Major section
Build Evidence for a TLS or DTLS Deployment (continued)
The worked decision above makes a bounded claim about one CoAP/DTLS link.
- Per-device or scoped PSK, identity label, rotation, old-secret rejection, and a profile that adds ephemeral ECDHE for forward secrecy.
- One fleet-wide PSK means a single extraction compromises every device, and a PSK-only profile may lack forward secrecy.
- The reject path is equally important: wrong identity, stale credentials, replayed records, or unacceptable policy must stop the connection.
Major section
How the Handshake and Records Earn Trust
The deeper layer explains how each guarantee is built and why each is separate.
- A connection is only as trustworthy as its handshake, its key agreement, its record protection, and its plaintext boundary.
- PSK-only handshakes do not provide forward secrecy.
- A cipher suite is not one algorithm.
Major section
How the Handshake and Records Earn Trust (continued)
An impostor is accepted, or parameters are silently downgraded to weak ones.
- Crucially, it authenticates a transcript of that negotiation: when both sides verify the Finished messages, any attacker tampering with or downgrading the offered parameters is detected.
- TLS 1.3 (RFC 8446) modernized this: its standard cipher suites use AEAD, ephemeral (EC)DHE provides forward secrecy, and static RSA key transport was removed.
- A later key compromise does not expose past recorded sessions.
Major section
How the Handshake and Records Earn Trust (continued)
The trade-off is concrete: early data is replayable by an attacker who captured it, and it is not forward-secret.
- Most of the handshake after the server's first message is itself encrypted, and the normal handshake completes in a single round trip.
- An optional 0-RTT "early data" mode sends data before that round trip completes, with replay risk.
- Optional faster reconnect, but it is replayable and not forward-secret.
Major section
How the Handshake and Records Earn Trust (continued)
TLS and DTLS protect a single connection hop, between the two endpoints of the transport session.
- In TLS 1.3 it selects an AEAD cipher (such as AES-GCM, AES-CCM, or ChaCha20-Poly1305) and a hash for key derivation and transcript binding; key exchange and authentication are negotiated separately.
- The peer is who the credentials claim, and negotiated parameters are not tampered or downgraded.
- A replayed early-data request triggers a state change.
Major section
How the Handshake and Records Earn Trust (continued)
DTLS 1.3 record processing rejects duplicate sequence numbers (RFC 9147 §4.5.1), while §3.4 describes replay detection as optional; a sliding anti-replay window is a common implementation.
- Naming "AES" says nothing about how keys are agreed or how the peer is authenticated, so a review records the version, suite, key-exchange mode, and authentication method.
- TLS detects replayed or reordered records through implicit sequence numbers bound to record protection (RFC 8446 §5.3; RFC 5246 §6.2.3); TCP also provides ordered delivery.
- Each record is confidential and tamper-evident, rejected before use on tag failure.
Major section
How the Handshake and Records Earn Trust (continued)
Duplicated or out-of-window records are rejected, so old messages cannot be replayed.
- DTLS datagrams may be lost, reordered, or duplicated, so the receiver uses per-record sequence numbers to detect duplicates; a sliding anti-replay window can also reject records that fall outside its acceptance range.
- A replayed datagram is executed as if it were a new command.
- Confusing encryption with authentication: An encrypted connection can still reach the wrong peer.
Major section
How the Handshake and Records Earn Trust (continued)
When enabled, a cookie or return-routability exchange makes a client prove it can receive at its claimed source address before the server commits substantial state or sends large responses.
- None of this makes a state-changing datagram idempotent: if a repeated command would be unsafe, the application still needs command identifiers or a deduplication policy of its own.
- Claiming end-to-end security past a terminating proxy or broker: TLS and DTLS protect a hop; the session terminator reads plaintext.
- Forgetting DTLS replay and DoS handling: Datagrams can be lost, reordered, or duplicated.
Major section
How the Handshake and Records Earn Trust (continued)
Allowing plaintext or weak-version fallback: A failed or blocked handshake must fail closed rather than drop to cleartext or an obsolete version.
- Using 0-RTT early data for state-changing commands: Early data is replayable and not forward-secret, making it unsafe for unlocks, configuration, firmware, or payments.
- A trustworthy review records each guarantee and its negative test, instead of accepting a single "it uses TLS" label.
- Session resumption reduces handshake cost, and TLS 1.3 can carry 0-RTT early data in the client's first flight, before the handshake finishes.
Major section
Compare Stream and Datagram Handshakes Before You Choose · Summary
On one connection hop, TLS and DTLS authenticate the peer, keep the data confidential, and make it tamper-evident; encryption to an unverified peer is not security.
- The handshake authenticates a negotiation transcript, so downgrade or tampering of the negotiated parameters is detected when both sides verify the Finished messages.
- TLS 1.3 (RFC 8446) standard suites use AEAD and no static RSA key transport; ephemeral (EC)DHE provides forward secrecy, but PSK-only mode does not.
- TLS 1.2 (RFC 5246) can be safe when configured with AEAD suites and ephemeral ECDHE.
Deck summary
Key takeaways
Encryption matters only if the right service receives the right reading and a copied message cannot be accepted as new.
- A transport-security review should produce concrete evidence rather than an "encrypted" label.
- The service must authenticate each device with asymmetric credentials.
- Expected name match, scoped trust anchor, chain plus validity plus revocation check, and a wrong-name rejection test.
- The worked decision above makes a bounded claim about one CoAP/DTLS link.
Retrieval practice
Recall check 1 of 3
Shield Shelly says: answer from memory, then check your reasoning.
Q1A sensor uses TLS but accepts any server certificate. Which properties can its encrypted connection still provide, even though it has not authenticated the intended server?
Show answer
Answer: A TLS can protect record confidentiality and integrity on the established connection, but accepting any certificate leaves the peer unverified.
Retrieval practice
Recall check 2 of 3
Shield Shelly says: answer from memory, then check your reasoning.
Q2A device confirms that the server certificate chains to a trusted root and is not expired, but it never checks that the certificate's name matches the server it intended to reach. Why is this still broken authentication?
Show answer
Answer: D A valid, in-date certificate for a different name proves only that some trusted CA issued it.
Retrieval practice
Recall check 3 of 3
Shield Shelly says: answer from memory, then check your reasoning.
Q3An IoT fleet uses a TLS 1.2 profile whose cipher suite performs RSA key transport (the client encrypts the session secret to the server's long-term RSA public key) instead of ephemeral ECDHE. An attacker records the encrypted sessions now. Why is this a forward-secrecy failure?
Show answer
Answer: A Forward secrecy means a future key compromise does not expose past traffic.
Print reference
Answers
Answer key.
- A · TLS can protect record confidentiality and integrity on the established connection, but accepting any certificate leaves the peer unverified.
- D · A valid, in-date certificate for a different name proves only that some trusted CA issued it.
- A · Forward secrecy means a future key compromise does not expose past traffic.