OpenBSC field test at 27c3 over

During the last week I was busy with

• December 22nd though 24th: Preparing OpenBSC to be ready for the field test at 27c3, i.e.
  • improving the output of the log at "INFO" level to be not too verbose at the expected network load
  • Implement the interface to LCR using a Unix domain socket rather than linking LCR with OpenBSC
  • Configuring all 6 BTS, put them in multi-TRX config, test the setup
  • Manufacturing nanoBTS stacking cable (with their weird RJ-69 plugs that you have to mill a notch off)
  • Install all required software on the machine that will run OpenBSC
• December 25th and 26th: Setting up the network
  • Physically mounting the nanoBTS units
  • Patching cables throughout the building, installing PoE switches
  • Configuring LCR
  • Interfacing with the Phone Operation Center (POC) via E1 / DSS1
• December 26th through 30th: Running the network
  • Fixing bugs as they appear (see e.g. zeckes mailing list post
  • Making sure users are happy
  • December 30th: De-installing the network

  I don't have much time now, still have to unpack lots of boxes full of gear. However, I have finally completed my scripts to graph some of the statistical data of the field test. You can see the graphs in the OpenBSC wiki.

  Unfortunately we don't have the same body of statistical data for the previous field tests at 25c3, 26c3 and har2009. However, for all of those three events we have now graphs about the IMSI/Country distribution of all the phones that have ever tried a LOCATION UPDATE with us: 25c3, 26c3, HAR2009, providing some nice statistics on what nationalities are attending the respective events.

Interview about GSM security (in German)

The major Austrian newspaper Der Standard was yesterday featuring an an Interview with me on GSM security related issues. Being in Austria, the interview is obviously in German language, sorry for all non-German-speaking readers of my blog.

Preparations for GSM network at 27C3 conference

Behind the scenes, we've been working on preparing the experimental GSM/GPRS/EDGE network at the 27th Chaos Communication Congress. The regulatory authority was nice enough to grant us 6 ARFCN, which we will split to 3 BTS (2 TRX each), resulting in one BTS with 2 TRX on each of the 3 conference building floors.

I've started a page in the 27C3 conference wiki about the GSM network. Please notice that this information is still preliminary at this point.

The wiki page also contains detailed instructions on how you can participate in the test network. I'm hoping a lot of you will bring a dedicated cellphone that you can put the 27C3 SIM inside and participate in the network.

I'm particularly excited about GPRS/EDGE support. We will be handing out official, world-wide routed, unfiltered IPv4 addresses to each and every phone. This means you are free to run port scans or other attacks (please: No DoS) over an unfiltered IP network directly into your mobile phone.

Learning how GPS _really_ works in order to truly understand RRLP

Back one or two years ago, when I first discovered the RRLP as a mechanism how operators can get very precise GPS positioning of a mobile phone (without any authentication or a way for the user to prevent or at least notice it), I was frankly speaking shocked.

We've done some experiments at HAR2009 and obtained a number of great position fixes, mostly from iPhones. The nice aspect of RRLP is that it is buried down inside Layer3 of the GSM protocol stack in the baseband processor. This is at a much lower level than all the web or App based location based services that are running in an application program in userspace of the application processor.

Now RRLP comes in a number of different flavors. What we have done so far is called ms-based positioning, where the phone works as an autonomous GPS receiver, pretty much like a personal navigation device or any hand-held GPS receiver. So the network simply asks "tell me your GPS coordinates if you know them" and the phone will respond. Some phones ask for assistance data in order to do A-GPS. But that's it.

What has been more of a mystery to me is the ms-assisted GPS RRLP mode, where the phone just performs some measurements and forwards the resulting data to the network. I never really understood the details of how it works, but always wanted to. Last week I finally found some time to do the research required to fully understand it:

The network tells the phone the exact bit timing, Doppler shift and other parameters for each of the satellites that it _knows_ the phone would be receiving given the current cell the phone is registered to. The phone then performs some measurements within very narrow time/frequency/synchronization windows, and passes back the timing of those received signals relative to the current GSM cell signal. Using this information, the actual position estimate will be completely computed inside the network, not inside the phone.

Presumably this ms-assisted mode was implemented to not have to put a full-blown GPS receiver into every phone, requiring sophisticated processing in either hardware or software. Also, this method should be much quicker as the network _knows_ all the current ephemeris data and GPS signal timing, whereas a stand-alone GPS receiver would have to take quite a lot of effort to acquire a signal from cold-start, even if there is some assistance data.

Unfortunately I don't have the time to actually implement the network side for this. It would be a fun project, but I have already way too many of them (and customers who only pay for other features in our Free Software GSM stack).

There's now a RRLP wiki page at security.osmocom.org. As short as it is it still contains more information about RRLP than I could find on any other public source on the network - except the protocol specs.

Wireshark patches enhancing IPA Abis/IP dissector accepted

The wireshark project recently accepted two of my patches related to the Abis/IP dissector. The first of them makes the TCP/UDP port numbers that are interpreted as IPA multiplex a configurable preference. This is really useful, as the actual port numbers used in production setups seem to differ from site to site (with no real standard port numbers and only some that are 'best practise'). Without this patch, in many case you always need to click 'Decode as... GSM IPA' every time you open a pcap file.

The second patch adds support for printing the debug messages that the Hay Systems Ltd. HSL Femtocell includes as stream identifier 0xDD in its Abis/IP variant.

I hope I can find some time to clean up / finish some of the other wireshark patches that we have pending for quite some time. The main problem here is that we imported some definitions from OpenBSC, which use gcc extensions and are thus not permissible for wireshark inclusion.

A US professor who was warning the Indian Government about lack of IT security in Voting machines is being deported from India

According to news reports, J Alex Halderman is refused entry into India and will be deported from the country upon entering. He is one of the authors of the study India's EVMs are vulnerable to fraud which a number of international experts on electronic voting machine security had published in order to warn the Indian government about the flaws in their voting machines.

This is outrageous. Instead of trying to keep those researchers out of the country, the Indian government should invite those experts (who are giving free advice about IT security problems) and have them do a detailed analysis and start an official investigation into why and how the existing machines could ever be used for election purposes.

It seems like the authorities in question have absolutely no clue on how proper incident response is being done. You don't get people to trust your system if you jail activists who outline flaws in voting machines and try to keep foreign experts out of the country. Trust has to be earned. And if there is some serious incident, a public investigation should be started, open to all experts in the field. Trying to cover up by ignoring results of IT security research (academic or otherwise) will not make the system more secure. All this will help is to further undermine trust in the system.

I would like to use this opportunity (and my upcoming trip to FOSS.in/2010) to call upon all my Indian friends: Don't just sit there idle and allow your government to get away with this. The public needs to know how trustworthy the voting machines are. If there are serious objections by academic experts in the field, the system needs to be updated/upgraded or even abolished altogether. Elections are the foundation of a democracy, their results cannot be entrusted to technology that has never received public and independent scrutiny.

UPDATE: It seems that according to indianevm.com, he was only held for 18 hours and later permitted entry into the country. While this is good news in general, it remains unclear why they held him for deportation in the first place, and why the Indian Electoral Commission is so nervous about anyone doing legitimate research on the security of electronic voting in India.

Back from the GPL Compliance Engineering Workshop in Taipei

I've been a bit over a week in Taipei, mainly to co-present (with Armijn Hemel) the GPL compliance engineering workshop at Academia Sinica. The workshop was attended by more than 100 representatives of the local IT industry in Taiwan, from both legal and engineering departments.

I think even only the sheer number of attendees is a great sign to indicate how important the subject of Free Software license compliance has become in the IT industry, and specifically in the embedded consumer electronics market.

I would like to use this opportunity again to thank the OSSF at Academia Sinica for doing a great job in organizing this event.

Thanks also to Armijn, who not only does excellent work at gpl-violations.org but also covered the majority of the presentations at the workshop.

So what did I do the remaining week? Lots of meetings, mostly with companies regarding GPL compliance, but also with old friends like Wolfgang Spraul and Holger Freyther who happened to be in the city at the same time.

I also had some very exciting meetings related to my various GSM related FOSS projects, but it is too early to really say anything about them.

Starting to work on drivers for the Mediatek MT6139/MT6140 RF Transceiver

In the last two days, I have finally started to get some initial work done on the OsmocomBB port for the Mediatek chipsets. My current focus is the MT6139/6140 RF Transceiver, including stuff like setting it up for Rx and Tx, computing the VCO/PLL dividers for all ARFCNs in 4 bands for uplink and downlink, etc.

Next will probably be the drivers for the MTK digital baseband BPI (baseband parallel interface) and BSI (baseband serial interface), which are needed to actually use the MT6139/6140 driver, as well as the antenna switch module, power amplifier and other parts of the RF front-end.

I'm not really testing any of this code at the moment, as I'm travelling a lot without access to my Racal 6103 or other GSM handset testing equipment. However, writing even untested code helps me understand the chipset better and is a first step in the right direction. I guess January 2011 will provide more time to continue/complete this task.

ST-Ericsson releases (and submits) Android GStreamer code

Back in October I blogged about ST Ericsson hooking gstreamer into Android but apparently making that code proprietary. I may have been a bit opinionated at the time. The reasons for not disclosing the code allegedly were that it is assumed to be of no general use. However, it still felt very bad that two Free Software projects are interacting with each other through a proprietary layer.

I've since had a very pleasant contact with the Head of MeeGo Business Development at ST-Ericsson and they have now released and submitted the respective code-bases, like the gst-android git repository and the Audioflinger sink in the gst-plugins-bad repository as well as Android makefiles for all parts of gstreamer.

It is great to see this kind of development, and see that ST-Ericsson is trying hard to do the right thing: Not only releasing their extensions of gstreamer under a GPL-compatible license to their customers, but even actively pushing those changes upstream. Thanks to everyone involved, particularly Andrea Gallo and Benjamin Gaignard.