25-Comp-B10 Distributed Systems · Undated paper
Nivaar worked solution (AI-drafted; not reviewed by a licensed engineer)
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) Cryptographic protocols for Web traffic and for email signing/encryption. Web site traffic is protected by TLS (Transport Layer Security, the successor to SSL): the browser and server first perform a handshake in which the server presents an X.509 certificate (binding its public key to its domain name, vouched for by a trusted certificate authority); the two sides use asymmetric cryptography (commonly an ephemeral Diffie-Hellman exchange, authenticated by the certificate) to agree a shared symmetric session key, then switch to fast symmetric encryption (e.g. AES) for the bulk of the HTTP traffic, giving confidentiality, integrity (via a MAC) and server authenticity for the rest of the session. Email is protected by a different pair of protocols — S/MIME or PGP — applied at the message-object level rather than the transport level: to digitally sign a message, the sender computes a cryptographic hash of the message and encrypts that hash with their own private key, letting any recipient verify (using the sender's public key) both the sender's identity and that the message was not altered in transit; to encrypt a message, the sender generates a random symmetric session key, encrypts the message body with it, and then encrypts that session key itself with the recipient's public key (a hybrid scheme, since symmetric encryption is far faster than asymmetric encryption for bulk data) so only the intended recipient's private key can recover it.
(b) Centralized key management — advantages and disadvantages. Advantages: a single, well-administered point of control simplifies key issuance, rotation and revocation (compromise of one user's key can be revoked centrally and immediately, rather than the compromise having to be independently discovered and propagated by every peer); it enables strong policy enforcement (uniform password/key strength rules, auditing of every key operation) and lets many users bootstrap trust in each other through one already-trusted authority (as Kerberos's Key Distribution Center does) without needing pairwise pre-shared secrets. Disadvantages: the central server is a single point of failure — if it is unavailable, no new keys can be issued/verified system-wide; it is also a single, high-value point of attack, since compromising it compromises every key it manages; it can become a performance bottleneck as the number of users/requests grows; and it typically requires every participant to place complete, unconditional trust in one central authority, which is a poor fit for systems that must span multiple independent administrative or organizational domains that do not wish to cede that trust to a single party.
(c) Conventional email vulnerabilities and defences.
| Threat | How it works against conventional (unprotected) email | Defence |
|---|---|---|
| Eavesdropping | SMTP carries messages in cleartext hop-by-hop, and every relay stores the message on disk before forwarding it; anyone who can tap a link or read a relay's queue or the recipient's mailbox can read the content | End-to-end encryption of the message body (PGP or S/MIME hybrid encryption with the recipient's public key), plus TLS between mail relays (STARTTLS/MTA-STS) and between the mail client and its server |
| Masquerading | The SMTP “From:” header and envelope sender are not authenticated, so anyone can send mail that appears to come from someone else (spoofing, phishing) | Digital signatures on the message (PGP/S/MIME) verified against a certified public key; domain-level sender authentication (SPF, DKIM, DMARC); authenticated submission (SMTP AUTH) to the sender's own server |
| Tampering | A relay, or an attacker on the path (e.g. one that spoofs DNS MX records to route mail through itself — a man-in-the-middle), can alter the content, attachments or headers, and the recipient has no way to detect it | A digital signature or MAC computed over the content (PGP/S/MIME, DKIM), so any change makes verification fail |
| Replay | An attacker captures a legitimate message (or its authentication token, e.g. a captured login/session) and resends it later to repeat its effect — e.g. replaying an old "approve this transaction" email | A digital signature alone does not prevent replay (the signature is still valid on the copy); bind a timestamp and/or a unique nonce into the signed content and have the recipient's system reject anything already seen or too old |
| Denial of service | An attacker floods a mail server with connection attempts or messages (spam floods, deliberately oversized attachments, SMTP command abuse) to exhaust its queueing capacity, storage or CPU so legitimate mail cannot be delivered | Rate limiting/greylisting per sending IP, spam/reputation filtering upstream, resource quotas per sender, and horizontally-scaled/replicated mail infrastructure so no single server is a single point of exhaustion |
(d) Man-in-the-middle attack on unauthenticated Diffie-Hellman. Because plain Diffie-Hellman authenticates nothing about the exchanged public values ga mod p and gb mod p — only that some party sent them — an attacker (Mallory) sitting on the path between Alice and Bob can run two entirely independent Diffie-Hellman exchanges: one with Alice, in which Mallory impersonates Bob and the two agree a shared secret KAM; and one with Bob, in which Mallory impersonates Alice and the two agree a different shared secret KBM. Neither Alice nor Bob can detect this: each genuinely completes what looks like a correct Diffie-Hellman exchange and each computes a key that is, from their own point of view, valid. From then on Mallory decrypts every message Alice sends (using KAM), reads or modifies it at will, re-encrypts it under KBM and forwards it to Bob, and mirrors this in the other direction — a transparent relay ("bucket-brigade" attack) that fully compromises confidentiality and integrity even though both Alice and Bob believe they share a secure, private channel. The fix is to authenticate the exchanged public values — e.g. sign them with a long-term key certified by a trusted authority (as TLS does, running an authenticated Diffie-Hellman inside a certificate-verified 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 before any secret is agreed.
(e) Security policy for a PEO exam-setup application. 1. All exam content (draft questions, final questions, answer keys, marking schemes) must be encrypted both in transit (TLS) and at rest, with access restricted to authenticated, individually-identified PEO/invigilator accounts only — no shared or anonymous access. 2. Role-based access control enforcing least privilege: only designated exam-setters may author or modify content, only designated invigilators may trigger release at the scheduled sitting time, and no single account may both author content and unilaterally publish/release it, with multi-factor authentication mandatory for any account able to touch unreleased content. 3. Every access to, and modification of, exam content must be recorded in an append-only, tamper-evident audit log (who, what, when), reviewed periodically for anomalies, so any unauthorized access or leak attempt is detectable and attributable after the fact. 4. Unreleased exam content must be technically embargoed — unretrievable in cleartext by anyone, including authorized accounts, before its scheduled release time (e.g. via time-locked decryption keys) — and the system must undergo independent security review and penetration testing before each exam cycle.
