1. Legacy Payment Systems Tyler Moore CS7403, University of Tulsa Reading: Anderson Security Engineering, Ch. 5.2.4 (136—138), 10.3-10.4 (328—343)

2. Agenda Test-key systems SWIFT: wholesale inter-bank payments Automatic Teller Machines (ATMs)

3. Bank payments in the 19 th century Banks became primary user of telegraph for interbank payments – ‘To Lombard Bank, London. Please pay from our account with you no. 1234567890 the sum of £1000 to John Smith of 456 Chesterton Road, who has an account with HSBC Bank Cambridge no. 301234 4567890123, and notify him that this was for ‘‘wedding present from Doreen Smith’’. From First Cowboy Bank of Santa Barbara, CA, USA. Charges to be paid by us.’ Since telegraph messages were relayed by intermediate operators, messages were vulnerable to manipulation Banks used a rudimentary hash function called test keys to ensure integrity of messages

4. Test key example To authenticate a payment of $284,912, send 53096469 with message: 53 for 0x1,000,000 09 for 2x100,000 64 for 8x10,000 69 for 4x1,000

5. Telegraphs with test keys: security analysis Given the key and value, can create test Given the test, cannot recreate value Vulnerable to cryptanalysis by observing many messages and codes, as well as chosen-plaintext attacker Yet banking systems experienced very little fraud using test key systems as late as 1980s Lack of support for dual control and vulnerability to cryptanalysis motivated shift to SWIFT

6. SWIFT Society for Worldwide International Financial Telecommunications (SWIFT) – Established in 1970s with remit to create secure and efficient alternative to telex-based test key systems for interbank payments – Essentially an email system with built-in encryption, authentication, and non-repudiation – Facilitates trillions in worldwide payments daily – Design copied by many asset transmission systems

7. SWIFT design constraints Banks didn’t want to trust SWIFT (dishonest SWIFT employees shouldn’t be able to forge or manipulate transactions) Authentication mechansims must be independent of encryption mechanisms due to export control rules Non-repudiation achieved without digital signatures (not invented yet) Enforce controls such as balancing, dual control, audit

8. SWIFT Architecture RGP: Regional General Processor (Symmetric) key management – Integrity (using MAC): pairwise between banks – Confidentiality: between banks and RGP, and between RGPs and SWIFT – Physical key exchange used

9. Non-repudiation in SWIFT Banks send messages to their RGP, who log the message and forward it to SWIFT, who logs the message and forward it to recipient’s RGP, who logs the message before delivery A bank (or malicious employee) who tries to repudiate a transaction would have to collude with two RDPs (often in different countries) and SWIFT While we think of non-repudiation guarantees coming from crypto, distributed logs work too (and judges understand logs better!)

10. SWIFT II SWIFT I ran 20 years with no public reports of external fraud In mid-1990s, SWIFT II added support for public- key crypto – Banks now share MAC keys by public key crypto – MACs can be digitally signed Public key crypto has introduced centralization that could be seen as vulnarability – Corrupt/hacked CA could sign keys on bank’s behalf

11. What goes wrong in SWIFT Most practical attacks don’t target payment security mechanisms directly Typical attack: rogue employee inserts bogus payment (tx $10M to account in Caymans) – Usually picked up by bank’s internal controls – Banks have accounts at other banks, and transfers debit these accounts – Large transfers require managerial approval – Similarly, transfers to new accounts raise red flags Technical attacks (e.g., banking trojans) are often stopped by bank’s internal controls

12. What goes wrong in SWIFT Most large bank frauds exploit procedural vulnerabilities, not technical ones – Fraudulent letter of guarantee can be sent via SWIFT; since no money transfers balancing controls don’t help; fraudster borrows money from new bank and launders it – Stanley Rifkin embezzled millions by replaying authentication code used to send wire transfers (defeating dual control), then avoided money laundering by converting stolen cash to diamonds

