Chapter 8 — Computer architecture | Engineering Privacy and data protection

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 Data in many places"]
  N2["8.2 Isolation"]
  N3["8.3 Trusted hardware for keys"]
  N4["8.4 Performance trade-offs"]
  N5["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5
  N5 --> EX["Worked example"]
  EX --> Q["Exercise EX022"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["8.1 Data in many places"]
  N2["8.2 Isolation"]
  N3["8.3 Trusted hardware for keys"]
  N4["8.4 Performance trade-offs"]
  N5["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX022"]

[Learning outcomes]
    |
    v
[8.1 Data in many places]
    |
    v
[8.2 Isolation]
    |
    v
[8.3 Trusted hardware for keys]
    |
    v
[8.4 Performance trade-offs]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX022]

Learning outcomes

You will (1) trace where data sit in memory and caches; (2) understand hardware isolation; (3) assess hardware features for protecting health data.

8.1 Data in many places

In computer architecture Zara follows a patient record through a server. It sits on disk, is copied into memory, passes through processor caches and may be written to swap space. Each copy is a place where data can persist or leak. She realises that an application that carefully deletes records may still leave fragments in memory dumps or swap files. For Pellmore she recommends encrypted swap and disabling crash dumps that include memory on production servers, unless a dump is explicitly requested and handled under a defined procedure.

8.2 Isolation

Architecture provides isolation: processes cannot normally read each other's memory, and virtual machines are separated by a hypervisor. Zara learns that hardware flaws have sometimes broken these boundaries, so cloud tenants share risk with neighbours. For Pellmore's records system she reads the cloud provider's documentation on dedicated hosts and confidential computing, which encrypts memory in use. She notes that such features reduce risk but add cost and complexity, and that the choice should follow a risk assessment rather than a vendor brochure.

8.3 Trusted hardware for keys

Hardware security modules and secure enclaves keep cryptographic keys away from ordinary memory. Zara links this to Chapter 3: if Pellmore uses cryptographic erasure for videos, the keys are the most valuable asset, and storing them in a hardware module makes accidental copying much harder. She sketches a design where each month of recordings has its own key, kept in the module, and deleting a month's key erases that month. The design turns retention enforcement into a simple, auditable key operation. Auditors can check key deletion logs.

8.4 Performance trade-offs

Encryption and isolation cost processor time. Zara measures that encrypting video at rest adds little load on modern processors with hardware acceleration. She records the measurement in her decision log, because the claim that privacy measures are too slow often blocks good designs without evidence. Prof. Holm reminds her that measurements should be repeated on Pellmore's actual workload, but her first figures are enough to move the conversation from opinion to data, which is a recurring goal in her engineering training. Encryption adds measurable latency.

Worked example

Zara maps copies of a record from disk to cache, recommends encrypted swap, considers confidential computing and designs monthly keys in a hardware module for cryptographic erasure.

Synthetic case. Pellmore's servers are synthetic.

Errors and limits

Hardware features have their own flaws; defence in depth still matters.

Exercises

EX022 — Hidden copies. Name two places where a deleted record may persist in a server. Rubric: 3 = memory dumps and swap (also caches);; 2 = names one;; 1 = vague;; 0 = none.
EX023 — Monthly keys. How do monthly keys make retention auditable? Rubric: 3 = deleting a month's key erases that month's recordings in one operation;; 2 = mentions keys;; 1 = omits;; 0 = none.
EX024 — Evidence over opinion. Why measure encryption overhead? Rubric: 3 = to replace claims that privacy is too slow with data;; 2 = mentions speed;; 1 = skips it;; 0 = none.

Synthesis

Chapter 8 places data in hardware. Chapter 9 advances programming.

Continue studying — chapter 08 of 50

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