Chapter 19 — Identity and cryptography
Lesson map
Lesson 19 published. Map, example, EX055.
flowchart TD
N0["Learning outcomes"]
N1["19.1 Patron sessions"]
N2["19.2 Staff access"]
N3["19.3 Encryption at rest"]
N4["19.4 Encryption in transit"]
N5["19.5 Signatures"]
N6["Key management"]
N7["Certificates"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX055"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["19.1 Patron sessions"]
N2["19.2 Staff access"]
N3["19.3 Encryption at rest"]
N4["19.4 Encryption in transit"]
N5["19.5 Signatures"]
N6["Key management"]
N7["Certificates"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX055"]
[Learning outcomes]
|
v
[19.1 Patron sessions]
|
v
[19.2 Staff access]
|
v
[19.3 Encryption at rest]
|
v
[19.4 Encryption in transit]
|
v
[19.5 Signatures]
|
v
[Key management]
|
v
[Certificates]
|
v
[Worked example] --> [Exercise EX055]
Learning outcomes
You will (1) explain authentication for patrons and staff; (2) describe encryption at rest and in transit; (3) use digital signatures for integrity.
19.1 Patron sessions
Patrons log in with library card numbers via a session manager; the PC itself runs a standard local account.
The session manager checks the card number against the library system and sets a time limit on the session. When the patron logs out or the time ends, the session closes and the profile is cleared. The PC's local account never knows who the patron was, which keeps identities off the machine and away from the nightly restore's logs. Mateo tested this on a lab PC.
19.2 Staff access
Staff administration uses separate named accounts with multi-factor authentication.
Named accounts mean every administrative action can be traced to a person, which shared accounts would prevent. The second factor stops a stolen password from being enough. Mateo checked that the second factor works from the branches, where mobile signal is poor at Millbrook, and chose hardware tokens for that reason. Staff who leave have their accounts disabled the same day by Marta. Administrative sessions time out after a short idle period, and every sign-in is logged.
19.3 Encryption at rest
Disk encryption, supported by the TPM, protects data if a PC or disk is stolen. Microsoft documents BitLocker for Windows.
Encryption matters most for staff laptops and for public PCs that could be carried away. The key is released by the TPM only when the boot chain matches, so a disk moved to another machine stays unreadable. Mateo confirmed that encryption is turned on for every public PC by checking the management reports, not by assuming the image setting was applied everywhere.
19.4 Encryption in transit
Management traffic uses TLS with certificates so PCs talk only to the genuine server.
The server's certificate is issued by Fernhill's own authority, and PCs trust only that authority for management traffic. A device pretending to be the server on the branch network would fail the check. Mateo tested this by pointing a lab PC at a test server with an untrusted certificate, and the PC refused to connect and logged the reason. The certificate's expiry is tracked with alerts well ahead, so renewal never surprises staff.
19.5 Signatures
Golden images and updates are signed; PCs verify signatures before applying them, as SP 800-147 recommends for firmware updates.
Signing means a PC applies an image only if it was produced by Fernhill's release process. An image altered on the server or in transit fails the check. The worked example confirms this on a lab PC. The protection is only as good as the signing key's security, which the key management discussion below takes up as a risk to resolve. Failures are logged and alerted.
Key management
Signing keys for images must be protected, because anyone holding them could sign a harmful image that PCs would accept. Initially the key sits on Marta's workstation. Mateo records this as a risk; chapter 45's independent review later moves the key to a managed hardware service. Disk encryption recovery keys are stored in Fernhill's directory service, accessible only to IT staff.
He documents who can use each key and how its use is logged.
Certificates
Server certificates are renewed automatically, with an alert thirty days before expiry.
Accounts for staff
Staff use separate administrative accounts only for IT tasks and normal accounts for email and browsing, reducing the impact if a normal account is compromised. Administrative logons are logged and reviewed weekly.
Patron credentials
Library card numbers are checked by the session system, not stored on PCs.
Logging
Signature failures are logged.
Worked example
Mateo tests what happens if an unsigned image is offered to a lab PC. It refuses to apply it and logs an error, which is the desired behaviour.
Synthetic case. Synthetic.
Errors and limits
Encryption without good key management protects little.
Exercises
- EX055 — Staff accounts. How do staff authenticate? Rubric: 3 = named accounts with MFA; 2 = partial; 1 = vague; 0 = none.
- EX056 — Disk encryption. What does disk encryption protect against? Rubric: 3 = stolen PC or disk; 2 = partial; 1 = vague; 0 = none.
- EX057 — Unsigned image. What happened when an unsigned image was offered? Rubric: 3 = refused and logged; 2 = partial; 1 = vague; 0 = none.
Synthesis
Authenticate people and verify software with cryptography.
Continue studying — chapter 19 of 50
← Chapter 18 (draft) · Course chapter index · Chapter 20 (draft) →