The fifth question is not a content question — it tests whether you developed an independent, critical view of cybersecurity. The professor states that a complete answer has two tasks:
Carefully and precisely summarise the article, taking into account the main cybersecurity topics seen during the course. Use the right vocabulary (CIA triad, threat consequences, design principles, etc.).
Show full understanding, identify the aspects worth reporting, and give a relevant discussion of the problems the article raises — proving you can think critically about the field.
All readings were discussed in class using a precise four-part pattern. Mirror it in your answer — it is the scaffold every reading section below uses:
Define the problem the article raises, in security terms.
Assess where things stand — evidence, incidents, scale.
Possible mitigation techniques, mapped to course concepts.
How the problem evolves, plus your own critical judgement.
Because grading is comparative, the differentiator is connections. The best answers tie the reading back to the lectures (a buffer overflow to complete mediation; an unpatchable router to a negative externality; a backdoored compiler to integrity vs. source inspection) and across readings (trust recurs in Thompson, the Worm, and e-voting). Section 8 is built for exactly this.
Click any card to jump to its full brief.
Readings #1a and #1b are a pair: Schneier (2014) diagnoses the unpatchable-IoT disease; the EU Cyber Resilience Act (2023) is the regulatory cure. The other three are independent classics on trust (#2), self-propagating malware and incident response (#3), and the limits of digitising a trust-critical process (#4).
A decade before billions of consumer devices came online, Schneier diagnosed the structural reason IoT and embedded systems would become a permanent, unpatchable attack surface: the people who could fix the software have neither the incentive nor the source code to do so.
Schneier argues that embedded systems — computers built into hardware, of which the Internet of Things is the consumer wave — have reached a security crisis point: they are riddled with vulnerabilities and there is no good way to patch them. He draws an explicit analogy to the mid-1990s PC insecurity crisis, which was eventually tamed by two mechanisms: full disclosure (publishing vulnerabilities to force faster patching) and automatic updates. The embedded case is worse because everything is now Internet-connected, the devices are powerful, malware spreads faster, and there is less expertise on both vendor and user sides.
The root cause is a market-structure (incentive) failure along the supply chain. Cheap, low-margin chips (Broadcom, Qualcomm, Marvell) run a stripped Linux plus open-source and proprietary drivers; chipmakers do minimal engineering and rarely update their “board support package.” Original Device Manufacturers (ODMs) pick chips on price and features and add little; the brand vendor adds a UI and ships. No single entity owns post-shipment patching. The software is old even when the device is new (a router survey found components four-to-five years older than the device; minimum Linux age four years, Samba six). Worse, patching is often impossible because many drivers ship as closed “binary blobs” with no source code; and even when patches exist, users are never alerted, lack the expertise, and ISP remote-patching is rare.
The result is hundreds of millions of devices sitting unpatched for five to ten years, already being exploited (DNS Changer against home routers; 4.5 million compromised DSL routers in Brazil used for fraud; a Symantec-reported Linux worm hitting routers and cameras; a Def Con researcher breaking into half of thirty home routers). Routers and modems are the priority risk: always-on, general-purpose, and sitting between the user and the Internet. Schneier’s fixes: pressure vendors to design securely, demand open-source drivers (“no more binary blobs!”), and mandate automatic update mechanisms for the device’s whole service life — with ISPs as the economic driver, since they absorb the downstream costs. He closes that this is “an incipient disaster... just a matter of when.”
A systemic availability/integrity risk rooted in a market externality: devices ship vulnerable, obsolete, and often closed-source, and no actor in the chain can or will patch them. It breaks open design and lifecycle complete mediation, and removes patch management.
An “incipient disaster” already materialising in 2014: long-unpatched devices, real exploitation (DNS Changer, 4.5M Brazil DSL routers, a Linux router/camera worm, Def Con). The asset is the router’s privileged network position. From 2026 hindsight, Mirai (2016) confirmed the warning.
His three (open-source drivers, secure-by-design, auto-update) plus course-grounded additions: secure default credentials (the exact Mirai gap), signed firmware via digital signatures/PKI to make auto-update safe, defense-in-depth/segmentation, least privilege, and attack-surface reduction.
Voluntary ISP economics did not self-correct the market — regulation became the real lever (this is why #1b exists). “No more binary blobs” is commercially unrealistic, so signed auto-updates + mandatory support windows + SBOMs are the pragmatic path. The hard frontier is device longevity: hardware outlives vendor support.
Mirai and the Cyber Resilience Act are not in Schneier’s 2014 text — cite them as later hindsight / a paired reading, not as claims he made. Schneier says full disclosure “won’t work the same way” for embedded systems (because of scale and unpatchability); the sharper claim that disclosure “arms attackers against devices that cannot be fixed” is your analysis, not his.
| Course topic | Connection |
|---|---|
| CIA — availability & integrity | Compromised routers join botnets (DDoS = availability); DNS/route manipulation and pharming break traffic integrity. |
| Threat consequences | Botnets = disruption; DNS/pharming = deception; persistent device control = usurpation. |
| Design principle: open design | “No more binary blobs” is the open-design principle — security must not rest on implementation secrecy, and openness enables third-party patching. |
| Design: secure defaults / economy of mechanism | “Design systems better” before shipping = fail-safe defaults; Mirai later showed the cost of shared default passwords. |
| Attack surface | Hundreds of millions of always-on, general-purpose routers = a vast exposed attack surface (the Module-1 tutorial concept), enlarged by IoT. |
| Digital signatures / PKI | Auto-update is only safe with signed firmware — otherwise the update channel becomes a malware-distribution channel. |
Summary: thesis (embedded/IoT structurally unpatchable) → 1990s-PC analogy and its two cures → supply-chain incentive failure → aging software → binary-blob obstacle → user/ISP install gap → evidence → his three fixes.
Comment (four-part): (i) availability/integrity risk that is really a market externality breaking open design and patch management; (ii) an already-real disaster, confirmed later by Mirai; (iii) his fixes plus secure defaults, signed firmware (PKI), segmentation, least privilege; (iv) markets did not self-correct, so regulation (CRA) is the lever; “no blobs” is unrealistic, so signed updates + support windows + SBOMs, with device longevity as the open frontier. Close: prescient diagnosis, slightly over-optimistic on market self-correction.
The first-ever EU law that turns “security as an optional afterthought” into a legally mandated property of every connected product sold in Europe — the regulatory answer to exactly the unpatchable-IoT problem Schneier warned about.
The Cyber Resilience Act (CRA) is the first horizontal EU regulation imposing mandatory cybersecurity requirements on products with digital elements — both hardware and software — placed on the EU single market. The Commission frames it around a clear market failure: many connected products ship with low security and, crucially, many manufacturers never provide updates. Because the cost of vulnerabilities is borne mainly by users and consumers rather than vendors (a negative externality), manufacturers have weak incentives to invest in secure design and updates. A second problem is an information asymmetry: buyers cannot judge or securely configure products.
The CRA addresses these through several mechanisms: (1) market access is conditioned on meeting essential cybersecurity requirements; (2) it mandates security-by-design, requiring manufacturers to factor cybersecurity into product design and development; (3) it enforces whole-lifecycle responsibility — manufacturers must define a support period and supply security updates throughout it, directly attacking the unpatchable-product gap; (4) it imposes transparency duties (clear security information and secure-use instructions); and (5) obligations cascade across the supply chain (manufacturers, importers, distributors), proportionate to role. Compliance uses the EU New Legislative Framework: a conformity assessment (self-assessment for lower-risk products, third-party for higher-risk/“important” ones), an EU Declaration of Conformity, and the CE marking for free movement in the internal market.
Enforcement falls to Member-State market surveillance authorities, which can restrict, withdraw, or recall products and levy administrative fines. On scope: pure software-as-a-service is excluded (covered instead by the NIS2 Directive and sectoral law), but the CRA complements NIS2 — secure products strengthen the supply chain NIS2’s essential/important entities depend on — and aligns with (and will amend/repeal) the RED Delegated Regulation for radio equipment. Timeline: once in force in 2024, operators have 36 months to comply, except the obligation to report actively exploited vulnerabilities and incidents, which applies after 21 months. Expected benefits: fewer incidents, lower costs, more trust, better protection of fundamental rights, and a potential global standard (the “Brussels effect”).
A structural market failure: insecure, never-patched connected products. The economic root is a negative externality (vendor saves, user pays) plus an information asymmetry (a “lemons market” where security cannot be priced). This is Schneier’s unpatchable-device problem, reframed as a regulatable defect.
As of Dec 2023 the CRA is agreed, entering force in 2024 (36-month transition; 21 months for vuln/incident reporting). The pre-CRA landscape was voluntary and fragmented; the EU layers NIS2 (operators) + RED (radio) and reuses the proven CE / New Legislative Framework model.
Governance controls that operationalise technical principles: security-by-design = fail-safe defaults; mandatory lifecycle updates = integrity/availability + complete mediation over time; the 21-month reporting duty = coordinated vulnerability disclosure; transparency = psychological acceptability; CE + market surveillance = a trust signal plus deterrent.
Likely a “Brussels effect” making secure-by-design and support periods global defaults. Weak points: self-assessment risks compliance theatre (CE certifies conformity, not security); support periods may be set minimally; and the mandated update channel is itself a high-value attack surface (a compromised update server pushes malicious firmware fleet-wide — echoing Thompson). SaaS exclusion is a coverage seam.
The source supports security-by-design (“factor cybersecurity into the design and development of products”) but does not use the distinct term “security-by-default” — do not present that as a CRA requirement. Terms like “externality,” “Brussels effect,” and the Saltzer–Schroeder principles are your analytical layer, not the Commission’s wording.
This is the pairing the examiner is most likely to reward. Click each 2014 problem to see the 2023 regulatory answer (and its limits).
| Course topic | Connection |
|---|---|
| CIA — availability & integrity | Mandatory updates protect firmware integrity and availability; the secure update channel is itself integrity-critical. |
| Design: fail-safe defaults / complete mediation | Security-by-design codifies Saltzer–Schroeder principles as legal obligations; lifecycle updates = complete mediation over time. |
| Threat consequences: usurpation / disruption | Unpatched IoT enables botnets (usurpation/disruption); a compromised mandated update server is a fleet-wide usurpation vector. |
| Risk-based assessment | Conformity assessment is calibrated to risk (self vs third-party), mirroring asset–vulnerability–threat–risk for product classes. |
| Supply-chain trust (cf. Thompson) | CE marking and the update path are only as trustworthy as the process behind them — Thompson’s lesson applied to conformity signals. |
| PKI / digital signatures | Delivering “security updates” securely implies authenticated, signed firmware so devices can verify update authenticity. |
Summary: first horizontal EU law for products with digital elements; two problems (no updates / externality, and information asymmetry); five mitigations (security-by-design, lifecycle updates, transparency, supply-chain cascade, conformity assessment + CE + enforcement); scope (SaaS → NIS2), timeline (36 / 21 months), Brussels-effect ambition.
Comment (four-part): (i) misaligned-incentive market failure + lemons-market asymmetry; (ii) agreed Dec 2023, layered with NIS2/RED, reusing CE/NLF; (iii) map each duty to a course concept; (iv) Brussels effect, but self-assessment theatre, minimal support periods, the update channel as a new attack surface (Thompson), CE certifies conformity not security. Close: right diagnosis, effectiveness hinges on standards quality, enforcement teeth, and signed updates.
The man who co-created UNIX uses his Turing Award stage to prove you cannot trust a single line of software you did not build yourself — because a self-perpetuating Trojan horse can live entirely in the compiler binary, invisible in every source file.
Thompson argues that source-level inspection is fundamentally insufficient to establish trust in software, because trust must ultimately rest on the people and tools that produced it, not on the code you can read. He builds “the cutest program I ever wrote” in three stages. Stage I: a self-reproducing program (a quine) in C that, compiled and run, outputs an exact copy of its own source. Two properties matter: such a program can be generated by another program, and it can carry arbitrary “excess baggage” reproduced along with it. Stage II: the “chicken-and-egg” bootstrapping of a self-hosting compiler (the C compiler is written in C). Teaching the compiler a new escape (\v = decimal 11) requires “training”: you hard-code the value, compile, install that binary as the official compiler, and thereafter the knowledge persists in the binary even after the source is cleaned up — “as close to a learning program as I have seen.”
Stage III combines the two into the attack. A first Trojan horse matches the UNIX login command and miscompiles it so it accepts either the correct password or a secret known password — a backdoor to log in as any user. Because such code in the compiler source would be noticed, a second Trojan horse matches the C compiler itself; its payload is a Stage-I self-reproducing routine that reinserts both Trojan horses whenever the compiler is recompiled. After bootstrapping this bugged binary into the official compiler, Thompson removes all malicious code from the source: the source is clean everywhere, yet the deployed login stays backdoored and the compiler silently re-propagates the attack into every future build.
The moral: “You can’t trust code that you did not totally create yourself.” No amount of source-level scrutiny protects you from untrusted tools. He notes he could have targeted any program-handling program — assembler, loader, or even hardware microcode — and that the lower the level, the harder the bug is to detect (a microcode bug would be “almost impossible to detect”). He distinguishes a bug (accidental) from a Trojan horse (deliberate). The lecture closes with social commentary criticising the press for glamorising intruders, arguing that breaking into a system should carry the same stigma as breaking into a neighbour’s house. He credits the original idea to an Air Force critique of an early Multics implementation.
Step through how a clean source tree can still produce a backdoored system.
The limit of trust in the software supply chain. The trust chain is recursive: to trust a program you must trust its compiler, that compiler’s compiler, the assembler, the loader, the OS, and ultimately the hardware. There is no source artifact at which the audit can stop. It is an integrity attack (binary ≠ audited source) enabling usurpation (login bypass).
Now lived reality: software is assembled from opaque chains — compilers, package registries, CI/CD, libraries, base images, firmware, silicon. Real echoes: XcodeGhost (trojanised compiler), SolarWinds/SUNBURST (build-system compromise), and the 2024 xz/liblzma backdoor. The attacker can sit beneath the source the defender audits.
No single fix; defense in depth: Diverse Double-Compiling (Wheeler), reproducible builds verified by hash, code signing via PKI, SBOM/provenance, trusted/measured boot + TPM toward the microcode layer, and small-TCB design (economy of mechanism, least/separation of privilege). These diversify trust so collusion becomes necessary — they do not eliminate it.
Extends to AI/ML pipelines: a poisoned dataset or backdoored model is the statistical analogue of Thompson’s compiler Trojan (cf. Module 2 poisoning), and an LLM coding assistant is a new low-level “program-handling program.” The deepest point is epistemological: aim to minimise and diversify required trust, because absolute self-sufficiency is unattainable.
“Co-creator of C with Dennis Ritchie” is standard external biography, not stated in the lecture (the source only calls Ritchie a longtime collaborator). The source says “Air Force critique,” not “US Air Force.” XcodeGhost, SolarWinds, xz, Diverse Double-Compiling, SBOM, TPM and the AI/ML angle are your modern commentary, not Thompson’s.
| Course topic | Connection |
|---|---|
| CIA — integrity | A pure integrity violation: the deployed binary does not implement its audited source. What you read is not what you run. |
| Threat consequences: usurpation / deception | The login backdoor (universal password) is usurpation via deception — the system behaves as if running clean code. |
| Threats: Trojan horse | Thompson gives the textbook contrast: deliberate miscompilation = Trojan horse; accidental = bug. |
| Authentication: something you know | The payload defeats password authentication regardless of password strength. |
| Design: open design | The strongest critique of naive “open source ⇒ secure”: the malice lives below the source. Open design must extend to verifiable, reproducible binaries. |
| Design: economy of mechanism / small TCB | The recursive trust chain shows why keeping the trusted computing base small and auditable is essential. |
| Crypto: hashing & digital signatures | Modern answers (reproducible builds checked by hash; code signing via PKI) apply secure hashing for integrity and signatures for authenticity. |
| AI & security: poisoning | A backdoored model is the statistical analogue: malice invisible in any human-readable source, propagating through an unauditable pipeline. |
\v = decimal 11); (III) two cooperating Trojans + self-reproduction.login accepts a secret password (backdoor as any user); Trojan #2 → compiler reinserts both on every recompile; then malicious source is deleted — no trace.Summary: thesis (trust rests on people/tools, not source) → Stage I quine (two properties) → Stage II self-hosting compiler “learning” → Stage III the two Trojans + self-reproduction, then clean the source → moral → generalisation to assembler/loader/microcode → bug-vs-Trojan, Multics attribution, social coda.
Comment (four-part): (i) recursive/transitive toolchain trust; integrity of artifact vs inspection of source; (ii) realised as XcodeGhost, SolarWinds, xz — the whole pipeline is the attack surface; (iii) Diverse Double-Compiling, reproducible builds (hash), code signing (PKI), SBOM, trusted boot/TPM, small TCB — diversify not eliminate trust; (iv) extends to poisoned data/backdoored models and LLM assistants; the point is epistemological — minimise and diversify required trust. Close: integrity of what runs, not just what is read, is the assurance target.
On 2 November 1988 a single self-replicating program disabled several thousand machines (under 5% of the ~60,000-host Internet) within hours — the first large-scale demonstration that the security of an interconnected network is bounded by its weakest, most-trusted, most-monocultural component.
Spafford gives a first-hand technical post-mortem of the 1988 Internet Worm. He first fixes terminology: a worm runs independently and propagates a fully working copy of itself across machines, whereas a virus is parasitic code that attaches to a host program and cannot run until that host is executed (Cohen/Denning). By its propagation method the November 2nd program is a worm; Spafford rejects the “virus” label as forcing an over-complex biological analogy.
The worm targeted only Sun-3 and VAX systems running 4BSD UNIX, exploiting four vectors: (1) a stack buffer overflow in fingerd — a 536-byte string overran the 512-byte input buffer (read with the unbounded gets() call), overwrote the saved return address, and ran injected shellcode doing execve("/bin/sh",0,0); (2) the sendmail DEBUG option, often shipped enabled on SMTP port 25, which let the worm pipe a recipient to /bin/sh; (3) trust relationships — BSD rsh/rexec used .rhosts and /etc/hosts.equiv to allow password-less remote execution between “trusted” hosts; and (4) password guessing — an entirely offline dictionary attack against the world-readable /etc/passwd (permuted-DES hashes), trying no-password and account-derived guesses, then a built-in 432-word list, then the system’s /usr/dict/words; some sites lost over 50% of their passwords.
Architecturally the worm had a main program plus a 99-line C vector/bootstrap: after breaking in it compiled the bootstrap on the victim, which reconnected to the infector using a magic-number challenge (to stop binary capture), pulled architecture-specific binaries, and relaunched. It used stealth: zeroing its argv, forking and killing its parent (rotating its PID and dodging CPU accounting), and running from memory after deleting its disk files. Its reinfection control was probabilistic and buggy: a “pleasequit” handshake reduced duplicates, but one in seven copies became “immortal” and never checked, and host lists flushed periodically — producing the runaway process load that exhausted swap/process tables and crashed hosts (the actual denial of service). Berkeley/MIT captured and decompiled the code within days; the author was Cornell student Robert T. Morris, later prosecuted under the Computer Fraud and Abuse Act (18 U.S.C. 1030). The lasting institutional response was the creation of CERT at Carnegie-Mellon’s Software Engineering Institute. Spafford’s lessons: the dangers of trust and of a software monoculture; the value of open communication / full disclosure (the same openness that spread the worm also cured it); and that the incident was a breakdown of ethics as much as of technology — a purely technical fix cannot solve the whole problem.
Click each vector to see its mechanism, the design principle it violated, and its modern descendant.
fingerd overflow, sendmail DEBUG, rsh trust, offline password cracking.An interconnected network inherits the union of every host’s vulnerabilities and the transitive closure of trust between them. The four vectors map onto principle violations (below). The consequence is primarily a disruption of availability achieved through usurpation (remote code execution).
Three of the four vectors are still dominant: memory-unsafe calls drove decades of exploits (gets finally removed in C11); insecure defaults reappear in IoT (#1a/#1b); trust abuse is the ancestor of lateral movement; offline dictionary attacks are the course’s John-the-Ripper tutorial. CERT scaled into the global CSIRT/CVE ecosystem.
Spafford’s own remain canonical: shadow files + hashing + lockout + proactive strength checking (defense in depth); replace static .rhosts trust with Kerberos session keys. Plus the overflow lineage (bounds-checked I/O, non-executable stacks, ASLR/canaries, memory-safe languages), hardened defaults, and a formal coordination body (CERT).
His strongest insight: this was a breakdown of ethics as much as technology — vindicated by malware’s drift to criminal/state-sponsored. His weakest point is rejecting software diversity: in a modern threat model, controlled heterogeneity genuinely raises attacker cost. He also under-weights that the missing destructive payload was luck, not assurance (cf. NotPetya).
The widely-cited “6,000 machines” figure is not in this source — the paper says “thousands of machines” / “less than 5%” of ~60,000 hosts; use those. The whole password attack is offline (the worm encrypts candidate words locally and compares against the readable hash file); /usr/dict/words is the system’s installed dictionary, not a network attack. Monoculture/diversity critique, Kerberos and the C11 history are course-level commentary.
| Course topic | Connection |
|---|---|
| Buffer overflow / complete mediation | The fingerd/gets exploit is the canonical stack-smashing attack — a direct failure of input validation / complete mediation. |
| Design principles (Saltzer & Schroeder) | sendmail DEBUG = failed fail-safe defaults; .rhosts/hosts.equiv = failed least/separation of privilege; world-readable /etc/passwd = failed least common mechanism. |
| Authentication & offline cracking (JtR) | The built-in 432-word + /usr/dict/words attack on DES hashes is exactly the offline dictionary attack; the shadow file is the defence. |
| Crypto: one-way / hash functions | UNIX stored a permuted-DES one-way hash; its security collapses once the hash is readable and the input space is small — motivating salting, slow hashes, shadowing. |
| CIA & threat consequences | Primarily disruption of availability (resource exhaustion) via usurpation (RCE); confidentiality/integrity spared only by restraint. |
| Attack surface / attack trees | fingerd, sendmail, rsh, /etc/passwd are four leaves; the worm’s “try each in turn” logic is an OR-node attack tree, automated. |
| Trusting Trust (#2) | Both are about misplaced trust: Thompson in the toolchain, Spafford in host-to-host trust that becomes transitive compromise. |
fingerd: 536-byte string into a 512-byte buffer via gets(); overwrite return address; execve("/bin/sh").sendmail DEBUG on SMTP port 25; trust via /etc/hosts.equiv + .rhosts (rsh/rexec)./etc/passwd: built-in 432-word list, then /usr/dict/words; >50% broken at some sites.argv, fork/kill parent, memory-only).Summary: worm/virus definition + date/scope → the four vectors with mechanisms (especially the 512/536-byte overflow) → two-stage design + stealth + the reinfection bug that caused the DoS → chronology, Morris, CFAA, CERT → lessons (trust, monoculture, open communication, ethics).
Comment (four-part): (i) a network inherits union-of-vulnerabilities + transitive trust; (ii) the four vectors are still dominant; tie to memory-safety history, shadow files, Kerberos; (iii) Spafford’s mitigations + modern overflow defenses + CERT, and his warning against the wrong fixes (restricting communication, forced diversity); (iv) socio-technical thesis (ethics + full disclosure), critique the anti-diversity stance, note the no-payload outcome was luck. Close on the legacy (CERT, CFAA, coordinated disclosure), linking to #1b and #2.
fingerd overflow at the stack level and connect it to complete mediation and modern mitigations.Elections are a system whose security failure cannot be undone, cannot be insured against, and may not even be detected — making e-voting the textbook case where a tiny breach of integrity destroys public trust in democracy itself.
The article surveys the security risks of moving elections onto computers, distinguishing two paradigms. E-voting uses technology at supervised physical polling stations: Direct-Recording Electronic (DRE) touchscreen machines for casting, optical scanners or punch-card readers for tabulation, and networked transmission of tallies. I-voting (internet/remote voting) lets citizens vote from any internet device, away from observer oversight, which makes verification far harder; Estonia is the only country with widespread i-voting.
The dominant concern is integrity: malware can alter votes on DRE machines, and in i-voting the voter’s own (often compromised) computer is the “weakest link”; attackers can even build fake voting clients that fool the user into believing a vote was cast. Much tampering is undetectable (2006 UC research on Diebold memory cards; 2018 DEF CON remote manipulation of an AccuVote TSX; an Estonian vote-counter malware simulation). Accuracy is weak too (DRE error rates of 1–2%, compounded in hybrid systems). Voter-Verified Paper Audit Trails (VVPATs) are proposed but costly, hard to administer, and rarely checked (Caltech/MIT: fewer than 1 in 10 take a new ballot when shown an error), and only help if recounts are mandated. A systemic problem is the loss of verifiability: proprietary code means the public cannot confirm software matches hardware behaviour (Germany’s Federal Constitutional Court required systems examinable “reliably and without specialist knowledge”; Estonia published code on GitHub in 2013, but incompletely). I-voting also enables coercion in uncontrolled environments, undermining ballot secrecy. The attack surface extends to voter-registration systems and pollbooks (Russian operatives hacked registration databases before the 2016 US election) and the supply chain (ES&S machines shipped 2002–2006 with remote-access software), plus human/procedural error and insider threats.
Lake weighs the benefits (faster counting, accessibility, lower long-term cost, fewer mismarked ballots) against the dangers and concludes against e-voting. His mitigations — open-source code, community hardware verification, comprehensive procedural guidelines, penetration testing, separate-device verification, multiple observers, paper audit trails, change-your-vote provisions — are necessary but, he argues, insufficient. His verdict: because democracy is at stake and tampering can be undetectable, paper ballots remain superior, since large-scale paper fraud cannot be hidden, is expensive and discoverable, and avoids the many failure points of complex digital systems.
Click each risk to see which security property it breaks and how it can be mitigated.
Elections need integrity + ballot secrecy + availability + auditability simultaneously, under maximal-stakes adversaries, where failure is irreversible. Digitising breaks paper’s key property — that large-scale fraud leaves observable traces — and adds a large, opaque attack surface; proprietary code violates open design.
Deployed systems are demonstrably insecure (Diebold AccuVote-TS malware-installable; AccuVote TSX remotely manipulable at DEF CON, used in 18 states; ES&S remote-access software; Virginia WinVote weak passwords; Russia 2016 registration-DB hacking). Some jurisdictions retreated to paper (Netherlands); Germany set a verifiability bar most systems fail.
Map to principles: open-source code (open design); pre-election hardware verification (complete mediation); mandatory VVPAT + risk-limiting audits (tamper-evident integrity, defense in depth); separate-device verification (endpoint check); observers + anti-insider controls (least/separation of privilege); coercion-resistance (change-vote).
End-to-end verifiable (E2E-V) crypto and risk-limiting audits can attack the undetectable-tampering problem, but founder on the coercion-resistance vs receipt-freeness tension and on psychological acceptability (a proof a layperson cannot understand does not build trust). The unsolved core is the untrusted client device — the same Trusting-Trust problem (#2). The risk asymmetry justifies a conservative, software-independent posture: paper as ground truth, never digital alone.
Lake invokes the CIA triad and design principles only implicitly; the explicit course-mapping, the Trusting-Trust parallel, and the E2E-V / risk-limiting-audit discussion are your analytical layer, not assertions in the article. All figures and incidents above are from the source.
| Course topic | Connection |
|---|---|
| CIA — integrity | Vote alteration via malware and undetectable DRE tampering is a direct integrity violation; its irreversibility/invisibility is what makes it uniquely dangerous. |
| CIA — confidentiality & availability | Coercion breaks ballot secrecy/free choice; DoS or registration-DB attacks threaten availability. |
| Threat consequences | Fake clients = deception + usurpation; coercion = unauthorized disclosure of the choice; vote-altering malware = disruption/usurpation of the tally. |
| Design: open design | Proprietary, unverifiable code violates open design; Germany’s “examinable without specialist knowledge” ruling is the principle applied. |
| Design: complete mediation / separation of privilege | Pre-election verification = complete mediation; multiple observers and anti-insider controls = separation/least privilege. |
| Attack surface / attack trees | Widens from the ballot machine to registration systems, pollbooks, transmission, supply chain, and the voter’s device. |
| Trusting Trust (#2) | The client-side weakest-link problem is Thompson applied to voting: you cannot trust software you did not fully verify. |
Summary: define e-voting vs i-voting → the risk taxonomy in CIA terms (integrity/undetectable tampering, accuracy, coercion, verifiability, wider attack surface, human/insider) with the concrete incidents → for/against balance and the anti-e-voting conclusion.
Comment (four-part): (i) elections need irreversible verifiable integrity + secrecy + availability; digital breaks paper’s tamper-evidence; (ii) repeated real-world breaks, retreats to paper, Germany’s standard unmet; (iii) mitigations mapped to design principles + defense in depth (VVPAT + risk-limiting audits); (iv) E2E-V crypto vs coercion-resistance and acceptability; the unsolved core is the untrusted client (Trusting-Trust); risk asymmetry ⇒ software-independent paper ground truth. Close: agree with the risk-asymmetry logic while noting he underweights modern E2E-V research.
The fastest way to earn a high mark is to show the readings are not five disconnected articles but variations on a few deep ideas. Click a theme to see which readings illustrate it — then weave one or two connections into your answer.
| Reading | Core problem | Primary CIA impact | Headline mitigation |
|---|---|---|---|
| #1a IoT (Schneier) | Unpatchable devices; market externality | Availability / integrity | Open drivers, secure-by-design, auto-update |
| #1b CRA (EU) | No legal duty to secure/patch products | Integrity / availability | Security-by-design + lifecycle updates, by law |
| #2 Trusting Trust | Trust in the toolchain; source ≠ binary | Integrity (→ usurpation) | Reproducible builds, diverse double-compiling, signing |
| #3 Internet Worm | Union of vulnerabilities + transitive trust | Availability (→ usurpation) | Shadow files, Kerberos, bounds checks, CERT |
| #4 E-voting | Digitising a trust-critical, irreversible process | Integrity + confidentiality | Paper ground truth, VVPAT + risk-limiting audits |
Trust is the spine of all five: Thompson attacks the toolchain you trust, the Worm walks the host-to-host trust you grant, e-voting asks you to trust an unverifiable client, and the IoT/CRA pair is about whether you can trust a vendor to keep a product secure. A strong 5th answer names this explicitly: secure systems fail at the points where trust is assumed rather than verified.
The 5th question names one reading — but recognising which reading a prompt points to is half the battle. Pick the best fit for each scenario.
(1) Precisely summarise the reading using the correct course terminology, and (2) critically comment on it — following the classroom pattern of problem → current situation → mitigations → future evolution — to show an independent, critical view of the field.
Everything is now Internet-connected; the devices are powerful and long-lived; malware spreads faster; there is less expertise on both vendor and user sides; and the fixes that worked for PCs fail here — patching is often impossible (closed-source binary blobs) and no actor in the supply chain has the incentive or ability to do it. It is a market/externality failure, not a single bug.
It makes security a legal property of products with digital elements: market access conditional on essential cybersecurity requirements, security-by-design, a defined support period with mandatory updates (attacking the unpatchable gap), transparency, and enforcement via CE marking + market surveillance + fines — internalising the externality back onto vendors.
The compiler binary contains two Trojan horses: one backdoors login, the other recognises the compiler’s own source and reinserts both Trojans on every recompile (a self-reproducing payload). Once that bugged binary is the official compiler, the malicious source is deleted — so the source is clean everywhere, but every build stays compromised. Hence: integrity of the binary, not inspection of the source, is what must be assured.
(1) fingerd stack buffer overflow via gets() — complete mediation / input validation; (2) sendmail DEBUG mode — fail-safe defaults; (3) rsh/rexec trust via .rhosts/hosts.equiv — least / separation of privilege; (4) offline dictionary attack on world-readable /etc/passwd — least common mechanism (and weak “something you know”).
A denial of service via resource exhaustion: a reinfection bug (1-in-7 copies became “immortal” and never checked for duplicates) made process load explode until swap/process tables were exhausted and hosts crashed. There was no destructive payload and no halt mechanism; intent was never definitively established — so the lack of data destruction was arguably luck, not design.
Because elections demand irreversible, verifiable integrity and ballot secrecy under maximal-stakes adversaries, and digital systems allow undetectable tampering while proprietary code blocks public verification. Paper’s advantage is tamper-evidence: large-scale fraud cannot be hidden, small-scale effects are caught, and a massive conspiracy would be expensive and discoverable.
Trust — specifically, systems fail where trust is assumed rather than verified: the toolchain (Thompson), host-to-host trust (Worm), the client device (e-voting), and vendor responsibility (IoT/CRA). Naming this thread and giving one concrete cross-reading link is exactly the kind of connection that lifts an answer above the class average.