Disk Encryption

The previous five lessons shared one assumption: the only way to reach the machine is through the running system. The inventory was pulled from inside that system, the patch was applied to that system’s components, the benchmark items changed that system’s configuration, the allowlist audited that system’s run decisions, and the sandbox ran an item on a copy of that system.

That assumption drops when the disk is pulled from the machine and mounted somewhere else. The running system drops out of the picture, and every control drops with it: the allowlist performs no evaluation, the baseline is not read, no log is kept. What is left is only the bytes on the disk. This lesson’s measure is how many of those bytes can be read, and how many can be written.

What Encryption Moves Out of Reach

Full disk encryption ties the disk’s contents to a key. Until the key is presented, the volume cannot be decrypted; until the volume is decrypted, no item on it can be read and none can be written. The two verbs matter separately. The read side is a familiar subject: credentials, business data, and logs are protected. What actually changes for this course’s measure is the write side.

Offline write is a foothold path seen for the first time in this course. When the disk is pulled and mounted on another machine, or the machine is booted from an external medium, a service definition or a scheduled task definition can be changed directly as a file. The allowlist does not work on this path, because nothing is being run; a file is being written, and the machine runs it itself on its next boot.

How the key is stored and rotated is not measured here; key management is a separate subject. Measuring the boot chain was done in the Identity, Access and Cryptography course and is taken as input here: the protective value of a key tied to the machine depends on that chain staying intact.

• SH31. The eighteen-item disk content, four machine states, and two encryption settings are a model; no real disk is read, no real encryption is set up.
• SH32. Items are written at the class level; file path and format are not modeled.
• SH33. A volume is either decrypted or it is not; there is no partial encryption or file-level encryption.
• SH34. Offline write is only counted as possible while the machine is off. Pulling the disk from a running machine means shutting the machine down, and that is a transition to the off state.
• SH35. In sleep, the key sits in memory; the model treats this state as decrypted.
• SH36. The machine counts, remaining points, and restart counts per class come from earlier lessons.

// disk/model.mjs — the item readable via physical access IS A MODEL. No real disk is read,
// no real encryption is set up; items are written at the class level.
// row: item | class | inside the encrypted volume | who can read it in a logged-in session | points it carries
export const ITEM = `
  boot-partition-configuration  boot          outside  administrator 1
  boot-signature-record         boot          outside  administrator 0
  recovery-key-hint             identity      outside  administrator 0
  service-definitions           definition    inside   administrator 4
  scheduled-task-definitions    definition    inside   administrator 2
  session-scripts                definition    inside   user          1
  configuration-hooks            definition    inside   administrator 1
  system-configuration           configuration inside   administrator 0
  credential-store                identity      inside   user          0
  saved-session-token             identity      inside   user          0
  client-cache                    data          inside   user          0
  local-logs                      record        inside   administrator 0
  page-file                       memory        inside   administrator 0
  hibernation-image               memory        inside   administrator 0
  temp-file-directory              data          inside   user          0
  meter-reading-data               data          inside   user          0
  local-backup-directory           data          inside   administrator 0
  removable-media-mapping          data          inside   user          0`
  .trim().split('\n').map((r) => {
    const [name, cls, where, reads, points] = r.trim().split(/\s+/);
    return { name, class: cls, inside: where === 'inside', reads, points: Number(points) };
  });
// Machine state: is the volume unlocked, is there an offline write path (disk removal / external boot)
export const STATE = {
  off: { unlocked: false, offlineWrite: true },
  sleep: { unlocked: true, offlineWrite: false },
  'locked-screen': { unlocked: true, offlineWrite: false },
  'logged-in-session': { unlocked: true, offlineWrite: false },
};
export const POINTS = ITEM.reduce((a, k) => a + k.points, 0);
export const OUTSIDE_POINTS = ITEM.filter((k) => !k.inside).reduce((a, k) => a + k.points, 0);

// Items readable and points writable via physical access in a given state and encryption setting.
export function measure(state, encrypted) {
  const d = STATE[state];
  const readable = !encrypted || d.unlocked;              // is the volume's content readable
  const readItems = ITEM.filter((k) => readable || !k.inside);
  const points = d.offlineWrite
    ? ITEM.filter((k) => readable || !k.inside).reduce((a, k) => a + k.points, 0) : 0;
  return { read: readItems.length, points,
    blocked: ITEM.length - readItems.length };            // items encryption blocks
}

// Fleet: points remaining per class (from earlier lessons) and points sitting outside the volume.
// preAuth: is pre-boot authentication required; if not, the key is tied to the machine.
export const CLASS = [
  { name: 'field-laptop', machines: 60, remaining: 9, outside: 1, restarts: 14, preAuth: true, lost: 5 },
  { name: 'branch-endpoint', machines: 24, remaining: 12, outside: 1, restarts: 14, preAuth: true, lost: 1 },
  { name: 'collector', machines: 12, remaining: 12, outside: 1, restarts: 26, preAuth: false, lost: 0 },
  { name: 'processing-server', machines: 6, remaining: 11, outside: 1, restarts: 12, preAuth: false, lost: 0 },
];
export const KEY_COPY = 2;                     // recovery key copies per machine
export const MANUAL_MIN = 12;                  // manual intervention on an unattended restart (min)

