Dieter Spaar's blog
   

RSS

Dieter's Web
mirider.com

Projects I am participating
OsmocomBB
OpenBSC

Categories

Archives

Other Bloggers
Harald Welte
David Burgess


blosxom


Contact/Impressum

       
Sun, 30 Jan 2011
GPRS Air Interface

To get a better understanding of how GPRS looks like at the air interface, I implemented some first experimental code in Airprobe (this is not yet ready to be released). The output of this code are the RLC/MAC blocks on the downlink (no uplink yet). As far as I am aware, WireShark cannot decode RLC/MAC yet.

The GPRS air interface is not that different than "standard" GSM (signalling or voice). The PDCH (Packet Data Channel) uses its own multiframe structure with a length of 52 frames, the biggest difference are four coding schemes (CS-1 to CS-4, CS-1 and CS-2 use puncturing) which are chosen depending on the quality of the radio link. If the link quality is good, a coding scheme with less forward error correction and more information bits is used which results in a higher data rate. As a side note, you can test how good your receiver really is if CS-4 is used (very good radio link quality, no forward error correction at all), you should have nearly no bit errors in the decoded data (the phone also receives error free data, otherwise CS-4 would not be used).

I have not yet implemented decoding EDGE, besides other coding schemes EDGE can also use a different modulation (8-PSK instead of GMSK).

Please note that being able to decrypt the A5 encryption does not help with GPRS, it does not use A5 encryption at all, it uses its own encryption algorithm (GEA) at a higher level. If you want to experiment with GPRS encryption, the easiest to start with is probably using a GPRS setup with OpenBSC plus the nanoBTS and look at the traces to the SGSN with WireShark (you have to implement a GPRS encryption algorithm in osmo-SGSN first, the specification of GEA3 is publicly available).

[ /gsm | permanent link ]

Tue, 25 Jan 2011
TETRA Air Interface

If you are interested in how the air interface and the lower levels of TETRA work, you should have a look at the http://tetra.osmocom.org/ website.

My contribution so far was to search for a suitable demodulator (TETRA uses PI/4-DQPSK) which I found at the OP25 project (the author of the demodulator is KA1RBI).

I also implemented some "proof of concept" code which allows decoding speech traffic and converting it to raw audio using the TETRA reference codec. Please note that this cannot be used to listen to encrypted TETRA traffic, it only works if no encryption is used.

[ /sdr | permanent link ]

Sat, 22 Jan 2011
GSM Ciphering Algorithms in mobile phones

You are probably aware that the A5/1 and A5/2 GSM ciphering algorithms are broken, A5/2 is so weak that even the GSMA mandates that it is no longer used in new mobile phones. A secure alternative would be A5/3, however it is not yet deployed in GSM networks, at least those networks I am aware of, and only some newer phones support it.

I had a brief look at some phones I have access to, most of them came out in the last four years. Interestingly quite a lot of them still support A5/2 and only very few support A5/3. If a phone does not indicate A5/3 support, this does not necessarily mean that it is not capable to run A5/3, for example on one of my test phones, a BlackBerry Bold 9000, A5/3 is disabled (for whatever reason). The phones in my collection with enabled A5/3 support are some new, cheap features phones from India based on a MediaTek chipset. And as a side note: The iPhone 4 I looked at does not have A5/3 enabled but at least A5/2 is disabled.

I also did a few quick tests to make sure that A5/2 cannot be used on those phones which claim that they do not support it, and so far this seem to be the case. The reason for this test: The phones can most certainly run A5/2 if they can run A5/1 (which all of my phones can), A5/2 is very similar to A5/1. If a phone claims to support only A5/1, it does not necessarily mean that the phone will not use A5/2 if you force it to do so, if there are bugs in the phone firmware, the phone could still run A5/2.

The short tests I did are only a first look at this issue. Additionally the same phone model could behave different when sold by a different operator or in a different country, as I already wrote, most of the time the supported ciphering algorithms can be configured by the phone manufacturer. So this is an area which should be investigated further.

[ /gsm | permanent link ]