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.

dtlstransport-securitytls-handshake

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

After studying this chapter

Learning objectives

You will be able to:

Explain: DTLS cannot: a datagram may be lost, reordered, or duplicated, so DTLS carries an explicit per-record sequence number and maintains an anti-replay window that rejects duplicates and records that fall outside the window.
Explain: The cookie makes a client prove it can receive at its claimed source address before the server commits state or sends large responses, which resists denial-of-service and amplification from spoofed source addresses.
Explain: 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.

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.

A protocol means shared rules for an exchange.
Transmission Control Protocol (TCP) means a stream that checks order and delivery.
Transport layer security means protection for that stream; it is called TLS.

Choose TLS or DTLS from the transport behavior, then prove peer identity and record protection; a plaintext fallback path is blocked.

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.

The handshake produces evidence: an offered policy, a verified peer identity, a key schedule, a transcript Finished proof, protected records, and a reject path for wrong, old, or replayed messages.

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

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.

The deeper layer explains how each guarantee is built and why each is separate.
A cipher suite is not one algorithm.
Diagnose the problem from cause to corrective action.

Major section

How the Handshake and Records Earn Trust (continued)

Each record is bound to a sequence number, so reordering and replay are detectable.

A connection is only as trustworthy as its handshake, its key agreement, its record protection, and its plaintext boundary.
Over a reliable stream, TLS leaves ordering to the transport.
A later key compromise does not expose past recorded sessions.

Major section

How the Handshake and Records Earn Trust (continued)

The peer is who the credentials claim, and negotiated parameters are not tampered or downgraded.

TLS 1.3 (RFC 8446) modernized this: cipher suites are AEAD-only, forward secrecy is effectively mandatory through ephemeral (EC)DHE, and static RSA key transport was removed.
Most of the handshake after the server's first message is itself encrypted, and the handshake completes in a single round trip.
A replayed early-data request triggers a state change.

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.

Naming "AES" says nothing about how keys are agreed or how the peer is authenticated, which is why a review records the negotiated suite, not just the cipher.
DTLS cannot: a datagram may be lost, reordered, or duplicated, so DTLS carries an explicit per-record sequence number and maintains an anti-replay window that rejects duplicates and records that fall outside the window.
TLS and DTLS protect a single connection hop, between the two endpoints of the transport session.

Major section

How the Handshake and Records Earn Trust (continued)

An impostor is accepted, or parameters are silently downgraded to weak ones.

The cookie makes a client prove it can receive at its claimed source address before the server commits state or sends large responses, which resists denial-of-service and amplification from spoofed source addresses.
Each record is confidential and tamper-evident, rejected before use on tag failure.
Duplicated or out-of-window records are rejected, so old messages cannot be replayed.

Major section

How the Handshake and Records Earn Trust (continued)

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.

A replayed datagram is executed as if it were a new command.
Optional faster reconnect, but it is replayable and not forward-secret.
A trustworthy review records each guarantee and its negative test, instead of accepting a single "it uses TLS" label.

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 vendor says "our sensor uses TLS, so the connection is secure," but the sensor accepts any server certificate. What is the strongest correction?

ATLS is outdated, so the sensor cannot be secure

BEncryption already proves the server's identity, so a certificate check is unnecessary

CTLS gives confidentiality and integrity for the connection.

DThe connection is secure as long as a strong cipher suite is negotiated

Show answer

Answer: C Confidentiality and authentication are separate jobs.

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?

AWithout a name match, a valid cert can identify the wrong server.

BThe trusted root and valid dates already establish that the certificate belongs to an approved server

CName matching only matters for web browsers, not for IoT devices

DEncryption still works, so authentication is fine

Show answer

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

AA sufficiently long RSA key makes recovering the recorded session secrets computationally impractical

BThere is no problem, because each session still uses a different symmetric key

CSwitching to a longer symmetric key such as AES-256 restores forward secrecy

DThe session secret is protected only by the server's long-term RSA key.

Show answer

Answer: D Forward secrecy means a future key compromise does not expose past traffic.

Print reference

Answers

Answer key.

C · Confidentiality and authentication are separate jobs.
A · A valid, in-date certificate for a different name proves only that some trusted CA issued it.
D · Forward secrecy means a future key compromise does not expose past traffic.