Chapter 11 — Operating systems
Lesson map
Lesson 11 published. Map, example, EX021.
flowchart TD
N0["Learning outcomes"]
N1["11.1 Isolation and privilege"]
N2["11.2 Cryptographic providers"]
N3["11.3 Updates and boot"]
N4["11.5 Practical activity"]
N5["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5
N5 --> EX["Worked example"]
EX --> Q["Exercise EX021"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["11.1 Isolation and privilege"]
N2["11.2 Cryptographic providers"]
N3["11.3 Updates and boot"]
N4["11.5 Practical activity"]
N5["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX021"]
[Learning outcomes]
|
v
[11.1 Isolation and privilege]
|
v
[11.2 Cryptographic providers]
|
v
[11.3 Updates and boot]
|
v
[11.5 Practical activity]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX021]
Learning outcomes
You will (1) describe processes, memory isolation, file permissions and system services; (2) explain how operating systems provide cryptographic services and key storage; (3) identify OS-level dependencies that control a migration; and (4) reason about update channels and their signatures.
11.1 Isolation and privilege
An operating system isolates processes in separate address spaces, enforces file permissions and grants privileges to users and services. Keys stored in a world-readable file defeat all of this; keys held by a privileged service, or by hardware such as a TPM, are reachable only through defined interfaces. Least privilege — giving each component only the access it needs — applies to cryptographic material as much as to files.
HCU's inventory therefore records where each key lives as well as which algorithm it uses.
11.2 Cryptographic providers
Applications rarely implement cryptography themselves. They call a provider: OpenSSL providers on Linux, the CNG framework on Windows, platform keystores on mobile systems. The provider and its version decide which algorithms an application can use, so a post-quantum migration often begins as an OS or library upgrade. System-wide crypto policies on some Linux distributions set allowed algorithms in one place; this is valuable for agility, because one policy change can enable a hybrid group across many services, and dangerous if changed without testing.
11.3 Updates and boot
Operating systems trust signed updates and, through secure boot, signed boot components. These signatures typically use RSA or ECDSA today. Because forge-later attacks target long-lived trust anchors, vendors are planning post-quantum or hash-based signatures for firmware and boot chains; SP 800-208 approves the stateful hash-based schemes LMS and XMSS, which suit firmware signing where the signer can manage state carefully. Devices whose boot ROM can verify only RSA cannot be upgraded by software alone.
Such devices need a replacement plan.
11.4 Worked example
HCU's branch servers run a Linux distribution whose current OpenSSL version supports the hybrid X25519MLKEM768 group in TLS. The team discovers that the core banking middleware ships its own older, statically linked TLS library and ignores the OS provider. Upgrading the OS changes nothing for that middleware; the vendor must ship a new build. The OS-level view revealed a hidden dependency that a server-by-server checklist would have missed.
The team adds a column to its inventory recording whether each application uses the system library or its own, and asks every vendor for a roadmap.
11.5 Practical activity
On a lab virtual machine you control, list the installed cryptographic libraries and their versions, and find where the system crypto policy (if any) is configured. Record which applications link their own copies.
Look for applications that bundle their own TLS library, such as some databases, language runtimes and vendor agents. Their versions may lag the system library by years. Do this only on a machine you control, and do not change the crypto policy during the exercise. Your record becomes a small version of the dependency inventory that HCU builds for its servers, and the same questions apply at scale.
11.6 Common errors and limits
- Assuming an OS upgrade migrates every application.
- Editing a system-wide crypto policy directly on production.
- Overlooking boot-chain and update signatures.
Applications that bundle their own libraries do not change when the operating system does. System-wide policy changes can break services in ways that are hard to trace, so test them in a lab and roll them out gradually. Boot and update signatures are easy to overlook because they work silently, yet they protect the most trusted code on the machine and often have the longest migration lead times.
Exercises
- EX021 — Provider dependency. Explain why an application that statically links its TLS library is a separate migration item. Rubric: 3 = dependency, ownership and testing consequences.
- EX022 — Boot chain. Why are stateful hash-based signatures suited to firmware signing but risky for a web server? Rubric: 3 = mentions state management, signing volume and recovery.
Synthesis
Operating systems supply the cryptographic providers, key storage and signed update chains that applications depend on. Migration therefore runs through OS and library layers — and through every component that bypasses them.
Continue studying — chapter 11 of 40
← Chapter 10 (draft) · Course chapter index · Chapter 12 (draft) →