Chapter 12 — Operating systems
Lesson map
Lesson 12 published. Map, example, EX023.
flowchart TD
N0["Learning outcomes"]
N1["12.1 Where cryptography lives"]
N2["12.2 System-wide policies"]
N3["12.3 Secure boot and updates"]
N4["12.4 Entropy and key storage"]
N5["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5
N5 --> EX["Worked example"]
EX --> Q["Exercise EX023"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["12.1 Where cryptography lives"]
N2["12.2 System-wide policies"]
N3["12.3 Secure boot and updates"]
N4["12.4 Entropy and key storage"]
N5["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX023"]
[Learning outcomes]
|
v
[12.1 Where cryptography lives]
|
v
[12.2 System-wide policies]
|
v
[12.3 Secure boot and updates]
|
v
[12.4 Entropy and key storage]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX023]
Learning outcomes
You will (1) locate cryptographic libraries and configuration in an operating system; (2) explain system-wide crypto policies; (3) understand secure boot and update signing; and (4) manage entropy and key storage. It builds on Chapters 8–9 and prepares inventory (Chapter 22) and maintainability (Chapter 39).
12.1 Where cryptography lives
On a Linux server, TLS usually comes from a shared library (OpenSSL, GnuTLS, NSS, BoringSSL in some applications), SSH from OpenSSH, VPNs from kernel IPsec plus a user-space IKE daemon. Applications may also bundle their own libraries — Java, Go and Rust programs often do. An inventory that checks only the system library misses statically linked or bundled cryptography.
Finding bundled code requires checking binaries and application packages, not just the package manager. For a Go binary, the build information lists the cryptographic modules compiled in; for Java, the configured security providers show which library handles TLS. These checks belong in the inventory script so every host is assessed the same way.
12.2 System-wide policies
Some distributions provide system-wide cryptographic policies that set default algorithms for all libraries that honour them. Policies are a powerful agility lever: changing one profile can enable hybrid groups or disable weak algorithms across many services. Their limit is coverage — applications with bundled libraries ignore them.
BPA uses the policy to enable the hybrid group on all services that use the system library in a single change, then checks each service's handshake to confirm it took effect. Services that do not show the hybrid group after the change are exactly those with bundled libraries, so the policy rollout doubles as a test of inventory coverage.
12.3 Secure boot and updates
Firmware verifies the bootloader's signature, which verifies the kernel's, and so on. These signatures must remain verifiable for the device's lifetime, which may exceed a decade. That makes boot chains early candidates for hash-based signatures (LMS, XMSS per SP 800-208), which CNSA 2.0 also prioritizes for software and firmware signing.
A device shipped in 2026 with a fifteen-year life will still verify updates in 2041, so the boot key chosen now must remain secure for that whole period. Changing the root of trust later may need physical access or may be impossible, which is why boot chains get first priority rather than last.
12.4 Entropy and key storage
Keys need good randomness from the OS (getrandom), especially at early boot and in virtual machines. Private keys belong in protected storage — HSMs, TPMs or OS keystores — never in world-readable files.
Virtual machines cloned from one image can start with identical random state, so keys generated at first boot may repeat across hosts. Waiting for getrandom to report that the pool is ready, and generating keys after boot completes, avoids that. On BPA's terminal servers, TLS private keys are stored in the TPM-backed keystore and audited monthly for file-permission drift.
12.5 Worked example
BPA's inventory of a terminal server finds OpenSSL 3.x as the system library, a Java application with its own provider, a Go binary statically linked, and an IPsec daemon. Enabling hybrid TLS through the system policy affects only the first; the other two need application changes. The migration plan records one work item per cryptographic provider, not per server.
Counting by provider gives four work items for this server, with different owners: the platform team for OpenSSL and IPsec, the application team for Java, and the developers of the Go service, who must rebuild with a newer toolchain. A plan counted per server would have marked this host done after the policy change while two of its four providers were untouched.
12.6 Common errors and limits
- Assuming one policy change migrates the whole host.
- Ignoring boot-chain signatures because they are "not network".
- Storing keys in configuration directories.
The worked example showed a policy change reaching only one of four providers on a single host. Boot-chain signatures matter because they must stay valid for the device's life and are hard to replace, so they come first in signing migrations. Keys kept in configuration directories are copied into backups and images, where they may outlive the systems they were meant to protect.
Exercises
- EX023 — Provider inventory. List four places cryptography may live on a server and how you would detect each. Rubric: 3 = includes bundled/static libraries.
- EX024 — Boot chain. Explain why firmware signing is an early PQC priority. Rubric: 3 = device lifetime and verification-only constraints.
Synthesis
Cryptography lives in many providers on one host; system policies help but do not cover bundled code; long-lived boot chains need early migration; keys need protected storage and good entropy.
Continue studying — chapter 12 of 50
← Chapter 11 (draft) · Course chapter index · Chapter 13 (draft) →