Domain 3 is how secure systems are designed: security models, trusted computing, cryptography and its lifecycle, and the physical protections around the hardware. It is the most technical domain, and the one where ATM hardware makes the abstractions concrete.
Case Study: The "Phantom Key" Hardware Shim Attack
Nexus Bank launched a fleet of compact "SlimLine" ATMs for subway stations. The design is modular: a PC core running Windows 10 IoT talks to the cash dispenser and to the encrypting PIN pad (EPP) over standard USB cables. The service panel opens with a standard key. The EPP ships with a legacy compatibility mode that sends the first 50 milliseconds of each keystroke burst in plaintext before switching to encrypted mode, and the mode is on by default.
A transnational gang built a small USB interceptor, a hardware shim, and installed it in seconds behind a service panel opened with a stolen key. Sitting between the EPP and the PC core, the shim captured the plaintext burst of every PIN. It also spoke directly to the dispenser, sending dispense commands that never touched the PC, its operating system, or its security software.
Two things made this work. The PIN left the tamper-resistant device in clear, so the cryptographic boundary the EPP exists to provide was broken by a configuration switch. And the dispenser accepted commands from anything on the bus, because it had no way to authenticate the controller it was supposed to be talking to. Nothing in the boot chain, no Secure Boot or TPM measurement, noticed unfamiliar hardware.
This is the black box attack the white paper describes: the attacker bypasses the PC core entirely, connects a device (a laptop, a phone, or a Raspberry Pi) to the dispenser, and issues native commands. Because the PC is out of the loop, whitelisting, antivirus and host authorization never fire, and the software logs stay clean. The paper adds the physical precondition: standardized top-hat keys can be bought online, so the cabinet lock is often the whole defense.
One organization each, three to six questions apiece in the printed examination. Nothing here gives an answer away — the scenario is what the question hands you before it asks.
Nexus Bank is replacing the fleet-management platform that administers its SlimLine terminals. Today it is one Windows server in the bank's own data center. The target design splits it four ways: a browser console for branch staff, an application tier of Linux containers on a shared cluster, event-driven functions at a cloud provider that reconcile cash balances overnight, and the legacy dispenser-control service, which nobody will rewrite and which will run as a guest on the bank's hypervisor. The migration board has ten weeks and no budget for a second cluster. Security must sign off on each tier separately, and the board meets once a month.
Nexus Bank · SlimLine subway ATM fleet
Nexus Bank has funded a replacement for its SlimLine subway terminal, the SlimLine II, after an interposer device fitted inside the original captured PINs at dozens of sites. The program board meets monthly and has just approved the architecture. Three decisions are still open: how the security requirements become a concrete control set, how the new dispenser interface will be joined to the existing transaction switch, and how 900 SlimLine units leave service. The bank's examiner has asked for evidence at each gate. Finance wants the retired units sold to a secondary-market refurbisher, which pays considerably more than a recycler does and collects from the branch loading dock.
Nexus Bank · SlimLine II replacement program
Nexus Bank has recovered small interposer devices from dozens of its SlimLine subway terminals. Each sat on the internal USB bus between the encrypting PIN pad and the Windows core, reading keystrokes and injecting its own traffic. The cash dispenser accepted dispense commands from that unauthenticated device without question. The pad shipped with a compatibility mode enabled that sent the first keystrokes of each PIN in clear text unless an installer opted out. The bank assumes its communication keys will eventually be stolen and wants recorded past sessions to stay unreadable when that happens.
Nexus Bank · SlimLine subway terminals
Nexus Bank's board wants to know why the controls it already paid for missed an interposer fitted inside its terminals. Every unit has a trusted platform module and measured boot. The network intrusion detection system watches all terminal traffic. Panel locks were the only barrier between passers-by and the internal bus, and the units stand in public subway space around the clock. Forensic examiners have since recovered a later device that never touched the data lines at all: it inferred PINs from tiny fluctuations in the pad's power draw as each digit was processed.
Nexus Bank · terminal engineering
Calderwood Payments is designing the terminal that will replace its current self-service estate. The proposal treats the large general-purpose core as untrusted and runs all PIN handling inside a small sealed module. Engineers want a fleet in which even a fully compromised core would have no independent ability to dispense cash. They also want architectural assurance that when a customer types a PIN, the keystrokes reach the trusted hardware over a route software on the core cannot intercept or imitate, and that the link between the two carries nothing readable if another device is ever installed on it.
Calderwood Payments · self-service terminal program
Draw the trust boundary where the standards draw it. PCI PTS POI certification exists so the PIN is encrypted inside the EPP and never leaves it in clear; a legacy plaintext mode should be disabled at commissioning, and better, absent from the product. Keys move under TR-31 and TR-34 key-block rules, which the white paper notes had a compliance deadline of 1 January 2025.
Treat the peripheral bus as a network. The dispenser should authenticate the PC core before it dispenses; the white paper lists secure peripheral communication and dispenser-level protections (image bonding, high-level dispenser settings) as the controls that answer black box attacks, and rates them High against that vector. Measured boot with a TPM lets the platform refuse to run when the hardware inventory changes.
Then the physical layer: unique or electronic locks on the top hat, a key management policy with named custodians, and a tamper alarm on the service panel that raises a ticket the moment it opens outside a scheduled visit.
Nexus pulled the legacy mode from the fleet by configuration push, replaced the service-panel locks, and added dispenser authentication in the next firmware. The PINs captured before detection forced card reissue on every account that had used a SlimLine unit in the exposure window.
Scenario questions here go to security models and where the trusted computing base ends: a dispenser that obeys any device on the bus is an integrity failure in the Biba sense, and the PIN path is a trusted path that was broken by a default. Expect questions on fail-safe defaults, on the roles of TPM, HSM and Secure Boot, on the cryptographic lifecycle (why key blocks matter), and on physical security as part of engineering instead of a separate discipline.
The bank in this scenario is a composite. The attack and the controls are documented in: