How safe is your network?

I was recently watching a video on youtube about GSM hacking (here) and it got me thinking, how safe are GSM networks and what can operators do to make them safer?

The first thing I looked at was the actual encryption algorithm itself. This is typically termed A5/X as there are a few different variants. A5/1 is the original encryption algorithm. A5/2 is a deliberate weakened version developed at a time when the standardisation community did not want to pass on the details of the A5/1 to certain non-trusted countries. A5/3 is the stronger version of A5/1. Finally A5/4 was recently introduced which is even stronger but still at its infancy in terms of support on UEs and deployment in live networks. So of all these options A5/3 sounds like the right choice to encrypt your voice calls. Right? Lets see..

First of all we need a device that supports A5/3. Even though the encryption algorithm has been around for a while, a lot of device manufacturers deliberately disable it. For the purposes of our testing I found a device that actually supported it as shown below.

Next we just need to make some voice calls and see which encryption algorithm the network instructs the device to use. The actual encryption is initiated via the RRC Ciphering Mode Command as shown below.

As can be seen the algorithm identity selected is 0. Looking at 3GPP TS 44.018 we find the table below which indicates that algorithm 0 equates to the older & and easier to crack A5/1. All 4 networks tested used A5/1.

The second thing to look at is how often is the ciphering key (termed Kc) is renewed. Obviously reusing the same key is bad practice and the ideal situation is to use a different cipher key for every call. The cipher key is generated by algorithm A8 using the RAND number and the individual subscriber key Ki. Ki resides in the SIM and RAND is sent via the Authentication procedure. It follows that in order to generate a new ciphering key Kc, the user needs to be re-authenticated. So how often does this happen?

Looking at operator 1, the same cipher key is re-used 7 times as shown below (only the messages of interest are shown and the rest are filtered).

Operator 2, seemed to have some random pattern of re-authenticating. This could be as low as once per call, but on other occasions the same cipher key was re-used 15 times.

Operator 3 had a regular pattern, re-using the same cipher key 15 times.

Finally operator 4 was the best of all re-using the same cipher key 5 times.

From an operators point of view of course, re-authenticating the user generates signalling load on the core network as the MSC/VLR has to fetch authentication triplets from the Authentication Centre. This explains why some operators are more or less generous with their cipher keys.

So what can you do as a subscriber to better protect yourself? Unless you have a trace tool, figuring out what ciphering algorithm your operator uses and how often the ciphering key changes is not something easy to find as operators do not make this information public. An easier choice would be to use the 3G network for your voice calls which means having a 3G device and finding a network that provides adequate 3G coverage. If you are are "brave" enough you could even lock you device to 3G only to prevent any accidental wandering to the 2G network. To date, to my knowledge, there have been no documented successful attacks on 3G networks.

Spectrum for rent, with a twist

At the recent auctions for 800MHz & 2600MHz spectrum here in the UK, a company by the name of Niche Spectrum Ventures Ltd (a subsidiary of BT) won 2x15MHz of FDD and 10MHz of TDD. 

There has been a lot of speculation about how a company that does not own a mobile infrastructure could use such spectrum and the conclusion is usually a) they build a network from scratch or b) they re-sell or lease the spectrum to an existing mobile operator.

However another business model I have been thinking of is a lot more interesting and it goes something like this..

A company wins some spectrum. It purchases and installs LTE small cells in key locations. These are fairly cheap and easy to install. If that company has transport network assets (like BT) then all the better. Once the small cells are installed and connected to an IP backbone, the company sells access to existing mobile operators. They way it does this is via MOCN (Multi Operator Core Network) functionality. For each customer that signs up their PLMN ID is broadcasted by the small cell and their core network is connected to the IP backbone. The specs allow for up to 6 PLMNs to be broadcasted so potentially all the existing mobile operators could be customers. What about the interworking of the LTE small cells with the existing network of the customer? Well, LTE has a raft of SON features that can take care of all of that with the minimum of manual intervention.  For neighbour planning the ANR feature can take care of that. This will work for intra-freq LTE, inter-freq LTE and IRAT. All it takes is for some UEs to camp on the small cell and send some measurement reports. PCI planning can also be automated as is RACH planning. As the core network is owned by the incumbent mobile operators do they have to do anything? Well not much. The S1 setup procedure takes care of that as it allows the MME and eNodeB to exchange the information they require to interwork. Finally from a UE perspective, MOCN functionality is mandatory in LTE so UE support is guaranteed.

