USSD Security. Part 2.
As a follow up to this post, lets talk about why James Bond style encryption methods don’t necessarily guarantee the security of your service. When the security systems are in place and the whole infrastructure seems invincible and you can finally lean back in a chair…Oh wait, is it really so?
You can have the best secure algorithms and technology but this doesn’t guarantee that you are 100% safe. Today’s highly advanced computer criminals are not going to expend any effort with hacking the sophisticated encryption methods you have set in place. Instead, they focus on the weakest link, and this, in most cases are the people.
Social engineering is the term coined by the famous hacker Kevin Mitnick. He used psychological manipulation techniques to get confidential information, instead of expending energy and hacking into the system. These methods exploit typical human traits such as gullibility, curiosity, sympathy and greed, a much easier and effective strategy.
Phishing is one method that is widely used. Phishing can be used to obtain credit card details, passwords and usernames by claiming to be a legitimate company. Generally, frauds send e-mails which directs the recipient to a fake web site, that looks like the exact replica of the official site, and it is there that users are asked to enter their sensitive data.
In the case of mobile phones, messages claiming to be from a bank request users to call the number provided in the message. After dialing the number, users are asked to enter their account number and PIN. Gullibility kicks in…
When creating a service, bear in mind that validating the identity of your users is the primary security task that should not be forgotten. At the same time, the users must have a system where they can identify that they are interacting with the genuine service and not a replica. A challenge-response scenario is the easiest way for both parties to prove that they are who they claim to be. For example, some banks provide customers with a picture which appears when logging onto their account, thereby letting them know that it is a genuine web site. For banks to know that it is actually you on the other side, they send two SMSes with passwords for your account. When you enter the first password, the dialogue prompts to “enter the new password”. At this stage, even if a fraud obtained your primary data, they will not know that the new password requested has been sent to you via SMS, and will therefore not be able to complete the transaction.
What these examples show us, is that even with all the technologically advanced security systems that banks put into place, it is crucial to factor human error and vulnerability into the equation, as they can make even the most sophisticated security systems redundant.
What does one do?
- Invent a scenario where both parties identify each other as the genuine article.
- Only then get yourself busy by implementing hi-end encryption and all that follows.
USSD Security.
Ok, seems like there is a lack of info on USSD security. With a growth of interest in mobile payment and banking, we really have to clear this one out. If you are not familiar with USSD, read basic facts about it here.
There are two ways for villains to sniff the data – in the air and when it is stored on servers. The thing is USSD signal itself is not encrypted when it is transferred over the air. People seem to talk a lot about it being a big security hole. But the GSM channel that carries the signal has built-in encryption, authentication, authorization and accounting protocols. It’s not like an easy thing to hack. It will cost a copious amount of cash to buy equipment which can do it. And then villains have to chase you wherever you go to trace the signal. And then you make a ten dollars transaction.
Aghh, too much hassle, right?
Imagine that bad guys had no success with your ten bucks. Then your signal arrives to operator, where data is decrypted within network. No need to panic, as operators have their own system of security. If you need you can ask for end-to-end encryption, when data is encrypted from the user to your service all the way through. Though, governments usually don’t allow operators to do it, as they are quite curious.
Now, all the aforementioned stuff applies to SMS as well. So USSD is, at least, as secure as SMS. Which is the most popular format for mobile commerce. But unlike SMS, USSD is not stored on servers for months and years to come, and it doesn’t leave traces on your mobile phone, as it is session-based.
Nobody really questions SMS, as nobody really questions security of credit cards. Well, maybe someone, but the cards are still widely used. This month a San Francisco man was sentenced to 13 years in federal prison for stealing 1.8 million bank and credit card numbers. Guess what? Banks are still there and credit cards are alive and well. It is instilled in people’s minds that they are safe, so they continue to use them. Thus finding holes in USSD is not the best idea – there are plenty of popular types of money transactions which are often hacked but still widely used.
The point is – it is useless to discuss the security of USSD out of service context. Firstly you need to define what your service is, what money is transferred. With default settings, USSD may not be secure for one million dollar transaction, hence you will have to adjust the channel for your particular needs. Remember also, that scenario for a service can provide high level of security by itself.
Follow these steps, if you are thinking of using USSD:
1. Specify the sum of money.
The level of security depends on the quantity of money involved. If your service is using micro/small payments, then standard GSM security is enough. For bigger transactions you would probably want to install additional encryption. Remember, though, better locks cost more, so count your money too.
2. Analyze network infrastructure.
Look at the whole network and see what parts of it don’t meet your security requirements. This may be the part where a signal goes from the mobile user to the operator’s server and then to your server. In this case, you can encourage users to install java applications to enhance the level of security.
If you are concerned about potential insecurity within the operator’s network, negotiate your needs with the operator. Keep in mind, that in many countries encryption/decryption of data within an operator is regulated by the government.
Finally, don’t forget about protecting your own service.
3. User experience is numero uno.
You can bury your business if clients have to go through numerous steps to install protection, such as going to different offices, buying a new SIM card, etc. Keep the balance between security and user experience. People want it simple.
4. Tell everybody how safe you are.
Make people trust your service by executing a marketing campaign, giving them guarantees, etc.
Don’t put security on the top, look at USSD from the point of business opportunity. It certainly can provide you with one.
We’ll certainly come back to this topic again later.
