Chapter 15 — Security fundamentals

Chapter 15 — Security fundamentals

Lesson map

Lesson 15 published. Map, example, EX043.

flowchart TD
  N0["Learning outcomes"]
  N1["15.1 The three properties"]
  N2["15.2 Threat models"]
  N3["15.3 Authentication and authorisation"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4
  N4 --> EX["Worked example"]
  EX --> Q["Exercise EX043"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["15.1 The three properties"]
  N2["15.2 Threat models"]
  N3["15.3 Authentication and authorisation"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX043"]

[Learning outcomes]
    |
    v
[15.1 The three properties]
    |
    v
[15.2 Threat models]
    |
    v
[15.3 Authentication and authorisation]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX043]

Learning outcomes

You will (1) map confidentiality, integrity and availability to cryptographic controls; (2) define threat models; (3) distinguish authentication from authorisation.

15.1 The three properties

Security is often described through confidentiality, integrity and availability. Aiyana maps each to Ridgeway's meters. Confidentiality of readings matters because consumption patterns reveal when homes are empty. Integrity matters because altered readings change bills. Availability matters because the utility needs readings to detect leaks. Cryptography mainly serves confidentiality and integrity: encryption for the first, authentication codes and signatures for the second. It can harm availability if keys are lost or certificates expire, which is why key management and operations are as important as algorithms.

15.2 Threat models

A threat model states who the attackers are, what they want, what they can do and what is out of scope. Aiyana writes one for meters: a curious neighbour with a radio receiver, a customer trying to lower a bill, a criminal group seeking to disrupt supply and a malicious insider. She sets nation-state hardware attacks out of scope for the pilot, stating that explicitly. Katz and Lindell insist that every security definition depends on an explicit attacker model; without one, claims such as "secure" have no meaning.

15.3 Authentication and authorisation

Authentication establishes who or what is communicating; authorisation decides what that party may do. A meter authenticates with its per-meter key, but it is authorised only to submit its own readings, not those of other meters or configuration changes. Aiyana finds a design draft where any authenticated meter could submit readings for any identifier, a classic confusion of the two. She adds a check binding each key to one meter identifier. Cryptography provides authentication; authorisation is a policy decision implemented in application logic.

Worked example

Aiyana maps CIA properties to meter controls, writes a four-attacker threat model with an explicit exclusion, and fixes a design where authentication did not imply correct authorisation.

Synthetic case. The threat model is invented.

Errors and limits

Threat models age; revisit them when systems change. Strong authentication with weak authorisation still allows abuse.

Exercises

• EX043 — Why confidentiality. Why does meter reading confidentiality matter? Rubric: 3 = consumption patterns reveal when homes are empty;; 2 = privacy;; 1 = no reason;; 0 = none.
• EX044 — Out of scope. What did Aiyana place out of scope and why state it? Rubric: 3 = nation-state hardware attacks; explicit scope makes claims meaningful;; 2 = scope stated;; 1 = vague;; 0 = none.
• EX045 — Authorisation fix. What check fixed the authorisation flaw? Rubric: 3 = binding each key to one meter identifier so meters submit only their own readings;; 2 = binding;; 1 = encryption;; 0 = none.

Synthesis

Security fundamentals frame cryptography: map it to explicit properties and attacker models, and keep authentication separate from authorisation.

Continue studying — chapter 15 of 50

← Chapter 14 (draft) · Course chapter index · Chapter 16 (draft) →