Harald Welte's blog


Harald's Web




Other Bloggers
David Burgess
Dieter Spaar
Michael Lauer
Stefan Schmidt
Rusty Russell
David Miller
Martin Pool
Jeremy Kerr
Tim Pritlove (German)
fukami (German)
fefe (German)
Bradley M. Kuhn
Lawrence Lessig
Kalyan Varma


Ohloh profile for laforge
Linked in

Creative Commons License
Articles on this blog/journal are licensed under a Creative Commons Attribution-NoDerivs 2.5 License.



Mon, 29 Nov 2010
Trying to understand Ericsson Abis-IP + OML

I've recently been able to look at packet traces of an Ericsson BTS (which they call RBS) and have been working on understanding their proprietary Abis-over-IP protocol stacking and OML layer.

By now, all equipment makers have migrated their BTS products from classic TDM (E1/T1) lines to some form of IP-based back-haul. However, the GSM specs as published by ETSI and 3GPP still only specify the E1/T1 transport layer, and every vendor seems to invent their own protocol for back-haul.

What we already know (and support) is the ip.access style Abis-over-IP, where they have their IPA multiplex layer inside TCP. Inside that they then have pretty straight-forward 08.58 (RSL) and 12.21 (OML) messages.

With Ericsson, they use a stacking like this: Ethernet, IPv4, L2TP, custom-HDLC, RSL/custom-OML.

The custom HDLC layer (I have called it Ericsson HDLC, or short EHDLC) seems to work quite different from all other forms of HDLC that I've seen:

  • 1 Byte Address
  • 1 Byte Length (including the header!)
  • 1-2 Bytes Control
  • n Bytes Data

The Control octets are just like in any HDLC, i.e. you have U/I/UI/S Frames and see commands like SABME, UA, RR, ... It mostly uses a two-octet control word that has both N(R) and N(S) for acknowledgements. At the beginning they actually do a XID exchange that seems compliant with ISO 8885 (if you cannot find that document, try reading the AX.25 spec instead, its XID is compatible with ISO 8885).

I have not fully understood the Address octet yet. I see lots of changes in the upper three bits, and it seems there is a SAPI or TEI that is the lower 5 bits of the octet.

Having a length field in an HDLC header instead of any flag bytes is indeed very uncommon to see.

The OML layer (called OM2000) is completely proprietary and shares nothing with the GSM specs 08.59/12.21 apart from the three byte header. However, I have managed to build a pretty complete dissector which you can find together with the EHDLC code in this rbs2409 patch which applies on top of the generic wireshark abis_oml.patch

It is my hope that this information (and particularly the dissector) will prove a valuable resource once we add Ericsson BTS support to OpenBSC. If there is anyone who can provide us real BTS (RBS) hardware, please let me know :)

[ /gsm | permanent link ]

Back from DeepSec 2010

I'm back from Vienna where I attended a very exciting DeepSec 2010 conference. This years focus was clearly on mobile security: The GSM security workshop by Karsten Nohl and me, the various talks like All your baseband are belong to us by Ralf-Phillip Weinmann, a talk on Android security auditing / forensics and much more.

In a few days, I'll be leaving for Taipei/Taiwan again. Apart from the one-day GPL compliance engineering course together with Armijn, there will be a number of meetings with various companies - both GPL as well as GSM/3G related.

It will be great to be back to Taipei - unfortunately only for 10 days, which is a real pity. I still miss it a lot.

[ /linux/conferences | permanent link ]

Fri, 19 Nov 2010
Initial mt6235 Linux and u-boot code available

As Marcin announced yesterday on the OsmocomBB mailing list, his initial u-boot and Linux port to the MT6235 baseband processor has been pushed to the git.osmocom.org server. He has also provided some instructions and pre-compiled kernel and u-boot images.

He's now working on the NAND, SD/MMC, GPIO and LCD drivers. If you want to help out, feel free to contact Marcin about this.

Meanwhile, I've been doing a bit of theoretical analysis on the GSM baseband / RF interface of the MT6235, based on the limited documentation that is available to the general public. Seems like it's about time to start with practical experiments soon..

[ /gsm/osmocom-bb | permanent link ]

Announcing Osmocom SIMtrace: A smart card sniffer