As the company only owns radio network assets the management of the network is fairly simple as everything else (core network, billing, subscriber management etc) belongs to the mobile network operators.

That is it. All it takes is a commercial agreement, the PLMN ID of the customer and some minimal configuration.

CELL_FACH to LTE reselection in 3GPP release 11

Just to keep everybody on their toes it seems the wise people at 3GPP decided to introduce mobility from 3G CELL_FACH to LTE from release 11 onwards. As the figure above shows (TS 36.331), that all important arrow from CELL_FACH to E-UTRA RRC_IDLE has been introduced. Why it was not included  in the first place is still a mystery to me as from a UE complexity point of view I wouldn't have thought it would be that difficult. From a RAN point of view it just re-uses the FACH measurement occasion concept defined since release 99 that allows a UE to search for inter frequency and IRAT neighbours during specific time intervals when it knows the RAN will not send it any data on the SCCPCH.

In addition to the above, SIB19 on 3G has some changes as the operator can choose if all EARFCNs will be searched for or only the higher priority ones (if applicable).

Although CELL_FACH can be thought of as a transient state it is possible that a UE can stay there long depending on RNC inactivity timers and keep alive periodicity from applications on the UE. With this change then the possibility of being "stuck" in 3G is minimised.

Base station in disguise, gone wrong..

One of issues faced with operators around the world is getting planning permission for base stations. At least here in the UK, one of the most common designs is the base station disguised as a lamp post. They usually blend in nicely, the public don't even notice them and some even have a functioning lamp so they serve a practical purpose besides housing an antenna.

Sometimes however things go wrong as the photograph above shows. I wonder how many people notice that it is a bit strange to have two lamp posts separated by 1 metre. Clearly the traditional lamp post should be removed but I guess someone got a bit lazy.. 

Small Cells, Big Impact (my version)

I was reading the now few month old announcement from AT&T around small cell strategy here and a few things came to mind. First, the story. AT&T announced back at the end of January that they were planning to roll-out 40,000 small cells by the end of 2015. They have also posted a video on the link above that shows one of the products they are trialing, which although the logo is purposefully out of focus can easily be identified as the Alcatel Lucent 9364 Metro Cell described here. The video also mentions that AT&Ts plan is to roll these out to improve coverage which is where an important distinction in my opinion has to be made.

Small cells can be used for two scenarios. Scenario 1: Not spot. Scenario 2: Hot spot.

Scenario 1 is the easier of the two and the one AT&T has opted for. Regardless of how much an operator can try some areas will always suffer from poor/no coverage. Once these areas are identified a small cell can easily be installed to provide coverage. Small cells due to their femto background are easily deployed, mostly auto-configure and require just a backhaul connection which can be of xDSL nature. Due to their small size they are also usually exempt from the usual painful planning permission process.

Scenario 2 is the more difficult one. Here there is macro coverage, but due to the high amount of traffic the macro network cannot cope. The solution? Either try to use Wi-Fi offload (with the problems described in my previous post here) or use a small cell to absorb some of the traffic. However placing a small cell among large powerful macro cells is not as easy as some people make. At best the range of the small cell is severely interference limited and at worst it acts as a noise source affecting macro network performance. In addition to this UE uplink power can interfere with the small cell when power controlled by a macro cell further away. The solution to these problems is the new industry buzz word "HetNets" (Heterogeneous Networks). But what does Heterogenous mean anyway?

heterogeneous [ˌhɛtərəʊˈdʒiːnɪəs]adj

1. composed of unrelated or differing parts or elements

2. not of the same kind or type

When it comes to mobile telecoms, HetNets is essentially an umbrela term to descibe a number of features (some standardised and some not) that allow nodes of different types (macro cells, small cells etc) to co-exist. To date most of it is theoretical or simulation based so it is too soon to draw any conclusions as to how well HetNets will perform.

Another thing to bear in mind is that HetNets require close co-operation between the small cell and the macro cells which is where the small cells from a femto background might face some problems due to their flat architecture (combined RNC/nodeB) which essentially makes interactions between small cell and macro cell inter-RNC based. Traditional macro cell vendors have recognised this opportunity, which is why most of them are introducing small cells in their product portfolio.

