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:
- osip_authentication_info_init () — create data structure
- osip_authentication_info_set_qop_options ()
- osip_authentication_info_set_rspauth (),
- osip_authentication_info_set_nonce_count () — fill it in
- 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.