During recent weeks I started to do some work related to SIM Application Toolkit (STK / SAT). Debugging this kind of application is hard, as you never really know what exactly is going on between your SIM and the phone, and you don't have the full source code for either of them.

Thus, the need for passively sniffing/tracing the smart card interface between SIM and phone was born. There are commercial solutions which are not only prohibitively expensive, but then they are again proprietary/closed, i.e. you cannot extend them how you want.

There are also some free/open projects like the good old Season scanner, or the slightly more modern RebelSIM Scanner. However, those are really dumb and you have to manually determine the bit-rate using an oscilloscope and then program the UART accordingly. Furthermore, their top speed is often limited. None of this is really useful if you e.g. want to test a variety of combinations between N SIM and M phones, where you don't want N*M times of manual determination of bit-timing on an oscilloscope.

As an alternative solution, I have now created Osmocom SIMtrace. It uses an AT91SAM7S micro-controller as hardware interface between the SIM card interface and USB. It properly sniffs the RST, CLK and I/O lines of the SIM and does auto-bauding, follows negotiation of new bit-rate negotiation via PPS/PTS and re-assembles / segments the APDUs as they come by.

Finally, the APDUs are picked up by a small command-line program that feeds them into wireshark, where you can inspect them like any other communication protocol that you're used to.

The code is still fairly experimental, but for anyone with an interest in this topic it should definitely be possible to reproduce my results.

There is not much specific to SIM cards in this project, by the way. It should work with any ISO 7816-3 T=0 smart card. Adding T=1 is just a matter of software, if you need that protocol..

And now I'm finally off to doing the actual work that I wanted to do.

[ /gsm | permanent link ]

Fri, 12 Nov 2010
A brief history on the withdrawal of the A5/2 ciphering algorithm in GSM

Recently, I wanted to investigate when and how A5/2 has been withdrawn from both GSM networks and GSM phones alike. Unfortunately there was no existing article discussing this history online, so I went through dozens of meeting reports and other documents that I could find online to recover what had happened.

If you don't know what this is all about: It is about the A5/2 air-interface encryption algorithm that was used in certain GSM networks until about 2005-2007.

A5/2 was specified as a security by obscurity algorithm behind closed doors in the late 1980ies. It was intentionally made weaker than it's (already weak) brother A5/1. The idea was to sell only equipment with A5/2 to the countries of the eastern block, while the less-weak A5/1 encryption was to be used by the western European countries.

A5/2 had been reverse engineered and disclosed in the late 1990ies, and has undergone a lot of attention from cryptographers such as Ian Goldberg and David A. Wagner. In a 1999 paper, they already expect that it can be broken in real-time.

It took several more papers until in August 2003, finally, the proponents of the GSM systems (ETSI/3GPP/GSMA) have realized that there is a problem. And the problem was worse than they thought: Since they key generation for A5/1 and A5/2 is the same, a semi-active downgrade attack can be used to retroactively break previously-recorded, encrypted A5/1 calls. The only solution to this problem is to remove A5/2 from all equipment, to make sure the downgrade is not possible anymore.

Starting from 2004 the security related working groups of 3GPP and GSMA thought about removing A5/2, and in the following years they convinced their respective bodies (3GPP, GSMA), and members thereof (operators, equipment makers) to fix this problem.

Ever since that time, it is known that using the same key generation for different algorithms enables down-grade attacks. However, the key generation for the then-new A5/3 algorithm was unmodified. So now that A5/1 has been broken in recent years, even if the operators deploy A5/3, the same model of down-grading attacks to A5/1 can be done again.

I have put down a time-line at the still mostly-empty security.osmocom.org website. Some of the goodies from it:

  • It took from 1999-2007 until this gaping security hole was fixed. Call that incident response!
  • Unnamed Northern American Operators (and the PTCRB) were the biggest blockers to remove A5/2 support from their networks. This is particularly strange since US operators should always have had A5/1 access.
  • As a breaking of the more secure A5/1 was already anticipated even back then, in 2002 A5/3 was first specified. Five years later (2007) there was virtually no support for A5/3 among manufacturers of GSM network equipment
  • It took until January 2009 until the GSMA discussed A5/3 testing with mobile phone makers
  • It took until November 2009 until there was a plug-fest testing interoperability between A5/3 enabled GSM network equipment and A5/3 enabled phones.

