Cryptography · Study deck
Core Security Properties
A smart lock receives an Open command.
Shield Shelly is your guide for this deck.
After studying this chapter
Learning objectives
You will be able to:
- Explain: E1 protects a local link, E2 extends protection to a trusted gateway, E3 keeps selected payloads protected to their application endpoint, E4 authenticates and protects a transport session, and E5 governs keys across their lifecycle.
- Explain: A bare hash, such as SHA-256 on its own, delivers neither origin nor secrecy: anyone can recompute it over modified data, so an attacker who changes the message can also recompute a matching hash.
- Explain: Each property is an independent guarantee with its own mechanism, and a weakness in one does not show up in a test for another.
Major section
Start With the Promise You Can Test · Security Properties Are Promises You Must Prove
A smart lock receives an Open command.
- The owner may want outsiders unable to read it, any change detected, the sender checked, and an old valid command refused.
- Hiding the command does not prove who sent it or whether someone has sent yesterday's command again.
Major section
Map Each Property to Where It Is Enforced
A property review turns a claim into evidence: it names the property, locates the boundary where it must hold, binds it to a mechanism, and proves it with a negative test.
- The workflow above becomes concrete only when each property is placed at a system boundary.
- Property It Enforces.
Major section
Map Each Property to Where It Is Enforced (continued)
At each level, ask which claimed property is enforced, who can still read or alter plaintext, and which negative test records the proof.
- This module organizes IoT protection into evidence levels E1 through E5, so a property review always asks not just which property but where it is established and where it stops.
- Per-device key scope, tamper rejection, and replay-window tests.
- Protection from a gateway that is allowed to decrypt.
Major section
Map Each Property to Where It Is Enforced (continued)
E1 protects a local link, E2 extends protection to a trusted gateway, E3 keeps selected payloads protected to their application endpoint, E4 authenticates and protects a transport session, and E5 governs keys across their lifecycle.
- A smart lock accepts an unlock command from a controller through a gateway.
- The team proposes "the unlock command is encrypted end to end" as the control.
- That supports a confidentiality claim for the payload.
Major section
Mechanisms, Evidence, and Failure Modes
The deeper layer explains how each property is delivered, how it is evidenced, and how it fails.
- Each property is an independent guarantee with its own mechanism, and a weakness in one does not show up in a test for another.
- Confidentiality means unauthorized parties cannot learn protected content.
- Freshness rejects a replayed valid message.
Major section
Mechanisms, Evidence, and Failure Modes (continued)
Encryption provides it, but only across the boundary where it is applied.
- A link-layer frame can be encrypted while the gateway still sees plaintext; a transport session can protect device-to-cloud bytes while the cloud stores decrypted payloads.
- These two are constantly merged but make different promises.
- Non-repudiation needs a signature.
Major section
Mechanisms, Evidence, and Failure Modes (continued)
The review question is not "is it encrypted" but "who holds plaintext at each hop," which is why confidentiality is evidenced with a plaintext-owner map rather than an algorithm name.
- Integrity means any modification is detectable: the receiver can tell the bytes changed.
- Authenticity (data-origin authentication) means the data provably came from the claimed sender.
- Unauthorized reader or intermediary sees only ciphertext and approved metadata.
Major section
Mechanisms, Evidence, and Failure Modes (continued)
Plaintext leaks at a gateway, log, or support bundle.
- A bare hash, such as SHA-256 on its own, delivers neither origin nor secrecy: anyone can recompute it over modified data, so an attacker who changes the message can also recompute a matching hash.
- A hash becomes an integrity-and-authenticity control only once it is carried inside a MAC or a signature.
- A modified message is rejected before the device acts.
Major section
Mechanisms, Evidence, and Failure Modes (continued)
Without ephemeral keys, an attacker who records ciphertext today and steals the long-term key tomorrow can decrypt the recording.
- A message can be confidential, unmodified, and from the right sender, and still be dangerous if it is old.
- A tampered command changes state before any check.
- A wrong or unknown sender or signer is rejected.
Major section
Mechanisms, Evidence, and Failure Modes (continued)
Any party that answers is trusted as the sender.
- The usual inputs are nonces, monotonic counters, sequence numbers, and timestamps with an acceptance window, each bound into the authenticated data so it cannot be altered.
- Freshness also needs a recovery rule: the counter or window state must survive reboot, and a device that resets must not start accepting old messages again.
- A third party verifies the signer; a MAC cannot bind one party.
Major section
Mechanisms, Evidence, and Failure Modes (continued)
A shared-key MAC is claimed as proof of a single originator.
- Availability, that the system keeps working, is a security goal, but cryptography does not provide it by itself.
- A replayed or out-of-window message is rejected, with reboot recovery.
- A valid old message is replayed and accepted as new.
Deck summary
Key takeaways
A smart lock receives an Open command.
- A property review turns a claim into evidence: it names the property, locates the boundary where it must hold, binds it to a mechanism, and proves it with a negative test.
- At each level, ask which claimed property is enforced, who can still read or alter plaintext, and which negative test records the proof.
- E1 protects a local link, E2 extends protection to a trusted gateway, E3 keeps selected payloads protected to their application endpoint, E4 authenticates and protects a transport session, and E5 governs keys across their lifecycle.
- Encryption provides it, but only across the boundary where it is applied.
Retrieval practice
Recall check 1 of 3
Shield Shelly says: answer from memory, then check your reasoning.
Q1A vendor says "our telemetry is encrypted, so it is secure." What is the strongest correction?
Show answer
Answer: D Encryption keeps content unreadable, but it does not by itself reject tampering, prove the sender, support denial-resistant third-party proof, or reject replay.
Retrieval practice
Recall check 2 of 3
Shield Shelly says: answer from memory, then check your reasoning.
Q2A design encrypts telemetry on the local link (E1) and again on the gateway-to-cloud transport (E4), but the gateway decrypts and logs the sensitive fields. The team claims end-to-end confidentiality. What is the evidence-bound conclusion?
Show answer
Answer: A Confidentiality is about who can read plaintext at each hop.
Retrieval practice
Recall check 3 of 3
Shield Shelly says: answer from memory, then check your reasoning.
Q3A team protects firmware-approval messages with a shared-key HMAC and claims this proves to an auditor exactly which party approved each release (non-repudiation). Why is this claim wrong?
Show answer
Answer: B An HMAC gives integrity and shared-key authenticity, but both parties hold the same shared key, so either could have produced the tag.
Print reference
Answers
Answer key.
- D · Encryption keeps content unreadable, but it does not by itself reject tampering, prove the sender, support denial-resistant third-party proof, or reject replay.
- A · Confidentiality is about who can read plaintext at each hop.
- B · An HMAC gives integrity and shared-key authenticity, but both parties hold the same shared key, so either could have produced the tag.