Cellphone security re-think

I found the case study of how not to implement mobile banking security as described on the Digital Soapbox very interesting. It is a fact that we cannot implement Internet banking security paradigms directly (as is) on the mobile phone. This is because of the following reasons:

• Many security advances on the Internet (like virus checkers, firewalls, security warnings etc.) have not been implemented on phones. It is also unlikely that these will be implemented on phones as the capacity and computing speed is such that it cannot mimic computer functionality.

Phones have characteristics that computers don't have that can be utilised to make security more powerful. Think of the characteristics of the SIM card, the uniqueness of the Phone ID, or cellphone number. (Computers do not have this). GSM have built-in security on the bearer channel where-as computers have to switch their's on with SSL. One should think about using cellphone characteristics in mobile banking.

The most classic pitfall (as is described on the Digital Soapbox) is where Internet banking security is enhaced through the cellphone channel and this is then transported as is to celllphone banking. Security that have been based on dual channels is suddenly reduced to one channel with inferior security protection... Problem.

• 
  

Security is in the eye of the bank

It is a common saying that security is only as secure as it is perceived to be. It is quite possible to develop many different security solutions that can protect what it is supposed to protect economically. (The cost of the system is less than the fraud that could be committed in the absence of the system)


Unfortunately this is not the criteria for a successful security solution that will be deployed and used. Rather it is if the security solution is perceived to be secure. In the case of mobile banking, the question should be asked "perceived by who?" and "what will convince them that it is secure enough?"

In the case of mobile banking, I would like to argue that it is not end-consumers that are the primary evaluaters of security. The key is not to ensure that end-consumers perceive mobile banking as secure, but rather bankers. In my experience, it is the banking fraternity that are uncomfortable with mobile banking security more often than not. Only if they are made to be comfortable with the security is it possible to launch a mobile banking solutions. Even when the end-consumer would have been happy long-ago, or even if the security solution can be proven to be economically sound, bankers will still resist.

So what is it that banks look for in a mobile banking solution:

• Conforming to banking standards. Banks are comfortable if some-one else says something is secure (VISA or the PCI etc.) Problem is that few of these standards exists that can be applied directly to mobile banking. Also read this blog-entry.
• Bankers like security if it looks like the security that they know and understand. They like PIN-blocks that are never stored and is never in the clear. They like digital security keys where the master keys are well-managed (preferably by a bank or a banking body)
• Bankers like security where the liabilities are clearly defined in the case if something do go wrong.
• Bankers like security systems where all of the functionality/components are under the direct control of the bank

Generally bankers are not enthused by maverick, sharp and innovative solutions to manage security, but rather using tried and tested approaches that can be mapped to existing procedures and internal banking rules.

In deploying mobile banking solutions, it is critical to keep this in mind.

PCI compliance for mobile payments

Many research reports and experts warn about the risks of allowing fraudsters and criminals access to sensitive credit card details. It is especially operators of financial and payment services that tend to be the biggest targets. Quoting Jon Kerr from Verisign: "It's no surprise that online banks and retailers are some of the most popular targets for identity theft since so many personal details are required by users,... With the average UK consumer worth over £10,000 to criminals, it's clear that each of us is a target."

It is because of this threat that the industry decided to publish a standard that a bank or payment processor should adhere to in order to provide acceptable protection to cardholders. This certification is known as the PCI compliance and is being driven by the Credit Card Associations. The objective of PCI compliance - to protect the consumer - is commendable and should be accelerated. Customers should be educated and should take their business away from banks and payment operators that do not comply.

An interesting question is how the providers of mobile payment solutions should (or should not) comply with PCI standards. In as much as mobile payment solutions touches card information the application of the standard is clear: None of the card information must be in the clear and it must not be possible for an un-authorised person to get access to this information. But what if no credit card information is used? What if the routing of payments are made on the basis of a subscribers telephone-number (as is often the case)? What should the minimum conformance be.

This topic is much more complex to deal with in the space of a short blog, but it is clear that the mobile payment industry should develop unique compliance requirements. Obviously this would be very similar to Card PCI compliance (catering for instance for access, un-authorised actions, reporting, physical protection etc.). But what about not displaying a telephone number when you could potentially see phone numbers of some-one just call you? What about look-up tables and what should the controls be around security elements?

It could be worthwhile to develop some of these rules pro-actively.

Transaction Manager (Part One)

This is by far the most complex and often overlooked component of mobile banking. If one were to analyse the fundamentals of mobile banking, one will get to the conclusion that good mobile banking design is about the management of transactions originating on a phone and terminating on a bank account - and many similar types of transactions. A well-designed mobile banking system caters for the support of many different transaction flows. In addition proper consideration should be given for error conditions or when external sources are not available.

A transaction manager should cater for transactions to and from the following subsystems:

• The transaction manager must be able to accept and send messages to the Mobile Channel. This should preferably be done in such a way that it can be done independently from the actual handset solution that has been deployed. Communication to this channel is very time sensitive, because a human would ultimately be receiving these messages. As such time-dependent actions should be configurable.
  
• Applications that are often integrated into mobile banking offerings (called Third Party Applications) must also be integrated. Typical systems that the transaction manager must be able to talk to are bill payment, pre-paid airtime, COD systems and more.
  
• Transaction Clearing is a often overlooked outcome of a mobile payment transaction. a well-designed transaction manager must be able to integrate to and support transactions to and from systems like Money Remittance systems, Central Clearing systems etc.
  
• A mobile banking transaction will ultimately lead to a debit and credit transaction on some account, purse or card. The transactions to and from these Value Stores can be quite complex.
  
• Many different security techniques can potentially be supported. This could be PIN-based, or User-ID and password. It could utilise CLI or certificates. The transaction manager must be able to route transactions to the correct source to verify security and adhere to requirements that may be applicable.
  
• The switch must record transactions in such a way that it is fully auditable and that it can be proved that the operation is fully in compliance with regulations. A well-designed switch will cater for this too.
  

In addition, the transaction manager must be able to string together different transactions in a logical way. It should have the capability to roll transactions back if one component fails or is not available. It should also have the ability to place transactions in pending status and have the ability to resolve pending transactions. This should, according to my experience, be possible without human intervention as it is possible to get hundreds of thousands of transactions in a pending status (when a pre-paid top-up system is not available for a time). When the failing component comes on-stream again, the transaction manager should be able to resolve the transaction in pending state automatically.

In the next blog, I will discuss characteristics and special conditions that a well designed transaction manager must cater for. I will also discuss critical conditions that the system will have to cater for and typical solutions to this.