All is not lost though, as vendors from a femto background already have a lot of experience in interference mitigation techniques and also auto configuration which when dealing with a large number of cells is a strong requirement.

It also worth remembering that LTE is based on a flat architecture so any advantages traditional macro vendors have might be short lived.

So, it will be interesting to see which small cells are the eventual winners. Will it be the enhanced femto cells or the miniaturised macro cells?

Nokia 6150, thirteen years on

When I started working in the mobile telecoms industry back in 2000, my employer at the time gave me a Nokia 6150. It was my first mobile phone and I loved it. At the time Nokia was the dominant force in mobile handsets and the 6150 was regarded as a top end device. Apple on the other hand in 2000 was purely focused on computers, launching products such as the Power Mac G4 and the iBook.

As time passed I got other mobiles and sold off the Nokia 6150. A few days ago however in a fit of nostalgia I went on eBay and purchased another 6150. A couple of days later I had in my hands and the rubbery keys felt instantly familiar. As I powered it on to make that first call, it got me thinking how much things have changed in the past 13 years..

So let's see. The Nokia 6150 supports GSM. That is it. No GPRS, no EDGE, no 3G, no HSDPA, no HSUPA, no HSPA+. Life was simple back then. Just GSM. The 6150 was dual band so it supported GSM in the 900MHz (no E-GSM though) and  the 1800MHz band. This at the time was quite a revolution. It also supported SMS, but only to a maximum of 160 characters, no concatenation. For data, it supported CSD (Circuit Switched Data) which essentially was a dial-up modem at an amazing speed of 9.6kbps! From a codec perspective it suppoted Full Rate, Half Rate and Enhanced Full Rate. No AMR obviously. Looking further into its capabilities it also supports the A5/2 cipher algorithm which has since been removed as a ciphering option by the GSMA.

Fast forward 13 years and the mobile telecoms industry has completely changed. But GSM networks are still around and are still backwards compatible as my Nokia 6150 works perfectly. I guess this is testament to those people in ETSI who developed GSM.

Comparing the Nokia 6150 to my current mobile, an iPhone 4, is obviously an unfair comparisson but one thing has not changed...

The weight. They both weigh 140gr!

CSFB alternative using E-UTRA detection

Traditional LTE deployments, set the LTE carrier(s) at a higher priority than the 3G carrier(s) thus ensuring the UE will always camp on the LTE carrier when present. Any voice calls are handled by CSFB with an associated delay in call set-up and a few signalling issues as described in previous posts.

I have recently been thinking of the IE eutraDetection as broadcasted in SIB19 on 3G (shown above) and an alternative approach to CSFB came to mind..

First let's look at how the IE eutraDetection is described in the specifications. The applicable document is TS 25.331 and the description is given as:

Furthermore section 8.6.2.5 provides this additional information "If the IE E-UTRA detection is included in a received message and set to TRUE and the UE is in CELL_PCH, URA_PCH state or idle mode, the UE may detect the presence of a E-UTRA cell on a frequency with a priority lower than the current UTRA cell and report the information to the NAS."

Taking the above into consideration the alternative to CSFB would be to set the LTE carrier(s) at a lower priority thus ensuring the UE camps on the 3G carrier(s). By setting the IE E-UTRA detection to TRUE the UE will display the 4G icon on the screen as that is passed on to the NAS layer. This will ensure the customer is happy as for all he/she knows they are camped on the 4G network.

Any voice calls would be set up on the 3G carrier directly without the need for CSFB and avoiding any call set-up delays. If on the other hand the UE wanted to establish a data session the RNC would trigger a re-direct or handover to 4G. Once the UE would finish with the data transfer it would reselect back to 3G but still display the 4G icon as before. So in essence the opposite of CSFB can be created, which could be termed PSFB :)

One problem with this approach is that UEs, especially smartphones, are prone to many small bursts of data, so these could be handled on the 3G layer and use a traffic volume measurement report to trigger the redirect  to 4G for larger data transfers. At the same time ISR (Inter-system Signalling Reduction) could be used to minimise the signalling when moving between the 3G and 4G networks.

So that is it, some small development needed on the RNC SW and PSFB could become reality..