Chapter 13 — Identity and access
Lesson map
Lesson 13 published. Map, example, EX025.
flowchart TD
N0["Learning outcomes"]
N1["13.1 Three steps"]
N2["13.2 PKI in brief"]
N3["13.3 Authentication flows"]
N4["13.5 Practical activity"]
N5["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5
N5 --> EX["Worked example"]
EX --> Q["Exercise EX025"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["13.1 Three steps"]
N2["13.2 PKI in brief"]
N3["13.3 Authentication flows"]
N4["13.5 Practical activity"]
N5["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX025"]
[Learning outcomes]
|
v
[13.1 Three steps]
|
v
[13.2 PKI in brief]
|
v
[13.3 Authentication flows]
|
v
[13.5 Practical activity]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX025]
Learning outcomes
You will (1) distinguish identification, authentication and authorization; (2) explain how certificates and public-key infrastructure (PKI) bind identities to keys; (3) identify quantum-vulnerable elements in common authentication flows; and (4) plan where post-quantum signatures will be needed first.
13.1 Three steps
Identification claims an identity; authentication proves it; authorization decides what the authenticated party may do. Passwords, one-time codes and passkeys authenticate users; certificates and signatures authenticate machines and software. Authorization is usually symmetric bookkeeping — access-control lists and roles — and is not directly threatened by quantum computers. Authentication based on public-key signatures is.
Keeping the three steps apart helps a migration team focus. HCU's role tables and access lists need no change for quantum reasons. Every place where a signature or a public-key login proves identity does, and those places are spread across phones, servers, the certificate authority and software releases. Listing them by step makes the scope of the work clearer.
13.2 PKI in brief
A certificate is a signed statement by a certificate authority (CA): "this public key belongs to this name, valid until this date". Verifiers trust a small set of root CAs and follow chains to them. If an adversary can compute a CA's private key from its public key — as Shor's algorithm would allow for RSA and ECDSA — they can issue certificates for any name. Because root keys are long-lived and widely embedded, PKI is the archetypal forge-later target. Post-quantum signature standards provide replacements: ML-DSA in FIPS 204 for general use and SLH-DSA in FIPS 205 as a conservative hash-based option.
13.3 Authentication flows
Passkeys and FIDO authenticators use public-key signatures (often ECDSA) inside a secure element. Single sign-on tokens are signed with RSA or ECDSA. Code-signing certificates protect software updates. Each flow has a different migration path: tokens with short lifetimes can switch quickly once libraries support ML-DSA; hardware authenticators need new devices; root CAs need long planning because relying parties must first trust the new roots.
HCU groups its flows by which of these paths they need. Short-lived tokens come first, the CA last.
13.4 Worked example
HCU lists authentication uses: member passkeys (ECDSA in phone hardware), staff SSO tokens (RSA-2048, 10-minute lifetime), internal CA (RSA-4096 root, 20-year validity), mobile app code signing (ECDSA, platform-controlled). The forge-later risk is greatest for the long-lived root and for code signing, where a forged signature would let an adversary distribute malicious software. Short-lived SSO tokens are lower priority: forging one requires a quantum computer at the moment of attack, and the key can rotate quickly once one exists.
The list also shows who controls each change. HCU can change its own tokens and CA; it depends on phone makers and app platforms for passkeys and code signing.
13.5 Practical activity
Draw HCU's certificate hierarchy: root, two intermediates, server and client leaves. Annotate each with algorithm, validity and who must trust it. Mark which changes require relying parties to update trust stores.
Relying parties include member phones, branch servers, ATMs and partner banks, each with a different way of updating trust. Some can take a new root in a routine update; others, such as ATMs, may need a vendor visit. Mark those carefully, because they set the pace of the whole certificate migration. Compare your diagram with a classmate's and check that both of you placed the same validity periods on the same certificates.
13.6 Common errors and limits
- Treating authorization lists as quantum-vulnerable.
- Planning to migrate leaf certificates before relying parties trust a post-quantum root.
- Forgetting hardware authenticators that cannot be updated.
Access lists and role tables use no public-key mathematics, so quantum computers do not threaten them. Issuing post-quantum leaf certificates before relying parties trust a matching root causes connections to fail. Hardware authenticators with fixed algorithms can only be replaced, which takes budget and years. A plan that ignores them will look complete on paper and stall in practice, when the devices turn out to be in members' pockets.
Exercises
- EX025 — Classify. For passwords, passkeys, SSO tokens and an internal root CA, state whether a quantum computer threatens the mechanism and why. Rubric: 3 = four correct, reasoned entries.
- EX026 — Order of work. Explain why a post-quantum root must be distributed to relying parties before post-quantum leaf certificates are useful. Rubric: 3 = chain validation logic stated.
Synthesis
Quantum computers threaten public-key authentication, not authorization logic. PKI roots and code signing are the long-lived targets; short-lived tokens can follow later.
Continue studying — chapter 13 of 40
← Chapter 12 (draft) · Course chapter index · Chapter 14 (draft) →