Chapter 15 — Security fundamentals

Chapter 15 — Security fundamentals

Lesson map

Lesson 15 published. Map, example, EX043.

flowchart TD
  N0["Learning outcomes"]
  N1["15.1 CIA for ledgers"]
  N2["15.2 Weakness classes"]
  N3["15.3 Defender's mindset"]
  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 CIA for ledgers"]
  N2["15.2 Weakness classes"]
  N3["15.3 Defender's mindset"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX043"]

[Learning outcomes]
    |
    v
[15.1 CIA for ledgers]
    |
    v
[15.2 Weakness classes]
    |
    v
[15.3 Defender's mindset]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX043]

Learning outcomes

You will (1) apply confidentiality, integrity and availability to ledgers; (2) describe common contract weakness classes; (3) think like a defender.

15.1 CIA for ledgers

Jonas applies the classic security goals. Integrity matters most for balances: credits must not be created, lost or moved without authority. Availability matters because members need to use credits when bills are due. Confidentiality matters for household data kept off-chain. He notes that blockchains strengthen integrity through replication and consensus, but can weaken confidentiality because shared data is visible to all nodes. Balancing these goals shapes the design decisions in later chapters. He writes one sentence per goal explaining how the platform will meet it, which the board reads before approving design work.

15.2 Weakness classes

Jonas studies weakness classes from the SWC registry and the OWASP Smart Contract Top 10, including access control flaws, re-entrancy where an external call lets code be entered again before state is updated, unchecked external call results, arithmetic and rounding errors, and reliance on manipulable price data. Atzei and colleagues (2017) organise similar weaknesses by their cause. He studies each from the defender's side: what the weakness is, why it occurs, and which design patterns and review checks prevent it.

Re-entrancy, for example, is prevented by updating state before any external call, a check a reviewer can confirm line by line.

15.3 Defender's mindset

Thinking like a defender means asking what could go wrong for each function and who could cause it, intentionally or by mistake. Jonas practises with the cooperative's planned transfer function: what if amounts are zero, larger than balances, or sent to the contract itself; what if the function is called twice at once; what if an administrator key is lost. Each question becomes a requirement or test. The aim is to find problems on paper and in tests before anyone else finds them in production.

Worked example

Jonas maps integrity, availability and confidentiality to the ledger, studies five weakness classes from public registries, and turns failure questions into requirements.

Synthetic case. Functions and questions are synthetic; the SWC registry, OWASP Smart Contract Top 10 and Atzei et al. (2017) are real sources.

Errors and limits

Learning weaknesses as attack recipes rather than as design failures to prevent misdirects defensive effort.

Exercises

• EX043 — Most important goal. Which goal matters most for balances? Rubric: 3 = integrity;; 2 = correctness;; 1 = confidentiality;; 0 = none.
• EX044 — Ledger weakness. Which goal can blockchains weaken? Rubric: 3 = confidentiality;; 2 = privacy;; 1 = integrity;; 0 = none.
• EX045 — Re-entrancy meaning. What is re-entrancy? Rubric: 3 = an external call lets code be entered again before state is updated;; 2 = re-entry;; 1 = overflow;; 0 = none.

Synthesis

Security goals, weakness classes and a defender's questions provide the foundation for contract security.

Continue studying — chapter 15 of 50

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