Security Issues in Branchless Banking
Saurabh Panjwani
Collaborators: Edward Cutrell, Prasad Naldurg, Raghav Bhaskar (Microsoft Research); Anupam Varghese (Eko).
• Extends banking services to low-income communities without installing physical branches
Branchless Banking
Branchless Banking
Customer
Traditional Banking
Teller
Customer
Bank Branch
(urban)
Mom ‘n pop shop
(peri-urban, rural)
Agent
(shopkeeper) Credit: CKS
Transactions
Agent
An SMS receipt
SMS receipts
(sent to both users)
“Transfer amount X to account Y”
Customer
Deposit (or money transfer): Customer deposits amount X into account Y. (Y could be self-owned or a friend’s account.)
Bank Server
Transactions
Agent
“Withdraw amount X’ from account Y via agent A”
Customer
Withdrawal: Customer (owner of account Y) withdraws amount X’ from Y by visiting agent A.
Transaction message
sent by customer
Bank Server
SpreadM-Pesa (Kenya)
15 million customers,
40,000 agents,
$2 million per day
G-Cash (Philippines)
> 2 million customers,
$100 million per day.
Eko, FINO, SubK (India)
> 40 million customers,
> 40,000 agents,
> $2 million per day.
Banco Postal (Brazil)
11 million customers,
$1 million per day.
Sources: CGAP, O’Reilly Radar
• User authentication
• Authentication of bank SMS’es
Security Issues
Did agent A send this message?Sender: Agent A
Message: Transfer X to Y
Sender: BankMessage: X deposited into Y
Did the bank send this message?
More generally: Users’ view of transaction must match bank’s view
Particularly a concern for money
transfers: risk of agent fraud
Challenge• Authentication is a well-studied problem
– Crypto tools (e.g., digital signatures) solve it
• Challenge #1: Feature phones continue to be used in the developing world
– Difficult to program for crypto
– Want platform-agnostic solutions
• Challenge #2: Want solutions with simple UI
– Minimize human computation
What Happens in Practice• Providers tend to use ad-hoc approaches for
authentication
– E.g., transmit PIN in plain SMS; use SIM Toolkit-based encryption (no application-layer security)
– Prevalence of Microsoft philosophy (security as post-hoc consideration)
• Systems have been attacked already
– Multiple reports of receipt forgery in Kenya and India (some involving SMS spoofing tools) [P13]
• E.g., agent issues fake receipts to customers, steals cash
– More have possibly taken place but unreported
– High attack likelihood in the future• Transactions are small individually, but large in aggregate
Our Work• A set of solutions to address authentication issues in
branchless banking
– Platform-agnostic approach: no phone programming required
– Solutions are provably-secure (under reasonable threat models)
– Solutions are usable by naïve users; one already deployed at scale by an Indian provider
General Approach• We use two approaches in our solutions
1. Human-computable cryptography: Use basic human capabilities for implementing secure authentication
2. Non-cryptographic authentication: Authentication through increased interactivity
User Authentication• General idea:
– 2-factor authentication with PIN as first factor
– Each user holds a unique security token (a codebook) with 10-digit one-time passwords (OTPs); combination of OTPs and PIN used as transaction signature [PC10, PNB10]
– Robust to loss of PIN or codebook (not both)
– Unlike traditional use of OTPs, here OTP is used to encrypt the PIN: more secure.
– Deployed by Eko (India). Daily transaction volumes of over 1 million USD.
Say PIN = 2350. If current OTP is as above, signature = 7583
SMS Authentication• Token-based approaches also work for message
authentication, but harder
• Technique 1: Use OTPs to create numeric signatures on SMS content [P11]
Message M
Key KSignature S
Bank has a copy of K; creates signatures using it. Customer verifies S using K
Example scheme:
M = 4500 INR
K
S = 9962
SMS Authentication• Token-based approaches also work for message
authentication, but harder
• Technique 2: Visually-verifiable signatures
– Based on a technique due to Naor and Pinkas [NP98]
– Our contribution [P12]: increasing space efficiency of visual authentication schemes when applied to textual messages
– Still, big transparencies per user (linear in #messages)
Message M
Key KSignature S
K is a transparency; S is an image. K
overlaid on S gives:
M
SMS Authentication• Modern technologies should lower implementation
cost of token-based SMS authentication (e.g., compact transparencies)
Mastercard’s latest “display card” technology – card with embedded LCD display (and keypad)
SMS Authentication• Token-based SMS authentication is compelling, but
has issues:
– Variability across phones reduces deployability
– Hard to enforce usage: human effort required is significant
• Alternate approach: trade off “some” security in favor of deployability
– Focus on the key security threat: SMS spoofing
– Question: can we prevent SMS spoofing without relying on security tokens?
– Our answer: Yes, we can!
Key Idea
Message M
• Enforce greater interaction between user and server in transactions
Beep
Message M’
Did the bank send this?
If pendingTxn(C), M’ = M
Else, M’ = “Fail”
Customer C
– Beeping is enforceable as a protocol step: “Your transaction fails if you don’t beep”
– Beeping (missed calling) is also effort-light
– For security, ensure that: customers beep at a trusted number; failure messages reliable
Beep-Based SMS Authentication• Key result: A protocol that is provably secure against
spoofing adversaries [P13]
• Various extensions possible
– Distributed beeping gives security against certain types of man-in-the-middle (MITM) attacks
– Replacing beeps with messages (e.g., “I need to deposit X with agent A”) increases flexibility e.g., delayed transactions
– Destination-shuffling enables user authentication
– Repeated beeping can potentially increase SMS reliability
Summary• Main contributions
– A set of authentication tools for mobile-based branchless banking systems
• Use of security tokens in novel ways to implement both user authentication and transaction authentication
• New “missed-call” scheme for transaction authentication
– One solution deployed at scale, others being tested
• Open issues
– Our work addresses authentication only; the issue of transaction privacy still open.
– Good security practice requires user vigilance and awareness. How do we effectively train users?
References
• M-Pesa statistics: http://memeburn.com/2012/05/mpesa-what-does-kenyas-mobile-darling-look-like-five-years-on-infographic/
• RBI data on financial inclusion (2013):http://financialservices.gov.in/banking/Overviewofefforts.pdf
• [PC10]: Saurabh Panjwani and Edward Cutrell. Usably Secure Low-Cost Authentication for Mobile Banking, in Proc. of ACM Symposium on Usable Privacy and Security, 2010.
• [PNB10]: Saurabh Panjwani, Prasad Naldurg, Raghav Bhaskar. Analysis of Two Token-Based Authentication Schemes for Mobile Banking, MSR Technical Report, 2010.
• [P11]: Saurabh Panjwani. Towards End-to-End Security in Branchless Banking, ACM HotMobile 2011.
• [P12]: Saurabh Panjwani. Space-Efficient Visual Authentication of Text, Bell Labs Science Workshop 2012.
References• [P13]: Saurabh Panjwani. Practical Receipt Authentication for
Branchless Banking, ACM Symposium on Computing for Development (DEV) 2013.
Security Formalism• For security, a branchless banking protocol should
have two properties:
– Soundness: if user U believes that money transfer worth Xtook place from U to V, bank must record the same
– Completeness: if the bank records a money transfer from Uto V worth amount X, U (and V) must believe the same
• Threat model:
– We assume an adversary who can
• Corrupt protocol users (i.e., decide who is malicious)
• Send arbitrary messages (call/SMS) with fake sender IDs (e.g. spoofed SMSes)
• Can tamper with protocol messages during transit
SMS authentication achieves this
User authentication helps achieve this
Security Formalism (contd.)• For end-to-end security, need to ensure:
– Messages include timestamps (which are also signed)
– Users “alert” bank whenever a failure state is reached (e.g., msg and signature mismatch); we assume secure channel for alerts (e.g., user authenticated voice call to bank).
– Users return output (“success” or “failure”) instantly after message verification/alert call; bank’s output is deferred slightly
(to accommodate possible alert messages).
• Main Claim: If a protocol implements secure 2-factor user authentication* for user-to-bank messages and secure message authentication** for bank-to-user messages, then it is sound and complete.* see [PNB10] for a definition of 2-factor user authentication** use the standard security definition (for message auth. codes) for this
Top Related