Physical Access Across Four States

// disk/measure.mjs — items readable, points closed, and cost, unencrypted vs. encrypted disk
import { ITEM, STATE, POINTS, OUTSIDE_POINTS, CLASS, KEY_COPY, MANUAL_MIN, measure } from './model.mjs';

const row = (g, ...s) => console.log(s.map((v, i) =>
  (g[i] < 0 ? String(v).padEnd(-g[i]) : String(v).padStart(g[i]))).join('').trimEnd());

console.log(`${ITEM.length} disk items, ${ITEM.filter((k) => !k.inside).length} outside the encrypted ` +
  `volume; ${POINTS} foothold-point definitions per machine, ${OUTSIDE_POINTS} outside`);

const A = [-20, 18, 20, 16, 18, 22];
console.log('\n1. items readable and points writable via physical access');
row(A, 'state', 'unencrypted read', 'unencrypted points', 'encrypted read', 'encrypted points', 'encryption blocks');
for (const d of Object.keys(STATE)) {
  const a = measure(d, false), b = measure(d, true);
  row(A, d, a.read, a.points, b.read, b.points, b.blocked);
}

const B = [-30, -14, 10, 8, 12, 22];
console.log('\n2. items outside the volume and points they carry');
row(B, 'item', 'class', 'location', 'points', 'when off', 'in session');
for (const k of ITEM.filter((x) => !x.inside || x.points > 0))
  row(B, k.name, k.class, k.inside ? 'inside' : 'outside', k.points,
    k.inside ? 'protected' : 'readable', `${k.reads} reads`);

const C = [-19, 11, 10, 15, 13, 15, 14];
console.log('\n3. fleet: points closed and the cost of encryption');
row(C, 'class', 'machines', 'points', 'closed points', 'open points', 'manual min/yr', 'lost devices');
const t = { points: 0, closed: 0, open: 0, min: 0, lost: 0 };
for (const s of CLASS) {
  const points = s.remaining * s.machines, open = s.outside * s.machines;
  const min = s.preAuth ? s.machines * s.restarts * MANUAL_MIN : 0;
  t.points += points; t.closed += points - open; t.open += open; t.min += min; t.lost += s.lost;
  row(C, s.name, s.machines, points, points - open, open, min, s.lost);
}
row(C, 'total', CLASS.reduce((a, s) => a + s.machines, 0), t.points, t.closed, t.open, t.min, t.lost);

const m = CLASS.reduce((a, s) => a + s.machines, 0);
console.log(`\nrecovery key copies               ${m * KEY_COPY} (${KEY_COPY} per machine)`);
console.log(`items readable on a lost device    unencrypted ${t.lost * ITEM.length}, ` +
  `encrypted ${t.lost * ITEM.filter((k) => !k.inside).length}`);
console.log(`items a user can read in a logged-in session ` +
  `${ITEM.filter((k) => k.reads === 'user').length} / ${ITEM.length}`);
console.log(`states encryption does not protect  ` +
  `${Object.keys(STATE).filter((d) => measure(d, true).blocked === 0).length} / ${Object.keys(STATE).length}`);

18 disk items, 3 outside the encrypted volume; 9 foothold-point definitions per machine, 1 outside

1. items readable and points writable via physical access
state                 unencrypted read  unencrypted points  encrypted read  encrypted points     encryption blocks
off                                 18                   9               3                 1                    15
sleep                               18                   0              18                 0                     0
locked-screen                       18                   0              18                 0                     0
logged-in-session                   18                   0              18                 0                     0

2. items outside the volume and points they carry
item                          class           location  points    when off            in session
boot-partition-configuration  boot             outside       1    readable   administrator reads
boot-signature-record         boot             outside       0    readable   administrator reads
recovery-key-hint             identity         outside       0    readable   administrator reads
service-definitions           definition        inside       4   protected   administrator reads
scheduled-task-definitions    definition        inside       2   protected   administrator reads
session-scripts               definition        inside       1   protected            user reads
configuration-hooks           definition        inside       1   protected   administrator reads

3. fleet: points closed and the cost of encryption
class                 machines    points  closed points  open points  manual min/yr  lost devices
field-laptop                60       540            480           60          10080             5
branch-endpoint             24       288            264           24           4032             1
collector                   12       144            132           12              0             0
processing-server            6        66             60            6              0             0
total                      102      1038            936          102          14112             6

recovery key copies               204 (2 per machine)
items readable on a lost device    unencrypted 108, encrypted 18
items a user can read in a logged-in session 7 / 18
states encryption does not protect  3 / 4

The Point Closed and the Path It Is Closed Against

The fleet table writes 936 into this course’s closed column: 936 of the 1038 point definitions sit inside the encrypted volume and cannot be written offline. The remaining 102 are the boot-partition entries present one per machine; a partition that has to be read before the volume is decrypted cannot be encrypted.

Placed next to the number without the path’s name, it reads wrong. Encryption closes these 936 points against the offline write path. The same 936 points are wide open to anyone who can run code on the machine while it is running; neither encryption nor the key does anything there. The 40 points closed in the course’s first lesson were genuinely removed and never came back on any path; the closing here belongs to a single path.

