Miscellaneous Projects » Mobile (in)Security

{{>toc}}

h1. Withdrawal of A5/2 algorithim support

After several attacks have been published on breaking the A5/2 encryption algorithm, the specification bodies (ETSI, 3GPP)

and the operator industry (GSMA) have started to phase out A5/2.  This has been a lengthy process, taking some four years

from attack publication to all GSM operators having fixed their networks.

Four years for incident response is completely unacceptable and a ridiculous time to mitigate such a severe threat against

the confidentiality of personal communication.

As there seems no public document describing this lengthy procedure in detail, the page in this wiki was created. It also

touches aspects that are not strictly A5/2 related but related to introducing the A5/3 and A5/4 algorithms.

Most of the information has been recovered from the published "3GPP SA3 WG meeting reports":http://www.3gpp.org/ftp/Specs/html-info/Meetings-S3.htm

As can be seen from the records below, the security working groups in the 3GPP and to a less extent in the GSMA are doing

what they can.  But the operator and manufacturer industry simply has no intention to provide timely incident response

and to pro-actively improve security of their mobile networks.

h2. Timeline

h3. August 2003: Crypto 2003: E. Barkan, E. Biham, and N. Keller: Instant Ciphertext-Only Cryptanalysis of GSM Encrypted Communication

http://www.ma.huji.ac.il/~nkeller/biham_gsm.pdf

h3. November 2004: 3GPP SA3 Meeting 36

From the official "report":http://www.3gpp.org/ftp/tsg_sa/WG3_Security/TSGS3_36_Shenzhen/Report/Draft_Rep_v004_SA3_36.pdf:

_TD S3-041028 Vodafone comments to S3-040955: Proposed CR to 43.020: Clarifying the support of algorithms

within mobile stations (Rel-6). This was introduced by Vodafone and comprised an update to TD S3-040955. It was

reported that phasing out A5/2 was acceptable for the GSMA Board. The effect on other operators who implement

only A5/2 (if any) was unknown, as they do not participate in the GSM/3GPP standardisation bodies). The CR was

revised in TD S3-041075, which was approved._

h3. April 2006: GSMA Industry Initiative to Withdraw A5/2 Briefing Paper

The paper can be found "here":http://www.3gpp.org/ftp/tsg_sa/WG3_Security/TSGS3_44_Tallinn/Docs/S3-060541.zip

h3. July 2006: 3GPP SA3 Meeting 44

From the official "report":http://www.3gpp.org/ftp/tsg_sa/WG3_Security/TSGS3_44_Tallinn/Report/S3-060772.zip:

<pre>

Charles Brookson gave a review of GSMA Security Group activities. Progress was being made on the 2006 work items:

-	Withdrawal of A5/2 from GSM handsets and networks

</pre>

_It was noted that some manufacturers are reluctant to remove A5/2 from their mobiles as some operators were still using it. The answer was that work is still ongoing to convince operators, mainly from North America, that A5/2 should be removed._

This means that even by mid-2006, 3 years after the attack was published, A5/2 was still actively used by operators even in the 1st world!

h3. September 2006: Withdrawal of A5/2 from Handsets deadline

The GSMA SG statement regarding the deadline for withdrawal of A5/2 from handsets can be found the 3GPP TSG SA WG3 meeting 45:

"Withdrawal of A5/2 from Handsets Deadline":http://www.3gpp.org/ftp/tsg_sa/wg3_security/TSGS3_45_Ashburn/Docs/S3-060751.zip

In this document, the GSMA SG 

_The successful withdrawal of A5/2 requires terminal manufacturers to remove it from, or disable it in, emerging GSM enabled devices._

_The risk of operators continuing to demand A5/2 device support stems from the possibility that some operators may not upgrade their networks to support stronger algorithms in a timely manner. The emergence of devices without A5/2 support will mean that encryption will not be possible on networks that have not upgraded their BSS infrastructure to support A5/1 and/or A5/3. However, because of the nature of the attack, and the fact that A5/2 does not offer a higher level of protection than A5/0, it is deemed preferable that these networks run with no encryption rather than use the compromised A5/2 protocol. Therefore, there is no valid reason why operators would continue to insist on A5/2 support in devices - even those that use the algorithm - and that is the key message that GSMA is promoting to its network operator members._

This is very interesting, as it explicitly states no encryption is not considered as a problem in case operators did not yet upgrade to A5/1, but new non-A5/2 capable devices are used on their network.

_GSMA and device manufacturer representatives at a meeting in London on 25th July at which support was pledged for the withdrawal of A5/2 by end of this year_

_In GSM Phase 1, terminals were only mandated to support A5/1 and A5/0 (unciphered mode). Therefore in order to support GSM Phase 1 mobiles, A5/2 networks have always had to allow terminals to connect using unciphered mode (A5/0)._

As we can see, some GSMA members apparently prefer to show their customers that their call is not encrypted while they are too lazy to upgrade their networks:

