Barclay's recently launched "Hello Money" in India (See website). Based on face value this is commendable and it seems as if a great job was done. It is always good if progress is made in mobile banking. I wish them many subscribers and of course a positive business case.
The one topic that I do find intriguing and would like to place on the table of discussion is the claim that it is secure. (I assume that this means that Barclay is happy that it conforms to their banking security policy). Based on what I have seen on their website, I would like to argue that this is not the case...
USSD traffic through the GSM network as it travels from the handset via base-stations and the radio network through the IN platform is often in the clear. This means that it can be intercepted by engineers skilled in the art of GSM traffic. It is virtually impossible to defend against such an attack (primarily because the bank does not have any control over this protocol). This means that it is possible to steal security information that would allow some-one to perform a fraudulant transaction.
Usually banks caters for this risk by limiting the functionality available through USSD-based mobile banking. Yet, Barclays have decided to allow fund transfers to unregistered Visa cards on a once off basis. This creates a serious potential security loophole. Am I missing something, or have they been ill-advised?
Thursday, July 24, 2008
Subscribe to:
Post Comments (Atom)
19 comments:
Barclays, along with the other banks, have to put their mobile banking on hold for now. See:
http://rbi.org.in/scripts/NotificationUser.aspx?Id=4377&Mode=0
http://in.news.yahoo.com/241/20080723/1264/tbs-rbi-asks-banks-to-put-mobile-payment.html
I'm not sure if you have read the draft of the operative guidelines RBI released. You might be interested in it --
http://www.rbi.org.in/Scripts/BS_PressReleaseDisplay.aspx?prid=18432
USSD is encrypted over the air (follows same setup path a phone call) and infinitely more secure than "bank by phone" where issuing analog DTMF tones to an IVR over unsecured call paths can be recorded and reverse mapped by any (unskilled) hacker.
Thanks for two excellent comments on this blog. I have now read the RBI guidelines and will publish a post on why I think that Hello Money does not conform.
It seems that many misconceptions exists regarding USSD. I will also blog on this. Suffice to say that, yes, USSD is far more secure than IVR based banking. Question is: "Is it secure enough for banking?"
now we in2 security by degrees rather than decrees :)
show me a bank in the world that has not "certified" bank by phone (IVR) ... the most insecure method of all.
the more prudent Q is what does the channel support?
Banking via XYZ can be secured by restricting the feature set. For example preventing user from adding a new beneficiary would neutralize any hack attack as funds could then only flow around the secured pond.
I think we are absolutely in agreement. If you read the original post, you would see that I agree that USSD for Hello Money is great, except when paying a previously unknown credit card - which according to the website is allowed.
Anyhow, starscriber, I would love to talk to you directly. why don't you send me a mail to Hannesvr AT hotmail DOT com?
I totally agree with the fact that USSD is not a secure banking protocol as it hugely depends on an environment outside of the bank’s control. USSD runs over the GSM 3.08 channel and is encrypted under the A5/1, 5/2 or 5/3 standard. This however depends solely on the way that the mobile operator has deployed their GSM environment.
In the USSD gateway that resides inside the Mobile operator there is a translation done from the native USSD to HTTP/S. this HTTP traffic is then send to the bank. If there was a rouge employee inside the mobile operator with the right skill, they could theoretically tamper with the message.
In other words the bank cannot guarantee confidentiality, integrity or even availability to their customers.
and breach @ gateway points to gate keeper ... EXACTLY where u want it 2b
when mobile == wallet handset (theft) is the only security issue:
SMS has clear text trail (sent items)
J2M can b disassembled
only USSD is forensically undetectable
it leaves no fingerprints on the phone (cannot be recalled)
further mobile money market is the mass unbanked and the "great unwashed".
java is a "coffee break" for the haves. the have nots can barely afford telephony let alone data and even 800pd gorillas have insufficient muscle to change mass dial behavior
Starscriber, as much as USSD is a good tool to deliver mobile banking solutions, it also does have it downsides. It does not help a healthy debate to ignore these. The fact that it is "forensically undetectable" also makes non-repudiation impossible. This is an essential component of any secure system. (Go and think about it). It is quite easy to replay a USSD message or mimic a USSD command from a another source than the phone it supposedly originated from.
You also seemed to forget about mentioning SIM based applications as a very secure, easy to use, available on any phone channel.
was simply sharing "guiding principals" rather than debating and much less "solutions"
anything more and that would b "consulting" (and unlike blog free.not :)
USSD is forensically undetectable from the *handset*. non-repudiation would imply no-pin and certainly never suggested that
also cannot fake USSD (telephony and SMS) MO: that is Mobile Originated
what u allure to is only on trusted link (SMMP) where provider can set TON and NPI and even then entering gateway OUTsideIN rather than secure INsideOUT (MSC > ) path
and even then missing PIN
USSD (as "u" know it) has one and only one flaw: user engagement sux. "command line dos to ms windows point and click"
STK anything but seamless (gofind menu) and universal (handset dependent)
hannes
read your comments with interest.Barclays soultion has addressed the security issues you talked about.As the telecom operators in india are on A5/3 standard,the USSD session is encrypted and further they have implemented HSM at the operators end ensuring end to end encryption
Can you folks comment a bit on the usability aspect of USSD too? I tried using mchek (in India) and I personally find it not very user friendly -- because of the low timeout, it's server initiated or you have to send an sms to get started, you have to press OK before you can give the response, and if something goes wrong you have to start all over again.
I am not sure how much success mchek has had from USSD but lately they seem to have moved to a Java application that provides that same functionality, with the communication over SMS.
Do you folks know about other banks outside India that deployed USSD for any application? How has the response been?
like any "narrowband" medium USSD design and screen flow is absolutely critical to success. USSD service invocation is also problematic.
can u detail mchek screen flows step by step?
u mention sending SMS to initiate. what is the message sent and what is the (USSD) response received ...
Starscriber is right. Design of the USSD service is critical from a usability perspective. According to my knowledge, many mobile banking USSD services have been launched all with limited transaction volumes. One exception is the FNB deployment in South Africa where SMS and USSD are mixed. (https://www.fnb.co.za/personal/transact/accessyouraccounts/cellHowDoI.html). Problem in South Africa with USSD is that the Operators figured out how to bill for it and it is thus not low cost anymore.
The majority of high take-up mobile banking success stories that I am aware of are STK SIM-based solutions (Smart Money, mPesa, MTN banking, Celpay and others) with HUGE volumes.
Hannes,
I see that you already had a pretty heated discussion regarding USSD. After your follow-up comment I went ahead and found that currently it is more secure than sms and plus the response time for interactive USSD-based services are generally quicker than sms based services. Just another point I thought I would add to the benefits of USSD.
Hi Hannes,
Thanks for an interesting discussion.
You mention that the "Problem in South Africa with USSD is that the Operators figured out how to bill for it and it is thus not low cost anymore" - although USSD is charged for, the rates are extremely low and are definitely not a barrier to entry. Unfortunately I don't have exact rates to hand.
BR,
Lynnsey
BTW - I work for FNB and used to work for MTN SA but this post is in my personal capacity.
Suresh, i noticed that you were mentioning that Barclays has asked the operator to put an HSM in the middle. But that does not rectify the security lapse. For an HSM to work properly, there needs to be some mechanism (application) at the mobile equipment to encrypt data. Unfortunately, in USSD's case, there isn't any application residing at the ME. The solution which Hannes is proposing instead can use HSM capabilities. Could you please elaborate how else they've made USSD secure, because current information seems insufficient?
Hi, I wonder which company has made marketing research for the Barclay, before they have decided to invest into Hellomoney?
Can anyone suggest please?
Thanks,
Anar
We are planning to invest in USSD based mobile payment service.
Can anyone suggest please which company has made marketing research for Barclay?
I will appreciate if anyone helps me.
Thanks,
Anar
Post a Comment