Lesson map
Lesson 17 published. Map, example, EX049.
flowchart TD
N0["Learning outcomes"]
N1["17.1 Hashes"]
N2["17.2 Encryption"]
N3["17.3 Signatures"]
N4["17.4 Passwords"]
N5["17.5 Monitoring and encryption"]
N6["17.6 Keys and trust"]
N7["17.7 Case"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX049"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["17.1 Hashes"]
N2["17.2 Encryption"]
N3["17.3 Signatures"]
N4["17.4 Passwords"]
N5["17.5 Monitoring and encryption"]
N6["17.6 Keys and trust"]
N7["17.7 Case"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX049"]
[Learning outcomes]
|
v
[17.1 Hashes]
|
v
[17.2 Encryption]
|
v
[17.3 Signatures]
|
v
[17.4 Passwords]
|
v
[17.5 Monitoring and encryption]
|
v
[17.6 Keys and trust]
|
v
[17.7 Case]
|
v
[Worked example] --> [Exercise EX049]
Learning outcomes
You will (1) explain hashing, encryption and digital signatures; (2) relate cryptography to authentication and email security; (3) use hashes for evidence integrity; (4) recognise cryptographic limits in monitoring.
17.1 Hashes
A cryptographic hash turns any data into a fixed-size fingerprint. It is practically impossible to find two inputs with the same hash. SOCs use hashes to identify files and to check that evidence has not changed.
Lucas uses SHA-256 for both purposes. For evidence, the hash recorded at export time proves the file is unchanged. For identification, a hash of a malicious attachment can be searched across mailboxes to find every exact copy. The worked example below shows the limit of the second use: changing a single character produces a completely different hash.
17.2 Encryption
Encryption makes data unreadable without a key. TLS encrypts web and mail traffic in transit; disk encryption protects lost laptops.
For the SOC, encryption in transit protects students' passwords on campus Wi-Fi from eavesdroppers, but it also protected the phishing page's traffic, so network sensors could not see what victims typed. Disk encryption on staff laptops means a stolen laptop is a lost device rather than a data breach, which changes how the SOC and the DPO respond to the loss.
17.3 Signatures
A digital signature proves who created data and that it has not changed. Email DKIM signatures let receiving servers verify that a message came from the claimed domain.
In the phishing case, the message claimed to come from the library but had no valid DKIM signature for the library's domain, because the attacker did not hold the library's signing key. Receiving servers could therefore tell the message was not genuine. The filter's response, a banner rather than rejection, determined whether students actually saw that warning.
17.4 Passwords
Passwords should be stored as slow, salted hashes so that a stolen database cannot be easily reversed.
Riverton's identity provider stores passwords this way, so a breach of its database would not hand over usable passwords quickly. But the phishing campaign shows the limit: the attacker never needed the database, because victims typed their passwords directly into the fake page. Strong storage protects against one kind of attack and does nothing against another, which is why MFA matters as a second barrier.
17.5 Monitoring and encryption
Encryption hides content from network sensors. The SOC relies on endpoint and service logs that see data before encryption or after decryption.
For mail and identity, the cloud services decrypt traffic as part of their work, so their logs show sign-ins and rules in full. For student devices, the SOC has no such view. This is why the architecture chapter places most monitoring at services, where data is visible, rather than on campus network links where it is encrypted end to end.
17.6 Keys and trust
Cryptography is only as safe as its keys. Compromised signing keys let attackers sign malicious content.
If the library's DKIM signing key had been stolen, the attacker could have sent messages that passed authentication checks, and filters would have treated them as genuine. Riverton keeps signing keys in the mail provider's managed service and rotates them on a schedule. The SOC alerts on any change to the domain's DNS records that publish those keys, since a swapped record would let an attacker's key pass.
17.7 Case
The phishing email failed DKIM for the domain it pretended to come from; receiving filters marked it suspicious, but the banner was easy to ignore.
The banner said the sender could not be verified, in small text above the message. Many students who clicked later said they had not noticed it. Lucas recorded a question for the incident review: whether messages failing authentication for Riverton's own domains should be quarantined rather than delivered with a warning. A banner that most readers overlook protects little, however accurate it is.
Certificates
Websites prove their identity with certificates signed by trusted authorities. The phishing page had a valid certificate for its look-alike name, so the browser padlock showed; a padlock proves encryption, not honesty.
Worked example
Lucas exports the phishing message and computes its SHA-256 hash for the case record. Later, a second copy reported by staff has a different hash: the attacker added the recipient's name to each message. Lucas notes that hashes identify exact copies, not campaigns; subjects and links group variants.
Synthetic case. Messages and hashes are invented.
Errors and limits
Cryptography protects data in specific ways; it does not make a system secure by itself.
Exercises
- EX049 — Hash uses. Name two SOC uses of hashes.
Show marking criteria
Rubric: 3 = identify files, check evidence integrity; 2 = one; 1 = vague; 0 = none. - EX050 — DKIM. What does a DKIM signature let receivers check?
Show marking criteria
Rubric: 3 = message came from claimed domain unchanged; 2 = partial; 1 = encryption; 0 = none. - EX051 — Variant hashes. Why did two copies of the phishing email have different hashes?
Show marking criteria
Rubric: 3 = personalised content changes hash; group by subject/link; 2 = partial; 1 = error; 0 = none.
Synthesis
Cryptography underpins authentication, email trust and evidence integrity, but it hides content from monitoring and depends on key safety.
Continue studying — chapter 17 of 40
← Chapter 16 (draft) · Course chapter index · Chapter 18 (draft) →