◇ OpenCyber Academy
Bachelor's · Chapter 17 · English

Chapter 17 — Cryptography concepts

Open, free learning for anyone who wants to protect people and technology. No account is required to read this text or its worked answers.

Chapter 17 — Cryptography concepts

Lesson map

Lesson 17 published. Map, example, EX049.

flowchart TD
  N0["Learning outcomes"]
  N1["17.1 TLS in transit"]
  N2["17.2 At rest"]
  N3["17.3 Hashes"]
  N4["17.4 Anti-patterns"]
  N5["17.5 Key custody"]
  N6["17.7 Testing the key export denial"]
  N7["17.8 Short-lived platform tokens"]
  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 TLS in transit"]
  N2["17.2 At rest"]
  N3["17.3 Hashes"]
  N4["17.4 Anti-patterns"]
  N5["17.5 Key custody"]
  N6["17.7 Testing the key export denial"]
  N7["17.8 Short-lived platform tokens"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX049"]

[Learning outcomes]
    |
    v
[17.1 TLS in transit]
    |
    v
[17.2 At rest]
    |
    v
[17.3 Hashes]
    |
    v
[17.4 Anti-patterns]
    |
    v
[17.5 Key custody]
    |
    v
[17.7 Testing the key export denial]
    |
    v
[17.8 Short-lived platform tokens]
    |
    v
[Worked example] --> [Exercise EX049]

Learning outcomes

You will (1) state what TLS does; (2) protect evidence at rest; (3) avoid inventing schemes.

17.1 TLS in transit

Confidentiality and integrity of sessions — not app AuthZ.

TLS keeps someone on the network path from reading or silently altering traffic between a customer's browser and TRB's servers, and it lets the browser check that it is talking to the bank's real domain. It does nothing about what happens once the request arrives. If the application gives customer A customer B's statement, it does so over a perfectly encrypted connection. Findings keep the two apart. An outdated protocol version or a weak cipher suite is a transport finding. A missing ownership check is an application finding, and fixing the TLS settings would leave it untouched.

17.2 At rest

Evidence vault encryption and key access logs.

Encrypting the vault's storage protects against someone obtaining the disks, backups or snapshots without going through the application, for example a misconfigured storage bucket or a discarded drive. It does not protect against anyone who can log in to the vault normally, because the application decrypts data for them. The key that unlocks the storage is the real asset, which is why its use is logged separately from file access. A burst of key-use events with no matching vault logins would suggest that someone is reading storage directly, which is the scenario encryption at rest exists to stop.

17.3 Hashes

SHA-256 for evidence integrity, not for password storage design lectures here.

A general-purpose hash such as SHA-256 is designed to be fast, which suits fingerprinting evidence files: hashing a large screenshot archive takes seconds and any change shows up. The same speed makes it a poor choice for storing passwords, where slowness is a deliberate defence against guessing. Password storage needs dedicated functions such as Argon2 or bcrypt, a topic for the identity chapters. In this book SHA-256 answers one question, whether this is the same file that was captured, and testers should not assume a system is secure because it uses a hash somewhere.

17.4 Anti-patterns

Homegrown crypto for TrackScope tokens is forbidden.

An early TrackScope prototype built session tokens by base64-encoding the tester's name and a timestamp, then XORing the result with a fixed string. It looked unreadable and offered no protection. Anyone who saw two tokens could recover the fixed string and forge new tokens. The rule since then is to use the framework's signed-token library or a vetted standard such as signed JWTs with a key held in the vault, and never invent an algorithm or encoding. When Sam sees opaque tokens in a system under test, he checks whether they change predictably between requests, which is a common sign of homemade schemes.

17.5 Key custody

Platform keys in HSM or vault with dual control where required.

Whoever holds a signing key can impersonate the system that uses it. TRB's most important keys, such as the one that signs TrackScope's scope files and the vault's master key, sit in a hardware security module. The HSM performs operations with the key but does not hand the key out. Dual control means sensitive operations, such as exporting a key or changing who may use it, need two authorised people acting together, so no single compromised or careless account can do them alone. Less critical keys live in the software vault, still with logged access and named owners.

17.6 Limits

Crypto does not stop authorized malicious admins with valid keys.

Encryption, signing and hashing protect against people without the keys. An administrator who legitimately holds a key can decrypt, sign or alter data, and the cryptography will faithfully confirm their actions as valid. Controls against insiders are therefore procedural and detective: separation of duties, dual control for the most sensitive operations, logging that the administrator cannot erase, and reviews of key use. When a report says data is protected by encryption, Sam adds who can decrypt it, because that list is where the remaining risk sits.

17.7 Testing the key export denial

HSM export ceremonies for platform keys require two people and a reason code. Sam's intern role cannot export. He tested the denial by attempting an export in staging and filing the deny log as evidence that the control works.

The test was cleared in advance with the HSM owner and run against a staging key that protects nothing real, so a failure would have had no consequences. The deny log records the account, the requested operation, the time and the reason for refusal. An auditor can rely on that record rather than on a statement that the policy exists. It also gives a reference point if the control's behaviour ever changes.

17.8 Short-lived platform tokens

Platform tokens expire within the window plus one hour. Sam tests that expired tokens cannot file findings. Lingering tokens are findings against the platform.

A token that outlives its purpose is a credential waiting to be stolen. The extra hour lets testers finish writing up after the window closes, and anything longer only adds exposure. The test is straightforward. Sam keeps a token from a finished window, waits past its expiry and tries to create a finding with it. The platform must refuse, and the refusal must appear in the log. If the attempt succeeds, the finding names the platform component that failed to check expiry.

17.9 Recording key ceremonies

Ceremony notes list attendees and key ids, never secret material. Sam files notes in the vault with the same retention as evidence.

A key ceremony is the formal event in which a key is created, rotated or exported under dual control. Its notes show that the event followed procedure, covering who was present, which key was involved, which reason code applied and what each person checked. Secret values never appear, even partially, because the notes are read by auditors and reviewers who should not be able to rebuild a key. Keeping the notes with the evidence retention schedule means they are available as long as anything signed with that key might be questioned.

17.10 A key-shaped string blocked in CI

Sam attempts to commit a "temporary" base64 blob that looks like a key. CI fails. He is glad. The failure message links to the key ceremony doc. Guardrails should teach, not only block.

The blob was a test fixture copied from staging, and Sam meant to remove it before merging. A secret scanner in the pipeline does not trust intentions. Once a key is in version history it is in every clone of the repository, and deleting it in a later commit does not remove it. The message's link explained how to request a proper test key, which fixed the immediate problem and showed the correct route next time.

17.11 When short token lifetimes inconvenience people

Token lifetime plus one hour once bit an analyst writing late. Better a re-auth than a token in a stolen laptop weeks later.

The analyst lost a few minutes of unsaved text when the token expired mid-sentence. The reasonable response was to fix the inconvenience without lengthening the lifetime. FindingsDesk now saves drafts locally in encrypted form and asks the user to sign in again before submitting, rather than discarding the work. Security controls that cost people effort tend to be worked around, so reducing the cost without weakening the control is part of designing it.

17.12 Keeping denials as evidence

Ceremony deny logs are retained as positive evidence for examiners who ask whether intern roles are enforced.

Examiners often ask how the bank knows a restriction is enforced rather than merely written down. A configuration export shows the intended setting. A dated record of a real attempt being refused shows the setting in effect. The deny logs are filed with the control they relate to and refreshed whenever the HSM software or role definitions change, so the evidence never describes an older version of the system than the one being examined.

17.13 Using denial records in onboarding

Positive deny evidence packets are reused in onboarding week one.

New staff learn more from seeing a real control refuse a real request than from reading that keys are protected. Each packet pairs the request, the refusal and the policy that caused it, and shows how to read the log. It also sets expectations. New interns see on day one that their role cannot export keys and that trying leaves a record, which makes the rule concrete. The packets contain only staging data and are reviewed before reuse.

Worked example (synthetic TRB)

Sam rejects a PR that encrypts scope files with a hard-coded AES key in source.

Synthetic case — Riverstone Transit Bank (TRB). The bank, Sam Ito, TrackScope/FindingsDesk/PulseMap and all figures are invented for teaching.

Errors and limits

This book grants no authority to test real banks or payment systems. Labs use documentation-range addresses and synthetic data only; exploit code is never provided.

Exercises

Synthesis

Use standard crypto correctly; never roll your own for engagement secrets.

Continue studying — chapter 17 of 40

← Chapter 16 (draft) · Course chapter index · Chapter 18 (draft) →