Masabists

Masabi's mates "Hamfatter" on Dragon's Den

2008-07-21T09:52:00.009+01:00

One of our recent clients, the band Hamfatter (who we built a mobile promo site for) are on UK TV's Dragon's Den tonight, making the normally aggressive investors sing for their supper, which should make for interesting viewing.

They should be on GMTV and Radio2 on Tuesday morning too, touting their alternative "direct" route to their own music promotion, using all the new distribution channels, and keeping control in the hands of the band.

To see the mobile site and get free MP3's and other mobile stuff,
text HAMFAT to 86688.
(text costs 25p plus normal network charges, to cover the response SMS messages - we'd charge less if there was a cheaper SMS that covered the cost of the response SMS)

We love their music too, so go and buy their new single for just 70p at play.com or itunes!
(and maybe one day you'll be able to buy music for download or postal delivery direct from the mobile using Masabi's credit card sales technology - who knows? Watch this space....)

The Guardian "the business model would allow the group to make around £3.50 an album, as opposed to the 30p they would get in royalties from a big label"

The Times "Indie band emerges from Dragon’s Den with the cash - and a rock revolution"

The Independent "middle-aged telecoms tycoon looking to recapture his youth?"

'THE GIRL I LOVE' MUSIC VIDEO

NME - Hamfatter strike deal with entrepreneur on BBC’s Dragon’s Den

Our favourite Indie newbies Hamfatter have become the first band to sign a deal on Dragon’s Den.

Millionaire Peter Jones signed a £75,000 deal with the Cambridge trio in return for 30% of their profits.

The episode, filmed in April, was aired as the first in the new series on BBC 2 on Monday 21st July.

All five Dragons wanted to make a deal with the band but manager Jamie and band members Eoin, Jimbo and Mark chose Peter Jones.

“Peter Jones simply said ‘I just love music, I don’t play music but I love it.’ And that for me was something big“ said guitarist Jimbo. “…plus he was wearing stripey socks.”

“Plus he was like 7ft tall so he kind of feels like your dad.” added singer Eoin.

Jimbo summed up: “Yep, it was 33% music, 33% socks, 33% TALL.”

The band see the deal as a revolutionary new business model for the music industry, ignoring the concept of labels.

“We don’t get an advance so we’re absolutely skint.” explains Eoin. “But that is literally the only downside. We retain complete creative control over what we do; who we work with, release dates, tour dates, which tracks we choose. Hamfatter Ltd is essentially our own record lab el.”

“Normally record labels would be perfectly in their rights to rip out bits of your songs they don’t like and get somebody else to stick a bit in.” He continues “That way you end up with horrible mutilations of tunes. Hopefully, with Hamfatter Ltd we’ll sign a bunch of other bands and offer them a similar deal; ‘We think you’'ve got it, we won’t tread on your toes, here’s a bunch of money, make a load more for us please!’”

The new single is available digitally now and is available on CD and vinyl from August 11^th 2008. Keep checking the website for details of new tour dates coming soon.

Job Vacancy: Mobile Tester

2008-07-03T12:16:00.003+01:00

Masabi are looking for another London-based Mobile Software Tester to come and work at our offices on the South Bank – our ideal candidate will be flexible and multi-talented, main responsibilities would include:

Testing new applications across all our mobile handsets;
Researching new mobile announcements and identifying what handsets need to be purchased;
Acquiring new handsets, configuring them, experimenting with their Java implementations and documenting everything about them.

Good attention to detail, Quality Assurance and an interest in playing with the latest handsets is crucial, but we’re a small company so there are huge opportunities to take on other roles and an ideal candidate would be able to show they bring a lot more to the table, be it skills in tech writing, graphics, sound, usability testing – surprise us!

Note: FULL TIME or PART TIME roles available, and full training provided for keen applicants who can demonstrate good technology puzzle-solving aptitude and ability to learn.

Email those CVs over to jobs (at) masabi.com with the subject line "MOBILE TESTER JULY 2008" or give Ben a call on +44 207 981 9781 to find out more.

Please - NO AGENCIES!

p.s. for those that want to see the office that you might be coming to work in:
Photos:
Exterior
Interior, Interior again
Ed pretending to do testing

(map shows it has great access to food heaven at Borough Market, Tube stops at Borough, London Bridge and Southwark, and commuting access from the Thames Water Taxi, and trains from Waterloo or London Bridge stations)

MoMo Global Summit 2008 Talks

2008-05-27T09:21:00.002+01:00

Last week I gave two presentations (linked below) at the Mobile Monday Global Summit 2008 in Kuala Lumpur, Malaysia attending in my 'other' role as co-founder of MoMo Estonia, alongside speakers from the Mobile Marketing Association, AdMob and a range of other global companies.
It was an excellent event with a very interesting cross-section of speakers and attendees from around the world. Topics covered included mPayments and some great insights into China.

Judging When An mPayment Makes Sense

2008-04-24T13:39:00.005+01:00

The clip starting at 10:00 in this video (courtesy Ketai) starkly represents why many mPayment schemes will not succeed - simply because you can do something doesn't mean you will or should do it.
mPayments will certainly work, if they offer a significant benefit to the user over all alternatives, and are sufficiently easy and obvious that the user will think of attempting them. In many implementations I have seen, this is sadly not the case. Cash or cards are just easy natural payment systems, so the phone should only be brought in where these alone are not possible.
To succeed, the payment system needs to take the minimum of clicks and be resilient to error. It needs to interface seamlessly with the vendor/machine, just like a credit card terminal does in a shop - and just like dropping a coin in a slot does. If either of those is a viable alternative and the ease of use does not match them, you're toast.
This suggests that the most fruitful targets are payments for less tangible things you can predict you need whilst on the move - like tickets - where there is huge benefit in the convenience of eg. not queuing behind ten slow people for a machine which may be out of change when you reach it, whilst your train is pulling out of the station. You could even buy the ticket with your phone after boarding the train, an option which has disappeared on many UK trains in recent years.
Having selected a 'mobile friendly' payment, you need to work out what the best platform is for taking it - which involves weighing up a number of factors:

For a small rapid payment with limited options that can absorb a 30-60% margin, Premium SMS (PSMS) is king

The response can even include simple barcodes, though not the complex ones likely to become standard in most applications;

For anything more complex, margin sensitive or larger than a few pounds/euros/dollars PSMS cannot be used.

The mobile web implemented well will offer rapid access for a user

It can have big problems for multistep payments when the user is on the move (flaky connections, no on-client validation etc)
There are also security concerns with some handsets/networks;

For regular payments a thick client offers big advantages if it is written to work for the whole mass market

Greater ease of use eg. with on-client validation, interactive help etc;
More resilience to poor connections;
Lower data costs.

Even with a good target service, success is not guaranteed - the process still needs to be smooth and just work, something sadly lacking for so many reasons in today's mobile experience. To quote Andrew Orlowski on the Register:
"Today's mobile hypesters who confidently predict the web going mobile, forgot that the web competes with local knowledge. It's almost always quicker (and more fun) to be prepared in advance, or ask someone, once mobile. You can ask someone next to you, or you can call a friend: either is quicker than tapping away on a phone. Mobile surfing was crap when it was WAP, crap now it's an XHTML browser, and will be crap when it's an AJAX Widget."

mPayments are not for everything. Before embarking on a trial just place yourself in the shoes of a user and ask - why does this make my life easier than the alternatives at my disposal? Only continue if you can answer that question honestly. We're currently getting great feedback from rail ticketing and parking trials and we're pursuing a number of other clear business cases with our partners - but we're steering clear of Coke vending machine purchases as coins look set to have some life in them yet!

Masabi at Infosecurity Europe 2008

2008-04-22T14:26:00.002+01:00

This week Masabi are at the Infosec show at London's Olympia demonstrating our mobile solution for secure ID jointly developed with our partner GrIDsure. If you're interested in having a chat about our work in this area or mobile encryption and security in general feel free to swing by the GrIDsure stand (No. G245) and ask for either Ben or Alex.

Masabi to Present at Mobile Monday Estonia

2008-04-15T11:56:00.003+01:00

If you happen to be in Tartu, Estonia on April 28th then drop in to the next MoMo Estonia meeting at the lovely Ülikooli Kohvik to hear Masabi’s very own Giacomo present and myself take part in a round table discussion.
The event topic will be: "Software Development for Mobile Phones: Platforms, Users, and Managing Complexity." The full event schedule is:

"Creating services for the mobile phone - how to best serve users on the move" - Giacomo Biggero, Masabi, London
"Designing mobile user experiences - coping with the huge range of mobile handset types" - Sven Kirsimäe, MoMo Estonia
Open Panel Discussion "Future services - The best and worst" - experts from different mobile companies

For those not in the know, Estonia is a veritable hot-bed of mobile software development so the event is likely to be both lively and informative.

Ideas for Interoperability of Secure Barcode Tickets

2008-04-13T15:06:00.005+01:00

Barcode ticket security is a growing issue (we get asked about it all the time) and there aren't any standards yet for preventing unscrupulous individuals from altering the tickets that are issued.

Barcodes are being used as a form of virtual ticket that you can print from your PC at home or show on your phone screen to gain access to airport check-in, bus tickets, train tickets, promotional coupons, to gain access to a venue or be entitled to something valuable.

What do we want to achieve?
Barcode tickets that can be used to allow a virtual transaction, such as on a PC or a mobile phone to provide an instant ticket to the customer, with which they can instantly prove entitlement at a venue.
Ideally, to get the largest acceptance of barcode tickets, the designers of venue ticket systems should be free to integrate the ticket validation in whatever hardware or software they want to, and without any onerous security requirements - that way whatever cash registers (tills/EPOS), handheld scanners or gate systems that a venue uses can be used at their convenience.

Is there a problem?
As an illustration, mobile and print-at-home barcode ticketing on the UK railways is currently limited as follows:

Barcode tickets are only used on a few routes because they are not inter-operable from one company to another;
The reading hardware and ticket data formats are not agreed - each route uses different standards (although reading hardware is pretty similar);
Barcodes are only currently used for advance-purchase tickets (purchased the day before travel) because the ticket validation databases don't propagate quickly enough from the central servers to the on-train scanners to support walk-up (instant) tickets.

The same problems affect event tickets, gift tokens, and other uses where a more unified approach, and more secure ticket data would enable the convenience of m-ticketing to grow.

So, we need to get something in place that allows interoperability between barcode schemes, and also allows walk-up tickets to be validated without having to propagate all of the ticket databases.

Why do we need Security?
As the value of barcode entitlements go up, more people will take an interest in copying, altering, or re-generating valuable barcodes. Without the security, the ticket cannot be proof.

Why Interoperability?
When a ticket needs to be issued by one party, and checked by another party, then you need some way of the two parties being sure that the ticket is valid, paid for, and has not been altered between issue and scanning.
On public transport, some journeys swap on and off vehicles run by different companies - it is preferable that a single ticket can bought in one place and validated by each different company on the route, rather than the user having to separately purchase and show different tickets.

The data security risk is that, in most cases the ticket generator can be kept in a safe place (locked in your secure e-commerce server) but your ticket checking is distributed thinly around, at the entrances to venues, or often in a mobile devices held by bouncers or ticket-inspectors that can't be expected to keep your devices safe from unwanted attention or theft 100% of the time.

We will describe the security measures for simple (small) 1D barcodes that just contain a number, medium sized barcodes with some details and symmetric seals, right up to large 2D barcodes that contain the full details of the ticket and asymmetric cryptographic signatures to verify authenticity.

SMALL BARCODES (1D, around 12 bytes)
(images are all examples only - don't expect to scan them and get anything useful out of them)

Anti-copying using DRM (Digital Rights Management)
However you deliver a barcode, it has to be presented in a scannable format, which means that an adversary can always scan the ticket, and if they want to, change some details on the barcode and create multiple copies without DRM. People that have barcode delivery systems that use or rely on "forward lock" or DRM to prevent the barcode image being sent from one person to another are being blind to the availability of barcode scanners to beat all of their software. Also consider that OMA DRM for forward locking images downloaded to phones places laughably little protection against an assailant armed with such exotic tools as a web-browser and a text editor.

Anti-copying using a local database at the scanner
Storing the serial number of each ticket scanned, and flagging/halting duplicate scan attempts can detect the most obvious cases of a small group of users copying tickets and sharing them around. You can refuse the second use of the same ticket, and also in your back-office systems start to collate details of which user's tickets are being copied/re-used the most, and lock those users out, or mark their tickets (and future tickets) on a blacklist for 100% inspection in the future, including ID check.

Anti-Editing using Central Database
Simple (small) barcode tickets are just a serial number, and their validity is checked from a database of known tickets, which reveals all of the extra ticket detail, possibly including ID information about the legitimate user of the ticket which might be checked in high value situations.

The problem of this approach is that your ticket checking systems must have up-to-date access to the ticket database. This is fine if all of your tickets are sold many hours in advance, and your local ticket validating system has had time and connectivity to synchronise it's local database with the ticket selling server, but is far less use when people are buying tickets immediately before use, or when your ticket database is too big for your portable ticket checking devices to download and store, or if one ticket vendor doesn't want to give copies of all of their tickets to every single ticket checking agent, because one of the agents may just sell them on!

Live Check Speed and reliability issue:
If you design a ticket checking system that relies on the scanners being connected to the internet, to access a central database to check every ticket, then you may get issues with speed of checking tickets, and therefore the throughput of your entry systems. Especially if you have to check tickets underground or on a moving vehicle.
Additionally, your whole system could become useless from a single point of failure or connection. A huge factor in the design of the Oyster smartcard transport system for London was to make sure that each station could continue to check tickets in milliseconds, even if disconnected or when connectivity was slow. Otherwise any unforeseen issue with central servers or internet connections could bring millions of Londoners to a grinding halt during business rush hour - an expensive and potentially pin-stripe and bowler-hat riot inducing situation, if you are unfamiliar with London!

Offline Ticket Checking
If you can put all of the details of the ticket into a medium or larger barcode, then an offline system can scan the ticket, and instantly know what the entitlement is without the need to access a database. Trouble is, you need to make sure that the ticket is genuine, and not adjusted. There are two major ways to do this:

MEDIUM BARCODES (2D, around 42 bytes, ~27pixel square)

These not only contain the ticket serial number, but can also contain brief details about what the ticket entitles, such as destination, price paid, and valid date, and possibly even some very brief ID information, such as the last 4 digits of the credit card used to purchase the ticket, which could be checked against the user to make sure they are the valid ticket holder.

Anti-Editing using Symmetric Cryptography.
If your ticket issuing server and your ticket checking systems all share a secret symmetric key (symmetric means that all parties use the same key) then the contents of the medium barcode can be encrypted using the secret key. You can either encrypt and hide the contents, or leave the contents in clear text and add a small amount of the encrypted version at the end, as a "seal" or "signature" that can be verified by the scanner. Were an attacker to change the plain text bit of the ticket (such as the date) then after scanning the verifying scanner can encrypt the new plain text, and compare the new encrypted seal with the previous seal in the barcode, and detect an alteration, and can now reject the barcode as a forgery. The moment we can "seal" the contents of the barcode, it means that we can also add customer ID information to the barcode so that a validating agent can check that the correct user is gaining access.

Example format:
sellerIdentifier + ticketNumber + ticketDetails + CMAC
(CMAC is a small message authentication code, around 4 to 16 bytes long, created from the text of the message with a symmetric cryptographic function, using a secret key known only to the ticket seller, and ticket validators)
Suggested encryption scheme: AES 256 based CMAC.

Benefits: doesn't add much data - adding a symmetric seal to the end of a ticket can be done in very little space (you can just put a small portion of the encrypted or hashed version of the ticket into the seal and still provide strong protection) You can even send these medium barcodes in an SMS picture message (not MMS or WAP).

Problems: If a symmetric key is discovered by a thief, they can create and adjust tickets. This becomes quite likely as you have to give every ticket validator copies of every single symmetric key in use, so that they can check tickets. If one piece of ticket validating equipment is stolen, or compromised by a virus, or sold to criminals, then it can reveal the symmetric keys.

The ITSO ticket system makes it difficult for a thief to retrieve keys from stolen equipment by protecting the keys in a smart-card "Secure Module", and closely controlling the development of hardware that works with the smartcard. However, you can only use special hardware and software that is certified for use with ITSO, which increases the costs of integrating new ticketing systems, and expanding ticket reading options. Some organisations resist adopting ITSO ticketing due to the added cost and reduced flexibility (Oyster isn't compatible for one). Even if a symmetric key system doesn't use ITSO, it would need some hardware or cunning protocol to protect against leaking of keys. The big problem is that it would be impossible to detect which agent was losing keys, so if there were business losses, it would be difficult to assign responsibility.

LARGE BARCODES (2D, around 128bytes, ~41pixel square)

These tickets can contain all of the information about the ticket, including detailed ID information, multiple travellers, terms of the ticket, and details about the purchase history and multiple entitlements such as multi-part journeys, reserved seating etc. Some draft standards for Airline tickets and Train tickets require data payloads as large as this for full e-tickets.

Anti-Editing using Asymmetric Cryptography
Modern internet systems use Asymmetric cryptography for just about every secure transaction you do on-line.
Asymmetric encryption is often called Public/Private key cryptography, and means that the two parties use different keys - one of which is kept secret at the server, for creating and signing tickets, but the Public half of the key for validating the tickets can be freely given away (even to your enemies).

Benefits: The public keys, and instructions for their use can be freely distributed to ticket validators, friends, and enemies, for checking the validity of tickets. It means that open source ticket checking software can be made available to allow quicker integration of new scanning systems, and greater flexibility of providers.

Each Ticket issuing party can have their own private key, and give away their public key on a public website for all ticket validators to download and use. The keys would not need to be updated, unless one was stolen, or completely new providers appeared.

If one of the Private keys was lost, through virus, hacking, theft, or deliberate fraudulent activity, then the only new tickets that a thief could create would be from that one ticket issuing source, and that ticket issuer could be held financially liable for fraudulent tickets, without other members of the scheme being affected.

Suggested usage: football tickets or Olympic tickets - these may be sold in many places, and need to be checked in multiple locations, by different organisations. In some cases it may be advantageous for a ticket to entitle certain linked items, such as reductions on food in the olympic village for certain guests. You would need the ticket to be checkable by a food vendor, but you wouldn't necessarily want to equip every vendor with an ITSO hardware module or a large database of tickets. However, if you could provide open software and public keys, then EPOS integrators, mobile phones, and all manner of cheaper scanners could perform scanning and validation of the global ticket without reducing the security of the ticket.

Simple Format of the data inside the barcode:
sellerIdentifier + ticketSerialNumber + ticketDetailsEncryptedBySellersPrivateKey
Suggested Asymmetric encryption standard: 1024bit RSA with PKCS#1

Drawbacks: Asymmetric cryptography creates larger signatures than the symmetric cryptography, and therefore requires larger barcodes to contain them. Some much older (black and white) mobile phones wouldn't be able to display the larger barcodes. However, for walk-up tickets on paper or the modern phones this would not be an issue. You could display these on a mobile which supported MMS or WAP or Java based ticket delivery.

What about ECC instead of RSA?
ECC based Asymmetric encryption could probably be used too, even on the medium sized 40 byte barcodes, but there aren't such clear standards for message encrypt/decrypt with ECC quite yet - we'd be keen to explore this further.

Common Misconception: Small devices haven't got the processing power to cope with Asymmetric Encryption - this is simply not true.
Phones displaying a barcode don't have to process the encryption at all, and phones or PDA's checking the code can do so easily with modern methods. An ancient black-and-white Nokia 6310i could check an 1024bit RSA encrypted barcode in 1 second, a modern mobile phone or PDA could check the code in less than 1/100th of a second. ECC is roughly equivalent to RSA in speed for small keys, and gets faster than the equivalent RSA key as they get bigger.

Suggestion: 2 approaches:
Legacy phones: Use MEDIUM barcodes, which have to be live-checked when being validated in an inter-operator way. Slower, but the only way to use the smaller ticket format without the security issues of having to give away all of your tickets or all of your private keys to third parties.
A standard web-services server interface should be agreed so that one ticket validator can query the validity of a ticket from the Ticket Issuer's database in a standard way.
Operators that trust each other could share secret keys and mirror databases to speed up ticket validation and allow off-line checking, as long as security steps have been taken to help prevent staff leaking keys and ticket databases.

Newer Phones and Print at Home: Use LARGE barcodes with Asymmetric encryption. This allows walk-up tickets to be sold and instantly verified by open standard scanning hardware, even with no database connectivity or secret key distribution.

Less Critical: 2D Barcode Format:
Datamatrix, QR Code and Aztec are all suitable.
Datamatrix is more freely available and has more scanners available, so if it was adopted there would be more choice for providers of scanning hardware. (More choice usually leads to cheaper and lighter hardware.)
Aztec can cope better when there's less whitespace around the barcode, which Datamatrix needs.

We've seen plenty of scanners that read Datamatrix and QR, but fewer that handle Aztec.
Every Aztec scanner reads Datamatrix and QR, and the same data format can be contained in all barcodes, and in most cases the hardware in the scanner makes the difference between one format and the other transparent anyway, as long as the scanner supports the rarer Aztec.

We would go for Datamatrix, but the internal data format and the security model behind it is the most important thing to standardise at this point.

If you are interested in Barcode tickets, please comment on this thread, especially the following:

Can people agree to inter-operate barcode tickets?
Is the ability to off-line check not as important in the connected world?
Are the large format barcodes that we talk about too big?
Should we link virtual tickets to physical smartcards?
Should we all publish our barcode ticket formats each time we launch mobile ticketing, so that other similar providers can easily copy them, to make sharing barcode systems easier in the future?
Have you had experience that one barcode symbology is MUCH better than the others for scanning success from the mobile?
What ECC (Elliptic Curves Cryptography) standard would you suggest to use Asymmetric encryption in MEDIUM 40byte barcodes? And how much data payload data could fit inside?

RSS Feeds for the Community

2008-03-04T20:08:00.003Z

As an RSS junkie, I get almost all of my mobile information through news feeds. Unfortunately, a few key sites just don't have them - most frustrating.

Well, after a little research I discovered the excellent Feed43.com, which I have been testing for the last few weeks. Their service allows you to rip a feed from any site, but offers far more control than any of the competitors I could find.

As a service to the mobile community we have decided to make these feeds available to anyone who needs them - on a non-commercial, unsupported (but hopefully as reliable as possible) basis, of course! The sites we have ripped feeds from are selected for their own quality, we aren't claiming any rights or ownership over the content and we urge you to support them in whatever way they want.

One last note: there are individual feeds offered direct from Feed43, and aggregated feeds aliassed through Feedburner. If anythign serious happened with Feed43's service we might consider changing the URLs of these individual feeds, but we will update the aggregated feeds accordingly and the Feedburner URLs will remain the same.

Without further ado - the feeds:

New handsets from GSMArena.com, an invaluable source of new handset information, including:

Nokia new handset feed from GSMArena
Samsung new handset feed from GSMArena
Sony-Ericsson new handset feed from GSMArena
Motorola new handset feed from GSMArena
LG new handset feed from GSMArena
(the full feed also includes all the minor manufacturers on their site)

Handset manufacturer developer specifications, incorporating updates of:

Sony-Ericsson new handset developer specs
Samsung handset Java specifications
Motorola new handset developer specifications
Plus Forum Nokia's own new handset feed

Orange UK handsets

Of course, while you're in an RSS mood remember to bookmark the Masabi feeds as well!

I hope you find all these feeds as useful as I do!

Please note: occasionally, the Feed43 feeds seem to throw up "Error: Source Page not available" news items; just ignore these, over the last few weeks of testing I've found that the service does work nicely most of the time despite occasional hiccups!

Masabi speaking at Mobile World Congress

2008-02-08T13:20:00.000Z

Quick note that Ben Whitaker (me) will be speaking briefly at Mobile World Congress in Barcelona just after 15:00 on Tuesday 12th Feb at the Mobile Innovation Market Place in Hall 2, Auditorium B.

This is thanks to Masabi being nominated as a "Top Innovator"

______________

For people that can't make it, the slides and speaker notes look something like the following:

Our applications are built on three core principals –

Make the application USABLE and relevant to the end user, and make the default use cases quick and easy on the mobile. (I’ll show you some of that later)

Then, PORTABILITY to all popular handsets, including the older handsets that many developers avoid, to ensure the largest possible user-base for your service.

And for Mobile commerce – SECURITY, on all phones, to modern public standards.

Most Data passed through standard GSM services will not be secured to meet Financial Services or Payment Card Industry regulations.

You shouldn’t use SMS or WAP to send payment instructions, bank passwords or credit card details from the phone because too many individuals can gain access to them in transit.
(True end-to-end https is only available on the latest handsets – slow and not usable from Java or SMS.)

"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“
Nick Jones, Gartner Research 2002

We built EncryptME to the latest standards for new secure web services, and it is still the world’s only US Government Certified mobile java security library.

At 3kb, it can provide security on the oldest java handsets, including the black and white Nokia 6310i (show legendary retro business phone)

Most importantly, it allows SMS data to be encrypted too!

(Hold up 3510i)
When you provide transactional software for these old phones, we find that significant numbers of people use them. Can you afford to throw away 10-20% of your users?
(By way of comparison Microsoft and iPhones represent around 1% of the market - they may be heavier data users, but others use data too)

To provide Portability, we use our own porting Framework: DevelopME

We’ve seen many mobile products that are either attractive, but high-end only; or basic-looking and available on all handsets.
Through DevelopME we are able to provide attractive apps on all Java phones.

You have to work hard to build full function applications that work on the older phones, and you can’t out-source it, or think about it late in your dev cycle – it has to be at the core of how you build everything.

It’s not just different graphics sizes and bugs, you have to build variations of UIs that make the best use of very different input mechanisms on the different phones, and not expect the end consumer to re-learn new UI concepts that they don’t already use on their phone every day.

[The screenshots above are animated, to show useful UI widgets helping the user to select from large lists, or input Credit Card numbers correctly]

WAP and WEB services are Thin Clients ; good when you have a reliable, low latency connection.
Mobile is not like that – inside buildings, moving vehicles and in remote locations connections are often dropped or unavailable.

Mobile Java allows us to build FAT clients, and not just glorified mini-browsers!

Applications should provide most of the interaction while OFF-LINE and then only require an occasional connection at the end to make transactions, or get updates.
e.g. you should be able to review your bank account and create new payment instructions while on the metro, not only when stood still in good

Here are screenshots showing how you can quickly select one station from a list hundreds long, and also how to perform local validation of credit card numbers before sending to reduce the number of unecessary network connections

SMS Failover:
Many users cannot make network connections from Java using WAP, because they need to switch to the correct INTERNET settings.
To provide these users with an out-of-the-box instant purchase, the application can automatically detect the lack of functioning GPRS and switch to encrypted SMS instead.

Ported to over 750 handsets, multiple languages, alphabets, brands, currencies.

Live around the world.

Full sign up, credit cards and bank transfers from the phone – no need for PC.

Managed upgrade process, add new payment methods or anti-fraud methods without upgrading the application, dynamic download catalogue, news alerts, etc even on the venerable 3510i.

Credit Card details entered just once into the application.

Users have said “easier to use the mobile purchase than web purchase” because of quick, optimised workflow.

We’re using on-screen barcodes to show the ticket values for reading by automatic gates, or checking by the train guards who carry hand-held scanners.

The ticket code can be transferred to the NFC element on compatible phones (like this Nokia 6131NFC) but this handset is the only widely available GSM handset with NFC and we’ve not heard of other mainstream devices in the pipeline.

Even when NFC services become mainstream, you will still need a secure interface to purchase entitlements, before they get transferred to the NFC element.

Simple – put in your car, your credit card, and how long you want to park.

Brand new user can sign up and pay in just one secure SMS (or 0.02pence worth of data)

Extend your parking without returning to the vehicle.

As Gartner point out, SMS are more easy to intercept than most people think, and for many professions that is not a good thing.

We can extend SMS quickly and simply for Operators and Businesses to provide confidential SMS only readable by the intended recipient, using public/private RSA encryption at Government approved strengths.

Come see me after for live demos,
or to chat about building secure mobile applications for:
m-commerce,
Banking,
Ticketing,
Messaging.

Carnival of the Mobilists 107/108

2008-01-28T18:56:00.000Z

Carnival of the Mobilists 108 is up at Skydeck now, and among the usual great writing features a link to my recent post on the reasons for mobile fragmentation - the same post which was also a late addition to Carnival of the Mobilists 107 over at MobHappy last week. Thanks to both of you, I wonder if it'll somehow sneak onto next week's as well :)

GSMA Barcelona - will it be the first time that we met?

2008-01-17T11:26:00.000Z

Masabi will be at the GSMA Mobile World Congress in Barcelona on Monday 11th to Tuesday 12th February in the Mobile Innovation Marketplace.

If you want to take the opportunity to meet us, at the venue or afterwards, then drop an email or SMS me on +44 7788 895 894.

Ben

The Truth About Mobile Fragmentation

2008-01-14T20:42:00.000Z

My most recent task has been architecting the Playtech mobile product, which currently encompasses 10 games running on over 600 devices in 8 languages, each heavily customised for multiple licensees. Furthermore, the system was designed to continue scaling across more than a hundred licensees, with dozens of games and languages, supporting all mass market devices, all managed by a small team of inter-disciplinary experts. This has given me some interesting insights into the problems of fragmentation which I would like to share.

The dominant UI model on the desktop has been the Windows, Icons, Menus and Pointers system that became popular when Apple copied it from Xerox, and has stayed in the mainstream since Microsoft copied it from Apple.

No such standardisation is present in the mobile handset world. This will remain the case for the foreseeable future, as the market segments - offering “Swiss Army Knife” phones for power users, as well as specialised phones for people who value music, games, photography or fashion most.

Some will have keyboards, some trackballs, some touchscreens; some will have high resolution displays, some low; some will be landscape oriented, some portrait; some will have powerful processors and lots of memory, some won’t; and all of this will change radically over time, with some users upgrading every six months and some every four years.

Factor in the tight commercial deadlines that phone releases are subjected to, which never leave enough time for firmware QA, and you see why any mobile development platform that is large enough to be mainstream will be fragmented for a long time to come.

Anyone who has ever attempted to develop software for mobile phones knows that there are many hidden pitfalls along the way. However, mobile development need not be fraught with pain. A little experience immediately allows you to identify the key problems before you write a line of code, and design around them; a few rules of thumb can work wonders on development schedules and keep the QA team happy.

Pick Your Platform

I’ll try not to repeat my earlier post here, and will just briefly describe the three main types of mobile application platform – SMS, browser-based and installed application. Each has its own strengths and weaknesses, and they can often be used together to build a stronger product.

SMS is excellent for short, simple, immediate interactions across any handset - but break down once complex instructions are required.

Browser-based applications are growing hugely on the fixed web now that client-side scripting (such as AJAX) allows slick interaction, benefiting from automatic updates for every user – because everything is fetched from the server on-demand. AJAX on mobile is more theory than reality right now however, able to reach a tiny fraction of the market with incompatible implementations. Browser rendering is also hit or miss, and data costs can rapidly rack up as XHTML markup is heavy and flat rate data rare. Data cost is still an issue, with prepay customers regularly overcharged; flat rate, when available, is often full of loopholes and obscure clauses - billing per Kb is still very much the norm outside of the US.

Browser fragmentation will get worse long before it gets better – for example, radically different hardware like the iPhone introduces special case UI and design rules, and then 3^rd party browsers like Opera or Mozilla further multiply these special cases whenever they launch for that hardware.

The other option is an installed client-side application, offering immediate and offline access, far greater presentation opportunities, and the potential for reduced data costs – but it is harder to update over time, and is best suited to services which are intended to be used regularly.

The Traditional View of Fragmentation

The most common thing people will say when discussing mobile applications, particularly those which are installed on the client-side, and Java apps in particular, is that fragmentation is a huge problem. This is generally repeated as a fact even by those who have never coded Java, which is why it is so often misunderstood. Figures like the 25,000 builds Glu required for Transformers are repeated with disbelief (which I share); I’d love to know how many of those included the tiny changes that operators demand to feature content on their portals, but I’d wager it’s a huge factor because I know Glu aren’t incompetent. As a comparison, we normally run to between 30 and 60 builds per language for an app or game.

Some history may explain how this feeling became “common wisdom” in the industry. In the bad old early days of MIDP 1 (the first version of mobile Java), applications were quite restricted in what they could do. MIDP 1 did not define a way to play sounds, vibrate the handset, or provide a mechanism to allow the game to take over the entire screen, for example.

Most major handset manufacturers saw this as an opportunity to differentiate their products, and dived in with proprietary APIs to do lots of extra things which arguably the MIDP 1 spec should have included in the first place. These could all be abstracted away by developers behind a common internal API and a single build, but it would have required a little effort to set up and was hardly ideal. This led to much of the initial bad press for mobile Java, which is still heard to this day. Buggy handset firmware is of course the other huge factor, but it is hardly restricted to the development environments - whole handsets regularly suffer.

Sun (the makers of Java) eventually got their act together and started to introduce extended functionality through the JSR process: first MMAPI for sound, then WMA for text messaging, and then MIDP 2. Rapidly, the old manufacturer APIs dropped away; some can still be found, but they are really only objects of curiosity these days. Right now, MIDP 2 is available on over three quarters of actively used Java-enabled handsets, with most popular devices also featuring lots of the common extensions as well.

The next most popular platform, Flash Lite, is now available on commonly used handsets in versions 1.0, 1.1, 2.0, 2.1 and 3.0. All of these offer different capabilities and implementations run in one of two different ways: either embedded on a web page (like a traditional Flash movie) or running as a standalone app (like JavaME content), each of which brings critical differences to the experience. Japanese handsets (where Flash Lite is arguably most popular) tend to embed Flash in the browser, preventing the Up and Down keys from being used in the Flash content. The main reason Flash Lite has fewer variations than JavaME is that it offers less power and access to the device’s features – and it still has its fair share of the standard cross-device issues and bugs.

After Flash come native Symbian OS apps – offering plenty of APIs (between the three major and many minor versions of Nokia’s Series 60 and the keypad and multiple touchscreen variants of UIQ). Recent versions of Symbian have repeatedly broken binary compatibility and the range of APIs always expand alongside device capabilities. So it goes on.

It is inevitable that any new feature absorbed into a phone – from cameras and music playing to GPS location tracking, OpenGL 3D and operator micropayment integration, will require a dedicated API before developers can access them. Features are being absorbed into phones at a very rapid pace, so any living development platform, be it browser or fully fledged open OS, will have API growth over time. There is simply no avoiding it.

Loosely drafted specifications with optional features and optional supported file formats still require management and should be avoided, but this is not rocket science. If you know that some devices support WAV sound but others only handle AMR, it’s not a particularly difficult problem to set up builds for the former to get WAVs and builds for the latter to get AMRs. We now have to generate platform-specific builds for a single application – we have certainly lost the “Write Once, Run Anywhere” bonus we were promised with Java. However this is simply unavoidable in the mobile space whatever platform you use, once you move beyond text-only messaging.

For what it is worth, my personal feeling is that the core Java functionality is becoming more reliable over time - we haven't had anything as bad as a 7650 or a 6600 for some time, and even some of the more notorious platforms like JBed are getting more stable. The more obscure APIs have teething problems and no platform is bug free, but most everyday features can be used easily enough once you know the basic tricks.

Mine’s Bigger than Yours

I’ve just listed one reason we may wish to split a single application into multiple binary files: incompatible file formats between devices. There are many more, and most apply to any development platform you care to mention.

The single factor which leads to the most extra work on any mobile app is the size of the device’s screen. The smallest screen the Playtech mobile product supports is 96x65 pixels for Nokia’s still popular low-end devices; the current largest is 352x416, used on some of Nokia’s highest end handsets; I have no doubt we will expand to support VGA and larger screens soon enough. In between, there are currently eight other screen size and orientation groups, all requiring individually redesigned graphics, to cover a few dozen actual real screen resolutions. For example, we consider a 176x196 pixel usable screen area to be equivalent to 176x220, and design the graphics and code to be happy with any height between 196 and 220px.

Note that often, the phone will let applications take over most of the screen, but keeps a header and/or footer for showing battery and signal information, the time etc.

Mobile apps and games almost exclusively use bitmap graphics – which have a fixed size and resolution – and not scalable vectors, like a traditional Flash movie, that would be capable of adapting somewhat to different screens sizes from only one binary file. Even Adobe admits that Flash Lite will need different binaries for different devices, as whilst Flash Lite theoretically offers the same vector scaling as its big brother, in reality this is too slow on current devices for fast complex graphics. Experts recommend the use of bitmaps for any non-trivial application, just like Java.

Managing this screen size complexity is a challenge without huge graphics production timelines (and suicidal designers), but one that can be met with scripting and templates. In Playtech’s case games can feature amazing levels of variation where the graphics require less than a day to customise for a new licensee, ready to drop into an automated build.

Fragmentation for All!

Assuming that intelligent code, good tools/scripting and carefully planned graphics can cope with screen size variations and differences in processor speed, what else do we have to worry about? Principally, the very first point mentioned in this post – the UI model of the handset, and the input mechanisms provided to make use of it.

The iPhone was rightly lauded for its touch user interface, a radical departure from even the conventional stylus-powered PDA platforms like UIQ and Windows Mobile, and thumb-powered interfaces as featured on the LG Prada. Windows Mobile itself is now changing to a new model based on gestures, and Nokia’s Series 60 is getting touch screens as well. Great news for consumer choice, but a fragmentation headache for developers - each of these systems requires its own dedicated interface solution to best meet the user’s expectations.

Even on more conventional phones, there are plenty of other differences – to enter some text into a field, most provide simple numeric keypads, but some handsets provide full keyboards and some provide their own proprietary solutions, such as RIM’s Suretype system. Even with a simple numeric keypad, some devices have a dedicated Clear/Delete key and some require a soft key for this function. In theory, you could just create a Java text field and let it worry about this detail, but that would tie you down to very ugly screens with extremely limited control. Most quality applications will implement their own UI components with full branding, but this means extra effort to support all types of character entry.

Even an app with no need for text entry should optimise the rest of the interface for whatever keys are available – allowing users to jump through lists by typing, for example, or handling motion control in games on devices which have no dedicated Up/Down/Left/Right keys. The optimal UI for a device with an Up/Down scrollwheel may be very poor on a device with a trackball, etc.

For a trivial app, these differences do not matter – and in a webapp, you simply can’t do these optimisations for your user experience. For a professional installed app that will see frequent and prolonged use, however, these optimisations are 100% critical to the project’s success. The interface must react exactly how the user expects it to, looking and feeling familiar whilst also presenting an attractive, professional and branded appearance.

OS Wars

Many years after Symbian was formed to be the phone OS of the future by some of the key mobile manufacturers of the day, the marketplace is still very fragmented. Motorola currently supports MIB, AJAR, MAGX (a Linux variant), Windows Mobile and UIQ (a Symbian variant); Samsung relies on a number of internal platforms alongside Windows and S60 (the other open Symbian variant); Nokia, the truly dominant force in mobile with between 30% and 40% of the global market at any given time, has managed to rationalise its OS portfolio down to the low-mid range Series 40 and the S60 platform for smartphones. Some operators are attempting to limit the number of platforms they support, but this is starting to look like trying to hold a finger in a leaking dyke.

If Nokia, by some metrics the most successful consumer electronics company the world has ever seen, finds it very hard to raise market share beyond 40%, then it would seem unlikely that anyone else can achieve more. Slow handset upgrade cycles mean that even if they did tomorrow, today’s fragmented handsets would still be in regular use in 2010. Current marketplace trends see increased diversification, both in form factor and in the types of software running on it – and with more software development platforms to work with. Fragmentation may be annoying, but it is here to stay.

Conclusions

Mobile development will always involve hitting multiple moving targets, and the only applications which succeed will be those that embrace this complexity and manage it sensibly. It is more important to ask “how many people can a platform reach?” than “how few targeted binary files will I have to generate?”

The only serious platforms that can give a satisfying answer to this question today are clearly WAP2 or Java, depending on the nature of the application. One day, it will hopefully become possible to write scriptable mobile web applications that can be updated day to day from the server end, but that simply is not possible for the mass market today, and won’t be for some years.

As CTO of a company which is in the business of knowing the ins and outs of every handset and every mobile platform, it is obviously to my advantage to state that only developers who can manage this complexity will be able to survive and thrive in the mobile space. Hopefully, the reasons why this is true, and the reasons why we as a company have taken the sometimes painful direction that we have, are clear. This is a very exciting space to be in, but when you try to work on the cutting edge you must take precautions not to get cut.

Carnival of the Mobilists

2008-01-09T19:43:00.000Z

This week's Carnival is hosted over at Mobile Point View, and once again Ben is featured for his most recent blog post on entropy and random number algorithm backdoors. Check out the Carnival for the best of the week's mobile writing!

Did the NSA put a back door in our Mobile Security? (and more about bad random number generators)

2007-12-19T11:44:00.000Z

After the recent discovery of a potential back-door in a NIST approved random number generator, I thought it would be timely to state clearly that we do not use the generator scheme involved, but a more straightforward AES based random number generator, which does not fall prey to the suspicious curves.

Why do we care about random number generators anyway?

For the encryption newbie: Quick Summary of key exchange to set up a secure session, using random number, and asymmetric encryption:

Generate a Big Random Number on the phone, that becomes your symmetric session key
Encrypt that secret session key using slow Asymmetric Encryption like RSA (using the server's public key that the mobile application already has, and we are quite happy for the attacker to know too)
Send the asymmetric encrypted session key over the public network to the server
Only the server with the private asymmetric server key can decrypt the data and read the secret session key
Secure session continues with fast symmetric encryption like AES using the shared secret session key in both directions.

If the attacker can guess what big random number you created at step 1, they can jump straight in to read everything at step 5.

The vulnerability in the news story above is that whoever knows the secrets to the elliptic curves that underpin that particular random number generator might be able to guess the sequence of random numbers it will generate more easily (mathematically quicker) than should be possible for a normal attacker.

This posting will not say anything more about that specific (possibly deliberate) vulnerability, but instead look at situations where developers inadvertently put much worse weaknesses in their security systems which allow attackers to beat your system as if they had a similar back door, which you accidentally left wide open, accompanied by big flashing neon signs that say "hackers enter here".

The Random Issue

All cryptography relies on a good source of randomness, and it is very important for system designers and security evaluators to understand that although they may have thought hard about how many bits long their keys are, all of their fancy cryptography is worth nothing if they haven't built it on top of a good random number.

WAKEUP CALL: If you build a 128 bit key from 8 bits of un-guessable randomness, you have a system with an effective security key strength of only 8 bits.

Pseudo Random Number Generators
Just having an approved Secure Random Number Generator is not enough, you need to seed (initialise) the generator with some real randomness (entropy) otherwise the secure random will be predictable. This is because all secure random number generators are actually PSEUDO-random number generators, and will produce exactly the same sequence of numbers from an identical seed. They have to work this way so that they can be properly tested and profiled to avoid generating patterns in the sequence output that could reveal something about the source seed (that is, that they are one way functions which don't create repeating patterns). In layman's terms, it means that the seed must be from something really random, and then your pseudo random number generator can get on with producing a nice continuous stream of apparently random numbers, suitable for cryptography.

What's a good seed?
One of the common forms of cryptographic attack (after fooling people) is "side channel attack" where an attacker observers some external aspect of the client system and uses that to guess the keys or data. In this case they can ignore the algorithms in use, and just second guess the seeding of the random number generator (RNG), which then gives them the session key.

It's easy to see why - the default Java implementation of secure random "seeds" it's RNG from the system time when it was started - so to guess the session key in use during an encrypted session, you simply guess (roughly) when that program's RNG was started (usually a few hundred milliseconds before the first network connection) and throw all the times around that through an identical RNG algorithm until one of the generated keys works. This would allow you to guess a 256 bit key in only 9 bits worth of attempts (effectively reducing the key strength to 9 bits, therefore easily brute-forcible). It turns out that since Java 5 the default seed implementation also adds a counter to the current system time, but that doesn't really represent a real attacker-defeating source of entropy!

Q: "We run a maths loop thousands of times and take the processing time and free memory differences from that to make the random seed, will that do?"

"Any one who considers arithmetical methods of producing random digits is, of course, in a state of sin.'' von Neumann

On mobile you cannot run a "futile cycle" to generate random times and memory usage like you do on a PC, as many handset operating systems are so simple that they run completely uniformly (the same every time) in most cases.
We profiled all common phones during thousands of program startup cycles, and found that on some Nokias, for example, you could load a hundred images and do all sorts of other things in memory and it would take the same number of milliseconds, (+/- 10ms) every time, so even if you "stirred" your RNG with the timing, memory, or results of your startup, it would be something that an attacker could also copy, and just use that as a known quantity in their "guessing". On top-end Symbian handsets you can get better access to microphone, screen coordinates, less uniform performance from the multi-tasking OS etc, but on standard MIDP phones it is all far too predictable to be a reliable source of entropy.

Side Note: Reverse Compiling Java:
Mobile Java is very straightforward to reverse-compile (getting the original source), so you have to start your analysis by assuming that a committed attacker can completely understand, and make use of your own code against you. All of the worst case scenarios that we are guarding against assume that the attacker has full knowledge of what the developer is doing, and could perform quite advanced profiling of how it performs on each handset, or just target a particularly vulnerable handset.

This may sound like a very long winded process, but the attacker may have been quite highly funded by criminal gangs or antagonistic Government agencies to break your security, or worse, they might just be a bored academic that likes a challenge.

Solution:
You have to rely on the USER for a true source of randomness.

Some PC security programs get the user to wiggle a mouse or speak into a microphone before they generate your keys - this is all about seeding. Get the mobile user to press buttons, or interact in some way, such as playing a game. This is the only way to get a good seed on many handsets.

The exact times of keypresses are one good source of some randomness. But you must first figure out how much true entropy you get on each handset from this. More handset profiling is required.

Clock Granularity - why the mobile cryptographer would care:
Many handsets give time in milliseconds, but only have a clock granularity (minimum reported time difference) of around 25ms. If someone is banging random keys, an attacker may guess the presses are occurring roughly each second, so the variation that they can't guess is going to be less than about half a second, varying by say 15 actual reported clock intervals (375ms). So we might only get 4 bits of randomness in the time. If they are hitting random buttons, on a 10 button keypad, the value of the key pressed is another 3 bits, and the key release time about another 1 bit of uncertainly. You can throw in the free memory at the time of keypress too if you like, which in the worst case may vary in a fixed way according to the timing of keypresses, so I'll not give myself any new uncertainty for that as you have to always consider the worst case.

So if I want to generate a 128 bit random key, and I get roughly 8 bits of un-guessable entropy from each user keystroke (if they are banging the keys to give me randomness) then they will have to hit at least 16 keys to be sure. (and there will be plenty of people that will argue for less bits of entropy per keystroke, and demand 20 keys hit, so we usually go for 20 as our minimum).

On newer phones you could get entropy from the tilt sensor, or record sounds and background noise from the microphone, but we have to make sure that there's a workable solution for even the most basic MIDP1 phones that only provide user keyboard input.

Some developers use the IMEI or other phone properties as an extra bit of information to throw into the random seed - by all means add this, but don't assume that this would be impossible for an attacker to find either from a browser HTTP header (Nokia S60 phones add the IMEI here) or by installing a second application that simply asks for the same properties (similar to the attacks on XP and BSD random seed pools); adding this doesn't increase your worst case entropy count.

Good Examples:

Playtech Mobile Casino - (written by Masabi) these games get the user to press random keys to seed the RNG, and also use the keystroke timings during fun-games (which run without secure networking) to collect seed information, and will only make a secure connection once enough seed information is collected. An entropy counter clocks up the number of user generated events, and only allows secure networking when enough have occurred.
Opera Mini Advanced - the secure versions of opera mini get the users to press random keys to seed their random number generator before making secure connections - good on you Opera!

Bad Examples:

There are plenty of "Secure" mobile applications that don't practice safe seeding, and are open to RNG guessing attacks. It could be that they have some other hidden source of randomness that none of the rest of the computer scientists in the world have thought of, but I doubt it.

If you are using a secure mobile app, especially on MIDP1, and you get a secure connection without pressing at least 16 buttons first, then chances are your connection is vulnerable to attack, and someone getting into your session in under 1000 guesses.
It's also a first sign that the application developer may not have had anyone skilled and independent truly analyse their security, because it would be the first thing spotted by a security professional or white-hat hacker, simply by looking at the finished product, and before viewing a single line of code.... there could be other mistakes too.

Another Bad (and common) approach:
No Random Number Generation, No Key Exchange
It is difficult to build both an Asymmetric and Symmetric encryption systems small and fast enough to use on mobile devices, and we've noticed that some secure mobile products don't bother with it at all, and just implement a Symmetric cipher alone, like RC4, 3DES or AES, and pre-share a symmetric encryption key through some other corner cutting technique.

Common bad key-sharing tricks: (we've seen these in live systems)

Building the key material into the application JAD or JAR file prior to install.
PROBLEM: The JAD and JAR are transmitted in the clear, and however obscured the key material is, it would be possible for an attacker to retrieve that key material from observed network data during install.
Using customer data entered on the mobile device (username, account numbers, DOB) as key material, as this is also known to the central server.
PROBLEM: much of this data would also be known or discoverable by the attacker.
Sending an "Activation code" via a second channel for the user to type in to Activate the secure connection, and using that activation code as the seed or key material
PROBLEM: building a 128 bit key from a 4 digit activation code represents a key strength of only 13 bits, far too weak to secure financial transactions that should be protected by at least 128 bits of effective cryptographic key strength (requiring an activation code of 39 digits length). Also if you are using 3DES your effective bitstrength is only 2/3 of the total number of bits of key material, so a 3DES system based on 14 bits of unknown key data may only present a 9 bit problem for an attacker to brute-force, possibly requiring the raw unadulterated processing power of a 1980's pocket calculator for a second or two.

So, after all that, we're not really scared that the US Government has a back door implanted into the publicly known and widely investigated algorithms that we use; but more importantly I hope we've looked carefully enough at our handling of random numbers and key exchange to make sure that we haven't inadvertently left another back door open for the attentive hacker to exploit.

However, it does seem that some vendors are still leaving these vulnerabilities in their systems by design - I hope that this all gets brought into line soon so that as an industry we don't make mistakes that could earn mobile commerce a bad reputation with the public before we've even truly got started!

Job Vacancy: Java Developer

2007-12-03T09:31:00.000Z

NO RECRUITING AGENTS! (I really mean this, I will be very rude to any recruiter that calls, you have been warned.)

Candidate must have Java experience, but doesn't necessarily need mobile experience.

Variety of work, young team, exciting world-changing projects and located in the heart of London's trendy South Bank, close to the culinary delights of Borough Market.

Location: SE1 0ES
Hours: core+flexitime
Money: 15-25 dependant on experience.

Send your CV to jobs@masabi.com
Call Ben on 0207 981 9781 to find out more about the role. (don't be shy, I'm quite friendly)

Cell IDs and Location-Based Services

2007-12-01T12:40:00.000Z

It was very interesting to read about the latest update to Google Maps, one of the nicest J2ME apps around at the moment, which can now find your location without GPS. My instant reaction was – “Finally! But will the operators let them continue?”

Current operator location services work by triangulating signal strength from multiple base stations, which can often give good accuracy in urban areas densely packed with cells. They carry with them a cost – low in absolute terms but sadly quite high for a lot of possible use cases - and all sort of privacy controls, which whilst clearly necessary have been a bit of a barrier to widespread adoption of Location-Based Services.

Back in I think it was 2002, Masabi had a working system to track handset location by cell IDs. Ben, being an engineer at heart, had strapped a modem unit to a Palm PDA and written an application to read out the current cell ID and plot it onto GIF maps downloaded live from StreetMap.co.uk. I distinctly remember being very impressed walking down Victoria Street towards Parliament Square in Westminster and seeing it track us across the map on this very GIF with surprising accuracy.

Consensus seems to be that Google are using a very similar system, with GPS users providing location data to map out operator’s cell IDs (something I believe explicitly mentioned). This suggests that Google haven’t purchased the location data from the operators. Why would that matter?

So how did we build up our cell location database? And if it worked, why didn’t we commercialise it? The two answers are connected – we were ramping up for a launch within certain industries which could have benefitted from a single network/limited device range service. Unfortunately – or perhaps fortunately, with hindsight – just before a major demo, the operator we were using decided to remove the cell broadcast info that had been supplying the base station OS grid reference locations (note: the cell IDs themselves did not appear to change, as I had erroneously stated earlier).

We considered some sort of effort to map cell IDs into a database, perhaps open source, but without widespread GPS ownership this was a huge task and there was no guarantee that the operators wouldn’t choose to change the IDs at any time in the future and we were not interested in trying to make commercial promises where we had no control over key components. So we put it to rest.

Some JavaME devices can access the current cell ID, as can signed Symbian apps and Windows Mobile apps; Google’s compatibility list suggests they are targeting only these devices, suggesting they are attempting something similar. I wish them luck!

EncryptME Wins IET Security Award

2007-11-16T15:22:00.000Z

We're delighted to announce that Masabi's EncryptME won the security category at the IET's annual Innovation in Engineering Awards.

Ben Whitaker, our head of security development, received the award from TV personality and science enthusiast Johnny Ball and Lance Howarth of ARM at an awards ceremony on Tuesday night.

The security category was sponsored by ARM, and in making the award the judges noted that "EncryptME is a mature offering, embodying some sound underpinning technology for the burgeoning market of secure m-commerce, where it could reduce risks for both mobile operators and 3rd party application providers."

This industry recognition further builds on the validation of EncryptME that we received from BT's Cryptographic labs earlier this year and underlines Masabi's position at the forefront of mobile security.