_There were also concerns that non-encrypted calls could give rise to customers being shown non-ciphering indicators on some terminals, causing them alarm. However, operators can turn off this feature using a configuration bit on the SIM/USIM._

h4. Include testing for A5/2 removal in certification

_The GSM Association’s Security Group (GSMA SG) fully supports and endorses the work item proposed within GCF to develop test cases to verify the removal of A5/2._

h3. October 2006: 3GPP SA WG3 Meeting 45

"Change Requests (S3-060790, S3-060791, S3060792) regarding the removal of A5/2 from the specification have been agreed and send to SA.

h3. February 2007: 3GPP SA WG3 Meeting 46

From the [http://www.3gpp.org/ftp/tsg_sa/WG3_Security/TSGS3_46_Beijing/Report/Draft_Rep_v003_SA3_46.zip":http://www.3gpp.org/ftp/tsg_sa/WG3_Security/TSGS3_45_Ashburn/Report/Draft_Rep_v004_SA3_45.zip]:

_5.4 GSMA [...] There is still workin ongoing on the removal of A5/2 from mobiles and, indeed, from the networks. First it would appear to convince operators to remove it first._

h3. May 2007: 3GPP SA WG3 Meeting 47

"_A5/3 Support ([http://www.3gpp.org/ftp/tsg_sa/WG3_Security/TSGS3_47_Tallinn/Docs/S3-070437.zip S3‑070437":http://www.3gpp.org/ftp/tsg_sa/WG3_Security/TSGS3_47_Tallinn/Report/S3_47_Draft_Rep_v008.zip] Liaison Statement (from GSMA SG): BSS vendor support for A5/3): The level of support for A5/3, (or the lack of it), was discussed and we approved the attached LS for input to SA WG3. The concern is that A5/3 is not widely supported by BSS vendors and the LS asks SA WG3 to review and update the specifications to ensure a clear deadline for A5/3 support in infrastructure is identified and it also asks SA WG3 represented BSS suppliers to respond to GSMA regarding their current/planned support for A5/3._

While A5/3 is not required to phase out A5/2, this shows the lack of interest in the industry to improve the system security.

h4. GSMA SG Liaison Statement about vendor support for A5/3

From that Liaison statement:

_SA3 will be aware that the A5/3 specification was first published in May 2002 and initial targets were that the algorithm should be supported in handsets and network infrastructure by end October 2004._

_The GSM Association’s Security Group (GSMA SG) discussed the level of support for A5/3 at its meeting on 14th and 15th May and we are gravely concerned that there is virtually no support for A5/3 5 years after the algorithm was published. This is despite the fact that an absolute deadline was agreed within 3GPP that Rel-6 compliant handsets are mandated to support A5/3._

_GSMA SG is seriously concerned that if A5/1 was to succumb to sustained attack no backup algorithm has been widely deployed in handsets and infrastructure and this would have the effect of leaving the industry and mobile users exposed to security threats for an extended period._

h3. July 2007: 3GPP SA WG3 Meeting 48

"From the GSMA Liaison report:

_A5/2 removal has now been issued with closure report within the GSMA. Very good progress is being made with operators changing over to A5/1 in their networks. Similarly, mobiles without A5/2 are emerging and the testing regimes have been modified to support this. An internal closure report is available to GSMA members._

So it seems, in July 2007, _only_ four years after a serious attack has been disclosed, the problem was fixed ;)

