25-Comp-B10 Distributed Systems · December 2019
Nivaar worked solution (AI-drafted; not reviewed by a licensed engineer)
U: x = write(i,55); write(j,66);” — assigning the result of a write to a variable is not meaningful pseudocode. Since the assigned name x is never subsequently read by U, this does not change the analysis below; U is treated as the two-operation transaction write(i,55); write(j,66), and T as x = read(i); write(j,44), exactly as printed.
Question text not reproduced: the examination questions are © Engineers and Geoscientists BC. Open the official past paper (linked at the top of this page) to read the question, then follow the worked solution below.
(a) Kerberos components and the three exchanges. The main components are the client (the user's process requesting access), the Key Distribution Center (KDC) — itself split into an Authentication Server (AS) holding every principal's long-term secret key, and a Ticket Granting Service (TGS) that issues short-lived service tickets — and the application server (S) the client ultimately wants to use. Exchange 1 (client ↔ AS). The client sends its identity and the TGS's identity in the clear; the AS returns a Ticket-Granting Ticket (TGT) plus a session key, both encrypted with the client's long-term key (derived from the user's password) so only the genuine client can decrypt them — the client's password itself never crosses the network. Exchange 2 (client ↔ TGS). To reach any particular application server, the client presents the TGT together with an authenticator (proving recent knowledge of the AS-issued session key) to the TGS, which returns a service ticket for server S plus a fresh client-server session key, both encrypted with a key only the TGS and the client share; this exchange is what lets the client obtain access to many different servers within one login without re-entering credentials each time. Exchange 3 (client ↔ server S). The client presents the service ticket plus a new authenticator directly to S; S decrypts the ticket (which it alone, besides the TGS, can decrypt since it is encrypted under S's own long-term key) to recover the session key and the client's identity, authenticating the client, and optionally returns a value encrypted with that session key to prove its own identity back to the client (mutual authentication).
(b) Web application vulnerabilities and defences.
| Threat | How it works against a conventional Web app | Defence |
|---|---|---|
| Eavesdropping | Traffic sent in the clear (plain HTTP) can be read by anyone on the path — a shared Wi-Fi network, a compromised router | TLS/HTTPS for all traffic; HSTS to prevent silent downgrade to plain HTTP |
| Cross-site request forgery (CSRF) | A malicious page tricks the victim's browser into submitting an authenticated request (e.g. via an auto-submitting form) to a site the victim is already logged into, using the victim's own session cookie | Per-session anti-CSRF tokens validated server-side; SameSite cookie attribute; re-authentication for sensitive actions |
| Injection (SQL/command/XSS) | Untrusted user input is concatenated directly into a SQL query, operating-system command, or HTML page, letting an attacker alter its meaning or inject executable script | Parameterized queries/prepared statements; strict input validation and output encoding; a Content-Security-Policy to limit what injected script can do |
| Replay | An attacker captures a legitimate request/message and resubmits it later to repeat its effect (e.g. replaying a captured "transfer funds" request) | Nonces or monotonically increasing sequence numbers plus timestamps bound into each authenticated request, rejected if already seen or stale |
| Denial of service | The attacker floods the server with requests (or exploits an expensive operation) to exhaust its CPU, memory or bandwidth so legitimate users cannot be served | Rate limiting/throttling, upstream traffic scrubbing/CDN absorption, load balancing across replicas, and designing expensive operations to be cheap to reject early |
(c) Man-in-the-middle attack on unauthenticated Diffie-Hellman. Because Diffie-Hellman authenticates nothing about the public values ga mod p and gb mod p exchanged — only that someone sent them — an attacker (Mallory) positioned on the path between Alice and Bob can run two independent Diffie-Hellman exchanges: one with Alice, in which Mallory impersonates Bob and agrees a shared secret key KAM; and one with Bob, in which Mallory impersonates Alice and agrees a different shared secret key KBM. Neither Alice nor Bob can detect this, because each believes they are talking directly to the other and each derives a key that is, from their own point of view, correctly computed from a Diffie-Hellman exchange. From then on, Mallory decrypts every message Alice sends (using KAM), reads or modifies it, re-encrypts it under KBM and forwards it to Bob, and does the same in reverse — a transparent "bucket-brigade" relay that fully compromises confidentiality and integrity while both legitimate parties believe they have a secure end-to-end channel. The fix is to authenticate the exchanged public values — e.g. sign them with a long-term private key verified against a certificate (as TLS does, running Diffie-Hellman inside a certificate-authenticated handshake), or use an explicitly authenticated variant such as the Station-to-Station protocol — so a value Mallory injects fails signature verification and the exchange aborts.
(d) Security policy statements for a PEO exam-setup application. 1. All exam content (questions, answer keys, marking schemes) must be encrypted both in transit (TLS) and at rest, and access restricted to authenticated, authorized PEO/invigilator accounts only. 2. Role-based access control must enforce least privilege — only designated exam-setters may create/modify exam content, only designated invigilators may release it at the scheduled sitting time, and no single role may both author and unilaterally publish an exam, with multi-factor authentication required for any account that can touch unreleased content. 3. Every access to and modification of exam content must be logged in an append-only/immutable audit trail (who, what, when), reviewed periodically for anomalies, so any unauthorized access or leak attempt is detectable and attributable. 4. Unreleased exam content must be embargoed — technically prevented from being retrievable, even by an authorized account, before its scheduled release time — and the system must undergo periodic independent security review/penetration testing before each exam cycle.