19-Soft-B3 Security · May 2014
Nivaar worked solution (AI-drafted; not reviewed by a licensed engineer)
National Exams, May 2014 — 04-Soft-B3, Security/Safety (closed book, 3 hours, no calculator). FIVE of the seven questions constitute a complete paper (the first five as answered in the answer book are marked, each of equal value); this solution answers all seven as a full study resource. Most questions call for essay-format answers; clarity and organisation of the answer are important. Question 6 asks for a security analysis of a short C program.
Reference texts. Stallings & Brown, Computer Security: Principles and Practice, 4th ed., Ch. 2–3 (Cryptographic Tools, One-Time Pad, Block Ciphers), Ch. 21 (Public-Key Infrastructure, Certificate Authorities), Ch. 3 (Hash Functions, MAC), Ch. 23 (Digital Signatures), Ch. 3 & 24 (User Authentication, Two-Factor, SSO), Ch. 9 (Firewalls, DMZ), Ch. 8 (Intrusion Detection, Honeypots), Ch. 10 (Buffer Overflow); Anderson, Security Engineering, 3rd ed., Ch. 4 (Access Control, Least Privilege), Ch. 1 & 9 (Defense in Depth, Separation of Duty).
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.
Part a) — two strangers with no shared secret. With no prior contact and nothing shared in advance, the two parties can still agree on a common secret over an insecure channel using the Diffie–Hellman key exchange: they publicly agree on a large prime $p$ and a generator $g$; each picks a private random value ($a$ and $b$), computes and exchanges $A = g^a \bmod p$ and $B = g^b \bmod p$ in the open, and each independently computes the same shared secret $K = B^a \bmod p = A^b \bmod p = g^{ab} \bmod p$. An eavesdropper who sees $p$, $g$, $A$, $B$ cannot feasibly recover $K$ without solving the discrete-logarithm problem. The parties then use $K$ (or a key derived from it) as a symmetric key with a block cipher (Question 1b) to encrypt their actual traffic.
Part b) — both parties already have a public/private key pair. With each side already holding a public/private key pair, they can communicate securely with public-key (asymmetric) cryptography directly: to send a message, the sender encrypts it with the recipient's public key, so only the holder of the matching private key can decrypt it, and/or signs it with their own private key (Question 3c) so the recipient can verify the sender's identity and that the message was not altered. Because asymmetric encryption is computationally expensive for bulk data, real systems use a hybrid scheme: the public keys are used only to authenticate each other and to establish a fresh, random symmetric session key (e.g. via a signed Diffie–Hellman exchange), and all subsequent traffic is encrypted with that faster symmetric cipher — the approach used by TLS/HTTPS.
Part c) — the certificate authority. A certificate authority (CA) is a trusted third party that verifies an entity's identity (through some vetting process) and then issues a digital certificate binding that entity's identity to its public key, signing the certificate with the CA's own private key. Anyone who trusts the CA and holds its public key can verify the certificate's signature and thereby trust that the enclosed public key really belongs to the named party — without ever having had prior contact with that party. This directly prevents a man-in-the-middle (impersonation) attack: without a CA, an attacker sitting between the two parties in part a) could substitute their own public key while claiming to be the other party, silently intercepting and re-encrypting all "secure" traffic; because the attacker cannot forge a CA signature over a certificate binding the victim's identity to the attacker's key, a client that checks the certificate chain against a trusted CA will reject the attacker's substituted key.
