Considering GSM Security


How secure is your phone? In this essay I consider the current state of GSM security, the strength of its cryptography, the privacy losses and touch on a few notable past security failures.

Do we even want strong cryptography for telephony? It may seem like “yes” is the obvious answer to this question, but in practice things are not so simple. The police and security services want access and are entitled to it by law. This makes designing a secure communications platform very difficult.

Walking in through the back

In light of this, any telephone system needs to give access to appropriate third parties. This has gone catastrophically wrong in the past. Backdoor functionality is rarely publicised[1] and so frequently does not get proper scrutiny.

In 2005 the Greek Prime Minister, the Mayor of Athens and 100 other officials learnt that their phones had been bugged. Vodafone Greece was compromised and the perpetrators used the wiretapping facilities of Vodafone’s systems. The malicious software implanted was only discovered when it generated errors and Ericsson was asked to fix it. Ericsson’s AXE switch had a lawful intercept feature, and an ingenious rootkit was installed that exploited this mechanism.

Crypto strength

Embedded devices are more limited in power, but with over 4 billion phones out there, engineers can get huge economies of scale for dedicated cryptography chips. This still leaves the question of how well designed the algorithm used is and how large the keys used are.

The algorithms used in GSM to encrypt the over the air traffic are A5/1, A5/2 and A5/3. It’s worth noting that this only covers the traffic between the handset and the base station, and the data is often not encrypted beyond that. Furthermore, although A5/3 is the strongest encryption algorithm of these, any A5/3-capable handset will downgrade if the base station does not offer 3G coverage.

A major problem for cryptanalysis of GSM is the lack of documentation. A5/1 had to be reverse-engineered by cryptanalysts before they could examine it. Today there are projects such as OpenBSC which implement GSM stacks to enable research.

I only talk briefly about the algorithms here, for further reading look at Cryptome’s GSM files.

A5/1

A5/1 is the compulsory GSM cryptography algorithm. The standards body chose a new algorithm rather than tried and tested algorithms. Ross Anderson discusses its weakness and political motivations in more depth on the comp.risks newsgroup.

A5/1 is broken. To briefly summarise its cryptographic weaknesses, it has an effective key length of 40 bytes, which is simply too short. Specialist hardware can be purchased (as do community projects [1] [2]) which will break the encryption in real time. A project to create rainbow tables (research paper here) has finished, making decryption much faster on a general purpose workstation.

A5/2

A5/2 is simpler and weaker than A5/1, and some attacks on A5/1 have been proposed which force phones to downgrade to A5/2. A5/2 is no longer supported by handsets released since 2006 (but took quite some time to get removed).

A5/3

A5/3, which uses the Kasumi cipher, is a substantial improvement. Kasumi is public and based on well established cipher called MISTY1. Sadly, A5/3 modifies MISTY1 and in doing so weakens it. To quote Bruce Schneier ‘attacks only get better over time’. A related key attack was found at the end of 2009 (research paper here), which uses four related keys to derive the full 128-bit key in only 2^32 time. At this point in time this is insufficient to mount a practical attack, provided that keys have been generated using good quality sources of entropy so related keys cannot be obtained. This is a major blow to A5/3 and places doubts on its long-term security. Sadly it is unlikely that the standards will change until we reach 4G mobile phones.

Alternatives available

What voice call options are available to the security conscious user? VoIP offers us an opportunity to select the encryption protocol ourselves, and avoid dubious untested protocols. The most popular option is ZRTP, a key exchange and encryption protocol intended for voice calls. This has the major advantages that it is a public, IETF Internet Draft that anyone can read, and is built on widely known protocols such as SRTP and AES.

As for Skype, reports vary. Skype is also undocumented (although as a business move this prevents 3rd party Skype clients). Skype has been claimed to be backdoor-free, although a number of public sector organisations have claimed they can access it, including the Austrian police. The CSO at Skype has refused to confirm or deny (German article) whether they can listen in.

Spoofing

There’s also the issue of spoofing. If a mobile phone can successfully convince the receiver that it is a different phone, it can access voicemail without encountering security measures. There are products such as Spoofcard that allow you to impersonate any caller ID you wish.

Ideally an attacker also wishes to spoof a number to the base station such that he can receive calls or texts intended for someone else. Whilst details are scarce, it seems that this has been achieved by some users using certain older Nokia handsets.

Bugging

Finally, a mobile phone has a wealth of information about you. Any GSM model will register with its local base station when switched on, so phone records later will show which cell you are in. In rural areas a cell can have a radius of up to 35km, but in cities it can be as small as 100m. The CIA were caught out by this in 2007. Today, many phones have even more accurate positioning using GPS or Skyhook technologies.

Some phones will actually act as bugs on demand. This ‘roving bug’ technique allows law enforcement to remotely install sound recording software on a handset. Again details are scarce, but I would imagine rooted Linux based phones would be immune to this.

 

(1) An exception to this is Cisco. To their credit, they document their lawful intercept system. This enables researches to examine the methodology.

Recent Posts

These Weeks in Remacs

This Week in Remacs

Announcing Remacs: Porting Emacs to Rust

Introspecting Glue Code

Searching A Million Lines Of Lisp