Evolution of Secure Interbank Payment Systems
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 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
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 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
IBM Method for generating ATM PINs
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
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
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
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.If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
You are allowed to download the files provided on this website for personal or commercial use, subject to the condition that they are used lawfully. All files are the property of their respective owners.
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.
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
