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?

Thank you

Saurabh Panjwani,

Bell Labs

saurabh.panjwani @ alcatel-lucent.com

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

Security Formalism (contd.)• We also consider security in a relaxed threat model

(where no man-in-the-middle attacks are allowed)

– If a protocol implements secure 2-factor authentication along with missed-call based message authentication, it is sound and complete in the relaxed threat model [P13]