Chapter 12 — Operating systems
Lesson map
Lesson 12 published. Map, example, EX034.
flowchart TD
N0["Learning outcomes"]
N1["12.1 Processes and memory"]
N2["12.2 The OS random generator"]
N3["12.3 Least privilege"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Worked example"]
EX --> Q["Exercise EX034"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["12.1 Processes and memory"]
N2["12.2 The OS random generator"]
N3["12.3 Least privilege"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX034"]
[Learning outcomes]
|
v
[12.1 Processes and memory]
|
v
[12.2 The OS random generator]
|
v
[12.3 Least privilege]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX034]
Learning outcomes
You will (1) explain how operating systems protect keys in memory and on disk; (2) use the OS random generator correctly; (3) apply least privilege to cryptographic services.
12.1 Processes and memory
An operating system separates processes so that one cannot read another's memory. Ridgeway's key service runs as its own process under a dedicated account; the billing application asks it to compute tags rather than holding keys itself. Aiyana learns that a key in a process's memory may also end up in swap files or crash dumps, so the service disables core dumps and locks key pages in memory where the platform allows. These operating-system details matter as much as the algorithm, because most real key thefts read keys from memory or disk, not by breaking cryptography.
12.2 The OS random generator
The operating system gathers entropy from hardware events and exposes a cryptographically secure generator to programs, on Linux through the getrandom system call. Python's secrets module uses it. Aiyana compares secrets.token_bytes with the random module, which is a fast, predictable generator meant for simulations; its outputs can be reconstructed after observing enough values. She rewrites a teammate's key-generation script that used random.getrandbits. The rule she adopts is simple: anything secret, including keys, nonces and tokens, comes from secrets or a vetted library, never from random.
12.3 Least privilege
Aiyana configures the key service to run with the minimum rights it needs: read access to its own encrypted key file, a single listening socket, and no shell. File permissions restrict the key file to the service account. Administrators access the service through an audited interface rather than logging into the host. SP 800-57 Part 1 stresses protecting keys throughout their lifecycle, and least privilege at the operating-system level is a large part of that protection. If the billing application is compromised, the attacker still cannot read raw keys.
Worked example
Aiyana moves keys into a dedicated service process with locked memory, no core dumps, minimal file permissions, and secrets-based generation.
Synthetic case. The key service is invented; SP 800-57 Part 1 is real.
Errors and limits
Memory locking and dump suppression are platform-dependent and imperfect. A privileged attacker on the host can still read memory, so isolation reduces rather than removes risk.
Exercises
- EX034 — Swap and dumps. Why disable core dumps for the key service? Rubric: 3 = keys in memory could be written to dumps or swap and stolen from disk;; 2 = disk leak;; 1 = performance;; 0 = none.
- EX035 — random versus secrets. Why must keys never come from Python's random module? Rubric: 3 = it is predictable and reconstructible; secrets uses the OS CSPRNG;; 2 = predictable;; 1 = slower;; 0 = none.
- EX036 — Compromised billing app. What can an attacker who compromises the billing application not do? Rubric: 3 = read raw keys, since the separate key service holds them under least privilege;; 2 = limited;; 1 = everything;; 0 = none.
Synthesis
Operating-system isolation, secure randomness and least privilege protect keys where most real thefts happen: in memory and on disk.
Continue studying — chapter 12 of 50
← Chapter 11 (draft) · Course chapter index · Chapter 13 (draft) →