This is the shared conclusion of six lessons. A closing number is comparable only once the path it is closed against is written down: removal closes against every path, patching closes a known defect, a benchmark item narrows the set of subjects that can write, the allowlist refuses to run, encryption stops offline writing. All five can be described with the sentence “the point closed,” and all five are different things.

Three States Encryption Does Not Protect

The first table’s last column is zero in three of four states. While the machine is asleep, the screen is locked, and a session is open, encryption contributes nothing, because the volume is decrypted. Eighteen of eighteen items are readable, and what protects them is the screen lock and the operating system’s access control.

This is not a shortcoming of encryption, it is its definition: a machine cannot run without its volume decrypted. But the measurement’s conclusion is clear — for the entire time an endpoint spends running, full disk encryption’s protective value is zero. Field laptops spend most of the day asleep, and in that state the key sits in memory.

There is a direct corollary. What raises encryption’s protective value is not a stronger algorithm, it is the time the machine spends in the off state. How many items are readable when a device is lost depends on which state the device is in at that moment: 3 if it is off, 18 if it is asleep. So the number worth measuring is not the encryption setting, it is the time from sleep to shutdown — how many minutes before the key in the machine’s memory is wiped. Shortening that duration lengthens the time spent off, at the cost of the user waiting through a reboot on every return. Put the two numbers side by side and the decision becomes measurable: how many minutes of waiting in exchange for how many hours off.

One of the bottom rows gives a second limit: in a logged-in session, 7 of 18 items are readable with ordinary user privileges. The credential store, the saved session token, the client cache, the temp file directory, and the meter-reading data are among them. Code running with a user’s own privileges at one endpoint reads these seven items, and disk encryption sees none of that reading.

The second table shows a third limit. Three items sit outside the encrypted volume, and one is the recovery key hint — the protection scheme’s own recovery path sits outside the area it protects. The others are the boot-partition configuration and the boot signature record; both have to be readable before the volume is decrypted, so neither can be encrypted.

Cost

Encryption’s cost gathers in three items. First, the recovery key: 204 copies for 102 machines. Every copy sits somewhere, and whoever can read that place can decrypt that machine’s disk. The number is directly proportional to the machine count and cannot be reduced — a machine whose key is lost cannot be recovered; it goes, along with the business data on its disk. Cutting the copy count to one halves the number of places that can read it and raises the risk of unrecoverability by the same proportion; the two numbers work in opposite directions.

Second, unattended restart. In the two classes requiring pre-boot authentication, every remote restart requires someone at the machine: 14,112 minutes a year, roughly 235 hours. This directly conflicts with the second lesson, where the thing that shortened the window was an unattended patch. On the collector and the processing server this cost is zero, because the key is tied to the machine and the machine unlocks its own disk. The tradeoff is not zero either: on a machine that unlocks its own disk, encryption protects only against the disk being removed, not against the machine itself being booted. The protection holding depends on the boot chain staying intact.

Third, it shows up in lost devices: 6 devices are lost a year. Without encryption, 108 item-classes become readable; with encryption, 18. This is the single largest gain in the table, and it shows the loss is distributed by device class — all six of the losses come from the two portable classes.

Summary

• Full disk encryption closes reading and writing together; what changes this course’s measure is the write side. Offline write is a foothold path the allowlist never sees at all.
• While the machine is off, 15 of 18 disk items are protected; in the other three states — sleep, locked screen, logged-in session — encryption’s contribution is zero, because the volume is decrypted.
• 936 of the fleet’s 1038 point definitions close against offline writing, 102 remain in the boot partition. A closing number is comparable only once the path it is closed against is written down.
• In a logged-in session, 7 of 18 items are readable with ordinary user privileges; one of the three items outside the encrypted volume is the protection scheme’s own recovery hint.
• The cost is 204 recovery key copies and, in the two classes requiring pre-boot authentication, 14,112 minutes a year of manual intervention — a direct conflict with the second lesson’s unattended patching.
• In the two classes where the key is tied to the machine, manual intervention is zero and protection holds only against the disk being removed; items readable on a lost device drop from 108 to 18 for the 6 lost a year.

Next Step

The topic closes with six measurements. Of the 84 point decisions the default setup left, 40 were removed and 44 were written to the baseline; patching brought the time points stayed open down from 10.8 days to 2.3; the benchmark narrowed the writing-subject set for 588 points; the allowlist made 972 points unable to run unapproved code; the sandbox closed no point at all, it only produced a decision; encryption closed 936 points against offline writing. The item count at the endpoint was narrowed, and foothold points were closed.

Underneath all of this measurement sits one untested assumption: that nothing is running. Every number was taken on the assumption that no malicious code exists on the endpoint, or that it has not run yet. Once code does run, how many of the closed points actually stop it, how many only slow it down, and what can be done through the ones that are not closed — none of that was asked. The next topic, Endpoint Protection, opens with that question: malicious software types are classified by their propagation and persistence behavior, signature-based and behavior-based detection are run against the same event set, and what each layer misses is counted separately.