_[http://www.3gpp.org/ftp/tsg_sa/WG3_Security/TSGS3_48_Montreal/Docs/S3-070540.zip S3-070540":http://www.3gpp.org/ftp/tsg_sa/WG3_Security/TSGS3_48_Montreal/Report/S3_48_Draft_Rep_v008.zip]: GERAN access security review update ... Concerning A5/1 it was suggested that it is not breakable for the moment_

A number of change requests regarding _Prohibiting A5/2 in mobile stations and other clarifications regarding A5 algorithm support_ were made and approved.

h3. 3GPP SA WG3 Meeting 49

"From the GSMA SG Liaison:

_In January 2007 a group of self styled “security enthusiasts” established the “A5 Cracking Project”, with the goal of designing and building affordable equipment that can crack A5/1. The project seeks to build on previously announced theoretical attacks against A5/1, and also aims to exploit the academic attack against A5/2 that was published in 2003 and that led to the industry decision to withdraw the algorithm._

_The backers of the project have publicly called for volunteers to contribute to the work by contributing expertise, information and money. The project is described in more detail at http://wiki.thc.org/cracking_a5, and consists of a number of phases. The first is to understand the status of various A5 hacking initiatives, the second is to crack A5/2 on a practical level, the third is to launch a practical attack against A5/1 using previously published academic papers, and the final phase will seek to identify new ways of attacking A5/1. _

_A second, related initiative called the GSM Software Project has also been launched.  The goal of this project is to develop a GSM scanner for under US$1,000.  The introduction and use of femtocells has made this a more likely possibility._

_Both projects are supported by The Hackers Choice, which in its own words is “a non-commercial group of computer experts focusing on practical and theoretical computer security … the group fosters independent research not driven by commercial interests and paradigms”._

_GSMA has carried out an analysis of the claims, and will be producing internal briefing documents. We have received favourable replies on upgrading to A5/3 both in the infrastructure and mobiles, and are following up the details_

h3. February 2008: 3GPP TSG SA WG3 Meeting 50

[http://www.3gpp.org/ftp/tsg_sa/WG3_Security/TSGS3_50_Sanya/Report/S3-080302%20SA3%2350_Draft_Rep_v002.zip":http://www.3gpp.org/ftp/tsg_sa/WG3_Security/TSGS3_49_Munich/Report/S3_49_Draft_Rep_v010.doc]

From the GSMA SG:

_A demonstrated attack on A5/1 is awaited perhaps in March at some hacker conference. GSMA has produced guiding papers for operators if need should be._

_SS7 protection is going to be discussed in the fore coming meeting of the GSMA group on roaming and interworking (IREG). TCAPsec and TCAP Handshake are the two candidate solutions, if they choose to do something._

h3. January 2009: 3GPP TSG SA WG3 Meeting 54

"_Recent joint meetings with the Mobile Manufacturers (EICTA) had discussed forthcoming tests to check A5/3 functions_

So in 2009 they are _discussing_ how to test A5/3 which was first specified in 2002 ?

h3. May 2009: 3GPP TSG SA3 WG Meeting 55

[http://www.3gpp.org/ftp/tsg_sa/WG3_Security/TSGS3_55_Shanghai/Report/FINALMeetingReport_SA3_55_v003.doc":http://www.3gpp.org/ftp/tsg_sa/WG3_Security/TSGS3_54_Florence/Report/SA3%2354_final_meeting_report_v002.doc]

_

A new series of work items had been started for the next period. If anyone was interested in working on these topics then they would be welcome: Software Only Infrastructure Algorithm Updates - Mandate capability to support security algorithms without need to replace hardware._

Mh, in 2009 they _start to think_ about mandating the software-updateability of ciphering algorithms in network equipment ;)

S3-091123 and S3-090829 are discussed, regarding 128bit encryption on GSM + GPRS as well as A5/4 key management

h3. July 2009: 3GPP TSG SA3 WG Meeting 56

"More discussion of Kc128 derivation from UMTS AKA (S3-091520, S3-091521) as well as the A5/4 and GEA4 specification (S3-091312)

h3. November 2009: 3GPP TSG SA3 WG Meeting 57

From the GSMA Liaison report:

_SG is looking at work items including the withdrawal of COMP128-1, something which is still causing issues for many operators after 12 years since it was broken._

12 years after it has been broken, the GSMA still has not officially withdrawn it?

Seven years after A5/3 has been specified:

_Successful tests were made on A5/3 enabled BTS equipment in Switzerland, with 10 handsets from 7 manufacturers being tested on a live network._

_We also discussed the need for a CERT-like warning scheme for the mobile industry_

_The meeting considered the need to ensure that future infrastructure algorithm updates will be exclusively software based_

h2. Miscellaneous

h3. The GSMA IR.21 roaming database

The GSMA is maintaining a database of GSM roaming operators called IR.21.  It contains information about

the various GSM operators world wide.

The structure of the information is described in 

[http://www.algerietelecom.dz/veilletech/bulletin67/pdf/mobile7.pdf GSM Association Roaming Database, Structure and Updating Procedures":http://www.3gpp.org/ftp/tsg_sa/WG3_Security/TSGS3_56_Seattle/Report/finalMeetingReport_SA3_56.doc].

Interesting bits of information are:

* Which ciphering algorithms are in use (this should tell us where A5/2 is still in use!)

* Whether or not _Authentication performed for roaming subscribers at the commencement of GSM Service_

* Whether or not _Authentication performed for roaming subscribers in case of GPRS_

Having access to this database (which is available to all 700+ full GSMA members) would give real insight in

the reality of GSM network security!

h3. GSMA PRD SG.15

the [GSMA_Security_Group] has a document called SG.15 which describes best common practises regarding the use

of GSM security features.

Unfortunately we don't have access to that document..

h3. Operators reluctant to phase out A5/2

"3GPP SA3 Meeting Report 44":http://www.3gpp.org/ftp/tsg_sa/WG3_Security/TSGS3_44_Tallinn/Report/S3-060772.zip (July 2006) states:

_It was noted that some manufacturers are reluctant to remove A5/2 from their mobiles as some operators were still using it. The answer was that work is still ongoing to convince operators, mainly from North America, that A5/2 should be removed. _

Interestingly, not the 3rd world countries were reluctant to switch to A5/1, but American operators ;)