Question 5 of 7: Security

Question 5: Security

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) Defences against man-in-the-middle attacks on public-key exchange. A naive, unauthenticated exchange of public keys is vulnerable because an attacker positioned on the path between the two parties can substitute its own public key for each party's, then transparently decrypt, read and re-encrypt every subsequent message — each side believes it is talking directly to the other while the attacker silently relays (and can alter) everything. Two standard defences:

1. A trusted certification authority (CA) and digital certificates. Rather than exchanging raw public keys directly, each party obtains a certificate binding its identity to its public key, signed with the private key of a CA both parties already trust (its public key is pre-installed/well-known, e.g. shipped with an OS or browser). A recipient verifies the certificate's signature using the CA's known public key; because the attacker does not hold the CA's private key, it cannot forge a certificate for a substituted key, so any tampering with the key itself is detectable. This is the mechanism behind TLS/HTTPS server authentication.

2. Out-of-band fingerprint verification (a web-of-trust / direct-verification model). The two parties exchange a short, cryptographic fingerprint (hash) of their public keys over a separate, independently-trusted channel — reading it aloud on a phone call, comparing it in person, or via a QR code — and each side confirms the fingerprint of the key it received over the (possibly compromised) network channel matches. Because the attacker cannot also intercept and forge the out-of-band channel, a substituted key's fingerprint will visibly mismatch. This is the model PGP itself uses (see part (b)) when no shared CA is available.

(b) PGP setup steps for privacy and authenticity. Before Alice and Bob can exchange email with both confidentiality and authenticity guarantees, the following must be in place: (1) Key-pair generation. Each user generates their own public/private key pair (traditionally RSA or a similar asymmetric scheme) and keeps the private key secret, protected locally by a passphrase. (2) Public-key distribution. Each user makes their public key available to the other — via a public key server, attaching it to an email, or direct exchange. (3) Authenticity verification of the received key (the critical, often-skipped step). Because a key obtained over an untrusted channel is exactly the man-in-the-middle exposure from part (a), each user must verify the other's public key genuinely belongs to them before trusting it — PGP's usual mechanism is the web of trust: other users who have already verified a key (e.g. by comparing its fingerprint in person) sign it with their own private key, and Bob trusts Alice's key if it carries enough such signatures from people Bob already trusts, or Alice and Bob verify each other's key fingerprint directly out-of-band. Only once this is done can messages that follow be trusted to actually be exchanged with the intended party rather than an imposter.

With both keys generated, distributed and verified, an actual message is protected as follows, achieving both properties the question asks for: privacy is provided by the sender generating a random one-time session key, encrypting the message body with that session key using fast symmetric encryption, then encrypting the (short) session key itself with the recipient's public key and attaching it — only the recipient's private key can recover the session key and hence the message; authenticity is provided by the sender computing a hash (digest) of the message and signing that digest with their own private key before sending it, so the recipient can verify (using the sender's already-trusted public key) that the message truly came from the claimed sender and was not altered in transit. PGP performs both operations together on outgoing mail (sign-then-encrypt), so a single exchanged message carries both guarantees simultaneously.