Chapter 10 — Ethics and authorized practice
Lesson map
Lesson 10 published. Map, example, EX019.
flowchart TD
N0["Learning outcomes"]
N1["10.1 Authorization is the boundary"]
N2["10.2 Scope for cryptographic work"]
N3["10.3 Dual use and disclosure"]
N4["10.5 Practical activity"]
N5["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5
N5 --> EX["Worked example"]
EX --> Q["Exercise EX019"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["10.1 Authorization is the boundary"]
N2["10.2 Scope for cryptographic work"]
N3["10.3 Dual use and disclosure"]
N4["10.5 Practical activity"]
N5["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX019"]
[Learning outcomes]
|
v
[10.1 Authorization is the boundary]
|
v
[10.2 Scope for cryptographic work]
|
v
[10.3 Dual use and disclosure]
|
v
[10.5 Practical activity]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX019]
Learning outcomes
You will (1) explain why authorization defines legitimate security work; (2) write a scope statement for a cryptographic assessment; (3) handle dual-use knowledge responsibly; and (4) route discovered weaknesses through coordinated disclosure.
10.1 Authorization is the boundary
The same action — scanning a server for its supported TLS groups, capturing a handshake, testing whether a device accepts a downgraded algorithm — is professional work when the system owner authorizes it in writing and an offence or a breach of trust when they do not. Authorization must name the systems, the time window, the permitted techniques, the data you may collect and the person to contact if something breaks. Verbal approval from a friendly engineer is not authorization; neither is the fact that a service is reachable from the internet.
10.2 Scope for cryptographic work
Cryptographic assessments can look harmless, but they touch sensitive things: certificates reveal internal hostnames, handshake captures may contain metadata, and downgrade tests can break production sessions. A good scope says, for example: "Passive observation of TLS handshakes on the HCU test gateway mirror port, 1–14 May; no payload retention; no active downgrade testing outside the isolated lab; results shared with the HCU security office only." Active experiments that modify negotiation or inject faults belong in isolated testbeds.
A written scope also protects the student: if something breaks, the record shows what was permitted.
10.3 Dual use and disclosure
Knowing how to find quantum-vulnerable systems also tells an adversary where to look. Publish aggregate findings rather than lists of named vulnerable hosts. If you find a weakness in a vendor product — for example, a library that accepts malformed ML-KEM keys — report it privately to the vendor, agree a timeline, and publish only after a fix or the agreed deadline. Label all synthetic data clearly so that teaching examples are never mistaken for real findings about real organizations.
HCU's reports on its own migration follow the same rule and describe progress as counts.
10.4 Worked example
An HCU student intern notices that a partner bank's public website still offers only classical key exchange and proposes to "scan all partner banks" for a class project. The ethical response: the observation of one public handshake made by a normal browser visit is ordinary, but systematic scanning of partners is outside HCU's authority. The intern instead studies published aggregate measurements and asks HCU's vendor-management team to include post-quantum readiness questions in partner questionnaires.
The response keeps the useful goal, learning how ready partners are, while moving it into a channel where HCU has standing to ask.
10.5 Practical activity
Draft a one-page authorization request for a passive TLS inventory of a synthetic HCU test network. Include systems, dates, techniques, data handling, stop conditions and contacts.
Stop conditions say when to halt: for example, if the test network shows unexpected production traffic or a service degrades. Contacts should include someone who can authorise a stop at any hour. Data handling states what is captured, where it is stored and when it is deleted. Ask a classmate to read your request as if they were the system owner and list anything they would refuse to sign.
10.6 Common errors and limits
- Treating internet reachability as permission.
- Retaining packet payloads "just in case".
- Publishing named lists of vulnerable systems.
Being able to reach a system is not the same as being allowed to test it; permission comes from its owner in writing. Payloads may contain personal data that the assessment never needed, and keeping them creates risk for no benefit. Named lists help attackers choose targets, so share them only with the people who will fix the systems. Each mistake damages the trust that lets security teams do their work.
Exercises
- EX019 — Scope gaps. Identify three missing elements in: "You may test our crypto next week." Rubric: 3 = three of systems, techniques, data handling, window, contacts, stop conditions.
- EX020 — Disclosure. Outline the steps after finding that a vendor's VPN appliance silently falls back to classical key exchange when hybrid is configured. Rubric: 3 = private report, evidence, timeline, coordinated publication.
Synthesis
Authorization, scoped data handling and coordinated disclosure are what make cryptographic assessment professional. Active downgrade or fault experiments belong only in isolated, authorized testbeds.
Continue studying — chapter 10 of 40
← Chapter 09 (draft) · Course chapter index · Chapter 11 (draft) →