Chapter 8 — Computer architecture | Engineering Human factors and cyber policy

Open, free learning for anyone who wants to protect people and technology. No account is required to read this text or its worked answers.

Chapter 8 — Computer architecture

Lesson map

Lesson 08 published. Map, example, EX022.

flowchart TD
  N0["Learning outcomes"]
  N1["8.1 Hardware users meet"]
  N2["8.2 Design and decisions"]
  N3["Synthesis"]
  N0 --> N1 --> N2 --> N3
  N3 --> EX["Worked example"]
  EX --> Q["Exercise EX022"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["8.1 Hardware users meet"]
  N2["8.2 Design and decisions"]
  N3["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> Q["EX022"]

[Learning outcomes]
    |
    v
[8.1 Hardware users meet]
    |
    v
[8.2 Design and decisions]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX022]

Learning outcomes

You will (1) relate hardware design to user security decisions; (2) understand secure hardware features users meet; (3) evaluate how design affects usable security.

8.1 Hardware users meet

Aiko studies how hardware shapes what users see. Laptops with a trusted platform module can store keys so that disk encryption unlocks automatically with a PIN; security keys contain small secure chips that perform authentication without revealing secrets. Users do not see the chips, but they experience the result: fewer passwords and simpler steps. Engineering hardware so that the secure path is also the easiest path is a central idea in usable security, echoing Sasse, Brostoff and Weirich (2001). She lists the features found on Greyford's laptops.

8.2 Design and decisions

Aiko compares two ways Greyford could protect field laptops. One asks users for a long separate disk password at start-up; the other uses the trusted platform module with a short PIN. Interviews with engineers show they would write the long password on the laptop. The hardware-backed option gives similar protection against a stolen laptop while removing the temptation. She notes that good hardware design reduces the number of security decisions users must make correctly. She presents both options to the IT manager with the interview evidence, and the hardware-backed design is chosen for the next laptop refresh.

8.3 Limits

Hardware features do not solve everything. Security keys can be lost, and replacement must be quick or staff will be locked out during urgent work. Firmware needs updates, which users may postpone if updates interrupt work. Aiko writes requirements: spare keys at depots, updates scheduled outside shifts and a clear recovery process. Hardware supports usable security only when the surrounding processes are designed for real working conditions. She also notes that staff need simple instructions for first use, because a confusing first experience with a security key can create lasting resistance, and she drafts a one-page guide with pictures for depots.

Worked example

Aiko links secure hardware to simpler user steps, compares two laptop protection designs and writes supporting process requirements.

Synthetic case. Designs and interviews are synthetic; Sasse et al. (2001) is real.

Errors and limits

Hardware features vary by model. Recovery processes can become an attack path.

Exercises

EX022 — Invisible chips. How do users experience secure hardware? Rubric: 3 = fewer passwords and simpler steps;; 2 = simpler;; 1 = vague;; 0 = none.
EX023 — Laptop choice. Why prefer the hardware-backed PIN for field laptops? Rubric: 3 = similar protection without engineers writing passwords on laptops;; 2 = usability;; 1 = vague;; 0 = none.
EX024 — Key loss requirement. What process requirement addresses lost security keys? Rubric: 3 = spare keys at depots and quick recovery;; 2 = spares;; 1 = vague;; 0 = none.

Synthesis

Hardware can make the secure path the easy path, if recovery and updates fit real work.

Continue studying — chapter 08 of 50

← Chapter 07 (draft) · Course chapter index · Chapter 09 (draft) →