13. Automatic Teller Machines ATMs were 1 st large-scale retail transaction processing systems – Invented in 1938, deployed by Citicorp in NYC – Withdrawn after 6 months because main users were “prostitutes and gamblers who didn’t want to deal with tellers face to face’ – Commercial introduction by Barclays in 1967 Security “firsts” in ATMs – Large-scale use of block ciphers – Tamper-resistant hardware

14. IBM Method for generating ATM PINs

15. PIN Key Management Early ATMs – All ATMs had copy of PIN key KP – All ATMs can verify all PINs – Offset kept on magstripe, can check PINs offline – Cash counters kept on magstripe ($500 weekly limit), can be enforced offline More recent ATMs keep offset off card, check balance and offset online

16. Implementing Dual Control in ATMs Dual control is implemented using tamper- resistant hardware security module (HSM) kept at bank 1.Operations on cleartext PINs and keys done in HSM; clear values never available to single bank employee 2.Cards and PINs sent to customer via separate channels; manufactured in distinct facilities with separate HSMs 3.Per-ATM terminal master key split and supplied by two bank officials

17. Implementing Dual Control in ATMs 4.For offline PIN verification, PIN key KP encrypted with terminal master key and sent from bank to ATM 5.For online PIN verification, PIN is encrypted using terminal master key and sent to bank 6.To accept other banks’ cards, PIN, PIN is encrypted using terminal master key and sent to bank, then reencrypted by HSM using key shared with network (e.g., VISA)

18. Extending Dual Control to Many Banks Challenges for interoperable ATMs – Bank security practices vary greatly, and many banks used software encryption instead of HSMs – In theory, programmers at banks using SW could decrypt PINs of any other bank’s customers – Solution was to standardize HSM use – Infeasible for banks to share pairwise keys, so use shared keys with networks such as VISA and Cirrus

19. Extending Dual Control to Many Banks Challenges for interoperable ATMs – Some banks turn off authentication and authorization messages for efficiency reasons – This enables anyone with network access to replay prior authorization and withdraw without PIN – Banks who do this claim they could turn authorization on if fraud rises – Yet these same banks may also blame customers when fraud arises

20. “Optimization is the process of taking something which works, and replacing it by something which doesn’t quite but is cheaper” Roger Needham

21. What Goes Wrong with ATMs ATM designer’s threat models anticipated sophisticated, rational criminals – Worried about large number of trusted banks – Worried about implementation loopholes and “optimizations”, encryption key strength – Worried that bank managers wouldn’t implement dual control correctly Decades of ATM fraud has shown that in many cases, criminals behaved differently

22. What Goes Wrong with ATMs Simple processing errors account for many disputes – Error rate between 1:10K and 1:100K – 5Bn transactions => 5-50K disputes Mail thefts of cards and PINs are common (accounting for 30% of UK card fraud losses at one point) Fraud by bank staff – Repairman installing skimmers – Bank used same key for testing and deployment, maintenance staff sold PINs to criminals Offline processing fraud was substantial

23. Who’s Liable for ATM Fraud? Judd v. Citibank (1980) – Customer disputed ATM withdrawals – Citibank refused to pay because its systems “were secure” – Court sided with Judd, because Citi’s infallibility claim creates unattainable burden of proof Federal Reserve Regulation E requires US banks to refund disputed transactions unless bank can prove customer fraud Banks in UK, Germany, Netherlands, Norway, South Africa were allowed to claim infallibility for many years – Only when many criminals were jailed for ATM fraud did the rules change

24. Case of John Munden John Munden was a British Police Officer – Upon return from vacation in 1992, found six unauthorized withdrawals totaling £460 – After disputing the transactions with his bank, he was prosecuted for “attempting to obtain money by deception” – Despite court evidence that the bank’s security was problematic, and despite dubious claims such as the ATM network’s invulnerability to bugs because the software was written in assembler, he was convicted and lost his job – Overturned 4 years later when the bank refused to grant access to systems for defense expert

25. Liability and the Importance of Incentives In US, because banks were liable for fraud, they invested heavily in countermeasures In UK and countries where banks could blame customers, banks fought fraud less aggressively In the end, UK banks suffered more fraud and spent more on security than US banks Classic example of moral hazard