Evolution of Secure Interbank Payment Systems
The evolution of interbank payment systems from legacy test key systems to the modern SWIFT network is explored, highlighting the challenges of securing telegraph-based transactions in the 19th century and the transition to SWIFT in the 1970s for more reliable and secure financial communication. The limitations of test key systems, the implementation of SWIFT, and the design constraints for ensuring trust and security in the banking sector are discussed.
Download Presentation
Please find below an Image/Link to download the presentation.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. Download presentation by click this link. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
E N D
Presentation Transcript
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)
Agenda Test-key systems SWIFT: wholesale inter-bank payments Automatic Teller Machines (ATMs)
Bank payments in the 19th 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
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
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
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
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
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
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!)
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
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
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
Automatic Teller Machines ATMs were 1st 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
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
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
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)
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
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
Optimization is the process of taking something which works, and replacing it by something which doesn t quite but is cheaper Roger Needham
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
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
Whos 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
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
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
