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: 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.
- Explain: 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.
- Explain: Confidentiality (unreadable to outsiders), integrity (changes detectable), authenticity (came from the claimed sender), non-repudiation (the originator cannot deny it), and freshness (old messages rejected) are five separate properties.
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.
- At each level, ask which claimed property is enforced, who can still read or alter plaintext, and which negative test records the proof.
Major section
Map Each Property to Where It Is Enforced (continued)
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.
- Property It Enforces.
- 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)
A tampered command changes state before any check.
- Non-repudiation is evidence that an identified originator approved data in a way a third party can check.
- A message can be confidential, unmodified, and from the right sender, and still be dangerous if it is old.
- A wrong or unknown sender or signer is rejected.
Major section
Mechanisms, Evidence, and Failure Modes (continued)
A digital signature can support this claim when the verification key is bound to one authorized signer and the private key is controlled; the signature alone cannot prove who operated a stolen or shared key.
- 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.
- Any party that answers is trusted as the sender.
Major section
Mechanisms, Evidence, and Failure Modes (continued)
A third party verifies the signer; a MAC cannot bind one party.
- Without ephemeral keys, an attacker who records ciphertext today and steals the long-term key tomorrow can decrypt the recording.
- Availability, that the system keeps working, is a security goal, but cryptography does not provide it by itself.
- A shared-key MAC is claimed as proof of a single originator.
- A replayed or out-of-window message is rejected, with reboot recovery.
Major section
Mechanisms, Evidence, and Failure Modes (continued)
Strong encryption and authentication do not stop a traffic flood, radio jamming, or a battery-exhaustion attack, and a strict fail-closed rejection rule can even be turned into a denial-of-service lever.
- A valid old message is replayed and accepted as new.
- A trustworthy review records the property, the mechanism, the boundary, and the rejection behavior, instead of accepting the word "encrypted" as a whole-system claim.
- A keyed MAC or an AEAD tag delivers both for the data it covers, because only a holder of the key can produce a tag that verifies.
Major section
Summary · Key Takeaway
Confidentiality (unreadable to outsiders), integrity (changes detectable), authenticity (came from the claimed sender), non-repudiation (the originator cannot deny it), and freshness (old messages rejected) are five separate properties.
- "Encrypted" is a confidentiality claim only; integrity and authenticity need an AEAD tag, a keyed MAC, or a signature, and a bare hash provides neither secrecy nor origin.
- Freshness needs a nonce, counter, sequence number, or timestamp window that survives reboot; confidentiality and authenticity do not stop replay.
- The E1-E5 levels show where each property is enforced and evidenced; availability is a goal cryptography alone does not provide.
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.
- 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.
- 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.
Retrieval practice
Recall check 1 of 4
Shield Shelly says: answer from memory, then check your reasoning.
Q1A command path claims integrity and freshness. Which negative test pair supports both claims?
Show answer
Answer: D Tamper rejection tests integrity, while replay rejection tests freshness.
Retrieval practice
Recall check 2 of 4
Shield Shelly says: answer from memory, then check your reasoning.
Q2A vendor says "our telemetry is encrypted, so it is secure." The design uses a confidentiality-only encryption mode, with no authentication tag or anti-replay check. 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 3 of 4
Shield Shelly says: answer from memory, then check your reasoning.
Q3A 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 4 of 4
Shield Shelly says: answer from memory, then check your reasoning.
Q4A 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: A 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 · Tamper rejection tests integrity, while replay rejection tests freshness.
- 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.
- A · An HMAC gives integrity and shared-key authenticity, but both parties hold the same shared key, so either could have produced the tag.