So, security on our phones, and we'd like to use publicly endorsed standards - 10 out of 10 security experts prefer it and describe any non-standard (proprietary) security as "Snake-Oil".
Q: HTTPS/SSL is used for e-commerce everywhere, why not use it for mobile-commerce?
A: a number of issues make it impractical for mass-market mobile use:
- Not available on all phones
MIDP1 phones don't support SSL connections. MIDP1 represents fewer than half of the JAVA enabled phones in circulation in the West, but a significant number and a greater proportion in the developing world where used handsets are popular. To develop systems that won't run on these handsets is to needlessly cut down your potential user-base. - Out of Date Symmetric Ciphers
Some handsets have built in HTTPS/SSL for their browsers and many handsets use the easiest to develop, and alas the oldest ciphers in their SSL/HTTPS. Some of these ciphers have known vulnerabilities, and should not be added to new systems, for example RC4. US Govt CERT Advisory: SSL/RC4 passwords easily crackable; solution: Do not use RC4 encryption.
This is alarming as most mobile browsers which have SSH/HTTPS only use RC4. Try connecting to your bank, and look at the page/connection security details, and I'll bet it says that you are using RC4. It should be retired, not built into brand new systems.
"RC4 encryption algorithm is not a Federal Information Processing (FIPS) standard and probably won't ever be because network professionals see RC4 as rather weak in terms of message authentication and integrity." - William Burr of NIST - Only secures TCP data
The built in SSL/HTTPS cannot be used to add encryption to locally stored data, SMS, MMS, Bluetooth, IrDA or any other connections used by the mobile device, so anything you are doing on these channels is in the clear. This non-TCP data is important because many users don't always have the correct data settings for java networking, or know how to use them, and you can greatly help them by being able to "fall-back" to encrypted SMS to make your purchase, as you will find in our latest apps. We will cover networking issues in a later blog post. Also people have attacked and opened the RMS data stores on phones, so your stored details are not safe unless you have taken extra steps beyond standard MIDP behaviour. - Certificate Problems
Many handsets don't have a full complement of root certification authority certificates installed. This means that your HTTPS server certificate will often not be recognised as a properly authenticated cert (throwing worrying messages to the user, and completely voiding the trust relationships that make SSL/HTTPS useful), and the phone will NOT CONNECT AT ALL to your server from Java as invalid and self-signed certificate warnings are not fed to the user when the connection is made. For example one of our test applications was unable to connect to the major and popular London Underground Oyster site, or the Barclays bank websites on most Nokias, because of certificate issues.
It is impossible on almost all handsets to install any new certificates, so regardless of the technical abilities of your users or support teams you will not be able to overcome this issue; the FAQ site for Opera mini also acknowledges this issue.
One final confusion: the original phone model from the handset manufacturer may have contained a valid Verisign or Thawte root cert, but sometimes the mobile network operator will remove that and put in their own certificates instead at the customisation stage, so you can't reliably know what certs are installed even if you are sure which model of handset you are talking to. - Slow to initiate
HTTPS and SSL require several connections to establish a secure session. On a fast PC network with low ping times this isn't much of a problem as the amount of data sent is tiny. However on a phone with two second ping times, commonly up to six seconds, each connection (regardless of amount of data) takes serious time to travel to the server and back. On many handsets the cryptography required on the handset side can also cause delays - in our experience up to eight seconds on the encryption alone, even on a recent MIDP2 Nokia.
- Vulnerabilities in WTLS/Secure WAP - also not end-to-end
Most handsets implement WTLS (Wireless Transport Layer Security protocol). This is similar in intent to SSL, but with some bits chopped out to make it easier for phones to use with their limited memory and small CPU. Once the data gets to the WAP gateway it is decrypted and then re-encrypted into an SSL/HTTPS session to the destination server on the internet.
Unfortunately the protocol allows the use of very weak, or no encryption at all between the phone and the WAP gateway. There are several known cryptographic attacks on WTLS too, detailed here.
Worse, the data is all in plaintext within the WAP gateway i.e. this does not constitute end-to-end encryption - it relies on network engineers not to read or sell your data, unknown 3rd parties to maintain the server security, and defend the WAP gateway from compromise.The risks of leaving your data in plaintext at the WAP gateway (or anywhere inside the mobile network) are wonderfully demonstrated by the recent revelations that hackers have gone undetected inside mobile networks for years - see stories of accidental discovery of long term hackers in Vodafone Greece and T-Mobile, and also of network engineers snooping at user data passing through their systems for romantic reasons.
[Open question to readers, because I'm suspicious but not sure: when using the default WAP Gateway, not an Internet Gateway, for your mobile data connection, are you able to use full end-to-end HTTPS or does the WAP/UDP protocol drag everything down to WTLS? If it did, all your WAP based banking may well be clear-text in the Wap gateway.]
Q: What about Opera Mini - the advanced one for MIDP2 that has some security built in, can't we just do e-commerce through that?
A: It's not end-to-end encrypted - so you have to trust Opera's engineers, servers, sysadmins and maintenance contractors with your plain-text passwords and credit cards. Again they chose to use the RC4 cipher of all things, which should be retired, not built into new products.
In good news though, they do seed their Random Number Generator correctly, which is disappointingly rare in mobile security.
Q: What about SMS - internet based hackers can't see them, as they are all in the Mobile Network Operator's walled gardens?
A: Same problems as WTLS, because network engineers, 3rd party service technicians, servers, and base stations in the Mobile Networks are not policed to PCI DSS standards (required for sending/processing credit cards).
Additionally an SMS may not just be going through the UK networks that have familiar brand names. SMS's are often transferred internationally across the Wild Wild Web through various companies that you have never heard of, and may originate or terminate in some very odd countries where you wouldn't dream of leaving your credit card.
The infamous case of bored network engineers poking through other people's MMS pictures of naked girlfriends (and forwarding them on) is nothing compared to what may happen when and if large amounts of credit card data start to get sent through SMS messages. After the case of O2 engineers abusing their access to SMS messages, analysts Gartner said "The contents of SMS messages are known to the network operator's systems and personnel. Therefore, SMS is not an appropriate technology for secure communications. Most users do not realise how easy it may be to intercept".
If I was thinking like a hacker or spy, the first thing I would do is place logging hardware in a few base-stations, which see plenty of data passing through them. Lawyers, government ministers and top business people leak enough valuable information without throwing credit cards into the mix. It should also be pointed out that it is child's play to fake the sender number of an SMS.
Q: What about the open source Bouncy Castle Light Crypto Libraries?
A: A jolly good start, but they're not THAT light. Adding a simple security system using Bouncy Castle with Asymmetric Key exchange, a Symmetric session cipher and a Random Number Generator (the bare minimum for secure comms) adds over 22Kb to the basic app, even after you've stripped unused code and obfuscated it. With the very oldest handsets having JAR size limits of 29Kb - such as the Nokia 6310i, which despite its age is still very popular, people clinging to it like limpets and some major companies still issuing them NEW to their executives (we learned in a recent meeting). Common MIDP1 handsets have 64Kb limits - Playtech saw more than 1 in 10 downloads go to these handsets in the first half of 2007, a substantial market share. Most of the work in mobile dev is making things small, and use as little memory as possible, so that you've got plenty of room for pictures and text and all that code that needs to glue it all together smoothly.
What a moaning session! I do apologise, but there's no point beating about the bush.
Solution: (a suggestion, not the only solution)
To reliably create encrypted sessions from mobile you have to build a truly lightweight encryption/decryption system into your applications. This allows you to support every possible phone and also control the choice of cipher, the encryption strength, and eliminate certificate incompatibilities. It also allows you to encrypt data stored on the handset, SMS messages, or communication on other channels, which HTTPS and SSH do not.
This is why Masabi built EncryptME, a 3KB security component for J2ME that allows all phones to make encrypted connections over SMS, GPRS, WiFi or just about anything else. EncryptME is also US Government verified and certified, so you don't have to take the our word for it that it does what it says on the tin. It provides 1024bit RSA, 256bit AES and an approved RNG, if you were wondering.
Additionally, by being standards compliant you can continue to use standard server cryptography components, for example those from Sun, Microsoft or our friends Bouncy Castle. Even against phones with built in SSL/HTTPS, EncryptME is between 6 and 20 times faster on a mobile in live tests.
And good choice of algorithms isn't enough! You must use them in a wise way with user education, good seeding, padding, key management, and protection against replays, insertions, concatenations, man in the middle, phishing and all manner of other attacks that cryptography alone will not solve - but that's another story, to be entitled "When good crypto goes bad".
Good Examples:
- Opera Mini Advanced: MIDP2 only, but has their own crypto with proper RNG seeding. Well done, apart from lack of end-to-end and use of RC4.
- Playtech Online Casino: supports almost all MIDP phones, built in encryption, 1024bit RSA and 256bit AES, with player key-strokes during gameplay used to seed RNG.
Bad Examples:
- Opera Mini Basic: no encryption, but allows users to interact with their secure HTTPS banking sites while sending cleartext usernames, passwords or credit cards over the internet. To be fair they do admit it here with a good diagram.
- Mobile java apps that rely on SSL or HTTPS - they won't work in all cases, and slow down user interaction where they do work.
- Plaintext SMS apps which invite you to send Credit Cards or other sensitive data.
- Anything using "security through obscurity" or "snake oil" where they don't reveal what they do to protect your data.
Also a special mention for the use of the word "patented" in security. It may help to raise a company's valuation in the eyes of Venture Capitalists and investors, but to a cryptographer (or hacker) "patented" doesn't mean safer, or correct, or even clever. It only really says that someone has sent it on a piece of paper to their local Patent Office and can be a good hint that very few people have had the chance to check it and test it, especially if this patented technology is only used by one or two companies.
In Java reverse compiling (reverse engineering) end user applications is pretty straightforward, so the secrets will come out pretty quick as soon as someone takes an interest in your product.
I hope that gives you some idea about security on current generation mobiles. My next post will cover getting good Entropy for your secure random number generator on mobile, a need highlighted in a timely fashion by Brian at Mobile Crunch.
Comments: there are no completely secure systems in the world, and security only gets better through challenging, discussion, testing, probing and questioning. Please post your questions or corrections if you have any, and I'll do my best to respond, or correct mistakes/omissions as they are pointed out.
Also please feel free to post good examples of clear and honest mobile security if you've seen some, but don't be surprised if we start poking them and asking questions back at you!
