Chapter 3 — Physics for computing
Lesson map
Lesson 03 published. Map, example, EX007.
flowchart TD
N0["Learning outcomes"]
N1["3.1 Information is physical"]
N2["3.2 Power, timing and emissions"]
N3["Synthesis"]
N0 --> N1 --> N2 --> N3
N3 --> EX["Worked example"]
EX --> Q["Exercise EX007"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["3.1 Information is physical"]
N2["3.2 Power, timing and emissions"]
N3["Synthesis"]
N0 --> N1 --> N2 --> N3 --> Q["EX007"]
[Learning outcomes]
|
v
[3.1 Information is physical]
|
v
[3.2 Power, timing and emissions]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX007]
Learning outcomes
You will (1) relate physical phenomena to hardware security risks; (2) explain why emanations and power use can leak information; (3) connect physical limits to architecture choices.
3.1 Information is physical
Sofia's physics module covers electricity, signals and heat. Daniel connects it to security: computers are physical devices, so computation produces measurable effects such as power variation, electromagnetic emission, timing differences and heat. Anderson (2020) describes how such side channels have leaked keys and data. For an architect, the lesson is not to build measurement rigs but to recognise where physical access or proximity creates risk, such as fare-card readers mounted on public buses where an attacker can touch, open or attach instruments to the device for hours without being noticed by staff.
3.2 Power, timing and emissions
Power consumption varies with the operations a chip performs. If a device's power use depends on secret data, an attacker measuring it can sometimes recover the secret; this is called power analysis. Timing works similarly in software, which is why constant-time comparisons are used for secrets. Electromagnetic emissions from cables and screens can carry signals too. Sofia learns that defending against these is mainly a job for hardware designers and certified secure elements, and that an architect's responsibility is to choose components evaluated against such attacks for places where attackers have physical access.
3.3 Physical limits in architecture
Physics also sets limits that architects must respect. Signal propagation and network latency mean a tram's fare validator cannot always reach the central server in time, so it must make some decisions offline with locally stored keys and deny lists. Batteries and heat limit how much cryptographic work a handheld inspector device can do. Physical tamper resistance costs money and size. Sofia writes a short note for Daniel explaining that fare validators should use secure elements for keys and should be designed to work offline safely, because physics, not preference, forces that design.
Worked example
Sofia lists three physical side channels, maps them to Corvia's on-vehicle fare readers and argues for secure elements and safe offline operation.
Synthetic case. Device placements and design notes are synthetic; Anderson (2020) is real.
Errors and limits
Side-channel risk depends on attacker access and skill; not every device needs the same protection. Physics limits change as hardware improves.
Exercises
- EX007 — Physical access risk. Why are on-bus fare readers more exposed to side channels than data-centre servers? Rubric: 3 = attackers can touch and instrument them for long periods in public;; 2 = access;; 1 = same risk;; 0 = none.
- EX008 — Architect role. What is the architect's responsibility regarding power analysis? Rubric: 3 = choose components evaluated against it where physical access exists;; 2 = choose components;; 1 = build rigs;; 0 = none.
- EX009 — Offline by physics. Why must fare validators make some decisions offline? Rubric: 3 = latency and connectivity limits mean the server may be unreachable in time;; 2 = latency;; 1 = preference;; 0 = none.
Synthesis
Physics shapes both the threats to devices and the constraints on secure architecture designs.
Continue studying — chapter 03 of 50
← Chapter 02 (draft) · Course chapter index · Chapter 04 (draft) →