And what do we learn from all this?

  • GSM equipment manufacturers and mobile operators have shown no interest in fixing gaping holes in their security system
  • Prior to that first A5/2 attack, they have never thought of procedures for upgrading the entire system with new ciphering systems (i.e. proactive plans for incident response)
  • Even after the A5/2 disaster, they have not learned the slightest bit. The same problem that was happening with A5/1 - A5/2 downgrade attacks can today be done with A5/3 - A5/1 downgrade attacks. And this before the majority of the operators has even started to use the already-7-year-old A5/3 in their production networks.
  • The security work group of 3GPP has had a lot of insight into the actual threats to GSM security even 10 years ago. You can see that e.g. in the Technical Recommendation 33.801. But nobody wanted to hear them!
  • Similar problems exist with the authentication algorithms. It took 12 years from first practical attacks on COMP128v1 until the GSMA is looking at withdrawing it.

[ /gsm | permanent link ]

Sun, 07 Nov 2010
Hashdays 2010 in Lucerne, Switzerland

The last couple of days I've been at #days 2010 in Lucerne / Switzerland. It was the first incarnation of this new IT security conference.

The conference went great, and I think the close-to-200 attendees were a great turnout for the first incarnation of an event. The talks were excellent, as was the delicious food that was served by the Radisson Blu hotel.

The GSM security workshop that David, Karsten and myself held over Wednesday and Thursday was attended by only 7 people, but we had some very lively discussions, particularly with some folks who were working for a GSM operator :)

Most notable about the event is the electronic conference badge, which was developed and produced with a lot of enthusiasm and numerous hours. To be honest, I think I would not have spent that much time on creating this. I mean, developing this type of gimmick is interesting, but then actually manually manufacturing it, without using a SMT line of any sorts - I wouldn't have done that 'just' for a badge. Respects to the team behind that. Hopefully the source code will still get released.

We were also running an experimental GSM + GPRS/EDGE network based on OpenBSC, OsmoSGSN and OpenGGSN, enabling users to run port scans and the like against the carrier-facing side of the IP stack of their own devices. While running this network, I discovered a number of new bugs, mostly in the GPRS stacks of various handsets.

At least one model of Blackberry seems to ignore the MS identity cannot be derived from the network cause of a Routing Area Update Reject message, which we send in case the TLLI of the messages from the phone is unknown. I would expect it to come back with a GPRS Attach Request, but it never does. All it does is to keep re-trying Routing Area Update

The other funny observation is: Several phones, including some iPhone models, react in a strange way if you REJECT them from the GSM network but ACCEPT them on GPRS (Assuming Network Mode of Operation III). They then seem to be perfectly happy with this connection, but will only supply data services and no voice service.

Getting back to the conference, though: The Radisson Blu is an quite costly, upscale hotel. I was really surprised by the type and number of small mistakes they made, particularly with the catering. One day they forget to put the sour cream next to the potatoes - despite a written sign indicating that they are supposed to be with sour cream. Another day they serve some mousse as desert, but there are no spoons placed at the desert buffet. Furthermore, the number of tables they provided during lunch time was always insufficient for the number of people who had lunch. The quantity of food was more than sufficient, though - indicating that it was not a problem of them not knowing the number of people who were eating.

[ /linux/conferences | permanent link ]

All your baseband are belong to us

I'd like to point out the slides of the talk: All Your Baseband Are Belong To Us by Ralf-Philipp Weinmann.

Ralf is one of those few people on this planet who have understood the security implications of now being able to send arbitrary protocol frames (particularly GSM L3 04.08 frames) to mobile phones.

GSM protocol stacks have never been written with the assumption that somebody might send intentionally malformatted messages on the air interface. But at the same time, the GSM network does not authenticate itself to the phone, i.e. everyone who can present a network-side GSM air interface to a phone will be able to exchange arbitrary messages with the phones.

This problem has been outlined in all the GSM security workshops and presentations I have been giving during recent years. Still, apart from Ralf-Philipp Weinmann's work, I have not seen a lot of public research in that area.

Exploiting and owning the baseband processor is a dangerous threat, as the microphone and entire audio path are connected to that very processor. Whoever owns the baseband can turn the mobile phone into a passive surveillance device, commonly called 'bug'. Since application processor and baseband processor are very far apart these days, with various layers of software in between, the user interface will not show any indication of what the baseband processor does.

[ /gsm | permanent link ]