4 Core Security Properties
Confidentiality, Integrity, Authenticity, Non-Repudiation, and Freshness
IoT security properties, confidentiality vs integrity, data-origin authentication, non-repudiation, anti-replay freshness, forward secrecy, evidence levels
4.1 Start With the Promise You Can Test
Imagine a smart lock report that says the command path is “secure.” That word is too broad to test. A reviewer has to split it into promises: who can read the command, who can change it, who is allowed to send it, whether an auditor can verify the release authority, and whether yesterday’s valid packet is rejected today.
This chapter keeps those promises separate. Each property gets its own boundary, mechanism, and negative test, so “encrypted” never stands in for integrity, authenticity, non-repudiation, freshness, or availability.
Security Properties Are Promises You Must Prove
A security property is a specific claim about what a system protects, not a vocabulary word. The most common mistake is to say a device is "secure" or "encrypted" and assume every protection is now in place. The first question is never which algorithm. It is which exact property you are claiming, because the properties do not come bundled.
Five properties cover most IoT needs. Confidentiality keeps data unreadable to anyone unauthorized. Integrity lets the receiver detect any change. Authenticity proves the data came from the claimed sender. Non-repudiation means the originator cannot later deny it, and a third party can verify that. Freshness stops an old valid message from being replayed.
If you only need the intuition, this layer is enough: name the exact property you are claiming, remember the properties are independent, and ask for the test that would fail if the property were missing. "Encrypted" is a confidentiality claim, and nothing more.
Think of a sealed, signed letter. A sealed opaque envelope keeps the contents private (confidentiality). A tamper-evident seal shows whether anyone opened it (integrity). A handwritten signature shows who wrote it (authenticity). A notary stamp a third party can check later means the writer cannot deny writing it (non-repudiation). A dated reference number stops the same letter being re-delivered as if new (freshness). One feature never does all five jobs, so a real design adds each on purpose.
In an IoT deployment, those differences become operational decisions. A smart-meter reading may be confidential because it reveals household behavior, but the utility also needs integrity so the value cannot be changed, authenticity so a rogue node cannot submit readings, and freshness so yesterday's packet is not billed again. A firmware approval record may not need secrecy at all, yet it may need non-repudiation because an auditor must verify which release authority signed it months later. Treat each property as a separate acceptance claim.
The One-Minute View
Each property is a separate promise
Confidentiality, integrity, authenticity, non-repudiation, and freshness are independent. A control that delivers one rarely delivers the rest.
Encrypted is not authenticated
The most common false claim. Encryption hides content; it does not show the message is unchanged or that it came from the expected sender.
A property needs a rejection test
A property is only proven when the matching bad case fails closed: tampering rejected, replay rejected, wrong sender rejected.
Beginner Examples
- A device that encrypts telemetry but cannot detect a changed message has confidentiality without integrity.
- A signed firmware image proves who built it and lets anyone verify that, yet it is still readable by anyone who downloads it. A signature is authenticity, not secrecy.
- A command that is confidential, unmodified, and from the right sender can still be dangerous if it is yesterday's unlock replayed tonight. Authenticity without freshness still allows replay.
Overview Knowledge Check
If you can name the five properties and explain why "encrypted" is only a confidentiality claim, you can stop here. Continue to Practitioner to map each property to where it is enforced and proven.
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. 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.
Walkthrough: From Claimed Property to Recorded Evidence
- Name the asset and the exact property. State what is protected (a command, telemetry, a firmware image) and which property is claimed: confidentiality, integrity, authenticity, non-repudiation, or freshness.
- Locate the boundary and evidence level. Decide where the property must hold and which E1-E5 level enforces it, so you know where plaintext appears and where identity is checked.
- Bind the property to a mechanism. Encryption for confidentiality, an AEAD tag or keyed MAC for integrity, a MAC or signature for authenticity, a signature for non-repudiation, a counter or nonce for freshness.
- Run the matching negative test. A property is unproven until the failing case is rejected: a modified message, a replayed message, a wrong or unknown sender, an expired credential.
- Record redacted evidence and lifecycle. Keep proof of the rejection behavior and the key lifecycle without publishing raw keys or sensitive plaintext.
The E1-E5 Property Map
Worked Review: A Smart-Lock Command Channel
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. The reviewer turns that statement into property questions.
What the claim covers
Encryption can hide the command body from an observer on the link or at the broker. That supports a confidentiality claim for the payload.
What the claim misses
It says nothing about whether a modified command is rejected (integrity), whether only the authorized controller may send it (authenticity), or whether last night's captured unlock can be replayed (freshness).
Conclusion
Accept only the confidentiality claim. Require an authenticated mechanism that rejects tampered commands, binds the sender identity at E2 or E4, and adds a counter or nonce so a replayed unlock fails. For a physical-action command, confidentiality alone is the weakest property to rely on.
Practitioner Knowledge Check
If you can match each property to a mechanism and an E1-E5 boundary and scope a claim to the evidence, you can stop here. Continue to Under the Hood for the mechanisms, how each property is evidenced, and the failure modes.
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: Who Can Read the Plaintext
Confidentiality means unauthorized parties cannot learn protected content. 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. 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 Versus Authenticity
These two are constantly merged but make different promises. 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. 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. 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.
Non-Repudiation Needs a Signature
Non-repudiation means the originator cannot later deny producing the data, and a third party can verify that. A shared-key MAC cannot provide it: because both the sender and the receiver hold the same key, either of them could have produced any valid tag, so neither can prove to an outsider which one did. Only a digital signature, where one party holds a private key and everyone else holds the matching public key, binds the data to a single originator in a way a third party can check. This is why firmware-release authority and audit trails rest on signatures, not on MACs.
Freshness and Anti-Replay
A message can be confidential, unmodified, and from the right sender, and still be dangerous if it is old. Freshness rejects a replayed valid message. 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.
Forward Secrecy
Forward secrecy is a property of key establishment, not of the bulk cipher. When each session derives its traffic keys from a fresh ephemeral key agreement (ephemeral Diffie-Hellman or its elliptic-curve form, DHE or ECDHE) and erases them afterward, a later compromise of a long-term identity key does not reveal traffic captured earlier. Without ephemeral keys, an attacker who records ciphertext today and steals the long-term key tomorrow can decrypt the recording.
Availability Is a Goal Cryptography Does Not Guarantee
Availability, that the system keeps working, is a security goal, but cryptography does not provide it by itself. 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. Availability needs rate limits, redundancy, and monitoring as separate controls; a property review should not credit cryptography with it.
Property, Mechanism, and Failure Mode
Common Pitfalls
- Treating "encrypted" as "authenticated." Confidentiality hides content; it does not detect tampering or prove the sender. Use an authenticated mechanism and test that modified data is rejected.
- Treating a bare hash as proof of origin. Anyone can recompute a hash, so it needs a key (MAC) or a signature before it proves integrity and authenticity.
- Claiming non-repudiation from a shared-key MAC. Both parties hold the key, so a MAC cannot bind the data to a single originator. Non-repudiation needs a signature.
- Forgetting freshness. An authenticated message can still be replayed without a counter, sequence number, or replay window, and that state must survive reboot.
- Confusing transport security with end-to-end ownership. An E4 transport session protects its endpoints; it does not keep the payload opaque to a gateway or service that terminates the session, which is an E3 claim.
Under-the-Hood Knowledge Check
At this depth, a security-property review is a set of independent guarantees: confidentiality for who may read, integrity for what may change, authenticity for who sent it, non-repudiation for who cannot deny it, and freshness for whether it is current, each enforced at a named E1-E5 boundary and each backed by a test that fails closed. 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.
4.2 Summary
- Security properties are specific, testable claims, not a single “secure” label: name the exact property before approving it.
- 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.
- Non-repudiation requires a digital signature; a shared-key MAC cannot provide it because both parties hold the key.
- Freshness needs a nonce, counter, sequence number, or timestamp window that survives reboot; confidentiality and authenticity do not stop replay.
- Forward secrecy comes from ephemeral key agreement, so a later long-term-key loss does not expose earlier captured traffic.
- The E1-E5 levels show where each property is enforced and evidenced; availability is a goal cryptography alone does not provide.
- Every property claim needs a matching negative test (tamper, replay, wrong peer, expiry) and redacted evidence, not a happy-path demo.
Never call a system “secure” without naming the property. Each of confidentiality, integrity, authenticity, non-repudiation, and freshness needs its own mechanism, a named E1-E5 boundary where it is enforced, and a negative test that fails closed. “Encrypted” proves confidentiality and nothing else.
4.3 See Also
Encryption Principles & Crypto Basics
Revisit the primitive roles, encryption, hash, MAC, signature, and KDF, that each property is built from.
See how signatures deliver authenticity and non-repudiation and how ephemeral key agreement gives forward secrecy.
Watch transport identity, integrity, and freshness enforced together in a real protocol profile.
Encryption Architecture & Levels
Place each property at the right E1-E5 boundary and decide where it is established and where it stops.