Recently Steve Song pointed me to the great project Freedom Fone (don't mess it with FreedomPhone, which is a different project). FreedomFone guys wrote an article about the horrible situation at Dadaab, the biggest refugee camp in the world: http://www.freedomfone.org/news/village-fone-dadaab

Steve pointed that VillageTelco may not be the best solution for the communication problems there. My reply is that a combined VillageTelco+Fairwaves/OpenBTS would be a much better solution:

From what I understand, the best solution might be a combined Fairwaves+VillageTelco system. As most people have their mobile phones, it would be beneficial to have a mobile network there. At the same time, there are few stationary places, like schools, agencies officesm etc where MPs could be installed. Our system is great, but it has a very limited capacity — 15 concurrent calls per base station sector. So we should do the best to offload traffic from it, and VillageTelco is the best solution for that.

For the same reason, it's unwise to provide completely free calls on the mobile network — people will quickly overload the network with random chats and more important calls couldn't come through. This is a bit different then with VillageTelco, where you can't have more calls then you have MeshPotatoes installed. Thus I see that if we were to install a network in Dadaab, we had to charge a small fee for mobile-to-mobile calls. While calls from mobile to a set of «emergency» numbers had to be free. E.g. calls to the Freedom Fone services would be free to provide maximum value to the people. MP-to-MP calls could be free as well to allow unlimited calling between important official offices. Then, the gathered money from mobile-to-mobile calls should help to support system maintenance and make the system sustainable.

This is a post by Max Suraev who currently works on authentication and encryption for OpenBTS, as well as on UmTRX host side software.

Preface

One of the key drivers behind open source implementation of GSM stack is the security concerns regarding notoriously insecure proprietary versions. So working on this feature is both challenging and interesting because it touches different under-the-hood parts of OpenBTS.

Unlike almost all GSM implementations OpenBTS is ip-based «from scratch» — it tries to lift call\sms from GSM protocol stack as soon as possible into well-known ip world of SIP voip stack. This simple idea is so good that essentially the same approach is employed by the next generation 4G (LTE) protocols with it's IMS in the core and ip all over the place.

Challenges

OpenBTS is written in C++. Yepp, it's industry-standard, mature, widely used language with efficient compilers. But it's still a challenge (what a nice way to say PITA ;) — manual memory management, arcane error messages and annoying imperative nature harms my lazy soul after experiencing beauty of Haskell and J.

We use SIP to communicate security requests and responses from phone via OpenBTS to SubscriberRegistry (pretty much self-explanatory name. To bend highly flexible SIP protocol the way we want, we got to work on per-message level via oSIP library. It's a very stable library used in many open source projects (like linphone for example). But the more I work with it — the more I'm convinced that it was developed by some poor guy abducted by aliens. The interface is not just inconsistent, it's brain damaging. For example, to send authentication data we do following:

1. osip_authentication_info_init () — create data structure
2. osip_authentication_info_set_qop_options ()
3. osip_authentication_info_set_rspauth (),
4. osip_authentication_info_set_nonce_count () — fill it in
5. and then —  osip_authentication_info_to_str () — serialize it to string and give it to parser to make response out of it! o_O

And apparently those aliens abduct anyone who attempt to write more or less
comprehensive documentation — judging from the fact that few examples and some
outdated doxygen info were all I've managed to google.

Current state

Anyway, authentication works at first glance. I'm hesitant to just say «it works!»
because the devil is indeed in the details. GSM is such a huge standard that in
printed form it could be used for improvised weight-lifting competition. There are
numerous corner cases we got to test to make sure that no phone left behind.
The encryption bits and pieces are flying around in seemingly proper way — now we
have to apply them to the right place at right time and — testing, testing, testing.

Next

It's a practically established tradition over several last CCCs — at the end of the
year some German guy (my deepest respect to Karsten and others) come up to the scene
and breaks yet another piece of GSM security

There are couple of proposals (both standardized and not yet) on how to turn GSM
security into less sorry state (shall I say — make it more German-proof?). Probably
the most straightforward — usage of backported a5/3 ciphers from 3G. Other
improvements include fast TMSI (the temporary ID hiding real you from eavesdroppers)
rotation, filling GSM rest octets (padding used when actual data is
too short to fill entire burst) with random junk and few more things which should
have been considered from the very beginning by GSM designers.

That's the most likely plan after which we'll convince ourselves that present
implementation is sufficiently field-test ready. This will give us first real test
system to check whether those security fixes are compatible with real mobile phones:
as Microsoft's neverending struggle with html tell us — there's too much temptation
to skip couple of pages from standard description.